Clean Coding

Apply the operating contract

• Protect correctness, data integrity, security, accepted contracts, and explicit user requirements before applying style heuristics.
• Select the workflow that matches the task. Do not force bug-fixing language onto features, refactors, or reviews.
• For a defect, fix the verified cause in the layer that owns the violated behavior or invariant.
• Do not implement a workaround, band-aid, symptom suppression, or temporary mitigation as the 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 fallback behavior only when the accepted contract requires it and the fallback is bounded, observable, and tested. Do not add a fallback merely to make a failure disappear.
• Treat a retry as legitimate only when evidence identifies a transient failure mode and the operation has verified bounds and safe/idempotent behavior. Reconcile the outcome of any state-changing attempt before retrying it.
• Keep work scoped to the current requirement while completing everything needed for correctness, safety, and maintainability.
• Verify behavior with evidence. Do not call a change complete because the code looks plausible.

Select the workflow and define the acceptance contract

Before editing, classify the task as a defect or incident, feature, refactor, review, or an explicit combination. Write a proportional acceptance contract containing: