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

open not picked up yet opened this
opened this

"great. glad we caught that. those are the kind of things that i need the forge to do on its own. this is going to help CI and our pipeline as a whole. the forge really needs to have a clear pipeline for us to work with and measure. i like the bottleneck chart and the boards. leaning into that and making it a real part of the engine with 24/7 crew maintenence workers would be awesome" — owner, 2026-10-27

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)

  • Pipeline snapshot: 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".
  • Bottleneck chart and panel: src/web/pages/flow-panel.ts; vitals src/flow/vitals.ts:1 (shared by home, the autonomy tick and the MCP flow tool, src/http/mcp/tools/flow.ts:6).
  • Alarms (#5930): src/flow/alarms.ts:1 — four only: red main, stuck, idle crew, no release. They report; none acts.
  • Boards: JSON files in forge/boards (src/boards/store.ts:2), sources in src/boards/sources.ts:1, 15 s machine sampler src/boards/sampler.ts:1.
  • Crew roles: 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) in src/hunt/.
  • Merge queue and bisection: src/checks/queue.ts:1 (#5994, #4235); budget-only re-run src/checks/budget_retry.ts:1 (#7354, closed); flake record src/checks/flake.ts:1 (check_flake, #6643).
  • Server-Timing: 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 maintainer crew 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).

  • Never land through the API and never push to main; fixes are pulls that go through the gate like anyone's.
  • Canary before any bulk action: act on one item, probe the effect, then continue.
  • Every claim is backed by a probe, and the probe and its result are recorded on the issue or pull (what was measured, the number, when).
  • Act, do not stack issues: a finding that still stands is one comment on one issue, not a new one.
  • A worker has a budget and a pause switch; an owner can pause any duty from the board.
  • No secrets in logs, argv or comments.

Children (in order)

  1. #7562 One pipeline model (stages, events, /api/v1/pipeline, MCP pipeline)
  2. #7554 Maintenance framework (maintainer role, duties, budgets, probes)
  3. #7555 Batch doctor (port of the steward tick: red batches)
  4. #7556 Flow keeper (port of unstick, lull-watch, alarms.js)
  5. #7557 Release keeper (port of release, verify-after, verify-release)
  6. #7558 Efficiency watcher (would have caught #7541; uses #7546)
  7. #7559 Performance watcher (would have caught #7494)
  8. #7560 Rule watcher (#7138, #7354, #7426, check_flake)
  9. #7561 Maintenance board (forge/boards + home tile)

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.

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.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs