Rhythm 2.0 Specifications

Appearance

ATS-PFM-TNL-002Open a workspace after its applications are ready: Capability Test Specification

Markdown

ATS-PFM-TNL-002

Open a workspace after its applications are ready: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-002

Design

Executed by
TST-PFM-TNL-056, TST-PFM-TNL-082

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

Open a workspace after its applications are ready: 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-002-01ATS-PFM-TNL-002-01
BR-CAP-PFM-TNL-002-02ATS-PFM-TNL-002-02
BR-CAP-PFM-TNL-002-03ATS-PFM-TNL-002-03
BR-CAP-PFM-TNL-002-04ATS-PFM-TNL-002-04
BR-CAP-PFM-TNL-002-05ATS-PFM-TNL-002-05, ATS-PFM-TNL-002-08
BR-CAP-PFM-TNL-002-06ATS-PFM-TNL-002-06
BR-CAP-PFM-TNL-002-08No scenario: FND-PFM-TNL-067

Activation and repeated activation preserve lifecycle authority. 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-001ATS-PFM-TNL-002-08 (proposed)
CAP-PFM-TNL-003Gap: FND-PFM-TNL-067
CAP-PFM-TNL-006ATS-PFM-TNL-002-08 (proposed)

Coverage

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

Test Scenarios

8 scenarios proving CAP-PFM-TNL-002; 7 bound to an existing test.

01 Dependencies determine construction orderruleunittest
Proves
BR-CAP-PFM-TNL-002-01
Preconditions
Participant declarations include their prerequisites.
Steps
Derive the plan and step catalog.
Expected
The workspace comes first and participants appear once before readiness and activation.
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/provisioning/provision-tenant-workflow.spec.js#has one step per planned participant, then the readiness check and the activation
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#provisions all seven of CRM’s participants, the tasks, activities and duplicates participants after the entities they depend on
Source
services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#runs the tenant row before anything that depends on it
02 Live declaration drift stops executionvalidationapinegativetest
Proves
BR-CAP-PFM-TNL-002-02
Preconditions
Live descriptions differ from the static participant order.
Steps
Start the lifecycle plan.
Expected
The refusal reports planned and current participants before their work runs.
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/provisioning/provision-tenant-workflow.spec.js#refuses a run whose participants are not the ones it was planned for, naming both plans
services-platform:modules/tenants/tests/unit/services/lifecycle/remote-participants.spec.js#plans the live manifests, so normalised, in exactly the order the static copies plan (what the publish step compares)
services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#refuses the purge as planned for other participants rather than skipping one
Source
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
03 Enablement controls remote constructioninteractionapitest
Proves
BR-CAP-PFM-TNL-002-03
Preconditions
Fixtures include enabled remote participants and a disabled application.
Steps
Provision under each registry configuration.
Expected
Enabled participants are invoked and the disabled application receives no description or work call.
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/provisioning/provision-tenant.integration.spec.js#asks the other macroservice to provision each of its participants, for the tenant being provisioned
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#neither describes nor asks Accounting while a registry that switches Accounting’s participants off is in force
Source
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
04 Readiness retains a missing-resource failurefailureapinegativetest
Proves
BR-CAP-PFM-TNL-002-04
Preconditions
A participant cannot account for a required resource.
Steps
Run construction through readiness.
Expected
The missing resource is reported and the workspace stays closed.
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/provisioning/provision-tenant.integration.spec.js#asks every participant to confirm what it made before the tenant is opened
Source
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
05 Activation retains its first openingtransitionapitest
Proves
BR-CAP-PFM-TNL-002-05
Preconditions
All construction participants report readiness.
Steps
Activate the workspace and repeat activation.
Expected
Active lifecycle uses the requested mode and the recorded activation time remains stable.
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-provisioning.e2e.spec.js#shows one step per participant, then the readiness check and the activation
Source
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant usable once the job has run
06 Retry omits completed constructioninvariantapitest
Proves
BR-CAP-PFM-TNL-002-06
Preconditions
An earlier attempt stopped after partial completion.
Steps
Run a replacement attempt.
Expected
Outstanding resources are supplied without repeating completed participant work.
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/provisioning/provision-tenant.integration.spec.js#does the missing work and not the finished work when it is provisioned again
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does not repeat work the other macroservice completed before it lost the answer
Source
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 Construction progress satisfies its journey assertionruleapitest
Proves
AS-JNY-PFM-TNL-001-02
Preconditions
The provisioning journey’s fixture has a successful build.
Steps
Inspect the resulting build snapshot.
Expected
Participant, readiness and activation steps are present and completed.
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-provisioning.e2e.spec.js#shows one step per participant, then the readiness check and the activation
Source
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows one step per participant, then the readiness check and the activation
08 Activation and repeated activation preserve lifecycle authorityinteractionapinegativeproposed
Proves
BR-CAP-PFM-TNL-002-05
Preconditions
The participant plan is ready and the workspace has no first opening time.
Steps
Complete construction, read lifecycle facts, repeat activation and attempt an ordinary client lifecycle edit.
Expected
Opening records one activation time; repetition and the client edit cannot replace it.
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-002-open-a-new-workspace-only-when-every-application-reports-it.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-006-keep-every-workspace-s-lifecycle-state-truthful.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-001-ask-for-a-new-workspace-and-have-every-application-build-it.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