fix(trekexecute): park a re-planned step's earlier new files before the fresh build

The revert of a step sent back to the plan leaves its new files on disk, and --resume built the revised step on top of them: a stale tests/batch.sh holding the rejected line would have passed Verify, the manifest and the success criterion. lib/util/park-attempt-files.mjs moves every still-untracked file the attempt created (from step-N-upward.diff) into the report dir, never deleting it; /trekexecute runs it before the fresh build helper (voyage-lekerepo trial 5, finding 4).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-10-18 19:54:54 +02:00
commit 3238327483
Signed by: ktg
SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
4 changed files with 267 additions and 4 deletions

View file

@ -1522,8 +1522,18 @@ and the skill to work by: `skill: test-first` for a build round,
**A step at `fix_rounds` 5 is never built again** (Sub-step F): skip the
launch and run only the checks (B, D1, D2, D3, D4, E) on whatever the operator
changed. A step at `fix_rounds` 4 on `--resume` was re-planned: launch a fresh
`build` helper for the revised step.
changed. A step at `fix_rounds` 4 on `--resume` was re-planned: first park
the earlier attempt's new files, which the revert left on disk untracked, so a
stale file can never pass the revised step's checks (voyage-lekerepo trial 5,
finding 4):
```bash
node ${CLAUDE_PLUGIN_ROOT}/lib/util/park-attempt-files.mjs --diff {report dir}/step-{N}-upward.diff --to {report dir}/step-{N}-attempt-{attempts}
```
It moves every file the attempt created that is still untracked into that
directory under its own path: moved, never deleted. Name the `parked` paths
and every `kept` path with its reason in the step report; exit 2 is a stop
(the tree was not checked). Then launch a fresh `build` helper for the
revised step.
- **Never pass the Agent tool's `name` parameter.** A named spawn becomes an
`in_process_teammate`: it does the work, but its result never reaches this
@ -1862,7 +1872,9 @@ directly (Sub-step B), and so does a second `plan-unreadable` after one correcte
git rm --cached -q -- {the step's new files: registered with --intent-to-add since start_sha}
```
The new files stay on disk, untracked, and `step-{N}-upward.md` names them —
nothing the step made is deleted, and none of it is left registered.
nothing the step made is deleted, and none of it is left registered. A
`--resume` after re-planning parks them in the report dir before the fresh
build (Sub-step C).
When the guard refuses the restore (it is destructive git: in the permission
mode that shows no prompts the guard refuses it, exit 2, "no one to ask"), or
the operator declines it, nothing was restored: write in `step-{N}-upward.md`