feat: notification service

TESTING.md

@@ -2,7 +2,7 @@
 
 ## Purpose
 
-This document defines the testing strategy for the [Galaxy Game](ARCHITECTURE.md) platform and provides a staged testing matrix aligned with the agreed service implementation order.
+This document defines the testing strategy for the [Galaxy Game](ARCHITECTURE.md) platform and provides an ordered testing matrix aligned with the agreed service implementation order.
 
 The strategy is built around the current architecture constraints:
 
@@ -199,7 +199,7 @@ The testing plan follows this service order:
   * later-event-wins behavior for session snapshots
   * subscriber shutdown interrupts blocking reads
 
-### Inter-service integration tests at this stage
+### Inter-service integration tests for this boundary
 
 * `Gateway <-> Redis`
 
@@ -218,7 +218,7 @@ The testing plan follows this service order:
   * verified authenticated command routing
   * signed response generation after downstream success
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * Authenticated request verification pipeline remains stable.
 * Public auth routes remain mounted and deterministic.
@@ -344,7 +344,7 @@ The testing plan follows this service order:
   * ensure-user compatibility for confirm
   * exists/block compatibility for internal revoke/block flows
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * `confirm-email-code` always returns a ready `device_session_id`.
 * Gateway continues authenticating from cache rather than synchronous auth lookups.
@@ -427,7 +427,7 @@ The testing plan follows this service order:
   * repeat login by same email without overwriting create-only settings
   * blocked email/user behavior
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * User resolution outcomes remain stable for auth flow.
 * User-facing profile APIs do not bypass auth/session rules.
@@ -476,7 +476,7 @@ The testing plan follows this service order:
 * Keep `Mail Service` stubbed in most broader suites.
 * Add only a small dedicated smoke suite for the real mail adapter.
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * Auth code mail remains a direct dependency of auth flow.
 * Mail failures do not corrupt auth challenge/session state.
@@ -488,11 +488,22 @@ The testing plan follows this service order:
 
 ### Service tests
 
-* Event intake tests:
+* Runtime-skeleton tests:
 
-  * accepted event types
+  * configuration loading and validation
+  * probe listener startup
+  * `GET /healthz`
+  * `GET /readyz`
+  * no `/metrics`
+  * Redis startup fast-fail
+  * graceful shutdown of the probe listener
+* Intent intake tests:
+
+  * accepted notification types
   * malformed event rejection
   * idempotent duplicate handling
+  * conflicting duplicate rejection
+  * AsyncAPI contract validation for `notification:intents`
 * Routing decision tests:
 
   * push only
@@ -501,9 +512,9 @@ The testing plan follows this service order:
   * discard/no-delivery cases
 * Rendering tests:
 
-  * event-to-notification mapping
-  * payload shaping for push
-  * payload shaping for email
+  * intent-to-route mapping
+  * FlatBuffers payload shaping for push
+  * template-variable shaping for email
 * Failure isolation tests:
 
   * push failure does not corrupt email route decision
@@ -511,7 +522,7 @@ The testing plan follows this service order:
   * retriable delivery behavior
 * Redis/event bus tests:
 
-  * consume domain/integration events
+  * consume normalized notification intents
   * publish client-facing events for gateway
   * enqueue mail commands for mail service
 
@@ -520,20 +531,49 @@ The testing plan follows this service order:
 * `Notification <-> Gateway`
 
   * client-facing event publication and push delivery
-  * user-targeted vs session-targeted push routing
+  * user-targeted fan-out without session-targeted routing
+  * all seven user-facing push types
+  * `notificationgateway` runs real `Notification Service`, real
+    `User Service`, real `Edge Gateway`, and real Redis
 * `Notification <-> Mail`
 
   * non-auth email delivery
   * retry/failure isolation
-* `Lobby/other fake producers <-> Notification`
+  * template-mode handoff for every notification email type, including both
+    user and administrator variants of `lobby.application.submitted`
+  * `notificationmail` runs real `Notification Service`, real `User Service`,
+    real `Mail Service`, and real Redis
+* `Notification <-> User`
 
