The throughput keeper: the forge watches its own landing rate, finds what binds it, and acts #7645

Owner, 2026-11-01: "the forge needs to have a subsystem that monitors throughput and actively works to improve it."

Part of #7553. This is the loop the other maintainers report into: #7556 (flow keeper), #7559 (performance), #7560 (rules), #7639 (red batches). Reason for it: on 2026-11-01 the forge could land 18 to 39 pulls an hour and landed about 1, because of two switches (Flow only with no flow issues; the governor trapped at one builder, #7644) and a stale pile. The alarms were on the whole time, and it took a person to ask. Nothing acted.

The loop, plain code first:

1. Measure: landed per hour against the best the forge has recently sustained, and the share of hours it actually ran.
2. Find the one thing binding right now, from a closed list of causes: a switch or brake, an empty pillar, ready issues with nothing assigned, a stale pile, red checks, capacity, subscription usage. Name it in one sentence.
3. Act where the action is reversible and within what the owner has allowed: lift a brake it can prove is holding work with no flood behind it, re-check, unstick, reassign. Otherwise ask the owner one question with one button.
4. Check the effect after a set time: did landings rise? If not, undo and try the next cause. Record each attempt.

Done when:

• [ ] A forge with ready issues, usage left and landings near zero cannot stay that way for more than 30 minutes without either acting or asking.
• [ ] The cause and the last action show in one line on /pipeline and home, and in the MCP flow report.
• [ ] A cause it cannot act on becomes one filed issue once, not one per tick.
• [ ] It works when the subscription is out: it is deterministic and spends no model tokens to detect, so it can say "usage is the limit, resets at HH:MM".
• [ ] A test replays 2026-11-01 (Flow only on, no flow issues, 55 open) and it names the cause and clears it.
• [ ] Measured over a week: hours running and landed per day are on the scorecard.

Generative judgment stays with the crew: the keeper may hand a run the question "why is this slow?", but detection and safe actions are code.

Taken over by nobody; stopped @scout.

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

From today's CI research: DORA 2025 tracks deployment frequency, lead time, recovery time, change fail rate and rework rate; AI adoption goes with higher throughput and higher instability. Add these to the keeper's measures, plus agent-era ones: revert rate, queue-wait p95, rework per agent, and how long a fix to the gate takes to land. Secondary sources only; check the primary report before citing numbers.

Parked by the crew: the check stayed red through 2 automatic tries (pull #7800 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Owner's conductor: reopened pull #7800. The latest red checks say: check failed: 1 of 4400 tests — "reserved names > every top-level page of the forge is a reserved name" check failed: does not merge into main: src/system/telemetry.ts Please read them and fix what is this pull's own. The owner wants this keeper in so the forge stops depending on one watching session.