fix(notifications): sync daily verse push with homepage VOTD + enable tap-to-verse

[CraigBuckmaster]

Problem

Bug #1 — Push notification VOTD doesn't match homepage VOTD.
The two code paths were completely independent:

• Homepage (useHomeData.ts) → holiday override first, else deterministic pick from a curated 31-verse NIV FEATURED_VERSES list by day-of-year.
• Notification (notifications.ts) → SELECT * FROM verses WHERE translation='kjv' ORDER BY RANDOM() LIMIT 1. Random. KJV. Unrelated.

Compounded by an iOS quirk: scheduled local notifications freeze their content at schedule time, so the old DAILY trigger fired the same random verse every morning forever until something rescheduled it.

Bug #2 — Tapping the notification didn't take you to the verse.
Two missing pieces:

1. No tap handler at all — no addNotificationResponseReceivedListener anywhere in the codebase. Tapping just opened the app to the last state.
2. Notification payload only carried { bookId, chapterNum } — no verseNum — so even if a handler existed, it couldn't route to a verse.

Bug #3 (bonus, discovered while investigating #2) — Scroll-to-verse had a silent layout race.
useChapterScroll.ts had the intent, but the effect ran when isLoading flipped to false — before onLayout callbacks populated verseYMap. Ref writes don't trigger re-renders, so the effect never retried. Net result: the deep-link verseNum parameter was effectively ignored on cold loads.

Architecture

File	Change
app/src/utils/verseOfDay.ts (new)	Single source of truth. Exports getVerseForDate(date), getVerseOfDay(), getHolidayForDate(), getEncouragementForDate(), FEATURED_VERSES. Pure module — no DB/platform deps.
app/src/hooks/useHomeData.ts	Refactored to consume the shared module. Homepage behaviour unchanged.
app/src/services/notifications.ts	Rewritten. Pre-schedules a rolling 60-day window of CALENDAR-triggered notifications, each with the correct verse for its date baked in (matches the homepage algorithm exactly). Uses scoped identifiers votd-YYYY-MM-DD so cancellation no longer nukes the reengagement-nudge slot. Payload now includes verseNum. New rescheduleIfStale() is idempotent and no-ops unless the last schedule was on a different calendar day.
app/src/hooks/useNotificationRouter.ts (new)	Handles both cold-start taps (via getLastNotificationResponseAsync) and warm taps (via addNotificationResponseReceivedListener). Polls navRef.isReady() for up to 5s on cold start. Routes to HomeTab → Chapter with { bookId, chapterNum, verseNum }.
app/App.tsx	Added navigationRef, mounted useNotificationRouter in AppShell, wired rescheduleIfStale() into the foreground AppState handler.
app/src/hooks/chapter/useChapterScroll.ts	Fixed the layout race. Scroll is now a pending intent that gets flushed from both handleVerseLayout and handleSectionLayout — whichever completes the picture second triggers the scroll. Requires both section-y and verse-y to be known before flushing, guarding against the nested-onLayout-ordering edge case. Kept the effect-based fast-path for cached-chapter re-entry.

Why pre-schedule a rolling window?

iOS caps scheduled local notifications at 64 per app and freezes their content at schedule time. A single DAILY trigger cannot show a different verse each day without a backend push. Pre-scheduling 60 calendar-day-specific notifications:

• Matches the homepage's deterministic verse per day exactly
• Works fully offline
• Leaves headroom (4 slots) for reengagement + any future scheduled features
• Is refreshed opportunistically on app foreground (stale check: once per day at most)
• Is scoped-cancellable so it doesn't interact with reengagement

Testing done

• Syntax-parse check passes on all 6 files.
• rescheduleIfStale() guards ensure it's cheap on steady state.
• Scope-scoped cancellation (votd-* prefix) coexists with reengagement-nudge.
• Tap payload narrowing is defensive — unknown shapes are ignored, not crashed on.

Testing needed (manual, on device)

