verification-before-completionlisted

# Verification Before Completion Do not claim success without fresh evidence. ## Core Rule Match every positive claim to a verification command or direct inspection result from the current session. If you cannot verify, say that you could not verify and explain why. ## Workflow 1. Identify the claim. Examples: tests pass, bug is fixed, build succeeds, migration works, file exists, branch is clean. 2. Identify the command or inspection that proves the claim. 3. Run it now. 4. Read the full result, including exit status and failure count. 5. Report the real outcome. ## Minimum Evidence - "Tests pass" requires the relevant test command. - "Build succeeds" requires the build command. - "Bug is fixed" requires a repro or regression check. - "Files were created" requires filesystem inspection. - "Git state is clean" requires `git status --short`. Previous runs, assumptions, and partial checks do not count as proof. ## Codex-Specific Rules - Use the project's real verification commands when available. - Prefer the narrowest command that proves the claim, then expand if needed. - If a command is too expensive or unavailable, state that clearly instead of implying success. - When handing work back to the user, separate: - what was verified - what was not verified ## Good Patterns - "Ran `pytest tests/foo_test.py`; it passed." - "Ran `npm test -- widget`; one failing test remains." - "I did not run integration tests because credentials are missing." ## Red Flags -