---
name: verification-before-completion
description: >-
  Use when about to claim work is complete, fixed, or passing -- requires
  running verification commands and confirming output before making any
  success claims. Evidence before assertions, always.
type: behavioral
trigger-patterns:
  - claiming completion
  - committing code
  - asserting tests pass
  - marking tasks done
discipline: rigid
allowed-tools:
  - Bash
  - Read
category: verification
tags:
  - verification
  - evidence
  - completion
agents:
  - gmd-executor
  - gmd-verifier
---

# 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

| Claim | Requires | Not Sufficient |
|-------|----------|----------------|
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
| Regression test works | Red-green cycle verified | Test passes once |
| Agent completed | VCS diff shows changes | Agent reports "success" |
| Requirements met | Line-by-line checklist | Tests passing |

## 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
- Relying on partial verification
- Thinking "just this once"
- Tired and wanting work over
- **ANY wording implying success without having run verification**

## Rationalization Prevention

| Excuse | Reality |
|--------|---------|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence does not equal evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter does not equal compiler |
| "Agent said success" | Verify independently |
| "I'm tired" | Exhaustion does not equal excuse |
| "Partial check is enough" | Partial proves nothing |
| "Different words so rule doesn't apply" | Spirit over letter |

## Key Patterns

**Tests:**
```
CORRECT: [Run test command] [See: 34/34 pass] "All tests pass"
WRONG:   "Should pass now" / "Looks correct"
```

**Regression tests (TDD Red-Green):**
```
CORRECT: Write -> Run (pass) -> Revert fix -> Run (MUST FAIL) -> Restore -> Run (pass)
WRONG:   "I've written a regression test" (without red-green verification)
```

**Build:**
```
CORRECT: [Run build] [See: exit 0] "Build passes"
WRONG:   "Linter passed" (linter doesn't check compilation)
```

**Requirements:**
```
CORRECT: Re-read plan -> Create checklist -> Verify each -> Report gaps or completion
WRONG:   "Tests pass, phase complete"
```

**Agent delegation:**
```
CORRECT: Agent reports success -> Check VCS diff -> Verify changes -> Report actual state
WRONG:   Trust agent report
```

## Why This Matters

- Trust broken by false completion claims cannot be rebuilt easily
- Undefined functions shipped would crash in production
- Missing requirements shipped means incomplete features
- Time wasted on false completion leads to redirect and rework
- Honesty is a core value. Evidence is honesty in action.

## 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.

This is non-negotiable.

## Domain Rationalization Prevention

These domain-specific patterns extend the universal rationalization-prevention skill:

| Thought | Reality |
|---------|---------|
| "Should work now" | "Should" is not evidence. Run the command. |
| "I'm confident this is correct" | Confidence is not verification. Run the command. |
| "I just ran it and it passed" | "Just ran" means nothing if it's not in THIS message. Fresh run only. |
| "The change is trivial" | Trivial changes cause non-trivial failures. Verify. |

## Source Preference During Verification

When verifying work against a Knowledge note, debug-session artifact, or
research summary, treat sources in this authority order (highest to lowest):

| Tier | Source | When to prefer |
|------|--------|----------------|
| 1 | Direct observation | Always when reproducible (run command, read file, query state) |
| 2 | Append-only evidence files | When direct observation is unavailable (`.planning/debug/**` Evidence entries, audit log lines, NDJSON events) |
| 3 | Git diffs | When you need to know what changed, not what is now |
| 4 | Summary prose | Fallback only — summary is a compressed claim about tiers 1-3 |

### Iron rule for `raw_source:` notes

If a note used during verification carries a `raw_source:` frontmatter field
(populated by debug-origin or research-origin authoring), the verifier MUST:

1. Resolve the pointer (read the pointed file) BEFORE acting on the summary body.
2. Treat raw-source content as higher-authority evidence than the summary prose.
3. If the pointer is missing, malformed, or points outside the repo, flag
   reduced confidence — do NOT fail the verification, do NOT block. Fail-open
   semantics inherited from v1.3 §4 governing invariants.

### Iron rule for diagnostic tasks WITHOUT `raw_source:`

If the verification task is diagnostic (debug, regression check, root-cause
confirmation) AND the consulted note has no `raw_source:` field, the verifier
MUST flag reduced confidence in the verification report. Diagnostic decisions
on summary-only evidence are the failure mode this section exists to prevent.

### Red Flags — STOP

- Trusting the summary body when a `raw_source:` pointer is present and unread
- Skipping the pointer resolution because "the summary looks right"
- Acting on diagnostic conclusions without checking for `raw_source:` at all
- Treating tier-4 summary prose as authoritative when tier-1 / tier-2 / tier-3
  evidence is reachable in the repo

### Why this section exists

LLM-generated summaries can compress away the very detail a verifier needs
(exact iteration count, microsecond timestamps, byte-for-byte response body).
Meta-Harness Table 3 (arXiv 2603.28052) measured a 38.7% / 56.7% accuracy gap
between summary-only and raw-trace diagnostic proposers. v1.4 DIAG carries
raw sources via `raw_source:` so verifiers can close that gap when it matters.
