Rhythm 2.0 Specifications

Appearance

ATS-PFM-TNL-014Pause or cancel deletion while preservation remains possible: Capability Test Specification

Markdown

ATS-PFM-TNL-014

Pause or cancel deletion while preservation remains possible: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-014

Design

Executed by
TST-PFM-TNL-062

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

Pause or cancel deletion while preservation remains possible: 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-014-01ATS-PFM-TNL-014-01
BR-CAP-PFM-TNL-014-02ATS-PFM-TNL-014-02
BR-CAP-PFM-TNL-014-03ATS-PFM-TNL-014-03
BR-CAP-PFM-TNL-014-04ATS-PFM-TNL-014-04
BR-CAP-PFM-TNL-014-05ATS-PFM-TNL-014-05, ATS-PFM-TNL-014-07
BR-CAP-PFM-TNL-014-06ATS-PFM-TNL-014-06
BR-CAP-PFM-TNL-014-07No scenario: FND-PFM-TNL-079

Cancellation does not imply delivery of its notice. 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-015ATS-PFM-TNL-014-07 (proposed)
CAP-PFM-TNL-016ATS-PFM-TNL-014-07 (proposed)

Coverage

  • Rule gap: FND-PFM-TNL-079
  • Transition gap: FND-PFM-TNL-079
  • Validation covered
  • Permission covered
  • Edge covered
  • Failure gap: FND-PFM-TNL-079
  • Boundary covered
  • Concurrency gap: FND-PFM-TNL-079
  • Invariant gap: FND-PFM-TNL-079
  • Interaction covered

Test Scenarios

7 scenarios proving CAP-PFM-TNL-014; 6 bound to an existing test.

01 Customer context cannot administer deletionpermissionapinegativetest
Proves
BR-CAP-PFM-TNL-014-01
Preconditions
A deletion request remains open.
Steps
Attempt hold, release, cancellation, read and list with customer authority.
Expected
Every call refuses without changing the 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/e2e/tenant-deletion-requests.e2e.spec.js#leaves the request exactly as it was after all of those refusals
Source
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not hold a deletion request
02 Action inputs must be accountable and currentvalidationapinegativetest
Proves
BR-CAP-PFM-TNL-014-02
Preconditions
Staff target a scheduled request.
Steps
Hold with an invalid reason and a stale version.
Expected
Both attempts leave it scheduled.
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/deletion-holds.integration.spec.js#refuses a hold with no reason worth reading
03 Holding preserves eligibilitytransitionapitest
Proves
BR-CAP-PFM-TNL-014-03
Preconditions
The request is scheduled.
Steps
Hold it with a reason, then repeat hold.
Expected
The first records the pause and actor without moving the date; repetition refuses.
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/deletion-holds.integration.spec.js#answers a held request
04 Release leaves a minimum review intervalboundaryapitest
Proves
BR-CAP-PFM-TNL-014-04
Preconditions
Held fixtures have distant, imminent and elapsed dates.
Steps
Release each fixture.
Expected
The distant date persists and others receive three days, with a new final reminder.
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/deletion-holds.integration.spec.js#keeps the date it had when that date is still far off
05 Cancellation preserves disabled statustransitionapitest
Proves
BR-CAP-PFM-TNL-014-05
Preconditions
One request is scheduled and another held.
Steps
Cancel both.
Expected
Both decisions are retained as cancelled and their workspaces are active but disabled.
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/deletion-holds.integration.spec.js#leaves the tenant disabled: calling off a deletion restores nobody access
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#leaves the tenant disabled: calling off a deletion restores nobody access
Source
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#answers a cancelled request
06 Execution prevents cancellationedgeapinegativetest
Proves
BR-CAP-PFM-TNL-014-06
Preconditions
The request has passed into executing.
Steps
Attempt to cancel it.
Expected
The response reports irreversible execution and preserves request state.
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#matches nothing once the request is executing, which is the point of no return
Source
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#refuses to cancel a request whose destruction has begun
07 Cancellation does not imply delivery of its noticeinteractionapinegativeproposed
Proves
BR-CAP-PFM-TNL-014-05
Preconditions
A reversible deletion request has its normal watcher sleeping.
Steps
Cancel it, inspect the stored cancellation obligation and let the ordinary watcher revisit the request.
Expected
The workspace remains disabled with active lifecycle; the obligation exists, but the ordinary watcher ends on cancelled standing without sending that cancellation notice.
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-014-hold-release-or-call-off-a-deletion-before-destruction.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-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-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