P0: the merge queue records and names the tests that failed each gate (not just the count), with a gates API, so a red batch can be acted on #6741

Every finished merge-queue gate is now stored with the tests that failed in it. The queue log names them, and GET /api/v1/repos/:o/:n/queue/gates?limit=20 and a new queue_gates MCP tool return them.

Why "2 failed" probably meant one test. At the end of a run, scripts/test-shards.ts prints every failure again, as (fail) name [1ms] [shard 3]. failuresOf didn't strip the [shard N] part, so it counted each failure twice. Both parsers now use one pattern and count each test once.

What changed

• Reading the output: src/checks/gate_tests.ts reads a gate's output for:

- how many tests passed, summed across shards; - how many distinct tests failed; - up to 20 failing tests, each with its file and its first 5 error lines.

landing.ts carries this on the red verdict, and queue_store.ts keeps it when a gate's verdict is picked up again after a restart.

• Storage: a new migration adds a gate_result table, written by src/checks/gate_result.ts. Every gate that finishes gets a row, green, red or cut_off: whole batches, the smaller gates run to find the culprit, and pulls gated alone. Each row holds the pulls, the reason, the counts, the failing tests and the duration. Rows older than 7 days are deleted whenever a new one is written.
• Log line: a red now reads gated 8 pulls: red (2 failed: "a > b", "c > d"). It names up to 5 tests and adds and N more past that. A red that named no test reads as before.
• API:

- It returns { items, next_cursor }, newest first. - limit is 1–100 and cursor is a gate id. - A malformed cursor gets a 422, and a repository you can't read gets a 404. - It names its session, gates and render timing phases. Leaving these out is what failed the check on #6740.

• Flaky flag: each failing test in the answer carries flaky: true when the same file and test failed in two red gates that share no pull. Only the last 500 red gates of the kept week are compared.

Not done

• A flaky red is still searched and bisected; the flag doesn't change what the queue does.
• The log line doesn't mark tests as flaky.
• No web page reads the table yet.
• #6643, which the issue points to for a flake list, is a pull that raises a migrate test's timeout. Main has no flake list, so the flaky flag is built on gate_result itself rather than on an existing list.

Tests

• test/merge-queue-gate-result.test.ts is new. A fake two-shard output with two failing tests gives both names once, with their files, error lines and counts. It also covers the 20-test cap, the log wording and the flaky rule.
• End to end, it runs sweepGreen against a fake check lane. The log line names both tests, and the API and MCP tool return both, with failed equal to the number named. It also checks paging, the 404, the 422, the flaky flag and the 7-day pruning.
• test/mcp.test.ts lists every MCP tool by name, so queue_gates was added to that list. The test wasn't wrong.
• The type check is clean. The new test, the route-timing, MCP, merge-queue, schema and list-shape suites, and the five cross files all pass.

To try it: bun test test/merge-queue-gate-result.test.ts. On the preview, once a gate has run: curl -H "authorization: Bearer $TOKEN" "$URL/api/v1/repos/trevato/forge/queue/gates?limit=5".

🤖 Generated with Claude Code

Closes #6739

Every finished merge-queue gate is now stored with the tests that failed in it. The queue log names them, and GET /api/v1/repos/:o/:n/queue/gates?limit=20 and a new queue_gates MCP tool return them.

Why "2 failed" probably meant one test. At the end of a run, scripts/test-shards.ts prints every failure again, as (fail) name [1ms] [shard 3]. failuresOf didn't strip the [shard N] part, so it counted each failure twice. Both parsers now use one pattern and count each test once.

What changed

• Reading the output: src/checks/gate_tests.ts reads a gate's output for:

- how many tests passed, summed across shards; - how many distinct tests failed; - up to 20 failing tests, each with its file and its first 5 error lines.

landing.ts carries this on the red verdict, and queue_store.ts keeps it when a gate's verdict is picked up again after a restart.

