constraint-design

Write the rule precisely enough for objective verification: describe what compliant code looks like, describe what violating code looks like, and confirm a reviewer could check it without ambiguity. Each constraint needs Rule, Enforcement, Tool, and Scope fields.

Use deterministic enforcement when a tool exists for the rule, such as a linter or formatter. Use agent enforcement when the rule is precise enough for consistent LLM review but no tool exists. Start with unverified if unsure and promote later.

Use commit scope for fast checks like formatting, pr scope for thorough checks like tests and secret detection, weekly for slow checks like dependency audits, and manual for exploratory rules being calibrated. Start with pr scope for most constraints.

Promote when a deterministic tool can check the rule, when you want faster and cheaper enforcement, or when the constraint wording has been stable across several audit cycles. Partial promotion is also possible, combining deterministic presence checks with agent quality review.

Agent enforcement is non-deterministic and may give different results on the same input. It is also token-intensive and slower than deterministic tools, so it suits nuanced rules that resist mechanical checking rather than high-frequency checks.