constraint-designlisted

# Constraint Design A constraint is a rule that must be enforced — not a suggestion, but a hard boundary. In the harness framework, each constraint occupies a **verification slot** that can be filled by either a deterministic tool or an agent-based review. The system does not care which backs the slot; only whether the constraint passed. ## Anatomy of a Constraint Every constraint in HARNESS.md has four fields: - **Rule** — what must be true, written precisely enough for objective verification - **Enforcement** — `deterministic`, `agent`, or `unverified` - **Tool** — which tool or agent checks this (or "none yet") - **Scope** — when the check runs: `commit`, `pr`, `weekly`, `manual` ## Writing a Verifiable Rule The rule field is the most important. Apply the same enforceability test used for conventions: 1. Describe what compliant code looks like 2. Describe what violating code looks like 3. Confirm a reviewer (human or agent) could check this without ambiguity Consult the `context-engineering` skill's convention patterns for detailed examples. ## Choosing Enforcement Type | Question | If yes | If no | | --- | --- | --- | | Does a deterministic tool exist for this? | Use deterministic | Continue | | Is the rule precise enough for consistent LLM review? | Use agent | Use unverified | | Is the team ready to set up tooling? | Use deterministic | Start with agent | Start with unverified if unsure. Promote when ready. ### Command Risk Classification For tool-leve