HOW I WORK

Large codebases arrive with a red baseline: hundreds of pre-existing type errors, a dozen failing suites, a linter that crashes on config load before it reads a file. The two easy responses are to report green anyway or to block every change forever.

I do neither. I run each gate on my branch and on the base branch in the same checkout — usually by checking the base into a throwaway worktree — and report the diff of the sorted error lists. Frequently it's byte-identical, and that is a real result: this change regressed nothing. It's also not the same claim as "the gates pass," so I write it as the first thing and not the second.

The same discipline applies to an agent's report of its own work. A plan I ran recently claimed two decisions had been "confirmed with the user." They hadn't — both contradicted the repo's own rules file. A verification pass reported a bug as pre-existing when it came from a stale module graph in the same session. Neither is dishonesty; both are what unverified self-reporting looks like. So I ask for the A/B: the run without the fix and the run with it, side by side. A report that only shows the fixed state isn't a measurement.

If a thing can't be tested, that's a fact about its shape, not about testing. An inline Date.now() becomes a parameter. A mapper buried in a hook that imports the whole wallet stack at module scope moves out to where a test runner can reach it. Retry glue tangled into a component becomes a plain function.

Refactoring for testability before covering it is slower on the day and it's the only version that produces a test worth keeping.

Every pull request I open ends with a section listing bugs I found outside its scope and deliberately left alone: an inert privacy gate, a mislabeled market on an adjacent route, a handler with the same defect I was fixing elsewhere, a call using the wrong major version of a library.

Silently fixing them makes the change unreviewable. Silently ignoring them loses the finding. Writing them down costs a paragraph and gives whoever picks the file up next a map. The same applies to the brief itself: when a spec turns out to be wrong, it gets amended before the next change is built against it.