---
name: completion-gate
description: Use when about to declare work done, fixed, or passing, before committing or opening PRs - demands executing verification commands and reading their output before making any success assertions; evidence precedes claims always
---

# Completion Gate

## Overview

Declaring work complete without verification is dishonesty, not efficiency.

**Core principle:** Evidence precedes assertions, always.

**No exceptions. No workarounds. No shortcuts.**

## The Prime Directive

```
NO COMPLETION ASSERTIONS WITHOUT FRESH VERIFICATION OUTPUT
```

If the verification command has not been executed in this message, you cannot assert it passes.

## The Entry Protocol

```
BEFORE asserting any status or expressing confidence:

1. IDENTIFY: Which command substantiates this assertion?
2. EXECUTE: Run the FULL command (fresh, complete)
3. INSPECT: Read every line of output, check exit code, tally failures
4. CONFIRM: Does the output support the assertion?
   - If NO: Report actual status with evidence
   - If YES: State the assertion WITH supporting evidence
5. ONLY THEN: Make the assertion

Skipping any step = fabrication, not verification
```

## Verification Requirements

| Assertion | Demands | Insufficient |
|-----------|---------|--------------|
| Tests pass | Test runner output showing 0 failures | Prior run, "should pass" |
| Linter clean | Linter output showing 0 errors | Partial scan, extrapolation |
| Build succeeds | Build command with exit code 0 | Linter passing, log fragments |
| Bug resolved | Original symptom tested and passes | Code modified, assumed fixed |
| Regression test valid | Red-green cycle confirmed | Single green pass |
| Agent finished | VCS diff showing actual changes | Agent self-reported "done" |
| Specification met | Line-by-line requirement checklist | Tests passing alone |

## Guardrails - HALT

- Using hedging language: "should", "probably", "seems to"
- Expressing premature satisfaction ("Done!", "Perfect!", "All good!")
- About to commit/push/open PR without verification
- Trusting an agent's self-reported success
- Relying on partial or stale verification
- Thinking "just this one time"
- Fatigued and wanting to wrap up
- **ANY phrasing that implies success without having run verification**

## Cognitive Traps

| Rationalization | Truth |
|-----------------|-------|
| "Should work now" | EXECUTE the verification |
| "I'm confident" | Confidence is not evidence |
| "Just this once" | No exceptions |
| "Linter passed" | Linter is not the compiler |
| "Agent reported success" | Verify independently |
| "I'm tired" | Fatigue is not justification |
| "Partial check is enough" | Partial proof is no proof |
| "Different wording so rule doesn't apply" | Intent over technicality |

## Verification Patterns

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

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

**Build:**
```
CORRECT: [Run build] [Output: exit 0] "Build passes"
WRONG: "Linter passed" (linter does not validate compilation)
```

**Specification compliance:**
```
CORRECT: Re-read plan -> Create checklist -> Verify each item -> Report gaps or completion
WRONG: "Tests pass, phase done"
```

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

## Verifying Configuration Changes

When testing changes to configuration, providers, feature flags, or environment settings:

**Do not merely confirm the operation succeeded. Confirm the output reflects the intended change.**

### The Silent Fallback Problem

An operation can succeed because *some* valid configuration exists, even if it is not the configuration you intended to apply.

| Change | Insufficient | Required |
|--------|-------------|----------|
| Switch LLM provider | HTTP 200 | Response body contains expected model identifier |
| Toggle feature flag | No errors | Feature behavior observably active |
| Change environment | Deployment succeeds | Logs/variables reference the new environment |
| Set credentials | Authentication succeeds | Authenticated identity is the correct one |

### Configuration Verification Sequence

```
BEFORE asserting a configuration change works:

1. IDENTIFY: What should be DIFFERENT after this change?
2. LOCATE: Where is that difference observable?
3. EXECUTE: Command that exposes the observable difference
4. CONFIRM: Output contains the expected difference
5. ONLY THEN: Assert the configuration change works

Warning signs:
  - "Request succeeded" without inspecting content
  - Checking status code but ignoring response body
  - Confirming no errors but lacking positive confirmation
```

## Verifying UI Work

When asserting UI work is complete:

| Assertion | Demands | Insufficient |
|-----------|---------|--------------|
| Component matches design | Visual comparison against UX reference | "It looks right to me" |
| Responsive design works | Tested at mobile, tablet, desktop breakpoints | Desktop-only check |
| Accessibility passes | Screen reader test + keyboard navigation + contrast check | "I added aria labels" |
| Design tokens applied | Spacing/colors/typography match token values | "I used the right classes" |

## Why This Matters

From accumulated failure patterns:
- your human partner said "I don't believe you" — trust shattered
- Undefined functions shipped — immediate 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."

## When to Apply

**ALWAYS before:**
- ANY variation of success or completion claims
- ANY expression of satisfaction
- ANY positive statement about work state
- Committing, PR creation, task completion
- Transitioning to the next task
- Delegating to agents

**Rule applies to:**
- Exact phrases
- Paraphrases and synonyms
- Implications of success
- ANY communication suggesting completion or correctness

## The Bottom Line

**There are no shortcuts for verification.**

Execute the command. Read the output. THEN state the result.

This is non-negotiable.