Daniel 9b2cb339a1 test(e2e): drive My Resources through the browser, and assert what it sends ... The unit tests for this feature read source files and assert patterns. They prove the code says the right thing, not that the screen does it, and nothing exercised the browser at all — so a mismatch between what the form sends and what the route reads passed all of them. Three real bugs shipped through that gap in one session: a modification that updated the markdown but not the deck, generation that failed whenever the slide reviewer was off, and a figure generated for a slide that never referenced it. Every one was found by driving the running server by hand. So these assert the request bodies, not only the rendering: that Generate sends topic, kind, slideCount, refinement, model and all four options as the strings the route compares against; that unticking the library sends 'false' rather than omitting the field, which the route would read as on; and that Modify posts to the right resource with every source option. Plus the screen's own behaviour — availability gating on both cards, the illustration hint switching on and staying off once overruled, the bounded searchable library, the two different empty states, an article never being offered as slides, a local refusal that spends no round trip, and a refused modification surfacing its reason. Fourteen tests, both viewports. The API is stubbed. This is the contract between the screen and the route, and stubbing keeps it fast, free and deterministic. Proven to catch regressions rather than merely pass: renaming useCorpus in the form failed two tests, breaking the availability gating failed one, and truncating the modify picker failed another. Two flakes of my own were fixed rather than retried. openTab slept 400ms for the library and picker instead of waiting for them, which made Modify report "nothing to modify yet" under load. And the console-error guard failed on net::ERR_ABORTED and net::ERR_NETWORK_CHANGED — a request in flight when the context closes, and the host network reconfiguring under a browser that runs on it. Both are the harness, not the page: anything genuinely failing carries a status code and is still caught. Five consecutive clean full runs after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Dv6sqaY6Vq3ChZHMem3cnU		2026-09-12 01:51:15 +02:00
..
tests	test(e2e): drive My Resources through the browser, and assert what it sends	2026-09-12 01:51:15 +02:00
fixtures.js	test(e2e): drive My Resources through the browser, and assert what it sends	2026-09-12 01:51:15 +02:00
package-lock.json	feat: A1+A2 — Playwright smoke suite + index.html mtime-based caching	2026-04-20 03:51:22 +02:00
package.json	feat: A1+A2 — Playwright smoke suite + index.html mtime-based caching	2026-04-20 03:51:22 +02:00
playwright.config.js	test(e2e): repair the harness, taking the browser suite from 96 failures to 11	2026-09-11 18:54:03 +02:00
seed.js	fix: voice mode reads the answer that just arrived, and reads what the page shows	2026-09-11 21:10:50 +02:00