Check whether .worktreeinclude covers spawn_dev.py's worktrees too, before duplicating it as a bespoke mechanism nf-10a ← Beads

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

Prescription: a cheap verification, not a build. Filed by the CTO off research into claude --worktree/--tmux (2026-08-10) — evaluated as a possible replacement for tools/office/spawn_dev.py and rejected for that (wrong worktree location — nested inside the repo, exactly #372's hazard; no git-identity guardrail; fixed branch naming). One piece of what it does is worth checking on its own merits, cheaply, before deciding whether to act on it further.

What was found

The installed claude CLI (v2.1.227, traced from the binary — confidence: inferred from strings, not from official docs; confirm the exact convention before relying on it) supports a .worktreeinclude file: a newline list of paths, read when claude --worktree creates a new worktree, that copies matching *gitignored* files (git ls-files --others --ignored --exclude-standard) into it. That's exactly the job spawn_dev.py does today with one hardcoded line — cp NuGet.Config <worktree>/NuGet.Config — needed because the .NET build wants a gitignored file that a fresh git worktree add doesn't carry.

Why this isn't an automatic win — verify before building anything

spawn_dev.py creates worktrees with plain git worktree add, never by shelling out to claude --worktree (and shouldn't start to — that command's other behavior is exactly what got it rejected as a spawn_dev.py replacement). It's unconfirmed whether .worktreeinclude is honored for a worktree claude didn't itself create, or whether it's read only inside the --worktree code path specifically. If it's the latter, this file does nothing for spawn_dev.py's worktrees no matter what's in it, and there is nothing to build here.

What to do

1. Confirm the actual convention first — check Claude Code's own official docs/changelog (not just binary strings) for .worktreeinclude's real name, location (repo root? .claude/?), and syntax.
2. Test cheaply, against spawn_dev.py's real mechanism: drop the file in ~/nf/ninefold (or wherever it belongs per step 1) naming NuGet.Config, spawn a dev the normal way (spawn_dev.py <topic> --dry-run won't touch git — use a real throwaway spawn, or a manual git worktree add matching what spawn_dev.py does), and check whether NuGet.Config shows up in the new worktree without spawn_dev.py's own cp line running. Clean up the throwaway worktree after.
3. If it's honored: this is a genuinely free win — one static file, in place of a hardcoded cp in spawn_dev.py, and it also covers any *other* worktree-creation path in this repo's tooling (e.g. rebuild_f5.py's own worktrees, merge_pr.py's new -gate worktree, both of which currently carry their own separate NuGet.Config copy logic — check #810's _gate_worktree and rebuild_f5.py's ensure_worktree for the exact call sites, since removing the duplication is the actual value, not just deleting one cp line). Land it as one small PR, and only then delete the equivalent hardcoded copies.
4. If it's not honored outside claude --worktree, close this as informational — do not build a bespoke declarative-config-file system to replace one working cp line for a single current consumer (NuGet.Config). One hardcoded copy for one known need is correctly sized; a generalized mechanism for a list of one is premature (B4 — add complexity when demonstrated need, not anticipated).

Out of scope

Everything else the research turned up about claude --worktree (worktree location, branch naming, identity, --dry-run, cleanup model) — those were reasons to keep spawn_dev.py as-is, not follow-up work.