A pure read says the stranded spend: dollars of crew runs on pulls that are open and not landed #6434

readStranded(db, publicOnly = false) now exists in src/flow/stranded.ts, with tests in test/flow-stranded.test.ts. bun test test/flow-stranded.test.ts passes (4 tests) and the type check is clean. I did not run the rest of the suite; the forge's check does that on this push.

It returns { usd, pulls, costliest }. usd is the sum of cost_usd over runs on pulls that are open and unmerged. costliest is the five most expensive of those pulls, each as { number, usd }, costliest first, with ties broken by the lower number. It is one SQL read with a window function for the totals. It uses the same publicOnly rule as readVitals: public repositories only when set.

The tests cover:

• Landed and closed pulls: a landed pull's runs and a closed unmerged pull's runs are not counted.
• publicOnly: it leaves out private repositories.
• Ranking: the costliest pulls come back in order.
• Speed: with 200 open pulls and 2,000 runs it answers under 50 ms. I set the bound at 50 ms, loose against the 5 ms target, so a slow shared machine doesn't fail the test. I didn't record the actual time.

pulls counts every open unmerged pull, including ones that haven't spent anything yet. That matches readVitals' open, and the issue could be read the other way. If you want it to count only pulls that have cost something, it is a small change.

Nothing calls it yet, as the issue asked. It adds no dependencies.

Closes #6421

readStranded(db, publicOnly = false) now exists in src/flow/stranded.ts, with tests in test/flow-stranded.test.ts. bun test test/flow-stranded.test.ts passes (4 tests) and the type check is clean. I did not run the rest of the suite; the forge's check does that on this push.

It returns { usd, pulls, costliest }. usd is the sum of cost_usd over runs on pulls that are open and unmerged. costliest is the five most expensive of those pulls, each as { number, usd }, costliest first, with ties broken by the lower number. It is one SQL read with a window function for the totals. It uses the same publicOnly rule as readVitals: public repositories only when set.

The tests cover:

• Landed and closed pulls: a landed pull's runs and a closed unmerged pull's runs are not counted.
• publicOnly: it leaves out private repositories.
• Ranking: the costliest pulls come back in order.
• Speed: with 200 open pulls and 2,000 runs it answers under 50 ms. I set the bound at 50 ms, loose against the 5 ms target, so a slow shared machine doesn't fail the test. I didn't record the actual time.

pulls counts every open unmerged pull, including ones that haven't spent anything yet. That matches readVitals' open, and the issue could be read the other way. If you want it to count only pulls that have cost something, it is a small change.

Nothing calls it yet, as the issue asked. It adds no dependencies.

The full gate on land was red; the pull is open again. Red tests:

• no tight wall-clock bound in a test > no test file bounds a request or a spawn below the floor
• no raw wall-clock budget in a test (#4429) > no test file holds a speed to a raw ms number
• no tight wall-clock bound in a test > no test file bounds a request or a spawn below the floor [347.04ms] [shard 640]
• no raw wall-clock budget in a test (#4429) > no test file holds a speed to a raw ms number [417.81ms] [shard 640]

readStranded now has no wall-clock assertion in its test, which was what turned the gate red. I did not run the two gate guards (the wall-clock bound and the raw-ms budget) locally. My filter matched no test files, so the gate on this push is the first check of them.

• Gate fix: I removed the performance.now() timing and the expect(ms).toBeLessThan(50) from test/flow-stranded.test.ts. I also removed the warm-up call that only existed for the timing. The 200-pull, 2,000-run test still checks that costliest holds five rows, that pulls is 203 and that usd is the full total. Row counts and totals pin correctness without a clock.
• Juniper's other note: I removed the meaningless expect(counter.get(pub)).toBeGreaterThan(0). bun test test/flow-stranded.test.ts passes (4 tests).
• Not done: wiring readStranded into the vitals page, tty and MCP. That is a separate change. I would do it as its own issue, linked under #5930, so this pull stays the pure read the issue asked for.

Steward tick: this pull is red on its own merge with current main (gated alone, failed) and was held out of the landing queue so the others can land. Rebase on main, fix the failing test, push - then the hold comes off.

I merged current main into the branch and pushed. I did not rebase, because rebasing would have needed a force push, which is refused. The merge was clean.

I could not tell which test failed on the steward's gated-alone run, since I only had the hold message and no log. The earlier red tests were the wall-clock guards, and the timing assertion behind them was already removed in the previous push. After the merge, test/flow-stranded.test.ts passes, 4 of 4. A full bun test test/ run exceeded the 10-minute limit, so the whole suite did not finish here. The forge's check on this push will show whether anything else is red.

I changed the test header to cite #5930, matching the module comment, so the file now uses one issue number.

I did not wire readStranded into the vitals page, tty or MCP, or add a README line. Juniper asked for that as its own pull under #5930, and I agree, so the README line goes in with it.