Full Stack E2E Review

Full-stack end-to-end review

Treat the task as a closed-loop product validation, not as "run the existing test suite." Build evidence across code, live services, APIs, and ordinary browser interactions. Do not claim full coverage while a requested layer remains untested.

Hosts load only this skill's name and description until the user asks for an end-to-end review. When that happens, follow the ladder below. Load BetterWright's browser skill or MCP tool guidance before driving the browser — this playbook does not repeat that protocol.

1. Establish the real system and review boundary

1. Read repository instructions and relevant skills first.
2. Inspect the branch diff, recent commits, migrations, environment files, and existing tests.
3. If a prior agent, branch, PR, or environment booted the stack, resolve its exact refs and inspect its environment metadata, setup scripts, transcript/start logs, and diff before reuse. Record both setup and feature refs; avoid copying setup files into the reviewed working tree unless necessary.
4. Map the feature through every affected layer:
   • data model and migrations
   • authorization and ownership rules
   • backend services, routes, jobs, and third-party gates
   • CLI or SDK surfaces
   • frontend state and actions
   • billing, quotas, lifecycle, and recovery paths
5. Write a short review matrix before testing. Its rows are user journeys or invariants; its columns are code inspection, focused test, live API, desktop UI, and mobile UI. Mark every cell passed, failed, not applicable, or blocked.

Use independent subagents in parallel for bounded exploration, setup reconstruction, or visual review. Keep blockers and the final integration in the parent. Give subagents exact files, URLs, actors, fixtures, expected results, prohibited side effects, and required evidence.

Browser harness

This skill defines what to prove, not one vendor's browser syntax.

When BetterWright is available through MCP, CLI, or a native tool:

1. Verify the integration with browser_doctor or betterwright doctor, then prove navigation and screenshot output before the review. Confirm its network policy permits the local test hosts; loopback must remain allowed for localhost applications.
2. Use the host agent's normal shell, repository, file, and test-runner tools for environment setup, database fixtures, raw API checks, code edits, and durable regression tests. BetterWright's browser sandbox has no host filesystem, process, module-loader, or unrestricted network-interception access and is not a replacement for Playwright Test or the project's test runner.
3. Use one named BetterWright session per independent browser lane. Sessions share a cookie jar, so use separate BetterWright profiles for different user identities. For parallel role testing over MCP, configure separate server aliases with distinct BETTERWRIGHT_PROFILE values; otherwise test roles sequentially with explicit sign-out/sign-in and verify identity after every switch.
4. Capture debug images while diagnosing and a visually inspected proof image for each important completed flow. Keep command output, API matrices, test results, and repository diffs as host-agent evidence.

With another browser harness, preserve the same semantics: fresh observed locators, action verification, isolated identities, mobile and desktop viewports, ordinary user controls, and proof screenshots.

2. Model realistic fixtures

Create deterministic local or test-only fixtures that expose boundary failures. Use the application's real persistence layer where practical; do not mock away the behavior being reviewed.

Cover the smallest meaningful matrix:

• actors: owner, admin, member, outsider, and empty/new user
• scopes: personal and shared/tenant scope
• resources: owned by the actor, owned by another member, archived or failed, and empty state
• account states: active, not started/free, past due or suspended when relevant
• collaboration: pending invitation and at least two members
• limits: below limit, at limit, and disallowed action

Use fake credentials and test-only auth helpers. For OAuth-only applications, seed test users and mint local sessions through the application's supported session mechanism without bypassing authorization middleware. Never reuse or expose production secrets. Make fixture scripts idempotent so they can be rerun after fixes.

3. Boot and prove the stack

1. Inspect install and database-preparation scripts before running them. Confirm all database URLs and external services are disposable local/test resources; never reset, migrate, or seed shared or production infrastructure without explicit approval.
2. Start long-lived services through a persistent, inspectable mechanism. Keep startup commands separate from health checks.
3. Verify each required port or health endpoint and inspect recent logs. A running process is not proof that the service is healthy.
4. Record the exact URLs, ports, test actors, and known unavailable integrations.
5. Distinguish harness problems from product failures. Repair the harness only when the change is isolated, reversible, and within the requested scope; otherwise mark it blocked.

4. Review code for missing invariants

Do not rely only on tests that already exist. Trace each journey and actively search for holes such as:

• scope identifiers accepted inconsistently across endpoints
• owner-only fields, URLs, tokens, IPs, or secrets leaking after partial redaction
• UI actions enabled even though the API will reject them
• list, detail, metrics, snapshots, search, or billing endpoints using different tenancy fences
• actor identity confused with billing subject or resource owner
• permission checks missing on mutation paths
• "personal" behavior differing between UI, CLI, API, and stored identifiers
• stale, loading, empty, partial-error, retry, and past-due states
• migration, rollback, idempotency, concurrency, and post-credit or post-plan behavior

For sensitive fields, assert absence as well as presence. For mutations, verify both the response and persisted state.