Rhythm 2.0 Specifications

Appearance

CAP-PFM-TNL-015Keep deletion decisions visible to staff

Markdown

CAP-PFM-TNL-015

Keep deletion decisions visible to staff

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-TNL-05
Key concepts
CON-PFM-TNL-005
Actors
ACT-PFM-004, ACT-PFM-039, ACT-PFM-012
Journeys
JNY-PFM-TNL-004
Depends on
CAP-PFM-TNL-013
Related
CAP-PFM-TNL-014, CAP-PFM-TNL-016, CAP-PFM-TNL-017
Proved by
ATS-PFM-TNL-015

KindCapabilityProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65

Keep deletion decisions visible to staff ​

Purpose ​

Deletion notices explain the request, changes and result, and required delivery states gate destruction.

How It Works ​

Request creation establishes the notice obligations for the waiting period. The schedule job sends each due notice and waits for the next due instant. Holds, releases and cancellation add their own notices. Destruction start and completion or failure are announced too. The recipient list combines the environment’s internal staff list and requester. An absent staff list is a delivery problem rather than permission to skip notification. The request notice and latest one-day reminder must be delivered or environment-suppressed before destruction. Failed gating notices keep the schedule waiting. Notice records retain attempts and errors, while record deduplication does not guarantee exactly-once message delivery.

Relationships ​

  • Schedule deliberate workspace deletion: 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.
  • Revalidate the irreversible deletion decision: The capabilities share the workspace’s recorded lifecycle decision.
  • Remove declared workspace resources and verify the result: Its batches and inventory determine the removal result.

The Formal Contract

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

Outcomes
Recipients are the internal staff list and requester.The request notice and latest one-day reminder gate destruction.Failed delivery retains the waiting state.
Surfaces
job
Intent sources
services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D8

Controls

25 controls apply, from the corpus control catalogue.

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

Business Rules

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

IdRuleKindEnforced atProvenance
01must prove
Proposed
Request creation schedules an immediate notice, a seven-day reminder for waits of at least eight days, and a one-day reminder that is immediate for waits shorter than two days.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Reminder schedule (approved)
no proof recorded yet
calculationservicetest
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is due at once just below two days, so a short period still has the notice destruction waits for
02must prove
Proposed
Notice obligations also accompany holds, releases, cancellation, destruction start and the final success or failure.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 (approved)
no proof recorded yet
policyservicetest
services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#owes an executing notice, so somebody is told the point of no return was passed
03must prove
Proposed
Deletion notices target the environment’s staff list and the requester; the system sends no customer-facing deletion notice.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4 (Andrew, 2026-10-09); §13 D8 (default in force)
no proof recorded yet
policyservicetest
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#tells the staff list and the requester, and nobody else
04must prove
Proposed
The watcher sends due notices and waits for the next due time; unique kind-and-date slots deduplicate records without ensuring exactly-once message delivery.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Delivery (approved)
no proof recorded yet
invariantservice, databasetest
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#slept until each notice was due rather than polling, and never for a fixed duration
05must prove
Proposed
Destruction requires the request notice and latest one-day reminder to be delivered or environment-suppressed; a failed gating notice keeps it waiting.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Notices that gate destruction (approved)
no proof recorded yet
policyservicetest
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced
06
Proposed
A notice retains delivery state, attempt count, error, recipients and delivery time as its sending history.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Record (approved)
invariantdatabasetest
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#counts every attempt, so a notice presented forty times reads differently from one presented once
07must prove
Proposed
An unconfigured staff list causes notice failure rather than silent omission and prevents destruction from beginning.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§13 D4 (Andrew, 2026-10-09)
no proof recorded yet
policyserviceobserved
services-platform:modules/tenants/services/deletion/notices/notice-recipients.ts (header, An unset list is a failure)
08
Proposed
Accumulating notices never evicts the notice records required to authorize destruction.
invariantservicetest
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#never drops the requested notice, which destruction waits for

Scenarios

IdGivenWhenThenProvenance
01The mail provider rejects the final gating reminder.The request reaches its eligibility date.Destruction remains waiting and subsequent checks continue rather than deleting silently.test
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced

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