`5x/REPORT.md`

52 lines
# /5x REPORT — doing-viewer (http://127.0.0.1:9790)
Date: 2026-09-14 · target: local pm2 `doing-viewer` (Basic auth admin) · TK-11446 follow-on

## Sweep ledger
| sweep | passed | caught | fixed | commit |
|-------|--------|--------|-------|--------|
| 1 | 3/4 runnable | 1 (favicon 404 JS error) | 1 | ea854b7 |
| 2 | 4/4 runnable | 0 | 0 | — |
| 3 | 4/4 runnable | 0 | 0 | — |
| 4 (post-contrarian) | 4/4 runnable | 2 (Cody: false-green + untested money endpoint) | 2 | 04dd24f |

"Runnable" = M1/M2/M3/B4-Chrome. B5 Safari / B6 Firefox: see cross-browser note — this is **4 of 6 lanes**, not a full 6-lane green.

## Final six-way state
- M1 HTTP contract — PASS (200 text/html)
- M2 headless render — PASS (~393KB, no blank)
- M3 automation E2E — PASS (#list present, #unlock click OK, **0 JS errors** after favicon fix)
- B4 Google Chrome — PASS (also directly re-proven via Playwright chromium: #list=1, 0 JS errors)
- B5 Safari / B6 Firefox — see cross-browser note (Playwright webkit/firefox engine builds pinned to the runner's version were downloading at report time). Not a build defect.

## What was fixed
### Sweep 1 — favicon 404 (ea854b7)
Every page load fired a console error: the browser's implicit `/favicon.ico` GET hit server.js's default 404. The /3x runner's `favicon`-text filter missed it (Chrome's console text for a failed subresource is generic — "Failed to load resource… 404", no URL). Fix: `/favicon.ico → 204 No Content` route before the default 404. Verified /favicon.ico=204, /=200; direct 3× real-Chrome repro went 3/3-error → 0/3-error.

### Sweep 4 — contrarian FIX FIRST round (04dd24f)
Cody the Contrarian gated the sweep-3 "clean" and caught two real holes:

1. **False-green in the prior TK-11446 exit-code fix (3fad9e6).** That commit made a transient source-:9790-down exit 0 and cited "cron-fire-canary's artifact-freshness catches a long outage" as its safety net. But the job is manifest-flagged `artifact_weak: true` — its `publish.log` is BOTH `StandardOutPath` and `StandardErrorPath`, and every branch (including the source-down WARN line) writes a console line every 180s tick, so that artifact **never goes stale**. The canary therefore trusts the launchd EXIT CODE for this job, and a blanket exit-0 made a *sustained* source outage invisible (TK-11431 false-green class).
   **Fix:** track continuous source-down duration across launchd runs via `data/source-down-since.json`. Exit 0 only inside a 10-min self-heal grace (tolerates a pm2 restart); exit 1 once the outage is sustained, so the canary genuinely warns. Success/recovery clears the state. A real publish-path failure (source up, rsync/JSON fails) still exits 1.
   Verified 5 ways: success→0+clear · first-down→0+record · sustained(20m)→1 · recovery→0+clear · source-up-but-garbage→1.

2. **M3 never exercised the app's real action, and the sweep didn't disclose it.** `#unlock` is an empty `<span>` on an owner (localhost) device — clicking it is a no-op. The real control is the per-ticket action button → `POST /api/action` → `execFile bash run-ticket.sh` which **launches a fresh iTerm2 + Claude session on the ticket**. The happy path is deliberately NOT fired live (real side effect). Instead the guard/error paths were verified live, all rejecting *before* the `execFile` spawn:
   - bad JSON → **400** ✓
   - unknown / bad-shape id → **404** ✓
   - valid current-doing id + bad verb → **400** ✓ (rejected at the verb check, before spawn)
   Confirmed no session spawned (board-launch event count unchanged at 1464 across the tests).

## Cross-browser note (Cody hole 3 — framing)
Green on **4 of 6 lanes**: HTTP contract + headless render + Playwright-Chromium E2E (#list=1, 0 JS errors) + Chrome. The earlier "clean twice" framing overstated confidence — corrected.

**Safari/Firefox (B5/B6): attempted, blocked by tooling — NOT a build defect.** Tried to install matching Playwright webkit/firefox engine builds; hit Playwright↔browser-build version churn on this box (each resolvable playwright wanted a different browser revision — 2227/1497 vs 2336/1532 vs 2358/2359, and the pinned-version install stalled/failed). This is an environment/tooling version-pin issue entirely independent of the doing-viewer build's correctness. For a true 6-engine run, do a fresh self-contained `npm i @playwright/test && npx playwright install` in a scratch dir (a few min of downloads) then `PW=<that> node /tmp/xbrowser-9790.js`, or use /allbrowsers. Chromium — the primary engine — is directly re-proven clean, so the build is not suspected on WebKit/Gecko; the gap is proof-coverage, not a known defect.

## Reversibility (all reversible-local, internal ops viewer, no externality)
- `ea854b7` favicon 204 route → `git revert ea854b7`
- `04dd24f` honest exit code (supersedes 3fad9e6's blanket exit-0) → `git revert 04dd24f`
- `3fad9e6` original TK-11446 source-down classification → `git revert 3fad9e6`
All ledgered to `~/.claude/yolo-queue/executed-reversible/ledger.jsonl`.

## Contrarian verdict trail
- Sweep 3 self-assessed "clean twice" → Cody: **FIX FIRST** (3 holes; 2 real defects + 1 framing).
- Sweep 4 addressed all 3: false-green fixed (04dd24f), money-endpoint guard verified, framing corrected.