• Schedule a daily verse for ~2 minutes in the future, verify the verse matches the homepage VOTD for that day
• Tap the notification cold — app should cold-start into the correct chapter + scroll to the correct verse
• Tap the notification warm (app in background) — app should navigate + scroll
• Verify reengagement notification still fires after 3 days of inactivity (scope-scoped cancellation didn't break it)
• Open a chapter via any in-app verse reference — scroll should land on the referenced verse reliably (fixes the layout race for general deep links too)

Tier-2 accuracy impact

None — no content files touched.

[github-actions]

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3209	❌ 0	3209
Suites	✅ 429	❌ 0	429

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 82.2s

[CraigBuckmaster]

Problem

Bug #1 — Push notification VOTD doesn't match homepage VOTD.
The two code paths were completely independent:

• Homepage (useHomeData.ts) → holiday override first, else deterministic pick from a curated 31-verse NIV FEATURED_VERSES list by day-of-year.
• Notification (notifications.ts) → SELECT * FROM verses WHERE translation='kjv' ORDER BY RANDOM() LIMIT 1. Random. KJV. Unrelated.

Compounded by an iOS quirk: scheduled local notifications freeze their content at schedule time, so the old DAILY trigger fired the same random verse every morning forever until something rescheduled it.

Bug #2 — Tapping the notification didn't take you to the verse.
Two missing pieces:

1. No tap handler at all — no addNotificationResponseReceivedListener anywhere in the codebase. Tapping just opened the app to the last state.
2. Notification payload only carried { bookId, chapterNum } — no verseNum — so even if a handler existed, it couldn't route to a verse.

Bug #3 (bonus, discovered while investigating #2) — Scroll-to-verse had a silent layout race.
useChapterScroll.ts had the intent, but the effect ran when isLoading flipped to false — before onLayout callbacks populated verseYMap. Ref writes don't trigger re-renders, so the effect never retried. Net result: the deep-link verseNum parameter was effectively ignored on cold loads.

Architecture

File	Change
app/src/utils/verseOfDay.ts (new)	Single source of truth. Exports getVerseForDate(date), getVerseOfDay(), getHolidayForDate(), getEncouragementForDate(), FEATURED_VERSES. Pure module — no DB/platform deps.
app/src/hooks/useHomeData.ts	Refactored to consume the shared module. Homepage behaviour unchanged.
app/src/services/notifications.ts	Rewritten. Pre-schedules a rolling 60-day window of CALENDAR-triggered notifications, each with the correct verse for its date baked in (matches the homepage algorithm exactly). Uses scoped identifiers votd-YYYY-MM-DD so cancellation no longer nukes the reengagement-nudge slot. Payload now includes verseNum. New rescheduleIfStale() is idempotent and no-ops unless the last schedule was on a different calendar day.
app/src/hooks/useNotificationRouter.ts (new)	Handles both cold-start taps (via getLastNotificationResponseAsync) and warm taps (via addNotificationResponseReceivedListener). Polls navRef.isReady() for up to 5s on cold start. Routes to HomeTab → Chapter with { bookId, chapterNum, verseNum }.
app/App.tsx	Added navigationRef, mounted useNotificationRouter in AppShell, wired rescheduleIfStale() into the foreground AppState handler.
app/src/hooks/chapter/useChapterScroll.ts	Fixed the layout race. Scroll is now a pending intent that gets flushed from both handleVerseLayout and handleSectionLayout — whichever completes the picture second triggers the scroll. Requires both section-y and verse-y to be known before flushing, guarding against the nested-onLayout-ordering edge case. Kept the effect-based fast-path for cached-chapter re-entry.

Why pre-schedule a rolling window?

iOS caps scheduled local notifications at 64 per app and freezes their content at schedule time. A single DAILY trigger cannot show a different verse each day without a backend push. Pre-scheduling 60 calendar-day-specific notifications:

• Matches the homepage's deterministic verse per day exactly
• Works fully offline
• Leaves headroom (4 slots) for reengagement + any future scheduled features
• Is refreshed opportunistically on app foreground (stale check: once per day at most)
• Is scoped-cancellable so it doesn't interact with reengagement

Testing done

• Syntax-parse check passes on all 6 files.
• rescheduleIfStale() guards ensure it's cheap on steady state.
• Scope-scoped cancellation (votd-* prefix) coexists with reengagement-nudge.
• Tap payload narrowing is defensive — unknown shapes are ignored, not crashed on.

Testing needed (manual, on device)

• Schedule a daily verse for ~2 minutes in the future, verify the verse matches the homepage VOTD for that day
• Tap the notification cold — app should cold-start into the correct chapter + scroll to the correct verse
• Tap the notification warm (app in background) — app should navigate + scroll
• Verify reengagement notification still fires after 3 days of inactivity (scope-scoped cancellation didn't break it)
• Open a chapter via any in-app verse reference — scroll should land on the referenced verse reliably (fixes the layout race for general deep links too)

Tier-2 accuracy impact

None — no content files touched.

[github-actions]

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3209	❌ 0	3209
Suites	✅ 429	❌ 0	429

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 82.2s

[CraigBuckmaster]

Problem

Bug #1 — Push notification VOTD doesn't match homepage VOTD.
The two code paths were completely independent:

• Homepage (useHomeData.ts) → holiday override first, else deterministic pick from a curated 31-verse NIV FEATURED_VERSES list by day-of-year.
• Notification (notifications.ts) → SELECT * FROM verses WHERE translation='kjv' ORDER BY RANDOM() LIMIT 1. Random. KJV. Unrelated.

Compounded by an iOS quirk: scheduled local notifications freeze their content at schedule time, so the old DAILY trigger fired the same random verse every morning forever until something rescheduled it.

Bug #2 — Tapping the notification didn't take you to the verse.
Two missing pieces:

1. No tap handler at all — no addNotificationResponseReceivedListener anywhere in the codebase. Tapping just opened the app to the last state.
2. Notification payload only carried { bookId, chapterNum } — no verseNum — so even if a handler existed, it couldn't route to a verse.

Bug #3 (bonus, discovered while investigating #2) — Scroll-to-verse had a silent layout race.
useChapterScroll.ts had the intent, but the effect ran when isLoading flipped to false — before onLayout callbacks populated verseYMap. Ref writes don't trigger re-renders, so the effect never retried. Net result: the deep-link verseNum parameter was effectively ignored on cold loads.

Architecture

File	Change
app/src/utils/verseOfDay.ts (new)	Single source of truth. Exports getVerseForDate(date), getVerseOfDay(), getHolidayForDate(), getEncouragementForDate(), FEATURED_VERSES. Pure module — no DB/platform deps.
app/src/hooks/useHomeData.ts	Refactored to consume the shared module. Homepage behaviour unchanged.
app/src/services/notifications.ts	Rewritten. Pre-schedules a rolling 60-day window of CALENDAR-triggered notifications, each with the correct verse for its date baked in (matches the homepage algorithm exactly). Uses scoped identifiers votd-YYYY-MM-DD so cancellation no longer nukes the reengagement-nudge slot. Payload now includes verseNum. New rescheduleIfStale() is idempotent and no-ops unless the last schedule was on a different calendar day.
app/src/hooks/useNotificationRouter.ts (new)	Handles both cold-start taps (via getLastNotificationResponseAsync) and warm taps (via addNotificationResponseReceivedListener). Polls navRef.isReady() for up to 5s on cold start. Routes to HomeTab → Chapter with { bookId, chapterNum, verseNum }.
app/App.tsx	Added navigationRef, mounted useNotificationRouter in AppShell, wired rescheduleIfStale() into the foreground AppState handler.
app/src/hooks/chapter/useChapterScroll.ts	Fixed the layout race. Scroll is now a pending intent that gets flushed from both handleVerseLayout and handleSectionLayout — whichever completes the picture second triggers the scroll. Requires both section-y and verse-y to be known before flushing, guarding against the nested-onLayout-ordering edge case. Kept the effect-based fast-path for cached-chapter re-entry.

Why pre-schedule a rolling window?

iOS caps scheduled local notifications at 64 per app and freezes their content at schedule time. A single DAILY trigger cannot show a different verse each day without a backend push. Pre-scheduling 60 calendar-day-specific notifications:

• Matches the homepage's deterministic verse per day exactly
• Works fully offline
• Leaves headroom (4 slots) for reengagement + any future scheduled features
• Is refreshed opportunistically on app foreground (stale check: once per day at most)
• Is scoped-cancellable so it doesn't interact with reengagement

Testing done

• Syntax-parse check passes on all 6 files.
• rescheduleIfStale() guards ensure it's cheap on steady state.
• Scope-scoped cancellation (votd-* prefix) coexists with reengagement-nudge.
• Tap payload narrowing is defensive — unknown shapes are ignored, not crashed on.

Testing needed (manual, on device)

• Schedule a daily verse for ~2 minutes in the future, verify the verse matches the homepage VOTD for that day
• Tap the notification cold — app should cold-start into the correct chapter + scroll to the correct verse
• Tap the notification warm (app in background) — app should navigate + scroll
• Verify reengagement notification still fires after 3 days of inactivity (scope-scoped cancellation didn't break it)
• Open a chapter via any in-app verse reference — scroll should land on the referenced verse reliably (fixes the layout race for general deep links too)

Tier-2 accuracy impact

None — no content files touched.

[github-actions]

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3209	❌ 0	3209
Suites	✅ 429	❌ 0	429

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 82.2s

[CraigBuckmaster]

Problem

Bug #1 — Push notification VOTD doesn't match homepage VOTD.
The two code paths were completely independent:

• Homepage (useHomeData.ts) → holiday override first, else deterministic pick from a curated 31-verse NIV FEATURED_VERSES list by day-of-year.
• Notification (notifications.ts) → SELECT * FROM verses WHERE translation='kjv' ORDER BY RANDOM() LIMIT 1. Random. KJV. Unrelated.

Compounded by an iOS quirk: scheduled local notifications freeze their content at schedule time, so the old DAILY trigger fired the same random verse every morning forever until something rescheduled it.

Bug #2 — Tapping the notification didn't take you to the verse.
Two missing pieces:

1. No tap handler at all — no addNotificationResponseReceivedListener anywhere in the codebase. Tapping just opened the app to the last state.
2. Notification payload only carried { bookId, chapterNum } — no verseNum — so even if a handler existed, it couldn't route to a verse.

Bug #3 (bonus, discovered while investigating #2) — Scroll-to-verse had a silent layout race.
useChapterScroll.ts had the intent, but the effect ran when isLoading flipped to false — before onLayout callbacks populated verseYMap. Ref writes don't trigger re-renders, so the effect never retried. Net result: the deep-link verseNum parameter was effectively ignored on cold loads.

Architecture

File	Change
app/src/utils/verseOfDay.ts (new)	Single source of truth. Exports getVerseForDate(date), getVerseOfDay(), getHolidayForDate(), getEncouragementForDate(), FEATURED_VERSES. Pure module — no DB/platform deps.
app/src/hooks/useHomeData.ts	Refactored to consume the shared module. Homepage behaviour unchanged.
app/src/services/notifications.ts	Rewritten. Pre-schedules a rolling 60-day window of CALENDAR-triggered notifications, each with the correct verse for its date baked in (matches the homepage algorithm exactly). Uses scoped identifiers votd-YYYY-MM-DD so cancellation no longer nukes the reengagement-nudge slot. Payload now includes verseNum. New rescheduleIfStale() is idempotent and no-ops unless the last schedule was on a different calendar day.
app/src/hooks/useNotificationRouter.ts (new)	Handles both cold-start taps (via getLastNotificationResponseAsync) and warm taps (via addNotificationResponseReceivedListener). Polls navRef.isReady() for up to 5s on cold start. Routes to HomeTab → Chapter with { bookId, chapterNum, verseNum }.
app/App.tsx	Added navigationRef, mounted useNotificationRouter in AppShell, wired rescheduleIfStale() into the foreground AppState handler.
app/src/hooks/chapter/useChapterScroll.ts	Fixed the layout race. Scroll is now a pending intent that gets flushed from both handleVerseLayout and handleSectionLayout — whichever completes the picture second triggers the scroll. Requires both section-y and verse-y to be known before flushing, guarding against the nested-onLayout-ordering edge case. Kept the effect-based fast-path for cached-chapter re-entry.

Why pre-schedule a rolling window?

iOS caps scheduled local notifications at 64 per app and freezes their content at schedule time. A single DAILY trigger cannot show a different verse each day without a backend push. Pre-scheduling 60 calendar-day-specific notifications:

• Matches the homepage's deterministic verse per day exactly
• Works fully offline
• Leaves headroom (4 slots) for reengagement + any future scheduled features
• Is refreshed opportunistically on app foreground (stale check: once per day at most)
• Is scoped-cancellable so it doesn't interact with reengagement

Testing done

• Syntax-parse check passes on all 6 files.
• rescheduleIfStale() guards ensure it's cheap on steady state.
• Scope-scoped cancellation (votd-* prefix) coexists with reengagement-nudge.
• Tap payload narrowing is defensive — unknown shapes are ignored, not crashed on.

Testing needed (manual, on device)

• Schedule a daily verse for ~2 minutes in the future, verify the verse matches the homepage VOTD for that day
• Tap the notification cold — app should cold-start into the correct chapter + scroll to the correct verse
• Tap the notification warm (app in background) — app should navigate + scroll
• Verify reengagement notification still fires after 3 days of inactivity (scope-scoped cancellation didn't break it)
• Open a chapter via any in-app verse reference — scroll should land on the referenced verse reliably (fixes the layout race for general deep links too)

Tier-2 accuracy impact

None — no content files touched.

[github-actions]

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3209	❌ 0	3209
Suites	✅ 429	❌ 0	429

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 82.2s

[CraigBuckmaster]

Problem

Bug #1 — Push notification VOTD doesn't match homepage VOTD.
The two code paths were completely independent:

• Homepage (useHomeData.ts) → holiday override first, else deterministic pick from a curated 31-verse NIV FEATURED_VERSES list by day-of-year.
• Notification (notifications.ts) → SELECT * FROM verses WHERE translation='kjv' ORDER BY RANDOM() LIMIT 1. Random. KJV. Unrelated.

Compounded by an iOS quirk: scheduled local notifications freeze their content at schedule time, so the old DAILY trigger fired the same random verse every morning forever until something rescheduled it.

Bug #2 — Tapping the notification didn't take you to the verse.
Two missing pieces:

1. No tap handler at all — no addNotificationResponseReceivedListener anywhere in the codebase. Tapping just opened the app to the last state.
2. Notification payload only carried { bookId, chapterNum } — no verseNum — so even if a handler existed, it couldn't route to a verse.

Bug #3 (bonus, discovered while investigating #2) — Scroll-to-verse had a silent layout race.
useChapterScroll.ts had the intent, but the effect ran when isLoading flipped to false — before onLayout callbacks populated verseYMap. Ref writes don't trigger re-renders, so the effect never retried. Net result: the deep-link verseNum parameter was effectively ignored on cold loads.

Architecture

File	Change
app/src/utils/verseOfDay.ts (new)	Single source of truth. Exports getVerseForDate(date), getVerseOfDay(), getHolidayForDate(), getEncouragementForDate(), FEATURED_VERSES. Pure module — no DB/platform deps.
app/src/hooks/useHomeData.ts	Refactored to consume the shared module. Homepage behaviour unchanged.
app/src/services/notifications.ts	Rewritten. Pre-schedules a rolling 60-day window of CALENDAR-triggered notifications, each with the correct verse for its date baked in (matches the homepage algorithm exactly). Uses scoped identifiers votd-YYYY-MM-DD so cancellation no longer nukes the reengagement-nudge slot. Payload now includes verseNum. New rescheduleIfStale() is idempotent and no-ops unless the last schedule was on a different calendar day.
app/src/hooks/useNotificationRouter.ts (new)	Handles both cold-start taps (via getLastNotificationResponseAsync) and warm taps (via addNotificationResponseReceivedListener). Polls navRef.isReady() for up to 5s on cold start. Routes to HomeTab → Chapter with { bookId, chapterNum, verseNum }.
app/App.tsx	Added navigationRef, mounted useNotificationRouter in AppShell, wired rescheduleIfStale() into the foreground AppState handler.
app/src/hooks/chapter/useChapterScroll.ts	Fixed the layout race. Scroll is now a pending intent that gets flushed from both handleVerseLayout and handleSectionLayout — whichever completes the picture second triggers the scroll. Requires both section-y and verse-y to be known before flushing, guarding against the nested-onLayout-ordering edge case. Kept the effect-based fast-path for cached-chapter re-entry.

Why pre-schedule a rolling window?

iOS caps scheduled local notifications at 64 per app and freezes their content at schedule time. A single DAILY trigger cannot show a different verse each day without a backend push. Pre-scheduling 60 calendar-day-specific notifications:

• Matches the homepage's deterministic verse per day exactly
• Works fully offline
• Leaves headroom (4 slots) for reengagement + any future scheduled features
• Is refreshed opportunistically on app foreground (stale check: once per day at most)
• Is scoped-cancellable so it doesn't interact with reengagement

Testing done

• Syntax-parse check passes on all 6 files.
• rescheduleIfStale() guards ensure it's cheap on steady state.
• Scope-scoped cancellation (votd-* prefix) coexists with reengagement-nudge.
• Tap payload narrowing is defensive — unknown shapes are ignored, not crashed on.

Testing needed (manual, on device)

• Schedule a daily verse for ~2 minutes in the future, verify the verse matches the homepage VOTD for that day
• Tap the notification cold — app should cold-start into the correct chapter + scroll to the correct verse
• Tap the notification warm (app in background) — app should navigate + scroll
• Verify reengagement notification still fires after 3 days of inactivity (scope-scoped cancellation didn't break it)
• Open a chapter via any in-app verse reference — scroll should land on the referenced verse reliably (fixes the layout race for general deep links too)

Tier-2 accuracy impact

None — no content files touched.

[github-actions]

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3209	❌ 0	3209
Suites	✅ 429	❌ 0	429

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 82.2s

[CraigBuckmaster]

Problem

Bug #1 — Push notification VOTD doesn't match homepage VOTD.
The two code paths were completely independent:

• Homepage (useHomeData.ts) → holiday override first, else deterministic pick from a curated 31-verse NIV FEATURED_VERSES list by day-of-year.
• Notification (notifications.ts) → SELECT * FROM verses WHERE translation='kjv' ORDER BY RANDOM() LIMIT 1. Random. KJV. Unrelated.

Compounded by an iOS quirk: scheduled local notifications freeze their content at schedule time, so the old DAILY trigger fired the same random verse every morning forever until something rescheduled it.

Bug #2 — Tapping the notification didn't take you to the verse.
Two missing pieces:

1. No tap handler at all — no addNotificationResponseReceivedListener anywhere in the codebase. Tapping just opened the app to the last state.
2. Notification payload only carried { bookId, chapterNum } — no verseNum — so even if a handler existed, it couldn't route to a verse.

Bug #3 (bonus, discovered while investigating #2) — Scroll-to-verse had a silent layout race.
useChapterScroll.ts had the intent, but the effect ran when isLoading flipped to false — before onLayout callbacks populated verseYMap. Ref writes don't trigger re-renders, so the effect never retried. Net result: the deep-link verseNum parameter was effectively ignored on cold loads.

Architecture

File	Change
app/src/utils/verseOfDay.ts (new)	Single source of truth. Exports getVerseForDate(date), getVerseOfDay(), getHolidayForDate(), getEncouragementForDate(), FEATURED_VERSES. Pure module — no DB/platform deps.
app/src/hooks/useHomeData.ts	Refactored to consume the shared module. Homepage behaviour unchanged.
app/src/services/notifications.ts	Rewritten. Pre-schedules a rolling 60-day window of CALENDAR-triggered notifications, each with the correct verse for its date baked in (matches the homepage algorithm exactly). Uses scoped identifiers votd-YYYY-MM-DD so cancellation no longer nukes the reengagement-nudge slot. Payload now includes verseNum. New rescheduleIfStale() is idempotent and no-ops unless the last schedule was on a different calendar day.
app/src/hooks/useNotificationRouter.ts (new)	Handles both cold-start taps (via getLastNotificationResponseAsync) and warm taps (via addNotificationResponseReceivedListener). Polls navRef.isReady() for up to 5s on cold start. Routes to HomeTab → Chapter with { bookId, chapterNum, verseNum }.
app/App.tsx	Added navigationRef, mounted useNotificationRouter in AppShell, wired rescheduleIfStale() into the foreground AppState handler.
app/src/hooks/chapter/useChapterScroll.ts	Fixed the layout race. Scroll is now a pending intent that gets flushed from both handleVerseLayout and handleSectionLayout — whichever completes the picture second triggers the scroll. Requires both section-y and verse-y to be known before flushing, guarding against the nested-onLayout-ordering edge case. Kept the effect-based fast-path for cached-chapter re-entry.

Why pre-schedule a rolling window?

iOS caps scheduled local notifications at 64 per app and freezes their content at schedule time. A single DAILY trigger cannot show a different verse each day without a backend push. Pre-scheduling 60 calendar-day-specific notifications:

• Matches the homepage's deterministic verse per day exactly
• Works fully offline
• Leaves headroom (4 slots) for reengagement + any future scheduled features
• Is refreshed opportunistically on app foreground (stale check: once per day at most)
• Is scoped-cancellable so it doesn't interact with reengagement

Testing done

• Syntax-parse check passes on all 6 files.
• rescheduleIfStale() guards ensure it's cheap on steady state.
• Scope-scoped cancellation (votd-* prefix) coexists with reengagement-nudge.
• Tap payload narrowing is defensive — unknown shapes are ignored, not crashed on.

Testing needed (manual, on device)

• Schedule a daily verse for ~2 minutes in the future, verify the verse matches the homepage VOTD for that day
• Tap the notification cold — app should cold-start into the correct chapter + scroll to the correct verse
• Tap the notification warm (app in background) — app should navigate + scroll
• Verify reengagement notification still fires after 3 days of inactivity (scope-scoped cancellation didn't break it)
• Open a chapter via any in-app verse reference — scroll should land on the referenced verse reliably (fixes the layout race for general deep links too)

Tier-2 accuracy impact

None — no content files touched.

[github-actions]

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3209	❌ 0	3209
Suites	✅ 429	❌ 0	429

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 82.2s

[CraigBuckmaster]

Problem

Bug #1 — Push notification VOTD doesn't match homepage VOTD.
The two code paths were completely independent:

• Homepage (useHomeData.ts) → holiday override first, else deterministic pick from a curated 31-verse NIV FEATURED_VERSES list by day-of-year.
• Notification (notifications.ts) → SELECT * FROM verses WHERE translation='kjv' ORDER BY RANDOM() LIMIT 1. Random. KJV. Unrelated.

Compounded by an iOS quirk: scheduled local notifications freeze their content at schedule time, so the old DAILY trigger fired the same random verse every morning forever until something rescheduled it.

Bug #2 — Tapping the notification didn't take you to the verse.
Two missing pieces:

1. No tap handler at all — no addNotificationResponseReceivedListener anywhere in the codebase. Tapping just opened the app to the last state.
2. Notification payload only carried { bookId, chapterNum } — no verseNum — so even if a handler existed, it couldn't route to a verse.

Bug #3 (bonus, discovered while investigating #2) — Scroll-to-verse had a silent layout race.
useChapterScroll.ts had the intent, but the effect ran when isLoading flipped to false — before onLayout callbacks populated verseYMap. Ref writes don't trigger re-renders, so the effect never retried. Net result: the deep-link verseNum parameter was effectively ignored on cold loads.

Architecture

File	Change
app/src/utils/verseOfDay.ts (new)	Single source of truth. Exports getVerseForDate(date), getVerseOfDay(), getHolidayForDate(), getEncouragementForDate(), FEATURED_VERSES. Pure module — no DB/platform deps.
app/src/hooks/useHomeData.ts	Refactored to consume the shared module. Homepage behaviour unchanged.
app/src/services/notifications.ts	Rewritten. Pre-schedules a rolling 60-day window of CALENDAR-triggered notifications, each with the correct verse for its date baked in (matches the homepage algorithm exactly). Uses scoped identifiers votd-YYYY-MM-DD so cancellation no longer nukes the reengagement-nudge slot. Payload now includes verseNum. New rescheduleIfStale() is idempotent and no-ops unless the last schedule was on a different calendar day.
app/src/hooks/useNotificationRouter.ts (new)	Handles both cold-start taps (via getLastNotificationResponseAsync) and warm taps (via addNotificationResponseReceivedListener). Polls navRef.isReady() for up to 5s on cold start. Routes to HomeTab → Chapter with { bookId, chapterNum, verseNum }.
app/App.tsx	Added navigationRef, mounted useNotificationRouter in AppShell, wired rescheduleIfStale() into the foreground AppState handler.
app/src/hooks/chapter/useChapterScroll.ts	Fixed the layout race. Scroll is now a pending intent that gets flushed from both handleVerseLayout and handleSectionLayout — whichever completes the picture second triggers the scroll. Requires both section-y and verse-y to be known before flushing, guarding against the nested-onLayout-ordering edge case. Kept the effect-based fast-path for cached-chapter re-entry.

Why pre-schedule a rolling window?

iOS caps scheduled local notifications at 64 per app and freezes their content at schedule time. A single DAILY trigger cannot show a different verse each day without a backend push. Pre-scheduling 60 calendar-day-specific notifications:

• Matches the homepage's deterministic verse per day exactly
• Works fully offline
• Leaves headroom (4 slots) for reengagement + any future scheduled features
• Is refreshed opportunistically on app foreground (stale check: once per day at most)
• Is scoped-cancellable so it doesn't interact with reengagement

Testing done

• Syntax-parse check passes on all 6 files.
• rescheduleIfStale() guards ensure it's cheap on steady state.
• Scope-scoped cancellation (votd-* prefix) coexists with reengagement-nudge.
• Tap payload narrowing is defensive — unknown shapes are ignored, not crashed on.

Testing needed (manual, on device)

• Schedule a daily verse for ~2 minutes in the future, verify the verse matches the homepage VOTD for that day
• Tap the notification cold — app should cold-start into the correct chapter + scroll to the correct verse
• Tap the notification warm (app in background) — app should navigate + scroll
• Verify reengagement notification still fires after 3 days of inactivity (scope-scoped cancellation didn't break it)
• Open a chapter via any in-app verse reference — scroll should land on the referenced verse reliably (fixes the layout race for general deep links too)

Tier-2 accuracy impact

None — no content files touched.

[github-actions]

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3209	❌ 0	3209
Suites	✅ 429	❌ 0	429

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 82.2s

[CraigBuckmaster]

Problem

Bug #1 — Push notification VOTD doesn't match homepage VOTD.
The two code paths were completely independent:

• Homepage (useHomeData.ts) → holiday override first, else deterministic pick from a curated 31-verse NIV FEATURED_VERSES list by day-of-year.
• Notification (notifications.ts) → SELECT * FROM verses WHERE translation='kjv' ORDER BY RANDOM() LIMIT 1. Random. KJV. Unrelated.

Compounded by an iOS quirk: scheduled local notifications freeze their content at schedule time, so the old DAILY trigger fired the same random verse every morning forever until something rescheduled it.

Bug #2 — Tapping the notification didn't take you to the verse.
Two missing pieces:

1. No tap handler at all — no addNotificationResponseReceivedListener anywhere in the codebase. Tapping just opened the app to the last state.
2. Notification payload only carried { bookId, chapterNum } — no verseNum — so even if a handler existed, it couldn't route to a verse.

Bug #3 (bonus, discovered while investigating #2) — Scroll-to-verse had a silent layout race.
useChapterScroll.ts had the intent, but the effect ran when isLoading flipped to false — before onLayout callbacks populated verseYMap. Ref writes don't trigger re-renders, so the effect never retried. Net result: the deep-link verseNum parameter was effectively ignored on cold loads.

Architecture

File	Change
app/src/utils/verseOfDay.ts (new)	Single source of truth. Exports getVerseForDate(date), getVerseOfDay(), getHolidayForDate(), getEncouragementForDate(), FEATURED_VERSES. Pure module — no DB/platform deps.
app/src/hooks/useHomeData.ts	Refactored to consume the shared module. Homepage behaviour unchanged.
app/src/services/notifications.ts	Rewritten. Pre-schedules a rolling 60-day window of CALENDAR-triggered notifications, each with the correct verse for its date baked in (matches the homepage algorithm exactly). Uses scoped identifiers votd-YYYY-MM-DD so cancellation no longer nukes the reengagement-nudge slot. Payload now includes verseNum. New rescheduleIfStale() is idempotent and no-ops unless the last schedule was on a different calendar day.
app/src/hooks/useNotificationRouter.ts (new)	Handles both cold-start taps (via getLastNotificationResponseAsync) and warm taps (via addNotificationResponseReceivedListener). Polls navRef.isReady() for up to 5s on cold start. Routes to HomeTab → Chapter with { bookId, chapterNum, verseNum }.
app/App.tsx	Added navigationRef, mounted useNotificationRouter in AppShell, wired rescheduleIfStale() into the foreground AppState handler.
app/src/hooks/chapter/useChapterScroll.ts	Fixed the layout race. Scroll is now a pending intent that gets flushed from both handleVerseLayout and handleSectionLayout — whichever completes the picture second triggers the scroll. Requires both section-y and verse-y to be known before flushing, guarding against the nested-onLayout-ordering edge case. Kept the effect-based fast-path for cached-chapter re-entry.

Why pre-schedule a rolling window?

iOS caps scheduled local notifications at 64 per app and freezes their content at schedule time. A single DAILY trigger cannot show a different verse each day without a backend push. Pre-scheduling 60 calendar-day-specific notifications:

• Matches the homepage's deterministic verse per day exactly
• Works fully offline
• Leaves headroom (4 slots) for reengagement + any future scheduled features
• Is refreshed opportunistically on app foreground (stale check: once per day at most)
• Is scoped-cancellable so it doesn't interact with reengagement

Testing done

• Syntax-parse check passes on all 6 files.
• rescheduleIfStale() guards ensure it's cheap on steady state.
• Scope-scoped cancellation (votd-* prefix) coexists with reengagement-nudge.
• Tap payload narrowing is defensive — unknown shapes are ignored, not crashed on.

Testing needed (manual, on device)

• Schedule a daily verse for ~2 minutes in the future, verify the verse matches the homepage VOTD for that day
• Tap the notification cold — app should cold-start into the correct chapter + scroll to the correct verse
• Tap the notification warm (app in background) — app should navigate + scroll
• Verify reengagement notification still fires after 3 days of inactivity (scope-scoped cancellation didn't break it)
• Open a chapter via any in-app verse reference — scroll should land on the referenced verse reliably (fixes the layout race for general deep links too)

Tier-2 accuracy impact

None — no content files touched.

[github-actions]

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3209	❌ 0	3209
Suites	✅ 429	❌ 0	429

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 82.2s