> **보존 안내** — 이 파일은 저장소 루트 `notification-superpowers-package/` 에 있던 납품 패키지의 README다. > 2026-08-15 문서 정리에서 설계서·계획서는 `docs/superpowers/specs/` 와 `docs/superpowers/plans/` 로 통합했고, > 실행 불가 상태였던 `validate_notification_docs.py` 와 `MANIFEST.sha256` 은 제거했다. > 아래 본문은 납품 시점의 기록이므로 제거된 파일을 가리키는 문장은 더 이상 유효하지 않다. # Notification Delivery Platform Superpowers Package 이 패키지는 Backend Skeleton의 `notification` 기술 모듈을 구현하기 위한 설계서와 TDD 구현 계획서다. ## 파일 ```text docs/superpowers/specs/2026-08-10-notification-platform-design.md docs/superpowers/plans/2026-08-10-notification-platform-implementation-plan.md VALIDATION.md validate_notification_docs.py MANIFEST.sha256 ``` ## 핵심 계약 ```text NotificationRequest → RecipientDelivery → DeliveryAttempt → ProviderEvent append-only ledger → channel-specific projection → SubmissionOutcome / DeliveryOutcome / EvidenceLevel ``` - `submit()` 성공은 durable acceptance만 뜻한다. - Provider acceptance와 delivery/read evidence를 분리한다. - 결과를 확정할 수 없으면 `AMBIGUOUS`로 보존한다. - ambiguous attempt의 자동 retry와 cross-channel fallback은 기본 차단한다. - FCM은 FID를 primary target으로, registration token을 legacy compatibility로 둔다. - Callback은 signature 검증 후 원장에 append하고 중복·역순·누락을 처리한다. - Contact Point는 AES-256-GCM 암호화와 HMAC-SHA-256 equality fingerprint를 사용한다. ## 구현 기준 가정 실제 Backend Skeleton 저장소가 입력되지 않았기 때문에 다음 가정을 문서에 명시했다. ```text Java 21 Gradle Kotlin DSL Spring Framework 6.2 common line + Spring 7.0 compatibility job PostgreSQL 16 JPA + Flyway root package: io.backend.skeleton.notification module root: modules/notification ``` 실제 저장소에서는 dependency catalog와 package/file path를 기존 규칙에 맞게 매핑하되 공개 계약과 신뢰성 의미론은 유지한다. ## 실행 1. 설계서를 검토한다. 2. 계획서 Task 1부터 순서대로 실행한다. 3. 각 Task에서 failing test → red 확인 → 최소 구현 → green 확인 → commit 순서를 지킨다. 4. Task마다 specification review와 code-quality review를 분리한다. 5. 마지막 release gate에서 contract, chaos, security, performance, compatibility job을 모두 실행한다. ## 검증 범위 `VALIDATION.md`는 문서 구조, Task 연속성, 파일 경로 중복, 미확정 표현, 핵심 계약, ZIP CRC를 검증한 결과다. 실제 Gradle compile과 Provider integration은 Backend Skeleton 저장소에서 계획서의 명령을 실행해야 한다.