Files
familysync/.planning/milestones/v1.1-phases/07-mobile-test-harness/07-DISCUSSION-LOG.md
T
2026-06-18 22:21:38 -04:00

5.5 KiB

Phase 7: Mobile Test Harness - Discussion Log

Audit trail only. Do not use as input to planning, research, or execution agents. Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

Date: 2026-06-10 Phase: 7-Mobile Test Harness Areas discussed: Device profile(s), Test-data strategy, Assertion approach, Stack lifecycle / baseURL


Device profile(s)

Option Description Selected
iPhone only Single iPhone profile; matches Apple-member UX constraint; fastest, misses Android-Chrome layout
iPhone + Pixel Two-profile matrix covering both ecosystems; ~2x runtime
iPhone + small-Android iPhone + narrow Android profile to stress tightest viewport

User's choice: iPhone + Pixel

Follow-up: engine fidelity

Option Description Selected
Faithful engines iPhone → WebKit, Pixel → Chromium; most faithful; adds WebKit to CI image
Chromium-only Both Chromium, iPhone viewport/UA/touch only; lighter, matches playwright-cli

User's choice: Faithful engines Notes: Accepts heavier browser image for true WebKit/Chromium rendering fidelity.


Test-data strategy

Option Description Selected
Seed DB fixtures Insert deterministic rows before run; realistic end-to-end render path
Mock API routes Playwright route-fulfill canned JSON; hermetic, bypasses real API
Chrome/empty-states only No population; assert nav/drawers/tap-targets/empty copy; smallest scope
Hybrid: seed + empty Seed DB for populated views + keep empty-state assertions; broadest coverage

User's choice: Hybrid: seed + empty Notes: Captured constraint — seed must be deterministic and reset per run (SC #3, repeatable day-over-day); runs in global-setup against MariaDB :3306, targets shared calendar id 10 + lists.


Assertion approach

Option Description Selected
Structural + tap-targets Role/locator + measured box checks (≥44px, no overflow); portable, stable; misses visual drift
Both (structural + screenshots) Add toHaveScreenshot; catches visual regressions but flaky cross-env
Screenshots-primary Lean on visual snapshots; highest flakiness/maintenance

User's choice: Other (free text) — "Defer this decision to research and for you to decide as it needs to be robust and low maintenance. I have to imagine this has been done elsewhere before and should be well documented." Notes: Marked as research question, not locked. Claude's steer: lead with structural + tap-target measurement; add screenshots only if research finds a non-flaky CI-baseline pattern. Schedule-X widget makes naive pixel snapshots drift-prone.


Stack lifecycle / baseURL

Option Description Selected
baseURL + readiness wait Configurable baseURL, readiness gate; caller owns stack bring-up; matches existing dev stack ✓ (Claude, per "you decide")
Playwright webServer Auto-start vite; can't own multi-container API/DB/Redis stack (partial — vite only)
You decide Pick best fit for SC #4 + local ergonomics

User's choice: You decide Notes: Claude's recommendation — baseURL (env-driven) + global-setup readiness gate on /health; caller (operator locally / compose in CI) brings up the stack; optional webServer for vite only with reuseExistingServer: !CI; API+MariaDB+Redis stay compose-managed. Satisfies SC #4.

Claude's Discretion

  • Assertion approach — deferred to research (robust/low-maintenance, host↔CI portable).
  • Stack lifecycle — "you decide"; recommendation captured above, planner may refine env-var name / webServer wiring.
  • Spec file location/structure, failure trace/artifact capture, npm-script + Makefile wiring — not discussed; planner's discretion following existing conventions.

Deferred Ideas

  • "Gitea CI — full regression + Docker publish" todo (score 0.6) — belongs to Phase 8, which consumes this harness. Reviewed, not folded.