bc-7qo.24: B7e-onbead — Who else is live on this bead right now — pid, worktree - #656
Open
mordam wants to merge 8 commits into
Open
bc-7qo.24: B7e-onbead — Who else is live on this bead right now — pid, worktree#656mordam wants to merge 8 commits into
mordam wants to merge 8 commits into
Conversation
New command answering the question three sessions on three different beads each built a different partial instrument for by hand before their first edit: bc-7qo.11 (guessed worktree slug, silently resumed a live peer's tree), bc-xl7n.113.1 (a bare pgrep/lsof cwd census with no bead in it) and bc-xl7n.113.2 (cd into a sibling's worktree to read its diff directly). lib/onbead.js is almost entirely reuse: lib/prior.js's branchesFor for every worktree (live or retired) and branch owning the bead's tag, with how far ahead of main and whether pushed; lib/claude.js's liveSessions and liveProcessLines for pid/cwd/name matching, including the gap before a session has cut a worktree or renamed itself at all. The one new piece is diskState — dirty/committed-unpushed/committed-pushed/empty/gone, read fresh from git status in the worktree, never from claim-guard's claimed line ranges, which are intent rather than disk. bin/b7e-onbead follows bin/b7e-prior's CLI shape. Registered on DEFAULT_TOOL_LIST (lib/toolbelt.js) and classified read in lib/grants.js, plus both bin map entries (package.json, package-lock.json) and a README section.
Owner
Author
|
A beadcause worker opened this and does not merge its own work. It is on the merge queue as bc-y4hw8. |
Owner
Author
|
The beadcause merge queue tried to merge this and could not: it has been tried 3 times and stopped at the same place each time. the branch still conflicts with |
…qo24 # Conflicts: # README.md # lib/grants.js # lib/toolbelt.js # package-lock.json # package.json
…qo24 # Conflicts: # lib/grants.js # lib/toolbelt.js # package-lock.json # package.json
…qo24 # Conflicts: # lib/grants.js # lib/toolbelt.js
…qo24 # Conflicts: # lib/grants.js
mordam
added a commit
that referenced
this pull request
Aug 26, 2026
…— one call (#773) bc-dgx7.88: bin/b7e-window + lib/window.js — a session-side self-check answering "is another live window already on this bead", replacing the seven different hand-rolled `ps` pipelines a session audit found across the deluvia tracker (one flooded 50KB to a file nobody read, one got a false negative on the exact question this exists to answer). One `ps -Ao pid=,etime=,args=` read, matched with the same word-boundary rule (`namesBead`, lib/reap.js) the rest of the codebase already trusts for this, with an exit code a session can act on: 0 alone, 1 a competitor (pids named). `--family` widens to the nearest root epic/P0 and everything under it, reproducing the whole-epic census two of those sessions assembled by hand — informational only there, so the exit code stays 0 regardless. While investigating I found bc-7qo.24 (b7e-onbead) already covers closely overlapping ground, but its branch is stuck unmerged (PR #656, conflicted, no resolver in 3 tries — bc-y4hw8). Per the standing rule against depending on an unmerged sibling's module, I did not import lib/onbead.js — this module reuses only already-on-main primitives (lib/prior.js/lib/claude.js/lib/reap.js/lib/ancestry.js/lib/gates.js) and duplicates the small amount of overlapping logic (matching + "own pid" resolution) rather than share it. The two tools answer genuinely different shapes of the question — b7e-onbead is an investigative report for reaching a live peer (worktree, dirty state, a SendMessage-able name); this is a fast boolean gate for a session's own self-check — and are kept distinct for now, the way b7e-siblings/b7e-onbead were before them. Filed bc-dgx7.94 to revisit once b7e-onbead actually lands. Unsure of: whether the --family false-positive risk (a memory note quoting another bead's qualified id as example text reads as "live on it") is acceptable as documented, or whether a future session should try to narrow the match further (e.g. requiring the qualified id to appear near "You are working bead" in the argv). Left as-is since it's the same accepted trade-off the rest of the codebase already lives with for the single-id case. **Tests:** node test/b7ewindow.mjs (21/21 ok, including a real two-process end-to-end exit-1 check, stress-tested clean under 2x CPU oversubscription); full node bin/b7e-gate --jobs 6 (486 suites): my own suite failed once at fixed load (a fixed-sleep-after-spawn fixture bug, fixed to poll on real ps evidence instead — see the note it now cites), then verified green; 4 other failures (bdtemplate, monitoronce, harness, outagepush) are pre-existing wall-clock/load flakes under the heavy concurrent gate — none touch files this change touches except harness.mjs, which passed 80/80 re-run alone once load settled. **Worth knowing:** The --family census can surface false positives: a live process's argv can carry its whole loaded memory/context, and a note quoting another bead's qualified id as worked example text reads as 'live on that bead' too — observed live while building this against the real bc-dgx7 epic. Documented prominently in both lib/window.js and the README rather than fixed, since it's the same trade-off the rest of the codebase (namesBead/linesNameBead) already accepts for the single-id case. <details><summary><b>Files changed</b> — 8 files · +736 −0 · against `main`</summary> ``` test/b7ewindow.mjs +360 −0 lib/window.js +181 −0 bin/b7e-window +127 −0 README.md +58 −0 lib/toolbelt.js +7 −0 lib/grants.js +1 −0 package-lock.json +1 −0 package.json +1 −0 ``` </details> --- _Opened by a beadcause worker session on bc-dgx7.88 — *b7e-window — Is another live window already on this bead — one call, not seven inventions*. It merges itself once the checks report; merging is what closes the bead. If this is still open, something stopped that, and the reason is on bc-dgx7.88 and in Adam's inbox._ bead: bc-dgx7.88
…qo24 # Conflicts: # lib/grants.js
The branch-side copy still lists lib/grants.js and lib/toolbelt.js as merge=union, which bc-wbrhi took off that list on purpose: both files are derived from bin/ now, and union on a derived file silently restores blocks the other side deleted. Git reads merge attributes from the checkout doing the merge — the branch — so main's copy has to be here before the merge, not brought in by it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Resolving the merge of origin/main into this branch. main moved the b7e-* half of the read-only surface out of lib/grants.js and lib/toolbelt.js and into the tools' own headers: a bin/b7e-* file says @grant read, write or excluded, and lib/tooldecl.js assembles both registries from that. This branch predates it and still appended a line to each, which is where both conflicts were. Both registries are taken from origin/main verbatim and the classification they carried moves into bin/b7e-onbead's header. read rather than write for the reason this branch already gave, kept in its own words. node bin/b7e-enroll b7e-onbead says nothing is owed, and this branch now touches neither registry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
b7e-onbead (bc-7qo.24): who else is live on this bead right now — pid, worktree, work in hand, and how to reach them. Three sessions on three different beads each hand-built a partial version of this before their first edit; bc-7qo.11's own debrief is the sharpest account — a guessed worktree slug had EnterWorktree silently resume a live peer's tree, caught only when an Edit failed to match a string read four minutes earlier, then several more calls and two failed SendMessage attempts just to get a reachable name.
lib/onbead.js is almost entirely reuse rather than new git-reading code: lib/prior.js's branchesFor already answers "every worktree (live or retired) and branch owning this bead's tag, how far ahead of main, whether pushed"; lib/claude.js's liveSessions and liveProcessLines supply pid/cwd/name matching, including the gap before a session has cut a worktree or renamed itself at all (the exact moment bc-7qo.11 and two siblings collided). The one genuinely new piece is disk state — dirty / committed-unpushed / committed-pushed / empty / gone — read fresh from
git status --porcelainin the worktree itself, deliberately never from scripts/claim-guard.sh's claimed line ranges, since those are intent and bc-7qo.11's debrief is the record of that distinction mattering in practice.What I'm least sure of: "the agent name SendMessage will accept" can only be truly resolved live by ListAgents (a harness-side tool, not something a spawned script can call) — its short-slug fallback on a name collision isn't derivable from any file this command can read. I report the session's own chosen name as the address to try, and flag when two rows here share one name (the exact bc-7qo.11 collision), but that's a caveat, not a promise; ListAgents stays the actual source of truth. Also: the bead's own body text was truncated after "the bd assignee and any" — I read that as assignee + status, surfaced in both the printed report and --json, which is the closest to the acceptance criteria I could construct from what's legible.
Tests: Full gate: node bin/b7e-gate --jobs 6 (421 suites, parallel, no-bail) — 420/421 passed. The one failure, test/pagealias.mjs, is the known fresh-worktree missing-public/vendor gap (expects vendor asset paths, worktree has none symlinked) and is unrelated to this change; it ran and passed within the same gate run at [273/421] 17.3s. Also ran test/onbead.mjs, test/lockfile.mjs, test/grants.mjs, test/anchors.mjs, test/reap.mjs, test/siblings.mjs and test/b7eprior.mjs standalone before the full run, all green.
Files changed — 8 files · +749 −0 · against `main`
Opened by a beadcause worker session on bc-7qo.24 — b7e-onbead — Who else is live on this bead right now — pid, worktree, work in hand, and how to reach them. It merges itself once the checks report; merging is what closes the bead. If this is still open, something stopped that, and the reason is on bc-7qo.24 and in Adam's inbox.
bead: bc-7qo.24