venus: adopt two-layer gitpush guard (strict --only + per-repo flock) per bs-mqoxiw8ptby

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-22
  parent=#1271
• wi-cli-venus commented · 2026-06-22
  Child of EVO-26, descended from fleet decision bs-mqoxiw8ptby (4/4 PMs). Two-layer gitpush guard for venus. Three legs: (1) venus/.gitpush-strict marker so gitpush refuses add -A and forces push --only paths [coder-venus]; (2) venus push-discipline.md note that strict + --only is now mandatory [pm-venus owns md sync]; (3) per-repo flock wrapping the push (flock -w 600 lockfile at cache evolutiva venus-push.lock, then gitpush --only paths) baked into spawn-worker.sh push path [bin-venus]. GATING leg = bin-venus flock-bake (so spawned workers cannot omit the guard); marker + doc ride after. Execution in aro:venus; pm-venus reports SHA + READY per leg there. Venus lowest urgency of the three (narrow lane coder+coderhelp, no db push exception, pre-go-live) - does not block pluto.
• wi-cli-venus commented · 2026-06-22
  Venus leg-1 shipped at b1a071f (bin-venus): spawn-worker.sh injects GITPUSH=gitpush-locked.sh flock wrapper into worker session env. GAP found by pm-venus: env-routing is a DEFAULT, not enforcement - a worker typing bare gitpush.sh bypasses the flock, so the decision bar worker-cannot-omit is NOT met by this. .gitpush-strict only covers content layer, not sequence. Transparent shim impossible (PreToolUse no-recreate hook blocks gitpush.sh outside terminal sh dir). Two paths to true cannot-omit: (a) relax the no-recreate hook for a target dir - Elazar call, NOT recommended (hygiene erosion); (b) gitpush.sh self-flocks when GITPUSH_LOCK env is set - transparent, zero blast radius for callers that do not set it, bin-owned, but touches fleet gitpush.sh and reopens decision unchanged point. Recommended (b). ESCALATED to Elazar for go/no-go. Venus accepts env ceiling (pre-go-live, lowest urgency); pluto (LIVE) is the driver and HOLDS its Layer-2 enforcement leg pending Elazar ruling. Layer-1 unaffected on both.
• wi-cli-venus commented · 2026-06-22
  Option-b design constraint from pm-pluto (carry into spec when unblocked): the self-flock must key on the REPO (git toplevel), not the spawning context/identity. Pluto serializes three push identities - coder + coderhelp + db (db has the ratified narrow exception: migrations applied, schema.md, reference-data.sqlite, package.json bump) - all bump the SAME package.json. So GITPUSH_LOCK must be set for every push identity and gitpush.sh must derive a per-repo lockfile (one lock per working tree), wrapping every push in that tree regardless of which agent invoked it. A coder-only keyed lock would miss the coderhelp+db races. Pluto leg split: Layer-1 (.gitpush-strict marker + per-role --only lanes incl db 4 paths) proceeds now; Layer-2 cannot-omit enforcement HELD pending Elazar go/no-go on option b. PLUTO-192 not yet dispatched.
• wi-cli-venus completed · 2026-06-22
  VENUS COMPLETE + production-verified. Leg1 flock: bin-venus b1a071f (gitpush-locked.sh + spawn-worker.sh v1.4 GITPUSH env injection; venus in SHARED_TREE_APPS) - live-proven: a coder spawned under v1.4 had GITPUSH_LOCK set at session creation and both its pushes ran through the flock wrapper. Legs2+3 coder-venus: d5d7755 v0.65.9 (.gitpush-strict marker, strict active) + 80575fe v0.65.10 (push-discipline.md note). PTD: /api/health live=0.65.10 dbOk true deploy READY. Reap clean (coder deregistered, no double-reg, tmux gone, roster zero venus workers). Venus accepts env-route ceiling, NO gitpush.sh change. NOTE: option-b self-flock (Elazar escalation, pluto-driven) would upgrade venus to true cannot-omit transparently via the GITPUSH_LOCK that spawn-worker v1.4 already sets - zero further venus work. Closing venus adoption at its accepted ceiling; fleet option-b tracked under the EVO-26 escalation.