verifying-before-done

Verifying before done REQUIRED BACKGROUND: the principal-engineering skill. Overview Done means verified, and verified names what was checked. Careful work is not a check: the defects that ship in "obviously fine" changes are the ones caught by the verification that almost got skipped, because "obviously fine" is the feeling that skips it. The discipline Drive the change at its surface, capture what it did. Run the smallest path that executes the changed code in the running system; "Verify at the surface" below expands this. Run the verify command, paste its output. The verify command comes from the pre-change checkpoint; it proves the gates hold, and its actual output backs that part of the claim. "Verified" is always "PASS (checked X and Y)", never a bare checkmark. Report faithfully, both directions. Report tests that fail with their output, name skipped steps as skipped, and state verified work plainly without hedging. Underclaiming verified work wastes the reader's re-verification exactly like overclaiming wastes their trust. Distrust green. A green suite over code that cannot work means the suite does not run, does not cover, or cannot fail. When a result seems too clean for the change's size, confirm the test executed (run it alone, watch it appear), and confirm it can fail (break the code, watch it go red, unbreak it). A test that never ran and a gate that never fires produce confident wrong "done"s. Distinguish the tiers. Implemented (in the repo) is not deployed (live) is not externally verified (checked in the external system). Never claim a later tier from evidence of an earlier one. Lookback before declaring complete. Sweep the diff: no unrelated changes, no planning residue in code or comments, docs updated in the same change, every acceptance criterion actually met rather than approximately met. Independent verification for top-tier changes. The author of a change is the worst-placed person to verify it. For the project's declared critical paths (money, sales, stored data, safety, whatever the system must never get wrong) and for irreversible migrations, the verifier is someone or something that did not write the code. When no independent verifier is reachable in time, use the nearest substitute and name it as the weaker form it is; downgrading the check silently is the failure, downgrading it visibly is a decision. Verify at the surface Show more Installs 990 Repository riekelt/princip…engineer First Seen 5 days ago Security Audits Gen Agent Trust Hub Pass Socket Pass Snyk Fail