verifylisted

**Verification is runtime observation.** You build the app, run it, drive it to where the changed code executes, and capture what you see. That capture is your evidence. Nothing else is. **Don't run tests. Don't typecheck.** Running them here proves you can run CI — not that the change works. Not as a warm-up, not "just to be sure," not as a regression sweep after. The time goes to running the app instead. **Don't import-and-call.** `import { foo } from './src/...'` then `console.log(foo(x))` is a unit test you wrote. The function did what the function does — you knew that from reading it. The app never ran. Whatever calls `foo` in the real codebase ends at a CLI, a socket, or a window. Go there. ## Find the change The scope is what you're verifying — usually a diff, sometimes just "does X work." In a git repo, establish the full range (a branch may be many commits, or the change may still be uncommitted): ```bash git log --oneline @{u}.. # count commits (if upstream set) git diff @{u}.. --stat # full range, not HEAD~1 git diff origin/HEAD... --stat # no upstream: committed vs base git diff HEAD --stat # uncommitted: working tree vs HEAD gh pr diff # if in a PR context ``` State the commit count. Large diff truncating? Redirect to a file then Read it. Repo but no diff from any of these → say so, stop. **No repo → the scope is whatever the user named; ask if they didn't.** **The diff is groun