03 — User Journeys (Notifications Module)

• J1 — New User Onboarding (Welcome + Verification)
• J2 — Resend Verification Email
• J3 — Password Reset Completed
• J4 — Unread Inbox Visit (Daily Loop)
• J5 — Empty State
• Planned Journeys (not implemented)

All journeys are grounded in the implemented flow: event → EventBus → NotificationsHandler → persistence → authenticated API (notifications.handler.ts:61-99).

J1 — New User Onboarding (Welcome + Verification)

1. UserRegistered fires on signup.
2. Handler maps to WELCOME (notifications.handler.ts:41-49), body interpolates firstName from payload (handler.ts:44-47), recipient = payload.userId.
3. User opens the app → bell badge shows 1 unread → inbox lists "Welcome to StudyLyon".
4. User verifies email → EmailVerified → badge 2 ("Email Verified", handler.ts:16-20).

Exit states: badge increments, list stays newest-first, tapping marks read.

J2 — Resend Verification Email

1. User requests resend → EmailVerificationResent (handler.ts:21-25).
2. Notification "Verification Email Sent" is created; user knows an email is coming without leaving the app.

J3 — Password Reset Completed

1. Reset flow finishes → PasswordResetCompleted → "Password Reset" (handler.ts:26-30).
2. Notification acts as confirmation + implicit security signal (someone reset it).

J4 — Unread Inbox Visit (Daily Loop)

1. Badge shows n unread (GET /api/v1/notifications/unread-count).
2. User opens /notifications → GET /api/v1/notifications?page=1&limit=20 → { data, meta } (notifications.service.ts:39-52).
3. Tap item → PATCH /api/v1/notifications/:id/read → badge decrements.
4. Scroll → infinite pagination (meta.hasNext → next page, pagination-query.dto.ts:32-39).
5. Optional "Mark all read" → PATCH /api/v1/notifications/read-all → badge = 0.

J5 — Empty State

First-run user (or after mark-all): list renders empty state. No notifications are ever auto-deleted; an empty list is a state, not a flow — see 05_Screen_Inventory §3.

Planned Journeys (not implemented)

• J6 — Domain fan-out: homework created/submitted/graded, results published, student/teacher/staff/parent created — routed to the in-app queue in event-queue-map.ts:10,13,22-40 but no worker/handler consumes them — (planned), see 14_QA_Checklist §G.
• J7 — Push on mobile: test reminder push (coaching) — docs/IMPLEMENTATION_PLAN.md:859 — (forward-looking); device-token registration (future) — docs/user-flows/END_TO_END_USER_FLOWS.md:788.
• J8 — Announcements in inbox: AnnouncementPublished is emitted (announcement.service.ts:80-91) but not mapped in EVENT_TYPE_MAP — announcements keep their own read receipts (announcement.service.ts:95-102). No overlap today; decide in a later phase whether announcements fan into the inbox (see 14_QA_Checklist §E).