Every GET /api/v1 route the timing walk exercises answers in under 1 s on the fixture, and the walk names its five slowest on every run #8148

The route-timing walk now prints its five slowest routes on every run, and a new test fails if any walked route takes 1 s or more. No walked route is over 1 s locally, so no route module changed: this pull adds only the report and the 1 s guard, as the issue's Risk line allows.

What changed (all in test/route-timing-coverage.test.ts):

• The walk keeps every answer it gets. A finally block prints the five slowest as pattern -> status in ms, slowest first, so the list appears whether the walk passes or fails.
• New test, "every walked route answers under 1 s on the fixture": it checks each walked route against ROUTE_MS = 1_000 and lists any that reach it as pattern -> status in ms, so a regression names its route.
• New unit test for the report: given seven made-up timings, the report must return the right five in the right order, worked out by hand.
• REQUEST_MS, UNEXERCISED and UNTIMED are unchanged. Requests still run in batches of 8.

Five slowest, from three local runs of bun test test/route-timing-coverage.test.ts:

All statuses were 200 except the one marked 404. Because the 8 requests in a batch run at once, these times include waiting behind the rest of the batch. That is why routes in the same batch show the same number. The slowest route took about an eighth of the 1 s limit.

Not done: I didn't change any route's code, since none was slow. I didn't fix a specific number of batches into the guard.

Checks: bun scripts/gate.ts and bun x tsc --noEmit passed. The 13 test files named by bun scripts/fast.ts passed (178 tests). The full suite was not run here; the forge runs it on this push.

To try it: run bun test test/route-timing-coverage.test.ts and read the "five slowest walked routes" block at the top of the output.

🤖 Generated with Claude Code

Closes #8145

The route-timing walk now prints its five slowest routes on every run, and a new test fails if any walked route takes 1 s or more. No walked route is over 1 s locally, so no route module changed: this pull adds only the report and the 1 s guard, as the issue's Risk line allows.

What changed (all in test/route-timing-coverage.test.ts):

• The walk keeps every answer it gets. A finally block prints the five slowest as pattern -> status in ms, slowest first, so the list appears whether the walk passes or fails.
• New test, "every walked route answers under 1 s on the fixture": it checks each walked route against ROUTE_MS = 1_000 and lists any that reach it as pattern -> status in ms, so a regression names its route.
• New unit test for the report: given seven made-up timings, the report must return the right five in the right order, worked out by hand.
• REQUEST_MS, UNEXERCISED and UNTIMED are unchanged. Requests still run in batches of 8.

Five slowest, from three local runs of bun test test/route-timing-coverage.test.ts:

All statuses were 200 except the one marked 404. Because the 8 requests in a batch run at once, these times include waiting behind the rest of the batch. That is why routes in the same batch show the same number. The slowest route took about an eighth of the 1 s limit.

Not done: I didn't change any route's code, since none was slow. I didn't fix a specific number of batches into the guard.

Checks: bun scripts/gate.ts and bun x tsc --noEmit passed. The 13 test files named by bun scripts/fast.ts passed (178 tests). The full suite was not run here; the forge runs it on this push.

To try it: run bun test test/route-timing-coverage.test.ts and read the "five slowest walked routes" block at the top of the output.

🤖 Generated with Claude Code

The route-timing walk now prints its five slowest routes on every run, green or red. A new test checks that every walked route answers in under 1 s on the fixture. No walked route is over 1 s locally, so no route module changed: this pull lands only the report and the 1 s guard, as the issue's Risk line allows.

All changes are in test/route-timing-coverage.test.ts:

• One shared walk: the walk runs once, in batches of 8 as before, and both the session-phase test and the 1 s guard wait for it. Either test now passes on its own under --test-name-pattern. The five slowest print as pattern -> status in ms even when the walk fails partway.
• No flaking on a busy machine: a walk answer's time includes waiting behind the other seven requests in its batch. So a route that takes 1 s or more in the walk is asked again on its own, and only a route still slow by itself fails the guard, named with its pattern, status and ms.
• One line helper formats a result as pattern -> status in ms. The report, the failure lists and the guard all use it. A unit test checks the slowest-five order and format against seven made-up timings.
• REQUEST_MS, UNEXERCISED and UNTIMED are unchanged.

Five slowest in the latest local run (all 200, about 1.4 s for the whole file). Routes in the same batch show the same time because they were sent together:

• /api/v1/flags — 63 ms
• /api/v1/telemetry/system — 63 ms
• /api/v1/telemetry/flow — 63 ms
• /api/v1/telemetry/home — 63 ms
• /api/v1/telemetry/sources — 63 ms

Earlier runs put /api/v1/repos/:owner/:name/waves, /api/v1/repos/:owner/:name/map, /api/v1/map and /api/v1/asked on top, at 90–133 ms.

I chose re-timing slow routes one at a time over reading the server's own Server-Timing total. Re-timing measures what a client actually waits for, and the guard does not depend on every route reporting a total. The re-timing branch has no test of its own, because the fixture has no slow route to drive it.

Checks: the full file passes, the guard passes when run alone, and bun x tsc --noEmit and bun scripts/gate.ts pass. I did not run the full suite; the forge runs it on this push.

To try it: bun test test/route-timing-coverage.test.ts, then add --test-name-pattern "under 1 s" to run the guard alone.

🤖 Generated with Claude Code