gdrive bisync down since ~May 16 (whey<->venus) — venus agents loading 2-week-stale evolutiva shared .md rules (missing WI#450 + A+B + any ratified change since May 16); fleet correctness/drift risk. Fix = repair rclone bisync (maintainer territory), then re-measure per-agent preload vs true current files.

Sub-tickets

Questions

Activity

• system created · 2026-05-31
  wi cli
• rob questionAsked · 2026-05-31
  q#38 to=elazar: Who owns the rclone/gdrive bisync repair (whey<->venus, down since ~May 16)? Needs an owner to fix it; until then no whey-side md/CLAUDE.md savings propagate to venus agents (venus loads stale fat rep
• rob blocked · 2026-05-31
  awaiting elazar
• rob questionAnswered · 2026-05-31
  q#38: Resolved by fleet vote (Elazar delegated 'vote + solve'). Owner-of-record by scope = os-whey-cc (whey OS/systemd); currently unregistered. maintainer-agents.md has NO rclone-gdrive.service entry = doc
• system statusChanged · 2026-05-31
  whey-side bisync repaired (bin-whey-cc). Remaining: venus un-stales on its next bisync pull from remote; pm-venus/nw-venus verify venus-local commons+global CLAUDE.md drop 15.4K/8.98K -> 11.6K/5.3K. Then close.
• system commented · 2026-05-31
  VENUS HALF NOT auto-healing (pm-venus diagnosis): venus pull unit gdrive-bisync.service is inactive/dead, last ran 2026-05-27 18:19 UTC, no next-run scheduled. venus-local still stale (commons 15.4K, global CLAUDE.md 8.98K). RISK: naive 'systemctl --user start gdrive-bisync' on venus could push venus-stale->remote and UNDO whey fix. Needs remote-wins --resync on venus side, executed by bisync owner (bin-whey-cc), NOT a naive start, NOT a PM (no-infra). nw-venus-cc maintainer OFFLINE. Staying inProgress; close only after venus pulls clean to 11.6K/5.3K.
• rob questionAsked · 2026-05-31
  q#40 to=elazar: Venus-side bisync recovery needs an AUTHORIZED executor and is the only thing left to un-stale venus (commons 15.4K->11.6K, global CLAUDE.md 8.98K->5.3K, ~3.6K/agent/turn). Venus's pull unit is dead (
• rob blocked · 2026-05-31
  awaiting elazar
• system blocked · 2026-05-31
  venus-half blocked: needs Elazar to authorize executor (nw-venus offline / bin ssh) - filed q#40
• system blocked · 2026-05-31
  venus-half blocked: needs Elazar to authorize executor (nw-venus offline OR bin ssh) - filed q#40
• system commented · 2026-05-31
  Executor options refined (generalpm consolidated ask to Elazar): REC = pm-venus-cc runs bin's exact verbatim sequence LOCALLY on venus (no cross-host ssh; needs Elazar to override pm-venus no-infra for this one verbatim run); ALT = authorize bin to ssh-exec; (wait) = hold for nw-venus-cc. bin remains safety author + confirms venus ~/gdrive path before any run. q#40 anchors the gate; generalpm owns the single Elazar ask.
• rob questionAnswered · 2026-05-31
  q#40: Elazar: YES. pm-venus-cc authorized to run recovery on venus host. bin-whey-cc confirms exact venus ~/gdrive path + posts verbatim 4-cmd remote-wins resync (--resync-mode path1); pm-venus runs it EXAC
• system statusChanged · 2026-05-31
  Elazar authorized venus executor (q#40 YES). pm-venus-cc runs bin's verbatim remote-wins resync on venus; closes on venus posting ~11.6K/5.3K counts.
• system blocked · 2026-05-31
  pm-venus pre-flight: runbook won't deliver. Agent-loaded files on venus (/home/rob/evolutiva-shared/, /home/rob/.claude/CLAUDE.md) are independent dirs, NOT downstream of ~/gdrive bisync. No gdrive->home pull service (checked --user units+mounts). ~/gdrive copies ALSO stale; ~/gdrive/.claude/CLAUDE.md doesn't exist (claude-backup is home->gdrive push only). So remote-wins resync un-stales gdrive tree but loaded files stay 15.4K/8.98K - goal unmet. BLOCKED on bin: what actually refreshes those two paths on venus? (pm-venus only checked user-systemd+mounts; need system-level/cron check.)
• system commented · 2026-05-31
  VERIFIED GROUND TRUTH (bin+nw-whey, sudo read-only): delivery chain is ABSENT fleet-wide, not just venus. (1) No post-commit hook in pensanta-websites repo - commit->gdrive->bisync model was NEVER wired; bin's commons commits updated git repo only. (2) /gdrive/evolutiva-shared/md/commons.md on WHEY still 15360 stale - repo->gdrive hop doesn't run. (3) Agent-loaded paths downstream of NO sync on any host. (4) Shared md canonical = /gdrive/evolutiva-shared (Drive=de-facto SSOT) but nothing pulls it to load-paths. (5) global CLAUDE.md per-host authored, ZERO propagation (only per-host dated gdrive backup). RE-SCOPE: #590 = design+wire canonical->all-hosts delivery for shared md. Lead=bin-whey-cc (generalpm structure lock); nw-whey (push side)+nw-venus (receive side)=sudo hands; pm-cc-w owns record+close. Close criterion now = agent-loaded paths on hosts show canonical counts after delivery built.
• system commented · 2026-05-31
  MATERIAL CORRECTION (nw-whey sudo, symlink resolution): WHEY NOT STALE. Whey in-repo agents load shared md via .claude/rules/ SYMLINKS -> canonical repo working tree (shared/md/evolutiva-commons.md = 11906B live, SHA f624f0a). No gdrive hop. Earlier 'whey stale' read /gdrive, which whey agents don't load from. REAL break is narrower: canonical = repo working tree; staleness ONLY on hosts loading a STANDALONE copy fed by repo->gdrive->host pipeline never built (venus /home/rob/evolutiva-shared/md/ 15360, /gdrive 15360 + missing files; no commit hook). DESIGN FORK (bin lead, needs venus fact from nw-venus): if venus HAS pensanta-websites checkout -> repoint venus .claude/rules symlinks at working tree (like whey) + git-pull timer, NO gdrive hop (cleanest); else -> gdrive push/pull fallback. Pending: (a) venus repo-checkout fact, (b) Elazar CLAUDE.md fleet-sync decision (q#41 via generalpm).
• system commented · 2026-05-31
  RESOLVING FACT (pm-venus, retracts her earlier standalone-copy claim): venus HAS pensanta-websites repo at SAME path as whey; venus agents load shared md from REPO WORKING TREE via .claude/rules symlink, NOT /home/rob/evolutiva-shared/ nor /gdrive. venus stale (15360) ONLY because repo HEAD is BEHIND whey. => DELIVERY MECHANISM ALREADY EXISTS = git + symlinks (identical both hosts). No pipeline to build. FIX = git pull venus repo -> slim commons 11906 lands -> venus agents load slim. DE-SCOPED from 'build delivery' to 'git pull venus + keep-current mechanism (pull timer/hook, bin design)'; check uncommitted venus-local edits first (nw-venus). CLAUDE.md still separate (outside repo, per-host) = q#41 only. CLOSE on venus post-pull working-tree commons = canonical count + keep-current shape in.
• system commented · 2026-05-31
  CORRECTION (my error, retracted): (1) pm-venus did NOT retract her standalone-copy finding - she re-confirmed it live; I wrongly said she retracted. (2) git pull alone does NOT fix venus - I de-scoped prematurely. TRUE STATE: venus git root = venus/ (rev-parse); venus .claude/rules/evolutiva-commons.md -> ../../../../../shared/md/ climbs ABOVE venus git root; readlink -f terminates at /home/rob/evolutiva-shared/md/evolutiva-commons.md = REAL standalone home file (15360) OUTSIDE venus repo. git pull refreshes venus repo but NOT that home dir. DIVERGENCE: whey git root=websites/, same path is real in-repo file (11906); venus git root=venus/, chain ends in standalone home. Different checkout shapes. FORK (bin design): (a) restructure venus to whey-shaped full-tree checkout (shared/md in-repo) + pull timer; (b) keep layout + feed /home/rob/evolutiva-shared/md/ from canonical. Open fact (nw-venus): does venus repo TRACK in-repo shared/md or only the home-terminating symlink? CLOSE on venus LOADED file = canonical count, whichever shape.
• system completed · 2026-05-31
  RESOLVED via nw-venus sparse-clone pivot (verified): ~/evolutiva-shared-feed = partial+sparse clone of evolutiva-pensanta-com/shared/md (commons=11906 @ f624f0a = canonical); /home/rob/evolutiva-shared/md symlink repointed to the feed; stale dir backed up (md.stale-1780233465, 15360). 20m ff-only pull timer (evolutiva-shared-pull.timer) keeps it current, oneshot test=success; nw-venus owns the timer. VERIFIED 16/16 agents resolve to 11906 (venus+pluto+mars dirs); whole md/ dir refreshed (db 1320->3917, frontend 1279->6235, +memory-discipline 11629). whey was already in-repo-correct (no change needed); venus was the only other Evolutiva agent host (lezama=GCABA, no Evolutiva agents). CLOSE CRITERION MET = loaded file = canonical on all affected hosts. NOTE: global ~/.claude/CLAUDE.md is OUT OF SCOPE here (outside the repo, per-host) - tracked separately in WI#591 q#41.