# 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.