← Corpus / corpora-builder / contract

Autonomy Gates — what an agent may do here unattended, and where it must stop

A written answer to "may I proceed?" — a green list that needs no permission, a red list that always does, and the four gates in between.

Path
contracts/Autonomy-Gates.md
Authors
Michael Staton
Augmented with
Claude Code on Claude Opus 5 (1M context)
Tags
Contract · Corpora-Builder · Autonomy · Agent-Behavior · Context-Vigilance

Autonomy Gates

context-v/contracts/ is an experimental folder per the context-vigilance skill. This is a constitution contract in that skill’s sense: standing rules an agent follows regardless of session, task, or model — not a suggestion, and stronger than a reminder.

Why this exists

The operator’s stated goal:

“I want to get to the point where I can let you loose and you mainly work as I hope and accomplish what you can accomplish and I don’t need to jump in except to check the work and make decisions.”

Two failure modes stand between here and there, and they pull in opposite directions:

  • Asking too much. An agent that checks in every twenty minutes has not saved the operator anything; they are still in the loop, just with worse ergonomics than doing it themselves.
  • Asking too little. An agent that pushes to master, rewrites a spec to match what it happened to build, or relaxes a failing assertion has produced work the operator cannot trust — which costs more than not running at all.

This contract draws the line so neither happens by accident. It pairs with [[../loops/Spec-to-Shipped-With-TDD]], which defines what the work is; this document defines how far you may take it alone.

GREEN — proceed without asking

Do these freely. Report them; don’t request them.

Documentation

  • Draft or revise anything in context-v/explorations/, specs/, plans/, issues/, decisions/, handoffs/
  • Write changelog/ entries at meaningful chunks
  • Update date_modified and bump semantic_version per the versioning convention

Code

  • Write and run tests
  • Implement against a signed-off spec until the ledger is green
  • Refactor within a spec’s scope when tests stay green and behaviour is unchanged
  • Run ruff, mypy, pytest, spec_status.py as often as useful

Git

  • Commit and push to development or a working branch
  • attempt(...) safety commits on failed verification — always preferred to a dirty tree

GitHub

  • Create issues and project items; mark them done as work lands

Storage

  • Read anything, anywhere
  • Write to the designated dev bucket only

Judgment calls

  • Naming, file layout, library choice within the stated stack, test structure, error-message wording, refactor boundaries. Make the call, state it in one line, move on. Do not convene a meeting about a variable name.

RED — always confirm, no matter what

These require explicit operator confirmation every time. A prior yes on one does not carry to the next, and no gate state makes them green.

  • Push to master. Ever. main only when promoting deliberately.
  • Force-push, history rewrite, or branch deletion on any shared branch
  • Write to any client corpus — augment-it/clients/*/corpus/ is read-only from here. reach-edu is a proving fixture, mirrored up, never written back.
  • Write to any R2 bucket other than the dev bucket
  • Delete or overwrite corpus content, including “cleanup” of files that look like junk
  • Anything outward-facing — deploys, published artifacts, anything that leaves the machine
  • Spend real money — provisioning paid infrastructure, raising storage tiers
  • Relocate a repo within the tree — triggers the root CLAUDE.md HARD STOP three-precondition checklist, which no autonomy setting overrides
  • Re-run corpus ingestion into Chroma — the operator runs that deliberately
  • Install a new MCP server or add a skill symlink — these change every future session

The four gates

From [[../loops/Spec-to-Shipped-With-TDD]]. At each: stop, state where you are, state what you’d do next, wait.

Gate 1 — a decision with no obvious default. Use AskUserQuestion, lead with a recommendation and its reasoning. If a defensible default exists, take it and say so instead of asking — a question with an obvious answer is noise.

Gate 2 — spec sign-off. Never implement an unsigned spec. Writing the spec is green; acting on it is not.

Gate 3 — a test that will not go green honestly. The single most important gate. Never edit, weaken, skip, xfail, or delete a spec test to reach green. Stop, switch to Lead Product Manager, propose the spec amendment, wait.

Amending a spec because reality taught you something is good work. Amending a spec so your existing code passes is fraud, and the difference is which one you wrote first.

Gate 4 — operator walk-through. A green ledger proves the code does what the tests say. Only the operator judges whether it does what they meant. Never mark a spec complete on a green suite alone.

Stopping vs. continuing when you hit a wall

Hitting a gate does not mean stopping the session. It means stopping that thread.

Do everything the gate does not block, then surface the gate. If Gate 1 blocks the capture spec but the storage seam is signed off, build the storage seam and report the open decision at the end. Returning with “I stopped because I had a question” — when three hours of unblocked work sat available — is the most expensive thing you can do with an unattended run.

Surface every gate you hit in the final response, together, with a recommendation for each. One decision-batch beats four interruptions.

Reporting standard

At the end of any unattended run, report:

  1. What the ledger says — output of spec_status.py, not your recollection
  2. What landed — commits pushed, with their headlines
  3. What is red or missing, plainly. Never round a failure up to a success.
  4. Every gate hit, batched, each with a recommendation
  5. What you did not do and why — especially scope you skipped

If tests fail, say so and show the output. If a step was skipped, say that. When something is done and verified, state it plainly without hedging.

Amending this contract

The agent may propose amendments in a session summary. The agent may not apply them. Changes land only with the operator’s explicit agreement — this document is the boundary of acceptable behaviour, and a boundary that moves itself is not one.

  • [[../loops/Spec-to-Shipped-With-TDD]] — the lifecycle whose gates this enforces
  • [[../plans/Corpora-Builder-MVP-R2-Native-With-Checkpoint-History]] — the plan of record
  • ../../CLAUDE.md (ai-labs) and ../../../CLAUDE.md (root) — the tree-wide rules this sits under, including the HARD STOP relocation protocol
  • The context-vigilance skill, §Experimental tier — what contracts/ is for