Verification Before Completion

Overview

Claiming work is complete without verification is dishonesty, not efficiency.

Core principle: Evidence before claims, always.

Violating the letter of this rule is violating the spirit of this rule.

The Iron Law

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If you haven't run the verification command in this message, you cannot claim it passes.

The Gate Function

BEFORE claiming any status or expressing satisfaction:

1. IDENTIFY: What command proves this claim?
2. RUN: Execute the FULL command (fresh, complete)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does output confirm the claim?
   - If NO: State actual status with evidence
   - If YES: State claim WITH evidence
5. ONLY THEN: Make the claim

Skip any step = lying, not verifying

Common Failures

Red Flags - STOP

• Using "should", "probably", "seems to"
• Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
• About to commit/push/PR without verification
• Trusting agent success reports
• Reporting a negative ("none exist", "all clean") from a scope you did not actually search — or never searched at all because the location list came from memory, a stale note, or a deleted script
• Inventing the coverage of a check ("every repo it ever ran in") you never established
• Treating an interrupted, errored, or partial search as evidence of absence
• Relying on partial verification
• Thinking "just this once"
• Tired and wanting work over
• ANY wording implying success without having run verification

Rationalization Prevention

Key Patterns

Tests:

✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"

Regression tests (TDD Red-Green):

✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
❌ "I've written a regression test" (without red-green verification)

Build:

✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)

Requirements:

✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"

Universal negatives — the scope must be discovered, not recalled:

✅ [Run search_files (target='files') over the real root] [See: the actual set of locations]
   "No leftovers in <named root>; I searched <path>, not a remembered list"
❌ "Every repo the loop ran against is clean"  ← recalled list, never searched

A negative claim is only as strong as the search behind it. Enumerate the scope with a live discovery command before claiming anything is absent, clean, or complete — a remembered project list is a hypothesis, not a filesystem. When the search cannot cover everything, say exactly what was searched and what was not. A failed or interrupted search proves nothing at all.

Why This Matters

From 24 failure memories:

• your human partner said "I don't believe you" - trust broken
• Undefined functions shipped - would crash
• Missing requirements shipped - incomplete features
• Time wasted on false completion → redirect → rework
• Violates: "Honesty is a core value. If you lie, you'll be replaced."

Scope: commands, never browser sessions

"Verification command" above means a deterministic local command: test runner, linter, typechecker, or build. This skill never requires launching a browser session (CDP connection, DevTools MCP, Playwright, DOM scraping, screenshots) — browser audits belong exclusively to the pipeline station that orders them (Station IIIB fix loop, Station IV gates), or to an explicit operator request. An explicit opt-out ("just build", "no browser check") is honored immediately: run the build/tests only, report browser verification as skipped, and move on.

When To Apply

ALWAYS before:

• ANY variation of success/completion claims
• ANY expression of satisfaction
• ANY positive statement about work state
• Committing, PR creation, task completion
• Moving to next task
• Delegating to agents

Rule applies to:

• Exact phrases
• Paraphrases and synonyms
• Implications of success
• ANY communication suggesting completion/correctness

The Bottom Line

No shortcuts for verification.

Run the command. Read the output. THEN claim the result.

And read the record before you hand over a manual check. When your report tells a human how to see the change for themselves — a "How to verify" block, a walkthrough, a closeout — a written one may already exist in the PR body, the PR summary, the issue, or an earlier report. Read it first and decide deliberately: reuse, tighten, or replace. Any difference gets one line saying why. Quietly dropping a step or a flag the artifact already got right is a verification failure of the same family as claiming an unrun check passed: both present something you did not prove.

This is non-negotiable.