FAS-PFM-CSH-03 Addresses and working context acceptance
Markdown Planning / Platform / Console Shell and Navigation / Feature Acceptance Suite Addresses and working context acceptance What the Feature Must Do as a Whole This suite examines whether shared record links remain usable through entry, reload, history, workspace switching and older-bookmark resolution. Staff context and record-reference construction join the same experience because either can determine where a link leads. The address, established context and visible destination must be assessed together.
The five scenario kinds are cumulative. Proposed cases remain executable work to assign; bound cases name the exact assertions reviewed and record no passing product run.
Interactions Between Capabilities Switching rewrites the record destination before the new working context is installed. Older bookmarks depend on retained clearance through HQ landing. Reference lookup decides whether a link is offered, while following it still passes through workspace and destination guards; the custom-reference handoff remains a proposed complete case.
Regression Record Revision Change Scenarios Reason 1 initial all Establish cumulative acceptance from the pinned capability contracts and existing executable evidence.
Scenarios 5 scenarios proving FEAT-PFM-CSH-03
03 Switching a record opens the corresponding new-workspace list lifecycle test
Exercises CAP-PFM-CSH-009CAP-PFM-CSH-010CAP-PFM-CSH-011Relies on ATS-PFM-CSH-011-06Preconditions A contact record is open and the sandbox is reachable. Steps Select the sandbox from the workspace menu and await its entry. Expected The sandbox list opens without the former record identity and its selector identifies the sandbox. Data An isolated browser context and run-owned association fixtures; deterministic authority, response and clock variants where specified. Bound to Source react-console:e2e/mock/url-architecture.mock.spec.ts #switching tenant opens the same list under the other tenant's id, record ids dropped 04 A refused staff bookmark returns to an explained HQ context permission negative test
Exercises CAP-PFM-CSH-010CAP-PFM-CSH-013Relies on ATS-PFM-CSH-013-04Preconditions A staff caller has no clearance for the bookmarked workspace. Steps Sign in through the bookmark with a controlled strict-entry refusal. Expected HQ opens with a notice naming the refused workspace; no emergency-access dialog or workspace staff-access banner appears. Data An isolated browser context and run-owned association fixtures; deterministic authority, response and clock variants where specified. Bound to Source react-console:e2e/controlled/staff-deep-link.controlled.spec.ts #an uncleared staff member's deep link goes to Rhythm HQ with a notice, not the emergency-access dialog 05 HQ landing keeps clearance useful for an older bookmark regression test
Exercises CAP-PFM-CSH-009CAP-PFM-CSH-012CAP-PFM-CSH-013Relies on ATS-PFM-CSH-012-05Preconditions Staff have entered a workspace covered by a standing grant. Steps Open the bare root, then follow the older Contacts bookmark. Expected HQ opens first and the older bookmark then resolves to the remembered cleared workspace. Data An isolated browser context and run-owned association fixtures; deterministic authority, response and clock variants where specified. Bound to Source react-console:e2e/mock/url-architecture.mock.spec.ts #a staff member's old tenant-less bookmark opens their remembered tenant after landing in Rhythm HQ ← Previous Feature Acceptance Suite FAS-PFM-CSH-02 · Finding work through navigation acceptance Next Feature Acceptance Suite → FAS-PFM-CSH-04 · Application access in the console acceptance