enterprise-contract

Files (5)

• SKILL.md
• evals.json · evals/
• contract-template.md · references/
• high-risk-domain-gate.md · references/
• quality-gate.md · references/

SKILL.md (first lines)

# 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](../enterprise/references/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](references/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](references/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](references/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

From anotherben/agentic-governance, MIT.

More from anotherben/agentic-governance