Coding

Goal

Write code whose shape is justified by the way it runs, the data it moves, and the evidence that proves it still behaves correctly.

Prefer direct, measurable reasoning over abstract architecture taste. When choosing between two designs, ask what changes in runtime, memory traffic, allocation count, branch shape, data locality, generated code, and verification cost.

Default Workflow

1. Read the local rules. Check repo instructions and the relevant source before editing.
2. Find the real path. Identify the code path the request changes, the data it reads and writes, and the boundary where behavior is verified.
3. Reuse deliberately. Search for existing types, helpers, folders, and validation commands before adding new ones.
4. Choose the simplest performant shape. Prefer functions for logic, simple data objects for state, explicit inputs, explicit outputs, and layouts that keep hot data compact.
5. Build scaffolding. For performance-sensitive or structural work, create or use instrumentation that measures the relevant cost. Working without instrumentation is working blind.
6. Write comments where context would be missing. Explain hot paths, memory layout, instrumentation boundaries, and surprising tradeoffs in plain language.
7. Verify. Run the focused tests, type checks, benchmark, trace, or validation command that proves the change.
8. Summarize evidence. Report the changed behavior, performance boundary if relevant, validation commands, and remaining risk.