ADR-0006 + CB-WP-0009: control gates are experiments

CB-EV-0007 found three defects in how gates are designed rather than in
any one gate: the meta budget cannot see the pass it governs, it blocks
its own repair, and nothing retires any gate.

D1 budgets measure their own window. D2 a soft breach is a signal, and
repairing the instrument that reports a breach is always in budget — a
gate must never block its own remedy, which is the trap CB-RES-0005 §4
named for session shape and that got built anyway two tasks later. D3
every gate declares what would retire it and a date to argue it on. D4
loop work cashes out into something runnable in the pass that invents
it, from the measured finding that cost per response tracks distance
from a runnable check. D5 the tier table finally covers changes to the
loop's own operation — CB-RES-0005 §6 said a second instance should
trigger it, and this ADR is the second.

The workplan is meta and above the budget line on recorded maintainer
authorization, which is D2's first use.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/CB-WP-0009-adaptive-gates.md

@@ -0,0 +1,125 @@
+---
+id: CB-WP-0009
+kind: meta
+title: "Make control gates experimental: window them, review them, cash them out"
+status: proposed
+authorized_above_budget: "maintainer, 2026-08-01 — 'improve our policies where it seems promising; we will experiment our way to sensible task- and context-specific control and review gates'. Meta read 59% at the time."
+state_hub_workstream_id: ""
+---
+
+# Purpose
+
+[ADR-0006](../decisions/ADR-0006-adaptive-control-gates.md) (tier M,
+survey merged into the ADR from [CB-EV-0007](../evidence/CB-EV-0007-stage-0.md)
+§3 and §5; chaos d4=3, no override, declaration 4 of 12).
+
+Six passes produced five control mechanisms and no way to retire any of
+them. CB-EV-0007 found three defects in how gates are *designed*:
+
+1. the meta budget cannot see the pass it governs — the same cumulative
+   defect CB-WP-0007 T01 had just fixed for session shape, reintroduced
+   two tasks later by the same hand;
+2. it blocks its own repair, which is the trap CB-RES-0005 §4 named and
+   rejected for session shape and then got built anyway;
+3. nothing retires a gate.
+
+This pass is **`kind: meta` and above the budget line**, on explicit
+maintainer authorization recorded in the frontmatter — the first use of
+ADR-0006 D2, and a deliberate exercise of it.
+
+Per **D4**, every task here ships something runnable. A task that ends in
+prose has not delivered.
+
+## Task: the meta budget measures the pass it governs
+
+```task
+id: CB-WP-0009-T01
+status: todo
+priority: high
+state_hub_task_id: ""
+```
+
+ADR-0006 **D1**. `make status` reports the meta share **for the current
+pass** — the window since the active workplan's first commit — and keeps
+the cumulative figure labelled *history*, exactly as `cb-cost`'s session
+shape block does since CB-WP-0007 T01.
+
+The instrument-repair exemption (**D2**) is what makes this task legal to
+open at 59%, so the task must also *state* the exemption where the budget
+prints, or the next reader will re-derive the same standoff.
+
+**Predicted:** the windowed share for CB-WP-0008 reads at or near 0% —
+it was a pure product pass — against 61% cumulative.
+**Refuted if** the two land within 20% of each other, in which case D1 is
+wrong and the machinery should be deleted rather than kept.
+
+## Task: `gates.toml` and `make gate-review`
+
+```task
+id: CB-WP-0009-T02
+status: todo
+priority: high
+state_hub_task_id: ""
+```
+
+ADR-0006 **D3**. A registry of every standing control gate: what it
+checks, what it has caught (with pointers), `review_by`, and **what would
+retire it**. `make gate-review` reports what is overdue and what has
+caught nothing.
+
+Seed it with the mechanisms that exist today — the cost budget, the
+shape budget, mutation coverage, the DFD fact gate, the meta budget, the
+chaos roll, the kernel spec→code gate, and `gate-review` itself, which is
+not exempt from its own rule.
+
+**The positive control this needs:** a registry that silently drifts
+behind the Makefile is worse than none, so `loop-lint` gains a check that
+every gate target has an entry and every entry names a real target. Its
+own self-test must fail when an entry is removed.
+
+## Task: InnerLoop v1.6
+
+```task
+id: CB-WP-0009-T03
+status: todo
+priority: medium
+state_hub_task_id: ""
+```
+
+Fold **D2**, **D4** and **D5** into `specs/InnerLoop.md`:
+
+- the breach-is-a-signal wording and the two exemptions (instrument
+  repair; recorded maintainer authorization);
+- the cash-out rule, with its refutation condition;
+- the tier trigger for changes to the loop's own operation, closing the
+  gap CB-RES-0005 §6 opened and this ADR's own tier declaration used.
+
+`InnerLoop.md` is at its 400-line loadability limit, so this task
+**displaces** as much as it adds: the chaos-roll rationale and the v1.1
+→ v1.4 change log move to `InnerLoopReference.md`, leaving the rule and a
+pointer. Loadability is itself a gate; growing the file to fit a rule
+about gates would be the joke writing itself.
+
+## Task: control loop — did the changes fire?
+
+```task
+id: CB-WP-0009-T04
+status: todo
+priority: high
+state_hub_task_id: ""
+```
+
+Commit `evidence/CB-EV-0008-adaptive-gates.md`. Four questions, all
+answered from output, not argument:
+
+1. **Does the windowed meta share differ from cumulative?** Against
+   T01's prediction; refuted within 20%.
+2. **What does `gate-review` say on its first run?** A registry where
+   every gate is current and every gate has caught something is a
+   registry that was written to look good — say which entries are
+   uncomfortable.
+3. **Did D4 hold for this pass?** Three of four tasks here ship a
+   command; T03 is prose. State whether the rule survives its own first
+   pass or needs the exception written down.
+4. **Cost**, against the 0.123–0.362 per-response range, and the meta
+   share this pass itself consumed — reported under the rule it wrote.