Coding standards

Maintain one concise project source for rules an independent reviewer must judge. Treat observed code as evidence, not policy, and prefer executable enforcement whenever it is reliable.

Process

1. Resolve the source. Use the path named by the user, then an established project standards source, otherwise root CODING_STANDARDS.md. Read any existing source before proposing changes. Do not create a second canonical file.
2. Inspect competing owners. Inspect only enough applicable agent instructions, contribution guidance, scripts, CI, formatter, linter, type, test, and build configuration to find contradictions, duplication, or a stronger owner. Inspect code only to understand the consequence and scope of a candidate rule; prevalence does not make a pattern accepted policy.
3. Filter each candidate. Keep a rule only when it is accepted, project-specific, durable across changes, concrete enough to judge in a diff, and not reliably enforceable elsewhere. Route other information without modifying its owner:
   • machine-checkable rules belong in executable configuration or CI;
   • navigation, non-obvious working choices, hazards, and authority boundaries needed during implementation belong in applicable agent instructions;
   • requirements, architecture, domain meaning, and durable rationale belong in their maintained sources;
   • task findings and preferences without project authority are not standards.
4. Propose the smallest delta. Show exact additions, revisions, removals, moves to stronger owners, and unresolved conflicts. Prefer deletion when a rule is stale, duplicated, generic, too vague to review, or now enforced automatically. Ask only about material policy choices that available evidence cannot settle.
5. Obtain acceptance. Do not establish or change project policy without explicit human acceptance of the proposed delta. A review, implementation, or retrospective finding may recommend a candidate rule but cannot add it as a side effect.
6. Apply and verify. Preserve unrelated content and write only the accepted delta. Use a simple # Coding standards document with ## Review rules and, only when needed, ## Exceptions. Verify that every retained rule has a clear review consequence, every pointer resolves, no stronger executable owner already enforces it, and the repository diff matches the accepted delta.

Boundaries