| name | enterprise-contract |
| description | Use when an enterprise implementation plan exists and work needs a locked contract with postconditions, invariants, consumer mapping, and traceability before build starts |
Enterprise Contract
The contract is the build gate. No enterprise build starts without it.
Inputs And Outputs
- Input:
docs/plans/YYYY-MM-DD-<slug>-plan.md
- Output:
docs/contracts/YYYY-MM-DD-<slug>-contract.md
- Side output:
.codex/enterprise-state/agent-sessions/<agent-id>-<slug>-postconditions.json
Entry Gate
Before locking or editing the contract, the current agent session must already record the plan artifact. Use the agent stage gate in agent-stage-gates.md before proceeding.
Contract work may consume most of the lane. Do not lock while current code, real DB schema/query behavior, file boundaries, SRP, E2E trace, or edge cases remain unclear.
Source And Database Grounding Gate
- Read the current implementation and consumers before writing postconditions. A contract based only on a migration, git diff, branch name, or plan prose is invalid.
- For schema/query/data-sensitive work, inspect real migrated Postgres or a live/dev DB surface before locking. This happens before postconditions are trusted, not after build.
- Every schema/query/data-sensitive postcondition must name a live DB or real integration test. Mocked database tests do not count.
- If live DB proof is unavailable, lock is blocked unless the user explicitly narrows the claim away from schema/query behavior.
- For UI, PDF upload, invoice upload, file upload, preview/download, modal, navigation, or rendered-output behavior, the contract must name headless browser proof.
- For owned-table or governed write paths, name the ownership seam and the DB ownership gate command. Direct writes in mixed-owner files are contract failures unless explicitly allowed.
Required Sections
Use contract-template.md as the starting shape.
- status header:
DRAFT then LOCKED
- preconditions
- postconditions by layer
- invariants
- error cases
- consumer map
- file and module architecture
- E2E trace and edge cases
- repo gate matrix
- live proof artifact plan
- blast radius
- side effects
- explicit non-goals
- traceability matrix
Lock Rules
Do not mark the contract LOCKED until the quality gate in quality-gate.md passes.
Once locked:
- build cannot invent new scope silently
- every new forge bug becomes an appended postcondition
- proof claims must trace back to this contract
- local CI mirrors, PR-body requirements, no-new-mock checks, DB ownership gates, and live-proof commands must be named before source edits continue
- the current agent session must record the locked contract and the session-scoped postconditions file
High-Risk Domain Rule
If the task touches money, auth, regulated data, external integrations, or any end-to-end hardening claim, run the checks in high-risk-domain-gate.md before locking the contract.
Fail-Closed Rules
- No vague postconditions
- No unmapped consumers for changed outputs
- No unowned blast-radius findings
- No unknown merge blocker, PR gate, no-new-mock gate, DB ownership gate, or live-proof command
- No
full-system claim unless the contract truly covers all required legs
