One path a person can follow: check, review, land, live #7793

Every pull now shows which of the four steps it is at (check, review, land, live) and one sentence on why it is waiting there. A new public page, /pipeline, explains the four steps to a newcomer. This covers the person-facing part of #7703. The suite and shard work is filed as child issues #7779–#7784, and #7703 now waits on them.

• Where a pull is (src/flow/path.ts): the step is the earliest one the pull has not passed yet.

- Check while a check on its head is queued, running, red or cancelled. If no check was ever recorded, it does not wait at check. - Review until someone approves this head. - Land once it is approved and green. - Live once merged into an app's default branch. It is marked done when production has deployed since the merge. A merge where nothing deploys stops at land, marked done. - For an open pull the sentence comes from the existing "who acts next" logic, so the two lines under the title cannot disagree.

• Pull page: under the title, on both the Conversation and Files tabs, a line like Check · Review · Land · Live — No review yet. with the current step marked and linked to /pipeline. Merged pulls get the line too. The existing Next: line is unchanged. No new CSS classes.
• MCP: pull also answers step: { step, why, done }. test/mcp-size.test.ts passes without raising any ceiling.
• /pipeline: the four steps in order. Each says what it waits for and what only it catches, and its finer parts sit one click down in a <details>. The name pipeline is reserved so no user can take it, the page is added to looks in forge.json, and the Boards Pipeline panel links to it.
• Docs: docs/features/pipeline.md.

Left for the child issues:

• #7779: remove the proof step.
• #7780: run the full suite as a scheduled report that files issues and never blocks.
• #7781: re-run a shard alone once when it crashed outside any test.
• #7782: reuse a green check result for the same tree instead of rerunning it.
• #7783: show the step in the feed, the pulls lists, /review and the terminal.
• #7784: measure each step's time and red rate and post the map in #7703. I can't read the forge's run data from here.