-  * domain event intake compatibility
+  * successful recipient enrichment
+  * `recipient_not_found` for missing users
+  * no stream-offset advancement while `User Service` is temporarily unavailable
+  * `notificationuser` runs real `Notification Service`, real `User Service`,
+    and real Redis
+* `Gateway <-> Auth / Session <-> User <-> Mail`
+
+  * public registration through the real mail path
+  * user creation through `User Service`
+  * gateway session projection
+  * regression that auth-code email bypasses `notification:intents`
+  * `gatewayauthsessionusermail` runs real `Edge Gateway`, real
+    `Auth / Session Service`, real `User Service`, real `Mail Service`, and
+    real Redis
+* Producer contract compatibility
+
+  * notification-intent contract compatibility
+  * Game Master, Game Lobby, and Geo Profile Service stay covered by
+    `galaxy/notificationintent` until those real producer boundaries exist
 * Assert explicitly that auth-code emails still bypass notification and go directly from auth to mail.
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * Notification stays delivery/orchestration-only and does not become source of truth.
 * Non-auth notifications consistently go through notification service.
+* Producer-owned audience resolution remains stable: user-targeted producers
+  publish concrete recipient `user_id` values, while admin-only recipients
+  remain type-specific notification-service configuration.
+* Private-game invite notifications remain user-bound by internal `user_id`.
 * Gateway push compatibility remains stable.
 
 ---
@@ -560,10 +600,10 @@ The testing plan follows this service order:
   * visibility rules for private games
 * Invite lifecycle tests:
 
-  * invite code creation
-  * invite code redemption
+  * user-bound invite creation
+  * invite acceptance
   * invite approval/rejection
-  * invite expiration if applicable later
+  * invite expiration and revoke handling where applicable
 * Application and approval tests:
 
   * public game application
@@ -615,7 +655,7 @@ The testing plan follows this service order:
   * authenticated context correctly propagated from gateway
 * Keep runtime launch boundaries stubbed until `Runtime Manager` exists.
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * `Lobby` remains source of truth for platform game metadata and membership.
 * `Lobby` user-facing game lists remain independent from `Game Master`.
@@ -669,7 +709,7 @@ The testing plan follows this service order:
   * optional operational event routing if enabled
 * Use a fake or test runtime backend first, then a targeted smoke suite against a real local Docker backend.
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * Runtime Manager remains the only component talking to Docker API.
 * Runtime job event contracts remain stable for `Lobby` and later `Game Master`.
@@ -752,7 +792,7 @@ The testing plan follows this service order:
   * setup call
   * finish callback
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * `Game Master` remains the only service allowed to call game engine containers.
 * Turn cutoff logic stays authoritative at platform level.
@@ -805,7 +845,7 @@ The testing plan follows this service order:
 
   * admin-generated notifications where needed
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * Admin Service remains orchestration/backend only.
 * System admin capabilities remain separate from private-owner capabilities.
@@ -872,7 +912,7 @@ The testing plan follows this service order:
   * optional admin notification flow
 * Keep geo processing fail-open relative to gameplay in all integration tests.
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * Geo processing never blocks the current gameplay request.
 * Review-recommended state remains queryable even when event/mail side effects fail.
@@ -920,7 +960,7 @@ The testing plan follows this service order:
 
   * user-facing entitlement reads reflect billing-fed updates correctly
 
-### Regression tests to keep from this stage onward
+### Regression tests to keep
 
 * Other services never depend directly on billing for live entitlement decisions.
 * `User Service` remains the source of truth for current entitlement.
@@ -979,8 +1019,8 @@ By default, they should use:
 ### D. Private game lifecycle
 
 * Eligible user creates private game.
-* Owner creates invite code.
-* Another user redeems invite code and applies.
+* Owner creates a user-bound invite.
+* The invited user accepts the invite and applies.
 * Owner approves application.
 * Owner starts game.
 * Running registration completes.
@@ -1030,7 +1070,7 @@ By default, they should use:
 
 ### J. Notification routing flow
 
-* Lobby emits invite/application/approval events.
+* Lobby emits invite/application/approval notification intents.
 * Notification Service sends push through gateway.
 * Non-auth email notifications route through Notification Service to Mail Service.
 * Auth-code emails remain direct `Auth / Session -> Mail`.