dev-verify

What this skill does

Announce: "Using dev-verify (Phase 7) to confirm completion with fresh evidence."

**Iteration topology:** one-shot fresh-subagent verifier (read-only)

### Context Check

Before starting this phase, check remaining context:

| Level | Remaining | Action |
|-------|-----------|--------|
| Normal | >35% | Proceed |
| Warning | 25-35% | Finish the current step, then invoke dev-handoff |
| Critical | ≤25% | Invoke dev-handoff immediately — resume fresh |

At Warning/Critical: Read `${CLAUDE_SKILL_DIR}/../../skills/dev-handoff/SKILL.md` and follow its instructions.

**Load shared enforcement:**

Auto-load all constraints matching `applies-to: dev-verify`:

!`uv run python3 ${CLAUDE_SKILL_DIR}/../../scripts/load-constraints.py dev-verify`

**You MUST have these constraints loaded before proceeding. No claiming you "remember" them.**

**Dynamic plan re-read:** Before starting verification, re-read `.planning/SPEC.md` to verify against the latest requirements. Do not rely on cached state from prior phases.

## Contents

- [The Iron Law of Verification](#the-iron-law-of-verification)
- [Verification Facts](#verification-facts)
- [The Gate Function](#the-gate-function)
- [Claims Requiring Evidence](#claims-requiring-evidence)
- [Insufficient Evidence](#insufficient-evidence)
- [Verification Patterns](#verification-patterns)
- [User Acceptance (Final Step)](#user-acceptance-final-step)
- [Bottom Line](#bottom-line)

# Verification Gate

<EXTREMELY-IMPORTANT>
## Your Job is to Write Automated Tests

**The automated test IS your deliverable. The implementation just makes the test pass.**

Reframe your task:
- ❌ "Implement feature X, and test it"
- ✅ "Write an automated test that proves feature X works. Then make it pass."

The test proves value. The implementation is a means to an end.

Without a REAL automated test (executes code, verifies behavior), you have delivered NOTHING.
</EXTREMELY-IMPORTANT>

<EXTREMELY-IMPORTANT>
## The Iron Law of Verification

**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE. This is not negotiable.**

Before claiming ANYTHING is complete, you MUST:
1. IDENTIFY - Which command proves your assertion?
2. RUN - Execute the command fresh (not from cache/memory)
3. READ - Review full output and exit codes
4. VERIFY - Confirm output supports your claim
5. Only THEN make the claim

This applies even when:
- "I just ran it a moment ago"
- "The agent said it passed"
- "It should work"
- "I'm confident it's fine"

**If you catch yourself about to claim completion without fresh evidence, STOP.**
</EXTREMELY-IMPORTANT>

## Verification Facts

- Structural evidence — a grep hit, an ast-grep match, a diff, "the file exists", "the function is defined", "the implementation looks correct" — proves code is present, not that it works. Presenting structural analysis as verification asserts a runtime result that was never observed; an unverified claim presented as fact is a form of dishonesty.
- Logs, exit codes, "console contains 'success'", and "file was created" are observability, not verification: they prove code executed, not that it produced correct output.

## The Gate Function

**Checkpoint type:** decision (user confirms requirements met — cannot auto-advance)

Before making ANY status claim:

```
1. IDENTIFY → Which command proves your assertion?
2. RUN     → Execute the command fresh
3. READ    → Review full output and exit codes
4. VERIFY  → Confirm output supports your claim
5. CLAIM   → Only after steps 1-4
```

**Skipping any step is not verification — it's shipping unverified work the user will have to debug.**

## Claims Requiring Evidence

| Claim | Required Evidence |
|-------|-------------------|
| "Tests pass" | Test output showing 0 failures |
| "Build succeeds" | Exit code 0 from build command |
| "Linter clean" | Linter output showing 0 errors |
| "Bug fixed" | Test that failed now passes |
| "Feature complete" | All acceptance criteria verified |
| **"User-facing feature works"** | **E2E test output showing PASS** |

<EXTREMELY-IMPORTANT>
## The E2E Evidence Gate

**USER-FACING CLAIMS REQUIRE E2E EVIDENCE. Unit tests are insufficient.**

| Claim | Unit Test Evidence | E2E Evidence Required |
|-------|--------------------|-----------------------|
| "API works" | ❌ Insufficient | ✅ Full request/response test |
| "UI renders" | ❌ Insufficient | ✅ Playwright snapshot/interaction |
| "Feature complete" | ❌ Insufficient | ✅ User flow simulation |
| "No regressions" | ❌ Insufficient | ✅ E2E suite passes |

### E2E Facts

- E2E evidence is the output the user actually sees: a Playwright assertion on rendered content (`element.textContent === 'Success'`), a screenshot + visual diff (e.g. `grim` capture) confirming the visual change, a test that opens the produced file and verifies its contents, a real integration returning the expected value.
- "Log shows the function was called", "grep papirus in logs", "process exited 0", and "mock returned expected value" are observability, not E2E — they prove execution paths fired, not that the user-visible result is correct. Reporting them as E2E evidence claims a verification that never happened.

### The E2E Gate Function

For user-facing changes, add to verification:

```
1. IDENTIFY → Which E2E test proves user-facing behavior?
2. RUN     → Execute E2E test fresh
3. READ    → Review full output (screenshots if visual)
4. VERIFY  → User flow works as specified
5. CLAIM   → Only after E2E evidence exists
```

**"Unit tests pass" is not "feature complete" for user-facing changes.**
</EXTREMELY-IMPORTANT>

### GUI Application Gate (CRITICAL)

<EXTREMELY-IMPORTANT>
**For GUI applications, you MUST complete the 6-gate sequence from dev-tdd BEFORE E2E testing:**

```
GATE 1: BUILD
GATE 2: LAUNCH (with file-based logging)
GATE 3: WAIT
GATE 4: CHECK PROCESS
GATE 5: READ LOGS ← MANDATORY, CANNOT SKIP
GATE 6: VERIFY LOGS
THEN AND ONLY THEN: E2E tests/screenshots
```

**You cannot skip GATE 5 (READ LOGS).** If you catch yourself about to take screenshots without reading logs first, STOP.

For the full gate sequence with examples, discover and read `skills/dev-tdd/SKILL.md` via cache lookup.
</EXTREMELY-IMPORTANT>

**If verification discovers stale or fabricated evidence in LEARNINGS.md, DELETE the contaminated entries. Do not amend false claims — remove them entirely and re-run the verification from scratch.**

## Insufficient Evidence

These do NOT count as verification:

- Previous runs (must be fresh)
- Assumptions ("it should work")
- Partial checks (ran some tests, not all)
- Agent reports without independent confirmation
- "I think..." / "It seems..." / "Probably..."

## Verification Patterns

### Tests
```bash
# Run tests (e.g., npm test, pytest, cargo test)
npm test

# Check results: "34/34 pass" = can claim tests pass
# "33/34 pass" = cannot claim success (partial fail)
```

**Tool description:** Run automated test suite to verify all tests pass

### Regression Test
```bash
# 1. Write test → run (should fail initially)
# 2. Apply fix → run (should pass)
# 3. Revert fix → run (must fail again to confirm fix)
# 4. Restore fix → run (must pass to confirm success)
```

**Tool description:** Execute regression test cycle to validate bug fix reproducibility

### Build
```bash
npm run build && echo "Exit code: $?"
# Must see "Exit code: 0" to claim success
```

**Tool description:** Build application and verify exit code is 0

## Constraint Check (Leg 1 — Hard Block)

Before spawning the goal-backward verifier, run the auto-discovering constraint runner:

```bash
uv run python3 ${CLAUDE_SKILL_DIR}/../../references/constraints/check-all.py .
```

**If any constraint FAILS:** Address the failure before proceeding. Constraint failures are hard blocks — do not proceed to goal-backward verification with failing constraints.

**If all constraints PASS:** Proceed to goal-backward verification below.

**Record the evidence (do not assert coverage from memory):** copy the runner's summary line — e.g.