contractlisted

# contract — The rules this project holds itself to A coding-standards document that only exists as prose is a document nobody re-reads. This skill writes one, then does the thing that makes it matter: **compiles every rule that can be enforced into the place that enforces it.** Each rule lands in exactly one of three tiers, and the tier is chosen by *how the rule can be checked*, not by how important it feels: | Tier | Destination | Enforced by | | :-- | :-- | :-- | | **Mechanical** | linter, formatter, type checker config | the quality gate — it cannot be skipped | | **Judgment** | the reviewer's rulebook, as a rule with an id | the reviewer — it is cited in findings | | **Narrative** | the contract document only | nothing; it is context, and it is honest about that | A rule that lands in Narrative is not a lesser rule. It is a rule you have decided not to enforce, which is worth knowing. ## Where it goes `<docs>/CONTRACT.md` — with its Judgment-tier rules compiled into the reviewer's rulebook. `<docs>` is the `- Docs:` line in `.steering/tech.md`, which defaults to `docs/`. In a multi-repo product it points at the shared documentation repository instead, so product-level truth has one home rather than one per repo. ## Steps 1. **Read what the project already does**, before writing what it should. `.steering/tech.md`, the linter and formatter config, the existing code, and — most valuable — the last fifty commits and any review comments. A convention followed in th