The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | createTenant | Submit the customer’s workspace details with a first administrator and domain sender. | CAP-PFM-TNL-001 | The response identifies a provisioning workspace and its recorded build. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#answers the provisioning job that is making the tenant usable |
| 2 | tenant_provisioning: provision:<participant> | Run application construction in the planned dependency order. | CAP-PFM-TNL-002 | Enabled participant work is invoked in sequence. | test services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#runs every participant, verifies them and opens the tenant |
| 3 | tenant_provisioning: provision:platform.security | Establish the requested customer Administrator invitation. | CAP-PFM-TNL-004 | A single recorded invitation supports safe replay. | test services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#invites them once, and records the invitation in the ledger |
| 4 | tenant_provisioning: provision:communications.sender-identity | Set up the association’s sending identities. | CAP-PFM-TNL-004 | Sender setup exposes DNS requirements while construction continues. | test services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#created the identities in SES on the way, so the customer has records to publish |
| 5 | tenant_provisioning: verify-readiness, activate | Check participant readiness and activate the result. | CAP-PFM-TNL-002 | Active lifecycle, requested business mode and first opening time are retained. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant usable once the job has run |
| 6 | getTenantProvisioning | Inspect the completed provisioning snapshot. | CAP-PFM-TNL-003 | Named participant and closing steps show their completion. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows every step completed, and names each one for the person reading it |
| 7 | notifyJobRequester | Read the requester’s outcome notice. | CAP-PFM-TNL-003 | The ready message identifies the workspace and links to progress. | test services-platform:modules/tenants/tests/integration/services/provisioning/provisioning-notices.integration.spec.js#sends the requester one message |
| 8 | /console/{tenantId} | Enter ordinary workspace use as the association’s administrator. | CAP-PFM-TNL-005 | The active enabled workspace passes its availability gate. | test services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is served a tenant-scoped route in an active tenant (the premise every refusal below is read against) |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 1 | The original submission is repeated. | Return the workspace and job already associated with it. | No second workspace or build is recorded. | test services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#answers the same tenant and the same job when the same submission is sent twice |
| alternate | 4 | No association sender is requested. | Skip sender identity creation. | Mail continues through Rhythm’s shared sender. | test services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#writes no sender identity, because the shared Rhythm sender is the answer for most tenants |
| failure | 5 | Readiness cannot find a required resource. | Refuse opening and report the missing resource. | Partial construction remains in a failed workspace for staff recovery. | test services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#leaves the tenant where an operator can see it, and does not open it |
| Id | Statement | Provenance |
|---|---|---|
01 | Customer availability changes from closed construction to active enabled use. | test services-platform:modules/tenants/tests/e2e/tenant-availability-gate.e2e.spec.js#is refused 403 in a tenant that is still being provisioned |
02 | The job retains completed participant, readiness and activation steps. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows one step per participant, then the readiness check and the activation |
03 | The handled ready notice contains a progress link and is not sent again in the replay fixture. | test services-platform:modules/tenants/tests/integration/services/provisioning/provisioning-notices.integration.spec.js#links to the job’s own page in Rhythm HQ, so the requester can read the steps |
04 | The new-customer fixture records an invitation and opens with sender verification pending. | test services-platform:modules/tenants/tests/integration/services/provisioning/tenant-email-strategy.integration.spec.js#opens the tenant anyway, which is what option A promises |
End-to-end policy: required: The outcome crosses lifecycle operations and warrants end-to-end verification; the current bindings establish backend fixtures, while screen and deployed-service coverage remain separate gaps.