/flow lists the pulls closed unmerged because a check was stopped for CPU, so a person can re-queue them #11908

/flow now lists the pulls that were closed without merging after a check was stopped for CPU, so the steward can queue them again. The flow tool returns the same rows when called with { kind: cpu }.

What changed

• src/flow/cpu_closed.ts (new): cpuClosedPulls(db, now, { cap?, publicOnly? }) returns pulls that are closed, not merged, and whose last check was a CPU stop that ended in the last 7 days. The list is newest close first and capped at 20.

- "Last check" ignores the retry that the close itself cancelled (summary pull closed / pull landed). Without that, every stopped-then-closed pull would end on that cancelled retry instead of the CPU stop. - It is one query. It starts from checks finished in the window, using the run_kind_finished index, rather than scanning closed issues.

• src/flow/cpu_stops.ts: the test for "was this check stopped for CPU" now lives in one exported function, isCpuStop. It counts both a stop that was queued again (CPU_STOP_SUMMARY) and a second stop that was reported red. The hour's count and the new list both use it, and the count's behaviour is unchanged.
• src/web/pages/flow-cpu.ts (new) and src/web/pages/flow.ts: below the clog block, admins see one paragraph: the hour's CPU-stop count, then the pulls as links. Nothing is drawn when both are empty.
• src/http/mcp/tools/flow.ts: a new cpu value for the existing kind argument returns { stopped, closed: [{ repo, number, closedAt }] }, with no new tool. As with kind: bugs, an admin sees every repository and anyone else sees public ones; stopped is reported to admins only.
• test/flow-cpu-closed.test.ts (new): seeds five closed pulls:

- stopped for CPU, then closed; - stopped for CPU, then merged; - red for its own reason, then closed; - stopped, then red for its own reason; - stopped twice, reported red, then closed, in a private repository.

Only the first and last are listed. The test also covers the public-only view, the cap, the clock in both directions, the /flow block's links and empty state, and the MCP rows per viewer. It fails without cpu_closed.ts.

Not done

• /flow is not in src/perf/page_budget.ts, so there was no statement budget to update; the block adds two bounded queries to the page.
• The list carries no re-queue button; the links lead to each pull.

Checks run: bun scripts/gate.ts, bun x tsc --noEmit, bun test test/mcp-size.test.ts and bun scripts/design-lint.ts pass. The flow, MCP-flow and CPU-stop test files ran 85 pass, 0 fail. scripts/fast.ts named 1755 files for this diff, so I picked those covering test files myself instead of running the whole suite.

The plan was not kept on the issue: keep_plan could not be reached from this sandbox (POST $FORGE_URL/mcp answered 404).

To try it: as an admin, open /flow after a pull whose check was stopped for CPU has been closed unmerged, or call the flow tool with { kind: "cpu" }.

🤖 Generated with Claude Code

Closes #11904

/flow now lists the pulls that were closed without merging after a check was stopped for CPU, so the steward can queue them again. The flow tool returns the same rows when called with { kind: cpu }.

What changed

• src/flow/cpu_closed.ts (new): cpuClosedPulls(db, now, { cap?, publicOnly? }) returns pulls that are closed, not merged, and whose last check was a CPU stop that ended in the last 7 days. The list is newest close first and capped at 20.

- "Last check" ignores the retry that the close itself cancelled (summary pull closed / pull landed). Without that, every stopped-then-closed pull would end on that cancelled retry instead of the CPU stop. - It is one query. It starts from checks finished in the window, using the run_kind_finished index, rather than scanning closed issues.

• src/flow/cpu_stops.ts: the test for "was this check stopped for CPU" now lives in one exported function, isCpuStop. It counts both a stop that was queued again (CPU_STOP_SUMMARY) and a second stop that was reported red. The hour's count and the new list both use it, and the count's behaviour is unchanged.
• src/web/pages/flow-cpu.ts (new) and src/web/pages/flow.ts: below the clog block, admins see one paragraph: the hour's CPU-stop count, then the pulls as links. Nothing is drawn when both are empty.
• src/http/mcp/tools/flow.ts: a new cpu value for the existing kind argument returns { stopped, closed: [{ repo, number, closedAt }] }, with no new tool. As with kind: bugs, an admin sees every repository and anyone else sees public ones; stopped is reported to admins only.
• test/flow-cpu-closed.test.ts (new): seeds five closed pulls:

- stopped for CPU, then closed; - stopped for CPU, then merged; - red for its own reason, then closed; - stopped, then red for its own reason; - stopped twice, reported red, then closed, in a private repository.

Only the first and last are listed. The test also covers the public-only view, the cap, the clock in both directions, the /flow block's links and empty state, and the MCP rows per viewer. It fails without cpu_closed.ts.

Not done

• /flow is not in src/perf/page_budget.ts, so there was no statement budget to update; the block adds two bounded queries to the page.
• The list carries no re-queue button; the links lead to each pull.

Checks run: bun scripts/gate.ts, bun x tsc --noEmit, bun test test/mcp-size.test.ts and bun scripts/design-lint.ts pass. The flow, MCP-flow and CPU-stop test files ran 85 pass, 0 fail. scripts/fast.ts named 1755 files for this diff, so I picked those covering test files myself instead of running the whole suite.

The plan was not kept on the issue: keep_plan could not be reached from this sandbox (POST $FORGE_URL/mcp answered 404).

To try it: as an admin, open /flow after a pull whose check was stopped for CPU has been closed unmerged, or call the flow tool with { kind: "cpu" }.

🤖 Generated with Claude Code