Unexplained: a session worktree gained staged deletions of files it never touched nf-cb5 ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/705 by tools/beads/import_github.py's reconcile pass.

Unclaimed / unlabelled — inert backlog. Filed by nf-dev-argo so a second occurrence has something to attach to. I could not determine the cause, and I would rather record the evidence than guess at one.

What happened

/root/nf/devs/argo (a worktree of /root/nf/ninefold) was at 38268ab on a topic branch. git status showed ~20 staged deletions and modifications of files this session never touched:

``` D design_docs/004-one-owner-for-the-integration-build.md D design_docs/005-probe-selection-and-build-config.md D tools/nflib/godot_build.py D tools/nflib/sessions.py D tools/office/reap.py D tools/pr/wrap_up.py D tools/tests/test_doc_pointers.py … plus M on CLAUDE.md, notes/*, tools/pr/poll.py, probe_gate.py, rebuild_f5.py ```

Verified at the time:

• git cat-file -e HEAD:tools/nflib/sessions.py → HEAD has it;
• the files were genuinely absent from disk;
• so the index held staged deletions relative to a HEAD that contained them.

Every "deleted" path is one that arrived on main in a recently merged PR (#647's sessions.py/reap.py, wrap_up.py, design docs 004/005, test_doc_pointers.py).

Why it matters

The session's own work was interleaved with this. A git add -A && git commit would have committed ~20 unrelated deletions — reverting four other sessions' merged PRs — inside a PR about something else. It was caught only because the staged list was read before committing rather than after.

⚠️ The gate would not have caught it either way. presubmit.py --all passed on that tree, because deleting those files does not break the suites that remained.

What I ruled out

• Not my edits: this session touched 9 files, all accounted for.
• Not a rebase artifact: the branch was freshly cut from main.
• Recovered cleanly with git reset --hard origin/main + git clean -fd, then re-applying the session's own diff — so nothing was lost, and the tree has been correct since.

Candidate causes, none confirmed

• tools/pr/wrap_up.py --remove and tools/office/reap.py both run git -C <clone> worktree remove --force and landed on main the same day. reap.py:190 already warns that *"a worktree removed while its claude is still writing to it is the state this…"*. Neither obviously produces staged deletions in a surviving worktree, so this is proximity, not evidence.
• Concurrent git operations against the shared clone from ~5 live sessions.
• Something in this session's own tool runs (merge_pr.py's checkout/restore, rebuild_f5.py) leaving an index inconsistent with HEAD.

If it recurs

Capture before touching anything:

``` git status --short; git log --oneline -1; git rev-parse HEAD git cat-file -e HEAD:<one deleted path> && echo "HEAD has it" ls -la .git 2>/dev/null; cat .git # worktree pointer git -C /root/nf/ninefold worktree list ```

The distinguishing question is whether HEAD contains the deleted files (index/worktree desync, as here) or whether HEAD itself moved (a ref got rewritten under the worktree). Those are different failures.

Refs #647.