Skip to content

JNY-PFM-NOT-005Register a notification type and publish a collapsing burst

Markdown

JNY-PFM-NOT-005

Register a notification type and publish a collapsing burst

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationObserved

KindJourneyProduct areaPlatformModuleStaff Notifications and Association CommunicationsRevision1End-to-endNone

Read atservices-platform ad3f6a65react-console baf6dae3

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Goal
Introduce a validated notification type and use transactional publication, current audience selection and repetition collapse.
Intent sources
services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#2. Scope

Steps

#SurfaceActionCapabilityExpectedProvenance
1platform_notifications_registrationDeployment submits a declaration whose template references an undeclared field.CAP-PFM-NOT-001Registration identifies the definition and field, rejects the entire manifest and stores nothing.test
2platform_notifications_registrationDeployment submits the corrected declaration.CAP-PFM-NOT-001The notification type appears in the shared HQ catalog.test
3publishNotificationThe application publishes to scoped responsibility holders within its transaction and retries that submission.CAP-PFM-NOT-002One request identity survives, and the repeat receipt indicates duplication.test
4platform-notifications-requestsProcessing evaluates the current audience.CAP-PFM-NOT-003Scoped holders, delegates and applicable fallback recipients qualify; outsiders do not.test
5platform-notifications-requestsThe application publishes four additional matching events within two minutes.CAP-PFM-NOT-005All four contributions collapse into the existing item.test
6listMyNotificationsThe recipient reviews Notifications.CAP-PFM-NOT-009One item presents the latest event details and four additional contributions.test

Alternate and Failure Paths

PathFrom stepConditionPath takenOutcomeProvenance
failure4The producer selects a user from another customer.Audience processing removes the user and retains the isolation refusal.Only eligible customer staff receive notices.test
failure4Audience resolution produces two hundred and one candidates after exclusions.The whole request records invalidity.No recipient receives an item, and History retains the failed request.test

Assertions

IdStatementProvenance
01Invalid registration stores no definitions, while the corrected manifest appears in the HQ catalog.test
02Repeating publication produces only one recipient item.test
03Five matching contributions share one recipient notice.test

End-to-end policy: none: Registration, publication, audience selection and collapse have backend evidence; other inbox journeys provide the browser experience for the final recipient view.

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.