b3os-verification

b3rys Verification — Prove It, and Keep It Proven

Where this sits among the team skills:

Skill	Question it answers
b3os-ai-code-safety	How do we build it? (structure, refactoring)
b3os-sf	How do we manage and report it?
b3os-harness-playbook	How do we split it across parallel agents?
b3os-verification	How do we prove the result is right — now and on every later change?

The core idea: a check you set up once must keep protecting you. A new feature or a bug fix ends with one row in the feature table + a test + a deliberately broken version that the test catches. The runner does the rest, every time.

Passing the runner is evidence for review and approval (TEAM-OS §4), not a substitute for them.

Scope: §1–5 apply to every change. §6–7 (one app window, the app runner) apply to products with a running app; for server or script work, skip them.

---

1. Three principles

1. Run it; don't read it. A diagnosis from reading source is a candidate. It is not a conclusion until a repro or a measurement confirms it.
2. The feature ↔ verification table is the single source. One feature = one row. Each row has: source files (for change-scoped runs) · headless tests · app check (family + steps) · performance gate with baseline · the mutant and whether it is proven caught · last result (date, sha, verdict) · gaps · access (UI path, shortcut, probe anchor ids — so any agent can map a vague report or a screenshot to a feature and drive it).
3. Budget first. One fix = 10 minutes; tests and verification included = 30 minutes. If a check would blow the budget, say so early and change the method (split, parallelize, move it headless). Do not drop the spec to fit the time.

2. Five ratchets — verification that only gets stronger

Each moves in one direction only.

Ratchet	Rule
① One bug = one test	A bug fix ships with a repro test and a mutant (the fix reverted) on which that test fails. The same bug cannot come back silently.
② Twice = a check	A review comment or feedback that repeats twice becomes an executable check (test, lint, CI rule, script guard) — not a line in a doc. Same rule as ai-code-safety's enforcement layers (a comment made twice moves one layer up).
③ Baselines only tighten	Improve → re-pin. Regress → block. Never loosen silently. A baseline change records the value and the condition (load, build type).
④ Wrong checks accumulate	Every check that was itself wrong becomes a triage rule (symptom → cause → action) or a known-flaky entry, so the runner classifies it next time.
⑤ Gap count only goes down	Per build, count rows without an app check, without mutant proof, and UNPROVEN (a mutant that passed). The count must not rise; the runner fails the run if it does.