01 · What it is
What the site is, and why it exists
This repo is not the kernel. It is the brochure. A Next.js marketing and documentation site for FrankenTUI, the Rust TUI kernel, live at frankentui.com. The README's FAQ says it outright: "Is this the kernel repo? No."
It exists for one structural reason. The kernel lives in a terminal. You cannot see what it does without cloning a Rust workspace and running a nightly toolchain, and most evaluators will never do that. So the site is the adoption funnel: screenshots, demo videos, architecture pages, and, at the center, a live demo that runs the actual kernel inside your browser through WebAssembly. Its audience is developers evaluating Rust TUI frameworks who want to judge the kernel without installing anything.
It matters for a narrower reason. Most open-source project sites assert. This one tries to prove. The WASM demo is pinned to a kernel commit hash, and the forensic pages ship the actual datasets behind the project's claims. That makes it a case study in a pattern worth stealing: evidence publishing as a website.
02 · Why build it
Why build it this way
The logic, as the maintainer's design implies rather than states outright, is that a kernel you cannot see will not be tried. The in-browser WASM demo lowers the trial cost to zero. And the evidence-forward design is executed rather than marketed: datasets shipped with provenance metadata, queried in the visitor's browser with no backend, no database, no API keys to operate. The demo manifest pins the served WASM build to a kernel commit SHA with per-file hash sums and a 209-line evidence file, and the site's caching headers are deliberately designed so the manifest is never cached (a stale manifest would pin visitors to a stale hash set). Someone thought about the failure modes.
The counter-argument: it is still a brochure, and a heavy one. The checkout is 141 megabytes: 84 MB of demo video, 20 MB of WASM payload. The README itself partially disowns the weight: it is "not a 'minimal JS' aesthetic project." Governance is a hard ceiling: one maintainer, no contributions accepted (outside PRs are reviewed but never merged), bus factor (the number of key contributors who could disappear before the project stalls) 1. And the FrankenSuite's non-OSI license rider is applied here by boilerplate, barring AI labs from even analyzing a 36k-line marketing site nobody would analyze anyway. It buys signaling at the cost of shrinking the evaluator pool.
And then there is the structural weakness that no amount of evidence-forward design fixes. The hero stats are hand-edited strings in a 2,517-line content file, with no generation step and no re-derivation from the kernel they describe. The day the kernel moves, the site's claims freeze in place.
03 · What was built
What the project actually built
About 36,300 lines of TypeScript/TSX across 122 files. Nine routes, eight live, one deliberately returning a 404 (the war-stories page was retired but its files kept). Both hostnames, frankentui.com and the Vercel deployment, serve. There are no API routes, no backend, no database connection string: everything interactive is build-time data shipping.
- The
/web WASM demo. Not a mock. A static terminal demo of the actual kernel, pinned to kernel commit 20d0952, synced September 18, 2026, with per-file sha256 sums and an evidence file in the payload. The demo carries its provenance metadata, not vaporware. - The
/beads forensic page. The kernel's issue database (1,168 issues, 15 tables) shipped as a 6.1 MB SQLite file with a provenance row, queried in the visitor's browser through an in-browser SQL engine and rendered as a force-directed graph. No backend serves it; the database is reassembled client-side from six content-addressed 1 MB chunks. - The spec-evolution lab. Thirty-one versioned spec commits from the kernel's five-day sprint, diffable in the browser.
Evidence · CI status
What the project’s own CI said at the pin
the pin = the commit the assessment was pinned to.
- !And there is no CI (continuous integration: automated checks that run on every change) at all.
The uncomfortable findings
Uncomfortable finding
"60 fps via WASM + WebGPU" appears everywhere in the site's copy, and nowhere in the repo is there a methodology, a measurement, or a trace for it. It is an unmeasured target presented as a result. "12 workspace crates" was true in February; the kernel has 20. "V0.1.1 Alive on Crates.io" is wrong twice over: no crate named frankentui exists on crates.io at all, and the published crates (ftui, ftui-core, ftui-runtime) are at 0.7.0 while the workspace itself is at 0.9.0. source source source Four hero stats, zero surviving contact with September reality.
Uncomfortable finding
The forensic datasets are frozen in February and presented without an "as of" label. The issue database's provenance row says 2026-02-04; the spec dataset says 2026-02-08, but the site presents the graph as the issue graph, with no date anywhere on the page. Meanwhile the viewer code was re-vendored from a sibling repo on September 21, the day before assessment: fresh viewer, seven-month-old data. The site itself looks finished; the data underneath is stale.
Uncomfortable finding
The Playwright end-to-end and performance suites exist (twenty spec files), but nothing enforces them on push, so a kernel resync that breaks the demo would ship silently to the live site. The docs are rotting first: the AGENTS.md is a copied template for a different project (a personal site with GSAP and Three.js, neither used here), and the CHANGELOG's latest entry is from March. source
04 · Where it stands
Where it stands
In the program's terms: TRL 9 as a deployed website artifact, technology-readiness not applicable. It is a support asset, not a technology. NODUS ring: Monitor. The program's ring rules name websites for Monitor, and the factsheet agrees: there is nothing to pilot (nobody adopts a brochure) and nothing to explore (it is HTML that ships).
Technology readiness
TRL 9 on a 1-to-9 scale.
That TRL rates the deployed website artifact only; technology-readiness is not applicable — a support asset, not a technology.
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 deployed artifact at TRL 9; technology-readiness itself is not applicable: a support asset, not a technology.
- 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: 36,296 lines including tests, counted; the page fetched HTTP 200; no CI configuration in the tree.
- Tier: unassessed in packet: The Playwright suites were never executed — greenness unknown; the 60 fps claim was never instrumented.
- Tier 3 · Maintainer claim: TypeScript strictness and ESLint unexecuted.
- Tier 5 · Inference: The Monitor ring at TRL 9 (artifact): the program’s website bucket.
Should you use it?
As a visitor, it works: the routes serve and the deployment returns HTTP 200. source
As a technology, there is nothing to adopt.
Should you learn from it?
Yes, but extract the pattern and ignore the copy.
The static-forensics pattern (versioned datasets, provenance rows, client-side querying, no backend) is reusable.
What would change the verdict, in order
- hero stats derived from sources of truth at sync time instead of hand-editing
- "as of" labels rendered from each dataset's own provenance row
- CI gating the Playwright suites so demo resyncs cannot break silently
- the 60 fps claim measured or reworded to a target.
None of that requires the kernel to change. It is all site-side hygiene, which is why it is achievable.
05 · What it teaches
What this teaches about building with agents
Here is the transferable lesson, and it has two halves.
The first half is the pattern: publish the dataset your claims are computed from, with a provenance row, queryable in the browser, with no backend to operate. A versioned dataset with its own generated_at survives whether or not the product does. In a world where agents generate docs and marketing alongside code, the static-forensics pattern is a cheap way to make a project's claims checkable by strangers. It is the exportable idea here, the one with no marketing value.
The second half is the site's own failure mode, and it is the more important half. Every number the maintainer typed by hand is stale. Every dataset the pipeline generated is fresh. That is the law this repo demonstrates: hand-edited stats rot; derived stats hold. In an agent-built codebase, the prose the agents write (README claims, hero stats, comparison tables) should either be regenerated from sources of truth or carry a date stamp. source Put the date on the plaque. The site's strongest pages would convert from a drift liability into an evidence demonstration if they simply rendered their own provenance rows ("this exhibit is from February"), and its weakest claim, the 60 fps, would become its strongest if the existing Playwright performance suite were wired to any scheduler and published the number.
Polish the glass, date the exhibit. Both are cheap. One is done. The other isn't.