/flow: the forge shows its own bottleneck — every stage from ready to live with its queue, wait and capacity, the knob beside it, machine use, and 24 h throughput #1554

Owner, 2026-10-15 14:40Z, in his words: "where is our bottleneck!?!?! I need to be able to see that so I can alter these things. I'm tired of talking to you and waiting forever. I want the controls and the tools to explore for myself right in the forge!!!"

Today the only way to know what limits throughput is to ask the steward, who reads pod processes, logs and five APIs. The answer tonight was a chain of six limits nobody could see: builder slots 1, crew runs 4, checks at once 3, one shard per check (pinned in forge.json), a 4-CPU check cell, a 16-CPU pod — the vxrail sat at 5% of 80 cores. All six are now raised; the owner must be able to find the next one himself in seconds.

Done looks like — one page, /flow (linked first in the header for an admin):

• [ ] The pipeline as stages, left to right, each with what is in it now, its capacity and how long the oldest item has waited: ready issues → building (slots) → check queue → checking (checks at once × shards) → review queue → reviewing → approved → landed → released → live. The stage whose wait is longest is drawn as the bottleneck, with the one sentence that says why ("12 pulls wait for a builder; slots = 1").
• [ ] Each stage's knob next to it, editable in place for an admin: autonomy slots and ceiling, crew.concurrency, checks.concurrency, checks.shards, check cell cpus/memory (from forge.json, read-only with a link to edit), children.max. A change says what it changed and is undoable (the capacity page's behavior, moved here).
• [ ] Machine use beside the knobs: the node's CPU and memory (live, from the pod's cgroup and the node), so "raise it" is visibly safe or not.
• [ ] Throughput over time: per hour, items in and out of each stage for the last 24 h, and the median ask→live; the ledger (#1386) feeds dollars when it lands.
• [ ] Drill down: every count is a link to the list it counts (the 12 pulls waiting for a builder, the 51 queued checks with their age), never a dead number.
• [ ] Served from data the forge already has (runs, pulls, reviews, capacity, autonomy); no new dependency; a test renders the page from a seeded forge and finds the bottleneck sentence.

This is the top of the map. Files: src/web/pages/flow.ts (new), src/core/capacity.ts, src/crew/autonomy.ts (numbers), src/web/layout.ts (header link), test/flow.test.ts.

Parked by the crew: the check failed ("report mode is loud to admins, and to nobody else > reported: the Capacity page says it once, as a note; vitals do not") and the decider saw no point in another try (pull #1570 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Owner, 2026-10-15 18:05Z: "where is my bottleneck now, where is my visualization in the forge?" Probed: GET /flow and GET /boards both answer 404 on 0.7.110. Boards so far is the query API only (#1671, #1680). Mason: build the /flow page now as the next pull, smallest visible slice first — the stages as rows (ready, building, check queue, checking, review, approved, landed, live) with the count, the oldest wait and the capacity per stage, and one sentence naming the stage with the longest wait. Knobs, history and drill-down come in later pulls. Planner: the first visible /boards page (one line chart over runs per hour from the query API) is the next slice of #1557; open it now.

Owner, 2026-10-15 19:40Z: "I'm liking the flow table. actual throughput would be nice." Next slice of /flow, Mason, as one pull: per stage, items OUT per hour over the last 24 h (issues started, pulls opened, checks finished, reviews returned, landed, released, live) as a number with a small sparkline beside it; the page headline gains "landed N in the last hour · median ask→live X h (24 h)". From the data the forge already has (runs, pulls, releases); no new table needed. Test: a seeded forge with landings spread over three hours shows the right counts per hour.