bc-dgx7.88: B7e-window — Is another live window already on this bead — one call

[mordam]

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.

Files changed — 8 files · +736 −0 · against `main`

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

---

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

[mordam]

A beadcause worker opened this and does not merge its own work. It is on the merge queue as bc-dmjs4.

[NeanderthalMan]

MergeAdvocate on bc-dmjs4 has this one. Bringing main (312aaec) into worktree-b7e-window-dgx788; the branch forked at aab79af, so it is 8 commits behind and the last green run here was against a base that no longer exists.

The overlap is five files: README.md, lib/grants.js, lib/toolbelt.js, package.json, package-lock.json. Four of those five are now covered by the merge=union driver main added in .gitattributes (bc-8479e) — this branch predates it, so the driver is not in its working tree yet and I expect to have to bring .gitattributes in before those resolve themselves rather than as conflicts. Either way, all four are both-sides-append registry lines and test/unionmerge.mjs is the thing that catches it if union got one wrong. README.md is deliberately not union-covered, and that is where I expect the one conflict I actually have to read: this branch appends a b7e-window section, main appended b7e-where, b7e-take and b7e-plate sections in the same neighbourhood. If the two sides turn out to be saying different things about the same paragraph rather than adding adjacent ones, I hand it back rather than pick.

The risk the worker flagged — the --family census reporting a false positive when a live process argv carries a note quoting another bead's qualified id — is documented rather than fixed, on the grounds that namesBead/linesNameBead already accept the same trade for the single-id case. I am not relitigating that; I am checking that main has not moved namesBead or the word-boundary rule out from under it in the eight commits since the fork.

Then node bin/b7e-gate, then push. The queue merges it; I do not.

[NeanderthalMan]

Resolved and pushed — 5a9afabf, MERGEABLE. Three conflicts, all of them both-sides-append; none of them a disagreement, so nothing here needed handing back.

lib/grants.js — one line each side at the same insertion point, 'Bash(b7e-window:*)' (ours) against 'Bash(b7e-where:*)' (main). Kept both.
lib/toolbelt.js — the same shape, a commented DEFAULT_TOOL_LIST entry each. Kept both.
README.md — two whole sections appended at the same anchor between b7e-answered and b7e-swbump: ours documents b7e-window, main's documents b7e-where. Different tools, no shared paragraph, no cross-reference either way. Kept both, ours first, and restored the blank line the conflict markers ate between them.
package.json and package-lock.json auto-merged; both carry both bin entries.

Worth writing down, because every branch older than .gitattributes will hit it exactly once: the merge=union driver did not apply here. Git reads merge attributes from the working tree at the start of the merge, and this branch forked at aab79af, before .gitattributes existed — so the driver arrived in the same commit that would have needed to already have it. I resolved by hand to precisely what union would have produced, and node test/unionmerge.mjs (17/17) is the thing that says so: no duplicated key, no read-vs-write collapse, 77 grants / 52 tools / 98 bin entries each declared once. After this downmerge the driver is in the branch's tree and any later merge resolves silently.

On the --family census false-positive the worker flagged: I did not relitigate the decision to document rather than fix it, I checked that main had not moved the ground under it. lib/reap.js — namesBead and the word-boundary rule the whole argument rests on — is untouched since the fork, as are claude.js, gates.js, ancestry.js and ownership.js. bin/b7e-window does reach two files main changed, lib/config.js and lib/bd.js, but both diffs are purely additive and loadConfig, Bd, bd.show and bd.graph all still exist with the signatures it calls.

Gate over the merged tree: node bin/b7e-gate --jobs 6, all 490 suites passed. That is cleaner than the worker's own run, which had four load flakes (bdtemplate, monitoronce, harness, outagepush) — all four green here. test/b7ewindow.mjs 21/21, plus anchors/grants/loadorder/lockfile green over the merged README and registries. And main is green at its own tip (312aaec), so nothing in this run is being excused as inherited red.

Handing it back to the queue to merge. I am not merging it and I am not closing bc-dgx7.88.

[NeanderthalMan]

CI settled green on 5a9afab — all four shards and the rollup test job pass. mergeStateStatus is now CLEAN.

That is a verdict on what is actually going to land, not on the base that was there this morning. Nothing outstanding from my side: the queue takes it from here and closes bc-dgx7.88 with bc-dmjs4.

[mordam]

Merged into main as 2ea8239c by the beadcause merge queue.

• The base moved under it 3 times. main was brought into the branch 3 times while it waited, so what merged was tested against a base that kept arriving.

The queue reports its own half only: how this branch got through, not what was in it. What the advocate actually did — the conflicts, which side it kept, the suites it ran and against which tree — is on bc-dgx7.88's merge bead, written by the window that did it. Nothing here is a summary of that; a process that did not watch the merge has no business paraphrasing one.