--- type: idea title: Accounting Context Runtime - Playwright Test Plan created: 2026-06-21 status: proposed origin_sources: - "[[2026-06-21 Accounting Context Runtime for Vendor Spend]]" - "[[2026-06-21 Accounting Context Runtime - Codex Build Spec]]" related_auto: [] used_in: [] --- # Accounting Context Runtime - Playwright Test Plan ## Scope This plan covers the browser-level verification slice for the Accounting Context Runtime prototype. It assumes the app will live at `tools/accounting-context-runtime` and that Playwright tests will be added under `tools/accounting-context-runtime/tests` once the app exists. The suite should verify the three required screens and the highest-risk accounting-control flows: - Accounting Inbox: seed artifacts, classification, extraction status, vendor links, linked cases, and re-processing. - Close Prep Queue: case status, treatment, evidence completeness, exception flags, filters, and navigation. - Case Review: trigger, evidence, extracted terms, proposed treatment, schedule, draft JE, controls, comments, audit trail, approval, compile, and export. The browser suite should not try to prove every heuristic. Unit or integration tests should own classifier, linker, extractor, schedule math, JE balancing, duplicate detection, and control-event creation. Playwright should prove those behaviors are correctly wired into the user workflow. ## Test Harness Assumptions When the app exists, prefer the app's native scripts and conventions. If no convention exists yet, the desired shape is: - `pnpm test:e2e` or equivalent runs Playwright from `tools/accounting-context-runtime`. - `playwright.config.ts` starts the local app through `webServer`. - Each test starts from deterministic seed data. - Tests can reset local state without manual cleanup. - Export tests use Playwright's download APIs and inspect downloaded CSV or workpaper contents. - Selectors prefer accessible roles and names. Add `data-testid` only for dense accounting tables or generated rows where accessible names are ambiguous. Recommended test file layout once the app exists: ```text tools/accounting-context-runtime/tests/ e2e/ accounting-inbox.spec.ts close-prep-queue.spec.ts case-review-controls.spec.ts exports.spec.ts fixtures/ seed-scenarios.ts support/ accounting-matchers.ts runtime-actions.ts ``` ## Seed Scenarios To Exercise Use the five seed scenarios from the build spec as named fixtures: 1. Open PO / missing invoice accrual. 2. Vendor renewal prepaid. 3. Invoice without support. 4. No-entry-needed low-dollar invoice. 5. Duplicate accrual risk. The Playwright layer should reference them by visible vendor/case names rather than by database IDs. IDs can change; the accounting scenario should not. ## Critical End-To-End Test ### Prepaid case happy path Flow: 1. Load the seeded Accounting Inbox. 2. Run or re-run processing. 3. Confirm renewal and invoice artifacts classify correctly. 4. Open the Close Prep Queue. 5. Filter to prepaid cases. 6. Open the vendor renewal prepaid case. 7. Confirm the above-the-fold case summary shows trigger, proposed prepaid treatment, dollar impact, close-period impact, evidence completeness, and required action. 8. Confirm evidence, extracted terms, prepared schedule, draft JE, controls, and audit trail panels are present. 9. Approve treatment. 10. Compile artifact. 11. Export the prepared schedule or draft JE. 12. Inspect the downloaded file for case ID, vendor, close period, treatment, evidence list, schedule or JE lines, approval state, and generated timestamp. Assertions: - The case moves from Ready for Review or Prepared to Approved, then Compiled. - The schedule total equals the source amount within currency rounding tolerance. - Draft JE lines balance debits and credits. - At least one ControlEvent appears for approval and one for compilation. - Export succeeds only after approval and compilation. ## Control-Focused Browser Tests ### Compile requires approval Open a prepared but unapproved case and attempt to compile. Expected result: - Compile is disabled or blocked. - The UI explains that approved treatment is required. - No compiled artifact is created. - No false Compiled status appears in the queue. ### Duplicate accrual risk blocks compile Open the duplicate-risk seed case and attempt to compile without resolving or overriding the duplicate warning. Expected result: - Duplicate or already-invoiced risk is visible in Exceptions and Controls. - Compile is blocked. - The case remains in a non-compiled status. - The audit trail records the blocked compile attempt only if the app is designed to log failed control checks. ### Missing evidence blocks material approval unless overridden Open the invoice-without-support seed case. Expected result: - Case status is Needs Evidence. - Missing evidence is visible. - Approval is blocked for material cases unless an override rationale is entered. - If override is supported, entering rationale records reviewer identity, timestamp, and rationale in the audit trail. ### No-entry-needed requires rationale Open the low-dollar no-entry-needed seed case and mark no entry needed. Expected result: - The action requires a rationale. - Case can close only after reviewer approval. - Evidence remains linked. - Audit trail records the final disposition. ## Screen-Level Smoke Tests ### Accounting Inbox Verify: - The app does not land on a generic chat homepage. - The Accounting Inbox is reachable as a first-class screen. - Seed artifacts appear with filename, artifact type, vendor link, extraction status, and linked case when available. - Processing updates artifact statuses without duplicating cases. - Unsupported or `other` artifacts remain visible and do not create accounting cases unless an accounting question is detected. ### Close Prep Queue Verify: - Cases show status, vendor, question type, amount, close-period impact, evidence completeness, proposed treatment, and exception flags. - Status and treatment filters narrow the list. - Opening a case preserves enough context to return to the filtered queue. - Needs Evidence, Ready for Review, Approved, Compiled, Deferred, and Rejected statuses render distinctly. ### Case Review Verify: - Above-the-fold summary includes why the case exists, proposed treatment, dollar impact, close-period impact, evidence completeness, and required action. - Required panels render: Trigger, Evidence, Extracted Terms, Proposed Treatment, Prepared Schedule, Draft JE / Reversal, Exceptions and Controls, Comments / Audit Trail. - Case-scoped actions update state and audit trail: approve treatment, request evidence, edit treatment, edit schedule, mark no entry needed, defer, escalate, reject, compile artifact. ## Export Tests Use Playwright download handling to verify: - Prepared schedule CSV includes case ID, vendor, close period, treatment, evidence list, period lines, approval state, and generated timestamp. - Draft JE CSV includes balanced debit and credit lines and a reversal JE when applicable. - Workpaper Markdown or HTML includes case summary, evidence list, extracted terms, treatment rationale, schedule or JE lines, approval state, and audit trail. - Export attempts for unapproved or uncompiled cases are blocked. ## Data Checks Inside Browser Tests Browser tests should include lightweight accounting invariants when data is rendered or exported: - Schedule period amounts sum to source amount within rounding tolerance. - Draft JE debit total equals credit total. - Accrual reversal is dated in the next period. - Every generated schedule and draft JE visibly links back to the case. - Approved/compiled cases include reviewer identity and timestamp. Do not duplicate all unit-level math tests in Playwright. Use one or two representative browser assertions to catch integration regressions. ## Accessibility And Selector Guidance Prefer selectors in this order: 1. `getByRole` with accessible names for navigation, buttons, tabs, filters, dialogs, and panels. 2. `getByLabel` for form fields. 3. `getByText` for stable business terms such as vendor names, statuses, and treatment labels. 4. `data-testid` for tables, schedule rows, JE rows, and generated export actions when role/name locators are ambiguous. Suggested stable test IDs: - `inbox-artifact-row` - `run-processing` - `case-row` - `case-status` - `case-summary` - `evidence-panel` - `prepared-schedule-table` - `draft-je-table` - `exceptions-controls-panel` - `audit-trail` - `approve-treatment` - `compile-artifact` - `export-schedule` - `export-draft-je` ## Minimum Pass Bar The Playwright suite is useful when it proves: - Seed data loads without manual setup. - The three required screens are reachable and populated. - Processing creates the expected seeded accounting cases. - A prepaid case can be approved, compiled, and exported end to end. - Unsafe compile paths are blocked. - Audit events are visible after review and compile actions. ## Suggested First Test To Implement Start with one test file named `tests/e2e/prepaid-happy-path.spec.ts`: ```text Load app -> process seed artifacts -> open Close Prep Queue -> open renewal prepaid case -> verify evidence and schedule -> approve treatment -> compile artifact -> download schedule export -> assert schedule total and audit events ``` This single test proves the main product promise without trying to cover the full runtime at once.