docs: add test coverage improvement plans (player, data fixes)

plans/007-characterize-browser-player-flow.md

@@ -0,0 +1,35 @@
+---
+finding: "Characterize the browser player flow"
+catalog: "Tests"
+impact: "Critical watch behavior can regress while parser tests and typecheck still pass."
+base_commit: "0d31d46"
+---
+
+## Effort
+
+M - add a focused DOM/browser test harness and cover the highest-risk interactions.
+
+## Risk
+
+LOW - tests should characterize existing behavior, not change product behavior.
+
+## Confidence
+
+HIGH - existing TypeScript tests cover helpers, while the player orchestration is largely untested.
+
+## Evidence
+
+- `static/player/main.ts:141-149` wires progress, controls, keyboard, skip, subtitles, quality, and mode behavior in one browser-only flow.
+- `static/player/progress.ts:65-76` persists progress through `fetch` and updates save state.
+- `static/player/episodes/complete.ts:10-28` posts completion, retries failures, and mutates UI state.
+- Existing TS tests are limited to `static/player/validate.test.ts` and `static/player/subtitles/vtt.test.ts`.
+
+## Resolution Approach
+
+Add targeted browser-player characterization tests without recreating broad flaky E2E coverage. Prefer small DOM tests under `static/player` that construct minimal player markup, stub `fetch`, `navigator.sendBeacon`, media element properties, timers, and `window.showToast`, then exercise the exported setup or lower-level modules.
+
+Start with the highest-risk flows: initial source URL construction from mode token and quality preference, progress save on pause/scrub, completion retry behavior, and graceful handling when no playable source exists. If current modules are hard to test, introduce minimal testability seams while preserving runtime behavior.
+
+Avoid reintroducing full Playwright infrastructure unless a lightweight DOM approach is insufficient. Keep fixtures short and readable so failures explain a specific player behavior.
+
+Verify with `bun test`, `bunx tsc -p tsconfig.json --noEmit`, and `bun run lint:ts`.

plans/008-add-data-fix-runner-characterization-tests.md

@@ -0,0 +1,34 @@
+---
+finding: "Add data-fix runner characterization tests"
+catalog: "Tests"
+impact: "Startup data repairs can drift or fail partway without fast regression coverage."
+base_commit: "0d31d46"
+---
+
+## Effort
+
+S - seed in-memory SQLite rows and assert before/after behavior.
+
+## Risk
+
+LOW - tests should use existing migration helpers and avoid production data.
+
+## Confidence
+
+HIGH - the runner and registered fixes currently lack direct characterization tests.
+
+## Evidence
+
+- `internal/database/fixes.go:33-50` runs each unapplied registered fix and records it only after success.
+- `internal/database/fixes/20260526_episode_availability_backfill_next_refresh_at.go:12-24` mutates cached episode availability rows at startup.
+- `internal/database/database_test.go:12-72` covers migrations and cache cleanup, but not `RunDataFixes` or registered fix effects.
+
+## Resolution Approach
+
+Add tests in `internal/database` or `internal/database/fixes` that use an in-memory SQLite database and existing migration helpers. Cover runner behavior and at least each registered fix’s observable effect.
+
+Runner tests should assert that unapplied fixes run, applied fix IDs are skipped, successful fixes are recorded in `data_fixes`, and failed fixes do not get marked applied. Individual fix tests should seed the minimum relevant rows, run the fix, and assert the changed fields and idempotency.
+
+If a registered fix depends on external services or slow behavior, isolate it behind existing dependency seams or test the row-selection/mutation behavior directly. Do not introduce network calls into these tests.
+
+Verify with `go test ./internal/database ./internal/database/fixes ./...`.