verify

name	verify
description	Behavioral verification rules for claiming a change works. Use before reporting any fix/feature as done, when tempted to conclude from typecheck or unit-test results alone, when deciding what evidence a change needs, or when a test result looks suspicious (stale build, flaky pass, snapshot churn).
metadata	{"internal":true}

Verify Behavior, Not Proxies

A change is verified only when you have observed the real behavior change — the actual CLI output, reporter output, or exit code — not when a proxy signal went green. This skill owns exactly one concern: what counts as evidence. How to run things lives in the testing skill; what work a change requires (including the Flip-and-Verify regression protocol) lives in the development skill — don't expect commands or checklists here.

Forbidden proxies

None of these, alone, justify claiming a behavioral change works:

• Typecheck / lint green. Proves the types compose, not that the behavior changed.
• Unit tests green. They exercise source via the workspace runner, not the built CLI → runner → reporter pipeline users run.
• "My new test passes." A test that passes both before and after the fix proves nothing — it must flip (protocol: development → Flip-and-Verify).
• "The code path is clearly hit." Reading the code and reasoning that it must work is prediction, not observation.
• Snapshot updated with -u. Regeneration makes tests green by definition; green-after-update is not evidence (update policy: testing → Snapshot policy).
• Build succeeded. Compiling is not running.
• A tool accepted your config. Silently-ignored options look identical to working ones — prove the rule/option fires by observing it reject or change something (inject a violation, toggle the option).

If verification is genuinely impossible (needs real CI, a specific OS, a headed browser you can't run), say so explicitly instead of substituting a proxy.

The observation loop

1. Start from fresh build state. E2E and fixture runs consume built output; if a result contradicts your expectation, suspect a stale or half-finished build before suspecting the code (rebuild procedure: testing → Rebuild before E2E).
2. Drive the real binary on the smallest repro. Run the actual rstest CLI the way a user would — an e2e fixture, not an import of internal functions (run forms: testing → Running tests).
3. Observe the output, not the summary. Read the reporter output for the specific behavior you changed, and check the exit code (echo $?) when the change affects pass/fail semantics.
4. Observe both directions when feasible. See the broken behavior without your change and the fixed behavior with it — a fix you never saw fail is unverified.

What to observe, by change shape

Change touches	Minimum real observation
Core runtime / runner / pool	A targeted e2e run plus its exit code, on a fixture that exercises the changed behavior
Reporter / console output	The actual stdout/stderr the CLI prints, not just assertion results
CLI flags / config options	Two runs — with and without the option — confirming the behavior differs
Browser mode	A browser e2e run (headless is the default; see testing → Browser E2E)
Adapters (rsbuild / rslib / rspack)	A fixture run through the adapter, confirming the transformed config takes effect at runtime
Coverage providers	The emitted report content, not just "the run succeeded"
Watch mode	An actual watch session reacting to a file change, not a one-shot run
Lint rules / hooks / gates	The gate firing on an injected violation with the intended message, then passing when clean

False-signal gotchas

• A pass on re-run after a fail may be flakiness, not a fix. Re-run the exact failing command; if results alternate with no code change, report it as flaky rather than fixed.
• Inexplicable fixture behavior is usually stale state, not logic — stale dist, persistent fixture output, shared cwd (mechanisms and cleanup: testing).
• Absence of a failure is weak evidence. "It didn't error" only counts if you confirmed the run actually reached the changed code path.