• Storage: a new migration adds a gate_result table, written by src/checks/gate_result.ts. Every gate that finishes gets a row, green, red or cut_off: whole batches, the smaller gates run to find the culprit, and pulls gated alone. Each row holds the pulls, the reason, the counts, the failing tests and the duration. Rows older than 7 days are deleted whenever a new one is written.
• Log line: a red now reads gated 8 pulls: red (2 failed: "a > b", "c > d"). It names up to 5 tests and adds and N more past that. A red that named no test reads as before.
• API:

- It returns { items, next_cursor }, newest first. - limit is 1–100 and cursor is a gate id. - A malformed cursor gets a 422, and a repository you can't read gets a 404. - It names its session, gates and render timing phases. Leaving these out is what failed the check on #6740.

• Flaky flag: each failing test in the answer carries flaky: true when the same file and test failed in two red gates that share no pull. Only the last 500 red gates of the kept week are compared.

Not done

• A flaky red is still searched and bisected; the flag doesn't change what the queue does.
• The log line doesn't mark tests as flaky.
• No web page reads the table yet.
• #6643, which the issue points to for a flake list, is a pull that raises a migrate test's timeout. Main has no flake list, so the flaky flag is built on gate_result itself rather than on an existing list.

Tests

• test/merge-queue-gate-result.test.ts is new. A fake two-shard output with two failing tests gives both names once, with their files, error lines and counts. It also covers the 20-test cap, the log wording and the flaky rule.
• End to end, it runs sweepGreen against a fake check lane. The log line names both tests, and the API and MCP tool return both, with failed equal to the number named. It also checks paging, the 404, the 422, the flaky flag and the 7-day pruning.
• test/mcp.test.ts lists every MCP tool by name, so queue_gates was added to that list. The test wasn't wrong.
• The type check is clean. The new test, the route-timing, MCP, merge-queue, schema and list-shape suites, and the five cross files all pass.

To try it: bun test test/merge-queue-gate-result.test.ts. On the preview, once a gate has run: curl -H "authorization: Bearer $TOKEN" "$URL/api/v1/repos/trevato/forge/queue/gates?limit=5".

🤖 Generated with Claude Code

Every merge-queue gate that finishes is now stored with the names of the tests that failed in it. The queue log line names them too. GET /api/v1/repos/:o/:n/queue/gates?limit=20 and a new queue_gates MCP tool return them.

Why "2 failed" probably meant one test. At the end of a run, scripts/test-shards.ts prints every failure a second time, as (fail) name [1ms] [shard 3]. failuresOf didn't strip the [shard N] part, so it counted each failure twice. Both parsers now share one pattern and count each test once.

What changed

• Reading the output: src/checks/gate_tests.ts reads a gate's output for:

- how many tests passed, added up across shards; - how many different tests failed; - up to 20 failing tests, each with its file and its first 5 error lines.

landing.ts carries this on the red verdict. queue_store.ts keeps it when a gate's verdict is picked up again after a restart.

• Storage: a new migration adds a gate_result table, written by src/checks/gate_result.ts. Every finished gate gets a row, whether green, red or cut_off. That covers whole batches, the smaller gates run to find the culprit, and pulls gated alone. A row holds the pulls, the reason, the counts, the failing tests and the duration. Each time a row is written, rows older than 7 days are deleted.
• Log line: a red now reads gated 8 pulls: red (2 failed: "a > b", "c > d"). It names up to 5 tests, then adds and N more. A red that named no test reads as before.
• API:

- The answer is { items, next_cursor }, newest first. - limit is 1–100 and cursor is a gate id. - A malformed cursor gets a 422. A repository you can't read gets a 404. - The route names its session, gates and render timing phases. Leaving these out is what failed the check on #6740.

• Flaky flag: a failing test in the answer carries flaky: true when the same test in the same file failed in two red gates that share no pull. Only the last 500 red gates of the kept week are compared.

Not done

• A flaky red is still searched and bisected the same way; the flag doesn't change what the queue does.
• The log line doesn't mark which tests are flaky.
• No web page reads the table yet.
• The issue points to #6643 for a flake list, but #6643 is a pull that raises a migrate test's timeout, and main has no flake list. So the flaky flag reads gate_result directly instead of an existing list.

Tests

