--- id: TST-PFM-NOT-103 title: system audience kind: integration product_area: platform module: notifications revision: 1 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - >- modules/notifications/tests/integration/services/system/system-audience.integration.spec.js implements: - ATS-PFM-NOT-013-01 - ATS-PFM-NOT-013-02 - ATS-PFM-NOT-013-03 - ATS-PFM-NOT-013-04 - ATS-PFM-NOT-013-05 - ATS-PFM-NOT-013-06 - ATS-PFM-NOT-013-08 - ATS-PFM-NOT-013-09 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 5 isolation: >- Suite-owned records in the prepared integration workspaces; seeded workspace identities remain shared fixtures. assertion_bindings: - scenario: ATS-PFM-NOT-013-01 suite: TST-PFM-NOT-103 assertions: - >- 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 - scenario: ATS-PFM-NOT-013-02 suite: TST-PFM-NOT-103 assertions: - >- 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 - scenario: ATS-PFM-NOT-013-03 suite: TST-PFM-NOT-103 assertions: - >- 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 - scenario: ATS-PFM-NOT-013-04 suite: TST-PFM-NOT-103 assertions: - >- 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 - scenario: ATS-PFM-NOT-013-05 suite: TST-PFM-NOT-103 assertions: - >- 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 - scenario: ATS-PFM-NOT-013-06 suite: TST-PFM-NOT-103 assertions: - >- 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 - scenario: ATS-PFM-NOT-013-08 suite: TST-PFM-NOT-103 assertions: - >- 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 - scenario: ATS-PFM-NOT-013-09 suite: TST-PFM-NOT-103 assertions: - >- 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 evidence: - >- services-platform:modules/notifications/tests/integration/services/system/system-audience.integration.spec.js - The file and referenced assertion titles exist at the pinned commit. dependency_evidence: - >- Real: PostgreSQL with row-level security on, the real orchestrator, dispatcher, consumer, adapter and persistence services, the - >- recipient constraint. Doubled: the dispatcher nudge and the SQS publisher (recorders), and Slack with its secret - >- (`tests/support/recording-slack.ts`). Never doubled: the database, the orchestrator or the adapter's decisions. --- # system audience ## Verification Boundary This suite exercises the local services and prepared PostgreSQL database. API lifecycle cases use signed test contexts through the real route handler; they do not invoke the deployed gateway. ## What This Suite Proves Its cases exercise process an HQ event through the ordinary pipeline; reject customer attempts to select HQ audiences; require a mapped HQ channel; create one operational delivery per mapped channel; render stable, bounded Slack content; handle Slack success, throttling and failure. The registered scenario bindings identify the assertions this executable file contributes. They retain individual test references so that a composite scenario does not become a claim of complete execution by one file. ## What It Does Not Prove Local outcomes do not prove deployed queues, external provider acceptance, production credentials or complete browser behavior. No fresh execution or conformance result is claimed. ## Real Dependencies and Test Doubles The notification fixtures use real PostgreSQL and module logic. Queue publication, visibility changes, nudges and installed channel adapters are recorded at their seams when the suite needs them. Signed API contexts replace the authorizer key in API suites. ## Must Not Be Doubled Database constraints, workspace policy, state guards and the service operation under test must remain real. Recording a provider or queue call must not replace the submission, claim or outcome logic being checked.