clay-borg/workplans/CB-WP-0009-adaptive-gates.md
tegwick f4dccb6f99
Some checks failed
ci / check (push) Failing after 3s
Sync hub IDs for CB-WP-0009; drop the duplicate frontmatter key
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 15:35:10 +02:00

4.9 KiB
Raw Blame History

id kind title status authorized_above_budget state_hub_workstream_id
CB-WP-0009 meta Make control gates experimental: window them, review them, cash them out proposed 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. 98c0af4a-415c-4cf5-92d0-a722eb70cb90

Purpose

ADR-0006 (tier M, survey merged into the ADR from CB-EV-0007 §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

id: CB-WP-0009-T01
status: todo
priority: high
state_hub_task_id: "c6eefacd-5bb9-4640-8356-12e8112bcf11"

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

id: CB-WP-0009-T02
status: todo
priority: high
state_hub_task_id: "0fb6cfaf-9304-481a-a96f-1f0150f4d81d"

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

id: CB-WP-0009-T03
status: todo
priority: medium
state_hub_task_id: "0b1b33ac-8046-4b34-b287-7b32755d964a"

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?

id: CB-WP-0009-T04
status: todo
priority: high
state_hub_task_id: "e06f57fc-147f-4cba-b398-0db6b060381f"

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.1230.362 per-response range, and the meta share this pass itself consumed — reported under the rule it wrote.