[Feature Request]: Automated Playwright and Screenshot Flow

[L03TJ3]

Feature summary

Introduce an automated Playwright-based browser testing and screenshot flow for GoodWallet. The flow should make it practical to exercise selected user journeys in a real browser and capture consistent visual evidence of key screens as part of development and CI.

Problem or opportunity

GoodWallet currently has unit-test coverage through Vitest, but no established end-to-end browser automation or repeatable screenshot workflow. This leaves important UI journeys, responsive layouts, and integration behavior reliant on manual checks, and makes visual changes difficult to review consistently.

Contributors, reviewers, QA, and product/design stakeholders would benefit from a shared, repeatable way to validate critical flows and inspect the resulting UI.

Proposed solution

Establish Playwright as the project’s browser-automation foundation, with a deliberately small initial set of stable, high-value journeys. The solution should:

• Provide a documented local command for running browser tests and generating screenshots.
• Start the application with a deterministic test configuration and avoid requiring real user funds, production credentials, or uncontrolled third-party state.
• Define reusable setup, test-data, and authentication/mocking patterns appropriate for GoodWallet's wallet and network integrations.
• Capture screenshots at agreed checkpoints and viewport sizes, using predictable naming and storage conventions.
• Make relevant screenshots and failure artifacts available from CI for pull-request review.
• Integrate an appropriate automated check into the existing PR workflow, while keeping feedback reliable and reasonably fast.
• Document how to add a new browser flow, update approved screenshots when intentional UI changes occur, and diagnose failures.

The planning phase should recommend the initial journeys, screenshot baselines versus run-time-only captures, supported browsers/viewports, artifact retention, and the right CI trigger strategy. Visual-diff regression testing is a possible follow-on; the first increment should prioritize dependable browser coverage and screenshot artifacts over a broad visual-regression matrix.

Additional context

• The application is a Next.js project using Yarn and has Vitest unit tests (yarn test).
• The existing GitHub Actions pull-request workflow already runs tests and is the natural integration point to evaluate during planning.
• This request intentionally describes desired outcomes rather than prescribing selectors, fixtures, exact routes, or a final CI design. Those details should be resolved in the implementation plan with product and engineering input.

Create the plan

Based on the above description create an execution plan in a new sub-issue and preserve the original issue content unchanged.
Do not execute the plan until given instructions to do so.

Sub-issue requirements:

• Title format: [DRAFT][PLAN] <what issue is being planned>
• Type: Task
• Description must start with: <sub-issue title>
• Link the sub-issue back to this parent issue.

Instructions when creating the plan:

• Map relevant files that are too be used as reference from all repos mentioned
• import existing @GoodDollar packages

Plan specification required sections:

• Required states, flows, and behaviors
• Execution plan
• acceptance criteria
• human-reviewer checklist