# FrankenTUI — Technical Due-Diligence Assessment

**The hook:** 1.12 million lines of Rust, zero `unsafe` blocks, and a public claims ledger that retracts its own rows — but the v0.9.0 release in the changelog was never tagged, published, or shipped.

**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**.

## TL;DR

FrankenTUI is a large, genuinely built terminal-UI kernel in safe Rust: 20 workspace crates, 1,124,747 lines of first-party Rust across 986 files, 87 distinct widget types, 45 interactive demo screens, a diff-based render kernel (`Buffer → BufferDiff → Presenter → ANSI`), RAII terminal teardown, first-class inline mode that preserves scrollback, resizable pane workspaces, in-tree web/WASM backends, and a Bayesian/adaptive intelligence layer (BOCPD — Bayesian online changepoint detection, e-processes — wealth-based sequential tests, conformal prediction, VOI — value-of-information — sampling) wired into resize coalescing, diff strategy, and budget alerting. Its most unusual artifact is not the kernel but the **evidence machinery around it**: a 152-row machine-checked claims ledger (`docs/claims-ledger.md`, 56 proven / 56 retracted / 34 pending-doc / 6 pending-code), five `make gates` checks (module reachability, claims proofs, env-var docs, close-audits of beads — the project's issue-tracker entries — baseline benches), a `doctor_frankentui` verification harness (194,840 lines: capture, determinism soaks, chaos drills, CEGIS (counterexample-guided inductive synthesis), concolic differential testing), shadow-run lane-migration validation, and a `slo.yaml` with machine-readable frame budgets. (Per-claim evidence tiers live in §4.3.) **TRL 6. NODUS ring: Explore.** Strongest strength: the honesty apparatus — the tree publishes its own losses (SIMD kernels that lose to scalar, an e-graph solver quarantined as 4–19× slower) and enforces the honesty with gates — everywhere except the release notes, where the phantom v0.9.0 sits. Strongest ceiling: governance — the CHANGELOG describes a v0.9.0 release (2026-09-18) that exists on no surface GitHub tags, GitHub Releases, or crates.io can see; GitHub Actions was disabled 2026-09-06 so all verification runs on maintainer-private DSR (Doodlestein Self-Releaser, the maintainer's own CI system) infrastructure invisible to outsiders; bus factor 1; and the non-OSI MIT+OpenAI/Anthropic-rider license withholds all rights — including benchmarking and analysis — from the two leading AI labs.

## Quick Links

- Repository: https://github.com/Dicklesworthstone/frankentui
- README: https://github.com/Dicklesworthstone/frankentui/blob/HEAD/README.md
- License (MIT + OpenAI/Anthropic rider, read verbatim): https://github.com/Dicklesworthstone/frankentui/blob/HEAD/LICENSE
- Changelog (scope window 2026-01-31 → v0.9.0 claim): https://github.com/Dicklesworthstone/frankentui/blob/HEAD/CHANGELOG.md
- Claims ledger (152 rows, proof grammar): https://github.com/Dicklesworthstone/frankentui/blob/HEAD/docs/claims-ledger.md
- Contributor/agent rules (DSR-only policy, test counts, gates): https://github.com/Dicklesworthstone/frankentui/blob/HEAD/AGENTS.md
- Web/WASM showcase (claimed live): https://frankentui.com/web
- crates.io `ftui` (max_stable 0.7.0, 22,442 downloads): https://crates.io/crates/ftui
- GitHub Releases (latest real: v0.8.0, 2026-09-14): https://github.com/Dicklesworthstone/frankentui/releases
- Perf writeups (method docs, incl. quarantined e-graph): https://github.com/Dicklesworthstone/frankentui/tree/HEAD/docs/perf
- SLO definitions: https://github.com/Dicklesworthstone/frankentui/blob/HEAD/slo.yaml

Link verification status: repo/README/LICENSE/CHANGELOG/claims-ledger/AGENTS.md/perf/slo.yaml paths verified present in the fresh clone [Verified, High]; releases list and tags read via GitHub API [External, High]; crates.io metadata read via crates.io API [External, High]; frankentui.com/web was **not** fetched (page fetch unavailable this run) — the domain resolves, the README claims it live, and the sibling website assessment confirms a `/web` static WASM demo exists in the website repo, but live rendering was not observed [Maintainer claim + partial external corroboration, Medium].

## Did you know?

The repo's own SIMD crate tells you not to call half of its kernels. `ftui-simd` ships safe portable-SIMD row-compare and ASCII-detection kernels, each with a scalar twin for parity testing — and its module docs state that `first_mismatch_u128` and `rows_equal_u128` are **3–4× slower** than their scalar twins, recommending only the ASCII kernels (5× at 64 bytes, 20–44× past a kilobyte), with full numbers in `docs/perf/simd_kernels_2026-09-18.md` [Verified in source + perf doc exists, High]. Publishing the benchmark you lose, in the doc comment of the code that loses it, is the project's honesty culture in miniature.

## Franken-worthy next steps

These are research directions, not engineering tickets: each is novel, specific, falsifiable, and backed by rigor this project has already demonstrated.

1. **Export the claims-ledger machinery as a standalone method.** `docs/claims-ledger.md` (152 rows, proof grammar `test:`/`path:`/`ident:`/`cmd:`/`count:`/`manual:`, statuses proven/pending/retracted/allowlisted) plus the `make claims` schema validator is a portable claim-governance protocol, currently coupled to this repo. **Falsification:** extract it into a repo-agnostic tool, apply it to a *different* codebase (a sibling FrankenSuite repo is the honest first target), and publish the drift it catches within 30 days; if it cannot be decoupled from FrankenTUI's bead vocabulary, or catches nothing a grep wouldn't, it is scaffolding, not a method.
2. **Inline mode as the agent-CLI harness standard.** FrankenTUI's first-class `ScreenMode::Inline` (stable chrome + scrolling logs above, scrollback preserved) plus RAII teardown is exactly the shape coding-agent CLIs need and plain streaming cannot provide. **Falsification:** build a reference agent harness on it, run a controlled task set (N≥30 multi-step agent runs) against the same harness with plain streaming output, with operator error rate as the primary metric (task-completion time secondary); if inline shows no statistically significant improvement (e-process sequential testing — the repo already uses e-processes for exactly this peeking problem), the inline thesis fails.
3. **Prove cross-lane determinism with ShadowRun.** The runtime has three execution lanes (Legacy, Structured, Asupersync) and `ShadowRun::compare()` exists to prove rendering determinism across migrations. **Falsification:** run the full deterministic fixture corpus through all three lanes and publish the frame-hash parity rate; anything below 100% identical frames on the deterministic corpus falsifies the "determinism across migrations" claim the rollout scorecard is supposed to certify.
4. **WASM/native rendering parity audit.** The same Rust core renders to terminal and to browser (WebGPU/canvas2d fallback). **Falsification:** render the 45-screen snapshot corpus through both backends and diff the outputs at the cell-grid level (pre-presentation — the WASM target never emits ANSI); publish the parity rate — below ~99% grid-identical frames, the "shared core" claim is marketing, and the failing screens name exactly where the backends diverge.
5. **Ledger dogfood: file the phantom v0.9.0 as a ledger row.** The evidence machinery's sharpest test is its home turf: add the CHANGELOG's v0.9.0 release claim to `docs/claims-ledger.md` with the proof grammar, and see whether `make claims` can even express — let alone catch — 'a release claim with no tag, no GitHub Release, and no crates.io package.' **Falsification:** if the proof grammar has no proof kind for release-artifact existence, or if the row can sit as `pending-doc` indefinitely without failing any gate, the machinery is incomplete exactly where it matters most — and the fix (a `release:` proof kind) is the exportable contribution.

