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.4---56Default 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.78# Verification Loop910## Overview1112Verify after each small change—not only at the end. Two modes share the same discipline:13141. **Routine verification** — run the right checks for the change type.152. **Claim-based verification** — prove or disprove a specific, measurable claim with baseline vs treatment evidence.1617## When to Use1819- After every code, dependency, or configuration change20- Before every commit or merge21- When the user asks to "verify this", "prove it works", or "show evidence"22- When tests pass but user-visible behavior still needs confirmation2324Do not use claim-based mode for vague assertions like "the code is cleaner". Ask for a falsifiable claim first.2526## The Loop2728```29Change → Verify → If fail: Fix → Verify → If pass: Continue30```3132### Step 1: Change3334Make a small, atomic change (~100 lines max).3536### Step 2: Verify3738Pick the mode that fits:3940| Situation | Mode | Action |41|-----------|------|--------|42| Normal development | Routine | Run checks from the table below |43| Specific claim to prove/disprove | Claim-based | Follow the claim workflow below |4445**Routine checks by change type:**4647| Change Type | Verification |48|------------|-------------|49| Code change | Tests for affected area |50| New feature | New tests + existing tests |51| Bug fix | Regression test + existing tests |52| Refactor | All tests (behavior must not change) |53| Dependency | Build + tests + security scan |54| Configuration | Build + smoke test |5556**Claim-based workflow:**57581. Restate the claim: condition, metric, threshold.592. Pick the smallest surface that can disprove it.603. Capture baseline (merge base, parent commit, or broken repro).614. Capture treatment with the same command, data, warmup, and environment.625. Compare artifacts: numbers, screenshots, transcripts, HTTP responses, profiles, heap snapshots, test output.636. Return exactly one verdict: `VERIFIED`, `NOT VERIFIED`, or `INCONCLUSIVE`.6465**Surfaces for claims:** unit/integration tests, `control-cli` / `control-ui`, browser traces, local HTTP/RPC diffs, timings, heap snapshots.6667**Verdict rules:**6869- `VERIFIED` — predicted change met threshold, no obvious confound70- `NOT VERIFIED` — unchanged, wrong direction, or below threshold71- `INCONCLUSIVE` — invalid baseline, noisy signal, or environment mismatch7273Claim output shape:7475```text76VERIFIED | NOT VERIFIED | INCONCLUSIVE77Claim: <falsifiable claim>78Evidence: <metric>: baseline=..., treatment=..., delta=..., threshold=...79Reasoning: <one paragraph>80```8182### Step 3: Fix (if failed)8384Read error output, fix the specific issue, do not change unrelated code, return to Step 2.8586### Step 4: Continue (if passed)8788Commit, move to the next change, repeat.8990## Verification Levels9192| Level | Scope | When |93|-------|-------|------|94| Unit | Affected function/module | After every small change |95| Integration | Affected feature | After feature complete |96| Full | All tests | Before commit/PR |97| E2E | Critical user flows | Before release |9899## Commands100101```bash102# TypeScript/JavaScript103bun test && bun run build && bun run lint && bun run typecheck104105# Python106pytest && ruff check . && mypy .107108# Go109go test ./... && go vet ./... && golangci-lint run110111# Rust112cargo test && cargo clippy && cargo build113```114115## Anti-Rationalization116117| Excuse | Counter |118|--------|---------|119| "I'll test everything at the end" | Errors compound. Verify early, verify often. |120| "The tests take too long" | Run affected tests first; full suite before commit. |121| "This change is too small to test" | Small changes can have large effects. |122| "It works on my machine" | Local verification is the minimum; CI validates the target environment. |123| "It probably works" | Without a falsifiable claim and comparison, you do not know. |
v1truv1us