Serial fold-back: rebase the task branch onto the current run tip, then
CAS the run branch to the rebased head. Mechanical while file-contact
surfaces are disjoint (the Architect guarantees this); a genuine content
conflict is a plan defect and escalates. Call under the engine's per-run
write lock.
Three things happen around the rebase that the fold's record depends on.
First, the surface harvest (#184). The worktree is force-removed in the
finally below, so anything the implementer left uncommitted dies there —
tracked or not. Whatever falls inside the task's declared file-contact
surface is the task's product by definition, so it is committed onto the
task branch under the bot identity before anything else runs, exactly as
Engine.harvest (#182) rescues a non-isolated dispatch from the same
teardown.
Second, what the harvest did not take is cleared (#224). An implementer that
runs the suite in a fresh worktree must npm install to do it, which
rewrites the lockfile — a file in no task's contact surface, so an obedient
implementer leaves it uncommitted and its own work becomes unfoldable. Those
tracked paths are discarded so the rebase can start, and every one is named
in the result. Untracked paths outside the surface do not block a rebase and
are not harvested, but the worktree removal drops them too, so they are named
as well: nothing is destroyed without being said out loud.
Third, the task branch survives a failed fold (#225), matching the position
foldHarvestBranch has held since review-04.md round-2 F9.
Call under the engine's per-run write lock — the harvest commit runs under
that lock too.
Serial fold-back: rebase the task branch onto the current run tip, then CAS the run branch to the rebased head. Mechanical while file-contact surfaces are disjoint (the Architect guarantees this); a genuine content conflict is a plan defect and escalates. Call under the engine's per-run write lock.
Three things happen around the rebase that the fold's record depends on.
First, the surface harvest (#184). The worktree is force-removed in the
finallybelow, so anything the implementer left uncommitted dies there — tracked or not. Whatever falls inside the task's declared file-contact surface is the task's product by definition, so it is committed onto the task branch under the bot identity before anything else runs, exactly asEngine.harvest(#182) rescues a non-isolated dispatch from the same teardown.Second, what the harvest did not take is cleared (#224). An implementer that runs the suite in a fresh worktree must
npm installto do it, which rewrites the lockfile — a file in no task's contact surface, so an obedient implementer leaves it uncommitted and its own work becomes unfoldable. Those tracked paths are discarded so the rebase can start, and every one is named in the result. Untracked paths outside the surface do not block a rebase and are not harvested, but the worktree removal drops them too, so they are named as well: nothing is destroyed without being said out loud.Third, the task branch survives a failed fold (#225), matching the position
foldHarvestBranchhas held since review-04.md round-2 F9.Call under the engine's per-run write lock — the harvest commit runs under that lock too.