Shared push-tree same-file concurrent-edit handoff protocol
The --only per-FILE (not per-hunk) staging bound bit twice in one session (2026-08-07), in both directions, on src/app/api/cron/practicas-kpi-report/route.ts: coder-pluto-cc and db-pluto-cc had simultaneous uncommitted edits to the same file; the push-instant flock mutex (pluto-commons Git/Push Rules) only wraps the gitpush.sh call itself, not the whole edit-to-push window, so it did not prevent either collision. First collision: db-pluto-cc's git diff check (worktree-vs-index) structurally could not see coder-pluto-cc's already-staged work, giving a false all-clear. Second: db-pluto-cc's own --only push on the same file swept coder-pluto-cc's unstaged notifyOnly hunks into db's PLUTO-99 commit (ae2dbe9, v2.22.63) under a commit message that names neither. Both times self-corrected (coder re-verified with git status --short + git diff --cached --stat; db disclosed the sweep proactively) but the tool provides no mechanism to prevent it going in. Design a lightweight same-file claim/handoff signal (e.g. a DM'd claim-and-release convention, or a per-file lock file) for the pluto shared working tree so two push-lane agents editing the same file don't need to discover the collision after the fact.
Questions
Activity
-
Pattern confirmed 3x this session, same root cause, wider than same-file collision: a non-push lane (audit-pluto-ca, db-pluto-cc) does correct work, then WITHDRAWS it from a commit specifically to preserve provenance (land it later under their own reviewed SHA) — and that withdrawal is exactly what strands it uncommitted in the shared tree with no owner tracking whether it ever lands. All three instances (PLUTO-99 Map rework, the 13-path 2026-07-21 boundary-audit set, admin-batch.ts/PLUTO-641 approveEmailChangesBatch) were each created by a correct call (don't ship unreviewed work under someone else's commit) but left with zero tracking of 'did the withdrawn work ever land'. coder-pluto-cc's suggestion: a standing check, not a one-off WI — e.g. a periodic (weekly?) git status sweep of the shared tree cross-referenced against open bwi items, or a discipline that any provenance-motivated withdrawal must file/reference a WI at withdrawal time so it isn't just silently abandoned in the index. Scope note: widen this WI's design ask to cover both same-file concurrent-edit collision AND stranded-after-withdrawal tracking — same underlying gap (shared tree has no attribution/landing-tracking discipline for non-HEAD state).