One harness repair after a verify failure — CYBERINE_HARNESS_REPAIR (k5dc7)

Off by default (operator decision D3-A). With CYBERINE_HARNESS_REPAIR=1, a code task that cyberine autopilot runs on its fleet engine with sync dispatch (the default; --dispatch sync or --verify) gets one repair attempt when its winner diff fails the task's verify: command or done-when check:

1. One improver call on the strong judge backend chain (routing.judges in fleet.json, else the default judge backends) reads the task, the verify failure, the worker's output and its diff, all fenced as untrusted text. It answers either "no repair" (a wrong implementation is not a harness defect) or a process failure (skipped step, tool misuse or missing context) with a span quoted from the worker's output and an overlay of brief.md and rules/<name>.md text.
2. The repair is refused unless the quoted span occurs verbatim in the worker's output and the overlay passes cyberine harness check (no guardrail, permission, secrets or owner-rule change).
3. Exactly one re-run follows on one worker of the task's pool, with the overlay rules and brief note added to the prompt; the overlay is never written into .cyberine/.
4. The re-run's diff lands only when the same verify check exits 0. Otherwise the original failure stands, and the task's failure line ends with harness repair: <outcome>: <why>.

CYBERINE_HARNESS_REPAIR=1 cyberine autopilot

Known Limitations and Deferred Work: the improver reads the winner's final output and error text, not its full tool transcript, so a process failure that left no trace in that text cannot be cited and is refused. The re-run worker is the first worker of the task's pool, not a separately chosen cheap worker. It costs one strong-model call plus one worker run per failed task, on top of the failed attempt; whether it beats an equal-budget plain retry is what kp1mv measures before anyone turns it on by default. Non-code tasks and the background (non-sync) dispatch path are not covered.