Fix The web UI's Overview page

- Workflow: ship-change
- Change set: 01M6QSJHF5WH4SZKCTTYD0W0SS: Fix The web UI's Overview page
- Worktree: /home/rhiza/code/rhiza.fix-the-web-ui-s-overview-page
- Autonomous: yes
- Started: 2026-11-06T06:55:06Z

## Steps

- build/build (visit 1): pass, then build/render: 1 of 1 leaves passed
- build/render (visit 1): pass, then build/check: exit 0
- build/check (visit 1): pass, then review/code: exit 0
- review/code (visit 1): pass, then review/review: exit 0
- review/review (visit 1): pass, then review/render: 5 of 5 checks passed
- review/render (visit 1): pass, then render-pr: exit 0
- render-pr (visit 1): pass, then open-pr: exit 0
- open-pr (visit 1): pass, then wait-pr: exit 0
- wait-pr (visit 1): pass, then pr-green: held after 12 checks
- pr-green (visit 1): pass, then signoff: exit 0
- signoff (visit 1): pass, then rebase: approved by rule autonomous
- rebase (visit 1): pass, then wait-rebased: exit 0
- wait-rebased (visit 1): pass, then rebased-green: held after 1 checks
- rebased-green (visit 1): pass, then land: exit 0
- land (visit 1): pass, then wait-landed: exit 0
- wait-landed (visit 1): pass, then landed-green: held after 11 checks
- landed-green (visit 1): pass, then rebase-merge: exit 0
- rebase-merge (visit 1): pass, then wait-rebased-merge: exit 0
- wait-rebased-merge (visit 1): pass, then rebased-merge-green: held after 1 checks
- rebased-merge-green (visit 1): pass, then merge: exit 0
- merge (visit 1): pass, then wait-main: exit 0
- wait-main (visit 1): pass, then main-green: held after 1 checks
- main-green (visit 1): pass, then close-out: exit 0
- close-out (visit 1): pass, then ship: exit 0
- ship (visit 1): pass, then end: exit 0

## Leaves

- web-overview-fast (step build/build): passed: attempt 2: verifier passed
  - attempt 1 builder, session d50f040f-9dbe-403a-961a-01a1afa3cf4c: pass (said done)
  - attempt 1 verifier, session 1b10d9f5-efc8-4c89-a894-01a1afa6b285: fail (verifier found 1 problem(s))
  - attempt 2 builder, session 705432ed-481a-4685-bf25-01a1afaca187: pass (said done)
  - attempt 2 verifier, session ddef990a-834f-4778-affa-01a1afb615bc: pass (Evidence written by the verifier)
  - attempt 1 finding f1: TestWebDaemonHealthCachedInBackground (internal/api/web_daemon_test.go:55-58) is flaky, so its 'many concurrent requests start one refresh' check fails sometimes. It reads started.Load() right after the 21 requests, but started is only incremented inside the refresh goroutine that healthCache.get spawns with `go h.refresh()`, and nothing makes the test wait for that goroutine to run. When it has not been scheduled yet, the test fails with 'web_daemon_test.go:57: 0 refreshes started, want 1'. Reproduced with `go test -trimpath -c -race -o $TMPDIR/api.test ./internal/api && $TMPDIR/api.test -test.run TestWebDaemon -test.count=300 -test.cpu 1,2,4,8`: 1 failure in 1200. Also seen once in `go test -trimpath -count=10 -race ./internal/api -run TestWebDaemon`. The cache code itself is correct: the refreshes flag allows only one refresh at a time, and every other point of the acceptance passed (both / and /fragments/daemon answer under 400 ms while health blocks, pending pill first, report shown once it lands, old report served while exactly one new refresh starts). Fix the test: wait for started to reach 1 (waitFor), then check, after a short pause, that it is still 1, the same way the stale-report phase already does at lines 76-80.
