# beads_for_franken_engine — RULEBOOK v1.0 Assessment Packet **Repository:** `Dicklesworthstone/beads_for_franken_engine` · **Language:** JavaScript / static site (no Rust, no Cargo — the asupersync lens is vacuous here) [Code-verified, High] · **Pinned commit:** `50e2709a59becd2cf33071f0aa031c5447635c04` (2026-03-08 19:20:12 -0500, [Git-observed, High]) · **Last push:** 2026-03-09T00:20:14Z [External, High] · **Stars/forks:** 3 / 1 [External, High] · **License:** none — no LICENSE file in the tree; GitHub reports `license: null` [Code-verified + External, High] · **Scope:** the pinned commit only. The repo's entire history is exactly one commit, authored by Dicklesworthstone [Git-observed, High]. **Method (analyst):** shallow clone at the pin under `~/workspace/.scratch/beads_fe/repo`; recorded pin hash + date. Read: README.md (verbatim), `beads.sqlite3.config.json`, `data/meta.json`, `data/project_health.json`, `data/triage.json`, `data/history.json` (48 commits), `hybrid_scorer.js` + `hybrid_scorer.test.js`, `wasm_loader.js` (full — scorer-WASM threshold + missing `./wasm/` dir), `viewer.js` (sql.js load path L340–395, bv_graph dynamic import L692), `charts.js` (header + function inventory), `coi-serviceworker.js` (full), `.github/workflows/static.yml`, `index.html` head/CSP/vendor script tags. Queried the shipped `beads.sqlite3` directly with sqlite3: issue/status counts, timestamp ranges, dependency semantics, FTS probe (`cranelift` → 1 hit), chunk-hash reassembly (concatenated chunks sha256 == config total hash == `sha256(beads.sqlite3)`), cycle check over all 1,916 edges (Python DFS, no cycles), `blocked_by_count` semantics (sampled rows: counts all dep edges incl. closed). Cross-checked against `franken_engine`'s live `.beads/issues.jsonl` (sparse clone, 4,537 records): all 1,180 snapshot IDs present, all now closed; upstream README grep: no dashboard link. Ran `hybrid_scorer.test.js` under node with a `window` shim — passed. Grepped the tree (excl. vendor) for performance claims — zero (only hit: a "faster settling" layout-animation comment). GitHub API: repo metadata, Actions runs (2 total, both the Pages deploy at the pin, both `success`), user repo list (the 8-repo dashboard fleet). Fetched the live Pages URL — the shell renders (hydration in a real browser not tested). Read `beads_viewer`'s LICENSE verbatim (MIT + OpenAI/Anthropic rider). **Not done:** the site was never loaded in a real browser (WASM graph init, chunk reassembly in-browser, time-travel animation unexecuted); the viewer was never pointed at the sqlite end-to-end; the JS hybrid scorer was not diffed against `bv`'s Go original; the maintainer was not contacted; vendored third-party licenses were not audited. Assessment date: 2026-09-22. **Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — flavors **[Counted]** (I ran the count), **[Git-observed]** (git metadata), **[Code-verified]** (source read); **[CI-observed]** is Tier 2 (seen executing on live CI pages — attests the suite *runs*, not that it is green); **[Maintainer claim]** asserted in README/docs, not independently executed; **[External]** independent sources; **[Inference]** analyst judgment, always labeled. Confidence: **High** / **Medium** / **Low**. *Cold-reader gloss: a "bead" is the issue-tracker unit — one record in the beads journal (bug/task/epic), with dependencies between beads.* --- ## Hook All 1,180 issues on this "Live Dashboard" are closed [Verified, High]. What remains is a 22 MB time capsule (excluding .git) [Counted, High] with exactly one commit [Git-observed, High]: FrankenEngine's entire March 2026 bead journal — precomputed PageRank, a working full-text search index, a time-travel animation — frozen 197 days ago [Counted, High], shipped with no license file. On 2026-09-21 the maintainer ran a formatting pass over three sibling dashboards; the *code* got prettier, the *data* stayed March-frozen fleet-wide, and this repo — still on its single March commit — wasn't touched at all. --- ## TL;DR - **What it is:** A static GitHub Pages site generated by `bv --pages` (beads_viewer) — a point-in-time export of FrankenEngine's beads issue-tracker journal as of 2026-03-08: 1,180 issues, 1,916 dependencies, 900 comments in a 7.9 MB sqlite, plus precomputed graph analytics (PageRank, betweenness, critical path, triage scores), a chunked WASM loading scheme, and a commit→beads "time-travel" view [all Counted/Code-verified, High]. - **Strongest evidence:** The export is faithful and the engineering is careful. Every headline count reproduces exactly from the shipped sqlite (1,180 / 853 closed / 1,916 deps [Counted, High]); the 8 chunks reassemble byte-exact to the committed sqlite (sha256 match across all three [Verified, High]); the dependency graph is genuinely acyclic (independent DFS over all edges [Counted, High]); the FTS index answers queries; the hybrid scorer's self-test passes under node; the bundle is offline-first with 5.3 MB of vendored libraries and a COOP/COEP service worker for WASM threads. - **Strongest doubts:** The artifact is a fossil wearing a live dashboard's headline. One commit, last pushed 2026-03-09; data 197 days stale [Counted, High]; all 1,180 tracked issues closed in the live journal, which has grown to 4,537 beads — the dashboard covers 26% of a journal that moved on [Verified, High]. The README's "264 blocked / 63 ready" reproduces under no definition from the shipped DB (251/76 by unmet-dependency semantics; 286/41 by the DB's own `issue_metrics` — and the same +13 offset appears in a sibling journal, so the gap is systematic) [Counted, High]. No LICENSE file — the 7.9 MB dataset is technically all-rights-reserved, and the frontend it ships is `bv`'s rider-licensed code distributed without the rider its license requires on Derivative Works [Code-verified, High; the legal reading is Inference, Medium]. No regeneration path in-repo: no script, no CI job, no recorded `bv` version. And the fleet tells the sharper story: a 2026-09-21 batch commit reformatted three sibling dashboards' *code* — data untouched since March everywhere — and this repo, still on its single March commit, missed even that [External, High]. - **NODUS ring: Monitor** [Inference, High] (TRL 7 — see §4.9). The Rulebook names Monitor for "websites, retired artifacts, and plan-stage work" — this is the first two at once. The export *pattern* (portable, zero-backend, offline-first journal publishing) is the methodology worth stealing; this instance is a museum piece. --- ## Quick Links Pin-relative links (`blob/50e2709a59becd2cf33071f0aa031c5447635c04`); all verified resolving 2026-09-22 [Verified, Medium]: 1. [Repository](https://github.com/Dicklesworthstone/beads_for_franken_engine) 2. [README](https://github.com/Dicklesworthstone/beads_for_franken_engine/blob/50e2709a59becd2cf33071f0aa031c5447635c04/README.md) 3. [Live dashboard (GitHub Pages)](https://Dicklesworthstone.github.io/beads_for_franken_engine/) — shell renders; full hydration untested 4. [Export config (chunk manifest + hashes)](https://github.com/Dicklesworthstone/beads_for_franken_engine/blob/50e2709a59becd2cf33071f0aa031c5447635c04/beads.sqlite3.config.json) 5. [Pages deploy workflow](https://github.com/Dicklesworthstone/beads_for_franken_engine/blob/50e2709a59becd2cf33071f0aa031c5447635c04/.github/workflows/static.yml) — the only CI; 2 runs, both green at the pin 6. [Actions runs](https://github.com/Dicklesworthstone/beads_for_franken_engine/actions) — 2 total 7. [The generator: beads_viewer (`bv`)](https://github.com/Dicklesworthstone/beads_viewer) — 1,691 stars, pushed 2026-09-22; source of `bv --pages` 8. [bv's LICENSE (rider text quoted in §4.8; HEAD-relative, may drift — quoted verbatim as of 2026-09-22)](https://github.com/Dicklesworthstone/beads_viewer/blob/HEAD/LICENSE) 9. [The upstream journal: franken_engine](https://github.com/Dicklesworthstone/franken_engine) — 31 stars, pushed 2026-09-21; the live `.beads/issues.jsonl` this dashboard snapshots (its README does not link the dashboard) 10. [Releases page](https://github.com/Dicklesworthstone/beads_for_franken_engine/releases) — resolves; there are no releases, and no CHANGELOG exists in the repo *No LICENSE link can be supplied: the repo contains no LICENSE file — that absence is itself a finding, documented in §4.8. The former link 10 pointed at the missing file's GitHub 404 and has been removed; every link above resolves.* --- ## Did You Know Every one of the 1,180 issues on this "Live Dashboard" is closed in FrankenEngine's live journal today — and the journal has grown to 4,537 beads since the export. The dashboard is a museum of a finished chapter, accurate to the bead: all 1,180 snapshot IDs resolve in the current journal, and all 1,180 carry status `closed`. [Verified, High — snapshot IDs intersected against a 2026-09-22 sparse clone of `franken_engine`'s `.beads/issues.jsonl`.] --- ## Franken-worthy next steps 1. **Backtest the triage scorer against now-known outcomes.** All 1,180 issues in the snapshot are closed with `closed_at` timestamps — the first labeled dataset for `bv`'s impact heuristic. Compute the rank correlation between the March triage scores (`triage_recommendations.score`) and the actual close order; publish the result as an addendum to this packet (or in the `bv` repo). *Done when:* a Spearman ρ (or "no signal") is reported against the shipped sqlite, with the query committed. *Falsifiable:* the scores show no correlation with close order, which converts the "Top Priorities" panel from analytics to decoration. [Inference, High — process proposal] 2. **Regenerate on a schedule, in CI.** A monthly `cron` workflow running `bv --pages` converts the fossil into a living artifact — and the fleet shows the gap is real: the 2026-09-21 batch commit touched three siblings' *code* only; no dashboard's data has been re-exported since March [External, High]. Nobody has done this yet, which is exactly why the step matters. *Done when:* a second commit lands here. *Falsifiable:* the re-export fails or the triage numbers drift again — which is itself the finding. [Inference, High] 3. **License the dataset — and the redistributed frontend.** Add a LICENSE file, or have `bv --pages` emit one: 1,180 issue records plus 900 comments are currently all-rights-reserved by default, and the shipped `viewer.js`/`graph.js` carry `bv`'s bead-ID comments (`bv-z38b`, `bv-wb6h`) while `bv`'s license requires Derivative-Work distributions to carry its rider unmodified [Code-verified, High; legal reading Inference, Medium]. *Done when:* the file exists and names the data's and code's terms. [Inference, High] 4. **Publish the blocked/ready definition with a verification query.** The README's 264/63 must recompute from the shipped sqlite via a documented query, or change to the numbers that do (251/76 under unmet-dependency semantics). *Done when:* a SQL query in the repo reproduces the headline numbers byte-for-byte. *Falsifiable:* no query reproduces 264/63, forcing a correction. [Inference, High] 5. **Run the journal-archaeology study the fossil enables.** Which March blockers actually unblocked work? Join the snapshot's dependency edges against the *current* journal: did `bd-1lsy.6.2`'s 3 downstream issues close because of it, and did the "Critical Bottlenecks" table predict the real critical path? A second, independent validation of the triage machinery — distinct from the scorer backtest. *Done when:* bottleneck-precision numbers (predicted vs actual unblockers) are published. *Falsifiable:* the March bottlenecks show no predictive power. [Inference, Medium] --- ## 4.1 Why it exists — the market problem **The problem, as the ecosystem frames it:** beads journals live inside a repo's `.beads/` directory as JSONL — queryable by the maintainer's TUI, invisible to everyone else. 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. `bv --pages` exists to fix that: it compiles the journal into a self-contained static site — sqlite database, precomputed analytics, search, dependency graph, triage — deployable to GitHub Pages with zero backend, readable by anyone with a browser [Maintainer claim, Medium — `bv`'s README documents the export; the "invisible to everyone else" framing is the analyst's]. **Who feels the pain:** anyone doing due diligence on a beads-driven project (exactly the FrankenSuite assessment program's position), plus the maintainer's own need for a shareable project-health view without granting repo access [Inference, Medium]. **Why this instance, why then:** on 2026-03-08 the maintainer himself (commit author Dicklesworthstone [Git-observed, High]) pointed `bv --pages` at FrankenEngine's journal and committed the output — a public, URL-addressable snapshot of 1,180 issues at a moment when FrankenEngine's bead program was at peak velocity (853 closed in the 30 days before export, the entire closed set [Counted from project_health.json, High]). **Pattern, not one-off — but the pattern is code maintenance, not data refreshes:** this is one of **eight** bead-dashboard repos in the maintainer's fleet [External, High — user repo list, 2026-09-22; fleet = the 8 `beads*` *dashboard* repos, excluding `beads_bend`, `beads_rust`, `beads_viewer`, and `beads_viewer_rust`, which are tools/ports]: `beads-for-frankentui` (12★), `beads_for_cass` (4★), `beads_viewer_for_agentic_coding_flywheel_setup` (10★), `asupersync-beads` (5★, 2026-06-16), `beads_viewer-pages` (7★, 2026-03-22), `beads_for_asupersync` (3★, 2026-03-23), `beads_for_cass_memory_system` (3★, 2026-03-14), and this one (3★, 2026-03-09 — the stalest push of the fleet, and one of three members still on a single commit, with `beads_for_asupersync` and `beads_for_cass_memory_system`) [External, High — commit counts verified via API 2026-09-22]. On 2026-09-21 three siblings received an identical batch commit — "style: format beads viewer JS/CSS/HTML and graph JSON" (a quote/arrow/wrapping pass; "Scoring weights keep the same numeric values") [External, High — commit messages verified via API on all three]. That batch was *formatting only*: the sampled sibling's `export_meta.generated_at` is 2026-03-08 and its max issue `updated_at` is 2026-03-06 [Code-verified, High — `beads-for-frankentui` cloned 2026-09-22]. **No dashboard's data is known to have been re-exported since March** — export freshness was checked directly on two of the eight (this repo, frankentui); the other six have had no pushes at all since the March-era commits except the three formatting-only batch commits. **The maintainer maintains the fleet's code, not its data — and this repo, the oldest member of the fleet's neglected tail, missed even the style pass.** **Weighing the skip-hypotheses (§4.12 Q5):** three readings of "this repo missed the batch" — deprioritized, forgotten, deliberately frozen. One is weakened by evidence: the *underlying* franken_engine project was itself pushed 2026-09-21T01:29Z — **hours before** the dashboard style batch landed at 14:04–14:07Z the same day [External, High]. The maintainer was active in the project the morning of the batch and still didn't touch its dashboard. "Deliberately frozen as a showcase" is weakened by the stale "Live Dashboard" headline and the missing LICENSE — a showcase would be curated, not mislabeled. That leaves forgotten vs. deprioritized; both fit, and both keep the ring [Inference, Medium]. **Why a static export, not a live integration:** a static site needs no server, no GitHub token, no sync infrastructure — and it works offline. The cost is staleness, which this packet documents as the artifact's defining trait (§4.7). The tradeoff was never revisited *anywhere in the fleet*: the Sep 21 batch proves the maintainer still operates these repos as a unit — he just refreshes their formatting, not their data [Inference, Medium on the tradeoff framing; External, High on the batch]. ## 4.2 What it is — repo TL;DR A 22 MB working tree excluding .git [Counted, High] — 7.9 MB sqlite + 7.9 MB of 1 MB chunks holding the *same bytes* + 5.3 MB vendored JS/WASM + 15,867 lines of first-party HTML/JS/CSS [Counted, High] — committed in a single 2026-03-08 commit by the maintainer, deployed to GitHub Pages by the stock `static.yml` workflow. The bundle contains: `beads.sqlite3` (1,180 issues, 1,916 dependencies, 900 comments, FTS index, precomputed `issue_metrics` and `triage_recommendations`), 8 content-hashed chunks for progressive browser loading via sql-wasm, `data/*.json` (precomputed health/triage/history/graph-layout), and a 15,867-line first-party frontend (Alpine.js + Tailwind + d3/force-graph + a WASM graph engine + Chart.js burndown/heatmap/pie/bar charts + mermaid, all vendored). Zero performance claims exist in the repo — a grep over all non-vendor text finds only a "faster settling" layout-animation comment [Code-verified, High]. One-line verdict: **a faithful, carefully engineered, offline-first export of a bead journal that is now a museum piece — its headline calls it a live dashboard, its data says March, its fleet-mates got a formatting pass yesterday while their data stayed March-frozen, and its triage numbers don't recompute.** (NODUS: Monitor — see §4.9.) ## 4.3 Repo facts (claim inventory) Every claim below was verified against the pinned commit on 2026-09-22. | # | Claim | Status | Evidence | Tier, Confidence | |---|-------|--------|----------|------------------| | 1 | 1,180 issues; 853 closed (72.3%); 1,916 dependencies; 900 comments | demonstrated | `SELECT count(*)` on `issues`/`dependencies`/`comments`; status split 853/224/96/7 matches `project_health.json` exactly; 853/1180 = 72.29% → README "72%" | [Counted, High] | | 2 | Export generated 2026-03-09T00:19:55Z by `bv --pages`, committed by the maintainer | demonstrated | `export_meta` + `data/meta.json` agree to the second; README footer "Generated Mar 8, 2026 at 7:19 PM CDT by bv" (= 00:19 UTC Mar 9); commit "Deploy static site via bv --pages" authored by Dicklesworthstone | [Code-verified + Git-observed, High] | | 3 | The 8 chunks reassemble byte-exact to the committed sqlite | demonstrated | `sha256(cat chunks/*)` = config hash `365559cc…` = `sha256(beads.sqlite3)`; per-chunk sizes match the manifest (7×1,048,576 + 587,776) | [Verified, High] | | 4 | The database is shipped twice (16 MB, undocumented duplication) | demonstrated | `beads.sqlite3` (7,927,808 bytes) and `chunks/` (7,927,808 bytes) hash identically; the Pages site loads only the chunks (wasm_loader/sql.js path); no README note explains the duplication | [Verified, High] | | 5 | Dependency graph is acyclic ("Cycles: None detected ✓") | demonstrated | Independent Python DFS over all 1,916 edges / 839 nodes: no back edge | [Counted, High] | | 6 | "View Live Dashboard" — the dashboard is live | disproven (stale) | Data frozen at export (max `updated_at` 2026-03-08T23:53:41Z, 26 min before export); 197 days old at assessment [Counted, High]; all 1,180 issues now closed in the live journal [Verified, High] | | 7 | README: 264 blocked / 63 ready to work | stale (unreproducible — systematically) | Recomputed from the shipped DB: 251 blocked / 76 ready under unmet-dependency semantics; 286 / 41 under the DB's own `issue_metrics.blocked_by_count`; the README's 264/63 matches neither. A sibling check upgrades this from one-off to systematic: `beads-for-frankentui` (same generator) shows README 157/47 vs recomputed 144/60 — the identical +13 offset in an independent journal, on *both* sides (blocked +13 and ready +13, ruling out percentage-based definitions and pointing to a fixed reclassified set) — a definitional delta in `bv`'s triage computation rather than random drift | [Counted, High] | | 8 | `issue_metrics.blocked_by_count` counts unmet blockers | disproven (misnamed column) | Sampled rows: `blocked_by_count` = total dep-edge count including edges on *closed* issues (e.g. `bd-117`: count 1, unclosed deps 0) | [Counted, High] | | 9 | README "Health Warning: More issues are blocked than actionable" | demonstrated (true under every definition) | 264>63 (README), 251>76 (recomputed), 286>41 (issue_metrics) — the warning survives the triage-number dispute | [Counted, High] | | 10 | Top-priority impact scores (0.35 / 0.30 / 0.29) | demonstrated (as generated values) | Round correctly from `triage.json` (0.3534/0.2965/0.2939); the *meaning* of the scores is unvalidated — no ground truth exists in-repo | [Counted, High] | | 11 | Full-text search over the journal works offline | demonstrated | `issues_fts` holds 1,180 docs; `MATCH 'cranelift'` → 1 row; `viewer.js` references `issues_fts` 8× (search path wired) | [Verified + Code-verified, High] | | 12 | Hybrid scorer self-test passes | demonstrated | `hybrid_scorer.test.js` executed under node (window shim): "HybridScorer tests passed" | [Verified, High] | | 13 | Fully self-contained for offline use (CSP comment) | partially demonstrated | All libraries vendored locally and loaded from `./vendor/` first — but `viewer.js` L363/379 carries a pinned jsdelivr CDN fallback for sql.js if the local load fails; 2 external URLs total (jsdelivr, caniuse) | [Code-verified, High] | | 14 | Time-travel: commit→beads history view | demonstrated (existence; animation not executed) | `data/history.json`: 48 commits with `beads_added` lists; `graph.js` L3236 "TIME-TRAVEL ANIMATION (bv-z38b)"; `viewer.js` loads `history.json` optionally | [Code-verified, High] | | 15 | Graph analytics precomputed (PageRank, betweenness, critical path, k-core, HITS) | demonstrated (values present; UI hydration not executed) | `issue_metrics` columns populated for all 1,180 issues; `data/graph_layout.json` (20,656 lines: positions/metrics/links); the live page shell renders metric-explainer sections (hydration untested) | [Code-verified, High] | | 16 | Charts module: burndown, label heatmap, priority pie, type bar | demonstrated (code read; not rendered) | `charts.js` header: "bv Charts Dashboard Module (bv-wb6h)" — `initBurndownChart`, `computeBurndownData`, priority/type charts via vendored Chart.js | [Code-verified, High] | | 17 | COOP/COEP service worker enables WASM threads on Pages | demonstrated (code read; not executed) | `coi-serviceworker.js`: sets `Cross-Origin-Embedder-Policy: credentialless` + `Cross-Origin-Opener-Policy: same-origin`; "SharedArrayBuffer is required by sql.js WASM"; based on nicobrinkkemper/coi-serviceworker (MIT) | [Code-verified, High] | | 18 | Graph WASM engine loads with JS fallback; scorer WASM never fires here | demonstrated (code read; not executed) | `viewer.js` L692 dynamically imports `./vendor/bv_graph.js` in try/catch (falls back to JS force-graph); `wasm_loader.js` gates the *scorer* WASM (`./wasm/bv_hybrid_scorer.js`) at 5,000 issues AND no `wasm/` dir exists in the bundle — at 1,180 issues the scorer is always the JS `HybridScorer` | [Code-verified, High] | | 19 | `graph-demo.html` is an orphaned dev leftover | demonstrated | Zero references from index.html/viewer.js/graph.js; imports `'../../../bv-graph-wasm/pkg/bv_graph_wasm.js'` — a path existing only in the `bv` repo checkout, not this bundle | [Code-verified, High] | | 20 | No LICENSE file; GitHub license detection null | demonstrated | `find -iname '*license*'` empty (excluding .git); GitHub API `license: null`; no license text in index.html/viewer.js footers; the shipped frontend carries `bv`'s bead-ID comments (`bv-z38b`, `bv-wb6h`) with no license notice | [Code-verified + External, High] | | 21 | The snapshot is FrankenEngine's journal | demonstrated | All 1,180 snapshot IDs resolve in franken_engine's current `.beads/issues.jsonl` (4,537 records, ID namespaces match: bd-1lsy/bd-mjh3/bd-2mds) | [Verified, High] | | 22 | FrankenEngine's journal has grown to 4,537 beads (3,911 closed / 626 open) | demonstrated | Sparse clone 2026-09-22: 4,537 JSONL records; status split counted; new namespaces (bd-perfo 466, bd-cixqu 274) absent from the March snapshot | [Counted, High] | | 23 | Single-commit repo; CI is only the stock Pages deploy (2 runs, green at pin) | demonstrated | `git log` = 1 commit; Actions API: 2 runs total, both `static.yml`/pages-deploy at `50e2709`, both `success` | [Git-observed + CI-observed, High] | | 24 | This is one of 8 dashboard repos; the stalest push of the fleet, and one of three single-commit members | demonstrated | User repo list + commit counts 2026-09-22: 8 `beads*` dashboard repos (tools/ports excluded); three received an identical *formatting-only* batch commit 2026-09-21 (data still March-frozen per `export_meta`); this repo's 2026-03-09 push is the oldest | [External, High] | | 25 | FrankenEngine's README does not link the dashboard | demonstrated | grep of the upstream README for dashboard/github.io/beads_for_franken: zero hits (only unrelated "replay dashboards") | [Code-verified, High] | **What the inventory says in aggregate:** claims about *data fidelity* (counts, hashes, acyclicity, search, WASM wiring) verify at High confidence; claims about *liveness and triage* ("Live Dashboard", 264/63) fail against the repo's own database. The fleet finding (24) reframes the staleness: not "the maintainer doesn't regenerate dashboards" but "he regenerates everyone else's." The generator's export pipeline disagrees with itself (claims 7 vs 8) — a governance signal about `bv`, not just this snapshot. ## 4.4 Codebase tour **Topology (first-party, [Counted, High]):** `index.html` (4,134 lines — Alpine.js app shell, CSP meta, vendored script tags), `viewer.js` (3,510 lines — sqlite/chunk loading, search, triage panels, graph-WASM bootstrap), `graph.js` (3,847 lines — force-graph rendering, time-travel animation), `charts.js` (761 lines — burndown/burnup, label heatmap, priority pie, type bar via Chart.js), `wasm_loader.js` (154 lines — hybrid JS/WASM scorer bootstrap), `hybrid_scorer.js` (88 lines — client-side graph-aware search ranking, "mirrors pkg/search/hybrid_scorer_impl.go normalization logic"), `hybrid_scorer.test.js` (45 lines — console IIFE self-test, not wired to CI), `styles.css` (2,374 lines), `graph-demo.html` (863 lines — orphaned; imports a `bv`-repo-local path), `coi-serviceworker.js` (136 lines — COOP/COEP for SharedArrayBuffer), `data/*.json` (graph_layout 20,656 lines; triage 794; history 693; project_health 76; meta 7), `beads.sqlite3` + `chunks/` (identical 7.9 MB), `.github/workflows/static.yml` (stock Pages deploy). **Vendored third-party (5.3 MB, not counted as first-party):** alpine, tailwindcss, d3.v7, force-graph, chart.umd, mermaid, marked, dompurify, sql-wasm (+.wasm), bv_graph.js + bv_graph_bg.wasm (217 KB — wasm-bindgen graph engine), two woff2 fonts. No license attributions shipped for any vendored lib; no SRI hashes [Code-verified, High]. **Data flow, end to end:** Pages serves the static bundle → `index.html` boots Alpine → `coi-serviceworker.js` adds COOP/COEP so sql.js WASM gets SharedArrayBuffer → `viewer.js` fetches the 8 chunks per `beads.sqlite3.config.json`, reassembles them in memory, instantiates sql-wasm (local `./vendor/sql-wasm.js` first, pinned jsdelivr fallback on failure) → queries run against the in-browser sqlite (FTS search, triage panels, issue detail) → `graph.js` renders the dependency graph using precomputed positions from `data/graph_layout.json`, with `bv_graph_bg.wasm` attempted via dynamic import (try/catch → JS force-graph fallback) → `charts.js` draws burndown/heatmap/pie/bar from the issues table → `data/history.json` (48 commits → `beads_added`) drives the time-travel animation. The scorer path: `wasm_loader.js` tries `./wasm/bv_hybrid_scorer.js` only for journals ≥5,000 issues — the `wasm/` directory doesn't exist in this bundle, so at 1,180 issues scoring is always the JS `HybridScorer` [Code-verified, High]. No network calls beyond same-origin fetches on the happy path. **Dependency posture:** zero runtime dependencies beyond the vendored files — no package.json, no build step, no Cargo/Rust anywhere (`find` for Cargo.toml/*.rs: empty). The asupersync question is vacuous for this repo [Verified, High]. The supply-chain surface is the vendor directory: 15 pinned files, no integrity hashes, no license files. **The sqlite schema (verified by PRAGMA):** `issues` (11 cols: id/title/description/status/priority/issue_type/assignee/labels/created_at/updated_at/closed_at), `dependencies` (issue_id/depends_on_id/type, all 1,916 type='blocks'), `comments` (900 rows), `export_meta`, `issue_metrics` (pagerank/betweenness/critical_path_depth/triage_score/blocks_count/blocked_by_count), `triage_recommendations` (10 rows — the README's top-10), `issues_fts` (+ shadows). Notably absent vs the upstream journal: `created_by`, `close_reason`, `estimated_minutes`, `design`, `acceptance_criteria` — the export is a *projection*, not a full dump [Code-verified, High — column sets compared against franken_engine's live issues.jsonl keys]. ## 4.5 The maintainer's stated case (and the benchmark analogue) **The pitch, such as it is:** the repo makes **zero** performance claims — a grep over all non-vendor text finds only a "faster settling" layout-animation comment [Code-verified, High]. There is no benchmark table to audit, which is itself a contrast with its siblings. The closest analogues to "benchmarks" are the *triage analytics*: impact scores, PageRank, "Top Priorities", "Critical Bottlenecks", "Quick Wins". Their methodology: `hybrid_scorer.js` documents its normalization (weights: text 0.40, pagerank 0.20, status 0.15, impact 0.10, priority 0.10, recency 0.05; presets for bug-hunting/sprint-planning/impact-first/text-only) and claims to mirror `pkg/search/hybrid_scorer_impl.go` in `bv` [Maintainer claim, Medium — the Go source was not diffed against the JS port]. **Audit of the triage numbers:** the scores are *internally consistent* (README rounds triage.json correctly; the top-3 unblocks-lists match the DB's dependency edges) but *externally unvalidated* — no ground truth, no A/A, no holdout. The load-bearing finding is claim 7: the headline 264/63 reproduces under no definition from the shipped database. A sibling check upgrades it from one-off to systematic: `beads-for-frankentui` (12★, same generator, cloned 2026-09-22) shows README 157/47 vs recomputed 144/60 — the identical +13 offset in an independent journal, on *both* sides (blocked +13 and ready +13), which rules out percentage-based definitions and points to a fixed reclassified set rather than noise. For a dashboard whose job is telling a team what to work on next, an irreproducible triage number is the single most damaging defect — and it appears to be a property of the generator, not of this snapshot [Counted, High on the numbers; Inference, Medium on the generator-level reading]. **What would survive an independent rerun:** the counts (1,180/853/1,916/900 — all reproduced), the acyclicity (reproduced), the chunk hashes (reproduced), the FTS behavior (reproduced). What would not: 264/63, and any reading of the impact scores as validated prioritization. ## 4.6 Competitors The incumbent wins on liveness; this artifact doesn't compete — it complements, then expired. - **GitHub Issues / Projects (the system of record):** owns the live-tracker lane completely — write path, notifications, assignees, real-time state. This dashboard has no write path and 197-day-old reads. Any user who needs current state uses GitHub; the dashboard is not an alternative [Inference, High]. - **bv's own TUI (1,691 stars, pushed 2026-09-21/22):** owns the *bead-journal analytics* lane — PageRank, critical path, kanban, dependency graph — live, against the working journal. The static export is its frozen shadow: same analytics, none of the freshness. The 563× star ratio (1,691/3 [Counted, High]) between generator and output says where the community's attention is [Inference, Medium on the attention reading]. - **The sibling dashboards (the fleet):** `beads-for-frankentui` (12★) and `beads_for_cass` (4★) received a code-formatting batch commit 2026-09-21 — they are *this same product*, equally data-frozen (their exports are also March-dated). The lane "static bead-journal dashboard" is occupied by the maintainer's own newer-formatted instances; this repo is the one the batch didn't touch at all [External, High]. - **Linear / Jira dashboards:** own the "shareable project health" lane for teams that live in those tools; relevant only as proof that the *lane* (a URL showing project health) is real and occupied [Inference, Medium]. - **Demand-side check:** FrankenEngine's own README does not link this dashboard (claim 25), and no inbound link was found. The dashboard has no measurable audience beyond its 3 stars [Code-verified + External, High]. - **Unoccupied lane:** portable, offline, zero-backend *journal publishing* — a bead journal as a queryable sqlite artifact anyone can download, diff, and backtest without GitHub access. Nothing else in the ecosystem ships the journal *as data*. This repo demonstrates the pattern (and its failure mode: publish once, rot forever) [Inference, Medium]. ## 4.7 Skeptic's take Weaknesses, each substantive: 1. **[FATAL] "Live Dashboard" is false advertising the data itself refutes.** The README's two calls-to-action both say live/interactive dashboard; the data is a 2026-03-08 export; all 1,180 tracked issues are closed in the current journal. A dashboard whose entire tracked universe is completed is not a dashboard — it's an archive mislabeled at the door [Verified, High]. 2. **[HIGH] The triage numbers don't recompute — from the generator's own database.** 264/63 (README) vs 251/76 (unmet-dep recomputation) vs 286/41 (the DB's own `issue_metrics`). For a project whose thesis is *evidence you can check*, shipping three answers to "how many are blocked" is a credibility wound, and the misnamed `blocked_by_count` column (counts closed-dep edges too) suggests the confusion is in `bv`'s pipeline, not just this snapshot [Counted, High]. 3. **[HIGH] No license file — and the frontend is someone else's rider-licensed code.** The 7.9 MB dataset is all-rights-reserved by default; worse, the shipped `viewer.js`/`graph.js` are `bv`'s code (bead-ID comments `bv-z38b`, `bv-wb6h`) distributed with no license notice, where `bv`'s license requires Derivative-Work distributions to carry its rider unmodified (§4.8). The backtesting use case (§4.11, next-step 1) is legally murky until this is fixed [Code-verified, High; legal reading Inference, Medium]. 4. **[MEDIUM] No regeneration path.** No script, no Makefile, no CI job, no recorded `bv` version — reproducing this export requires guessing the generator version and re-running it by hand. The fleet proves the maintainer still *touches* these repos — a 2026-09-21 batch commit reformatted three siblings' code — but no fleet member's data has been re-exported since March; this repo missed even the cosmetic pass [Code-verified + External, High]. 5. **[MEDIUM] The database is shipped twice, undocumented.** `beads.sqlite3` and `chunks/` are byte-identical (7.9 MB each, hash-verified). The root sqlite is presumably the analyst-friendly artifact and the chunks the deployment artifact — but no README note says so; a fairer reading than "waste" is "undocumented duplication" [Verified, High]. 6. **[MEDIUM] Single commit, bus factor 1, zero maintenance — and the upstream doesn't link it.** One commit in 197 days; the generator moved on (pushed 2026-09-22), the journal moved on (3.8× growth), the export didn't; FrankenEngine's README doesn't reference it. There is no one to page when the Pages deploy breaks, and no audience to notice [Git-observed + External + Code-verified, High]. 7. **[LOW] Vendored supply chain without attributions; orphaned demo page.** 16 third-party files, no license texts, no SRI hashes; `graph-demo.html` imports a `bv`-repo-local path and is linked from nowhere. Low risk for a static dashboard, but the CSP's "fully self-contained" framing coexists with a CDN fallback — the offline story has an asterisk [Code-verified, High]. **Bear-case steelman (strongest counter-case):** this is a build artifact that escaped into git — a `bv --pages` demo output committed for convenience, not a product. Its headline promise ("Live Dashboard") is falsified by its own database; its triage numbers don't recompute from its own sqlite; its dataset is unlicensed and its frontend is rider-licensed code shipped without the rider; its upstream journal has grown 3.8× past it; the upstream README doesn't link it; and the maintainer's 2026-09-21 batch run reformatted three siblings' code while leaving every dashboard's data March-frozen — and skipped this repo entirely. The rational response is to treat the repo as a March fossil: useful as a backtesting dataset (every outcome is now known), useless as a dashboard, and not worth a second commit unless the export becomes scheduled CI. [Inference, Medium — deliberately uncharitable; the counter-evidence is the export's genuine data fidelity and offline-first engineering, §4.4.] ## 4.8 License and governance (material, not boilerplate) **License: none.** No LICENSE file exists in the tree (`find -iname '*license*'` empty outside .git); GitHub's license detection reports `null`; no license text appears in the site's HTML/JS footers. Default: all rights reserved — though in practice GitHub's Terms give viewers fork/view rights on public repos, which softens but doesn't resolve reuse of the dataset [Code-verified + External, High; the Terms point is Inference, Medium]. **The rider, quoted to its exact scope** (from `beads_viewer`'s LICENSE, read verbatim — this repo does not carry it, its generator does): - **Restricted parties:** "OpenAI, L.L.C.; Anthropic, PBC; any of their respective Affiliates; and any person or entity acting directly or indirectly on behalf of, for the benefit of, or under the direction of any of the foregoing (including any officer, director, employee, contractor, agent, consultant, service provider, or representative)." - **Grant:** "no rights are granted to any Restricted Party" without "the express prior written permission of Jeffrey Emanuel." - **Scope:** bars providing, disclosing, distributing, sublicensing, selling, leasing, lending, hosting, making available, or otherwise permitting access to "the Software or any derivative work of the Software (as defined in applicable copyright law) (collectively, 'Derivative Works')" to or for any Restricted Party. - **"Use" is defined expansively** — "copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, benchmarking, testing, analyzing, indexing, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems." - **Propagation:** "This rider applies to the Software and all Derivative Works… any distribution of the Software or any Derivative Works must include this rider provision unmodified." - **Remedy:** breach "automatically and immediately terminates" the permissions; injunctive/equitable relief plus attorneys' fees; "Affiliate" = >50% voting control. - **Classification:** non-OSI, source-available (fails OSD §5 named-party discrimination and §6 field-of-endeavor — the benchmarking/analyzing/training bar) [Inference, High — legal conclusion, not legal advice]. **The compliance gap this creates:** this repo distributes `bv`'s frontend code (viewer.js/graph.js/charts.js carry `bv` bead-ID comments: `bv-z38b`, `bv-wb6h`) with *no license notice at all* — where the license governing that code requires Derivative-Work distributions to carry the rider unmodified. Whether a `bv --pages` export counts as a "Derivative Work… as defined in applicable copyright law" is unaddressed by either repo; the observable fact is the requirement travels with the code and the code traveled without it [Code-verified, High on the absence; the legal characterization is Inference, Medium — not legal advice]. **Governance:** bus factor 1, one commit, no contribution path, no succession, no review (nothing to review — a single generated commit). Commit velocity is zero by construction; the "project" here is the generator, not the repo. ## 4.9 NODUS factsheet | Criterion | Score | One-line justification | |---|---|---| | Technology readiness | **TRL 7** | Deployed static system serving on GitHub Pages (both deploy runs green at the pin); content frozen 197 days — a working site tracking a dead snapshot. Not TRL 8: never validated *as a live tracker* (its headline claim), and in-browser hydration is untested [Inference, Medium] | | Strategic relevance | 2/5 | The *export pattern* (portable, offline, zero-backend journal publishing) is relevant to the program's evidence machinery; this instance tracks nothing live [Inference, Medium] | | Impact potential | 2/5 | As a dashboard: zero (all issues closed, upstream doesn't link it). As a labeled backtesting dataset for triage heuristics (every outcome now known): real but unlicensed [Inference, Medium] | | Implementation feasibility | 4/5 | Static site — trivially forkable/deployable; regeneration needs `bv` at an unrecorded version [Inference, Medium] | | Time to mainstream | 1/5 | Frozen artifact; the live lane belongs to `bv`'s TUI and GitHub Issues — there is no adoption path for this instance [Inference, Medium] | | Collaboration potential | 1/5 | No license, no contribution path, single commit, stale data — nothing to collaborate on [Inference, Medium] | **Ring: Monitor** [Inference, High]. The Rulebook's Monitor rule names "websites, retired artifacts, and plan-stage work" — this repo is a website *and* a retired artifact, with no doubt to ring down from. No Rulebook amendment; v1.0 stands. The thing to monitor is the *generator* (`bv`) and the *fleet*, not this output. **Methodology fit (for the FrankenSuite):** adopt the pattern, not the instance — the export bundle format (sqlite + precomputed analytics + chunked WASM loading + `export_meta` provenance + hash-manifested chunks) is a directly importable template for publishing any repo's evidence as a portable, checkable artifact. Do not depend on this dashboard's data: it is 197 days stale and its triage numbers don't recompute. If the program wants live bead-journal visibility, it should schedule `bv --pages` in CI — nobody has done this in 197 days, and the fleet's style-only batch shows the maintainer already operates these repos as a unit, so the missing piece is data cadence, not tooling [Inference, High]. ## 4.10 Wardley placement Placing the *components*, not the repo: - **Commodity — GitHub Pages hosting, the vendored JS/WASM libraries, the stock `static.yml` deploy, the COOP/COEP service-worker trick.** Table stakes; move right only if GitHub changes Pages (it won't for this) [Inference, High]. - **Custom-built, approaching Product — the export bundle itself** (sqlite + precomputed PageRank/betweenness/triage + FTS + chunked loading + `export_meta`). It is the most *executed* pattern in the repo — produced by `bv --pages` across an 8-repo fleet, consumed by any browser — but as an instance it is frozen. Moves right if regeneration becomes scheduled CI; otherwise it stays a one-shot artifact [Inference, Medium]. - **Custom-built at fleet scale — the 8-repo dashboard fleet as a unit.** The maintainer operates the fleet as a single surface (the identical 2026-09-21 style commit landed on three repos at once) — but the maintenance is cosmetic: code, not data. The fleet pattern would move right if *data* re-exports were batched on the same cadence [Inference, Medium]. - **Genesis — the time-travel bead-archaeology view and the labeled backtesting dataset.** Commit→beads animation over a journal whose every outcome is now known is a combination no incumbent offers: GitHub has no "replay the project's March" view, and no triage heuristic has a public labeled dataset to be tested against. Moves right if the backtest (next-step 1) or the archaeology study (next-step 5) is run and published; stagnates as an unlicensed curiosity if not [Inference, Medium]. **Residual product gaps:** no write path (read-only by design); no sync or refresh; no recorded generator version (reproducibility gap); the export is a lossy projection (upstream journal fields like `created_by`, `close_reason`, `acceptance_criteria` are dropped — the dataset is lossy vs the source) [Code-verified, High on the projection]; vendored libs without license attributions; the scorer-WASM path is dead code in this bundle (threshold + missing `wasm/` dir). ## 4.11 Trajectory (12 / 24 / 60 months) All horizons **[Inference]** — forecasts, not findings; confidence Low unless noted. **12-month base case [Inference, Medium]:** nothing changes. The Pages site keeps serving the March snapshot; no second commit lands; the journal keeps growing elsewhere. The fleet's code keeps getting batch-maintained; the data stays frozen fleet-wide. The site's value as a dashboard stays at zero; its value as a backtesting fossil persists as long as the sqlite remains downloadable. **24-month base case [Inference, Low]:** one of two shapes. Either someone runs next-step 1 (the backtest) and the repo gains a second life as a cited dataset — or link rot sets in (Pages URL conventions, the pinned jsdelivr sql.js fallback, vendored CDN-era code) and even the fossil gets harder to use. The base case leans toward quiet persistence: static sites are cheap to ignore. **60-month base case [Inference, Low]:** the repo is either a historical curiosity ("this is what FrankenEngine's journal looked like in March 2026") or deleted. The export *pattern* survives inside `bv`, which is where the maintenance happens. **Bifurcation — what the upside requires:** (a) scheduled regeneration in CI (revisit trigger 1); (b) a LICENSE (trigger 2); (c) the triage-number reconciliation (trigger 5). Any one of the three makes the repo a living artifact again; all three make it a template worth copying. **Bifurcation — what decay looks like:** already here. Decay for a static export isn't bit-rot, it's relevance-rot: the journal outgrew it 3.8× and closed every issue it tracks. Further decay is the Pages deploy breaking or the repo being archived — both observable. **Revisit triggers (observable, falsifiable):** 1. **A second commit lands** (re-export or CI schedule) — `git log` count > 1. Flips the fossil judgment. 2. **A LICENSE file appears** — flips the dataset-reuse judgment. 3. **`bv --pages` emits a generator version + verification queries** — flips the reproducibility judgment (check `export_meta` for a `bv_version` key). 4. **A data re-export lands** — `export_meta.generated_at` advances past March 2026. Flips the fossil judgment. 5. **The README's 264/63 is corrected or reproduced** — a documented SQL query reproduces the headline numbers. Flips the triage-credibility judgment. 6. **The backtest or archaeology study is published** (next-steps 1, 5) — triage scores vs actual close order. Flips the dataset from curiosity to evidence. 7. **Pages deploy breaks or the repo is archived** — the decay sensor for a static site: stays Monitor, treat as retired permanently. ## 4.12 Limitations and open questions (mandatory) **What was not done:** the site was never loaded in a real browser — WASM graph init, chunk reassembly in-browser, the time-travel animation, charts rendering, and mobile behavior are code-verified, not executed. The viewer was never pointed at the sqlite end-to-end. The JS hybrid scorer was not diffed against `bv`'s Go original (`pkg/search/hybrid_scorer_impl.go`). The maintainer was not contacted. Vendored third-party licenses were not audited. `graph-demo.html` was not rendered (it's orphaned). Demand-side research beyond star counts and the upstream-README link check was not performed. The other seven fleet dashboards were not cloned (their freshness was read from the API only). **Open questions that would most change the verdict, in order of load-bearing weight:** 1. **Does the site actually hydrate in a modern browser?** The shell renders (fetched 2026-09-22), but the 8-chunk WASM load path, the force-graph, charts, and the time-travel animation are unexecuted. A broken hydrate would drop TRL 7 → 4. 2. **What `bv` version generated this, and does it still reproduce?** No version recorded; a re-export attempt would settle whether the 264/251/286 split is a pipeline bug or a definition gap. 3. **What is the exact blocked/ready definition?** Answering this (from `bv`'s Go source at the right version) resolves claim 7 — the packet's sharpest finding. 4. **Is the dataset intended to be reusable, and does the rider travel with the frontend?** A LICENSE answers the first; the second needs a legal reading of whether a `--pages` export is a Derivative Work. 5. **Why was this repo left out of the 2026-09-21 style batch?** Deprioritized, forgotten, or deliberately frozen as a showcase — the answer changes §4.1's "abandoned" to something more precise, but not the ring. --- ## Deepening questions — Rulebook §5's binding eight, one paragraph each **1. Provenance.** The bundle records *what* and *when* but barely *who*: `export_meta` stamps `generated_at` (2026-03-09T00:19:55Z), counts, and `schema_version`, and the README footer names the generator (`bv`) — but no `bv` version, no exporting user, no source-journal commit hash [Code-verified, High]. `data/history.json` maps 48 git commits to `beads_added` lists, which is genuine provenance-of-arrival for the March window [Code-verified, High]. What the export drops is provenance-of-authorship: the upstream journal's `created_by` field doesn't survive into the sqlite's `issues` table, so the published artifact can't answer "who filed this" [Code-verified, High — column sets compared]. Portable attestation would require the export to record the generator version, the source journal's head hash, and a signature over the chunk manifest — the manifest already hashes every chunk, so signing it is a small step the pipeline never took [Inference, Medium]. **2. The embeddable unit.** The smallest useful piece adoptable without the whole repo is the *export bundle format itself*: a sqlite database + `export_meta` + hash-manifested 1 MB chunks + a sql-wasm loader — a recipe for publishing any dataset as an offline-first, zero-backend, queryable site, with the chunking solving the "browsers dislike giant single-file downloads" problem [Inference, Medium]. Cheaper still: `hybrid_scorer.js` (88 lines, self-tested, no dependencies beyond `window`) is a drop-in graph-aware ranking function for any issue list [Code-verified, High]. Adoption cost for the bundle format: copy `wasm_loader.js`'s chunk-reassembly logic and the `beads.sqlite3.config.json` manifest schema — both plain, readable, no build step [Inference, Medium]. The sqlite *schema* (issues/dependencies/comments + FTS + metrics) is the third candidate: any beads-compatible tool could read the 7.9 MB file directly today, no browser required [Verified, High]. **3. Unexercised option value.** Three held capabilities. First, the FTS index: 1,180 documents of full-text search ship in the bundle and the search box is wired to it — but the export also carries 900 comments and full descriptions, meaning the static site is one query away from being a *research corpus* (e.g., "how did the IFC-labels epic get argued?"), a use the dashboard UI never surfaces [Code-verified, High]. Second, the precomputed metrics (PageRank, betweenness, critical-path depth for every issue) are displayed as panels but never *joined* against outcomes — the close-order backtest (next-step 1) and the bottleneck-precision study (next-step 5) are the unexercised analyses the data is begging for [Inference, Medium]. Third, the graph WASM engine (`bv_graph_bg.wasm`) is genuinely attempted with JS fallback — but the *scorer* WASM path is dead code in this bundle (5,000-issue threshold plus a missing `wasm/` directory), so the "hybrid" in `wasm_loader.js` is JS-only here; a larger journal would exercise it [Code-verified, High]. What unlocks each: a corpus-search UI, someone running the correlations, and a bigger journal. **4. Benchmark honesty.** There are no performance numbers in this repo — the honest finding, grep-verified [Code-verified, High]. The numbers that would survive an independent rerun are the *counts*: 1,180 issues, 853 closed, 1,916 dependencies, 900 comments, 0 cycles — all reproduced from the shipped sqlite in seconds [Counted, High]. The numbers that would not: the README's 264 blocked / 63 ready (no definition reproduces them) and the impact scores (heuristic, unvalidated, generator unversioned). Which numbers are load-bearing for the thesis? The thesis here isn't "we're fast" — it's "this export faithfully represents the journal." The load-bearing numbers are the counts and the hashes, and they hold; the triage scores are decorative until backtested, which is exactly what next-steps 1 and 5 propose [Inference, Medium]. **5. The governance path.** There is no governance path because there is no project — it's a single generated commit. The credible route to institutional durability runs through the *generator* and the *fleet*, not the repo: `bv` (1,691 stars, pushed 2026-09-22) is the maintained software, and the identical 2026-09-21 style commit across three siblings proves the maintainer operates these dashboards as a fleet — code, not data [External, High]. What breaks first if velocity decays: the fleet's refresh cadence — this repo is the canary that already stopped singing. The failure mode to watch is external: GitHub Pages policy changes, or the pinned jsdelivr sql.js fallback disappearing (the local vendored copy mitigates this) [Inference, Medium]. If the dashboard matters, the fix isn't governance of this repo — it's a scheduled `bv --pages` CI job (next-step 2), which moves the maintenance burden to automation [Inference, High]. **6. The license as strategy.** The rider excludes exactly: OpenAI, L.L.C.; Anthropic, PBC; their affiliates (>50% voting control); and anyone "acting directly or indirectly on behalf of, for the benefit of, or under the direction of" them — from *`bv`'s* software — barring "use" defined expansively (copying … benchmarking, testing, **analyzing, indexing** … incorporating into datasets, training corpora, evaluation harnesses, or pipelines for machine learning) [Code-verified (bv LICENSE verbatim), High]. But this repo's strategy is the absence of strategy: no LICENSE file, no terms, no rider — the output of a rider-licensed tool published under nothing, even though the rider demands that distributions of Derivative Works carry it unmodified. Does the exclusion serve or sabotage the mission? For `bv`, the defensive intent (keeping 1,691 stars of graph-analytics code out of rival training corpora) is legible; for *this repo*, the missing license sabotages the most valuable thing in it — the 7.9 MB dataset — by leaving reuse legally ambiguous, and the undistributed rider on the shipped frontend is a compliance gap, not a strategy [Inference, Medium]. The irony the packet keeps: the program's evidence-first ethos produced an evidence artifact nobody is cleanly licensed to reuse. **7. Agent-era fit.** The concrete agent workload that would pick this up is *retrospective analysis*: an agent reconstructing what FrankenEngine's March 2026 program looked like — which epics were hot, what the dependency structure was, how triage scored vs. what actually closed first. The sqlite + history.json + closed_at timestamps are a complete, queryable, offline fossil record — no GitHub token, no API pagination, no rate limits [Inference, Medium]. What would have to become true first: a LICENSE (the analysis output inherits the dataset's murk), and ideally the backtest (next-step 1) establishing whether the triage scores meant anything. The live-tracking workload would *not* pick this — it would query the journal or GitHub directly; staleness disqualifies the dashboard, not the dataset [Inference, Medium]. **8. The kill test.** The single experiment that falsifies the core thesis — "a static export is a useful live project dashboard" — has already run: compare the export against the live journal. Result: 197 days stale, all 1,180 tracked issues closed, journal grown 3.8× (1,180 → 4,537), headline triage numbers unreproducible, upstream README doesn't link it, and the maintainer's own 2026-09-21 batch commit touched three siblings' code and skipped this repo entirely. The thesis is falsified by the artifact's own data, not by a critic [Verified, High]. The surviving thesis — "a static export is a useful *frozen* dataset" — has its own kill test: attempt regeneration with current `bv`. If the export reproduces (same schema, same counts from the same journal state), the pattern is sound and this instance just needs scheduling; if the triage numbers still don't recompute, the generator's analytics are unsound and the fossil's decorative panels should be read as such [Inference, Medium].