At a Glance
Persona: Audit / Config (Auditor + System Administrator) · Module: purchase-order · Scenarios: ~30
Categories: Happy Path · Permission · Validation · Edge Case
E2E coverage: maps to401-po.spec.ts(transactional paths only) in../carmen-inventory-frontend-e2e/; audit-log query and config-management surfaces covered by API / integration tests
This page captures the test scenarios that the Audit / Config persona axis directly drives in the purchase-order module. Two distinct roles sit on this axis: the Auditor (read-only across the full procurement chain — Purchase Request → Purchase Order → Goods Receive Note → vendor invoice / AP posting), who uses the PO module's ActivityLogTab, workflow_history, tb_purchase_order_comment (PO_POST_005, PO_POST_009), and the cross-document bridges (tb_purchase_order_detail_tb_purchase_request_detail, GRN back-references per PO_XMOD_003, three-way-match records under PO_POST_008) to verify policy compliance, segregation of duties (PO_AUTH_010), three-way-match integrity (PO_POST_008 / PO_POST_009), and traceability end-to-end; and the System Administrator (configuration only), who owns the PO numbering scheme, the workflow definition (tb_purchase_order.workflow_id, stages, user_action.execute[] membership per PO_AUTH_011), the RBAC role-to-permission map for PO_AUTH_001–PO_AUTH_011, the integration wiring (vendor, vendor-pricelist, budget, inventory), the PR-to-PO conversion and vendor+currency grouping rules per carmen/docs § 2.3.2, the document templates referenced at transmission per PO_POST_004, and the tax / currency / FX rate sources consumed by PO_CALC_001–PO_CALC_011. Neither role transitions a PO across enum_purchase_order_doc_status: the Auditor exits via a generated report (no PO state change), the Sysadmin exits via a saved configuration with an effective_from timestamp (POs already at in_progress / sent / partial retain their original snapshot; new POs use the new configuration). Scenarios are grouped into the happy paths described in 03-user-flow-audit-config.md, the RBAC boundary that separates read-only-audit from configure-only-sysadmin from no-direct-transact, the validation rules around snapshot preservation, export approval, deadlock prevention, delegation windows, and scan limits, and a small set of edge cases around in-flight boundaries, rollback, mass delegation, audit-log gaps, and config vs in-flight race conditions. The shared 401-po.spec.ts E2E spec exercises transactional paths only; audit-log query and configuration-management surfaces are covered by API / integration tests today (no dedicated audit-config E2E spec exists at this time).
| # | Scenario | Pre-condition | Steps | Expected |
|---|---|---|---|---|
| AUD-HP-01 | Auditor queries PO by date range | Auditor auditor@blueledgers.com logged in with read-only role; at least 50 POs created between 2026-04-01 and 2026-04-30 across multiple buyers / vendors / po_status values |
1. Sidebar → Audit workspace → Procurement Activity Queries. 2. Select template "All POs in period". 3. Set order_date filter = 2026-04-01 .. 2026-04-30. 4. Apply. |
Result table renders one row per PO with po_no, vendor, buyer, current po_status, last_action, last_action_at_date. Empty filter set would have been rejected (see AUD-VAL-05); date range applied successfully. No tb_purchase_order row is mutated; no workflow_history entry written. The query itself is logged to the audit-side activity store with the Auditor's identity, filter set, and result count. |
| AUD-HP-02 | Auditor drills into one PO and walks its activity log | Auditor logged in; PO PO-DR-01 exists with po_status = completed, full lifecycle: created, submitted, approved (2 stages), sent, partial GRN, full GRN, three-way-match success |
1. From AUD-HP-01 result set, click PO-DR-01. 2. Open Activity Log tab. 3. Open Related Documents tab. 4. Expand each workflow_history entry. |
ActivityLogTab shows the full ordered list of events: created → submitted (PO_POST_002) → approved × N (PO_POST_003) → approved final (PO_POST_004, po_status: in_progress → sent) → received × 2 (PO_POST_006 / PO_POST_007). Each entry shows actor user_id, timestamp, stage, and any tb_purchase_order_comment entry attached. RelatedDocumentsTab shows the originating PR(s) via the PR→PO bridge and the two GRNs via the GRN back-reference per PO_XMOD_003. PO state unchanged. |
| AUD-HP-03 | Auditor follows the forward chain PO → GRN → invoice → AP | Auditor logged in; PO PO-FC-01 at po_status = completed; one GRN GRN-FC-01 posted; vendor invoice INV-FC-01 matched cleanly under PO_POST_008; AP liability posted |
1. Open PO-FC-01. 2. Related Documents tab. 3. Click GRN link → review GRN posting. 4. Click invoice link → review three-way-match record. 5. Click AP voucher link → review GL posting. |
Chain renders contiguously with no time-ordering gaps: PO sent at T0 → GRN posted at T1 > T0 (PO_XMOD_003) → invoice captured at T2 > T1 → three-way-match success at T3 ≥ T2 (PO_POST_008) → AP posted at T4 ≥ T3 (PO_XMOD_007). Each step shows the actor and the rule citation. Segregation of duties verified: buyer_id of PO-FC-01 ≠ GRN poster (PO_AUTH_010). PO state remains completed; no mutation. |
| AUD-HP-04 | Auditor follows the back chain PR → PO via the bridge | Auditor logged in; PO PO-BC-01 with po_type = purchase_request; two PR lines consolidated into one PO line via tb_purchase_order_detail_tb_purchase_request_detail (PO_XMOD_001, PO_XMOD_002) |
1. Open PO-BC-01. 2. Open the PO detail line. 3. Expand Source PR(s) section. 4. Click each pr_no link → review PR approval trail. |
Bridge rows surface both pr_detail_id references with pr_detail_qty per row; Σ bridge.pr_detail_qty for each PR line equals that PR line's approved quantity (PR fully converted per PO_XMOD_002). Each PR opens to its own approval trail showing PR status timeline. Vendor+currency grouping (carmen/docs § 2.3.2) verified: both PR lines share the same (vendor_id, currency_id) tuple, justifying their consolidation onto the one PO line. PO state unchanged. |
| AUD-HP-05 | Auditor exports a period report with secondary approval | Auditor logged in; result set from AUD-HP-01 includes sensitive fields (buyer / approver identities, vendor pricelist snapshots, three-way-match deviation detail); data-export approver export.approver@blueledgers.com available |
1. From the result table, click Export → CSV (full detail). 2. System materialises the request in pending state. 3. Export approver receives notification, reviews scope. 4. Approver clicks Release. 5. Auditor downloads CSV from case file. | Export request enters pending with the Auditor's identity, filter set, sensitive-field manifest, and requested scope. Export approver review log records approver identity + decision. On release, the CSV is materialised and a download link is recorded in the audit case file with the approver's identity attached. The export itself is an audit object — visible only inside the case file until released. No PO state change. |
| AUD-HP-06 | Sysadmin adjusts PO numbering scheme | Sysadmin sysadmin@blueledgers.com logged in; change ticket links Finance memo approving the new year-prefix format PO-2026-NNNNN; current scheme is PO-NNNNN |
1. Configuration → PO Numbering & Templates. 2. Open the active scheme. 3. Change prefix to PO-2026-, sequence width = 5, reset rule = yearly. 4. Preview next-issued po_no. 5. Save. |
Preview shows next-issued po_no = PO-2026-00001. On save, configuration is written with effective_from = now(); configuration audit log records the version diff. POs already at in_progress / sent / partial retain their original po_no (snapshot semantics); new POs created after effective_from issue under the new scheme. No tb_purchase_order row is mutated. The first new PO created post-save verifies the new format. |
| AUD-HP-07 | Sysadmin changes RBAC for the purchase role |
Sysadmin logged in; change ticket requests adding void capability to purchase role at the partial status (currently Procurement-Manager-only per PO_AUTH_007) — tenant has approved this elevation |
1. Configuration → RBAC & Roles. 2. Select purchase role. 3. Find PO_AUTH_007 permission entry. 4. Toggle "Void from partial" = on. 5. Preview affected user count. 6. Save. |
Preview shows the count of users currently in the purchase role who would gain the new right. On save, the RBAC map is updated with effective_from = now(); configuration audit log records the change. Users in the purchase role can now exercise void from partial on new sessions; existing sessions refresh permissions on next API call. POs already in flight are not affected (snapshot semantics on user_action.execute[] at the current stage); the change applies to future actions only. |
| AUD-HP-08 | Sysadmin configures PR-to-PO vendor+currency grouping rule | Sysadmin logged in; change ticket requests adding delivery_location_id as a third grouping dimension on top of (vendor_id, currency_id) per carmen/docs § 2.3.2 — to keep multi-location deliveries on separate POs |
1. Configuration → PR-to-PO Rules. 2. Open the active grouping rule. 3. Add delivery_location_id to the grouping key. 4. Preview against a recent test batch of 20 PRs. 5. Save. |
Preview shows how the 20-PR test batch would re-group under the new rule (e.g. 12 POs instead of 8 under the old rule). On save, configuration is written with effective_from = now(). In-flight PR-to-PO conversions complete under the rules in force at wizard start (the groups the user already confirmed do not re-shuffle); the next conversion initiated after effective_from uses the new three-dimensional key. Configuration audit log records the change and the in-flight conversion count at save time. |
| AUD-HP-09 | Sysadmin sets up an approval delegation window | Sysadmin logged in; Procurement Manager pm@blueledgers.com out on leave 2026-06-01 .. 2026-06-14; delegate pm.delegate@blueledgers.com granted approval rights for the window per PO_AUTH_011 |
1. Configuration → PO Workflow Settings → Delegations. 2. Click New delegation. 3. Pick delegator = pm@blueledgers.com, delegate = pm.delegate@blueledgers.com, scope = "High-value approval stage", start_at = 2026-06-01T00:00:00Z, end_at = 2026-06-14T23:59:59Z. 4. Save. |
Validation passes (end_at > start_at; see AUD-VAL-04 for the failure mode). Configuration audit log records the new delegation. During the window, the delegate inherits user_action.execute[] membership at the high-value stage; notifications for any PO currently sitting at that stage are re-fanned to the delegate. POs already in flight see the inherited rights for the duration of the window; on end_at, the inherited rights drop automatically and the original pm@blueledgers.com membership is restored (which never actually changed). No PO state change. |
| # | Scenario | Expected behaviour (allow/deny + reason) |
|---|---|---|
| AUD-PERM-01 | Auditor opens any PO in any po_status (read-only across the chain) |
Allow. Per the Auditor role's read-only mandate, the Auditor can open PR, PO, GRN, invoice, and AP records across all statuses including terminal (completed, closed, voided). The PO detail page in the Auditor's view is read-only: edit / submit / approve / void / close / transmit actions are not exposed in the UI; direct API edit calls return "You are not authorised to edit this PO at the current stage." No tb_purchase_order mutation possible. |
| AUD-PERM-02 | Auditor attempts a write action (edit a line, void, comment as actor) on a PO | Deny. The Auditor has no write surface in the purchase-order module — not on tb_purchase_order, not on tb_purchase_order_detail, not on tb_purchase_order_comment (other than the audit-side case file, which is a separate store). UI hides write actions; direct API attempts return "Read-only role — write actions are not permitted from the Audit workspace." Audit-side case-file notes are written by the Auditor but are NOT tb_purchase_order_comment entries (no PO record change). |
| AUD-PERM-03 | Sysadmin opens any configuration surface (numbering, workflow, RBAC, integration, PR-to-PO rules, templates) | Allow. The Sysadmin role holds configure rights on every surface listed in 03-user-flow-audit-config.md § 2.2. Each save is recorded in the configuration audit log with the Sysadmin's identity, the version diff, the effective_from timestamp, and any affected-population count from the preview panel. |
| AUD-PERM-04 | Sysadmin attempts to create / submit / approve / transmit a PO from the configuration workspace | Deny — segregation. The Sysadmin role configures the rules but does NOT execute transactions on them. Per PO_AUTH_001 (Procurement Officer creates), PO_AUTH_003 (Procurement Officer submits), PO_AUTH_004 (Procurement Manager approves at high-value), PO_AUTH_006 (Procurement Officer / Manager transmits), the Sysadmin role is not in any of these subjects. UI does not expose a "New PO" button in the configuration workspace; direct API attempts return "Sysadmin role cannot transact in the purchase-order module — use the Procurement Officer or Procurement Manager role." |
| AUD-PERM-05 | Auditor requests an export including sensitive fields (full identities, pricelist snapshots, deviations, attachments) | Allow — with secondary approval gate. Per the data-export policy, exports including sensitive fields enter pending state; the Auditor cannot bypass. An export approver releases the export, after which the CSV / PDF is materialised and a download link is recorded in the audit case file alongside the approver's identity. AUD-HP-05 walks the happy path; AUD-VAL-02 covers the unapproved case. |
| AUD-PERM-06 | Sysadmin executes an elevated void on a deadlocked / orphaned PO via PO_AUTH_007 escalation |
Allow — exceptional. When an audit finding or a workflow deadlock requires terminating a non-compliant PO and no Procurement Manager is available, the Sysadmin holds an elevated path to void under PO_AUTH_007 (tenant-configured override). This action requires (a) an audit finding reference or a deadlock-warning reference from the configuration audit log, (b) the Sysadmin to confirm with second-factor / step-up auth, and (c) a mandatory reason in tb_purchase_order_comment. The void itself fires PO_POST_010 (* → voided); the override is recorded in BOTH tb_purchase_order_comment (system) AND the configuration audit log for cross-reference. This is the only path by which the Sysadmin touches a PO record directly. |
| AUD-PERM-07 | A user who is neither Auditor nor Sysadmin (e.g. purchase@blueledgers.com, requestor@blueledgers.com) opens the Audit workspace or Configuration workspace |
Deny. Per RBAC, only users with the Auditor role can open the Audit workspace and only users with the Sysadmin role can open the Configuration workspace. UI hides both sidebar entries for users without the role; direct URL navigation returns "Audit workspace requires the Auditor role." or "Configuration workspace requires the System Administrator role." Transactional personas (Purchaser, Receiver, Finance Officer) have their own activity views on the PO record (ActivityLogTab is visible there) but cannot open the cross-document audit query builder. |
| # | Scenario | Trigger | Expected error |
|---|---|---|---|
| AUD-VAL-01 | Sysadmin changes config while a PO is in flight — snapshot preserved | PO PO-SP-01 at po_status = in_progress under the OLD high-value threshold of ฿1,000,000; Sysadmin changes the threshold to ฿2,000,000 while PO-SP-01 is still mid-workflow |
The save is allowed (rules are not locked by in-flight POs). PO-SP-01 continues under its snapshotted threshold band and stage chain; its routing does NOT retroactively change. Preview panel surfaces the affected-PO count before save. Configuration audit log records the change and the in-flight count. On save, new POs created after effective_from use the new ฿2,000,000 threshold; PO-SP-01 finishes its current workflow under the old ฿1,000,000 routing. No tb_purchase_order mutation occurred from the config save. |
| AUD-VAL-02 | Export approval bypass attempted | Auditor logged in; request CSV export including sensitive fields; data-export approver has NOT approved | Reject the download. Server returns "Export requires approval — sensitive fields detected (buyer identity, pricelist snapshot, deviation detail). Export is in pending state until release by an export approver." Download link is not generated; the pending export remains in the case file. The Auditor cannot click through; direct API call to materialise returns 403 Forbidden — approval required. AUD-HP-05 is the happy-path counterpart. |
| AUD-VAL-03 | Sysadmin attempts to save a config that would deadlock an in-flight PO | PO PO-DL-01 waiting at stage S2 with only one user last.approver@blueledgers.com in user_action.execute[]; Sysadmin opens the workflow editor and tries to remove last.approver@blueledgers.com from S2 |
Preview panel flags the deadlock: "Saving this change will leave PO-DL-01 with no eligible approver at stage S2 — the PO will time out at this stage and require manual intervention (one-off delegation or void under PO_AUTH_007)." Sysadmin is asked to (a) cancel, (b) add a replacement approver to S2 before save, or (c) save anyway with the warning acknowledged. If saved anyway, the configuration audit log records both the change AND the deadlock warning for audit attribution. |
| AUD-VAL-04 | Delegation window with end_at < start_at rejected at save |
Sysadmin opens a new delegation; start_at = 2026-06-14T00:00:00Z; end_at = 2026-06-01T00:00:00Z (swapped by mistake) |
Reject the save. Server returns "Delegation window is invalid — end_at (2026-06-01T00:00:00Z) must be strictly greater than start_at (2026-06-14T00:00:00Z)." No delegation row is written; configuration audit log records the rejected attempt. AUD-HP-09 is the happy-path counterpart with the correct ordering. |
| AUD-VAL-05 | Auditor submits an empty filter set on a date-range query | Auditor opens Audit → Procurement Activity Queries; clicks Apply without setting any filter | Reject the query. Server returns "Empty filter set — at least one of date range, business unit, vendor, or buyer must be specified to prevent unbounded scans across the procurement chain." No result set is rendered; no audit-side activity-store entry is written. The Auditor must add at least one filter chip; the most common is the date range used in AUD-HP-01. |
| AUD-VAL-06 | Sysadmin saves a threshold-range with an invalid band | Sysadmin opens the threshold editor; sets the high-value threshold to -50000 (negative) or to lower > upper on a multi-tier threshold |
Reject the save. Server returns "Threshold value is invalid — must be a non-negative number; multi-tier thresholds must satisfy lower < upper." Configuration is not persisted; preview panel does not advance. The Sysadmin revises the input and re-saves. The configuration audit log records the rejected attempt to prevent silent retries. |
| AUD-VAL-07 | Sysadmin saves a no-op (no actual change) | Sysadmin opens a config surface, opens the editor, and clicks Save without changing any field | Reject the save. Server returns "No changes detected — save was not persisted." Configuration version is not incremented; no audit-log entry is written. This prevents audit-log inflation from accidental no-op saves. The configuration page returns to view mode. |
| AUD-VAL-08 | Sysadmin attempts to delete a referenced master-data record (e.g. a tax_id referenced by an active PO line) |
Sysadmin opens Configuration → Tax Codes; selects a tax code that is currently referenced by at least one tb_purchase_order_detail.tax_id on a non-terminal PO; clicks Delete |
Reject the delete. Server returns "Cannot delete tax code <id> — referenced by N active PO line(s). Archive the tax code instead to preserve historical references." The archive flow is the only acceptable path: archived codes remain valid on historical PO snapshots but are not selectable for new PO lines. This preserves the calculation-rule integrity in PO_CALC_001–PO_CALC_011 for in-flight and historical POs. |
| # | Scenario | Condition | Expected |
|---|---|---|---|
| AUD-EDGE-01 | In-flight snapshot boundary — config saved exactly at submission | PO PO-SB-01 is at po_status = draft; Purchaser clicks Submit at T; Sysadmin saves a workflow change with effective_from = T (same millisecond) |
Race resolved by atomic effective_from comparison. If PO-SB-01's PO_POST_002 submit timestamp is strictly less than effective_from, the PO captures the OLD workflow snapshot (user_action.execute[], stage chain, threshold band) and the new configuration applies only to subsequent submissions. If PO-SB-01's submit timestamp is ≥ effective_from, the PO captures the NEW workflow snapshot. The PO's workflow_history first entry records the configuration version it bound to, so the audit chain is unambiguous. Configuration audit log records the in-flight count and the bordering PO ID for forensic clarity. |
| AUD-EDGE-02 | Rollback of a bad config change | Sysadmin saves a new RBAC config at T1; verification at step 6 of the happy-path flow finds that a needed approver was inadvertently removed; Sysadmin reverts to the prior version at T2 > T1 |
Rollback is itself a configuration save with effective_from = T2. POs created between T1 and T2 are NOT retroactively re-evaluated (snapshot semantics); they finish under the broken-RBAC snapshot — typically rescued via one-off delegation (AUD-HP-09) or PO_AUTH_007 void if completely deadlocked. POs created after T2 use the rolled-back configuration. Configuration audit log retains BOTH versions (the forward change at T1 and the rollback at T2); a clean trail is preserved. AUD-EDGE-01's snapshot boundary mechanic also applies at T2. |
| AUD-EDGE-03 | Mass-delegation activation at the organization boundary | Sysadmin sets a delegation window start_at = 2026-12-25T00:00:00+07:00 .. 2026-12-31T23:59:59+07:00 covering 12 approvers (year-end holiday); PO load during the window is unusually high (300+ POs in flight) |
Window activation is atomic at start_at — all 12 delegates inherit user_action.execute[] membership for their respective scopes at the same instant. Notifications for the 300+ in-flight POs are batched (not per-PO 300 emails, but per-delegate digests) to avoid notification storms. Each PO's stage routing now offers BOTH the original approver AND the delegate; either may approve. On end_at, all 12 inherited rights drop atomically; in-flight POs continue with their original approvers. The configuration audit log records the mass activation, delegate count, and PO-affected count for forensic reconstruction. |
| AUD-EDGE-04 | Audit-log gap — missing system event | Auditor walks PO-GAP-01's timeline; finds that workflow_history has the submitted entry at T0 and the approved (final) entry at T2 but is MISSING any intermediate approved entry (PO_POST_003) that should sit between them for the multi-stage workflow |
The gap is itself an audit finding. The Auditor flags PO-GAP-01 in the case file with a "missing intermediate workflow_history entry" note, attaches the timeline excerpt + the configured workflow stage count (which says there should be N entries), and routes to the Sysadmin for investigation. Possible causes: (a) replay-log corruption (escalate to ops), (b) a transition that bypassed the writer (escalate to engineering), (c) a soft-deleted comment (PO_POST_012 does not apply to workflow_history — workflow_history is append-only). The Auditor does NOT close the case as "no findings"; the case stays open until the gap is explained. |
| AUD-EDGE-05 | Query timeout on a huge dataset | Auditor sets date range = 2024-01-01 .. 2026-05-15 (29 months) + no other filter, against a tenant with 80,000+ POs in scope |
Query hits the date-range scan limit (AUD-VAL-05 prevents the empty case, but a 29-month single-filter still risks timeout). System chunks the query — first returns the first 1,000 rows + a "Continue to next page" cursor, persists the query plan, and runs the remainder asynchronously. The Auditor can either page through synchronously or schedule a full-extract export (which then enters the AUD-HP-05 / AUD-VAL-02 export-approval flow). No timeout error is surfaced to the user; the experience degrades gracefully to paged + async. |
| AUD-EDGE-06 | Config save vs in-flight PO submission race | Sysadmin clicks Save at T; simultaneously, 5 Purchasers click Submit on 5 different draft POs in adjacent browser tabs; all 6 actions arrive at the backend within the same 500 ms window |
The backend serialises by effective_from timestamp on the configuration row and PO_POST_002 last_action_at_date on each PO. Each PO submission is atomically tagged with the configuration version active at the instant of its PO_POST_002 write. Result: of the 5 submissions, some may capture the OLD snapshot and some the NEW depending on order — but each PO's workflow_history first entry unambiguously records WHICH version it bound to. No PO ends up in a hybrid state; no submission is rejected as "configuration in transition." Configuration audit log records the count of in-flight submissions resolved against each side of the boundary for forensic clarity. |
X-PO-* scenarios. The Auditor's chain audit references X-PO-07 (three-way-match dispute) and X-PO-09 (AP posting close-out) for context.PO_AUTH_005 (delete-in-draft, exercised on the Sysadmin's elevated rollback path), PO_AUTH_006 (transmit, configured by the Sysadmin via document templates), PO_AUTH_007 (Procurement Manager void, escalated to via Sysadmin elevated path on deadlock per AUD-PERM-06), PO_AUTH_008 (Inventory Manager close — referenced by the Auditor in chain audit), PO_AUTH_009 (Finance Officer read-only — same pattern the Auditor inherits in PO scope), PO_AUTH_010 (segregation of duties — verified by the Auditor in chain audit per AUD-HP-03), PO_AUTH_011 (workflow-derived stage-gated approval — configured by the Sysadmin via user_action.execute[] membership). Section 5 — PO_POST_005 (reject comment surface audited), PO_POST_009 (three-way-match failure comment audited), PO_POST_010 (void path used in the Sysadmin elevated escalation), PO_POST_012 (soft delete — explicitly NOT applicable to workflow_history).PO_XMOD_001 / PO_XMOD_002 (PR→PO bridge walked in back-chain audit per AUD-HP-04), PO_XMOD_003 (PO→GRN bridge walked in forward-chain audit per AUD-HP-03), PO_XMOD_005 / PO_XMOD_006 (vendor-pricelist snapshot and deviation, surfaced in sensitive-field exports), PO_XMOD_007 (AP / three-way match close-out audited end-to-end).PO_AUTH_007 / PO_AUTH_008); also the consumer of Sysadmin threshold / workflow configuration.PO_AUTH_010: Purchaser ≠ Receiver).PO_POST_008 / PO_POST_009) close the forward-chain audit on the AP side.PO_POST_006 / PO_POST_007.../carmen-inventory-frontend-e2e/tests/401-po.spec.ts — shared / mixed-persona coverage of the transactional happy paths the Auditor walks read-only; no dedicated audit-config E2E spec exists at this time. Audit-log query and configuration-management surfaces are exercised at the API / integration level (cross-module audit and config services). The SKIP_NOTE_BACKEND annotation in 401-po.spec.ts flags configuration-driven behaviour (sequence generation, RBAC enforcement, workflow stage routing, integration sync) as out-of-scope for UI E2E — these are validated via the audit logs the Auditor walks and the configuration audit log the Sysadmin writes.