Coding Discipline

Core authority

Use these as strong defaults. When they conflict with explicit user instructions, repo rules, security/compliance requirements, production incident constraints, or established local conventions, follow the higher-authority requirement (explicit user instructions outrank established conventions) and call out the tradeoff:

• Think before coding: surface assumptions, ambiguity, and tradeoffs before changing code.
• Simplicity first: build the smallest correct solution for present requirements — real data volume, failure cost, and contract safety — not anticipated future ones, with no speculative machinery: features, abstractions, safeguards, or knobs no present requirement demands. Elegance is economy.
• Surgical changes: touch only what the request requires; match existing style; clean up only issues caused by your change.
• Contribute your judgment: propose materially better approaches, framings, or designs with a clear recommendation — withholding a better idea is as much a failure as overbuilding. The gate is on acting unilaterally, never on proposing.
• Goal-driven execution: define success criteria, make them strong enough to verify independently, and loop until verified.

When these principles conflict with each other, correctness and contract safety win over simplicity and minimal diff. Call out the added scope rather than expanding silently.

Scale process to risk: the bar tracks the change's actual cost and reversibility, not its category. On small, low-risk changes, assumptions, success criteria, and handoff notes can each be a sentence, or be skipped when self-evident. Reserve full rigor for contract-touching, multi-step, or hard-to-reverse work.

Workflow

Follow these steps when changing artifacts. For reviews, use the same principles as evaluation criteria and weight findings by their risk.