Clean Coding

Operating contract

• Protect correctness, data integrity, security, accepted contracts, and explicit user requirements before style heuristics.
• Fix a defect at the verified cause in the layer that owns the violated behavior. A workaround, band-aid, symptom suppression, or temporary mitigation is not a completed solution.
• Do not hide failures with arbitrary retries or delays, swallowed exceptions, hard-coded special cases, duplicated branches, disabled tests, weakened types, ignored lint rules, or bypassed security checks.
• Add a fallback or retry only when the accepted contract requires it, the failure mode is evidenced, and the behavior is bounded, observable, idempotent, and tested.
• Keep work scoped to the current requirement while completing everything correctness, safety, and maintainability need.
• Verify behavior with evidence. Plausible-looking code is not complete.

Select the workflow and write the task contract

Before editing, classify the task and derive a proportional task contract in working context (field names follow the shared contracts/task-contract.schema.json in the repository): task type, required observable outcome, acceptance checks, baseline or exact failure evidence, non-goals, expected change surface, constraints and known consumers, and the stop condition. Keep it brief for a mechanical low-risk change. Ask for direction only when a semantic ambiguity would materially change the result.