beads-for-frankentui

01 · What it is

What this is, and why it matters

This is not a product. It is a generated deployment artifact: the output of bv --pages, a feature of the maintainer's beads_viewer tool (1,691 stars), pointed at frankentui's beads database: a SQLite-backed issue tracker that lives inside the repo, where each "bead" is a bug, task, or epic with dependencies between them. The tool compiled the whole journal (2,590 issues, 3,700 dependencies) into a static, interactive dashboard hosted on GitHub Pages: 16,196 generated lines of JavaScript/HTML/CSS (not hand-written here), a 10 MB SQLite database shipped as eleven 1 MB chunks with SHA-256 integrity checks, vendored copies of every library it needs, a Rust-compiled PageRank module running in WebAssembly, and precomputed triage analysis: "top priorities," "critical bottlenecks," "quick wins."

Why it matters is the pattern, not this instance. Projects driven by coding agents generate issues faster than a human can triage them. The deployment log records 1,237 bead closures in a single week in February. A dashboard that renders a thousand-issue dependency graph legible, publishes as a static site with zero servers to operate, works offline, and checksums its own backend is an unusual artifact. This repo is one of eight such dashboards the maintainer's generator produced. Every one of them has the same disease, which is what this brief is about.

02 · Why build it

Why this approach?

The maintainer's stated case, reconstructed from the deployment log: legibility at scale (PageRank impact scores, bottleneck detection, and quick wins computed, not hand-curated); zero-ops publishing (bv --pages snapshots the database, pre-computes the analytics, chunks the DB with hashes, and force-pushes the result, "no server-side component"); offline-first (every dependency vendored down to the fonts, a service worker enabling the database engine's threading); and documented history (the CHANGELOG documents the orphan-commit topology, a removed time-travel feature, and a completion metric regressing from 99% to 92%, in writing, dated).

The counter-argument is that the incumbent is the forge itself. GitHub Projects and Insights already give every repo kanban boards, burndown charts, and dependency tracking, live, at zero marginal cost, with zero staleness: the three properties this dashboard lacks. The dashboard's only uncontested edge is its computed graph analysis, which the forge doesn't do. But computed analysis of stale data is a diorama, not a triage tool. And the sharpest competitive frame is internal: the generator behind this export has 1,691 stars; this deployment has 12. The byproduct starved while the product ate.

03 · What was built

What the project actually built

The construction is careful, and the analyst verified it: the issue counts reproduce exactly from the shipped database (2,590 issues, 3,700 dependencies); all 11 chunk hashes were re-verified against the manifest; the hybrid search scorer's self-test passes when executed; the pin (the commit the assessment was pinned to)'s deploy run is green; the live site returns HTTP 200; there are zero external URLs at runtime and a real content-security policy enforcing it. The offline story survives inspection end to end.

Evidence · CI status

What the project’s own CI said at the pin

GitHub's API reports null, which is worse than the suite's usual restrictive rider, because here no party holds reuse rights; CI (continuous integration: automated checks that run on every change) does nothing but deploy (35 successes, 22 cancellations, 0 failures across 57 runs), and the repo's single test is a browser-embedded self-test that no automation ever runs.

The uncomfortable findings

Uncomfortable finding

The snapshot is frozen at March 8, 2026: 197 days before the pin. frankentui kept shipping the whole time; its own HEAD pushed on September 22, the day after this repo's freshest change. That freshest change, dated September 21, is a pure formatting pass, co-authored by Grok, that normalized quotes and whitespace across the dashboard's JavaScript while the data sat untouched since March. The agent that formatted the code could have regenerated the snapshot, and didn't. That is the staleness mechanism in miniature.

Uncomfortable finding

The rest of the ledger: there is no license file at all. The analyst ran it by hand under a shim; the WASM loader imports a scorer module from a wasm/ directory that does not exist (dead code behind a 5,000-issue threshold the snapshot never reaches); the README says 3,696 dependencies while the database says 3,700; the CHANGELOG omits the last three maintenance commits; eight commits, one author, zero releases. source

04 · Where it stands

Where it stands

In our program's terms: TRL 8, NODUS ring Monitor. In plain English: the deployed technology is proven: the site works, the integrity machinery is real. But the ring rates the artifact's fitness, and this is a website serving a 197-day-old snapshot with no development beyond formatting. The value that survives is the pattern, and it lives in beads_viewer, not here. source

Technology readiness

13579

TRL 8 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 8.
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: Chunk mechanics (eleven 1 MB chunks, SHA-256 reassembly) read in code; the 302 KB index.html fetched HTTP 200; the 197-day staleness dated from the CHANGELOG and the API.
Tier 2 · CI-observed: Deploy-only CI: 35 successes, 22 cancellations, 0 failures — it deploys, it does not verify.
Tier 3 · Maintainer claim: Chunk reassembly, search, and WASM execution are code-verified, never run in a browser by the analyst.
Tier 4 · External: No independent validation.
Tier 5 · Inference: The Monitor ring: a website artifact; the program’s website bucket.

Should you use it?

As a triage surface, no — every "top priority" on it describes a project from March.

Should you learn from it?

Yes.

bv --pages is the FrankenSuite's cheapest auditability upgrade: every repo's issue database rendered as a self-contained, offline, integrity-checked static site. The tool already supports --watch-export (re-export whenever the database changes), so the freshness loop is one scheduled workflow away from being closed. A freshness-guaranteed static dashboard is a lane nobody occupies, because the refresh loop is the hard part, and this repo is the documented failure mode.

What would change the verdict, in order

the snapshot manifest's date advancing past March (a scheduled regeneration, which would re-ring to Explore)
a LICENSE file (the adoption ceiling lifts)
a sibling repo shipping its own bv dashboard (pattern export confirmed).

The terminal alternative is archiving with a dated banner: a museum piece labeled as one, instead of a dashboard labeled "live."

05 · What it teaches

What this teaches about building with agents

The transferable lesson is about freshness as an instrumented property, not a hope. This repo already demonstrates the integrity discipline in full: every byte of its database is SHA-256-verified against a manifest. What the manifest doesn't record is which frankentui commit the snapshot came from. So "stale" is an accusation the analyst had to assemble from timestamps, instead of a number the artifact reports about itself. The fix is one field: hash-pin the source revision in the snapshot manifest. Extend the checksum discipline from bytes to provenance, and staleness becomes a measured quantity with an alarm, not a finding in someone else's audit.

The second half of the lesson is the Grok formatting commit. Agent energy flowed to code polish (whitespace, quote style) while the data rotted, because polishing was the legible task and regenerating was the scheduled one that nobody scheduled. The tool already had the regeneration flag; what was missing was the cron job. When you run agents on a codebase, instrument the thing that decays, not just the thing that looks untidy.

And the enabling condition for all of this: the maintainer dated everything. The staleness finding exists only because the CHANGELOG and the manifest carry accurate timestamps. source Date everything. Documented history is what lets an auditor, or an agent, convict you accurately instead of guessing.

beads-for-frankentui A Working Dashboard of a Finished March