---
## 4.1 Header

| Field | Value |
|---|---|
| Repository | https://github.com/Dicklesworthstone/frankentui |
| Pinned revision | `979d26c259c3ade3b3ab8b80254662f266c97dd3` — 2026-09-22 10:27:34 -0400 (14:27:37 UTC per GitHub push timestamp) [Verified, High] |
| Assessment date | 2026-09-22 |
| Language / toolchain | Rust, edition 2024, pinned `nightly-2026-08-31` (`rust-toolchain.toml`, with a documented rationale: a clippy-driver ICE on 2026-08-22/23 nightlies) [Verified, High] |
| License | MIT License **with OpenAI/Anthropic Rider** — NOT OSI open source; full text read verbatim, rider scope quoted in §4.8 [Verified, High] |
| Scale | 20 workspace crates; 1,124,747 Rust lines / 986 files (crates only); 11 fuzz targets; 70 scripts [Verified, High] |
| Stars / forks | 283 / 29 (GitHub API, 2026-09-22); 1 open issue [External, High] |
| Releases / tags | 8 real GitHub Releases (v0.2.1–v0.8.0, latest v0.8.0 published 2026-09-14); remote tags stop at v0.8.0 — **the CHANGELOG's v0.9.0 (2026-09-18) has no tag, no GitHub Release, and no crates.io package** [External, High] |
| crates.io | `ftui` max_stable **0.7.0** (not 0.9.0 as CHANGELOG claims); 22,442 total downloads [External, High] |
| Last push | HEAD commit 2026-09-22 [Verified, High] |
| Maintainer | Single: Dicklesworthstone (Jeffrey Emanuel, per LICENSE copyright) — bus factor 1; heavy agent-persona commit conventions shared across the FrankenSuite [Verified identity, High; agent share Inference, Medium] |
| Inception | 2026-01-31 per CHANGELOG [Maintainer claim, High] |

**Analyst method.** Fresh shallow clone of HEAD to `~/workspace/.scratch/frankentui-verify/` (depth 1; no history). Read: README (3,229 lines, skimmed with targeted deep reads), LICENSE (verbatim), CHANGELOG head + version timeline, CHANGELOG_RESEARCH.md head, AGENTS.md (in full — it documents the DSR-only policy, test counts, gates, and reality-check history), `docs/claims-ledger.md` (schema + status census), `rust-toolchain.toml`, `slo.yaml` head, `docs/perf/` listing, per-crate `Cargo.toml` descriptions, `crates/ftui-simd/src/lib.rs` docs. Grep-verified: workspace members, Rust line/file counts, per-crate volumes, largest files, zero `unsafe` constructs across all 986 files (with identifier false-positives individually classified), `forbid(unsafe_code)` distribution, unique widget-type count, demo-screen count, `ScreenMode::Inline`, `TerminalSession`'s `Drop` impl, `BufferDiff::compute`, `PaneDragResizeMachine`, asupersync feature wiring in `ftui-runtime`, Bayesian module inventory, fuzz target count, Cargo.lock package count, remote tags and releases via GitHub API, crates.io metadata via crates.io API. **Not done:** did not compile the workspace, run any test or bench, execute the demo or any binary, observe DSR verification runs, fetch frankentui.com/web in a browser, or independently re-run the snapshot corpus. Page-fetch tooling was unavailable for the releases page; API reads substituted where possible.

## 4.2 Executive verdict

FrankenTUI is a **genuinely large, working terminal-UI kernel in safe Rust** [Inference, High] — not a demo repo: a shallow clone of HEAD confirms 20 crates and 1,124,747 lines of first-party Rust [Verified, High], a real diff-based render pipeline (`Buffer → BufferDiff → Presenter → ANSI`) [Verified key types exist, High], RAII terminal teardown via `TerminalSession`'s `Drop` impl [Verified, High], first-class inline mode preserving scrollback [Verified enum, High], 87 distinct widget types [Verified, High], 45 demo screens [Verified, High], pane workspaces with a drag/resize state machine [Verified, High], in-tree web/WASM backends [Verified, High], and an 11-target fuzz suite [Verified, High]. Its most defensible novelty is not any widget but the **evidence apparatus**: a 152-row claims ledger with a proof grammar and 56 public retractions, five `make gates` checks, a 194,840-line `doctor_frankentui` verification harness, shadow-run lane-migration proofs, and machine-readable SLOs [Verified, High]. **But:** the CHANGELOG's v0.9.0 release (2026-09-18) is phantom — no git tag, no GitHub Release, no crates.io package; crates.io sits at 0.7.0 [External, High]; GitHub Actions was disabled 2026-09-06 so all verification now runs on maintainer-private DSR infrastructure no outsider can observe [Verified from AGENTS.md, High]; there is zero independent validation found (no third-party review, benchmark, or production deployment) [External, High within recall]; the API is explicitly unstable pre-1.0 [Maintainer claim, High]; and the MIT+OpenAI/Anthropic-rider license withholds all rights — including benchmarking and analysis — from OpenAI, Anthropic, affiliates, and anyone acting for them [Verified, High]. **NODUS: Explore. Wardley: custom-built TUI kernel approaching product, with the evidence machinery at early custom-built and the Bayesian/adaptive layer at genesis.** The methodology may outlive the kernel [Inference, Medium].

## 4.3 Claim inventory: demonstrated vs aspirational

Status values: *demonstrated* / *partially demonstrated* / *aspirational* / *disproven* / *stale*. For each *partially demonstrated* row, the missing half is named.

