--- id: JNY-PFM-SEC-001 title: Prepare and hand over a customer workspace feature: FEAT-PFM-SEC-01 product_area: platform module: security revision: 1 status: draft product_intent: confirmed implementation_evidence: observed supersedes: [] source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f actor: ACT-PFM-004 goal: >- Establish the customer, provision its workspace, invite the initial administrator and make the business go-live decision. capabilities: - CAP-PFM-SEC-001 - CAP-PFM-SEC-003 - CAP-PFM-SEC-002 - CAP-PFM-SEC-008 screens: - /hq/customers - /hq/tenants/provision - '/hq/jobs/tenant_provisioning/{jobId}' - '/hq/tenants/{tenantId}' steps: - 'n': 1 surface: /hq/customers action: Create a customer with the chosen readable reference and classification. capability: CAP-PFM-SEC-001 expected: The mocked customer page opens before any workspace is added. provenance: test source: >- react-console:e2e/mock/hq-ops.mock.spec.ts#New Customer creates one with Platform's types and opens it - 'n': 2 surface: /hq/tenants/provision action: >- Open provisioning for that customer and specify the workspace, calendar, initial administrator and sender. capability: CAP-PFM-SEC-003 expected: The customer is preselected when provisioning starts from its page. provenance: test source: >- react-console:e2e/mock/hq-ops.mock.spec.ts#opens with the customer already chosen when it starts from that customer - 'n': 3 surface: createTenant action: Complete the wizard and submit the setup request. capability: CAP-PFM-SEC-003 expected: The mocked submission navigates to the newly started job. provenance: test source: 'react-console:e2e/mock/hq-ops.mock.spec.ts#walks every step and lands on the job it started' - 'n': 4 surface: '/hq/jobs/tenant_provisioning/{jobId}' action: Inspect provisioning progress on the job page. capability: CAP-PFM-SEC-003 expected: The backend job snapshot lists participant work followed by readiness and activation. provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows one step per participant, then the readiness check and the activation - 'n': 5 surface: '/hq/tenants/{tenantId}' action: 'Inspect the workspace overview, sandbox list and sender records in HQ.' capability: CAP-PFM-SEC-002 expected: 'The mock page displays the overview, related sandboxes and sender DNS records.' provenance: test source: >- react-console:e2e/mock/hq-ops.mock.spec.ts#shows the overview, its sandboxes and the sender's DNS records - 'n': 6 surface: patchHqTenant action: Change the workspace business status to live through HQ. capability: CAP-PFM-SEC-002 expected: The HQ update returns live business status independently of lifecycle activation. provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenants.e2e.spec.js#answers 200 and the live status to the HQ patch alternates: - from_step: 4 condition: Provisioning reports a failed step. path: Review the displayed reason and choose Retry. outcome: The mock job returns to a running state. provenance: test source: 'react-console:e2e/mock/hq-ops.mock.spec.ts#shows a failed job''s reason and retries its provisioning' - from_step: 5 condition: The customer requires initial data migration. path: Use the initial-loading workflow and activate with the required staff permission. outcome: >- The tested activation returns the workspace to active lifecycle with implementation business status. provenance: test source: >- services-platform:modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js#is served to a staff member holding hq.tenants.activate, returning the tenant to active failures: - from_step: 3 condition: The requested workspace reference is taken. path: Display the server refusal at the workspace-reference field. outcome: The mock UI offers the existing workspace rather than opening a new job. provenance: test source: >- react-console:e2e/mock/hq-ops.mock.spec.ts#puts Platform's refusal of a taken tenant ID on the Tenant ID - from_step: 6 condition: A customer administrator requests a business-status change through the console. path: Reject the console update and identify the HQ operation. outcome: The console request cannot make that status change. provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenants.e2e.spec.js#refuses a customer administrator the same change on the console route, naming where it is made rules_in_play: - BR-CAP-PFM-SEC-001-01 - BR-CAP-PFM-SEC-001-02 - BR-CAP-PFM-SEC-003-02 - BR-CAP-PFM-SEC-003-03 - BR-CAP-PFM-SEC-003-04 - BR-CAP-PFM-SEC-003-06 - BR-CAP-PFM-SEC-003-07 - BR-CAP-PFM-SEC-002-02 - BR-CAP-PFM-SEC-002-09 assertions: - id: AS-JNY-PFM-SEC-001-01 statement: The mocked provisioning wizard completes its steps and navigates to the started job. provenance: test source: 'react-console:e2e/mock/hq-ops.mock.spec.ts#walks every step and lands on the job it started' - id: AS-JNY-PFM-SEC-001-02 statement: The backend provisioning run leaves the workspace active and records activation time. provenance: test source: >- services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant usable once the job has run - id: AS-JNY-PFM-SEC-001-03 statement: 'The mock HQ editor saves detail changes, excludes reference editing and confirms disabling.' provenance: test source: >- react-console:e2e/mock/hq-ops.mock.spec.ts#the edit sheet saves, has no identifier to change, and confirms before disabling the tenant e2e_policy: required e2e_reason: >- The intended flow connects HQ screens, backend provisioning and handover. A browser run against real services is required to establish the combined experience; mock navigation and backend job tests provide separate evidence. evidence: - 'Pinned react-console references for the structured rows: e2e/mock/hq-ops.mock.spec.ts.' - >- Pinned services-platform references for the structured rows: modules/tenants/tests/e2e/hq-tenant-loading.e2e.spec.js; modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js; modules/tenants/tests/e2e/tenants.e2e.spec.js. proved_by: [] --- # Prepare and hand over a customer workspace ## Story A Rhythm administrator begins on the customer page and starts workspace provisioning from there. They complete the wizard and use the job page to follow progress or retry a failure. After setup, they inspect the workspace overview and sender instructions. An initial migration uses the loading workflow before handover; business go-live remains a separate HQ action.