ux-acceptance-coordinator

# Coordinate UX acceptance testing Run a goal-driven browser journey with a tester that has no repository context. Keep site preparation, private success checks, and product diagnosis in the coordinator context. ## Prepare the run 1. Read the selected journey in `acceptance/journeys/`. 2. Check the journey's `status` and `requires` frontmatter. If its status is `needs-profile`, report the missing bootstrap requirements and stop. Do not substitute a simpler profile or relax the journey. 3. Read its site profile in `acceptance/sites/` and the portable tester instructions in `acceptance/tester/SKILL.md`. 4. Choose the journey's target. Use Node unless the journey or change under test requires the Cloudflare runtime. 5. Start one disposable site: ```console pnpm ux:site:start -- --target node --profile editorial-small ``` 6. Keep the run ID, start URL, and run-data path from the command output. Never send the run-data file or API token to the tester. ## Isolate the tester Create the tester outside the repository checkout. Give it only: - the contents of `acceptance/tester/SKILL.md`; - the journey's `Tester brief` section; - the generated start URL; - a writable location for its report and screenshots. Do not give the tester `AGENTS.md`, repository skills, source files, route names, the coordinator checks, or implementation context. Do not describe a clean context as isolated when the selected agent mechanism still exposes the checkout. If the environment cannot create a separate context within the user's authorization, prepare the handoff and ask the user to launch it. Use any agent implementation that provides browser control. Do not translate the brief into tool-specific click instructions. ## Verify and report Wait for the tester to finish or explicitly give up. Preserve its action log, screenshots, and report without rewriting its observations. Run the journey's `Coordinator checks` independently. Prefer a read-only public API with the local token in the run-data file; use direct database inspection only when the public surface cannot establish the result. The tester's claim is not proof of completion. Classify the run as one of: - `PASS`: the checks passed and the tester found no material friction. - `PASS_WITH_FRICTION`: the checks passed and the tester found a concrete UX issue. - `FAIL_PRODUCT`: the site remained usable, but the journey goal was not achieved. - `FAIL_INFRASTRUCTURE`: bootstrap, browser control, or the local server prevented a meaningful attempt. - `INCONCLUSIVE`: the available evidence cannot distinguish product and test failures. Report the functional result separately from UX findings. Include the path taken, failed or confusing actions, evidence, and independent check results. Stop the exact run after collecting evidence, even when the journey fails: ```console pnpm ux:site:stop -- <run-id> ``` Keep the site running only when the user asks to inspect it further.