# AI-Generated Code Acceptance Checklist: Verify the Result

## Reusable acceptance record

Blank template: no tests have been run and no outcome is pre-approved. Duplicate each case for distinct behaviors. Do not put credentials or private customer data in this file.

## Target and authorization

- Task / owner / date: ____
- Baseline / candidate commit / uncommitted diff snapshot: ____
- Environment / runtime / browser / device: ____
- Requirements and confirmation source: ____
- Authorized roles / data provenance / permitted read-write scope: ____
- External effects / stop condition / cleanup authorization: ____
- Performance threshold and source / measurement method: ____
- Excluded scope and decision source: ____

## 2. Run the applicable checks

- [ ] Requirements: Map every REQ/AC to an implementation entry point, case, and result. Include promised behavior absent from the diff; record agreed exclusions. Check that the change did not add a new business rule or permission.

- [ ] Core function and persistence: Start from the normal role-specific entry point. Complete the task and verify the result. For writes, refresh or reopen and read the authoritative state through permitted access; correlate the same object and request. A success toast alone is insufficient.

- [ ] Boundaries and state: Check omitted, empty, invalid, lower-bound and upper-bound inputs where applicable. Use the actual counting unit and business rule. Exercise legal and forbidden state transitions, repeated clicks, stale views, and competing updates when these can affect the result.

- [ ] Errors and recovery: In an authorized isolated environment, exercise relevant timeout, rejection, partial failure, and interruption paths. Check that users know what happened and can recover. Verify retries do not duplicate side effects and a late response cannot undo a newer action.

- [ ] Security basics: Check server-side authorization for the actual action and object, including a second test account with different ownership. Verify rejected requests do not change data. Inspect applicable input validation, output encoding, and credential exposure in bundles/logs. Run only authorized checks, never attacks against unrelated systems.

- [ ] Accessibility and interaction: Complete the affected flow using the keyboard; inspect focus, names/labels, errors, and dialog dismissal. Check zoom and narrow layouts, readable contrast, and meaningful text alternatives. Add assistive-technology checks appropriate to the product; these basic checks do not establish conformance.

- [ ] Performance: Agree the operation, data size, device/network conditions, measurement method, and threshold before testing. Measure the complete user operation, not just an API call. Compare with the baseline under the same conditions; retain samples and resources observed. If no threshold exists, report measurements and a pending decision.

- [ ] Regression and review: Run affected existing checks and repository-required lint/type/build/tests. Exercise shared callers and adjacent valid/invalid paths. Review the final diff for omitted requirements and weakened assertions. For a repair, preserve a signal that fails before the fix and passes after it.

- [ ] Evidence and delivery: Link every claim to the tested version, actual steps/command, expected result, observed result, and raw evidence. Label mocks, fixtures, synthetic data, and static review. Confirm that evidence still matches the final diff. Report local verification, deployment, and target-runtime acceptance separately.

| Check | REQ/AC and CASE IDs | Status | Pass evidence | Fail evidence | Gap / owner / next step |
| --- | --- | --- | --- | --- | --- |
| Requirements | ____ | NOT RUN | ____ | ____ | ____ |
| Core function and persistence | ____ | NOT RUN | ____ | ____ | ____ |
| Boundaries and state | ____ | NOT RUN | ____ | ____ | ____ |
| Errors and recovery | ____ | NOT RUN | ____ | ____ | ____ |
| Security basics | ____ | NOT RUN | ____ | ____ | ____ |
| Accessibility and interaction | ____ | NOT RUN | ____ | ____ | ____ |
| Performance | ____ | NOT RUN | ____ | ____ | ____ |
| Regression and review | ____ | NOT RUN | ____ | ____ | ____ |
| Evidence and delivery | ____ | NOT RUN | ____ | ____ | ____ |

## Copy one record per case

- CASE / REQ / AC: ____
- Role / starting state / data source and substitution permission: ____
- Exact reproducible steps or command: ____
- Expected result and rule source: ____
- Actual result: ____
- Status (PASS / FAIL / BLOCKED / NOT RUN / N/A): ____
- Pass evidence: artifact or redacted log, timestamp, version: ____
- Fail evidence: exact mismatch and artifact, timestamp, version: ____
- Persistence / external terminal-state readback: ____
- N/A rationale or remaining gap / owner / next step: ____
- Before-fix result / after-fix result / affected regression: ____
- Final-diff review evidence: ____

## Decision and handoff

- Standards: PASS / FAIL / PENDING VERIFICATION: ____
- Spec: PASS / FAIL / PENDING VERIFICATION / NO AUTHORITATIVE SPEC: ____
- Runtime acceptance: PASS / FAIL / NOT RUN: ____
- Open acceptance items / owner / resumption condition: ____
- Explicit exceptions / decision source / residual risk: ____
- Delivery state: implemented / locally verified / deployed / live-path accepted: ____
- Recovery or rollback plan and authorization: ____
- Reviewer / date / final artifact version: ____

Leave the decision pending while applicable acceptance items are FAIL, BLOCKED, or NOT RUN. Evidence for fixtures, mocks, synthetic data, and static review must remain labelled. This template is not security or accessibility certification.