The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | tenant_provisioning: RecordFailure | Retain the failed participant result and stop construction. | CAP-PFM-TNL-003 | The workspace remains with its partial resources and failed lifecycle. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant saying its provisioning failed, which is what makes it retryable |
| 2 | notifyJobRequester | Read the failure notice. | CAP-PFM-TNL-003 | The notice explains the outcome and the available retry or deletion choices. | test services-platform:modules/tenants/tests/integration/services/provisioning/provisioning-notices.integration.spec.js#says the tenant is left standing and can be retried or deleted |
| 3 | /console/{tenantId} | Attempt ordinary customer entry into the failed workspace. | CAP-PFM-TNL-005 | Availability remains closed to customer context. | test services-platform:modules/tenants/tests/unit/services/access/tenant-availability.spec.js#answers the rule for every combination of lifecycle state, status and caller |
| 4 | getTenantProvisioning | Inspect the provisioning snapshot’s failure explanation. | CAP-PFM-TNL-003 | The snapshot retains the participant’s summary. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#says so in the snapshot too, with the failure summary the task refused with |
| 5 | retryTenantProvisioning | Correct the cause and request retry. | CAP-PFM-TNL-003 | The response identifies a new attempt linked to the failed build. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#answers 200 and a new job to the retry |
| 6 | tenant_provisioning (retry) | Complete the outstanding construction and readiness work. | CAP-PFM-TNL-002 | Retained steps are not repeated and the workspace becomes active. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant usable after the retry |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 5 | Staff decide to abandon construction. | Disable the failed workspace and submit deletion. | The never-opened fixture enters its shorter waiting path. | test services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day |
| alternate | 1 | Execution never reached a participant task. | Repair the stranded workspace after job reconciliation. | Staff can retry or request removal from failed lifecycle. | test services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js#moves the stranded tenant to provisioning_failed, which makes it retryable and deletable again |
| failure | 5 | The existing build did not fail. | Reject the retry request. | Workspace and job remain unchanged. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#refuses to provision a tenant again whose provisioning did not fail |
| Id | Statement | Provenance |
|---|---|---|
01 | Failure retains the constructed resources and a readable explanation. | test services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#says so in the snapshot too, with the failure summary the task refused with |
02 | Replacement construction completes outstanding work without duplicating completed steps. | test services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does the missing work and not the finished work when it is provisioned again |
03 | Disposal of the disabled never-opened fixture uses a one-day eligibility period. | test services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day |
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.