--- id: ATS-PFM-TNL-013 scope: CAP-PFM-TNL-013 product_area: platform module: tenant-lifecycle revision: 3 status: proposed approved_by: null approved_at: null source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69 services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b services-committees: 36129c24daeaadcdb339218c38cdeaff9861359d services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 services-submissions: 64236c19be89579ef5897aad7de3925ed3ce03bf services-websites: 5fc6823c69d5e6f208c21dba8c0eb3132f8bdc4c services-marketing: d071a159fe9782bb71ff246d5c67d5bbfe07fbfa rhythm-v2-docs: d318a948692343e2f0a7ecc2e11c50db179a8c95 scenarios: - id: ATS-PFM-TNL-013-01 title: Customer authority cannot request removal level: api proves: - BR-CAP-PFM-TNL-013-01 preconditions: An eligible disabled workspace is available. steps: Request deletion as customer-admin and non-staff identities. expected: No deletion request is recorded. negative: true data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a caller who is not Rhythm staff - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#writes no request for a caller who is not Rhythm staff provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted category: permission action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted binding_note: >- The original test-title references contribute separate assertions from several files. No suite receives an implements link for the complete combined scenario; a full executable mapping remains FND-PFM-TNL-084. binding_gap: FND-PFM-TNL-084 - id: ATS-PFM-TNL-013-02 title: Confirmation rejects stale or mistaken decisions level: api proves: - BR-CAP-PFM-TNL-013-03 preconditions: Staff have read a disabled workspace. steps: 'Submit wrong-name, identifier-as-name, short-reason and stale-version variants.' expected: Each refuses and name errors identify the confirmation input. negative: true data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a confirmation that does not repeat the tenant's name as 400 - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#names the confirmation in that refusal, so the person knows what to type - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a confirmation that repeats the tenant id, which is no longer what the person types - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a reason too short to tell anybody anything - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that has changed since the screen was drawn - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a body with no version as 400 provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a confirmation that does not repeat the tenant's name as 400 category: validation action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a confirmation that does not repeat the tenant's name as 400 assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a confirmation that does not repeat the tenant's name as 400 binding_note: >- The original test-title references contribute separate assertions from several files. No suite receives an implements link for the complete combined scenario; a full executable mapping remains FND-PFM-TNL-084. binding_gap: FND-PFM-TNL-084 - id: ATS-PFM-TNL-013-03 title: Ineligible workspace removal is refused level: api proves: - BR-CAP-PFM-TNL-013-04 preconditions: 'Fixtures cover enabled, outgoing, locked, parent and protected workspaces.' steps: Request deletion for each. expected: The refusal identifies the failed condition and records no new protected-workspace request. negative: true data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still live, because people must lose access first - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still being implemented, for the same reason - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is being deleted - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is locked - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is somebody else parent - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a well-known tenant the whole development environment is built on - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a tenant that is still live as 409 provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still live, because people must lose access first category: validation action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still live, because people must lose access first assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still live, because people must lose access first binding_note: >- The original test-title references contribute separate assertions from several files. No suite receives an implements link for the complete combined scenario; a full executable mapping remains FND-PFM-TNL-084. binding_gap: FND-PFM-TNL-084 - id: ATS-PFM-TNL-013-04 title: Database and service prevent duplicate requests level: api proves: - BR-CAP-PFM-TNL-013-05 preconditions: The workspace has an open request. steps: Request another and attempt a direct duplicate insert. expected: Both refuse and one open request remains. negative: true data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#leaves the tenant with exactly one request after the refusal - >- services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#refuses a second open request for the same tenant, by the index and not only by the service - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a second request for the same tenant as 409 provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open category: concurrency action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open binding_note: >- The original test-title references contribute separate assertions from several files. No suite receives an implements link for the complete combined scenario; a full executable mapping remains FND-PFM-TNL-084. binding_gap: FND-PFM-TNL-084 - id: ATS-PFM-TNL-013-05 title: Cancellation is retained rather than revived level: api proves: - BR-CAP-PFM-TNL-013-06 preconditions: An earlier request is cancelled. steps: Request deletion again. expected: A new date and request are recorded beside the cancelled history. negative: false data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#allows a new request, with a new waiting period, once the first is cancelled - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#leaves the cancelled request in the history beside the new one - TST-PFM-TNL-063 provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#allows a new request, with a new waiting period, once the first is cancelled category: transition action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#allows a new request, with a new waiting period, once the first is cancelled assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#allows a new request, with a new waiting period, once the first is cancelled binding_note: >- All cited checks for this scenario occur in the registered file. The link establishes inspected executable source rather than a passing run. - id: ATS-PFM-TNL-013-06 title: Standard wait honors the Production floor level: unit proves: - BR-CAP-PFM-TNL-013-07 preconditions: Waiting-period inputs exercise default and configured values. steps: Compute eligibility for ordinary workspaces. expected: Default is thirty days; Production rejects thirteen and accepts fourteen days. negative: false data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#becomes eligible thirty days after the request - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#refuses a configured period below fourteen days rather than quietly raising it - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#accepts exactly fourteen days (the boundary, the negative control) - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#records the thirty-day waiting period Andrew set - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#fixes the date destruction may begin, thirty days on by the calendar of the tenant zone - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#answers the thirty-day waiting period provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#becomes eligible thirty days after the request category: boundary action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#becomes eligible thirty days after the request assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#becomes eligible thirty days after the request binding_note: >- The original test-title references contribute separate assertions from several files. No suite receives an implements link for the complete combined scenario; a full executable mapping remains FND-PFM-TNL-084. binding_gap: FND-PFM-TNL-084 - id: ATS-PFM-TNL-013-07 title: No first activation selects the one-day path level: unit proves: - BR-CAP-PFM-TNL-013-08 preconditions: The workspace has no first-activation record. steps: Compute eligibility inside and outside Production. expected: Both calculations select one day. negative: false data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day, because no association ever used it - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day in Production too, where the fourteen-day floor does not apply to it - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day, because no association ever used it category: boundary action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day, because no association ever used it assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day, because no association ever used it binding_note: >- The original test-title references contribute separate assertions from several files. No suite receives an implements link for the complete combined scenario; a full executable mapping remains FND-PFM-TNL-084. binding_gap: FND-PFM-TNL-084 - id: ATS-PFM-TNL-013-08 title: Disposable acceleration is environment-limited level: unit proves: - BR-CAP-PFM-TNL-013-09 preconditions: Fixtures include disposable and ordinary workspaces in Production and outside it. steps: Request reduced waiting periods. expected: Only disposable non-Production fixtures use the minute path. negative: true data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits ten minutes outside Production, so an automated test can watch a whole deletion - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused a period longer than the configured one, so the field can only shorten - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused for a tenant that is not disposable, rather than ignored - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused in Production even for a disposable tenant - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses the disposable path in Production, where no tenant is disposable provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits ten minutes outside Production, so an automated test can watch a whole deletion category: boundary action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits ten minutes outside Production, so an automated test can watch a whole deletion assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits ten minutes outside Production, so an automated test can watch a whole deletion binding_note: >- The original test-title references contribute separate assertions from several files. No suite receives an implements link for the complete combined scenario; a full executable mapping remains FND-PFM-TNL-084. binding_gap: FND-PFM-TNL-084 - id: ATS-PFM-TNL-013-09 title: Request and watcher are recorded together level: api proves: - BR-CAP-PFM-TNL-013-10 preconditions: Staff confirm an eligible disabled workspace. steps: Submit the deletion decision. expected: >- The scheduled request, copied identities, notice obligations, pending lifecycle and watcher job are recorded. negative: false data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#records who asked and why - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#moves the tenant to deletion_pending - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#owes the notice destruction waits for - >- services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#submits one schedule job with the request, before anything has waited - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#moves the tenant to deletion_pending, read back through the tenants API provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone category: transition action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone binding_note: >- The original test-title references contribute separate assertions from several files. No suite receives an implements link for the complete combined scenario; a full executable mapping remains FND-PFM-TNL-084. binding_gap: FND-PFM-TNL-084 - id: ATS-PFM-TNL-013-10 title: Failed-build disposal uses its shorter wait level: api proves: - AS-JNY-PFM-TNL-002-03 preconditions: The recovery journey includes a never-opened failed build. steps: Request its deletion after disabling it. expected: The recorded request becomes eligible a day later. negative: false data_needs: >- Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared. bound_to: - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#fixes that tenant date one day on - TST-PFM-TNL-063 provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day category: interaction action_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day assertion_evidence: provenance: test source: >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day binding_note: >- All cited checks for this scenario occur in the registered file. The link establishes inspected executable source rather than a passing run. - id: ATS-PFM-TNL-013-11 title: A committed request survives a watcher start failure category: interaction level: api proves: - BR-CAP-PFM-TNL-013-10 interacts_with: - CAP-PFM-TNL-015 - CAP-PFM-TNL-014 - CAP-PFM-TNL-016 preconditions: A disabled eligible workspace is reviewed by authorized staff and its execution starter will fail. steps: >- Request deletion, inspect the retained request, notices and watcher job, then invoke schedule recovery after settlement. expected: >- The committed decision and notice obligations remain; recovery replaces execution without changing the decision or its eligibility date. negative: true data_needs: >- Create a separate run-owned workspace for each decision branch and an unaffected comparison workspace. Use a controlled clock, paused task or injected fault at the boundary named in the scenario. bound_to: [] provenance: proposed source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-013-ask-for-a-workspace-to-be-deleted-after-a-waiting-period.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-015-tell-rhythm-staff-about-every-step-of-a-deletion.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-014-hold-release-or-call-off-a-deletion-before-destruction.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-016-begin-destruction-only-when-every-safeguard-still-holds.md action_evidence: provenance: proposed source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-013-ask-for-a-workspace-to-be-deleted-after-a-waiting-period.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-015-tell-rhythm-staff-about-every-step-of-a-deletion.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-014-hold-release-or-call-off-a-deletion-before-destruction.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-016-begin-destruction-only-when-every-safeguard-still-holds.md assertion_evidence: provenance: proposed source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-013-ask-for-a-workspace-to-be-deleted-after-a-waiting-period.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-015-tell-rhythm-staff-about-every-step-of-a-deletion.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-014-hold-release-or-call-off-a-deletion-before-destruction.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-016-begin-destruction-only-when-every-safeguard-still-holds.md evidence: - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted - >- services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#refuses a confirmation that does not repeat the tenant's name as 400 - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a tenant that is still live, because people must lose access first - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#allows a new request, with a new waiting period, once the first is cancelled - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#becomes eligible thirty days after the request - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day, because no association ever used it - >- services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits ten minutes outside Production, so an automated test can watch a whole deletion - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#copies the tenant name and customer, so the record still reads after the tenant is gone - >- services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day - >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-013-ask-for-a-workspace-to-be-deleted-after-a-waiting-period.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-015-tell-rhythm-staff-about-every-step-of-a-deletion.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-014-hold-release-or-call-off-a-deletion-before-destruction.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-016-begin-destruction-only-when-every-safeguard-still-holds.md coverage: rule: 'gap: FND-PFM-TNL-078' transition: 'gap: FND-PFM-TNL-078' validation: covered permission: covered edge: 'gap: FND-PFM-TNL-078' failure: 'gap: FND-PFM-TNL-078' boundary: covered concurrency: covered invariant: 'gap: FND-PFM-TNL-078' interaction: 'gap: FND-PFM-TNL-078' coverage_notes: transition: >- The listed scenarios sample lifecycle changes. Complete transition, guard and side-effect proof is still owed for the state models named in the coverage finding. interaction: >- The added interaction is proposed. Related capabilities not included in that scenario remain named in the coverage finding. transition_obligations: - state_model: STATE-PFM-TNL-001 transition_n: 1 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/persistence/tenants.ts:activateProvisionedTenant' - state_model: STATE-PFM-TNL-001 transition_n: 2 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: >- services-platform:modules/tenants/services/provisioning/provision-tenant-failure.ts:applyTenantProvisioningFailure - state_model: STATE-PFM-TNL-001 transition_n: 3 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: >- services-platform:modules/tenants/services/provisioning/submit-tenant-provisioning.ts:retryTenantProvisioning - state_model: STATE-PFM-TNL-001 transition_n: 4 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/request-deletion.ts:requestTenantDeletion' - state_model: STATE-PFM-TNL-001 transition_n: 5 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/persistence/tenants.ts:enterTenantLoading' - state_model: STATE-PFM-TNL-001 transition_n: 6 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/request-deletion.ts:requestTenantDeletion' - state_model: STATE-PFM-TNL-001 transition_n: 7 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/persistence/tenants.ts:activateLoadedTenant' - state_model: STATE-PFM-TNL-001 transition_n: 8 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/lifecycle/lifecycle-transitions.ts:SUCCESSORS' - state_model: STATE-PFM-TNL-001 transition_n: 9 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/deletion-holds.ts:cancelTenantDeletion' - state_model: STATE-PFM-TNL-001 transition_n: 10 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/begin-destruction.ts:beginTenantDestruction' - state_model: STATE-PFM-TNL-001 transition_n: 11 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/persistence/tenants.ts:forceTenantDeletingAfterRestore' - state_model: STATE-PFM-TNL-004 transition_n: 1 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/deletion-holds.ts:holdTenantDeletion' - state_model: STATE-PFM-TNL-004 transition_n: 2 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/begin-destruction.ts:beginTenantDestruction' - state_model: STATE-PFM-TNL-004 transition_n: 3 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/deletion-holds.ts:releaseTenantDeletion' - state_model: STATE-PFM-TNL-004 transition_n: 4 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/deletion-holds.ts:cancelTenantDeletion' - state_model: STATE-PFM-TNL-004 transition_n: 5 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/deletion-holds.ts:cancelTenantDeletion' - state_model: STATE-PFM-TNL-004 transition_n: 6 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/begin-destruction.ts:beginTenantDestruction' - state_model: STATE-PFM-TNL-004 transition_n: 7 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/tenant-purge-operations.ts:tenantPurgeOperations' - state_model: STATE-PFM-TNL-004 transition_n: 8 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/tenant-purge-failure.ts:applyTenantPurgeFailure' - state_model: STATE-PFM-TNL-004 transition_n: 9 coverage: 'gap: FND-PFM-TNL-078' provenance: observed source: 'services-platform:modules/tenants/services/deletion/operator-recovery.ts:retryTenantPurge' permission_obligations: - key: platform.tenants.deletion-request where_checked: api scenario_examples: - ATS-PFM-TNL-013-01 coverage: 'gap: FND-PFM-TNL-078' note: 'Examples do not establish the complete key-by-key grant, revoked-grant and staff-context matrix.' provenance: documented source: >- rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-013-ask-for-a-workspace-to-be-deleted-after-a-waiting-period.md evidence_note: >- The test-specific convention lists an Evidence body section, but the corpus checker rejects it. Sources and verification limits remain in frontmatter so this artifact conforms without changing the checker. --- # Schedule deliberate workspace deletion: Capability Test Specification ## Coverage The category map separates defined scenarios from missing proof. A covered category has a scenario; a binding records inspected test assertions and carries no execution result. State-model completeness and untested interactions remain explicit gaps. | Rule | Proved by | |---|---| | `BR-CAP-PFM-TNL-013-01` | `ATS-PFM-TNL-013-01` | | `BR-CAP-PFM-TNL-013-03` | `ATS-PFM-TNL-013-02` | | `BR-CAP-PFM-TNL-013-04` | `ATS-PFM-TNL-013-03` | | `BR-CAP-PFM-TNL-013-05` | `ATS-PFM-TNL-013-04` | | `BR-CAP-PFM-TNL-013-06` | `ATS-PFM-TNL-013-05` | | `BR-CAP-PFM-TNL-013-07` | `ATS-PFM-TNL-013-06` | | `BR-CAP-PFM-TNL-013-08` | `ATS-PFM-TNL-013-07` | | `BR-CAP-PFM-TNL-013-09` | `ATS-PFM-TNL-013-08` | | `BR-CAP-PFM-TNL-013-10` | `ATS-PFM-TNL-013-09`, `ATS-PFM-TNL-013-11` | | `BR-CAP-PFM-TNL-013-11` | No scenario: `FND-PFM-TNL-078` | ## Interactions With Related Capabilities A committed request survives a watcher start failure. The combined scenario sets up the stated boundary, changes the upstream condition and observes its effect on the dependent outcome. Its steps and assertions are proposed; component tests do not establish this combined execution. | Related capability | Combined coverage | |---|---| | `CAP-PFM-TNL-014` | `ATS-PFM-TNL-013-11` (proposed) | | `CAP-PFM-TNL-015` | `ATS-PFM-TNL-013-11` (proposed) | | `CAP-PFM-TNL-016` | `ATS-PFM-TNL-013-11` (proposed) | | `CAP-PFM-TNL-003` | Gap: `FND-PFM-TNL-078` |