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.

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.