The Rescue proof: the AI died mid-build. A weaker one finished it — from a file.
The setup
Real projects die this way every day: you're halfway through a build when the AI you're paying for hits its limit, and the project sits there, half-finished, in a shape only that session understood.
So we staged it honestly. A stronger model (deepseek-v4-pro) built a small day-planner tool — dates module, events module, command-line module, exact output formats throughout — one file per call, like one working session. After the second file, we stopped the session. No third file was ever requested. What remained was a stranded project: two working modules and a missing third.
The operator then wrote the project's continuation pack — spec.md and state.md, in the /continue format — from the artifact exactly as it lay: what the rules are, what is finished and verified, what the single next action is. Nobody briefed the finisher in person.
The test — protocol frozen before any run
A different, weaker model (deepseek-flash — the cheap one) got three attempts in each of two arms. Same stranded files both times. Same deterministic checker grading everything cold: date rules, event validation, conflict detection (including the edge where two events merely touch and must NOT count as a conflict), and the command line end-to-end with exact output strings.
| Arm | What the finisher received | Result |
|---|---|---|
| Pack arm | The continuation pack (spec.md + state.md) + the two stranded files | 3/3 PASS — every check, every attempt |
| Control arm | The same two files + "Finish this project." Nothing else. | 0/3 PASS |
What the control arm actually did
It didn't fall apart. All three control attempts left the existing files untouched, and all three wrote plausible, coherent code — an argparse-based main.py with its own command grammar. Every one of them invented a reasonable project. None of them invented this project: the file name, the commands, the exact printed lines, the exit code for a bad command live nowhere in two orphaned modules. They live in the pack.
That's the whole finding in one sentence: the files tell a new AI what exists; the pack tells it what "finished" means.
Disclosures
- The stranded artifact was verified before the pack was written (the
two finished modules pass their frozen unit checks), and state.md says so on its face — a real pack carries its verification, or says it isn't there.
- The pack was written by a human operator following the site's own
/continue templates — that is the product being tested, used the way a user uses it.
- The task is deliberately spec-shaped: a small tool with exact
contracts. This result does not claim rescue works on an arbitrary undocumented codebase; it claims that when the spec is frozen and the state is written down, a stranded build is finishable by a weaker stranger — 3 of 3, against 0 of 3 without the pack.
Evidence — re-grade it yourself
| File | What it is |
|---|---|
| B-rescue/PREREG.md | Frozen protocol + pre-registered metric, written before any run |
| B-rescue/SPEC.md | The frozen project spec |
| B-rescue/check.py | The deterministic checker (all three arms) |
| B-rescue/run_b.py | The runner — starter, pack arm, control arm |
| B-rescue/halted/ | The stranded artifact, verbatim, with its verification |
| B-rescue/pack/ | The continuation pack as written (spec.md, state.md) |
| B-rescue/attempts/ | Every finisher attempt: raw output, written files, verdict |
| B-rescue/RESULTS.md | The results write-up, spend included |
| AMENDMENT.md | The transport incident that preceded the runs |