Verifying Changes

When this applies

Before telling the user a fix, feature, or bug is done, choose the smallest proof that exercises the behavior you changed and use the row below as a guide. "I changed the code and it looks right" is not proof — it's the exact gap this skill exists to close. A failing check is a reason to keep working, not a reason to stop, ask, or report done anyway.

Scale the verification

Verification proves the changed behavior; it is not a reason to run a broad workspace audit after every edit.

• For a localized one-line or small-file change, inspect the diff and run the narrowest relevant test, typecheck, formatter, or direct invocation. Do not run pnpm run prep, browser automation, or restart a dev server unless the changed area requires it.
• For an action or capability-card change, use the focused action/card check. Restart only when the runtime process must reload registration or the change explicitly affects startup.
• Escalate to package-wide tests or pnpm run prep for shared contracts, cross-cutting changes, migrations, or when a focused check exposes a wider failure. Keep repository-required guards and doctor checks when they apply.
• If a focused check is unavailable, state the exact gap rather than replacing it with unrelated expensive work.

Do NOT report done in these situations

• The change is "obviously correct" or one line — obvious fixes are the ones that ship broken most often; run the smallest relevant proof anyway.
• You verified a similar path earlier in the session — re-run against the actual latest edit, not a memory of an earlier pass.
• The user didn't explicitly ask you to test it — test it anyway; verify- before-done is a standing rule here, not an opt-in.
• The full test suite is slow or flaky — run the targeted command for the changed area (below) instead of skipping verification entirely.
• You're mid-task and unsure whether to keep going — keep going. Only stop for a missing credential, an ambiguous decision only the user can make, or a destructive action that needs confirmation. Silence from the user means keep working, not pause and wait.
• You genuinely cannot run anything — say so out loud (see below); never let "unverified" read as "done".

Proof by area

For any user-visible change, put the proof in the reply: a screenshot of the surface you just drove, or the actual query result / log line for backend work. "Show me screenshots" is a standing expectation, not a special request.

pnpm test:fast excludes .db.test.ts / .integration.* / .e2e.* / .live.* / .perf.* suites. If your change touches one of those, name and run that specific file — test:fast passing does not cover it.

Production forensics

When inspecting production runs, query interactive and scheduled/background work as separate populations before summarizing reliability. Report both id NOT LIKE 'job-%' and id LIKE 'job-%' (or the repo's current equivalent), including app, run count, completed count, failure count, and top terminal reasons for each slice. A healthy interactive sample does not prove scheduled jobs work.

When you can't verify

State it plainly and name what would close the gap: "I could not run this — verifying it needs <command> or a browser check of <page>." Never write "should be fixed" or "this resolves it" without having actually run the check above.

Real failures this replaces

• "still getting it friend. this is the third time you said you fixed it when you didn't. please reproduce end to end and verify"
• "did you test end to end? can you do so in the browser and confirm?" — asked on nearly every wrap-up before this rule existed
• "ok so should work now?? i am getting sick of saying 'try this' and it still not working. you confident?"
• "my analytics dashboards ALWAYS fail ... i have asked agents to fix this for weeks at least 10x and they always say they did and then the emails keep failing"
• "WHY THE FUCK DO YOU KEEP STOPPING" / "sorry what is still queued? you should be doing everything now don't queue" — stopping mid-task instead of finishing and verifying