.planning/phases/07-mobile-test-harness/07-REVIEW.md

@@ -18,11 +18,12 @@ files_reviewed_list:
 findings:
   critical: 0
   critical_resolved: 1
-  blocker: 2
+  blocker: 0
+  blocker_resolved: 2
   warning: 7
   info: 5
   total: 14
-status: issues_found
+status: blockers_resolved
 ---
 
 # Phase 7: Code Review Report (DEEP)
@@ -98,6 +99,20 @@ in README §"What globalSetup Does"; flagged only so it is not mistaken for broa
 
 ## Blocker Findings (NEW — surfaced by call-chain analysis)
 
+> **BOTH BLOCKERS RESOLVED in commit `53c3ca5`.**
+> - **BL-01:** the dead-`EmptyState` / always-rendered-wrapper assertions were replaced with a real
+>   DB→UI proof — `getByText('Seeded Test Event')` must be visible in the grid. Verified non-vacuous:
+>   passes with the seed on both profiles; with `/api/events` mocked to `[]` the title is absent
+>   (the assertion would fail). The old `'Nothing here'` check was empirically confirmed dead
+>   (count 0 even with zero events).
+> - **BL-02:** the reviewer's stated *mechanism* was inaccurate — the fetch window
+>   `[monthStart−7d, monthEnd+7d]` (verified in `calendarStore.initialCalendarRange`) **does** include
+>   `now+24h`, so the API window never excludes it. The real fragility is the rendered **month-agenda
+>   view of the current month** (both profiles are phone-width): on a month's last day "tomorrow" is in
+>   the next month and not displayed. The *conclusion* (a date-fragile visibility assertion) was correct.
+>   Fixed by re-anchoring the seed to **noon-today (UTC)** — always today's local date, always in the
+>   current-month view.
+
 ### BL-01: `calendar.spec.ts` populated-state assertions are vacuous — they cannot fail if the seed regresses
 
 **Files:**

.planning/phases/07-mobile-test-harness/07-VERIFICATION.md

@@ -105,9 +105,28 @@ These are carried from the code review as advisory only; none block the phase go
 
 ### Gaps Summary
 
-No gaps. All four success criteria are verified against the actual codebase and confirmed by live execution.
+No gaps against the four success criteria — all verified against the actual codebase and confirmed by live execution.
+
+---
+
+## Post-verification addendum (deep code review, 2026-06-11)
+
+A deep cross-file code review run *after* this verification found that two `calendar.spec.ts`
+"populated state" assertions were **vacuous** — they targeted `CalendarShell`'s `EmptyState`
+(dead code, never rendered) and the always-rendered Schedule-X wrapper, so they could not have
+failed if the seed regressed. This did **not** invalidate the four success criteria (SC-1's
+layout/tap-target coverage is `layout.spec.ts`, which carries its own injected-defect
+self-validation and remains sound), but it was a real coverage gap in the calendar
+populated-state tests.
+
+Resolved in commit `53c3ca5`: replaced with a genuine DB→UI proof (`getByText('Seeded Test
+Event')` visible in the grid), verified non-vacuous (passes with the seed on both profiles; with
+`/api/events` mocked to `[]` the title is absent, so the assertion would fail), and re-anchored
+the seed to noon-today so it sits deterministically inside the rendered current-month view. Full
+58-test suite passes on both profiles. See `07-REVIEW.md` BL-01/BL-02.
 
 ---
 
 _Verified: 2026-06-11T02:30:00Z_
 _Verifier: Claude (gsd-verifier)_
+_Addendum: 2026-06-11 — deep review BL-01/BL-02 resolved (commit 53c3ca5)_