--- id: ATS-PFM-NOT-013 scope: CAP-PFM-NOT-013 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-013-01 title: Process an HQ event through the ordinary pipeline level: api proves: - BR-CAP-PFM-NOT-013-01 preconditions: Prepare a provisioning-completed alert published in the system scope. steps: Execute operational alert processing. expected: >- One request creates a recipient-less notice and queued system Slack delivery with rendered payload. negative: false data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is accepted as one request, one instance with no recipient and one queued slack_system delivery with the Block Kit payload - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#writes a delivery-work row the dispatcher publishes to the chat queue as a pointer to the delivery - >- react-console:acceptance/notifications/playwright/journeys/hq/NT-ACC-0150.spec.ts#NT-ACC-0150 - TST-PFM-NOT-004 - TST-PFM-NOT-103 provenance: test source: >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is accepted as one request, one instance with no recipient and one queued slack_system delivery with the Block Kit payload category: rule 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-013-02 title: Reject customer attempts to select HQ audiences level: api proves: - BR-CAP-PFM-NOT-013-02 - INV-DOM-PFM-NOT-003-06 preconditions: Prepare a definition that declares the system audience. steps: >- Publish it from a customer organization; publish an audience of people in the system scope; store a recipientless notice in a customer organization. expected: >- Both forbidden audience cases are rejected and create no notices or deliveries. negative: true data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is refused in a customer’s tenant as audience_kind_not_allowed, even for a definition that declares it, and nothing is made - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#takes no audience of people in the system scope, which has none - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#keeps a customer’s tenant from having an instance with no recipient, whatever wrote it - >- services-platform:modules/notifications/tests/unit/audience-planner.spec.js#refuses a system audience outside the Rhythm system scope even when the definition declares it - >- services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#refuses a system audience for now, whatever the definition declares - TST-PFM-NOT-079 - TST-PFM-NOT-103 - TST-PFM-NOT-104 provenance: test source: >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is refused in a customer’s tenant as audience_kind_not_allowed, even for a definition that declares it, and nothing is made category: permission binding_scope: >- Each binding supplies its own assertions; the aggregate references do not imply that one executable file proves every step. invariant_source: >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is refused in a customer’s tenant as audience_kind_not_allowed, even for a definition that declares it, and nothing is made - id: ATS-PFM-NOT-013-03 title: Require a mapped HQ channel level: unit proves: - BR-CAP-PFM-NOT-013-03 preconditions: Prepare the channel map and the provisioning definitions. steps: Submit for registration a system definition with no entry; publish one. expected: >- Registration names the unmapped definition in its rejection, and processing records an invalid request with missing-channel reason. negative: true data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/unit/hq-channels.spec.js#sends both provisioning outcomes to the operations channel, and nothing else - >- services-platform:modules/notifications/tests/unit/hq-channels.spec.js#refuses a system definition with no entry in the map, naming the definition and the audience_kinds path - >- services-platform:modules/notifications/tests/unit/hq-channels.spec.js#is frozen, so nothing changes where an alert goes while the process runs - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is recorded invalid, naming no_hq_channel, when the definition has no channel in the map - TST-PFM-NOT-103 - TST-PFM-NOT-107 provenance: test source: >- services-platform:modules/notifications/tests/unit/hq-channels.spec.js#sends both provisioning outcomes to the operations channel, and nothing else category: validation 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-013-04 title: Create one operational delivery per mapped channel level: api proves: - BR-CAP-PFM-NOT-013-04 preconditions: Prepare a definition mapped to two channels. steps: Publish it twice for the identical occurrence. expected: >- Two mapped channels create two notices and deliveries, no console delivery and no additions on repetition. negative: false data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#writes one instance and one delivery for each channel of the map - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#makes nothing twice when the same occurrence is published again under another request - TST-PFM-NOT-103 provenance: test source: >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#writes one instance and one delivery for each channel of the map category: invariant 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-013-05 title: 'Render stable, bounded Slack content' level: unit proves: - BR-CAP-PFM-NOT-013-05 preconditions: 'Prepare a alert with a long body, special characters and an open action.' steps: Render the same alert using winter and summer occurrence times. expected: >- The payload follows its fixed layout, formats Eastern time across daylight-saving changes, truncates and escapes text, and uses a channel key without a Slack identifier. negative: false data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/unit/slack-system-render.spec.js#is exactly a bold title and the body, the Rhythm HQ context line in Eastern time, one URL button and a plain fallback - >- services-platform:modules/notifications/tests/unit/slack-system-render.spec.js#reads the instant in Eastern time on the other side of daylight saving time - >- services-platform:modules/notifications/tests/unit/slack-system-render.spec.js#cuts the section text at 3,000 characters - >- services-platform:modules/notifications/tests/unit/slack-system-render.spec.js#escapes the three characters Slack treats as control characters, and nothing else - >- services-platform:modules/notifications/tests/unit/slack-system-render.spec.js#names the channel by key and carries no id, so what is stored on a delivery names no workspace identifier - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#links the Open job button to the job page on the console’s origin - TST-PFM-NOT-103 - TST-PFM-NOT-115 provenance: test source: >- services-platform:modules/notifications/tests/unit/slack-system-render.spec.js#is exactly a bold title and the body, the Rhythm HQ context line in Eastern time, one URL button and a plain fallback category: boundary 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-013-06 title: 'Handle Slack success, throttling and failure' level: unit proves: - BR-CAP-PFM-NOT-013-06 preconditions: Prepare a recording Slack. steps: >- Answer ok; 429 with and without Retry-After; each permanent rejection; another rejection; a 5xx; a network failure; no secret. expected: >- Success retains the message reference. Throttling honors the minimum wait; permanent errors fail immediately and transient errors retry. Missing configuration skips with one warning. negative: true data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#posts the stored payload to the channel id the secret holds for the key, with the token as the credential, and answers the message ts - >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#answers a 429 as a retryable failure carrying Retry-After - >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#waits 30 seconds when a 429 names no Retry-After - >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#keeps the four named refusals among the permanent ones - >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#answers any other refusal as a retryable failure, so the queue’s receives are the retry budget - >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#answers a network failure as a retryable failure - >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#skips every delivery `channel_unconfigured` when there is no secret, posts nothing, and warns once for the process - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#requeues a rate limit for at least Slack’s Retry-After, longer than the queue’s backoff - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#fails channel_not_found at once and acknowledges the item - TST-PFM-NOT-103 - TST-PFM-NOT-114 provenance: test source: >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#posts the stored payload to the channel id the secret holds for the key, with the token as the credential, and answers the message ts category: failure 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-013-07 title: Exclude credentials from retained Slack delivery data level: unit proves: - BR-CAP-PFM-NOT-013-07 preconditions: Prepare a capturing logger and a recording Slack. steps: >- Exercise operational delivery with a successful response and an error response. expected: Retained delivery outcomes and payloads contain no Slack credential. negative: false data_needs: Use only records created and owned by this suite. bound_to: - >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#never puts the token in a log line, an outcome or the payload it stored - >- services-platform:modules/notifications/tests/unit/hq-channels.spec.js#does not echo the token in the refusal of a malformed value - TST-PFM-NOT-107 - TST-PFM-NOT-114 provenance: test source: >- services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js#never puts the token in a log line, an outcome or the payload it stored category: invariant 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-013-08 title: Keep provisioning alerts in Rhythm operations level: api proves: - AS-JNY-PFM-NOT-004-01 preconditions: Prepare a recording Slack and the Rhythm system scope. steps: Complete a provisioning job and process its published operational alert. expected: >- One Block Kit message targets operations; customer notification history contains no copy. negative: false data_needs: The journey's own personas and Northeast unit. bound_to: - >- react-console:acceptance/notifications/playwright/journeys/hq/NT-ACC-0150.spec.ts#NT-ACC-0150 - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#posts the payload to the channel id and records the delivery sent with the message ts, the instance delivering - TST-PFM-NOT-004 - TST-PFM-NOT-103 provenance: test source: >- react-console:acceptance/notifications/playwright/journeys/hq/NT-ACC-0150.spec.ts#NT-ACC-0150 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-013-09 title: Initialize the reserved workspace idempotently level: api proves: - BR-CAP-PFM-NOT-013-11 preconditions: Prepare a environment with no system workspace. steps: 'Ensure the system scope, next ensure it a second time.' expected: >- One active support workspace belongs to the demonstration customer and remains nonlive and unlicensed. negative: false data_needs: An environment with no system workspace. bound_to: - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is a support tenant of its own demo customer, active but never live, with no licence company - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is created once: a second ensure changes nothing and says so - TST-PFM-NOT-103 provenance: test source: >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js#is a support tenant of its own demo customer, active but never live, with no licence company category: invariant 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-013-10 title: HQ routing stays separate from personal selection and operator recovery category: interaction level: api proves: - BR-CAP-PFM-NOT-013-04 exercises: - CAP-PFM-NOT-013 - CAP-PFM-NOT-012 preconditions: >- Use the reserved operational workspace and a customer workspace, with a mapped alert and temporary Slack failure. steps: >- Publish the operational alert, try the same audience in the customer workspace, exhaust its delivery and retry the exhausted work from HQ. expected: >- The operational notice has no personal recipient and the customer request creates no notice. Operator retry changes only eligible exhausted work. 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-013-alert-rhythms-own-staff-in-slack.md#frontmatter - >- rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-012-support-a-customers-notifications-from-rhythm-hq.md#frontmatter interaction_with: - CAP-PFM-NOT-012 - id: ATS-PFM-NOT-013-11 title: Post an operational payload to the configured provider category: rule level: api proves: - BR-CAP-PFM-NOT-013-06 preconditions: >- Configure the development operational Slack secret and a mapped operations channel. steps: >- Render the suite’s operational payload, send it through the real Slack adapter and inspect the returned outcome. expected: >- The adapter reports sent and retains a provider message reference in the expected timestamp form. negative: false data_needs: >- One operational provider-test message in the configured development operations channel. bound_to: - >- services-platform:modules/notifications/tests/provider/slack-system.provider.spec.ts#posts one message to the operations channel and answers its ts - TST-PFM-NOT-119 provenance: test source: >- services-platform:modules/notifications/tests/provider/slack-system.provider.spec.ts#posts one message to the operations channel and answers its ts binding_scope: >- This suite sends one real development message through the operational adapter; it does not exercise publication, request processing or provisioning producers. evidence: - >- Pinned evidence inventory 1: services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js; services-platform:modules/notifications/tests/unit/audience-planner.spec.js; services-platform:modules/notifications/tests/unit/hq-channels.spec.js; services-platform:modules/notifications/tests/unit/slack-system-adapter.spec.js - >- Pinned evidence inventory 2: react-console:acceptance/notifications/playwright/journeys/hq/NT-ACC-0150.spec.ts; services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js; services-platform:modules/notifications/tests/unit/slack-system-render.spec.js coverage: rule: covered transition: not-applicable validation: covered permission: covered edge: 'gap: FND-PFM-NOT-074' failure: covered boundary: covered concurrency: 'gap: FND-PFM-NOT-074' invariant: covered interaction: covered coverage_notes: transition: >- This capability computes or reads an outcome and owns no lifecycle transition; state changes are tested in the owning capability. edge: Exceptional but valid input needs a dedicated expected-outcome case. concurrency: >- The suite lacks a complete race case with controlled interleaving and post-race assertions. findings: - FND-PFM-NOT-074 transition_coverage: [] workflow_coverage: - workflow: WF-PFM-NOT-001 capabilities: - CAP-PFM-NOT-001 - CAP-PFM-NOT-013 scenario_candidate: ATS-PFM-NOT-013-10 coverage: 'gap: FND-PFM-NOT-084' reason: >- The proposed related-capability sequence does not independently isolate every workflow hop, failure seam and interleaving. - workflow: WF-PFM-NOT-006 capabilities: - CAP-PFM-NOT-013 - CAP-PFM-NOT-003 - CAP-PFM-NOT-007 scenario_candidate: ATS-PFM-NOT-013-10 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: - invariant: INV-DOM-PFM-NOT-003-06 scenarios: - ATS-PFM-NOT-013-02 coverage: specified source: >- rhythm-v2-docs:specs/platform/notifications/design/objects/DOM-PFM-NOT-003-staff-notification.md verification_note: >- The candidate supplies the fixture outcome; individual binding limits remain applicable. --- # Send operational alerts to Rhythm 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-013-01` | `ATS-PFM-NOT-013-01`, `ATS-PFM-NOT-013-10` | | `BR-CAP-PFM-NOT-013-02` | `ATS-PFM-NOT-013-02` | | `BR-CAP-PFM-NOT-013-03` | `ATS-PFM-NOT-013-03` | | `BR-CAP-PFM-NOT-013-04` | `ATS-PFM-NOT-013-04` | | `BR-CAP-PFM-NOT-013-05` | `ATS-PFM-NOT-013-05` | | `BR-CAP-PFM-NOT-013-06` | `ATS-PFM-NOT-013-06` | | `BR-CAP-PFM-NOT-013-07` | `ATS-PFM-NOT-013-07` | | `BR-CAP-PFM-NOT-013-11` | `ATS-PFM-NOT-013-09` | ## Interactions With Related Capabilities Use the reserved operational workspace and a customer workspace, with a mapped alert and temporary Slack failure. Publish the operational alert, try the same audience in the customer workspace, exhaust its delivery and retry the exhausted work from HQ. 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.