--- id: TST-PFM-SEC-226 title: Workspace email sender request checks kind: api-lifecycle product_area: platform module: security revision: 2 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js implements: - ATS-PFM-SEC-002-13 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 5 isolation: Use the prepared test database and suite-owned fixture rows; retain shared seed records. assertion_evidence: - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#a tenant’s e-mail sender in Rhythm HQ (end to end) - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#a tenant with its own sender identity, whose customer has published nothing yet - provenance: test source: 'services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers 200' - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers the address the association’s mail will come from, and the domain it is proving - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers the DNS records the customer must publish, so a support person can read them out - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers the identities Platform created in SES for it - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers pending, because the customer has not touched their DNS - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers the instant it asked SES, which is what makes the reading live - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#a tenant whose customer has just published their records - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers verified on the next read, having asked SES as it answered - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#a tenant asked for over POST /tenants with a domain strategy that names no domain - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers 200 to the request, which is phase 2’s shape with the sender beside it - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#proves the tenant’s own domain, because the request left the strategy’s domain to it - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#a tenant that sends from the shared Rhythm sender - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers 200, because every tenant has an answer to what its mail comes from - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers null rather than a record, which is how it says the shared sender - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#a caller who is not Rhythm staff - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#refuses an administrator of the tenant’s own customer as 403, because this is a system route - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#discloses nothing of the sender identity in that refusal - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#refuses an anonymous call as 401 - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#answers the same tenant’s sender identity to Rhythm staff, which is the premise those refusals need - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#a tenant that does not exist - provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js#refuses the read as 404, rather than answering null for a tenant nobody has dependency_evidence: >- The local request harness exercises the route dispatcher and the prepared database. The suite controls message delivery, the signing key at the declared seams; those collaborators remain outside its live proof. evidence: - 'services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js' - >- Static review at the recorded source revision; executable results remain not-run and conformance remains not-verified. binding_note: >- Each binding names the scenario to which this file contributes assertions. A binding is not a recorded pass and does not extend the file’s dependency boundary. examiner: codex examined_at: '2026-10-23' final_text: OpenAI dependency_review: provenance: test source: 'services-platform:modules/tenants/tests/e2e/tenant-email-sender.e2e.spec.js' explicit_no_doubles: false identified_double_boundaries: - message delivery - the signing key --- # Workspace email sender request checks ## Verification Boundary The file exercises public request handling through the local service harness. The assertion references identify the source checks for workspace email sender. ## What This Suite Proves The source assertions support the observations named in the bound scenarios. A scenario spanning multiple files must retain the other files’ contributions. ## What It Does Not Prove This examination does not run the suite. Passing behavior, deployed conformance and the behavior of substituted dependencies require separate execution evidence. ## Real Dependencies and Test Doubles The local request harness exercises the route dispatcher and the prepared database. The suite controls message delivery, the signing key at the declared seams; those collaborators remain outside its live proof. ## Must Not Be Doubled Keep route dispatch, signed-context verification and the exercised service decisions real. A test key can supply signatures, but replacing the authorization decision cannot prove request enforcement.