The terminal's Flow screen reads the same panel cache as /boards #7005

The Flow screen now takes its panel figures from src/flow/panel_cache.ts, so opening it right after a /boards load runs none of those readers again. bun x tsc --noEmit is clean and the new test/tui-flow-cache.test.ts passes. I did not run the whole suite.

What changed

• flowLines in src/tui/screens/flow.ts calls panelFigures(db, "owner" | "agent", now). The rights split is the cache's own: an agent gets its public-only set, an admin gets the full one.
• Seven figures come from the cache: the pile, conflicted pulls with the rebase lane, changes-requested waits, reviewer load, idle pulls, parked, and the lead-time, yield, review-latency and openers lines.
• idleLines now takes the idle list instead of reading it itself. Nothing else called it.
• Several figures still read fresh, because the cache doesn't hold them: the pipeline stages, throughput, merge queues, vitals, clog, alarms, warming, held, and the duplicate-test lines.

Tests

• The new test proves that a screen opened after a panel load runs fewer reads than one with nothing kept.
• It checks that the screen's lead-time, build-yield, review-latency and pile lines equal what the cache holds.
• It checks that an agent's set is kept apart from the admin's.
• The first check is an inequality, not an exact count. idlePullsCached keeps its own mark, so the exact numbers differ by one between cold and warm.
• Reading the issue's "proves no reader ran again" literally would mean a count of exactly zero for the cached readers only. I settled for the inequality; a stricter test would need hooks in the readers.

Pre-existing failure test/flow-panel-cache.test.ts ("an agent never sees an admin's figures") fails intermittently when run alongside the tui-flow* and flow-panel* files. It failed the same way with my change stashed, so it is not caused by this change, and it passes on its own. I left it alone.

To try it, open /boards, then open Flow in the terminal within 30 s with no write in between.

Closes #6975

The Flow screen now takes its panel figures from src/flow/panel_cache.ts, so opening it right after a /boards load runs none of those readers again. bun x tsc --noEmit is clean and the new test/tui-flow-cache.test.ts passes. I did not run the whole suite.

What changed

• flowLines in src/tui/screens/flow.ts calls panelFigures(db, "owner" | "agent", now). The rights split is the cache's own: an agent gets its public-only set, an admin gets the full one.
• Seven figures come from the cache: the pile, conflicted pulls with the rebase lane, changes-requested waits, reviewer load, idle pulls, parked, and the lead-time, yield, review-latency and openers lines.
• idleLines now takes the idle list instead of reading it itself. Nothing else called it.
• Several figures still read fresh, because the cache doesn't hold them: the pipeline stages, throughput, merge queues, vitals, clog, alarms, warming, held, and the duplicate-test lines.

Tests

• The new test proves that a screen opened after a panel load runs fewer reads than one with nothing kept.
• It checks that the screen's lead-time, build-yield, review-latency and pile lines equal what the cache holds.
• It checks that an agent's set is kept apart from the admin's.
• The first check is an inequality, not an exact count. idlePullsCached keeps its own mark, so the exact numbers differ by one between cold and warm.
• Reading the issue's "proves no reader ran again" literally would mean a count of exactly zero for the cached readers only. I settled for the inequality; a stricter test would need hooks in the readers.

Pre-existing failure test/flow-panel-cache.test.ts ("an agent never sees an admin's figures") fails intermittently when run alongside the tui-flow* and flow-panel* files. It failed the same way with my change stashed, so it is not caused by this change, and it passes on its own. I left it alone.

To try it, open /boards, then open Flow in the terminal within 30 s with no write in between.

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

• GET /alice/forge/settings names its phases and answers within its budget

The gate's log: /api/v1/repos/trevato/forge/gates/1793108675774-39c81f9c53a9/log

Both of juniper's items are done and pushed. I think the gate's red test was timing noise, not this pull.

• Gate failure: GET /alice/forge/settings names its phases… came back at 51 ms against a limit of 50. That page doesn't touch the flow panel, and it passes when I run test/settings-repo-timing.test.ts alone (5 of 5). I changed nothing for it; it should clear on a re-run.
• Tighter test: src/flow/panel_cache.ts now exports panelReads, a counter bumped each time the readers run. The first test in test/tui-flow-cache.test.ts now asserts exactly that. A panel load adds one read, and opening the Flow screen right after adds zero. A screen opened with nothing kept adds one.
• Flaky test: test/flow-panel-cache.test.ts ("an agent never sees an admin's figures") failed on about one run in five, even alone. It seeded pulls exactly one hour old, which is the edge of the openers' one-hour window. They aged out before the read, so the openers count was 0 instead of 2. The pulls are now 30 minutes old. I fixed it in this pull, so I did not open a separate issue.

bun x tsc --noEmit is clean. bun test test/tui-flow test/flow-panel passed six times in a row, and I did not run the whole suite.

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 it, and I changed the two things juniper flagged. I did not find which test failed on the Steward's merge with main. After the merge, bun x tsc --noEmit is clean. These pass: test/tui-flow*, test/flow-panel*, test/tui-screens and test/tui-app. I did not run the whole suite.

• Merge, not rebase: I rebased on main first, but a force push is refused here, so I pushed a merge commit instead. The diff against main is still the three files: src/tui/screens/flow.ts, test/flow-panel-cache.test.ts and test/tui-flow-cache.test.ts.
• Counter removed: panelReads is gone from src/flow/panel_cache.ts, which is back to what main has. The test now counts runs of the openers reader's SQL (WITH RECURSIVE flow). Only the panel's readers issue it, and flowLines no longer does. A panel load runs it once, the screen right after runs it zero times, and a screen opened after a write runs it once.
• Agent screen test: it seeds an agent's pull in a private repo. The admin screen says scout: 1 pull, and the agent screen has no scout and says Opened in the last hour: no pulls. Each screen still gets its own set when asked again.

Parked by the crew: the last three runs here failed or were declined within an hour, so nothing more starts until a person says what to try.

I merged main into the branch and pushed it. The type check is clean, and test/tui-flow* and test/flow-panel* pass (30 tests); I did not run the whole suite.

The only conflict was in test/flow-panel-cache.test.ts. main had made the same fix I had, moving the seeded pulls from one hour old to 30 minutes old so they stay inside the openers window. I kept main's version of that line. It differs from mine only in a trailing comment, so nothing from this pull was lost.

The pull's change itself is unchanged: the terminal's Flow screen reads the shared panel cache, and test/tui-flow-cache.test.ts covers it.