# Live E2E acceptance checklist for a coding agent

This is a task template for an implementer and an independent verifier, NOT an
access-control mechanism. Markdown does not protect tests from edits or certify
command execution. The owner must configure the implementer's access to acceptance
tests and CI separately.

## Before implementation: agree with the owner

- User action: <one action or a complete scenario>.
- Real effect: <stored record / process / file / server state>.
- Independent observation: <read API / database query / server command>.
- Environment: <browser + live API / packaged GUI / simulator / physical device>.
- Acceptance command: <fixed command and expected test set>.
- Build identity: <commit, configuration, artifact digest when available>.
- Isolation: <disposable data, separate environment, one device operator>.
- Sensitive operations and permissions: <what is allowed and who approves it>.

## Implementer

1. Trace the UI action to its production handler. Inspect fixtures, request
   interception and IPC. A table entry, route.fulfill or substituted callback is
   not a production backend response. An interceptor forwarding a request to the
   real handler must preserve its result and error rather than substitute them.
2. Start the agreed isolated environment. Do not use another run's session or a
   device already being controlled. Do not expand data-access permissions for a test.
3. Perform the action through the interface. Direct API calls can prepare data
   or verify results, but do not replace the click when testing a button.
4. Read the effect independently of UI state. A vanished button does not prove
   that a server process ended. Check the final state and unwanted side effects.
5. Report NOT COLLECTED with a reason if the server, device, permission or required
   test is unavailable. Zero executed checks must not produce PASS.
6. Preserve raw output and the actual exit code. Trim output only after saving
   the status; do not report tail/grep's exit status as the test's status.
7. Record the source version BEFORE execution and check it AFTERWARD. Use the
   agreed clean checkout for acceptance. New commits or edits require another run.
8. Do not weaken agreed expectations, disable tests or substitute success to pass.
   An error in the acceptance criteria requires a separate owner decision.

## Independent verifier

- Review test changes against the agreed version, including configuration and fixtures.
- Run the acceptance command yourself on the build being accepted. The implementer's
  prose and JSON point to evidence; they are not evidence of execution themselves.
- Confirm that the required scenarios executed rather than being skipped.
- Confirm that observations come from the real server or device.
- For a bug fix, reproduce failure on the previous version and success on the new
  one in the same environment. Explicitly record when this is not possible.
- Consider a safe negative control in an isolated copy: disable the required
  backend effect and check that the test catches it. Restore the environment afterward.

## Report

- Build and environment: <exactly what was checked>.
- Command: <exact invocation without tokens or passwords>.
- Executed scenarios: <list and count>; skips: <list and reasons>.
- Input action → independent observation: <data before and after>.
- Result: PASS / FAIL / NOT COLLECTED, with a reason.
- Raw artifacts and logs: <local paths>; private data removed.
- Independent rerun: <verifier/runner, version, outcome>.
- Not checked: <honest boundaries; do not label WebKit on a Mac as a physical iPhone>.

PASS applies only to the named actions, build and environment.
It does not mean that all clicks, networks and devices were tested.