---
id: TST-PFM-SEC-228
title: Workspace provisioning alerts 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-provisioning-alerts.e2e.spec.js
implements:
  - ATS-PFM-SEC-003-07
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-provisioning-alerts.e2e.spec.js#Rhythm HQ’s
      alerts for a tenant provisioning (end to end)
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#a tenant
      that was provisioned
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#posts
      “Tenant ready” to the operations channel, with the message ts as the delivery’s provider
      reference
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#posts
      exactly the alert: the title, the body naming the tenant and the job, the Open job button on
      the job page
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#tells the
      requester by e-mail as well: the alert is beside the notice, not instead of it
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#alerts once
      for the job, however often the task that ends it runs
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#a
      provisioning that failed
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#posts
      “Tenant provisioning FAILED” with the operator-safe reason, beside the requester’s e-mail
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#Slack not
      being configured
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#skips the
      delivery channel_unconfigured, the job and the alert request both standing
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#a scope
      that cannot take the alert
  - provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#never fails
      the job: the tenant is active, the requester told, and nothing is alerted
dependency_evidence: >-
  The local request harness exercises the route dispatcher and the prepared database. The suite
  controls Cognito, message delivery, workflow execution, remote service participants, the signing
  key at the declared seams; those collaborators remain outside its live proof.
evidence:
  - 'services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.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-provisioning-alerts.e2e.spec.js'
  explicit_no_doubles: false
  identified_double_boundaries:
    - Cognito
    - message delivery
    - workflow execution
    - remote service participants
    - the signing key
---
# Workspace provisioning alerts request checks

## Verification Boundary

The file exercises public request handling through the local service harness. The assertion references identify the source checks for workspace provisioning alerts.

## 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 Cognito, message delivery, workflow execution, remote service participants, 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.