--- id: FAS-PFM-NOT-01 title: Application Notification Catalog feature: FEAT-PFM-NOT-01 product_area: platform module: notifications revision: 1 status: proposed product_intent: proposed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f capabilities: - CAP-PFM-NOT-001 scenarios: - id: FAS-PFM-NOT-01-01 title: A declared event becomes a usable catalog entry kind: behaviour exercises: - CAP-PFM-NOT-001 relies_on: - ATS-PFM-NOT-001-05 - ATS-PFM-NOT-001-11 preconditions: >- A producer owns a valid personal declaration and HQ staff have catalog authority. steps: Register the manifest and read its catalog entry from HQ. expected: >- Staff find the declared event without private rendering content or schemas. negative: false data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: [] provenance: proposed source: - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-05 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-11 - id: FAS-PFM-NOT-01-02 title: An unmapped operational declaration cannot enter processing kind: interaction exercises: - CAP-PFM-NOT-001 - CAP-PFM-NOT-013 relies_on: - ATS-PFM-NOT-001-08 - ATS-PFM-NOT-013-03 preconditions: >- Include a valid personal event and an operational event without an HQ mapping. steps: >- Submit the manifest, then attempt processing of the unmapped operational event. expected: >- Registration refuses the manifest and the operational request records invalidity without a delivery. negative: false data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: [] provenance: proposed source: - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-08 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-013-alert-rhythms-own-staff-in-slack.md#ATS-PFM-NOT-013-03 - id: FAS-PFM-NOT-01-03 title: Release changes preserve declaration history kind: lifecycle exercises: - CAP-PFM-NOT-001 relies_on: - ATS-PFM-NOT-001-07 - ATS-PFM-NOT-001-09 - ATS-PFM-NOT-001-10 preconditions: >- Keep an open request, a settled request and stored preferences for an existing definition. steps: >- Register unchanged and changed releases, omit the declaration, then restore it. expected: >- Version history remains readable; retirement closes only open requests and restoration reuses the declaration identity. negative: false data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: [] provenance: proposed source: - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-07 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-09 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-10 - id: FAS-PFM-NOT-01-04 title: Customer authority does not expose the global catalog kind: permission exercises: - CAP-PFM-NOT-001 - CAP-PFM-NOT-013 relies_on: - ATS-PFM-NOT-001-11 - ATS-PFM-NOT-013-02 preconditions: Use a customer administrator and an authorized HQ account. steps: >- Read the catalog under each identity and try a customer-scoped operational audience. expected: >- Only HQ reads the global declarations; customer publication cannot create an operational notice. negative: true data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: [] provenance: proposed source: - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-11 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-013-alert-rhythms-own-staff-in-slack.md#ATS-PFM-NOT-013-02 - id: FAS-PFM-NOT-01-05 title: Manifest refusal leaves installed definitions available kind: regression exercises: - CAP-PFM-NOT-001 relies_on: - ATS-PFM-NOT-001-08 - ATS-PFM-NOT-001-12 preconditions: >- Install one valid declaration and prepare a second release with invalid fields. steps: Submit the invalid release and reread the existing catalog. expected: >- The installed declaration remains unchanged and the refused release supplies a field-specific problem. negative: false data_needs: >- Suite-owned records and repeat keys, named recipient identities and controlled provider outcomes. bound_to: [] provenance: proposed source: - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-08 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-12 evidence: - >- rhythm-v2-docs:specs/platform/notifications/planning/features/FEAT-PFM-NOT-01-notification-registry.md - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-05 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-11 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-08 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-013-alert-rhythms-own-staff-in-slack.md#ATS-PFM-NOT-013-03 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-07 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-09 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-10 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-11 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-013-alert-rhythms-own-staff-in-slack.md#ATS-PFM-NOT-013-02 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-08 - >- rhythm-v2-docs:specs/platform/notifications/design/tests/ATS-PFM-NOT-001-register-the-kinds-of-notification-an-application-can-send.md#ATS-PFM-NOT-001-12 regression_record: - revision: 1 change: initial scenarios: - FAS-PFM-NOT-01-01 - FAS-PFM-NOT-01-02 - FAS-PFM-NOT-01-03 - FAS-PFM-NOT-01-04 - FAS-PFM-NOT-01-05 reason: >- Initial cumulative feature acceptance coverage from the pinned planning and design layers. --- # Application Notification Catalog: Feature Acceptance Suite ## What the Feature Must Do as a Whole This suite follows the feature from its initial inputs through the outcomes people inspect. Its cases combine capability results so that a change at one stage is checked against the later stages that depend on it. ## Interactions Between Capabilities Submit the manifest, then attempt processing of the unmapped operational event. Registration refuses the manifest and the operational request records invalidity without a delivery. The feature cases retain their prerequisite scenario references. A component test alone does not establish execution of the complete feature chain. ## Regression Record | Revision | Change | Scenario | Why | |---|---|---|---| | 1 | initial | All initial cases | Establish cumulative feature coverage and preserve its dependencies for later revisions. |