`--install` has no inter-process lock: the settings.json merge, the bin copies and the receipt all read/merge/replace unserialized

[brettheap]

openRepoTools --install has no inter-process lock anywhere: two simultaneous runs for one account race on every file it writes. The shape is the same read/merge/replace at three sites, and two of them predate PR #103:

• the SessionStart and UserPromptSubmit hook merge into ~/.claude/settings.json — read with jq, staged with mktemp, mv -f into place (plan_hook_merge / place_skill_and_hook, since Lane tooling moves home: filter-repo from brett-wip, openRepoTools wip init, --install installs the lane skill and hook (Amendment 9 act 3) #24/--install stamps the documented mode on every artifact and refuses a target it cannot write in the planning phase, and wip init stages the template paths it wrote rather than git add -A -- . #44/The name guard refuses a prompt whose window, session name and register row are not ONE lane — the lock types /rename <lane> into the pane, a person's rename is an OFFER answered at the next prompt, and a transcript two live processes hold is a refusal in the guard, in lane-start and in lane-end --retire #52);
• the bin-directory copies themselves (install_commands: cp then chmod, twelve files, no lock);
• the receipt installed.tsv (--install writes a receipt of what it placed, so a later retirement has ownership evidence stronger than a header substring #57 / PR --install writes a receipt of the files it placed, and a retirement reads that before it reads a header substring #103): read, rows for this run's names replaced, mktemp + mv -f; receipt_forget on retirement does the same.

Copilot named the third on PR #103 (thread #103 (comment)): two installs with different OPENREPOTOOLS_BIN_DIR values can both read the receipt and the last mv discards the other's rows. That is real and it is narrower than the file's own rule already makes it — the receipt is EVIDENCE with a fallback (the header marker still identifies an installer copy, and a row that is missing means "fallback", never "remove"), so a lost row costs a retirement its stronger evidence, not a file. A lock added to the receipt alone would leave the two older sites racing and would be the one lock in a command that otherwise has none, which is why PR #103 declined to add it there and files the whole shape here instead (take what a round introduced; file what predates it).

What this wants, if anything: ONE lock around the whole of --install (a mkdir lock beside the bin directory or under $XDG_RUNTIME_DIR, since flock is not on macOS — lanes-edit.sh already carries the portable idiom), taken before the plan and released on exit, with a case in tests/test_openrepotools_command.py that a held lock is waited on and then named rather than raced past. Or a ruling that two simultaneous installs for one account are not a supported use and the command says so. Not urgent: nothing on Eagle or Raven runs the installer twice at once; the container entrypoint (workBenches#99) runs it once per start under its own flock.

Filed by lane openRepoTools-1 from PR #103's review.

[brettheap]

Deferred under Brett Heap's close-out direction of 2026-10-06 (no new feature PRs until the existing openRepoTools PRs are landed for the triad migration). Lane openRepoTools-1 claimed this, a writer read the ground and chose the shape, and stopped before writing code; the claim is released and the notes below are the handover.

Shape chosen (not built). ONE mkdir-based lock (flock is not on macOS; lanes-edit.sh carries the idiom) around the whole install and the whole retirement, placed in the receipt's DATA directory (dirname "$(receipt_file)"), not beside the bin directory: two installs with different OPENREPOTOOLS_BIN_DIR still share the receipt and ~/.claude/settings.json, so a lock beside the bin directory would not serialize them. A data directory that cannot be written is a one-line note and an UNLOCKED install, never a refusal (#57's rule). Bounded wait, then a refusal (exit 2) naming the holder's pid file; a stale lock (holder gone) reclaimed with one line.

Open question for whoever builds it: the lane's brief said "take the lock after the plan", but plan_hook_merge READS settings.json during the plan, so the read/merge/replace of settings.json would not be serialized unless place_skill_and_hook re-reads it; if it does not, the lock belongs before plan_hook_merge (after the fetches), which is what this issue itself says ("taken before the plan"). Settle that first.

Branch prepared (no commits): fix/install-marker-on-every-file-and-one-install-lock off main 2080f3d, local only. Shared with #104.

[brettheap]

RELEASED — lane openRepoTools-1, session df82f553-7803-49c4-8ddf-3f9acdcb8ee0@Eagle, 2026-10-06T20:49:29Z, for #106 — deferred under Brett Heap's close-out direction of 2026-10-06; shape posted on the issue; no code; no PR