--- id: ATS-PFM-NOT-012 scope: CAP-PFM-NOT-012 product_area: platform module: notifications revision: 2 status: proposed approved_by: null approved_at: null source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-PFM-NOT-012-01 title: Keep HQ notification keys staff-only level: unit proves: - BR-CAP-PFM-NOT-012-01 preconditions: Prepare the permission catalog and the HQ reader policy. steps: Retrieve the keys' flags and the policy. expected: >- Read and operate keys are restricted to staff, operate is sensitive and reader policy grants neither. negative: false data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/unit/permissions.spec.js#makes both HQ keys staff-only, operate sensitive - >- services-platform:modules/notifications/tests/unit/permissions.spec.js#leaves both HQ keys out of the HQ reader policy: the Rhythm Administrator holds them through hq.*.* - >- services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#refuses the system door and Rhythm HQ’s routes to a console caller, even one holding every platform key - TST-PFM-NOT-069 - TST-PFM-NOT-109 provenance: test source: >- services-platform:modules/notifications/tests/unit/permissions.spec.js#makes both HQ keys staff-only, operate sensitive category: permission binding_scope: >- Each binding supplies its own assertions; the aggregate references do not imply that one executable file proves every step. - id: ATS-PFM-NOT-012-02 title: Require an active customer access grant level: api proves: - BR-CAP-PFM-NOT-012-02 preconditions: >- Use Rhythm staff granted access to one workspace but lacking access to a second. steps: >- Retrieve History and requests of each, and of a workspace that does not exist. expected: >- The granted read returns administrator-equivalent history; the remaining reads fail without returning customer records. negative: true data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is refused without an active staff access grant, naming nothing of the tenant - >- services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is answered with an active grant into the tenant, the same page its administrator reads - >- services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is refused for another tenant, the grant reaching only the tenant it names - >- services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is refused for a tenant that does not exist - >- services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#refuses a tenant’s requests for Rhythm HQ without an access grant into the tenant, as its History is - >- react-console:acceptance/notifications/playwright/journeys/history/NT-ACC-0100.spec.ts#NT-ACC-0100 - TST-PFM-NOT-002 - TST-PFM-NOT-069 - TST-PFM-NOT-072 provenance: test source: >- services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is refused without an active staff access grant, naming nothing of the tenant category: permission binding_scope: >- Each binding supplies its own assertions; the aggregate references do not imply that one executable file proves every step. - id: ATS-PFM-NOT-012-03 title: Retry only exhausted notification deliveries level: api proves: - BR-CAP-PFM-NOT-012-04 preconditions: >- Prepare a single delivery with attempts exhausted, one rejected permanently. steps: 'Retry each, and an unrecognized delivery.' expected: >- The exhausted delivery returns to queued work. Missing and permanently refused deliveries fail eligibility checks without changes. negative: true data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#queues a delivery that ran out of receives again, with its work row, and nothing else - >- services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#refuses a delivery the provider refused permanently, leaving it as it was - >- services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#refuses a delivery that is not there - >- services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#lists the dead deliveries and refuses to retry one that is not there - TST-PFM-NOT-069 - TST-PFM-NOT-074 provenance: test source: >- services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js#queues a delivery that ran out of receives again, with its work row, and nothing else category: transition binding_scope: >- Each binding supplies its own assertions; the aggregate references do not imply that one executable file proves every step. - id: ATS-PFM-NOT-012-04 title: Read HQ History only while access is granted level: api proves: - AS-JNY-PFM-NOT-004-02 preconditions: >- Prepare staff sessions with active granted access and without granted access. steps: Retrieve the customer's history as each. expected: Active-grant history succeeds; the same read without a grant fails. negative: true data_needs: The journey's own personas and Northeast unit. bound_to: - >- services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is answered with an active grant into the tenant, the same page its administrator reads - >- services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is refused without an active staff access grant, naming nothing of the tenant - >- react-console:acceptance/notifications/playwright/journeys/history/NT-ACC-0100.spec.ts#NT-ACC-0100 - TST-PFM-NOT-002 - TST-PFM-NOT-072 provenance: test source: >- services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js#is answered with an active grant into the tenant, the same page its administrator reads category: interaction binding_scope: >- Each binding supplies its own assertions; the aggregate references do not imply that one executable file proves every step. - id: ATS-PFM-NOT-012-05 title: Expose the current operator content and grant boundary level: api proves: - BR-CAP-PFM-NOT-012-07 preconditions: >- An authorized HQ operator without an active customer grant and an exhausted customer delivery containing rendered content. steps: >- Read its dead-letter record and retry the eligible delivery; separately request customer History without the grant. expected: >- Operator responses currently include channel content, while customer History is rejected; the product question determines the required future content boundary. negative: false data_needs: 'Use an isolated workspace, delivery payload and operator grant state.' bound_to: [] provenance: proposed source: >- services-platform:modules/notifications/services/centre/hq-notifications.ts category: boundary - id: ATS-PFM-NOT-012-06 title: HQ retry affects operational progress within its authority boundary category: interaction level: api proves: - BR-CAP-PFM-NOT-012-04 exercises: - CAP-PFM-NOT-012 - CAP-PFM-NOT-013 preconditions: >- Prepare an operational Slack delivery exhausted through temporary failure and a permanent provider refusal. steps: >- List failed work, retry each delivery from HQ, then process queued work and inspect operational notice progress. expected: >- Only the exhausted delivery is offered again. The permanent refusal remains final, and the retried operational notice reflects the new delivery outcome. negative: false data_needs: >- A suite-owned workspace, named staff accounts and unique occurrence keys; external adapters record attempts without shared writes. bound_to: [] provenance: proposed source: - >- rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-012-support-a-customers-notifications-from-rhythm-hq.md#frontmatter - >- rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-013-alert-rhythms-own-staff-in-slack.md#frontmatter interaction_with: - CAP-PFM-NOT-013 evidence: - >- Pinned evidence inventory 1: services-platform:modules/notifications/tests/unit/permissions.spec.js; services-platform:modules/notifications/tests/integration/services/centre/hq-notifications.integration.spec.js; services-platform:modules/notifications/tests/integration/services/dispatch/deliver-delivery.integration.spec.js - >- Pinned evidence inventory 2: services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js; react-console:acceptance/notifications/playwright/journeys/history/NT-ACC-0100.spec.ts coverage: rule: 'gap: FND-PFM-NOT-073' transition: covered validation: 'gap: FND-PFM-NOT-073' permission: covered edge: 'gap: FND-PFM-NOT-073' failure: 'gap: FND-PFM-NOT-073' boundary: covered concurrency: 'gap: FND-PFM-NOT-073' invariant: 'gap: FND-PFM-NOT-073' interaction: covered coverage_notes: rule: >- The specification does not isolate a general positive outcome outside the narrower category cases. validation: Malformed input is not isolated in a dedicated category scenario. edge: Exceptional but valid input needs a dedicated expected-outcome case. failure: The suite lacks an isolated dependency failure and recovery case. concurrency: >- The suite lacks a complete race case with controlled interleaving and post-race assertions. invariant: >- The suite does not isolate every persistent guarantee in a dedicated category scenario. findings: - FND-PFM-NOT-073 transition_coverage: [] workflow_coverage: - workflow: WF-PFM-NOT-008 capabilities: - CAP-PFM-NOT-012 scenario_candidate: ATS-PFM-NOT-012-06 coverage: 'gap: FND-PFM-NOT-084' reason: >- The proposed related-capability sequence does not independently isolate every workflow hop, failure seam and interleaving. domain_invariant_coverage: [] --- # Investigate and retry notifications from HQ: Capability Test Specification ## Coverage Each scenario names the guarantee it proves. Category coverage describes specified cases; executable bindings retain their narrower assertion boundaries. Lifecycle coverage remains a gap wherever guards and effects lack independent verification. | Rule | Proof | |---|---| | `BR-CAP-PFM-NOT-012-01` | `ATS-PFM-NOT-012-01`, `ATS-PFM-NOT-012-06` | | `BR-CAP-PFM-NOT-012-02` | `ATS-PFM-NOT-012-02` | | `BR-CAP-PFM-NOT-012-04` | `ATS-PFM-NOT-012-03` | | `BR-CAP-PFM-NOT-012-07` | `ATS-PFM-NOT-012-05` | ## Interactions With Related Capabilities Prepare an operational Slack delivery exhausted through temporary failure and a permanent provider refusal. List failed work, retry each delivery from HQ, then process queued work and inspect operational notice progress. The interaction case combines the producing, processing and reading outcomes named in its frontmatter. It remains proposed until an executable suite performs that complete sequence.