| # | Claim | Status | Evidence |
|---|---|---|---|
| 1 | "Minimal, high-performance terminal UI kernel" (GitHub repo description) | **Disproven on "minimal"; partially demonstrated on the rest** | [External, High] — 1,124,747 lines / 986 files / 20 crates is not minimal by any size definition; "minimal" survives only as a philosophy-of-surface claim (narrow external deps, kernel/framework split), which the architecture partly bears out |
| 2 | 1.1M+ lines of Rust across 20 crates | **Demonstrated** (counted 1,124,747 lines / 986 files / 20 members — the README understates) | [Verified, High] |
| 3 | Zero `unsafe` blocks; `#![forbid(unsafe_code)]` in all 20 crates | **Demonstrated** | [Verified, High] — zero `unsafe {`/`fn`/`impl`/`trait`/`extern` constructs and zero `#[unsafe(` attributes in 986 files; 8 `unsafe`-word hits are identifiers in safe code (e.g. `unsafe_codes.sort()`, `unsafe_snapshot.disposition`), individually classified |
| 4 | 80+ direct `Widget`/`StatefulWidget` implementations | **Demonstrated** (87 unique types, 130 impl blocks — conservative; the counting regex misses generic impls, so 87 is a floor) | [Verified, High] |
| 5 | Widget volume is greenfield kernel work | **Partially demonstrated** — import provenance verified; license compatibility unchecked | [Verified, High] — v0.5.0 "OpenTUI-import closeout" + `docs/opentui-import-support-matrix.md` + `alien_kernel_tests.rs` show part of the widget mass is a governed OpenTUI import; the import's license compatibility with the rider is an open question |
| 6 | 45 interactive demo screens | **Demonstrated** | [Verified, High] — 45 screen files (46 incl. `mod.rs`); `cargo run -p ftui-demo-showcase` is the documented primary path (not executed by analyst) |
| 7 | Inline mode preserving scrollback (`ScreenMode::Inline`) | **Partially demonstrated** — types exist; no executed behavior run | [Verified enum + docs, High] + [Maintainer claim on behavior, Medium] — not executed by analyst; no inline-specific E2E identified |
| 8 | RAII terminal cleanup even on panic (`TerminalSession`) | **Partially demonstrated** — `Drop` impl verified; panic path not executed | [Verified `Drop` impl calls `cleanup()`, High] |
| 9 | Deterministic rendering: Buffer → Diff → Presenter → ANSI, one-writer rule | **Partially demonstrated** — pipeline types verified; end-to-end determinism rests on the unexecuted snapshot corpus | [Verified `BufferDiff::compute`, `TerminalWriter`, zero `async fn` in `ftui-render`, High] |
| 10 | Asupersync executor lane (Legacy / Structured / Asupersync) | **Partially demonstrated** — wiring verified; lane behavior not executed | [Verified, High] — `asupersync = "=0.5.0"` optional dep, `asupersync-executor` feature, lane enum + `asupersync_available()` in `program.rs`; without the feature the lane falls back to Structured |
| 11 | Bayesian intelligence layer (BOCPD — Bayesian online changepoint detection, VOI — value of information, conformal prediction, e-processes — wealth-based sequential tests) | **Partially demonstrated** — modules exist; adaptive effectiveness unproven | [Verified module inventory, High] — `bocpd.rs`, `voi_sampling.rs`, `conformal_*.rs`, `eprocess_throttle.rs`, `countmin_sketch.rs` all present; README's experimental sections carry honest "Where it runs" lines; effectiveness is [Maintainer claim, Medium] |
| 12 | Web/WASM backend exists in-tree | **Demonstrated** | [Verified, High] — `ftui-web`, `ftui-showcase-wasm`, `build-wasm.sh` all present |
| 13 | All 45 screens run as WASM at frankentui.com/web | **Partially demonstrated** — crates exist; live rendering not observed | [Maintainer claim, Medium] — domain resolves; sibling website assessment corroborates a `/web` demo surface exists (not that 45 screens run there); page fetch unavailable this run |
| 14 | Shadow-run validation + RolloutScorecard for lane migrations | **Partially demonstrated** — harness exists; cross-lane parity not executed | [Verified files exist, High] — `shadow_run.rs`, `rollout_scorecard.rs`, `rollout_runbook.rs` in `ftui-harness` |
| 15 | 26,009 tests (`--workspace`), 28,315 with `--all-features` | **Partially demonstrated** — count claimed; greenness at HEAD unknown | [Maintainer claim, Medium] — measured 2026-09-19 per AGENTS.md; not re-run by analyst |
| 16 | v0.9.0 released 2026-09-18; 17 crates published to crates.io at 0.9.0 | **Disproven** | [External, High] — no v0.9.0 ref of any kind remotely (no tag, branch, or release), no GitHub Release (latest is v0.8.0, 2026-09-14), crates.io max_stable is 0.7.0 |
| 17 | `ftui-tty` replaces Crossterm | **Aspirational** | [Verified, High] — crossterm 0.29.0 remains a dependency of 8 crates *including ftui-tty itself*; the replacement is in progress, not done |
| 18 | Benchmarks: diff 1.2µs/8.3µs/45µs; SAT tile-skip 28→21µs | **Partially demonstrated** — method documented; no independent rerun | [Maintainer claim, Medium] — criterion-format output quoted in README (harness inferred from format); `docs/perf/` writeups; host confounds (frequency scaling, allocator, CPU) uncontrolled for outsiders |
| 19 | Published losses: SIMD kernels 3–4× slower than scalar; e-graph solver 4–19× slower, quarantined | **Demonstrated** (the honesty, not just the numbers) | [Verified, High] — stated in `ftui-simd` docs and README with "Where it runs: nowhere" |
| 20 | Claims ledger: 152 rows (37 C + 71 V + 39 S + 5 N) with proof grammar, `make claims` enforcement | **Demonstrated** | [Verified, High] — 56 proven / 56 retracted / 34 pending-doc / 6 pending-code (= 152: 37 C + 71 V + 39 S + 5 N); statuses counted in the file; seeded 2026-09-17; the 56 retractions are one 2026-09-19 audit (experimental-modules), not continuous drift |
| 21 | CI via GitHub Actions (`.github/workflows/` has 4 files) | **Stale** | [Verified files exist, High] + [Maintainer claim, Medium] — Actions disabled in repo settings 2026-09-06 per AGENTS.md; DSR is the mandated path; the workflow files are historical |

## 4.4 Architecture (reconstructed, not summarized)

[Verified from the clone; README diagrams treated as claims where noted]

**Crate topology (20 workspace members):** `ftui` (public facade + prelude, 4,995 lines), `ftui-core` (terminal lifecycle, event parsing, capabilities, inline mode; 48,645), `ftui-render` (cells, buffers, diff, ANSI presenter; 56,902 — incl. 180 KB `diff.rs`, 189 KB `presenter.rs`), `ftui-runtime` (Elm/Bubbletea-style `Program` event loop, subscriptions, three execution lanes; 156,975 — incl. 709 KB `program.rs`, 302 KB `terminal_writer.rs`), `ftui-widgets` (87 widget types; 117,760), `ftui-layout` (flex/grid solvers + pane workspaces; 47,990 — incl. 396 KB `pane.rs` with `PaneDragResizeMachine`), `ftui-text` (spans, wrapping, grapheme width; 35,187), `ftui-style` (themes; 10,161), `ftui-backend` (backend traits, `ScreenMode`; 706), `ftui-tty` (native Unix backend "replaces Crossterm"; 4,111), `ftui-web` (WASM backend; 19,246), `ftui-showcase-wasm` (WASM runner; 5,166), `ftui-simd` (safe portable-SIMD kernels; 590), `ftui-a11y` (accessibility tree; 4,625), `ftui-i18n` (4,232), `ftui-pty` (PTY test utils; 12,096), `ftui-extras` (feature-gated: markdown, charts, mermaid, VFX rasterizer at opt-level=3; 152,466 — incl. 483 KB `mermaid.rs`), `ftui-harness` (test utils, shadow-run, snapshot framework; 79,810), `ftui-demo-showcase` (reference app, 45 screens; 168,244), `doctor_frankentui` (verification harness + diagnostics; 194,840 — the largest crate, bigger than the runtime).

