The proposal flow from phase 10 can write files and run tests. So the obvious question is: what happens when the tests fail? The tempting answer is “feed the failure back to the model and let it try again until it’s green.” That is also how you end up watching a 7B model flail at the same bug for twenty iterations while your laptop fan screams. Phase 13 of kodr takes the disciplined version: one repair, then stop.
The healing path
When a post-write verification run fails, kodr can:
- Notice the failure.
- Repack fresh context from the workspace (the files changed, so the old context is stale).
- Include
.kodr/last-test.md- the actual failure output from the verification runner - so the model can see what broke. - Ask for exactly one repair proposal.
- Apply it and rerun the tests once.
Then it stops. Pass or fail, that is the end of the automatic path. If the repair worked, great. If it did not, you get a hard stop and the artifacts to go look yourself.
Why one-shot
A single repair catches the cheap mistakes - a typo, a missed import, an off-by-one the model can spot when it sees the error message. Those are worth automating because they are boring and obvious.
An unbounded repair loop catches nothing extra and costs a lot. Worse, it hides problems: a loop that eventually stumbles into green has buried however many wrong turns it took to get there, and you have no signal that the model was actually confused. A hard stop after one attempt keeps the failure visible. If one focused repair with the test output in hand cannot fix it, that is information - the model is stuck, and a human should look.
The tests for the phase nail this down from both directions: a failing write gets repaired once and passes, and - just as important - there is never a second repair loop. The hard stop is the feature.
Healing is deliberately not autonomy. It is one polite “want to try that again?” and nothing more.
Links:
- Phase doc: phases/13-one-shot-healing.md
- Kodr post: blog/13-one-shot-healing.md
- The healer: src/healing.mjs