Verification Loop
Overview
Continuous verification ensures every change is validated immediately. Instead of building everything then testing, verify after each small change. This catches errors early and prevents compounding mistakes.
When to Use
- After every code change (edit, write, patch)
- After every dependency addition or update
- After configuration changes
- Before committing any change
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
Run the appropriate verification:
| 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 |
Step 3: Fix (if failed)
- Read the error output carefully
- Fix the specific issue
- Do NOT change unrelated code
- Return to Step 2
Step 4: Continue (if passed)
- Commit the change
- Move to next change
- Repeat the loop
Verification Commands
# TypeScript/JavaScript
bun test # Run tests
bun run build # Build project
bun run lint # Run linter
bun run typecheck # Type check
# Python
pytest # Run tests
ruff check . # Lint
mypy . # Type check
# Go
go test ./... # Run tests
go vet ./... # Vet code
golangci-lint run # Lint
# Rust
cargo test # Run tests
cargo clippy # Lint
cargo build # Build
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 |
Anti-Rationalization Table
| Excuse |
Counter |
| "I'll test everything at the end" |
Errors compound. A bug in step 1 makes steps 2-10 wrong. Verify early, verify often. |
| "The tests take too long" |
Run only affected tests for quick feedback. Full suite before commit. |
| "This change is too small to need testing" |
Small changes can have large effects. Every change deserves verification. |
| "It works on my machine" |
Local verification is the minimum. CI verifies in the target environment. |
Imported from cursor-team-kit/verify-this (MIT, cursor/plugins)
Verify This
Verification is not a recap. It proves or disproves a specific claim with repeatable evidence.
When To Use
- The user asks "verify this", "prove it works", "did this fix it", or "show me the evidence".
- A bug fix needs a before/after repro.
- A UI, CLI, API, performance, or memory claim needs measurement.
- A test passes but the user-visible behavior still needs confirmation.
Do not use this for vague claims like "the code is cleaner". Ask for a measurable claim first.
Workflow
- Restate the claim in falsifiable form: condition, metric, and threshold.
- Pick the smallest local surface that can disprove it.
- Capture a baseline from the old state: merge base, parent commit, failing branch, or current broken repro.
- Capture treatment from the changed state with the same command, data, warmup, and environment.
- Compare raw artifacts: numbers, screenshots, terminal transcripts, HTTP responses, profiles, heap snapshots, or test output.
- Return exactly one verdict:
VERIFIED, NOT VERIFIED, or INCONCLUSIVE.
Local Surfaces
- Code behavior: focused unit/integration tests or a minimal repro script.
- CLI/TUI behavior:
control-cli, terminal transcript, or demo recording.
- UI behavior:
control-ui, screenshots, accessibility snapshots, or browser traces.
- API behavior: local HTTP/RPC request and response diff.
- Performance: same-machine baseline/treatment timings or CPU profiles.
- Memory: heap snapshots before and after the suspected operation.
Artifact Layout
When safe to write artifacts:
/tmp/verify-this/<claim-slug>/
├── claim.md
├── timeline.md
├── baseline/
├── treatment/
├── diff/
└── verdict.md
If artifacts may contain sensitive code, prompts, screenshots, HTTP bodies, or heap data, keep only the minimal inline evidence unless the user agrees to disk storage.
Verdict Rules
VERIFIED: baseline and treatment differ in the predicted direction, by the claimed threshold, with no obvious confound.NOT VERIFIED: the behavior is unchanged, moves the wrong way, or misses the threshold.INCONCLUSIVE: no valid baseline, noisy signal, failed measurement, or an environment difference invalidates the comparison.
Output
Use this shape:
VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>
Evidence:
<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>
Reasoning:
<one tight paragraph naming the evidence and any confounds>
Do not soften a negative result. A clear NOT VERIFIED is useful.
1---2name: verification-loop-23description: Continuous verification methodology. Verify after every change, not just at the end. Run tests, check builds, validate behavior. Use when implementing features, fixing bugs, or refactoring.4---56# Verification Loop78## Overview910Continuous verification ensures every change is validated immediately. Instead of building everything then testing, verify after each small change. This catches errors early and prevents compounding mistakes.1112## When to Use1314- After every code change (edit, write, patch)15- After every dependency addition or update16- After configuration changes17- Before committing any change1819## The Loop2021```22Change → Verify → If fail: Fix → Verify → If pass: Continue23```2425### Step 1: Change26Make a small, atomic change (~100 lines max).2728### Step 2: Verify29Run the appropriate verification:3031| Change Type | Verification |32|------------|-------------|33| Code change | Tests for affected area |34| New feature | New tests + existing tests |35| Bug fix | Regression test + existing tests |36| Refactor | All tests (behavior must not change) |37| Dependency | Build + tests + security scan |38| Configuration | Build + smoke test |3940### Step 3: Fix (if failed)41- Read the error output carefully42- Fix the specific issue43- Do NOT change unrelated code44- Return to Step 24546### Step 4: Continue (if passed)47- Commit the change48- Move to next change49- Repeat the loop5051## Verification Commands5253```bash54# TypeScript/JavaScript55bun test # Run tests56bun run build # Build project57bun run lint # Run linter58bun run typecheck # Type check5960# Python61pytest # Run tests62ruff check . # Lint63mypy . # Type check6465# Go66go test ./... # Run tests67go vet ./... # Vet code68golangci-lint run # Lint6970# Rust71cargo test # Run tests72cargo clippy # Lint73cargo build # Build74```7576## Verification Levels7778| Level | Scope | When |79|-------|-------|------|80| Unit | Affected function/module | After every small change |81| Integration | Affected feature | After feature complete |82| Full | All tests | Before commit/PR |83| E2E | Critical user flows | Before release |8485## Anti-Rationalization Table8687| Excuse | Counter |88|--------|---------|89| "I'll test everything at the end" | Errors compound. A bug in step 1 makes steps 2-10 wrong. Verify early, verify often. |90| "The tests take too long" | Run only affected tests for quick feedback. Full suite before commit. |91| "This change is too small to need testing" | Small changes can have large effects. Every change deserves verification. |92| "It works on my machine" | Local verification is the minimum. CI verifies in the target environment. |9394## Imported from cursor-team-kit/verify-this (MIT, cursor/plugins)9596# Verify This9798Verification is not a recap. It proves or disproves a specific claim with repeatable evidence.99100## When To Use101102- The user asks "verify this", "prove it works", "did this fix it", or "show me the evidence".103- A bug fix needs a before/after repro.104- A UI, CLI, API, performance, or memory claim needs measurement.105- A test passes but the user-visible behavior still needs confirmation.106107Do not use this for vague claims like "the code is cleaner". Ask for a measurable claim first.108109## Workflow1101111. Restate the claim in falsifiable form: condition, metric, and threshold.1122. Pick the smallest local surface that can disprove it.1133. Capture a baseline from the old state: merge base, parent commit, failing branch, or current broken repro.1144. Capture treatment from the changed state with the same command, data, warmup, and environment.1155. Compare raw artifacts: numbers, screenshots, terminal transcripts, HTTP responses, profiles, heap snapshots, or test output.1166. Return exactly one verdict: `VERIFIED`, `NOT VERIFIED`, or `INCONCLUSIVE`.117118## Local Surfaces119120- Code behavior: focused unit/integration tests or a minimal repro script.121- CLI/TUI behavior: `control-cli`, terminal transcript, or demo recording.122- UI behavior: `control-ui`, screenshots, accessibility snapshots, or browser traces.123- API behavior: local HTTP/RPC request and response diff.124- Performance: same-machine baseline/treatment timings or CPU profiles.125- Memory: heap snapshots before and after the suspected operation.126127## Artifact Layout128129When safe to write artifacts:130131```text132/tmp/verify-this/<claim-slug>/133├── claim.md134├── timeline.md135├── baseline/136├── treatment/137├── diff/138└── verdict.md139```140141If artifacts may contain sensitive code, prompts, screenshots, HTTP bodies, or heap data, keep only the minimal inline evidence unless the user agrees to disk storage.142143## Verdict Rules144145- `VERIFIED`: baseline and treatment differ in the predicted direction, by the claimed threshold, with no obvious confound.146- `NOT VERIFIED`: the behavior is unchanged, moves the wrong way, or misses the threshold.147- `INCONCLUSIVE`: no valid baseline, noisy signal, failed measurement, or an environment difference invalidates the comparison.148149## Output150151Use this shape:152153```text154VERIFIED | NOT VERIFIED | INCONCLUSIVE155Claim: <falsifiable claim>156157Evidence:158<metric/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>159160Reasoning:161<one tight paragraph naming the evidence and any confounds>162```163164Do not soften a negative result. A clear `NOT VERIFIED` is useful.
v1truv1us