**Mass distribution (the structural story):** the demo showcase (168,244 lines) is ~3× the render kernel (56,902), and the `doctor_frankentui` verification harness (194,840) is larger than the runtime it verifies (156,975). `ftui-extras` carries ~1.13 MB of mermaid diagram code (`mermaid.rs` 483 KB + `mermaid_layout.rs` 344 KB + `mermaid_render.rs` 330 KB) — a diagram renderer riding inside a "minimal" kernel. This is a verification-and-demo project with a kernel inside, not a kernel with tests bolted on [Verified line counts, High]. The two largest single files are `ftui-runtime/src/program.rs` (709 KB) and `ftui-layout/src/pane.rs` (396 KB) — monoliths that belie the "small focused crates" framing, though the workspace DAG itself is acyclic by construction (cargo enforces it) and `ftui-render`'s Cargo.toml documents an explicit allowed-dependency policy (only `ftui-core` + `ftui-a11y`).

**Library DAG hygiene:** the `ftui` facade depends only on library crates (`ftui-runtime`/`ftui-extras` optional) — the demo showcase, the doctor harness, and the test harness do not leak into the library build graph (the manifest comments this explicitly) [Verified, High]. The embeddable-unit claim rests on this, not just on crate boundaries.

**Data flow:** input events → `ftui-core` (`TerminalSession`, parsers) → `ftui-runtime` (`Program::update`, `Cmd`, subscriptions) → widgets render into `Frame`/`Buffer` → `BufferDiff::compute` → `Presenter` emits minimal ANSI → `TerminalWriter` (one-writer rule) → `ftui-backend`/`ftui-tty` (or `ftui-web` for browser). No async in the render path; `asupersync` appears only as an opt-in blocking-task lane behind the `asupersync-executor` feature [Verified, High].

**Memory-safety posture** [Verified, High]: zero `unsafe` constructs anywhere in 986 files — the strongest unsafe census in this program (FrankenRedis fenced four sites; here there are none). `#![forbid(unsafe_code)]` present across the 20 crates per README §"Zero Unsafe Code Policy"; the README is candid that this is enforced for `unsafe` but that no `clippy::arithmetic_side_effects` lint is enabled, so arithmetic overflow protection is convention, not compiler guarantee [Verified README text, High]. Portable SIMD is done in safe `std::simd` (nightly `portable_simd` feature) with scalar twins for parity testing.

**Dependency posture:** 607 packages in `Cargo.lock` (incl. the 20 workspace members); the direct external surface is narrow for a project this size — `crossterm`, `unicode-width`, `pulldown-cmark`, `tracing`, `insta` (snapshot testing), `asupersync` (optional, `=0.5.0`) [Verified, High]. **Drift:** AGENTS.md describes `ftui-tty` as the "Native Unix terminal backend for FrankenTUI (replaces Crossterm)," but crossterm 0.29.0 remains a dependency of 8 crates *including ftui-tty itself* — the replacement is in progress, not done [Verified, High]. **The asupersync question resolves opposite to FrankenRedis:** evaluated-and-*adopted* as an opt-in executor lane, not the core runtime — the kernel does not depend on it.

**README-vs-code drift (governance signal):** the phantom v0.9.0 (CHANGELOG claims release + crates.io 0.9.0; reality is v0.8.0 / crates.io 0.7.0) is the largest drift found in any packet so far [External, High]. Smaller: README says GitHub Actions-era workflows are the verification story in places while AGENTS.md mandates DSR-only since 2026-09-06; `make claims`/`env-docs` docs are self-aware about their own scoping gaps (env-docs covers only 2 binaries; 91 env vars elsewhere unseen). The pattern is honest-about-limits rather than concealment, but the v0.9.0 entry is a release claim with no artifact — the one place the honesty culture visibly lapsed.

## 4.5 Benchmark and conformance audit

### Maintainer-produced numbers

| Workload | Number | Method controls | Would it survive independent rerun? |
|---|---|---|---|
| `diff/identical_100x50` | 1.2 µs, 4.2 Mcells/s | `cargo bench -p ftui-render` (criterion-style output quoted in README) | Plausible; criterion benches are re-runnable, but host/CPU-sensitive |
| `diff/sparse_5pct_100x50` | 8.3 µs, 602 Kcells/s | Same | Same |
| `diff/dense_100x50` | 45 µs, 111 Kcells/s | Same | Same |
| SAT tile-skip, 200×60 sparse | p50 28 µs → 21 µs (~25%) | `diff/sparse_5pct_rows/200x60`; writeup `docs/perf/sat_tile_skip_2026-09.md` | The writeup exists; rerun needs the same bench setup |
| SIMD `all_ascii`/`ascii_width` | 5× at 64 B, 20–44× past 1 KB vs scalar twin | Parity-tested twins; writeup `docs/perf/simd_kernels_2026-09-18.md` | Strongest shape: the twin design makes cheating hard |
| SIMD `first_mismatch_u128`/`rows_equal_u128` | **3–4× slower than scalar** | Same | The published loss — the number most likely to survive |
| e-graph layout solver vs `Flex::split` | **4–19× slower** (233 ns vs 1.99 µs; 5.2 µs vs 99.8 µs) | `cargo bench -p ftui-layout --bench layout_bench`; writeup `docs/perf/egraph_vs_flex_2026-09-18.md` | Published loss; solver quarantined ("Where it runs: nowhere") |
| Test volume | 26,009 (`--workspace`), 28,315 (`--all-features`) | `cargo nextest`; measured 2026-09-19 per AGENTS.md | Re-runnable in principle; not re-run by analyst |
| Snapshot corpus | 45 screens × insta (snapshot-testing crate) snapshots; deterministic E2E (`E2E_DETERMINISTIC=1`) | `scripts/e2e_test.sh`, `demo_showcase_e2e.sh` | Corpus exists; greenness at HEAD unknown |

**The honesty pattern, quoted:** the SIMD crate docs ("`first_mismatch_u128` and `rows_equal_u128` are **3-4x slower** than their twins… Call these [the ASCII ones]"), the README on the e-graph solver ("**Where it runs: nowhere on the layout path, by measurement**"), and the README on `Virtualized` variable heights ("everything above describes an API that works when *you* call it, not a path the demo or the log viewer exercises"). A packet must never cite the 1.2 µs as a result without noting these numbers are maintainer-host measurements with no independent rerun.

