Date: 2026-09-13. Hypotheses recorded before implementation. Evidence: C.
Observation and baseline
User: “lets go ahead with these principles and improve the harness by applying them correctly.” The repair loop verifies proposed edits but forgets successful repairs between runs. Repeating the same failed source requires another inference. RL-020 used reduced response budgets, different prompts per model, and cumulative reasoning snapshots; its results do not support a general model-ranking or speedup claim.
Hypotheses
An identical source, goal and observed check contract can reuse a previously accepted repair without inference. Reuse must still pass fresh checks and must never overwrite a concurrent edit. Different source, goal or observations must miss. Rejected repairs must be evicted. Storage must be bounded and conversation scoped. No hidden reasoning or transcript is needed.
Method
Use synthetic verifier transitions with scripted model replies. Measure model calls and verify calls on first application and repeated application, then test changed context and a formerly successful repair that now regresses. This is harness evidence, not model quality or real-browser performance evidence.
Results
39 targeted tests pass; full suite 713/713 passes; typecheck and build pass. First application: one model call, two verifier calls. Identical repeat: zero model calls, two verifier calls. Synthetic regression and concurrent-edit cases preserve the original/current user source and evict stale experience.
Electron fixture passes: holds the original preview during generation, renders
an accepted repair, restores original on an unfinished run, refreshes final
HTML, and closes the preview when the conversation changes. The first fixture
run used the wrong IPC channel and failed; corrected from agent:code to the
actual code:stream, then passed. No production protocol was changed for it.
Intervention and boundaries
Eight successful repair proposals maximum per in-memory conversation, keyed by SHA-256 of the complete source, original goal, current request and complete verifier observations. Only repairs that improve a failing check without regressions are remembered. Replay uses the ordinary exact-edit and fresh-verification path; failures evict the entry. Reset/restart does not persist this experience to a training dataset. Repair origin is included in the existing local journal. No hidden reasoning, cross-project retrieval, new model training or automatic model switching occurs.
The desktop keeps an open preview synchronized with accepted repair snapshots and the final retained draft. Preview visibility remains the user's choice. Check coverage is limited to the existing browser verifier. Successful replay is not proof that every requested feature is correct.
Evidence and assumptions
See evidence/RL-021/results.json. A repeated exact state saves an inference:
supported in fixture. Frequency in real usage and wall-clock improvement:
untested. Dyna's robotics results transfer to software-agent training: hypothesis
only; this change implements a bounded use of observed outcomes, not that claim.
RL-020 does not establish a causal latency benefit or a fair model ranking.
Public claims H3/H4/H5 remain consistent; no new model-quality claim is made.
Reproduce
node --import tsx --test tests/repairExperience.test.ts tests/codeRepair.test.ts tests/verifiedWebsite.test.ts
npm test; npm run typecheck; npm run build;
npx electron scripts/check-repair-preview.mjs.