The process around the code is the bottleneck now.

Stage 1 — Plan

Ideas stop waiting for someone to write them up. Intent is captured once, in the originator's own words, as a version-controlled artifact the next stage can act on.

• Contents. Problem, desired outcome, affected users and systems, constraints, success criteria, open questions.
• Gate. The product owner sets Status: accepted. The accepting commit is the record — and it must not be the author's own.
• Evidence. The committed file, with author, timestamp and full revision history.
• Measure. Leading: hours from first conversation to a committed intent. Lagging: the share of intents accepted into Design rather than closed.

Stage 2 — Design

Requirements and design collapse into one session. Policy is applied while the spec is written, not discovered in a review weeks later.

• Flagged concerns first. These are the points an analyst would have escalated. Each names a policy owner and is resolved with them before engineering sees the spec.
• Gate. The owner sets Status: signed-off, consulting a technical lead for anything classed as higher risk.
• Evidence. The spec, the prompt that produced it, and the skill versions in force — all in version control.
• Measure. Leading: elapsed time between the intent and spec commits. Lagging: spec commits dated after the first plan commit, which is requirements rework.

Stage 3 — Build

Nothing is implemented without an accepted plan. Institutional knowledge becomes files the agent reads, and guardrails run as code rather than as habits.

• The plan names the files that change, the order of work, the risks and the tests that prove it — detailed enough that an engineer who never saw the conversation could implement it.
• Record rejected approaches and why, so a later session does not re-walk them.
• Gate. Status: accepted before any file is edited. If implementation departs from the plan, update the plan in the same commit.
• Binding. An acceptance is recorded for a base commit. Bind it to the merge base — the fork point the approval was granted at — not the branch tip, which moves after the branch is cut.
• Coverage. Every source file the change touches must be named in the plan; the gate refuses a diff that touches a file the active plan does not mention.

Stage 4 — Test

Every session checks its own work before a human sees it, and the configuration that steers the agent gets regression-tested like the code it writes.

• Write the target first, watch it fail. A test that has only ever been seen green is not evidence.
• For a bug fix, commit the failing test first, then make it pass without editing the test. A test the agent could not rewrite is proof the bug is gone.
• Protect the loop. An agent fixing code must not be able to weaken the check on that code — block edits to test files during a fix, or reject such a diff in review.
• Evals are the stage gate that keeps up. Run them on any change to the agent's own configuration — instructions, skills, hooks — and on a schedule. Every production incident becomes a permanent eval case.
• Prove a test can fail. Mutate the implementation and confirm the suite goes red. A surviving mutation is an untested behaviour, not a pass.

Stage 5 — Deploy

Review runs in both directions, and governance is enforced as the agent acts. The agent may do everything up to the production gate and nothing past it.

• REVIEW.md defines the passes — bugs, security, then compliance against spec.md and plan.md — plus what counts as Important versus a Nit, a nit cap, and what to skip.
• Separation of duties. The agent that wrote the code has no route to approve it. A human code owner still merges.
• Close the intent on merge. Set Status: shipped. This is not bookkeeping: a still-accepted chain keeps authorising later unrelated edits to every file its plan named. Never reset a shipped chain to keep working under it — start a new intent.
• Hooks as approval gates. A hook can allow, block, or ask. A block should explain itself and name the route to approval.
• Measure. Leading: time to first review, and comments resolved without a human touching the branch. Lagging: defects caught before merge versus those escaping to production.

Stage 6 — Maintain

The loop closes. A trigger invokes the agent with no person in the invocation path, and what it finds re-enters the pipeline as intent.md.

• Detection stays deterministic. A version-controlled, unit-tested script watches the metric. The model is never in the detection path.
• Tier by deviation. 1σ log · 2σ diagnose read-only · 3σ act, but only by opening a pull request into the review gate or running a pre-approved runbook.
• Rollback is the most rehearsed path in the pipeline, exercised regularly in staging, because the 3σ tier may call it.
• Dismissals tune the bands and are recorded, so noise falls over time.
• Measure. Leading: time from band breach to an intent in the triage queue. Lagging: the share of findings that become merged fixes, and repeat incidents of the same class.

# bands.yaml — monitoring the CI test failure rate
metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose, tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose, routes: [pull_request, runbook:rollback-deploy] }