Rhythm 2.0 Specifications

Appearance

CAP-PFM-TNL-006Preserve valid workspace lifecycle states

Markdown

CAP-PFM-TNL-006

Preserve valid workspace lifecycle states

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-TNL-02
Exercised by
FAS-PFM-TNL-02-01, FAS-PFM-TNL-02-02, FAS-PFM-TNL-02-03, FAS-PFM-TNL-02-04, FAS-PFM-TNL-02-05, JNY-PFM-TNL-003, JNY-PFM-TNL-004
Key concepts
CON-PFM-TNL-001
Actors
ACT-PFM-012, ACT-PFM-004
Related
CAP-PFM-TNL-002, CAP-PFM-TNL-005, CAP-PFM-TNL-011, CAP-PFM-TNL-013, CAP-PFM-TNL-014, CAP-PFM-TNL-016
Open questions
OQ-PFM-TNL-003
Proved by
ATS-PFM-TNL-006

Implementation

Executable suites
TST-PFM-TNL-052, TST-PFM-TNL-077, TST-PFM-TNL-096

KindCapabilityProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65

Preserve valid workspace lifecycle states ​

Purpose ​

Lifecycle workflows maintain a state that follows allowed transitions and agrees with the workspace’s business mode.

How It Works ​

Staff see lifecycle separately from business status. A client editing ordinary workspace fields cannot write the lifecycle axis or first activation time. Construction, loading, activation and deletion workflows make those changes. The transition policy limits each move and accepts a repeat of the current state. Database checks keep loading tied to implementation mode. The same checks keep pending or executing deletion tied to disabled status. Staff must cancel deletion before separately re-enabling the workspace. Disposable fixtures use a testing convention that is refused in Production.

Relationships ​

  • Open a workspace after its applications are ready: Its readiness and activation finish workspace construction.
  • Apply workspace availability consistently: Its access decision determines when callers can use the workspace.
  • Control the initial import and subsequent opening: Its loading period and activation decision control initial import availability.
  • Schedule deliberate workspace deletion: The capabilities share the workspace’s recorded lifecycle decision.
  • 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.

The Formal Contract

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

Outcomes
Client inputs cannot replace system lifecycle facts.Lifecycle transitions accept only permitted paths and harmless repeats.Loading and deletion retain their required business statuses.
Surfaces
apijob
Intent sources
services-platform:docs/tenants/tenant-lifecycle-plan.md#§2.2services-platform:docs/proposals/rhythm-data-job-engine-plan.md#§21.3 D5

Controls

29 controls apply, from the corpus control catalogue.

TC-AVL-001 TC-AVL-004 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-DAT-006 TC-IAM-001 TC-IAM-003 TC-IAM-006 TC-LOG-001 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 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.manage-statusapiglobal

Business Rules

7 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
Client writes discard lifecycle state and first-activation time; lifecycle workflows control those values.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§2.2 No API sets lifecycle_state directly (approved)
proved by ATS-PFM-TNL-006-01
invariantapi, servicetest
services-platform:modules/tenants/tests/integration/services/persistence/tenants.integration.spec.js#ignores a lifecycle state a write input carries, rather than letting a client set the system axis
02must prove
Proposed
Allowed lifecycle moves connect provisioning to active or failed, failed to provisioning or deletion pending, active to loading or deletion pending, loading to active or deletion pending, and deletion pending to active or deleting; deleting has no successor.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§2.2 Transitions (approved); services-platform:docs/proposals/rhythm-data-job-engine-plan.md#§12.1 (D5)
proved by ATS-PFM-TNL-006-02, TST-PFM-TNL-096
lifecycleservicetest
services-platform:modules/tenants/tests/unit/services/lifecycle/lifecycle-transitions.spec.js#refuses deleting, so nothing can skip the waiting period by writing the state
03must prove
Proposed
Repeating the current lifecycle state succeeds without a transition or further state change.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§2.2 (approved)
proved by ATS-PFM-TNL-006-03, TST-PFM-TNL-096
invariantservicetest
services-platform:modules/tenants/tests/unit/services/lifecycle/lifecycle-transitions.spec.js#allows deleting to deleting, so a retried purge step is idempotent
04must prove
Proposed
Database checks require disabled status during pending deletion and destruction, and implementation status during loading.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§2.2 (approved); services-platform:docs/proposals/rhythm-data-job-engine-plan.md#§21.4 (Andrew, 2026-10-11)
proved by ATS-PFM-TNL-006-04, ATS-PFM-TNL-006-07, TST-PFM-TNL-077
invariantdatabasetest
services-platform:modules/tenants/tests/integration/services/persistence/tenants.integration.spec.js#refuses a status change the lifecycle forbids, by the rule the database holds
05must prove
Proposed
Business-status changes belong to authorized Rhythm staff; customer administrators may correct ordinary workspace details but cannot change that status.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§2.2 Who can change status (approved)
proved by ATS-PFM-TNL-006-05, TST-PFM-TNL-052
permissionapitest
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not disable it, because cutting an association off is a staff act
06
Proposed
Direct fixture creation outside a provisioning submission defaults the workspace to active lifecycle.
lifecycleservicetest
services-platform:modules/tenants/tests/e2e/tenants.e2e.spec.js#answers the lifecycle state of a tenant created ready to use
07must prove
Proposed
Disposable workspaces are a testing convention and their creation is rejected in Production.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.3 Disposable test tenants (approved)
proved by ATS-PFM-TNL-006-06, TST-PFM-TNL-077
validationservicetest
services-platform:modules/tenants/tests/integration/services/persistence/tenants.integration.spec.js#refuses a disposable tenant in Production, where no such tenant exists

Scenarios

IdGivenWhenThenProvenance
01A disabled workspace awaits deletion.A write attempts to make its status live while leaving deletion pending.The database rejects the inconsistent axes.test
services-platform:modules/tenants/tests/integration/services/persistence/tenants.integration.spec.js#refuses a status change the lifecycle forbids, by the rule the database holds

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