**Bench governance (the positive finding):** budgets are not decorative. `scripts/bench_budget.sh` enforces them with "missing evidence fails" semantics (exit 0 = every selected budget measured *and* met), `docs/perf/baseline_profiles.md` carries per-benchmark budget tables (e.g. pane-tree solve/apply/planning/replay keys in nanoseconds), and `docs/perf-promotion-policy.md` governs promotion — this is the same enforce-honesty machinery as the claims ledger, applied to performance [Verified, High].

**The open loop:** `docs/perf/baseline_profiles.md` publishes budget tables but no measured values — the budgets are public, the measurements against them are not; loop closure happens inside DSR, invisible to outsiders [Verified, High]. This is the benchmark-side mirror of the verification story: the machinery exists and is enforced, but an outsider cannot watch it close.

**Confounds an independent rerun must control:** CPU frequency scaling and thermal state, allocator choice, LTO/codegen-unit settings (`release` uses `opt-level = "z"`, `lto = true`, `codegen-units = 1`, `panic = "abort"` — a size-optimized profile, while `release-perf` uses `opt-level = 3`), and for E2E frame budgets the terminal emulator itself. None are pinned in the quoted numbers.

**Reproduction cost (honest):** the tree is large (~1.1M lines) but dependency-light; builds on pinned `nightly-2026-08-31`; the sanctioned path is DSR on the maintainer's hosts (`rch` offload) — an outsider can `cargo bench` the render benches locally in minutes, but the full verification contract (nextest 26k–28k tests, E2E scripts, `make gates`, doctor workflows) is documented for DSR hosts, and DSR runs are not publicly observable. The full-suite cost is hours; the render-bench cost is minutes.

### Conformance evidence

- **Snapshot corpus:** insta snapshots across the 45-screen showcase + `BLESS=1` update flow [Verified corpus exists, High; greenness Maintainer claim, Medium].
- **Deterministic E2E:** seeded/time-stepped runs (`E2E_SEED`, `E2E_TIME_STEP_MS`) [Verified scripts exist, High].
- **Fuzzing:** 11 cargo-fuzz-style targets (input parser, layout constraints, text width/hyphenation/shaping, grid mutations) [Verified, High]; execution history not verified.
- **Shadow-run:** `ShadowRun::compare()` for cross-lane determinism [Verified exists, High; results not executed].
- **SLO gate:** `slo.yaml` machine-readable budgets; `make gates` includes `baseline-benches` [Verified, High].

### Independent numbers

**None found.** Web-visible evidence is the repository itself, its docs, and crates.io metadata (22,442 downloads of `ftui`, max_stable 0.7.0) [External, High]. No third-party benchmark, code review, or production deployment found — with the usual search-recall caveats (private corporate evaluations and unindexed writeups would not surface). Download counts are adoption-adjacent, not validation: they include CI churn and the maintainer's own pipeline traffic, unattributed. **Independent validation: zero.**

## 4.6 Comparison: who owns the lane

**The incumbent** is **ratatui** — the de-facto Rust TUI standard, with the widget ecosystem, the tutorial corpus, the downstream apps, and institutional familiarity [External, High]. **Why the incumbent wins today, in one paragraph:** switching a TUI stack is a trust and ecosystem decision, not a benchmark decision — ratatui has years of production use, a stable-ish API contract, third-party widgets, and answers on Stack Overflow; FrankenTUI has 87 widget types and a faster diff on the maintainer's host, but an explicitly unstable pre-1.0 API ("we're in early development with no users… NO TECH DEBT" per AGENTS.md), bus factor 1, zero independent validation, and a license that excludes the AI labs. Nobody rewrites a shipping terminal app onto a 0.8.0 kernel whose own changelog ships phantom releases.

**The README's own comparison table** names its columns: FrankenTUI vs **Ratatui** vs **tui-rs (legacy)** vs **raw crossterm** [Verified, High]. Its "~20 | ~12" widget counts are the maintainer's and read as stale-or-narrow against the project's own verified 87-type count — treat that row as a strawman, not a census [Maintainer claim, Low].

**Adjacent lanes:** **cursive** (owns the blue-screen/legacy lane), **iocraft** (React-like, owns the component-model lane), **console_engine** and others (own the minimal lane). **OpenTUI** is the unusual one: a TypeScript TUI framework whose patterns FrankenTUI *imported* (v0.5.0 "OpenTUI-import closeout", `docs/opentui-import-support-matrix.md`, `alien_kernel_tests.rs`) — the widget volume is partly a governed migration, not pure greenfield. **FrankenTerm** (sibling repo) is the in-ecosystem downstream consumer of this kernel — the closest thing FrankenTUI has to a real workload fit [Inference, Medium].

**The genuinely unoccupied lane [Inference, Medium]:** the *correctness-certified* TUI kernel — inline mode with scrollback guarantees, RAII teardown proven by construction, deterministic rendering with a machine-checked claims ledger and shadow-run migration proofs. Nobody owns it, and there is a structural reason ratatui can't just add it: ratatui's immediate-mode, alt-screen-assuming design puts inline behavior and teardown in app code by architecture, while FrankenTUI puts them in the kernel (`ScreenMode`, `TerminalSession`) — absorbing them would mean re-architecting the incumbent, not adding a feature. iocraft doesn't do the evidence machinery, and the agent-CLI wave (the heaviest new consumer of terminal UIs) currently builds on ad-hoc streaming. Whether anyone will *pay* for certified correctness in TUIs is the open question — it is a lane, not yet a market. Bluntly: there is zero demand-side evidence. No agent-CLI builder has publicly asked for certification; they currently accept ad-hoc streaming. The lane may be unoccupied because it is unwanted [Inference, Medium].

## 4.7 Technical merit and adversarial review

