Rhythm 2.0 Specifications

Appearance

CAP-PFM-TNL-013Schedule deliberate workspace deletion

Markdown

CAP-PFM-TNL-013

Schedule deliberate workspace deletion

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-TNL-05
Key concepts
CON-PFM-TNL-005, CON-PFM-TNL-001
Actors
ACT-PFM-004
Journeys
JNY-PFM-TNL-002, JNY-PFM-TNL-004
Depends on
CAP-PFM-TNL-006
Related
CAP-PFM-TNL-014, CAP-PFM-TNL-015, CAP-PFM-TNL-016, CAP-PFM-TNL-003
Open questions
OQ-PFM-TNL-003
Proved by
ATS-PFM-TNL-013

KindCapabilityProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65

Schedule deliberate workspace deletion ​

Purpose ​

Authorized staff record a deletion decision and its fixed eligibility date before any destruction.

How It Works ​

Staff first disable the workspace to close customer access. They request deletion using the exact workspace name, a reason and the version they reviewed. The service locks the workspace and checks its eligibility. Children, locks, protected identities or an unsuitable state produce a refusal. A successful request records identity snapshots and a waiting period. It also records required notices and the schedule job in the same transaction. The workspace moves to deletion pending, but no records are destroyed. A customer can be marked for removal with its last workspace. Another request cannot coexist with an open one, and a request after cancellation begins a fresh waiting period.

Relationships ​

  • Preserve valid workspace lifecycle states: Its result establishes the state or declared resources needed by this operation.
  • Pause or cancel deletion while preservation remains possible: The capabilities share the workspace’s recorded lifecycle decision.
  • Keep deletion decisions visible to staff: The capabilities share the workspace’s recorded lifecycle decision.
  • Revalidate the irreversible deletion decision: The capabilities share the workspace’s recorded lifecycle decision.
  • Understand and recover a workspace build: Its snapshots and recovery explain interrupted construction.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Deletion starts from a disabled, eligible workspace with typed name confirmation.Later configuration changes do not shorten the recorded waiting period.Only one request remains open and cancellation is retained as history.
Surfaces
consoleapijob
Intent sources
services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.1services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.2services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.3services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.7services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D1, D2, D3

Controls

29 controls apply, from the corpus control catalogue.

TC-AVL-001 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-DAT-001 TC-DAT-003 TC-DAT-004 TC-IAM-001 TC-IAM-002 TC-IAM-003 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-003 TC-PI-005 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
platform.tenants.deletion-requestapiglobal

Business Rules

12 rules, 10 to be proved before approval. A rule's product intent is derived from its origin: 12 confirmed by a product decision, the rest inheriting this capability's confirmed.

IdRuleKindEnforced atProvenance
01must prove
Confirmed
Deletion requests require Rhythm staff with deletion-request authority and are unavailable to customer administrators.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.2 (approved 2026-10-09)
no proof recorded yet
permissionapi, servicetest
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not ask for a tenant to be deleted
02
Confirmed
The requesting staff member is the sole approver; deletion requires no second authorization person.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D2 (Andrew, 2026-10-09)
policyservicedocumented
services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D2
03must prove
Confirmed
A request repeats the workspace name, supplies a reason of ten to two thousand characters and includes the version staff reviewed.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.2 (approved); services-platform:docs/hq/rhythm-hq-plan.md#§D4
no proof recorded yet
validationapi, servicetest
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
04must prove
Confirmed
Deletion accepts a disabled active or provisioning-failed workspace that is unlocked, has no children and is not a protected development workspace.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.2 (approved 2026-10-09)
no proof recorded yet
validationservicetest
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
05must prove
Confirmed
Only one deletion request may remain open per workspace; service and database checks reject another and identify the existing request.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.7 (approved)
no proof recorded yet
invariantservice, databasetest
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#refuses a second request, naming the one that is open
06must prove
Confirmed
After cancellation, another deletion request creates a fresh history entry and waiting period rather than reviving the cancelled request.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.7 (approved)
no proof recorded yet
lifecycleservicetest
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
07must prove
Confirmed
Standard eligibility is fixed when requested, defaults to thirty days and refuses a Production setting below fourteen days.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D1 (Andrew, 2026-10-09)
no proof recorded yet
calculationservicetest
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#refuses a configured period below fourteen days rather than quietly raising it
08must prove
Confirmed
A workspace without a first activation time waits one day, including in Production.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D3 (default in force)
no proof recorded yet
calculationservicetest
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
09must prove
Confirmed
Outside Production, disposable test workspaces default to ten minutes and may request a shorter wait; the shortcut is refused for other workspaces and in Production.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.3 Disposable test tenants (approved)
no proof recorded yet
calculationservicetest
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is refused in Production even for a disposable tenant
10must prove
Confirmed
The request transaction copies workspace and customer identity, records the actor, reason and time, schedules notices and the watcher job, and moves the workspace to deletion pending.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.1, §5.4 (approved)
no proof recorded yet
lifecycleservice, databasetest
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#moves the tenant to deletion_pending
11must prove
Confirmed
Staff may request deletion of the customer with its final workspace; omission keeps the customer record.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.4 shared, platform.customers (approved)
no proof recorded yet
policyservicetest
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#carries the answer to what becomes of the customer
12
Confirmed
Long-disabled workspaces appear in a staff report rather than entering deletion automatically.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D9 (default in force)
policyserviceobserved
services-platform:modules/tenants/scripts/long-disabled.ts (header)

Scenarios

IdGivenWhenThenProvenance
01A departed association’s workspace is disabled.Staff confirm its name and request deletion.A standard request fixes eligibility thirty days later and records the request notice.test
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#answers a scheduled request against the tenant asked about
02A failed build has no first activation time.Staff request its deletion after disabling it.Eligibility is recorded one day after the request.test
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes a tenant that was never provisioned wait one day

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