AI-Generated Code Acceptance Checklist: Verify the Result

A working demo is one observation. Acceptance asks a narrower, more useful question: does this exact version satisfy the agreed task, under the conditions that matter, and can someone inspect the evidence?

Use this checklist for a small application feature, an API change, or a bug repair in an authorized environment. Start with the normal user entry point and finish at the durable result. You can use the checklist manually; the related Skills organize the work but are not required to fill it in.

Where this checklist fits

Suitable for independent developers reviewing bounded changes with an identifiable baseline, requirements, and access to the relevant runtime. Scale the checks to the affected behavior rather than the number of files.

It is not a penetration test, accessibility conformance assessment, regulated-system certification, or production load-test plan. Payment, identity, sensitive-data, destructive-migration, and safety-critical changes need additional domain-specific review. Do not use a checked box as a security or legal guarantee.

1. Freeze the acceptance target

Record the baseline and candidate commit or artifact, environment, browser/runtime, roles, approved data source, and permitted side effects. Uncommitted edits need a diff snapshot or hash as well as the commit. Attach the requirement source and assign REQ/AC IDs before looking at test results.

For each requirement, write an observable outcome independent of the implementation. “The Save handler runs” is insufficient; “the authorized user sees the new value after reopening the record” describes a result. Mark missing rules as BLOCKED rather than inferring the desired behavior from generated code.

Use PASS, FAIL, BLOCKED, NOT RUN, or N/A. N/A requires a reason the check is outside this feature, never merely missing tools. A blank evidence field cannot support PASS. Record exceptions as explicit decisions with owner, scope, and follow-up; do not silently turn them into passes.

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.

3. Keep a small, inspectable evidence record

For each case record: CASE ID → REQ/AC → role and data source → exact steps → expected result → actual result → status → pass/fail evidence → environment/version → remaining gap and owner.

Screenshots show visible state; they do not prove persistence. A 200 response does not prove the intended object changed. A green mocked test does not prove a dependency works. Match the evidence to the claim, redact secrets, and share only with authorized reviewers.

Use the companion Markdown template, or copy the case record below. The template contains nine starter rows and space to duplicate cases; a starter row is a coverage prompt, not proof that an entire category passed.

• 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: ____

4. Worked example: a saved display name

Synthetic teaching example only. These inputs and outcomes are invented to demonstrate the record format; they were not run in the user’s production project or any live acceptance session.

Suppose an explicitly agreed rule allows 1–40 Unicode code points after trimming outer whitespace; a user can change only their own display name. This rule is an assumption for the example, not a recommended universal limit.

CASE-NAME-01 / AC-NAME-01: open Profile from the normal menu, save “River”, reopen Profile. Expected: “River” remains and the permitted readback identifies the same account. Hypothetical observation: the toast says saved but reopening shows the old value. Illustrative status: FAIL. Evidence to collect in a real run: before/after screen, redacted request and authoritative readback tied to the account and version. No such runtime evidence is supplied here.

CASE-NAME-02: try empty text after trimming, 1, 40, and 41 code points. Expected: reject empty and 41; accept 1 and 40 under the assumed rule. These are planned cases, NOT RUN. Count the actual samples before using them; code points, bytes, and user-perceived characters differ.

CASE-NAME-03: attempt to change account B using account A in the authorized test environment. Expected: denied with no change to B. CASE-NAME-04: interrupt a save, then retry according to the agreed recovery rule and inspect the final state. Both remain NOT RUN until executed with authorized test accounts and fault conditions.

5. Decide what is actually ready

Keep separate outcomes for repository standards, requirement coverage, and runtime acceptance. An unresolved FAIL, BLOCKED, or NOT RUN acceptance item prevents an overall completion claim for the agreed scope. “No demonstrable defects found in this diff” is a scoped review result, not a guarantee of no bugs.

If a check fails, preserve its evidence and classify the cause: product, test, environment, data, or unclear requirement. Do not weaken an assertion, remove a case, or rerun until lucky to obtain a pass. Repair only within authorization, rerun the original case and affected paths, then review the latest diff.

Use precise delivery language: implemented; locally verified; deployed; or live-path accepted. Local acceptance does not authorize deployment. Deployment does not by itself prove the user’s task works.

Choose a related workflow

• talking-us: Unclear success rule or unresolved product decision: clarify requirements without changing the product.
• write-design-doc: Confirmed requirements but unclear API/data/state contracts: make the design implementable.
• test-case: Turn requirements into cases. Use design for planning or validation for authorized existing checks; mode names do not grant repair or data-substitution permission.
• bug-fixing: A reproduced failure: trace the first broken rule, repair only when authorized, and verify related paths.
• code-review-multiagent: Review the final diff against requirements and callers. Deep Solo is the default; independent agents are conditional on risk and host support.
• develop-closed-loop: Carry an authorized, specified change through implementation, testing, repair, regression, review, and delivery. Install required companion workflows separately.

Known limits and references

This is an original practical guide informed by the six workflow packages, not a report that their agent behavior was tested across models. Skills do not supply accounts, browsers, data, deployment access, or permissions. A single downloaded Skill is not the complete suite. Some UI-design branches refer to the external, unbundled frontend-design-lab workflow.

The template records evidence; it cannot detect defects by itself. Sampling needs a stated equivalence and uncovered branches. Synthetic examples cannot replace required real business data. When access is missing, keep dependent acceptance pending and continue safe independent checks.

For security basics, OWASP recommends permission validation on every request and enforcement at the appropriate trusted boundary: OWASP Authorization Cheat Sheet. For introductory accessibility checks and their limits, see W3C WAI Easy Checks. Neither reference makes this checklist a full audit.

Download the Markdown template