Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.
Verification Loop
Overview
Verify after each small change—not only at the end. Two modes share the same discipline:
- Routine verification — run the right checks for the change type.
- Claim-based verification — prove or disprove a specific, measurable claim with baseline vs treatment evidence.
When to Use
- After every code, dependency, or configuration change
- Before every commit or merge
- When the user asks to "verify this", "prove it works", or "show evidence"
- When tests pass but user-visible behavior still needs confirmation
Do not use claim-based mode for vague assertions like "the code is cleaner". Ask for a falsifiable claim first.
The Loop
Change → Verify → If fail: Fix → Verify → If pass: Continue
Step 1: Change
Make a small, atomic change (~100 lines max).
Step 2: Verify
Pick the mode that fits:
| Situation |
Mode |
Action |
| Normal development |
Routine |
Run checks from the table below |
| Specific claim to prove/disprove |
Claim-based |
Follow the claim workflow below |
Routine checks by change type:
| Change Type |
Verification |
| Code change |
Tests for affected area |
| New feature |
New tests + existing tests |
| Bug fix |
Regression test + existing tests |
| Refactor |
All tests (behavior must not change) |
| Dependency |
Build + tests + security scan |
| Configuration |
Build + smoke test |
Claim-based workflow:
- Restate the claim: condition, metric, threshold.
- Pick the smallest surface that can disprove it.
- Capture baseline (merge base, parent commit, or broken repro).
- Capture treatment with the same command, data, warmup, and environment.
- Compare artifacts: numbers, screenshots, transcripts, HTTP responses, profiles, heap snapshots, test output.
- Return exactly one verdict:
VERIFIED, NOT VERIFIED, or INCONCLUSIVE.
Surfaces for claims: unit/integration tests, control-cli / control-ui, browser traces, local HTTP/RPC diffs, timings, heap snapshots.
Verdict rules:
VERIFIED — predicted change met threshold, no obvious confoundNOT VERIFIED — unchanged, wrong direction, or below thresholdINCONCLUSIVE — invalid baseline, noisy signal, or environment mismatch
Claim output shape:
VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>
Evidence: <metric>: baseline=..., treatment=..., delta=..., threshold=...
Reasoning: <one paragraph>
Step 3: Fix (if failed)
Read error output, fix the specific issue, do not change unrelated code, return to Step 2.
Step 4: Continue (if passed)
Commit, move to the next change, repeat.
Verification Levels
| Level |
Scope |
When |
| Unit |
Affected function/module |
After every small change |
| Integration |
Affected feature |
After feature complete |
| Full |
All tests |
Before commit/PR |
| E2E |
Critical user flows |
Before release |
Commands
# TypeScript/JavaScript
bun test && bun run build && bun run lint && bun run typecheck
# Python
pytest && ruff check . && mypy .
# Go
go test ./... && go vet ./... && golangci-lint run
# Rust
cargo test && cargo clippy && cargo build
Anti-Rationalization
| Excuse |
Counter |
| "I'll test everything at the end" |
Errors compound. Verify early, verify often. |
| "The tests take too long" |
Run affected tests first; full suite before commit. |
| "This change is too small to test" |
Small changes can have large effects. |
| "It works on my machine" |
Local verification is the minimum; CI validates the target environment. |
| "It probably works" |
Without a falsifiable claim and comparison, you do not know. |
1---2name: verification-loop3description: Continuous verification after each change, plus claim-based proof when evidence is required. Use when implementing, fixing bugs, or refactoring.4metadata:5 category: user-invoked6disable-model-invocation: true7---89Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.1011# Verification Loop1213## Overview1415Verify after each small change—not only at the end. Two modes share the same discipline:16171. **Routine verification** — run the right checks for the change type.182. **Claim-based verification** — prove or disprove a specific, measurable claim with baseline vs treatment evidence.1920## When to Use2122- After every code, dependency, or configuration change23- Before every commit or merge24- When the user asks to "verify this", "prove it works", or "show evidence"25- When tests pass but user-visible behavior still needs confirmation2627Do not use claim-based mode for vague assertions like "the code is cleaner". Ask for a falsifiable claim first.2829## The Loop3031```32Change → Verify → If fail: Fix → Verify → If pass: Continue33```3435### Step 1: Change3637Make a small, atomic change (~100 lines max).3839### Step 2: Verify4041Pick the mode that fits:4243| Situation | Mode | Action |44|-----------|------|--------|45| Normal development | Routine | Run checks from the table below |46| Specific claim to prove/disprove | Claim-based | Follow the claim workflow below |4748**Routine checks by change type:**4950| Change Type | Verification |51|------------|-------------|52| Code change | Tests for affected area |53| New feature | New tests + existing tests |54| Bug fix | Regression test + existing tests |55| Refactor | All tests (behavior must not change) |56| Dependency | Build + tests + security scan |57| Configuration | Build + smoke test |5859**Claim-based workflow:**60611. Restate the claim: condition, metric, threshold.622. Pick the smallest surface that can disprove it.633. Capture baseline (merge base, parent commit, or broken repro).644. Capture treatment with the same command, data, warmup, and environment.655. Compare artifacts: numbers, screenshots, transcripts, HTTP responses, profiles, heap snapshots, test output.666. Return exactly one verdict: `VERIFIED`, `NOT VERIFIED`, or `INCONCLUSIVE`.6768**Surfaces for claims:** unit/integration tests, `control-cli` / `control-ui`, browser traces, local HTTP/RPC diffs, timings, heap snapshots.6970**Verdict rules:**7172- `VERIFIED` — predicted change met threshold, no obvious confound73- `NOT VERIFIED` — unchanged, wrong direction, or below threshold74- `INCONCLUSIVE` — invalid baseline, noisy signal, or environment mismatch7576Claim output shape:7778```text79VERIFIED | NOT VERIFIED | INCONCLUSIVE80Claim: <falsifiable claim>81Evidence: <metric>: baseline=..., treatment=..., delta=..., threshold=...82Reasoning: <one paragraph>83```8485### Step 3: Fix (if failed)8687Read error output, fix the specific issue, do not change unrelated code, return to Step 2.8889### Step 4: Continue (if passed)9091Commit, move to the next change, repeat.9293## Verification Levels9495| Level | Scope | When |96|-------|-------|------|97| Unit | Affected function/module | After every small change |98| Integration | Affected feature | After feature complete |99| Full | All tests | Before commit/PR |100| E2E | Critical user flows | Before release |101102## Commands103104```bash105# TypeScript/JavaScript106bun test && bun run build && bun run lint && bun run typecheck107108# Python109pytest && ruff check . && mypy .110111# Go112go test ./... && go vet ./... && golangci-lint run113114# Rust115cargo test && cargo clippy && cargo build116```117118## Anti-Rationalization119120| Excuse | Counter |121|--------|---------|122| "I'll test everything at the end" | Errors compound. Verify early, verify often. |123| "The tests take too long" | Run affected tests first; full suite before commit. |124| "This change is too small to test" | Small changes can have large effects. |125| "It works on my machine" | Local verification is the minimum; CI validates the target environment. |126| "It probably works" | Without a falsifiable claim and comparison, you do not know. |
v1truv1us