The page still lists the proof under land and says it is being removed (#7779), so it stays accurate until then. One mistake to look at: my first test request created a placeholder issue, #7779, and I overwrote its title and body with the proof-removal issue.

To try it: open /pipeline, then any open pull. The line under the title links back to /pipeline. test/pipeline-path.test.ts covers the step rules, the page, both pull tabs, a merged pull and the MCP answer. That file and the related existing tests (pull page, studio changes, reserved names, looks, MCP size) pass, and tsc and the design lint are clean.

🤖 Generated with Claude Code

Closes #7703

Every pull now shows which of the four steps it is at (check, review, land, live) and one sentence on why it is waiting there. A new public page, /pipeline, explains the four steps to a newcomer. This covers the person-facing part of #7703. The suite and shard work is filed as child issues #7779–#7784, and #7703 now waits on them.

• Where a pull is (src/flow/path.ts): the step is the earliest one the pull has not passed yet.

- Check while a check on its head is queued, running, red or cancelled. If no check was ever recorded, it does not wait at check. - Review until someone approves this head. - Land once it is approved and green. - Live once merged into an app's default branch. It is marked done when production has deployed since the merge. A merge where nothing deploys stops at land, marked done. - For an open pull the sentence comes from the existing "who acts next" logic, so the two lines under the title cannot disagree.

• Pull page: under the title, on both the Conversation and Files tabs, a line like Check · Review · Land · Live — No review yet. with the current step marked and linked to /pipeline. Merged pulls get the line too. The existing Next: line is unchanged. No new CSS classes.
• MCP: pull also answers step: { step, why, done }. test/mcp-size.test.ts passes without raising any ceiling.
• /pipeline: the four steps in order. Each says what it waits for and what only it catches, and its finer parts sit one click down in a <details>. The name pipeline is reserved so no user can take it, the page is added to looks in forge.json, and the Boards Pipeline panel links to it.
• Docs: docs/features/pipeline.md.

Left for the child issues:

• #7779: remove the proof step.
• #7780: run the full suite as a scheduled report that files issues and never blocks.
• #7781: re-run a shard alone once when it crashed outside any test.
• #7782: reuse a green check result for the same tree instead of rerunning it.
• #7783: show the step in the feed, the pulls lists, /review and the terminal.
• #7784: measure each step's time and red rate and post the map in #7703. I can't read the forge's run data from here.

The page still lists the proof under land and says it is being removed (#7779), so it stays accurate until then. One mistake to look at: my first test request created a placeholder issue, #7779, and I overwrote its title and body with the proof-removal issue.

To try it: open /pipeline, then any open pull. The line under the title links back to /pipeline. test/pipeline-path.test.ts covers the step rules, the page, both pull tabs, a merged pull and the MCP answer. That file and the related existing tests (pull page, studio changes, reserved names, looks, MCP size) pass, and tsc and the design lint are clean.

🤖 Generated with Claude Code

I regenerated the stale MCP tool table in docs/MCP.md with bun scripts/mcp-tools.ts. That was the only change, and it's pushed as ca6d0e2f.

The one test that failed on the forge's check, "docs/MCP.md's tool table is current", now passes. The 168 tests in its file pass locally. I did not re-run the rest of the suite here, and I did not run bun x tsc --noEmit or scripts/gate.ts (the change is a generated doc). A broader scripts/fast.ts run hit the 120 s timeout, and I didn't wait for it to finish. The forge runs the full check on this push.

Nothing else in the pull changed. The pipeline work from #7703 (the four words check, review, land and live, and the /pipeline page) is as before. To try the fix, run bun test on the file with the tool-table test. It should be green.

I merged main into the branch and pushed it. The only conflict was the looks list in forge.json.

• The conflict: main added /feed and my branch added /pipeline. I kept both and left the rest of the list in main's order.
• Checks: bun x tsc --noEmit is clean after bun install. A first run had failed on happy-dom because node_modules was stale. I also ran the pull-pipeline, looks, reserved-names, pull-pipe, MCP tools/docs and flow-pipeline tests: 247 pass and 3 fail.
• Failures: the 3 failures are the real-chromium capture tests in test/looks.test.ts, which need /usr/bin/chromium and this sandbox doesn't have it. The forge's check will run them.
• Not run:

- bun scripts/gate.ts printed nothing I could read. - scripts/fast.ts reported the diff as too broad to name tests, and I ran a hand-picked set instead. - I didn't run the full suite.

To try it, open /pipeline on the preview and check that /feed still answers.

Parked by the crew: the check stayed red through 2 automatic tries

I fixed two of the six failing tests and pushed the fix. The other four pass when I run them here, so I changed nothing for them.

• Design audit: /pipeline is a new top-level page with no entry in docs/design/audit.md. I added one.
• Server-Timing sweep: /pipeline answered with app alone. It now records session and render phases, as the other pages do (src/web/pages/pipeline.ts).
• Not reproduced: I ran these four on their own and they pass.

- forge help vs docs/CLI.md headings - the subscriptions-screen cursor test - the canonical-address test - the MCP map / wait_for test

I think the check hit them under load or against a stale base, but I haven't confirmed that. If any of them fail again on this push, the log will say why.

Checks run before the push:

• bun test on the audit, sweep and pipeline-path tests passes.
• bun x tsc --noEmit is clean.
• bun scripts/design-lint.ts is clean.

I didn't run scripts/gate.ts or the full suite. The forge runs the full suite on the push.

I pushed the follow-up as a89f68cc. I couldn't read the written review itself (the reviews endpoint returned nothing), so I worked from the uncommitted changes I'd already made on this branch. If your feedback asked for something else, say so.

What changed

• /pipeline: each step is now a row() that folds to its finer parts, so it uses the existing component and no new CSS class. The copy now says an admin sees the per-step counts on Boards.
• Pull page: a finished path shows a "done" badge in place of the "✓" marks.
• Reading who acts next: stepOfPull takes the next that changeHead already computed, so the page reads it once.
• Terminal: the pull screen's header now shows step: review beside next:.
• Tests: a new test covers a merged pull into an app. It is "landed" until a production deploy that is serving has run since the merge, then "live". Deploys from before the merge, still booting, or on a preview don't count. test/pull-next-tui.test.ts also checks the terminal's step text.
• Docs: README, docs/features/pipeline.md and docs/design/areas/lists.md are updated.

Checks run

• bun x tsc --noEmit and bun scripts/design-lint.ts are clean.
• test/pipeline-path.test.ts and test/pull-next-tui.test.ts pass (13 tests).
• bun scripts/gate.ts printed nothing, so I can't confirm it passed.
• I did not run the full suite; the forge's check runs it on this push.

Left for later: the step in the feed, the pulls lists and /review is still #7783. The proof step stays on the page under land until #7779 removes it.

To try it, open /pipeline on the preview, then any pull. The line under the title links back to it.

🤖 Generated with Claude Code

I couldn't find a cause in this pull's code for the shard 14 failure, so I pushed a merge of main and nothing else.

• What failed: shard 14 was killed after 41 s, and the log names test/verify-timing.test.ts. The other 74 shards passed, and the run reported 0 tests failed.
• Why I think it's a stall: test/verify-timing.test.ts passes here in about 2 s (4 of 4). It has no connection to the /pipeline or pull-step changes, and I didn't touch it.
• What I pushed (63f7cb33): I merged origin/main into the branch, which should also change which tests land in which shard.
• Checks before the push: bun x tsc --noEmit is clean, and test/pipeline-path.test.ts plus test/verify-timing.test.ts pass (16 tests).

If shard 14 is killed again on this push, the cause is in the check runner or the machine's load, not in this pull. The log of that run will say which test it was stuck on.