| Filename | Latest commit message | Latest commit date |
|---|---|---|
9d57a46079
Soul's second attack on the mutation harness found three ways a target stayed mutated. A multi-target entry wrote its targets outside the try, so a write that threw on the second target skipped the finally and left the first mutated. M0's write-through had no finally at all. And a hard kill mid-entry, which is what a tool timeout is, runs no finally, so the target stayed mutated with nothing recording what it had been. Every write now sits inside a try whose finally restores every target the step touched, M0's included, each proven by hash; a target that cannot be restored is printed with RESTORE FAILED and its original SHA-256 before the run throws. Before any target is written its original bytes go to a sidecar beside it, deleted only after a verified restore, and a run that finds a sidecar at startup restores from it, verifies, removes it and says a previous run died mid-mutation. Commands run through a Process with a -TimeoutSeconds limit (1800 by default) and are killed with their tree by the harness inside its own finally, so a hung cargo ends inside the entry's restore rather than under the operator's tool. Reproduced against a fake repo: A1 (M0 target write-locked) and A2 (the second of two targets locked, in both hashtable orders) leave every target byte-identical with no sidecar; A3 (tree killed mid-entry) leaves the mutant and the sidecar, and the rerun reports the repair and kills the entry; a 3-second timeout against a 12-second runner reports TIMED OUT (no verdict) and restores. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> |
||
| .. | ||
| eureka-cut5-mutations.psd1 | ||
| eureka-cut6-mutations.psd1 | ||
| eureka-cut6b-mutations.psd1 | ||
| eureka-mutations.ps1 | ||