beads_for_franken_engine

01 · What it is

What this is, and why it matters

This is a sibling of the frankentui dashboard brief: another bv --pages static export. The maintainer's beads_viewer tool (1,691 stars) compiles a project's beads journal (a SQLite-backed issue tracker where each "bead" is a bug, task, or epic) into a self-contained website. source This instance captures FrankenEngine's journal as of March 8, 2026: 1,180 issues, 1,916 dependencies, 900 comments in a 7.9 MB SQLite database, shipped as 8 content-hashed chunks, with precomputed PageRank, betweenness, and critical-path analytics, a full-text search index, a hybrid search scorer, and a commit→beads "time-travel" view. It is one of eight such dashboard repos in the maintainer's fleet, and the stalest push of the eight: a single commit, landed March 9, never touched since.

Why it matters, again, is the pattern. Bead journals live as JSONL inside a repo's .beads/ directory: queryable by the maintainer's terminal UI, invisible to everyone else. bv --pages compiles the journal into a static site on GitHub Pages: no server, no token, no sync infrastructure, readable offline by anyone with a browser. The export is a lossy projection (authorship, close reasons, and acceptance criteria don't survive into the published database), but it is a queryable artifact: the journal as data you can download, diff, and interrogate without GitHub access.

02 · Why build it

Why this approach?

The case, such as the repo states it: a contributor, auditor, or curious outsider who wants to see "what is this project working on, what's blocked, where's the critical path" has no URL to open. The static export fixes that at near-zero operating cost. The build system lives upstream in the generator, and the repo is its output.

The counter-argument is the same as its sibling's and lands harder here. The incumbent is GitHub Issues: the live lane (write path, notifications, assignees, real-time state), completely owned. This dashboard has no write path and 197-day-old reads, so it doesn't compete; it complements, and then it expired. The tradeoff was never revisited anywhere in the fleet: on September 21 the maintainer batch-reformatted three sibling dashboards' code while every dashboard's data stayed March-frozen. This repo missed even the cosmetic pass, still on its single March commit, despite the maintainer pushing FrankenEngine itself that same morning, hours before the style batch landed. The fleet gets its code maintained; its data, never.

03 · What was built

What the project actually built

The data fidelity is genuine, and the analyst verified it claim by claim: every headline count reproduces exactly from the shipped database (1,180 issues, 853 closed, 1,916 dependencies, 900 comments); the 8 chunks reassemble byte-exact to the committed SQLite file; the dependency graph is acyclic. An independent depth-first search over all 1,916 edges found no back edge; the full-text index answers queries; the scorer's self-test passes; a service worker sets the isolation headers the database engine's threading needs; 5.3 MB of libraries are vendored for the offline story.

The uncomfortable findings

Uncomfortable finding

The export is 197 days old. Every one of the 1,180 tracked issues is closed in FrankenEngine's live journal, which has grown to 4,537 beads. The dashboard covers 26% of a journal that moved on. A dashboard whose entire tracked universe is completed is not a dashboard; it's an archive mislabeled at the door. - The triage numbers don't recompute, not even from the generator's own database.** The README says 264 blocked / 63 ready to work. source Recomputed from the shipped SQLite: 251 / 76 under unmet-dependency semantics, or 286 / 41 under the database's own metrics column. The same +13 offset, on both sides, appears in the sibling frankentui journal — a systematic definitional error in bv's triage pipeline, not random drift. The column named blocked_by_count counts edges on already-closed issues, so the name is wrong too. For a project whose thesis is evidence you can check, shipping three answers to "how many are blocked" is a credibility wound. - No license, and the frontend is someone else's rider-licensed code. The 7.9 MB dataset is all-rights-reserved by default. Worse, the shipped frontend carries the generator's code (bead-ID comments from bv) with no license notice at all, where bv's license requires derivative distributions to carry its AI-lab rider unmodified. The legal status of the reuse this repo most needs — forking it as a template — is murky on two fronts at once. - No regeneration path, and the database ships twice. No script, no CI (continuous integration: automated checks that run on every change) job, no recorded generator version — reproducing the export means guessing the tool version and re-running it by hand. And the 7.9 MB SQLite file is committed twice: once whole, once as chunks, byte-identical, with no note explaining which is the deployment artifact and which is the analyst-friendly one. An orphaned demo page imports a path that exists only in the generator's own checkout; the scorer-WASM directory it references doesn't exist.

04 · Where it stands

Where it stands

In our program's terms: TRL 7, NODUS ring Monitor. In plain English: a working static site tracking a dead snapshot. The Rulebook names Monitor for websites and retired artifacts, and this repo is both at once.

Technology readiness

13579

TRL 7 on a 1-to-9 scale.

NODUS ring

MonitorExplorePilotInvest

The program’s adoption ring for this project.

Verdict key

NODUS ring: Monitor: Websites, retired artifacts, and plan-stage work.
TRL: Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 7.
CI: Continuous integration: the project’s automated checks, run on every change.
The pin: The exact commit the assessment was pinned to. “At the pin” means as of that commit.

Evidence tiers

Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
Tier 5 · Inference — The analyst’s judgment. Always labeled; never presented as fact.

What this verdict rests on. Tier labels are the assessment packet’s own annotations.

Tier 1 · Verified: Site mechanics read in code; the fleet dashboard inventory and 197-day freeze read from the API.
Tier 2 · CI-observed: Both deploy runs green at the pin: a working site tracking a dead snapshot.
Tier 3 · Maintainer claim: In-browser hydration, charts, and the time-travel animation are code-verified, never executed; the JS scorer was not diffed against the Go original.
Tier 4 · External: No independent validation.
Tier 5 · Inference: The Monitor ring: the generator is the project; the repo is a frozen export.

Should you use it?

No.

Its triage advice describes a project chapter that ended in March.

Should you learn from it?

Two things, and both are the pattern rather than the instance.

First, the export-bundle format (SQLite plus precomputed analytics plus chunked WASM loading plus a provenance manifest plus hash-manifested chunks) is a directly importable template for publishing any repo's evidence as a portable, checkable artifact. Second, the fossil is a labeled backtesting dataset: all 1,180 outcomes are now known, with close timestamps, so bv's triage scores can be validated against actual close order — a rank correlation that would say whether "Top Priorities" was signal or decoration. No triage heuristic in the ecosystem has a public labeled dataset to be tested against. This one exists, and it's unlicensed.

What would change the verdict, in order

a second commit: a scheduled re-export in CI, the one thing nobody in the fleet has done in 197 days
a LICENSE file
the 264/63 reconciled with a documented, re-runnable query. Any one of the three makes it a living artifact again
all three make it a template worth copying.

05 · What it teaches

What this teaches about building with agents

The transferable lesson is about provenance of definitions, not just bytes. This repo checksums every chunk of its database, and then disagrees with itself three ways on how many issues are blocked, because the blocked/ready definition lives in an unpinned generator version and a misnamed column. Integrity-check the semantics, not just the bytes: publish the verification query alongside the number, so anyone — human or agent — can re-derive the headline from the artifact. A dashboard whose numbers don't recompute from its own database is decoration with a checksum.

The deeper fleet finding sharpens the frankentui brief's lesson. The maintainer operates eight dashboard repos as a single surface, with identical batch commits landing the same day, but the batch discipline covers code, never data. The missing piece was never tooling (--watch-export exists); it was scheduling data cadence with the same batch rigor as code formatting. When agents maintain your repos, they will polish what is legible and scheduled, and ignore what decays silently. The freshness loop has to be the scheduled thing.

And as with its sibling: the staleness finding was only possible because the export stamped an accurate generated_at and the journal kept its close timestamps. Accurate timestamps are what turn a fossil into a dataset — and a dataset into an experiment.

beads_for_franken_engine A Museum Mislabeled "Live"