Rhythm 2.0 Specifications

Appearance

ATS-PFM-TNL-013Schedule deliberate workspace deletion: Capability Test Specification

Markdown

ATS-PFM-TNL-013

Schedule deliberate workspace deletion: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-013

Design

Executed by
TST-PFM-TNL-063

KindAcceptance test setProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision3

Read atservices-platform ad3f6a65services-crm a8d1364fservices-commerce c8b66a98services-committees 36129c24services-membership 5994c270services-submissions 64236c19services-websites 5fc6823cservices-marketing d071a159rhythm-v2-docs d318a948

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.

RuleProved by
BR-CAP-PFM-TNL-013-01ATS-PFM-TNL-013-01
BR-CAP-PFM-TNL-013-03ATS-PFM-TNL-013-02
BR-CAP-PFM-TNL-013-04ATS-PFM-TNL-013-03
BR-CAP-PFM-TNL-013-05ATS-PFM-TNL-013-04
BR-CAP-PFM-TNL-013-06ATS-PFM-TNL-013-05
BR-CAP-PFM-TNL-013-07ATS-PFM-TNL-013-06
BR-CAP-PFM-TNL-013-08ATS-PFM-TNL-013-07
BR-CAP-PFM-TNL-013-09ATS-PFM-TNL-013-08
BR-CAP-PFM-TNL-013-10ATS-PFM-TNL-013-09, ATS-PFM-TNL-013-11
BR-CAP-PFM-TNL-013-11No scenario: FND-PFM-TNL-078

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 capabilityCombined coverage
CAP-PFM-TNL-014ATS-PFM-TNL-013-11 (proposed)
CAP-PFM-TNL-015ATS-PFM-TNL-013-11 (proposed)
CAP-PFM-TNL-016ATS-PFM-TNL-013-11 (proposed)
CAP-PFM-TNL-003Gap: FND-PFM-TNL-078

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

Test Scenarios

11 scenarios proving CAP-PFM-TNL-013; 10 bound to an existing test.

01 Customer authority cannot request removalpermissionapinegativetest
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.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
Source
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted
02 Confirmation rejects stale or mistaken decisionsvalidationapinegativetest
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.
Data
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
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
03 Ineligible workspace removal is refusedvalidationapinegativetest
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.
Data
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 well-known tenant the whole development environment is built on
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
04 Database and service prevent duplicate requestsconcurrencyapinegativetest
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.
Data
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/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
Source
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open
05 Cancellation is retained rather than revivedtransitionapitest
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.
Data
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
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
06 Standard wait honors the Production floorboundaryunittest
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.
Data
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#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#fixes the date destruction may begin, thirty days on by the calendar of the tenant zone
Source
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#becomes eligible thirty days after the request
07 No first activation selects the one-day pathboundaryunittest
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.
Data
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 in Production too, where the fourteen-day floor does not apply to it
Source
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#waits one day, because no association ever used it
08 Disposable acceleration is environment-limitedboundaryunitnegativetest
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.
Data
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/integration/services/deletion/request-deletion.integration.spec.js#refuses the disposable path in Production, where no tenant is disposable
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
09 Request and watcher are recorded togethertransitionapitest
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.
Data
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/e2e/tenant-deletion-requests.e2e.spec.js#moves the tenant to deletion_pending, read back through the tenants API
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
10 Failed-build disposal uses its shorter waitinteractionapitest
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.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
Source
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day
11 A committed request survives a watcher start failureinteractionapinegativeproposed
Proves
BR-CAP-PFM-TNL-013-10
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.
Data
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.
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

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software