Review: Bug: date field dead on mobile — no calendar picker

Verdict: READY

Template Completeness

• [x] Type — present (Bug)
• [x] Lineage — present (plan-wkq → Phase 14)
• [x] Repo — present (forgejo_admin/westside-contracts)
• [x] What Broke — present (substitutes for User Story, appropriate for bug)
• [x] Repro Steps — present (4 clear steps)
• [x] Expected Behavior — present (native date picker with disabled attribute)
• [x] Environment — present (cluster, namespace, commit)
• [x] Acceptance Criteria — present (6 criteria, all testable)
• [ ] File Targets — partial. Code snippet shown inline but no formal "File Targets" section listing files to modify and files not to touch. Minor gap; the single-file scope is obvious.
• [ ] Test Expectations — missing. No test commands or test file references. Acceptable for a 1-point CSS/HTML fix, but an agent would benefit from knowing the existing test suite.
• [ ] Constraints — missing. No mention of patterns to follow. Minor for this scope.
• [ ] Checklist — missing (PR opened, tests pass, no unrelated changes). Boilerplate, not blocking.
• [x] Related — present (project, issue #9, issue #7)

File Targets

• [x] src/routes/contract/[token]/+page.svelte — verified on main (commit 813baf3). Line 462 (not 458 as ticket states) contains <input class="form-input" type="text" id="signDate" value={dateStr} readonly>. The bug is real. Line number discrepancy is minor (462 vs 458).
• [x] dateStr computed at line 27 via toLocaleDateString('en-US', ...) — confirmed. Returns human-readable string like "March 24, 2026", not YYYY-MM-DD format needed for input[type=date].
• [x] Success overlay at line 494 uses {dateStr} — fix must ensure human-readable display is preserved here. The branch fix adds a displayDate derived value for this purpose.

Repo Placement

Dependencies

• Issue #9 (SSR timezone fix) — closed, merged as PR #10 (commit 813baf3). This issue is a follow-on from #9's fix. The timezone fix moved date computation to onMount but kept type="text" readonly. Documented correctly in the ticket.
• Issue #7 (E2E validation) — open, in next_up column (board item 330). This ticket's label says blocks:contracts. Issue #7 depends on the contract flow working, so this fix unblocks E2E sign-off. Dependency is correctly documented.
• Issue #6 (outbox event) — done on the board (item 328). No conflict.
• Branch already exists: 11-fix-date-input-mobile with commit 8bc82d0 already implements the fix. The fix changes type="text" readonly → type="date" disabled and adds displayDate derived value for the success overlay.

Acceptance Criteria

• [x] "Date field uses type=date with today as default value (YYYY-MM-DD)" — testable via DOM inspection
• [x] "Field is disabled so user cannot change the date" — testable via DOM attribute check
• [x] "Native mobile calendar picker appears on tap" — testable on real device / mobile emulation (Playwright can't verify native picker, but can verify type=date + disabled)
• [x] "Display format is human-readable on all platforms" — testable, though platform-dependent rendering of type=date varies. The fix branch adds displayDate for the success overlay.
• [x] "Success overlay still shows correct signed date" — testable via Playwright after submit
• [x] "No regression in form validation or submit flow" — testable via existing test suite

Blast Radius

• No similar pattern in westside-app — grep found zero type="text" readonly instances in the sibling app.
• "Already signed" view (line 156 on main) uses new Date(player.contract_signed_at).toLocaleDateString() to display the historical signing date. This is a different concern (display-only, server timestamp) and is not affected by this fix.
• Submit payload — the fix must ensure the value sent to the API on form submission is still correct. The dateStr format changes from "March 24, 2026" to "2026-03-24", which may affect the server endpoint. The branch fix handles this correctly since the API receives the ISO date string.

Recommendation