bc-dgx7.98: B7e-graph — The workspace's beads and comments as one local snapshot…

[mordam]

Recovers and finishes a dead attempt's work: this worktree (b7e-graph-dgx798a) already held a complete, uncommitted bin/b7e-graph + lib/beadsnapshot.js + test/beadsnapshot.mjs + README section + package.json/lock entries from 2026-08-27, frozen (no live process on it) rather than a duplicate in progress. I committed it as-is, then rebased 91 commits of intervening main onto it — one conflict, in README.md, where main had appended a different new section (b7e-why) right after the same anchor point this one appends after; resolved by keeping both, in main's order.

What it does: bin/b7e-graph reads a beads workspace's issues/labels/comments/parent-edge tables directly off its embeddeddolt/<prefix> Dolt database via dolt sql -r json -q <fixed literal> — never through bd's own query layer, which is exactly what the bead's cited incidents (dv-3rn.2: 48 concurrent bd processes, five-minute hangs) show falling over under concurrent load. Filtering (--title-match, --assignee, --label, --status, --parent, --closed-reason, --with-comments) happens afterward over the plain JS array, so no caller input ever reaches SQL. Results are cached under os.tmpdir() (never ~/.config/beadcause — a disposable read cache doesn't owe an evidence-register entry or a retention decision), invalidated by Dolt's own manifest+journal change mark or --max-age (default 5 min), with --refresh to force a rebuild.

What I verified rather than took on faith from the frozen worktree: the acceptance criteria's live claim (ran it against deluvia's actual graph, not just the test fixture), that the registries the bead's own text names as owed (package.json/lock, README section) are complete and internally consistent after the rebase, and that node bin/b7e-enroll — the tool this repo built since this work was written, specifically to check what a new b7e-* command still owes — finds nothing missing. One thing worth flagging: the bead's own acceptance/description still says the DEFAULT_TOOL_LIST entry goes in lib/toolbelt.js; that convention changed under bc-wbrhi to a self-declared @grant read header line, which bin/b7e-graph already carries, so nothing further was needed there — noted here so nobody re-reads the bead text and goes looking for a toolbelt.js edit that no longer applies.

Tests: node --test test/beadsnapshot.mjs: 46/46 checks pass, including a real bd+dolt fixture proving field-for-field parity with bd list --status=all --json, the read-only guarantee, and the cache invalidation rules. Live-ran against deluvia's real graph: node bin/b7e-graph -w deluvia --title-match 'Entry 107' --with-comments answered correctly in 2.4s (acceptance criteria's 5s bar), comments inlined verbatim. node bin/b7e-enroll b7e-graph: nothing owed (bin/package.json/lock/README/@grant header all agree). Ran the 54 suites node bin/b7e-affected names as touched by this diff (README.md, bin/b7e-graph, lib/beadsnapshot.js, package.json/lock, test/beadsnapshot.mjs) via node --test: 54/54 pass, 0 fail. Started a full node bin/b7e-gate --jobs 6 but it queued 20+ min behind two other sessions' gates on this shared Mac without reaching a suite; stopped it rather than hold the window — CI runs the full suite on the PR.

Files changed — 6 files · +1243 −0 · against `main`

test/beadsnapshot.mjs  +634 −0
lib/beadsnapshot.js    +343 −0
bin/b7e-graph          +198 −0
README.md              +66 −0
package-lock.json      +1 −0
package.json           +1 −0

---

Opened by a beadcause worker session on bc-dgx7.98 — b7e-graph — The workspace's beads and comments as one local snapshot you can actually query. 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.98 and in Adam's inbox.

bead: bc-dgx7.98

[mordam]

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

[mordam]

Merged into main as 5a0258ad by the beadcause merge queue.

• Straight through. No refusal, no downmerge: it was mergeable when the queue first read it.

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.98'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.