The fix that finally let the coding harness produce a clean, applying patch worked on the very first real attempt. And the very first real attempt still reported failure.
The actual problem: a check that was never checking the right thing
The loop’s test stage called run_tests to see whether the patch fixed the bug. It had always called it against the real, unpatched working tree. apply_result.get("test_results"), the field meant to carry whether the patched code passed, had been an empty vestige since the very first version of the loop. A perfect patch and a broken one would report exactly the same test result, because the test command was never running against the patch at all.
This had been true through every earlier session. It just never mattered, because no patch had ever survived the dry-run guard long enough to reach the test stage. The bug was unreachable, and an unreachable bug that never fires might as well not exist, right up until something upstream stops failing first.
What got weird: fixing the loud bug promoted the quiet one
The structural diff-authoring fix from the previous post converged on its first real attempt. And that attempt reported a failed test, on a patch that, read by hand, looked correct. The pattern was immediately recognizable to anyone who’s chased a bug behind a bug before: the loud failure (malformed diffs, never applying) had been silently protecting a quiet failure (a test check that measured nothing meaningful) from ever being exercised. Fix the loud one, and the quiet one is the very next thing you hit.
This isn’t a coincidence worth being surprised by twice. Any pipeline stage that’s gated behind an earlier stage that always fails first is, by construction, untested in the one condition that matters: success. The first real success is also the first real test of everything downstream of it.
What worked: run the test where the patch actually lives
The fix was a new tool, run_tests_with_patch, built specifically so the real workspace is never at risk while testing an unverified patch. It copies the workspace’s tracked and untracked-not-ignored files (via git ls-files -co --exclude-standard, so genuinely untracked scratch files aren’t silently dropped) into a disposable temporary directory, applies the patch inside that copy, and runs the configured test command there, with the sandbox’s Python path and interpreter resolved carefully against the real workspace, so an editable install can’t quietly re-test the original source instead of the patched copy. The temp directory is always cleaned up afterward, success or failure. The real tree is never mutated by a test run, only by a human-approved apply.
What next
With both the diff-authoring bug and the test-oracle bug fixed the same day, the loop was re-verified against real Ollama on three fresh fixtures, each harder than anything tried before: three for three, converging in one, two, and one iterations, with the second fixture producing the first observed end-to-end self-correction cycle, an imperfect first patch, a real test failure fed back correctly for the first time ever, and a converging second attempt. The loop was, for the first time, actually testing what it claimed to be testing.
What Next
A Review Panel on One Model Is One Reviewer in Four Hats
Next in the Local Coding Harness arc: with the fix loop finally converging, the harness turns to a harder question, can four review personas on one resident model actually catch what a real reviewer would catch?