Rhythm 2.0 Specifications

Appearance

ATS-PFM-CSH-001Use a consistent console frame: Capability Test Specification

Markdown

ATS-PFM-CSH-001

Use a consistent console frame: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-CSH-001

Design

Executed by
TST-PFM-CSH-006, TST-PFM-CSH-008

KindAcceptance test setProduct areaPlatformModuleConsole Shell and NavigationRevision3

Read atreact-console baf6dae3services-platform ad3f6a65rhythm-v2-docs 25e253cb

Use a consistent console frame: Capability Test Specification ​

Coverage ​

The coverage map describes specified proof, not a passing run. Each mandatory rule below has a scenario or an explicit finding; a proposed scenario remains an execution obligation even when its expected outcome follows the pinned implementation.

Mandatory RuleScenarios or Finding
BR-CAP-PFM-CSH-001-03ATS-PFM-CSH-001-01, ATS-PFM-CSH-001-06
BR-CAP-PFM-CSH-001-04ATS-PFM-CSH-001-02, ATS-PFM-CSH-001-03
BR-CAP-PFM-CSH-001-05ATS-PFM-CSH-001-04
BR-CAP-PFM-CSH-001-07ATS-PFM-CSH-001-05

Startup retry must be exercised through every failure outcome, cancellation and session ending. Workspace remount and cleanup belong to the switching interactions, not to an assumed universal cache-erasure guarantee.

The frame and menu wait together; after the answer, CRM destinations appear under the established workspace.

The interaction rows cite the contracts they exercise. Related combinations without a complete case remain in the coverage finding, together with cross-capability workflows and permission boundaries. A helper assertion is bound only for its stated outcome; the full browser handoff remains proposed until a suite checks it.

Pinned source and exact test anchors are recorded in frontmatter. Test bindings record static assertion review and use the executable-suite register; no product test result is inferred from that review. The prior planning and design examinations supply context, while this continuation records the remaining proof obligations explicitly.

Coverage

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

Test Scenarios

6 scenarios proving CAP-PFM-CSH-001; 2 bound to an existing test.

01 A context answer precedes working contentinvariantbrowsertest
Proves
BR-CAP-PFM-CSH-001-03 AS-JNY-PFM-CSH-001-01
Preconditions
A signed-in employee starts in a fresh browser context.
Steps
Capture the first load and repeat after reload.
Expected
The context read leads the application requests; working content mounts only after its answer.
Data
An isolated browser context with the stated identity, workspace and response fixtures.
Bound to
Source
react-console:e2e/dev/initialisation.dev.spec.ts#asks the Platform exactly one thing first, and shows nothing until it is answered
02 Retry moves failed startup into usable workfailurebrowsernegativeproposed
Proves
BR-CAP-PFM-CSH-001-04
Preconditions
An initial context read fails; the retry can return usable authority.
Steps
Start the console, select retry and complete the next answer.
Expected
The failure view supplies retry and sign-out; successful retry mounts the working console.
Data
An isolated browser context with the stated identity, workspace and response fixtures.
Source
react-console:components/console/console-boot-screens.tsx:consoleBootScreens
03 Access refusal and incomplete setup remain distinguishablepermissionunitnegativeproposed
Proves
BR-CAP-PFM-CSH-001-04
Preconditions
One account is refused access; a separate build lacks required configuration.
Steps
Present each startup condition independently.
Expected
Refusal names the signed-in account and provides sign-out; incomplete setup lists the missing configuration.
Data
Independent fixture inputs for the variants listed in this case.
Source
react-console:components/console/console-boot-screens.tsx:consoleBootScreens
04 Fallback notice can be dismissed without losing worktransitionbrowsertest
Proves
BR-CAP-PFM-CSH-001-05
Preconditions
The remembered workspace has become unavailable.
Steps
Load the console, inspect the fallback notice and dismiss it.
Expected
The changed starting context is explained; dismissal removes the notice while leaving the console usable.
Data
An isolated browser context with the stated identity, workspace and response fixtures.
Bound to
Source
react-console:e2e/controlled/tenant-unavailable.controlled.spec.ts#falls back to the default tenant, with a word of explanation, rather than refusing access
05 Sample currency conversion keeps its own rounding contractboundaryunitproposed
Proves
BR-CAP-PFM-CSH-001-07
Preconditions
The demonstration amount helper selects Canadian dollars.
Steps
Convert a base amount in both directions and format ordinary and compact results.
Expected
The fixed rate and cent rounding determine conversion; each display uses the helper’s defined precision.
Data
Independent fixture inputs for the variants listed in this case.
Source
react-console:components/console/console-provider.tsx:useMoney
06 Frame startup supplies the first usable menuinteractionbrowserproposed
Proves
BR-CAP-PFM-CSH-001-03 BR-CAP-PFM-CSH-006-02
Preconditions
An association employee opens a fresh workspace session.
Steps
Delay the context answer, then return an enabled CRM context.
Expected
The frame and menu wait together; after the answer, CRM destinations appear under the established workspace.
Data
A fresh browser context, isolated account fixtures and controlled responses for the listed transitions.
Source
rhythm-v2-docs:specs/platform/console-shell/planning/capabilities/CAP-PFM-CSH-001-work-inside-one-console-frame.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