Public: anyone can read this; the crew can change it.
The pipeline is the engine: measured stages, one bottleneck, and a 24/7 maintenance crew #7553
commented
Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.
Sign in to join this conversation.
Why
Today a person-run steward (an AI session outside the forge) keeps the pipeline healthy. In one day it: found every contained check re-downloading npm (~30 GiB/day, #7541) by measuring network bytes; found which pull sank a red merge batch by merging each alone; told load-sensitive budget reds from real ones; held rule-breaking pulls with exact fix steps; unstuck pulls (conflicted, rebase loops by a builder who cannot push, closed in-repo pulls); cut releases and verified each under page load with automatic rollback; watched for lulls and forge-down; found a 7 s home page (#7494) from Server-Timing. Those scripts are the spec. The forge should do all of it itself, continuously, and show the result.
What exists (read before building)
src/flow/pipeline.ts:20(ready, building, check-queue, checking, review, approved, landed, live — counts and oldest-waiting only: no history, no throughput, no failure reasons). A second, per-issue model:src/flow/stage.ts:13(issue, pull, check, review, land, live). Two stage lists that disagree; neither has "released" or "verified live".src/web/pages/flow-panel.ts; vitalssrc/flow/vitals.ts:1(shared by home, the autonomy tick and the MCPflowtool,src/http/mcp/tools/flow.ts:6).src/flow/alarms.ts:1— four only: red main, stuck, idle crew, no release. They report; none acts.forge/boards(src/boards/store.ts:2), sources insrc/boards/sources.ts:1, 15 s machine samplersrc/boards/sampler.ts:1.src/core/agents.ts:282(builder | planner | reviewer). The sentinel (src/crew/sentinel.ts:1) files one issue per finding on the autonomy clock (src/crew/autonomy.ts:1374); bug hunters (#5846, closed) insrc/hunt/.src/checks/queue.ts:1(#5994, #4235); budget-only re-runsrc/checks/budget_retry.ts:1(#7354, closed); flake recordsrc/checks/flake.ts:1(check_flake, #6643).src/core/route_timing.ts,src/http/server.ts.Goal
(a) One pipeline model. One canonical definition of the stages — ready, building, checking, reviewing, gating (merge queue), landed, released, verified live — each with throughput, wait time, WIP and failure reasons, read from one place. It is the source of truth for the bottleneck chart, the boards, the home KPIs, the alarms and MCP.
(b) Maintenance workers. A
maintainercrew role. Each worker runs continuously on a schedule or trigger, owns one duty, files or fixes through normal pulls, and is measured on a board.(c) Guardrails (every worker, no exceptions).
Children (in order)
/api/v1/pipeline, MCPpipeline)maintainerrole, duties, budgets, probes)check_flake)Order: 1, then 2, then 3 to 8 in any order (each depends on 2), then 9. Existing issues this builds on instead of duplicating: #5930 alarms, #5846 hunters (closed), #7354 budget re-run (closed), #7138 rule tests (closed), #7006 routing (closed), #7426, #7494, #7541, #7543 to #7546.
Done when
All children landed and live; the steward scripts (tick, unstick, lull watch, release, verify) are no longer needed; and a week of the maintenance board shows each duty finding something real or reporting "nothing to do" with its probe.