• test/merge-queue-gate-result.test.ts is new. It feeds in a fake two-shard output with two failing tests and gets both names once, with their files, error lines and counts. It also covers the 20-test cap, the log wording and the flaky rule.
• End to end, it runs sweepGreen against a fake check lane. The log line names both tests. The API and the MCP tool return both, with failed equal to the number of tests named. It also checks paging, the 404, the 422, the flaky flag and the 7-day pruning.
• test/mcp.test.ts lists every MCP tool by name, so queue_gates was added to that list. The test itself wasn't wrong.
• The forge check passed on the current head (82c46ebd, 291 s), and the pull merges cleanly into main.

To try it: bun test test/merge-queue-gate-result.test.ts. On the preview, after a gate has run: curl -H "authorization: Bearer $TOKEN" "$URL/api/v1/repos/trevato/forge/queue/gates?limit=5".

🤖 Generated with Claude Code

Closes #6739

Every merge-queue gate that finishes is now stored with the names of the tests that failed in it. The queue log line names them too. GET /api/v1/repos/:o/:n/queue/gates?limit=20 and a new queue_gates MCP tool return them.

Latest push: merges main, which now has #6732's check retry and #6736's README move. The only conflict was the comment at the top of src/checks/queue.ts, and it now describes both changes. No code conflicted. The check-retry and the gate-result tests both pass on the merged tree.

Why "2 failed" probably meant one test. At the end of a run, scripts/test-shards.ts prints every failure a second time, as (fail) name [1ms] [shard 3]. failuresOf didn't strip the [shard N] part, so it counted each failure twice. Both parsers now share one pattern and count each test once.

What changed

• Reading the output: src/checks/gate_tests.ts reads a gate's output for:

- how many tests passed, added up across shards; - how many different tests failed; - up to 20 failing tests, each with its file and its first 5 error lines.

landing.ts carries this on the red verdict. queue_store.ts keeps it when a gate's verdict is picked up again after a restart.

• Storage: a new migration adds a gate_result table, written by src/checks/gate_result.ts. Every finished gate gets a row, whether green, red or cut_off. That covers whole batches, the smaller gates run to find the culprit, and pulls gated alone. A row holds the pulls, the reason, the counts, the failing tests and the duration. Each time a row is written, rows older than 7 days are deleted.
• Log line: a red now reads gated 8 pulls: red (2 failed: "a > b", "c > d"). It names up to 5 tests, then adds and N more. A red that named no test reads as before.
• API:

- The answer is { items, next_cursor }, newest first. - limit is 1–100 and cursor is a gate id. - A malformed cursor gets a 422. A repository you can't read gets a 404. - The route names its session, gates and render timing phases. Leaving these out is what failed the check on #6740.

• Flaky flag: a failing test in the answer carries flaky: true when the same test in the same file failed in two red gates that share no pull. Only the last 500 red gates of the kept week are compared.

Not done

• A flaky red is still searched and bisected the same way; the flag doesn't change what the queue does.
• The log line doesn't mark which tests are flaky.
• No web page reads the table yet.
• The issue points to #6643 for a flake list, but #6643 is a pull that raises a migrate test's timeout, and main has no flake list. So the flaky flag reads gate_result directly instead of an existing list.

Tests

• test/merge-queue-gate-result.test.ts is new. It feeds in a fake two-shard output with two failing tests and gets both names once, with their files, error lines and counts. It also covers the 20-test cap, the log wording and the flaky rule.
• End to end, it runs sweepGreen against a fake check lane. The log line names both tests. The API and the MCP tool return both, with failed equal to the number of tests named. It also covers paging, the 404, the 422, the flaky flag and the 7-day pruning.
• test/mcp.test.ts lists every MCP tool by name, so queue_gates was added to that list. The test itself wasn't wrong.
• After the merge the type check is clean. The merge-queue, gate, MCP and route-timing suites pass: 146 tests across 19 files.

To try it: bun test test/merge-queue-gate-result.test.ts. On the preview, after a gate has run: curl -H "authorization: Bearer $TOKEN" "$URL/api/v1/repos/trevato/forge/queue/gates?limit=5".

🤖 Generated with Claude Code

Closes #6739