ATS-PFM-CSH-009 Open console work through a durable address: Capability Test Specification
Markdown Design / Platform / Console Shell and Navigation / Addresses and working context / Capability Test Specification Open console work through a durable address: 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.
Address coverage must separate recognized placeholders, unknown routes and sign-in return, including child records and query encoding. Builder and source-scanning tests cannot establish every runtime page guard.
Regions is active within Configuration and both navigation surfaces identify the same destination.
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.
Show evidence (sources, provenance, origins, pinned commits)Coverage Rule covered Transition covered Validation covered Permission gap: FND-PFM-CSH-059 Edge covered Failure covered Boundary covered Concurrency gap: FND-PFM-CSH-059 Invariant gap: FND-PFM-CSH-059 Interaction gap: FND-PFM-CSH-059 Test Scenarios 10 scenarios proving CAP-PFM-CSH-009 ; 8 bound to an existing test.
01 Source guards keep the page inventory within the address boundary invariant unit negative test
Proves BR-CAP-PFM-CSH-009-01 BR-CAP-PFM-CSH-009-04 Preconditions The pinned page tree and canonical route declarations are available. Steps Scan page inventory and forbidden literal navigation paths. Expected Every scanned page belongs to a route or declared exception; scanned console links use the permitted address construction. Data Independent fixture inputs for the variants listed in this case. Bound to Source react-console:lib/routes/__tests__/guards.test.ts #places every page.tsx on a route node or an allowed page that is not a tenant's 02 Defined address words follow the naming convention validation unit negative test
Proves BR-CAP-PFM-CSH-009-03 Preconditions Static route segments and application folder names are enumerated. Steps Check the defined words in both catalogues. Expected They use lowercase or camelCase and contain no forbidden hyphen or underscore. Data Independent fixture inputs for the variants listed in this case. Bound to Source react-console:lib/routes/__tests__/guards.test.ts #names every folder under app/ with a lowercase word or camelCase 03 Representative builder and matcher fixtures agree rule unit test
Proves BR-CAP-PFM-CSH-009-02 BR-CAP-PFM-CSH-009-09 Preconditions Fixtures include Configuration Regions and a query-bearing contact or queue destination. Steps Build the fixture addresses and evaluate the matching destination fixture. Expected Built addresses retain supported query values and the representative destination matches its expected route nodes. Data Independent fixture inputs for the variants listed in this case. Bound to Source react-console:lib/routes/__tests__/routes.test.ts #puts a tenant path under the tenant, query kept 04 Record reload and list history retain their destinations transition browser test
Proves BR-CAP-PFM-CSH-009-06 AS-JNY-PFM-CSH-003-02 Preconditions Independent browser fixtures cover a record and the Contacts and Organizations lists. Steps Reload the record; separately navigate the two lists and use Back and Forward. Expected The record keeps its identity and query on reload; the list-history case restores each visited list address. Data An isolated browser context with the stated identity, workspace and response fixtures. Bound to Source react-console:e2e/mock/url-architecture.mock.spec.ts #a record deep link survives a reload 05 Sign-in returns to the requested page and query interaction browser test
Proves BR-CAP-PFM-CSH-009-07 AS-JNY-PFM-CSH-003-01 Preconditions A signed-out browser opens a workspace destination with query information. Steps Follow sign-in and complete the development fixture login. Expected The signed-in browser reaches the original page with its query retained. Data An isolated browser context with the stated identity, workspace and response fixtures. Bound to Source react-console:e2e/dev/url-architecture.dev.spec.ts #a signed-out deep link goes through sign-in and comes back to the same page and query 06 Planned and unknown destinations remain different edge browser negative proposed
Proves BR-CAP-PFM-CSH-009-08 Preconditions A registered unfinished destination has a declared page permission. Steps Open it with and without authority, then open an unregistered path. Expected The respective outcomes are a guarded placeholder, permission refusal and not found. Data An isolated browser context with the stated identity, workspace and response fixtures. Source react-console:app/(console)/console/[tenantId]/[...slug]/page.tsx :ModulePage 07 Configuration namespaces never share one key boundary unit negative test
Proves BR-CAP-PFM-CSH-009-05 Preconditions The registered modules and cross-module areas are both available. Steps Compare each area word with the module-key collection. Expected The two namespaces contain no shared key. Data Independent fixture inputs for the variants listed in this case. Bound to Source react-console:lib/routes/__tests__/routes.test.ts #never shares a word between a configuration module and a cross-module area 09 A direct settings address aligns menu and breadcrumb interaction browser test
Proves BR-CAP-PFM-CSH-009-02 BR-CAP-PFM-CSH-006-07 Preconditions A customer administrator can read Configuration Regions. Steps Open Regions directly and inspect its active entry and breadcrumb. Expected Regions is active within Configuration and both navigation surfaces identify the same destination. Data A fresh browser context, isolated account fixtures and controlled responses for the listed transitions. Bound to Source react-console:e2e/mock/url-architecture.mock.spec.ts #Configuration › CRM › Regions loads with its place in the sidebar and the breadcrumb 11 Former Eligibility links preserve the workspace and rule screen rule unit test
Proves BR-CAP-PFM-CSH-009-10 Preconditions Redirect fixtures cover the list, creation and each defined rule subpage. Steps Apply the permanent redirect declarations to each former address in two workspaces. Expected The matching Configuration destination keeps the named workspace and the selected rule screen; unrelated paths are unchanged. Data The pinned route and page fixtures; browser measurements use a fresh demonstration context at each tested viewport. Bound to Source react-console:lib/routes/__tests__/eligibility-redirect.test.ts #redirect permanently ← Previous Capability Test Specification ATS-PFM-CSH-008 · Locate custom record types in familiar navigation: Capability Test Specification Next Capability Test Specification → ATS-PFM-CSH-010 · Enter the workspace named by a link: Capability Test Specification