Skip to content

ATS-PFM-TNL-015Keep deletion decisions visible to staff: Capability Test Specification

Markdown

ATS-PFM-TNL-015

Keep deletion decisions visible to staff: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-015

Design

Executed by
TST-PFM-TNL-064

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

Coverage

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

Test Scenarios

6 scenarios proving CAP-PFM-TNL-015; 5 bound to an existing test.

01 Reminder timing follows the chosen waitboundaryunittest
Proves
BR-CAP-PFM-TNL-015-01
Preconditions
The fixture covers long, boundary and short waiting periods.
Steps
Calculate request notice obligations.
Expected
Seven-day reminders require at least eight days and final reminders become immediate below two 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#owes the notice at request, the seven-day reminder and the one-day reminder, in that order
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is owed at exactly eight days, the shortest period with room for it
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is skipped just below eight days, where it would fall before the request itself
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
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is due at once for a one-day period, the never-active tenant
services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes both of those notices due at once, or a tenant with a one-day period could never be deleted
Source
services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#owes the notice at request, the seven-day reminder and the one-day reminder, in that order
02 State changes create notice obligationstransitionapitest
Proves
BR-CAP-PFM-TNL-015-02
Preconditions
Fixtures exercise hold, release, execution, completion and failure.
Steps
Inspect notice obligations after each event.
Expected
Each event retains the corresponding notice kind.
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#owes a notice, because a schedule that changes silently is a schedule nobody can trust
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
Source
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes a notice, because a schedule that changes silently is a schedule nobody can trust
03 Recipients remain internalpermissionapitest
Proves
BR-CAP-PFM-TNL-015-03
Preconditions
The request advances through its waiting period.
Steps
Inspect captured recipients for each notice.
Expected
Recipients are the staff list and requester, with no customer-facing addition.
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/tenant-deletion-schedule.integration.spec.js#tells the staff list and the requester, and nobody else
04 Notice slots deduplicate recorded obligationsinvariantapitest
Proves
BR-CAP-PFM-TNL-015-04
Preconditions
A thirty-day request is scheduled.
Steps
Run its notice schedule and append an existing slot again.
Expected
Notices occur at their due times and repeated slot insertion adds no duplicate record.
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/tenant-deletion-schedule.integration.spec.js#slept until each notice was due rather than polling, and never for a fixed duration
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores a notice whose schedule slot is already taken, so a re-run sends nothing twice
Source
services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends the requested notice on the day of the request
05 Failed gating notices prevent destructionfailureapinegativetest
Proves
BR-CAP-PFM-TNL-015-05
Preconditions
A required notice has failed and another fixture is environment-suppressed.
Steps
Advance schedules beyond eligibility.
Expected
Failure continues waiting with the notice identified, while suppression satisfies the gate.
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/tenant-deletion-schedule.integration.spec.js#holds the deletion indefinitely when a notice could not be delivered, rather than destroying the tenant unannounced
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#still lists a failed notice, so a send that never worked never lets a tenant be deleted
services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores a seven-day reminder that was never sent: only two kinds gate destruction
Source
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 Gating delivery controls the irreversible handoffinteractionapinegativeproposed
Proves
BR-CAP-PFM-TNL-015-05
Preconditions
An eligible scheduled deletion has a failed final-reminder notice.
Steps
Run the destruction check, record delivery or policy suppression for the obligation and run the check again.
Expected
The first check keeps the decision reversible; a satisfied gate allows the remaining safeguards to decide whether purge may begin.
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-015-tell-rhythm-staff-about-every-step-of-a-deletion.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-016-begin-destruction-only-when-every-safeguard-still-holds.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-014-hold-release-or-call-off-a-deletion-before-destruction.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.