Rhythm 2.0 Specifications

Appearance

ATS-PFM-TNL-008Apply defaults without undoing customer choices: Capability Test Specification

Markdown

ATS-PFM-TNL-008

Apply defaults without undoing customer choices: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-008

Design

Executed by
TST-PFM-TNL-026, TST-PFM-TNL-076

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

Apply defaults without undoing customer choices: 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-008-01ATS-PFM-TNL-008-01
BR-CAP-PFM-TNL-008-02ATS-PFM-TNL-008-02, ATS-PFM-TNL-008-08
BR-CAP-PFM-TNL-008-03ATS-PFM-TNL-008-03
BR-CAP-PFM-TNL-008-04No scenario: FND-PFM-TNL-073
BR-CAP-PFM-TNL-008-05ATS-PFM-TNL-008-04
BR-CAP-PFM-TNL-008-06ATS-PFM-TNL-008-05

Reset and baseline replay retain customer configuration. 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-002ATS-PFM-TNL-008-08 (proposed)
CAP-PFM-TNL-009ATS-PFM-TNL-008-08 (proposed)
CAP-PFM-TNL-012ATS-PFM-TNL-008-08 (proposed)

Coverage

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

Test Scenarios

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

01 First seed application retains its runruleapitest
Proves
BR-CAP-PFM-TNL-008-01
Preconditions
A workspace has no seed entries for the set.
Steps
Apply the set.
Expected
Each applied seed has one ledger row referring to the applying run.
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/persistence/tenant-seed-applications.integration.spec.js#applies every seed of the set and records each against the run that wrote it
02 Customer customization survives seed replayinvariantapitest
Proves
BR-CAP-PFM-TNL-008-02
Preconditions
A seeded workspace has one renamed and one deleted default.
Steps
Repeat provisioning.
Expected
The edited record stays edited and the removed record stays absent.
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-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#leaves a type the customer renamed after it was seeded exactly as they left it
Source
services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#does not recreate a default the customer deleted
03 Natural-key matches are adoptededgeapitest
Proves
BR-CAP-PFM-TNL-008-03
Preconditions
A customer-created record matches a seed’s key.
Steps
Apply the seed set.
Expected
The original record is preserved and its adoption is ledgered.
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-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#adopts a role the customer made first with a seed’s id, rather than duplicating it
services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#records an adopted role in the ledger too, so it is never written over later
services-crm:modules/tenant-lifecycle/tests/integration/services/participants/activities-provisioning.integration.spec.js#adopts a type the customer made first under a seed’s id, rather than overwriting it
services-committees:modules/tenant-lifecycle/tests/integration/services/starter-types.integration.spec.ts#adopts the position the customer made under a starter’s id instead of overwriting it
Source
services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#adopts a role the customer made first with a seed’s id, rather than duplicating it
04 Readiness identifies missing seed entriesvalidationapitest
Proves
BR-CAP-PFM-TNL-008-05
Preconditions
Fixtures represent a workspace before and after provisioning.
Steps
Evaluate participant readiness in both fixtures.
Expected
Missing entries are named before provisioning and none are missing afterward.
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-commerce:modules/tenant-lifecycle/tests/integration/services/participants/orders-participant.integration.spec.js#answers verifyProvisioned not ready for a fresh tenant, naming the two built-in audiences
Source
services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#answers not ready, naming every seed, before it has provisioned
05 Seed ledgers remain workspace-scopedboundaryapitest
Proves
BR-CAP-PFM-TNL-008-06
Preconditions
Two distinct workspaces are available.
Steps
Apply seeds in one and inspect from the other.
Expected
The second workspace cannot see or change the first ledger.
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/persistence/tenant-seed-applications.integration.spec.js#keeps one tenant’s ledger out of another tenant’s reach
06 Baseline replay adds no duplicateinvariantapitest
Proves
AS-JNY-PFM-TNL-005-02
Preconditions
The baseline journey has already applied its seed sets.
Steps
Repeat the reconciliation fixture.
Expected
No additional default or seed entry is created.
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-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#skips every seed on a second provisioning
07 Baseline respects renamed defaultsinteractionapitest
Proves
AS-JNY-PFM-TNL-005-03
Preconditions
The baseline journey includes customized seed records.
Steps
Reconcile after rename or deletion.
Expected
The customer’s changes remain as recorded.
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-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#leaves a type the customer renamed after it was seeded exactly as they left it
Source
services-crm:modules/tenant-lifecycle/tests/integration/services/participants/provisioning.integration.spec.js#leaves a type the customer renamed after it was seeded exactly as they left it
08 Reset and baseline replay retain customer configurationinteractionapinegativeproposed
Proves
BR-CAP-PFM-TNL-008-02
Preconditions
An import workspace has ledgered defaults, customized retained settings and imported data.
Steps
Reset the classified data, inspect defaults and their ledger, then initialize the same seed sets again.
Expected
The reset follows its classification; restored defaults acquire their expected seed entries and replay creates no duplicate. Retained settings keep their customer values.
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-008-give-every-workspace-its-default-configuration-exactly-once.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-012-empty-a-loading-workspace-so-it-can-be-loaded-again.md; 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-009-bring-every-existing-workspace-up-to-the-current-baseline.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