**Strengths:**
1. **The evidence machinery is the best in this program.** The claims ledger (152 rows, proof grammar, 56 public retractions), five `make gates` checks, the `doctor_frankentui` verification harness, shadow-run lane proofs, machine-readable SLOs, and perf writeups that publish losses — as a packaged discipline this is more transferable than any widget [Verified, High].
2. **Zero unsafe across 1.12M lines is a real, verified property.** Not "fenced," not "audited sites" — zero `unsafe` constructs in 986 files, with portable SIMD done in safe `std::simd` [Verified, High]. For a terminal stack that parses untrusted byte streams (escape sequences, SGR), this is a meaningful attack-surface claim, not a slogan.
3. **Inline mode + RAII teardown is a genuine kernel-level gap in the incumbent lane.** ratatui leaves inline/scrollback and teardown to app code; FrankenTUI makes them kernel features (`ScreenMode::Inline`, `TerminalSession`'s `Drop`) [Verified types exist, High] — and this is exactly the shape agent CLIs need.
4. **The Bayesian/adaptive layer is weird and ambitious in a way incumbents aren't.** BOCPD resize coalescing, e-process flake detection, conformal frame guards, VOI sampling, count-min width caches — no competitor ships a statistics textbook in the render loop [Verified modules, High]. Effectiveness is unproven, but the *direction* (self-tuning rather than hand-tuned thresholds) is genesis-stage.
5. **Candor is load-bearing, not decorative.** The gates *enforce* it: `make claims` fails a README experimental section without a "Where it runs" line; the close-audit gate rejects bead closures without 80+ character evidence-bearing reasons; the ledger's 56 retractions are public. This is the rare repo where the honesty has a test suite [Verified, High].

**Weaknesses:**
1. **The phantom v0.9.0 is a governance red flag.** A changelog describing a release with no tag, no GitHub Release, and no crates.io package — written in release-note past tense ("published," "shipped") — is exactly the README-vs-reality drift the project's own gates exist to prevent, and it is the *current* headline of the changelog [External, High]. Either the release process ran ahead of the artifacts or the artifacts never shipped; neither is visible from outside.
2. **Verification is maintainer-private.** GitHub Actions disabled 2026-09-06 [Maintainer claim, Medium — per AGENTS.md, a secondary source]; DSR runs are not publicly observable; the 26,009-test claim, the E2E greenness, and the shadow-run parity are all take-the-maintainer's-word [Verified policy, High]. For a project whose thesis is *verified correctness*, the verification being unverifiable by outsiders is a structural irony and a hard ceiling on trust.
3. **Zero independent validation.** No third-party benchmark, review, or production deployment found; crates.io's 22,442 downloads are unattributed [External, High]. The widget library is partly an OpenTUI import whose certification is self-administered.
4. **Bus factor 1 at extreme velocity.** The GitHub contributors API lists exactly one human (Dicklesworthstone, 4,112 contributions) plus dependabot [External, High]; agent fleets do the rest. The reachability gate exists because 30 of `ftui-runtime`'s 64 modules were once unreachable-unnoticed [Maintainer claim, Medium — per AGENTS.md]. The gates catch drift, but nothing reviews the reviewer.
5. **Pre-1.0 API instability is policy.** "We do not care about backwards compatibility… NO TECH DEBT" [Verified AGENTS.md, High] — admirable for velocity, disqualifying for anyone choosing a foundation this year.
6. **The license sabotages the agent-CLI future.** The rider withholds even benchmarking and analysis from OpenAI/Anthropic and their agents — the exact builders of the agent CLIs that would be this kernel's best customers [Verified, High].

7. **The proportionality question.** Is a 152-row claims ledger with a proof grammar *proportionate* for a TUI framework, or is it process theater? Dated facts sharpen it: the ledger was seeded 2026-09-17 — five days before this assessment — and its 56 retractions came from a *single* audit on 2026-09-19 (eleven README experimental sections claimed runtime use; zero crates imported them; the rows were retracted and “Where it runs” lines added) [Verified, High]. So the ledger's first act was its biggest, and the retraction count measures one audit's thoroughness, not a velocity of drift. The confirmed blind spot: the word “release” appears zero times in the ledger — release claims are outside its tracked surface, which is exactly where the phantom v0.9.0 sits [Verified, High]. A process that audits everything except the release notes is auditing the easy part [Inference, Medium]. The opportunity-cost form of the same question: 1,124,747 lines ÷ 283 GitHub stars ≈ 3,975 lines per star. Stars are not adoption — but the ratio makes the cost legible [Verified arithmetic on verified numbers; interpretation Inference, Low].
8. **Lane-complexity proportionality.** Three execution lanes (Legacy / Structured / Asupersync), a shadow-run comparator, and a rollout scorecard — distributed-systems migration machinery — for routing blocking closures in a *terminal UI runtime*. The wiring is verified; the proportionality is unasked. If the Asupersync lane never carries real traffic, this is the runtime-side twin of the ledger question: impressive machinery whose cost exceeds its problem [Inference, Medium].

**Steelman of the bear case:** FrankenTUI is a cathedral built for a congregation that doesn't exist. The TUI lane is owned by ratatui on ecosystem, not on microbenchmarks — and the kernel's genuine novelties (inline mode, RAII teardown, Bayesian diff tuning) are features, not products: ratatui could absorb any one of them in a release cycle without the 1.1M-line commitment. The evidence machinery is admirable but self-referential — a ledger that only the maintainer's private DSR pipeline can verify is a diary, not an audit. The Bayesian layer is unproven sophistication on a problem (terminal rendering) whose performance envelope was settled years ago; the e-graph solver episode proves the team will quarantine what loses, but also proves how much of the 1.1M lines is exploratory mass. At bus factor 1, with a phantom release in the changelog and a license that bars the AI labs, the likely terminal state is a magnificent, well-documented research artifact that agent-CLI builders admire and nobody depends on. The sharpest form of the bear case is the project's own gates turned against it: the machine that guarantees correctness has no customer — 26,009 tests, 152 ledger rows, shadow-run proofs, enforced bench budgets, and the release notes still shipped a version that doesn't exist. Methodologies don't get imported; dependencies do — and nobody depends on this one.

**Hook audit (the packet grades its own hook):** "1.12 million lines of Rust, zero `unsafe` blocks, and a public claims ledger that retracts its own rows — but the v0.9.0 release in the changelog was never tagged, published, or shipped." Line count, zero-unsafe, and the 56 retractions are verified; the phantom v0.9.0 is verified absent on all three surfaces (tags, releases, crates.io). "Public claims ledger" is accurate (it's in the repo). The hook survives.

## 4.8 License and governance (material, not boilerplate)

**License text, read verbatim** [Verified, High]: `LICENSE` is the MIT License **with an "ADDITIONAL RIDER / RESTRICTION (OpenAI / Anthropic)"** that is "part of the 'conditions' of this License" and "controls" in any conflict. Quoted scope: *"Restricted Parties" means 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).* *"Notwithstanding any other provision of this License, no rights are granted to any Restricted Party."* And: *"use" includes, without limitation: copying, modifying, … 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.* Breach terminates all permissions automatically; injunctive relief and attorneys' fees reserved to Jeffrey Emanuel (copyright holder, 2026). **Classification: NOT OSI open source** — named-party discrimination plus a use restriction covering even benchmarking and analysis. The README badge discloses it ("license-MIT%2BOpenAI%2FAnthropic%20Rider"), which is more visible than FrankenRedis's plain-"MIT" competitor table — but a badge is still easy to miss.

**The rider as strategy:** defensively coherent (prevents the two leading labs from absorbing the work into training/eval without permission); offensively self-sabotaging for this repo specifically — the most credible adopters of a correctness-certified TUI kernel are the builders of agent CLIs, and the rider names exactly those builders (or their funders) as excluded parties. It also chills the independent validation the project needs: no third party can publish a benchmark without lawyering the rider, since benchmarking is explicitly a restricted "use."

**OpenTUI import vs the rider (open question):** the widget mass is partly an OpenTUI import, and the rider re-licenses derivatives with a use-restriction — whether the import's upstream license permits adding that restriction was not checked (no license statement found in the import docs) and would most change the legal picture [Inference, Low].

**Governance:** owner-directed single maintainer; the contributors API confirms one human plus dependabot — bus factor 1 [External, High]; commit velocity extreme with agent-persona conventions; the `.beads` issue tracker is the planning surface; `make close-audit` enforces evidence-bearing closure reasons (80+ chars with `kind:value` references) because 188 of 2,900 historical closes had no reason at all [Verified from AGENTS.md, High]. Bus factor 1 [Inference, High]. **What breaks first if velocity decays:** review depth, then the tree — the reachability gate already caught 30 unreachable modules in `ftui-runtime` once; at 1.1M lines on a pinned nightly with no second maintainer, a slowdown strands the codebase rather than stabilizing it [Inference, Medium].

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness (TRL 1–9) | **6** | Real kernel, real releases (v0.8.0), crates.io presence, WASM backend, large test corpus — demonstrated in relevant environments (Unix terminal + browser via WASM); but 0.x API, no independent validation, verification not outsider-observable |
| Strategic relevance (1–5) | **3** | Correctness-certified terminal UI is a real gap for the agent-CLI wave; capped by rider, pre-1.0 state, and ratatui owning the ecosystem |
| Impact potential (1–5) | **3** (4 if the evidence machinery is exported) | TUI market is entrenched; impact is methodological + niche unless the ledger/gates become a second-project standard |
| Implementation feasibility (1–5) | **4** | The kernel is largely built and released; remaining work (API stability, WASM parity proof, second maintainer) is bounded |
| Time to mainstream (1–5) | **2** | Years minimum: needs 1.0 API commitment, independent validation, and either a license change or a non-lab adopter |
| Collaboration potential (1–5) | **2** | Source-available; rider blocks the two most likely AI-lab collaborators; bus factor 1; contribution bar is evidence-heavy |

**Ring: Explore.** The ring rules are decisive: *Pilot* requires a release artifact plus a bounded, real-workload fit — releases exist (v0.8.0), but no bounded real workload adoption is evidenced and the verification story is outsider-unverifiable; *Invest* requires independent validation plus governance — neither exists. Explore is the default for substantive-but-unproven. Revisit triggers: a real v0.9.0 (or 1.0) with matching tag + release + crates.io; an independent benchmark, review, or production deployment; a second maintainer; any change to the rider.

## 4.10 Wardley placement

- **TUI widgets and layout solvers:** Commodity — ratatui owns the ecosystem; FrankenTUI's 87 widget types add no leverage here, and part of the volume is a governed OpenTUI import.
- **Clean-room Rust TUI kernel (render diff, runtime, inline mode, RAII teardown):** Custom-built → early Product — works, released (0.8.0), validated against its own corpus but not by third parties; moves right to Product with a 1.0 API commitment + independent validation, left toward Commodity if ratatui absorbs inline mode and snapshot testing as framework features.
- **Bayesian/adaptive render intelligence (BOCPD, e-processes, conformal guards, VOI):** Genesis — no equivalent in any incumbent; moves right if the adaptivity proves out in published measurements, left into curiosity if it stays module-inventory.
- **Evidence apparatus (claims ledger + `make gates` + doctor harness + shadow-run + SLOs):** Custom-built — novel as a packaged discipline and the most transferable component; moves toward Product the moment a second project adopts it (see next step 1).

**The decoupling lens:** FrankenTUI represents *correctness-from-the-kernel* (teardown, determinism, and inline behavior move from app code into the kernel as guarantees), advances *render-engine-from-framework* (the kernel is usable without the widget library — `ftui-render` depends only on `ftui-core`), and gestures at *render-core-from-presentation-target* (one Rust core, terminal and browser targets; note the WASM target renders via WebGPU/canvas2d, not a terminal — the decoupling is at the cell-grid level, not the ANSI level). **The methodology-export lens:** if the kernel fails, the claims-ledger-plus-gates machinery is the candidate survivor — it is the only artifact in the repo that is simultaneously novel, documented, and enforced by its own tests. **The asupersync question:** verified adopted as an opt-in executor lane (`=0.5.0`, feature-gated, fallback to Structured) — the kernel does not depend on it. **The rider question:** quoted verbatim above; as strategy it defends against lab absorption while sabotaging the agent-CLI adoption path that is the kernel's best market.

## 4.11 Trajectory (12 / 24 / 60 months) — [Inference]

- **12 months:** continued high-velocity single-maintainer/agent work; the v0.9.0 phantom resolves one way or the other (real release or changelog correction — the gates should force this); probable 1.0 API-stability commitment or explicit deferral; DSR verification stays private; stays in Explore.
- **24 months:** bifurcation. **Upside:** an agent-CLI builder adopts the kernel for inline mode + teardown guarantees, or a second project adopts the claims-ledger machinery — either is a Pilot trigger. **Decay:** velocity slows with no successor; the pinned nightly ages; the 1.1M-line tree (with 709 KB `program.rs`) becomes unmaintainable; drifts to Monitor as a research artifact whose methodology outlives its product.
- **60 months:** binary. Either a niche-but-real foundation (the certified kernel inside agent infrastructure — the "no-flicker, no-teardown-bug" lane, still unbuilt by anyone), or superseded: ratatui absorbs inline mode and snapshot testing, the Bayesian layer is remembered as an interesting experiment, and the "Rust TUI" lane consolidates. The verification methodology is the more likely survivor either way.
- **The trust-ceiling branch [Inference]:** if DSR verification stays private forever, the trust ceiling never lifts regardless of velocity — the kernel can be *correct* without ever being *believed*, and Explore becomes the permanent ring. If the nightly pin (2026-08-31) ages out and the tree stops building on newer toolchains, decay accelerates from quarters to months.

**Revisit triggers (concrete, observable):** an agent-CLI builder publicly *evaluating* (not even adopting) frankentui for inline mode; a v0.9.0 (or later) release with matching git tag + GitHub Release + crates.io package; any independent benchmark, code review, or production deployment; a second human maintainer with merge rights; adoption of the claims-ledger/gates machinery by a second project; any change to the license rider; published WASM/native parity numbers.

## 4.12 Limitations and open questions (mandatory)

**Not done:** did not compile the workspace, run any test, bench, or binary, execute the demo showcase, observe a DSR verification run, fetch frankentui.com/web in a browser, or re-run the snapshot corpus — all behavioral and performance claims rest on maintainer evidence plus revision-bound documentation. Shallow clone only (no history; contributor graphs and review depth not assessed). Star/fork counts from the GitHub API; download counts from the crates.io API. Web search for independent coverage carries the usual recall caveats. Page-fetch tooling was unavailable for the GitHub releases page during this assessment; GitHub API and crates.io API reads substituted.

**Open questions that would most change the verdict:** why the v0.9.0 artifacts never shipped (process failure or in-flight?); DSR run greenness and whether any outsider can ever observe it; whether the 26,009-test suite is green at HEAD; whether any enterprise has evaluated the rider's legal exposure; whether the OpenTUI import's upstream license permits the rider's use-restriction on derivatives; funding and succession intentions of the maintainer; whether the Bayesian layer's adaptivity beats hand-tuned thresholds in published A/B measurements; what happens to the tree when the nightly pin ages out.

## The eight deepening questions (one paragraph each)

1. **Provenance.** The system records almost nothing about *who produced* a runtime artifact: frames, diffs, and snapshots carry pixels and hashes (insta snapshot hashes, deterministic-seed E2E logs) but no producer attestation — the one exception is the evidence plane, where the claims ledger binds each claim to a proof (`test:`/`path:`/`ident:`/`cmd:`), a verification date, and a bead owner, and `make close-audit` requires closures to cite `commit:`/`test:`/`path:` references [Verified ledger schema + gate, High]. Making attestation portable would require signing the ledger rows and the snapshot hashes with a maintainer key and hash-chaining them so a rewritten history is detectable; today the ledger is a versioned markdown file — auditable, but tamper-evident only through git itself, and the DSR artifacts it cites are not publicly fetchable, so an outsider cannot re-verify the chain [Inference, Medium].

2. **The embeddable unit.** The smallest useful adoptable piece is `ftui-render` (cells, buffer, diff, presenter — 56,902 lines) plus `ftui-core` (terminal lifecycle, events, inline mode — 48,645 lines), which together give deterministic diff-based rendering and RAII teardown without the Elm runtime or the widget library — and the separability is real, not aspirational: `ftui-render`'s Cargo.toml restricts its workspace deps to `ftui-core` + `ftui-a11y` by documented policy, and it contains zero `async fn` [Verified, High]. The adoption cost is real: ~105k lines of nightly-only Rust (`portable_simd`, edition 2024), a pre-1.0 API with an explicit no-backwards-compatibility policy, no stable-Rust story, and the rider follows every derivative — so embedding means vendoring a fast-moving, rider-encumbered kernel whose API the maintainer reserves the right to break [Verified, High].

3. **Unexercised option value.** The architecture holds at least four unused capabilities: the `experimental` quarantined modules (eleven README sections with "Where it runs" lines — a documented options inventory most repos lack); the WASM backend, which exists but has no published parity proof against native; the `ftui-simd` kernels, which are opt-in and half-losing; and `doctor_frankentui`'s synthesis machinery (CEGIS, abstract interpretation, concolic differential testing), currently aimed at this repo but shaped like a general TUI verification service [Verified, High]. What unlocks them is, respectively, wiring or deleting the quarantined modules, a published parity audit, bench-justified SIMD promotion, and pointing the doctor at a second codebase — all product decisions, none blocked on research [Inference, Medium]. And the doctor itself is the largest unexercised option of all: a 194,840-line verification harness, larger than the runtime it verifies, pointed at a second codebase becomes a standalone TUI verification service — plausibly a bigger product than any of the four options above [Inference, Medium].

4. **Benchmark honesty.** The numbers most likely to survive an independent rerun are the *adverse* ones — the SIMD kernels that lose 3–4× to scalar, the e-graph solver quarantined at 4–19× slower — because they are published losses with documented methodology, and nobody publishes losses they can't defend [Inference, Medium]. The headline wins (1.2 µs identical-diff, 20–44× ASCII speedups) have the strongest method shape (criterion benches, parity-tested scalar twins, dated perf writeups) but are load-bearing for the performance thesis and measured on the maintainer's host with no independent rerun — so the thesis currently rests on numbers only their author has produced, which the repo's own honesty culture would flag as provisional [Verified method docs exist, High; rerun status unknown].

5. **The governance path.** The credible route from one maintainer to an institution runs through a 1.0 API-stability commitment: a stable API creates downstream dependents, dependents file issues against real deployments, and a second maintainer emerges from the dependent base or from a company that depends on the inline/teardown story — there is no shortcut, because today the API is explicitly unstable and adoption is therefore experimental by policy [Inference, Medium]. What breaks first if velocity decays is the review surface: at this commit rate the reachability gate already caught 30 orphaned modules once, and a slowdown without a successor doesn't stabilize 1.1M lines on a pinned nightly — it strands them, with the DSR verification pipeline (the thing that proves the tree still works) being the least transferable asset of all [Inference, Medium].

6. **The license as strategy.** The rider excludes exactly OpenAI, L.L.C., Anthropic, PBC, their affiliates, and anyone acting for, benefiting, or under the direction of them — and it defines "use" to include benchmarking, testing, analyzing, indexing, and training-data incorporation, with automatic termination and injunctive relief reserved to Jeffrey Emanuel [Verified verbatim, High]. As strategy it is coherent defensively and self-sabotaging offensively for this repo: the kernel's best market is agent-CLI builders, the excluded parties *are* (or fund) the agent-CLI builders, and the rider's breadth (even benchmarking is forbidden) chills the independent validation the project most needs — which helps explain why independent validation is zero [Inference, Medium].

7. **Agent-era fit.** The concrete workload that would pick FrankenTUI over ratatui is an agent CLI or harness that needs *inline* rendering — stable chrome while tool logs stream above, scrollback preserved for audit — with teardown that cannot be left broken by a panic, and deterministic frame output for replaying agent sessions [Inference, Medium]. What would have to become true first: a 1.0 API commitment (no agent platform bets on an explicitly unstable API), an independent validation of the determinism claim (the shadow-run parity numbers, published by someone other than the maintainer), a WASM/native parity proof for browser-based agent UIs, and — unavoidably — a license an agent-platform company can actually sign [Inference, Medium]. The experiment that would settle the fit question is proposed as next step 2 below.

8. **The kill test.** The single event that would falsify the core thesis — "terminal UIs need a correctness-certified kernel" — is ratatui shipping first-class inline mode with scrollback guarantees, RAII teardown, and a snapshot/determinism harness as framework features: that would commoditize FrankenTUI's kernel-level differentiators and leave it competing purely on implementation, a fight it cannot win at bus factor 1 with no independent validation [Inference, Medium]. The experimental falsifications are nearly as decisive: an independent rerun of the render benches showing the headline numbers don't reproduce off the maintainer's host, or a demonstration that the 26,009-test suite is red at HEAD — either would collapse the pillar (measured performance, verified correctness) the thesis stands on [Inference, Medium]. And there is an *internal* kill test the methodology sets for itself: the claims ledger does not track release claims — the phantom v0.9.0 sits in the CHANGELOG, outside the ledger's surface — so filing it as a ledger row and watching whether `make claims` can even express 'a release claim with no artifact' falsifies the completeness of the evidence machinery on its home turf [Inference, Medium].

---

**Working notes:** clean shallow clone at `~/workspace/.scratch/frankentui-verify/` (HEAD `979d26c`, 2026-09-22). Page-fetch tooling was unavailable for the GitHub releases page during this assessment; GitHub API and crates.io API reads substituted and are labeled as such. No durable user-facing files created besides this assessment and its versioned intermediates.