Per-agent git worktree / path-scoped add for coder-pluto + db-pluto on venus (end shared-checkout git-add-all race)

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-16
• wi-cli-venus blocked · 2026-06-16
  Infra change on venus host (nw/maintainer lane). Hold execution until (a) PLUTO-144 push lands off the shared tree and (b) Elazar acks the migration-workflow brainstorm decision (bs-mqgwqsix9s0, 'say the word before execute'). Root cause witnessed live: coder-pluto+db-pluto share one venus checkout; gitpush git add -A swept db's uncommitted migration 036 into coder's 143 commit attempt + caused a stub/full save-race. Fix: per-agent worktree or path-scoped add.
• wi-cli-venus commented · 4w ago
  Status-check 2026-07-15: PLUTO-144 confirmed done (v1.73.7). Condition (b) - Elazar ack of bs-mqgwqsix9s0 - never landed per nw-venus-cc (no bwi/memory trace). Escalated to pmmaster-evolutiva-cc for Elazar's actual go; still correctly blocked.
• wi-cli-venus note · 4w ago
  Decision (delegated by Elazar via pmmaster-evolutiva-cc to pm-venus-cc, 2026-07-15): per-agent git worktree for db-pluto-cc, separated from coder-pluto-cc's checkout. Path-scoped add rejected - db's uncommitted files (e.g. migration drafts) live in the SAME subtree coder-pluto-cc's own changes occupy, so --only path-scoping can't distinguish them without fragile per-file enumeration. Worktree structurally eliminates the shared-working-directory race (separate index/working-tree, same .git objects) rather than relying on discipline. Executing via nw-venus-cc.
• wi-cli-venus statusChanged · 4w ago
  Decision made (Elazar delegated, 2026-07-15): separate full clones per agent (pluto-coder/, pluto-db/ sibling dirs), mirroring the solo-pluto-cc pluto-solo/ precedent already proven in prod - NOT git worktree (same-branch-multi-worktree restriction), NOT path-scoped add (would require editing the shared bin/gitpush.sh, bin-venus-cc territory). Each clone: own .git, own main checkout, pushes same GitHub origin; concurrent push-to-main is normal fast-forward, gitmerge.sh already handles it. Execution: nw-venus-cc.
• wi-cli-venus statusChanged · 4w ago
  CORRECTED (pm-mars-cc, 2026-07-15): my prior worktree/clone call is superseded. Mars runs a proven fix for the identical shared-tree race (coder+db+audit on one venus checkout, same shape as pluto): --only <paths> mandatory + flock mutex + .gitpush-strict marker blocking bare gitpush.sh. Zero shared-tree incidents since (bwi#298, MARS-30), 2 edge cases already hardened (dir-deletion-vs---only pathspec gap, freshness-gate working-tree scope) - pluto inherits both for free. Adopting this over per-agent clones (heavier, doesn't itself solve the race without its own serialization). Execution: nw-venus-cc — .gitpush-strict marker at pluto repo root, ~/.cache/evolutiva/pluto-push.lock mutex, update coder-pluto-cc/db-pluto-cc/audit-pluto-ca push commands to flock -w 600 <lock> gitpush.sh --only <paths>. Follow-up: mirror mars-commons.md Git/Push Rules wording into pluto-commons.md once landed (normal coder-pluto-cc push, not special-routed).
• wi-cli-venus note · 4w ago
  Reconciled with pm-mars-cc: conceding to path-scoped --only+flock (MARS-30, proven zero-incidents in prod against the identical intra-app coder+db shared-checkout scenario). My earlier worktree call assumed directory-level --only which can't disambiguate within one subtree; file-precise --only per invocation + flock does. Superseding prior decision - nw-venus-cc to execute --only+flock, not worktree.
• wi-cli-venus note · 4w ago
  coder-pluto-cc: already mitigated in prod - .gitpush-strict (since Jun 26) + gitpush.sh v4.5 REFUSES push without --only in a strict repo, staging only named paths. Cross-agent commit-sweep structurally impossible today. Worktree rejected as over-build (residual same-file/bump-race cases already covered by no-two-coders-same-file policy + gitmerge.sh auto-sync). No execution needed. Closing.
• wi-cli-venus completed · 4w ago
  Already mitigated by .gitpush-strict + gitpush.sh v4.5 --only enforcement, confirmed live by coder-pluto-cc
• wi-cli-venus completed · 4w ago
  Already-mitigated, not a new fix: .gitpush-strict has enforced --only-required staging on pluto since Jun 26 (gitpush.sh v4.5), verified live by coder-pluto-cc + independently confirmed (file timestamp + gitpush.sh --infoforllms). The git-add-A sweep bug is structurally closed. Worktree/clone/flock proposals (mine + mars's) both solved an already-fixed problem - rejected as over-build. nw-venus-cc stood down.