architecture-contracts-as-lawlisted

# Architecture contracts as law Large systems accumulate implicit invariants ("this module never imports that one," "only this file talks to the LLM SDK") that everyone half-remembers and nobody has written down. The fix is a single, explicit contract document that is treated as merge-blocking law, updated in the same commit as any change to what it governs: not a wiki page that quietly goes stale. ## The contract document is a source of truth, not documentation Whatever you call it (a CONTRACTS file, an architecture decision record, an invariants doc), it needs one property to actually work: **drift between it and the code is treated as a bug**, not as "the doc needs updating eventually." Concretely: - Any change to schema, API/wire shape, route surface, or a documented invariant updates the contract document **in the same commit**, and the change is called out explicitly in the summary of that commit/PR. - If the contract is ambiguous or looks wrong for what you're trying to do, that's a stop-and-surface moment. Don't silently improvise an interpretation and move on. - Locked algorithms or formulas (see the llm-eval-harness-and-scoring-pipeline skill for a concrete example) live here, with an explicit note on who has to sign off before they can change. ## Enforce a module dependency direction, and name the exceptions If your system has a layered or DAG-shaped dependency structure (module A may depend on B but never the reverse), write the intended direction down expli