- web-overview-fast (step review/review): open
  - attempt 2 fixer in cycle 2, session 30f56250-a046-4ebe-adef-01a1afc4a8ba: pass (said done)
  - attempt 2 verifier in cycle 2, session 9192c011-8828-4cd6-a61d-01a1afc7d9c3: pass (Evidence written by the verifier)

## Checks

- compliance (step review/review): passed after 1 cycle
  - cycle 1: passed, check session 8875d330-67b3-4dd6-9a28-01a1afbf058d pass (said done)
  - round 1 (cycle 1): 2 findings, 0 confirmed
    - f1 minor at internal/api/web_daemon_test.go:46 on web-overview-fast: The 'pending, not failed' half of the acceptance is asserted against the class rz-pill--failed, which never renders: the failing health state is "bad" (internal/api/health.go:35), so the template emits rz-pill--bad. The not-failed check is vacuous; it passes today only because no pills render before the first report. Assert the absence of rz-pill--bad (or of any non-pending pill).
    - f2 nit at internal/api/web_daemon_test.go:38 on web-overview-fast: The acceptance says 'well under 0.5 s', but the test's bound is 400 ms, close to the limit. Responses really take about a millisecond, so a tighter bound (e.g. 100 ms) would match the wording better.
- quality (step review/review): passed after 2 cycles
  - cycle 1: failed, check session 2899ef5d-b583-4adc-b46f-01a1afbf32f3 pass (said done), critic session f6057c30-05a8-41de-84c7-01a1afc3b2c7 pass (said done)
  - cycle 2: passed, check session 663d881c-6d28-4549-b02b-01a1afceec8f pass (said done)
  - round 1 (cycle 1): 3 findings, 1 confirmed
    - f1 major at internal/api/web_daemon.go:41 on web-overview-fast: Nothing tells the open page when a background health refresh lands. The daemon section re-fetches only on a 'daemon' event (app.js onEvent), and web.EventDaemon (internal/api/web_events.go:77) fingerprints only the daemon state file, which a health refresh never changes. So an owner who opens the Overview first after the daemon starts sees 'Checking…' with no pills until they reload or the daemon's state happens to change, and a refreshed report (after 30 s) never reaches an open page either. Before this change, every daemon-event fetch recomputed health. Fix: make the health cache's result (e.g. the pills' states and summaries, or a generation counter) part of the daemon event's fingerprint, or have the cache's landing emit a daemon event, and test that the pending panel is replaced live. — confirmed: Checked against the code. The daemon section (internal/web/daemon.go:79) re-fetches only on daemon, inbox or change events. web.EventDaemon (internal/api/web_events.go) fingerprints only daemon.ReadState fields, and healthCache.refresh (internal/api/web_daemon.go:43) changes none of them and emits nothing. So the 'Checking…' pill this change adds to the first render stays on an open page in a quiet repo until some unrelated event or a reload. This is a regression: before the change the first render always carried the pills. Must be fixed.
    - f2 minor at internal/api/web_daemon.go:41 on web-overview-fast: refresh runs runHealth on a bare goroutine. A panic there now kills the daemon process, where in the request path net/http recovered it. It also leaves refreshes stuck true. Consider a recover that clears refreshes.
    - f3 nit at internal/api/web_daemon_test.go:46 on web-overview-fast: The 'not failed' half of the pending assertion looks for rz-pill--failed, but health states are ok/warn/bad, so it can never match. It should check that no rz-pill--bad (or any model pill) is shown before the report lands.
  - round 2 (cycle 2): 4 findings, 0 confirmed
    - f1 minor at internal/web/events.go:55 on web-overview-fast: A narrow race remains for the pending panel: the stream takes its baseline fingerprint when it connects, so if a refresh that some earlier request started (another tab, or a reload while 'Checking…' shows) lands between the page's render and the EventSource connecting, the baseline already holds the report, no daemon event is ever sent, and the page keeps showing 'Checking…' until the next reload or an unrelated daemon change. onopen re-fetches sections only after a reconnect. Re-fetching the daemon section on the first open too, or rendering the fingerprint into the page, would close it.
    - f2 minor at internal/api/web_daemon.go:46 on web-overview-fast: fingerprint starts a refresh whenever the report is 30 s old, and every open /events stream calls it once a second, so one idle open tab now runs the full model check (about 5 s of CPU on the VM) every 30 s, indefinitely, beside the daemon's agent runs. Before, health ran only on page loads and daemon events. Worth a longer interval for stream-driven refreshes, or refreshing only when a page is fetched.
    - f3 minor at internal/api/web_daemon.go:50 on web-overview-fast: Still open from cycle 1: refresh runs runHealth on a bare goroutine with no recover, so a panic in the check kills the daemon (net/http used to recover it on the request path) and leaves refreshes stuck true.
    - f4 nit at internal/api/web_daemon_test.go:145 on web-overview-fast: The last phase sleeps 100 ms and counts events without first waiting for the second refresh to land, so it passes whether or not the identical report was re-stored. Waiting for the cache's at to move (or for a third read to become possible) would make 'the same report sends no event' a real check.
- qa (step review/review): passed after 1 cycle
  - cycle 1: passed, check session e0e47890-626b-49ac-9713-01a1afbf5bc9 pass (said done)
  - round 1 (cycle 1): no findings
- scope (step review/review): passed after 1 cycle
  - cycle 1: passed, check session a88f3cee-3ecb-488f-9dd6-01a1afbf8a7c pass (said done)
  - round 1 (cycle 1): no findings
- model (step review/review): passed after 1 cycle
  - cycle 1: passed, check session 77dec5ee-5133-4a86-b1ae-01a1afbfb899 pass (said done)
  - round 1 (cycle 1): no findings

## Code checks

- step review/code: pass

## Sign-offs

- signoff (visit 1): approved by rule autonomous

## Sessions

- build/build, session d50f040f-9dbe-403a-961a-01a1afa3cf4c: tokens input 18, output 4802, cache creation 34668, cache read 462567; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 1b10d9f5-efc8-4c89-a894-01a1afa6b285: tokens input 24, output 5355, cache creation 35352, cache read 666837; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 705432ed-481a-4685-bf25-01a1afaca187: tokens input 10, output 1394, cache creation 25954, cache read 237689; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session ddef990a-834f-4778-affa-01a1afb615bc: tokens input 16, output 2965, cache creation 33077, cache read 426252; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 8875d330-67b3-4dd6-9a28-01a1afbf058d: tokens input 10, output 2341, cache creation 32441, cache read 249859; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 2899ef5d-b583-4adc-b46f-01a1afbf32f3: tokens input 24, output 3580, cache creation 40451, cache read 718748; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session e0e47890-626b-49ac-9713-01a1afbf5bc9: tokens input 34, output 7131, cache creation 43725, cache read 1068255; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session a88f3cee-3ecb-488f-9dd6-01a1afbf8a7c: tokens input 8, output 1237, cache creation 32172, cache read 190383; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 77dec5ee-5133-4a86-b1ae-01a1afbfb899: tokens input 20, output 2883, cache creation 40559, cache read 591450; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session f6057c30-05a8-41de-84c7-01a1afc3b2c7: tokens input 16, output 2485, cache creation 33730, cache read 418282; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 30f56250-a046-4ebe-adef-01a1afc4a8ba: tokens input 28, output 8375, cache creation 44651, cache read 863277; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 9192c011-8828-4cd6-a61d-01a1afc7d9c3: tokens input 14, output 2736, cache creation 37407, cache read 381787; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 663d881c-6d28-4549-b02b-01a1afceec8f: tokens input 20, output 3480, cache creation 42170, cache read 591039; helper tokens input 0, output 0, cache creation 0, cache read 0

Totals: tokens input 242, output 48764, cache creation 476357, cache read 6866425; helper tokens input 0, output 0, cache creation 0, cache read 0