Hadúr

Your first Round–Wave loop

The loop is the whole methodology in one sentence: Rounds find. Waves fix. Signals decide. A Round is diagnostic — parallel, independent reviewers, each with one question. A Wave is corrective — patches, in dependency order, each passing a verifier-gate before commit. The loop repeats until the seven signals say it is done (§4, §7.3).

Before anything: commit

A round is anchored to the identity of the code it reviewed — a digest over your git tree, taken outside the loop's own bookkeeping (§7.3.4). A dirty tree voids eligibility: a digest of a dirty tree describes the last commit, not what the reviewer read. So the first rule costs one line:

git status   # clean, or commit first

Round 1: dispatch reviewers

Pick your lenses from the lens registry — each lens is a question, not an area (§7.3.1). For a first round, dispatch at least the contract lens, the security lens, and the behaviour lens; a full cycle eventually needs every row, including the free sweep.

For each lens:

  1. Write a brief that names the lens and the question, and store it under .hadur/ — outside the reviewed surface, so writing it does not perturb the identity it attests to. The brief is pinned by content hash: an operator cannot rewrite the question after seeing the answer.
  2. Dispatch an independent reviewer — one reviewer identity per lens. One identity holding two lenses is one pass of attention claiming to be two questions, and both claims are rejected (§7.3.4).
  3. Record findings through the CLI. Never edit .hadur/findings/*.json by hand — evidence of a round is born from the tool, and a hand-written round file is exactly the forgery the evidence rules exist to catch.

Findings come back with severities: Critical, Major, Minor, Nit. A clean verdict is admissible only from a named lens with provenance; from the free sweep, a bare CLEAN is inadmissible — it must enumerate what it examined (§7.3.2).

Wave 1: fix in strict order

A Wave executes what Round 1 found (§4):

  1. Patches first, in dependency order — lowest-dependency modules first, so downstream patches reference stable signatures.
  2. Verifier-gate before every commit (§5): a mechanical pass that confirms the patch actually landed, then a runtime-semantics walkthrough for anything large or behavioural. A patch agent's "done" is a claim, not a fact.
  3. Criticals earn the Breaker (§5.8): an adversarial reviewer whose brief is to construct a bypass of the fix, not to check a box. A Critical fix that has not survived the Breaker is not closed.

One commit per patch. Never amend a committed wave; never skip hooks.

The part everyone resists

The wave changed the code, so every lens's clean streak is now void — including lenses that found nothing and lenses whose files the wave never touched. "The wave did not touch my files" is itself a claim, and it is exactly the claim a reachability defect falsifies. There is nothing to declare and nothing to forget: the reset happens because the tree digest changed, not because anyone wrote a wave record (§4, §7.3.4).

Plan for it: the last wave of a cycle is always followed by a full re-run of the registry, twice, all clean.

Check where you stand

hadur convergence   # the seven-signal verdict; non-zero while not met
hadur trends        # criticals/majors per round, per-lens streaks

Expect not met for a while. A first round that comes back heavy is the loop working, not failing — and if it comes back with many new systemic Criticals, that is divergence: stop patching per-plan and triage at the contract level instead (§7.4).

What not to do

  • Do not prune lenses to make convergence cheaper. On the record that produced this methodology, the lens dropped to save a dispatch is the lens that finds the Critical. Declare the cycle unconverged and say which lenses were not run.
  • Do not mark findings resolved to make a round look clean. The signals do not read your bookkeeping as truth (§7.3.4) — the mismatch will surface, at the worst time.
  • Do not review a dirty tree. Commit first. Always.