Rhythm 2.0 Specifications

Appearance

CAP-PFM-TNL-002Open a workspace after its applications are ready

Markdown

CAP-PFM-TNL-002

Open a workspace after its applications are ready

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-TNL-01
Key concepts
CON-PFM-TNL-002, CON-PFM-TNL-003, CON-PFM-TNL-001
Actors
ACT-PFM-012
Journeys
JNY-PFM-TNL-001, JNY-PFM-TNL-002
Depends on
CAP-PFM-TNL-007, CAP-PFM-TNL-008
Related
CAP-PFM-TNL-001, CAP-PFM-TNL-003, CAP-PFM-TNL-006
Proved by
ATS-PFM-TNL-002
Exercised by
JNY-PFM-TNL-005

KindCapabilityProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65

Open a workspace after its applications are ready ​

Purpose ​

The customer gains access after all planned application participants finish and pass readiness checks.

How It Works ​

Platform derives a build plan from enabled participant declarations. It compares that plan with the participants described by the applications. A changed order or participant list stops the job with the difference reported. Each participant then builds its own resources in sequence. Completed steps are carried into a retry rather than invoked again. Readiness asks every planned participant to account for its resources. A missing item leaves the workspace closed and the build failed. Successful readiness permits activation in the requested business mode. Activation also establishes application and staff-access housekeeping, with different failure handling for those writes.

Relationships ​

  • Account for each application’s lifecycle responsibilities: The provisioning request records the job and its opening choices.
  • Apply defaults without undoing customer choices: Registration supplies the dependency plan.
  • Request a complete customer workspace: The capabilities share the workspace’s recorded lifecycle decision.
  • Understand and recover a workspace build: Its snapshots and recovery explain interrupted construction.
  • Preserve valid workspace lifecycle states: 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
Participant construction follows dependency order.A missing resource prevents opening and is identified for staff.Opening preserves the requested business mode and records first activation.
Surfaces
job
Intent sources
services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.2services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.5services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.2

Controls

23 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-IAM-003 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
hq.tenants.provisionserviceglobal

Business Rules

9 rules, 7 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
The provisioning plan orders enabled participants by dependency, starting with the workspace record.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.2 (approved 2026-10-09)
no proof recorded yet
calculationservicetest
services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#runs the tenant row before anything that depends on it
02must prove
Proposed
A difference between the live participant order and the stored plan stops execution before participant work and reports both orders.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.1 Registration (approved 2026-10-09)
no proof recorded yet
validationservicetest
services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#refuses a run whose participants are not the ones it was planned for, naming both plans
03must prove
Proposed
Each remote participant builds through its application’s lifecycle function; disabled or unreachable participants refuse the step.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§6.1 (approved 2026-10-09)
no proof recorded yet
policyservicetest
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#asks the other macroservice to provision each of its participants, for the tenant being provisioned
04must prove
Proposed
Readiness checks every planned participant and prevents opening when a participant reports missing resources.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.5 (approved 2026-10-09)
no proof recorded yet
validationservicetest
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#asks every participant to confirm what it made before the tenant is opened
05must prove
Proposed
Activation changes provisioning to active, preserves the first activation time and applies the requested business status; another activation has no further effect.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.5 (approved 2026-10-09)
no proof recorded yet
lifecycleservice, databasetest
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#records when the tenant became usable
06must prove
Proposed
Retry completes outstanding work while preserving completed participant steps.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§4.4 (approved 2026-10-09)
no proof recorded yet
invariantservicetest
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does the missing work and not the finished work when it is provisioned again
07
Proposed
Provisioning executes participants sequentially in dependency order.
policyserviceobserved
services-platform:modules/tenants/services/provisioning/provision-tenant-workflow.ts (header, Sequential, not parallel)
08must prove
Proposed
Activation enables always-available applications; failures establishing founding-staff access or development grants are logged, while application-enablement errors can fail the task.
no proof recorded yet
policyserviceobserved
services-platform:modules/tenants/services/provisioning/provision-tenant-operations.ts:activateOperation
09
Proposed
The provisioning execution allows seven days and retries transient task failures, while treating refusals as final for that attempt.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§2.4 (approved 2026-10-09)
policyservicetest
services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#gives the execution a week, which is longer than one attempt of every task together

Scenarios

IdGivenWhenThenProvenance
01The plan enables CRM, Accounting and Commerce participants.Provisioning invokes the plan.Calls follow dependency order, including valid not-applicable responses.test
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#provisions accounting.configuration after the tenant row and accepts its not_applicable
02Readiness finds a missing seed.The job attempts to open the workspace.The job reports the seed and leaves customer access closed.test
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#leaves the tenant where an operator can see it, and does not open it

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