# FrankenSQLite Website — RULEBOOK v1.0 Assessment Packet v5 **Repository:** `Dicklesworthstone/frankensqlite_website` · **Language:** TypeScript/React (Next.js 16) [Code-verified, High] · **Pinned commit:** `d21491fb6b4f157c0144d7b1272c8f090ffacd2a` (2026-09-21 10:07:47 -0400 / 14:07 UTC, [Git-observed, High]) · **Author of pin:** Jeff Emanuel [Git-observed, High] · **Last push:** 2026-09-21T14:10:37Z [External (GitHub API), High] · **Repo created:** 2026-02-27 [External, High] · **Stars / forks:** 4 / 3 [External, High] · **Open issues:** 0 [External, High] · **Commits:** 29 total via GitHub API [External, High]; the in-repo CHANGELOG documents only the first 17 (through 2026-03-16) — the 12 commits of the 2026-09-21 refresh are undocumented in it [Code-verified, High] · **License:** none — no LICENSE file; README declares default copyright applies (quoted verbatim in §4.8) [Code-verified, High] · **Assessment date:** 2026-09-22. **Method (analyst):** shallow clone of HEAD to `~/workspace/franken-research/frankensqlite_website-clone/` (single-commit depth; working tree at the pin). Read: README (377 lines), AGENTS.md (567 lines), CHANGELOG (202 lines), `lib/content.tsx` (1,144 lines — the master content model), `lib/site-config.ts`, `app/` pages (home 1,078 lines, architecture 656, getting-started 315, showcase 46, spec_evolution 12), `components/site-footer.tsx`, `app/robots.ts`, `app/sitemap.ts`, `tests/unit/content.test.ts`, `package.json`, `.beads/issues.jsonl` (9 issues). Counted: first-party TS/TSX/CSS lines (28,784), viz components (36), jargon glossary terms (47), `test()`/`it()` call sites (158 across 9 files). Verified live: `https://frankensqlite.com` and all five routes return HTTP 200 [Verified, High]; every Quick Link fetched for status. Queried `public/spec_evolution_v1.sqlite3` with the sqlite3 CLI: valid SQLite 3.x database, 2,629,632 bytes, tables `base_doc/change_groups/commits/meta/patches`, 137 commits + 137 patches, `schema_version 1` [Verified, High]. Cross-checked engine-facing claims against the sibling FrankenSQLite packet (pinned `315bc0f1`, 2026-09-22 14:12 UTC — five minutes newer than this pin, so drift comparisons are at matching currency) and by direct grep over that engine clone [Verified/Cross-checked, High]. GitHub API: repo stats, 29-commit history, 12 recent commit authors, flywheel star counts. **Not done:** never installed dependencies (`bun install`), never built (`next build`), never ran vitest or Playwright, never executed the sql.js/WASM spec viewer in a browser, never inspected the Vercel deployment configuration, never verified the remaining 12 flywheel star counts individually. Engine-side facts (unsafe census, crate topology, benchmark disclaimers) are inherited from the sibling packet's verified counts plus direct re-greps — a cross-check, not independent validation. **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**. --- ## Hook frankensqlite.com is a 28,784-line [Counted, High] marketing site for a 28-crate engine that it describes — in its hero stats, its architecture page, its OG images, its FAQ, and its own unit tests — as a 26-crate workspace with zero unsafe code. The engine actually has 28 crates [Counted, High] and 41 counted `unsafe` blocks [sibling-packet census, re-grep-confirmed, High], and its own README states the site's two flagship features (RaptorQ self-healing storage, page-level encryption) are "not yet reachable from the public API" [Maintainer claim, High — engine README]. The site's code examples invoke three APIs (`PRAGMA fsqlite.key`, `PRAGMA fsqlite.repair_ratio`, `fsqlite_current_csn()`) with zero occurrences anywhere in the engine [Counted, High]. It is a case study in marketing outrunning a carefully hedged README — and the drift is the finding. --- ## TL;DR - **What it is:** The official marketing + documentation website for FrankenSQLite (Next.js 16 / React 19 / TypeScript strict / Tailwind 4, bun-only, Vercel-deployed): five routes (home, architecture, getting-started, showcase, spec_evolution), a 36-component interactive visualization suite, a 47-term jargon glossary, a 14-tool "Agent Flywheel" showcase, and a genuinely novel in-browser spec-evolution viewer backed by a real 137-revision SQLite patch database [all Counted/Code-verified, High]. Live at https://frankensqlite.com — all routes return 200 [Verified, High]. - **Strongest evidence:** The site is a real, deployed, crafted artifact — 28,784 first-party lines, 158 counted test call sites across unit + Playwright e2e, a valid 2.6 MB SQLite database powering the spec viewer, per-route OG images, sitemap/robots, and unusual marketing candor in places (comparison table grades FrankenSQLite "Production Maturity: Early" against C SQLite's "20+ years"; FAQ says "under active development… evaluated carefully"; the license badge honestly reads "Unspecified") [Verified/Counted, High]. - **Strongest doubts:** Four site claims are contradicted by the engine it markets, at same-day currency: (1) "26-crate workspace" vs 28 counted crates — stale, and the staleness is **enforced by the site's own tests** (`expect(crates).toHaveLength(26)`) [Verified, High]; (2) "0 unsafe blocks / pure safe Rust throughout / entire workspace enforces `#![forbid(unsafe_code)]`" vs 41 counted unsafe blocks in `fsqlite-vfs` plus the `fsqlite-c-api` FFI boundary — disproven as stated [Verified, High]; (3) self-healing storage ("No external backups needed") and page-level encryption marketed with copy-paste code examples, while the engine README says both are "not yet reachable from the public API" — aspirational presented as shipped [Maintainer claim, High]; (4) the changelog's "up to 8x throughput improvement" traces to a benchmark family the engine's own methodology doc says "Do not cite… for concurrent-writer speed claims" [Maintainer claim, High]. No LICENSE file (default copyright — more restrictive than the engine's MIT+rider), no CI workflows, CHANGELOG stale by 12 commits, bus factor 1, 4 stars [all Verified, High]. - **NODUS ring: Monitor** [Inference, High — Rulebook §4.9: *Monitor is for websites*]. TRL 8 for the site qua website (live, serving, all routes 200; analyst never built it and no CI gates it). The site's value is as the engine's communication surface and as a container for one genuinely exportable artifact (the spec-evolution viewer); its claims about the engine should not be cited without the engine's own README, which is the more honest document. --- ## Quick Links All links fetched for HTTP status 2026-09-22 [Verified, High]: 1. [Repository](https://github.com/Dicklesworthstone/frankensqlite_website) — 200; 4 stars, 3 forks, 29 commits 2. [Live site](https://frankensqlite.com) — 200 3. [Architecture page](https://frankensqlite.com/architecture) — 200 ("A 26-crate layered workspace…") 4. [Getting-started page](https://frankensqlite.com/getting-started) — 200 (`cargo add fsqlite`; `# fsqlite = "0.1"`) 5. [Showcase page](https://frankensqlite.com/showcase) — 200 6. [Spec evolution viewer](https://frankensqlite.com/spec_evolution) — 200 7. [README](https://github.com/Dicklesworthstone/frankensqlite_website/blob/main/README.md) — 200; license badge reads "Unspecified" 8. [Site content model (`lib/content.tsx`)](https://github.com/Dicklesworthstone/frankensqlite_website/blob/main/lib/content.tsx) — 200; every marketing claim lives here 9. [Engine source](https://github.com/Dicklesworthstone/frankensqlite) — 200 (the project being marketed) 10. [crates.io/fsqlite (footer link)](https://crates.io/crates/fsqlite) — **404 to this client under two user agents**; the crates.io API confirms the crate exists at 0.4.4 (76,465 downloads) [Verified, High — link-health caveat, see claim 14] 11. [docs.rs/fsqlite (footer link)](https://docs.rs/fsqlite) — 200 --- ## Did You Know The site's own test suite enforces its drift. `tests/unit/content.test.ts` asserts `expect(crates).toHaveLength(26)` (L110–111) and `expect(crateStat?.value).toBe("26")` (L74–76) — so correcting the stale "26-crate" claim to the engine's actual 28 would **fail the website's own tests**. The drift isn't just undocumented; it's load-bearing in the test suite. [Code-verified, High] --- ## Franken-worthy next steps 1. **Kill this exact drift class with a machine-checked claim manifest.** Extract the site's engine-facing claims (crate list, unsafe posture, feature flags) into a manifest generated from the engine's `Cargo.toml` workspace members at a recorded engine pin, and make the 26-count test read it. *Done when:* adding a crate to the engine breaks the website build, not a human's memory. [Inference, High — process proposal; falsifiable via the test itself] 2. **Compile-check the site's Rust examples against the real engine API.** The three nonexistent identifiers (`fsqlite_current_csn()`, `PRAGMA fsqlite.key`, `PRAGMA fsqlite.repair_ratio`) would all fail today; extract every code example into a test crate pinned to the engine version and `cargo check` it. The engine's own "Documentation Invariants" rule (every numeric claim names its benchmark) is the model — apply it to the website's code. *Done when:* `cargo check` is green at the pinned engine commit. [Inference, High] 3. **Export the spec-evolution viewer as the program's reusable spec-archaeology component.** It is the site's one genuinely novel artifact (in-browser SQLite patch reconstruction, custom diff patch engine, 137-revision dataset with integrity hashes). *Done when:* a second FrankenSuite repo's spec document renders in it unmodified. [Inference, Medium] 4. **Force the license decision.** No LICENSE file means default all-rights-reserved — the most restrictive posture in the FrankenSuite, and it silently contradicts the "open" marketing. *Done when:* a LICENSE file exists (any terms, stated) and the README badge no longer reads "Unspecified". [Inference, High] 5. **Give the site the CI its own README prescribes.** The README lists `bun tsc --noEmit`, `bun lint`, `bun run build`, `bun test`, `bun run test:e2e` as pre-push checks, but the repo has no `.github/workflows` — deployment is push-to-Vercel with no gates. *Done when:* a green CI run is observable on a push. [Inference, High] --- ## 4.1 Why it exists — the market problem **The problem, as the maintainer frames it:** database project sites either explain internals poorly or treat docs as an afterthought; a from-scratch engine with novel concurrency and durability claims needs a surface that can *demonstrate* behavior, not just assert it (README "TL;DR"; AGENTS.md "Project Overview") [Maintainer claim, High]. The site answers with interactive visualizations (36 components: MVCC races, WAL lanes, RaptorQ healing, VDBE bytecode), a centralized content model, and a browser-based spec-history lab — docs-as-demo rather than docs-as-brochure [Code-verified, High]. **Who feels the pain:** evaluators of FrankenSQLite who need to understand page-level MVCC, the safe-merge ladder, or RaptorQ durability without reading 1.78M lines of Rust; and the maintainer, who needs a marketing surface for an engine with no users yet [Inference, Medium]. **Why now:** the engine reached v0.4.4 with real releases (2026-09-17) and needed a public face; the site's own history shows a 6-month quiet period (2026-03 → 2026-09-21) followed by a 12-commit same-day refresh landing exactly when the engine's release cadence accelerated [Git-observed/API, High]. The refresh timing suggests the site is maintained in bursts tied to engine milestones, not continuously [Inference, Medium]. **The tension this packet holds:** the site solves the stated problem (it *is* a technically deep, interactive docs surface) while creating a new one — its marketing claims now outrun the engine's own carefully hedged README, making the less-honest document the public front door [Inference, High — developed in §4.3/§4.7]. **The maintenance economics behind the drift:** the commit history is the governance story in miniature — 17 commits in the Feb–Mar 2026 launch burst, six months of silence, then 12 commits on a single day (2026-09-21) refreshing landing, OG images, architecture, chrome, and tests [External (GitHub API), High]. That is burst maintenance, not continuous maintenance: the site is updated when the maintainer needs a public face for an engine milestone, not as the engine moves. Burst maintenance plus hand-written marketing copy is a drift machine — both of the engine's new crates (`fsqlite-wasm`, first published 2026-06-19; `beads-doctor`, 2026-08-27 [External (crates.io API), High]) were born during the silent six months and no human was watching the site. Any fix that relies on the maintainer remembering to update the site will fail the same way; only generated claims survive this maintenance pattern [Inference, Medium]. ## 4.2 What it is — repo TL;DR A Next.js 16 (App Router) marketing and documentation website for FrankenSQLite: five routes, a client-shell architecture (header/footer/custom cursor/a decorative on-screen "signal HUD" status readout/page transitions), a centralized static content model in `lib/content.tsx` (hero stats, 12 features, 26-crate catalog, 17-row comparison table, Rust code examples, changelog, FAQ), 36 interactive visualization components under `components/viz/`, a 47-term "FrankenJargon" glossary system, a 14-tool "Agent Flywheel" showcase section, per-route OG/Twitter image generation, sitemap + robots, and a spec-evolution subsystem that loads a real SQLite database in-browser via sql.js/WASM with a custom unified-diff patch engine [all Counted/Code-verified, High]. First-party code: 28,784 TS/TSX/CSS lines (app 3,833; components 20,853 — of which the viz suite alone is 13,089 lines, 45% of the entire codebase [Counted, High]; lib 1,819; hooks 232; tests 1,867; types + public/frankenmermaid 89; root configs 152) [Counted, High — excludes `bun.lock`, images, the 2.6 MB SQLite asset]. Deployed to Vercel on push to `main` per README/AGENTS.md [Maintainer claim, Medium — no Vercel config inspectable in-repo]; the live site serves all routes with HTTP 200 [Verified, High]. One-line verdict: **a genuinely well-crafted interactive docs site whose engine-facing claims have drifted past the engine's own honesty line — the site is worth studying as a frontend artifact and as a cautionary tale about marketing outrunning a carefully hedged README.** (NODUS: Monitor — see §4.9.) ## 4.3 Repo facts (claim inventory) Every site claim below was checked against the pinned website commit; engine-facing claims were additionally checked against the engine repo at `315bc0f1` (2026-09-22 14:12 UTC — five minutes newer than the site pin, so currency matches) and the sibling packet's verified counts. **Status** is the Rulebook's audit verdict. | # | Claim (as the site states it) | Status | Evidence | Tier, Confidence | |---|---|---|---|---| | 1 | "26-crate workspace" (hero stats, architecture page "All 26 Crates", OG image, AGENTS.md, FAQ, site-config description) | **stale** | Engine `crates/` lists 28 members at the same-day pin; the site omits `fsqlite-wasm` and `beads-doctor`. The stale count appears in 14 files — including two viz components (`query-pipeline.tsx`, `safety-dashboard.tsx`), the jargon glossary (`franken-jargon.ts`), and the e2e spec — so the drift surface is the whole site, not one page [Counted, High]. The two missing crates were both born *inside* the site's six-month silence: `fsqlite-wasm` first published to crates.io 2026-06-19, `beads-doctor` 2026-08-27 [External (crates.io API), High] — the site's crate catalog is a pre-June snapshot. Irony noted: the omitted `fsqlite-wasm` is the engine's experimental WASM target, and the site itself is a heavy WASM consumer (sql.js, frankenmermaid) [Inference, Medium]. The site's own tests assert 26 (`content.test.ts` L74–76, L110–111), so the drift is test-enforced | [Counted, High] on both counts | | 2 | "0 unsafe blocks — pure safe Rust throughout — entire 26-crate workspace enforces `#![forbid(unsafe_code)]`" (hero stat, feature card, FAQ) | **disproven as stated** | Sibling census (re-grep-confirmed): 41 `unsafe` blocks in `fsqlite-vfs` (mmap/shm/uring/atomics) + the `fsqlite-c-api` FFI boundary; 2 of 28 crates carry local `allow` overrides. The engine's posture ("unsafe confined to vfs/c-api") is real; the site's absolute "zero" is not | [Verified, High] | | 3 | "8 concurrent writers — x throughput via MVCC" (hero stat); changelog: "Enabled concurrent writers — up to 8x throughput improvement" | **partially demonstrated** (writers) / **aspirational lineage** (8x) | Concurrent writers are real in the engine (`BEGIN CONCURRENT`, page-level MVCC [sibling packet, Verified]). But the engine's own `docs/bench-methodology-concurrent-writers.md` says "Do not cite its rows for concurrent-writer speed claims" and documents that the earlier "4.72× faster at 8 writers" figure "was not a FrankenSQLite win — it was a sequential-vs-multi-threaded comparison." The site's "8x" has no cited artifact and descends from a disavowed number family | [Code-verified, High] on the disavowal | | 4 | "100% SQLite-compatible" SQL dialect (hero stat) | **aspirational presented as demonstrated** | The engine's 100% is explicitly a *target*: "100% behavioral parity target with C SQLite 3.52.0 for the supported surface… Aspirational (explicitly a target)" [sibling claim inventory, Maintainer claim, High]; the strict release policy *requires* 100% declared-surface parity, which makes it a gate, not a result. No published parity scorecard found | [External (sibling packet + engine README), High] | | 5 | "Self-Healing Storage — bit rot and disk corruption trigger automatic recovery. No external backups needed." (feature card) | **aspirational** | Engine README (L2800): "page encryption plus RaptorQ self-healing are not yet reachable from the public API." Repair-symbol generation exists on native WAL; the compat WAL reader never calls the decoder [sibling packet, Verified]. "No external backups needed" is unsupportable at the pin | [Maintainer claim, High] | | 6 | "Page-Level Encryption — XChaCha20-Poly1305 encrypts each 4KB page… DEK/KEK envelope… change the passphrase without re-encrypting" + copy-paste `PRAGMA fsqlite.key` / `PRAGMA fsqlite.repair_ratio` example | **aspirational** (design exists, wiring does not) | `encrypt.rs` exists in `fsqlite-pager` [sibling packet, Verified]; but `PRAGMA key`/`rekey` are not dispatched — and unrecognized PRAGMAs are silently ignored, so `PRAGMA key` *returns success while leaving the database unencrypted* [sibling packet, Verified, High]. Engine-wide grep: zero occurrences of `fsqlite.key`, `fsqlite.repair_ratio`, or `fsqlite_current_csn` (used in the time-travel example) [Counted, High]. Engine README FAQ: "do not rely on FrankenSQLite for encryption at rest" | [Counted + Maintainer claim, High] | | 7 | "Reads and writes standard .sqlite3 files directly. Drop-in migration… No data conversion" (feature card, FAQ) | **partially demonstrated** | Byte-level SQLite file-format compatibility is the engine's stated non-negotiable and the page-format parser is verified in tree — but no round-trip behavior was executed by either packet, so "reads and writes" as a behavior is code-presence plus maintainer assertion, not an observed result [sibling packet, Maintainer claim, Medium]. "Drop-in" overstates the API difference (Rust API ≠ C API), which the FAQ itself concedes ("The Rust API is different from the C API") | [Code-verified, Medium] | | 8 | "Time-Travel Queries — `FOR SYSTEM_TIME AS OF`" (feature + code example) | **partially demonstrated** | `SYSTEM_TIME` appears in 26 engine files; the syntax is real [Counted, High]. But the site's example obtains its timestamp via `SELECT fsqlite_current_csn()` — zero engine occurrences [Counted, High] — so the flagship example does not run as written | [Counted, High] | | 9 | "Adaptive Indexing — learned indexes replace B-tree traversal; database cracking builds indexes on the fly" (feature card) | **partially demonstrated** | "Learned index"/"database cracking" each appear in exactly 2 engine crate files and **zero** engine README/docs files [Counted, High] — research-stage code the site presents as a shipped feature | [Counted, High] | | 10 | "Live site: https://frankensqlite.com" (README, site-config) | **demonstrated** | `/`, `/architecture`, `/getting-started`, `/showcase`, `/spec_evolution` all return HTTP 200 [Verified, High] | [Verified, High] | | 11 | Spec-evolution viewer: "loads a SQLite database in the browser… initial spec snapshot and full patch history" (README, CHANGELOG) | **demonstrated** | `public/spec_evolution_v1.sqlite3`: valid SQLite 3.x DB, 2,629,632 bytes, 642 pages; tables `base_doc, change_groups, commits, meta, patches`; 137 commits / 137 patches; `schema_version=1`, dataset/classification/db hashes, `spec_path=COMPREHENSIVE_SPEC_FOR_FRANKENSQLITE_V1.md`, `base_commit=c08f1602…` [Verified via sqlite3 CLI, High] | [Verified, High] | | 12 | "SQLite compatibility test suite with 10,000+ test cases" (site changelog, Phase 5) | **demonstrated** (conservative) | Sibling packet counted 25,684 `#[test]` annotations at the engine pin [Counted, High] — the site's figure understates reality | [External (sibling), High] | | 13 | "No CMS, no backend APIs, bun-only, strict TypeScript" (README) | **demonstrated** | `package.json`: no server deps, no API routes in `app/`; `engines.bun >= 1.3.0` with "DO NOT USE NPM"; `tsconfig.json` strict [Code-verified, High] | [Code-verified, High] | | 14 | Footer links: crates.io/crates/fsqlite, docs.rs/fsqlite, GitHub, X | **partially demonstrated** | docs.rs/fsqlite → 200; GitHub/X → 200; **crates.io/crates/fsqlite → 404** to this client under two user agents, while the crates.io API confirms the crate exists (0.4.4, 76,465 downloads) [Verified, High]. A visitor clicking the footer link may land on a 404; root cause (bot-gating vs genuinely broken route) undetermined | [Verified, High] | | 15 | "Deploys automatically to Vercel on push to main" (README, AGENTS.md) | **maintainer claim** (deployment observed, mechanism not) | Live site serves the pinned content, consistent with auto-deploy; but no `.github/workflows/` exists in the repo and no Vercel config is inspectable from the clone — nothing gates or attests the pipeline [Code-verified, High on the absence] | [Maintainer claim, Medium] | | 16 | Flywheel star counts (14 tools, e.g. Mail 1,654; BV 1,211) | **stale** | Spot-checked 2026-09-22 via GitHub API: mcp_agent_mail 1,654 → **2,152**; beads_viewer 1,211 → **1,691** (both +30–40%) [External, High]. Remaining 12 not individually re-verified — assume drifted | [External, High] | **What the inventory says in aggregate:** claims about *the site itself* (it's live, the DB is real, the viz exists, the tests exist) verify at High confidence; claims about *the engine* skew stale-to-disproven, and the two most load-bearing marketing features (self-healing, encryption) are disavowed by the engine's own README. The site's drift is directional: every stale claim flatters the engine. ## 4.4 Codebase tour **Framework topology (Next.js 16 App Router, [Code-verified, High]):** five content routes — `/` (client component, 1,078 lines: hero, animated stats, features, gallery, comparison, code, crates grid, timeline, CTA), `/architecture` (server, 656 lines: 6 layers, crate catalog, "All 26 Crates" grid), `/getting-started` (server, 315 lines: `cargo add fsqlite`, quickstart, CLI, FAQ — including the stale `# fsqlite = "0.1"` manual-install hint vs the engine's actual 0.4.4 [Code-verified, High]), `/showcase` (server, 46 lines: gallery), `/spec_evolution` (12-line server shell delegating to a dynamically imported client viewer). Per-route OpenGraph/Twitter image generators (`opengraph-image.tsx` / `twitter-image.tsx` — OG images for link unfurls; the home OG image bakes in "26 CRATES" and "ZERO" unsafe as share-image text [Code-verified, High]), `robots.ts` (allow `/`, sitemap pointer), `sitemap.ts` (5 routes, `lastModified: new Date()`), `not-found.tsx`, dynamic `icon.tsx`/`apple-icon.tsx`. **Client shell layer:** `components/client-shell.tsx` wraps every page in `SiteProvider` (anatomy mode via Ctrl+Shift+X, Web Audio API sound effects) + error boundary; standard pages get floating header, footer, custom cursor, signal HUD, scroll-to-top, and `AnimatePresence` transitions; `/spec_evolution` gets a minimal fullscreen shell [Code-verified, Medium — read, not executed]. **Content system:** `lib/content.tsx` (1,144 lines) is the single source of truth for all marketing copy — hero stats, 12 features, the 26-entry crate catalog, the 17-row comparison table (FrankenSQLite vs C SQLite vs libsql vs DuckDB), three Rust code examples, the 5-phase changelog, FAQ (13 Q&As), and the flywheel tool registry [Code-verified, High]. Because every claim lives in one file, the drift audit was a single-file read — the content model is the site's most auditable decision [Inference, High]. **Visualization suite:** 36 `.tsx` components under `components/viz/` [Counted, High] — MVCC races, WAL lanes, conflict ladders, learned indexes, RaptorQ healing, VDBE bytecode, page encryption pipeline, ARC eviction, B-tree explorer, among others. The CHANGELOG's launch entry says "35 interactive components" — the count has drifted by one since, undocumented [Counted, High — minor]. Heavy viz is deferred via an IntersectionObserver wrapper (600px rootMargin) with skeleton placeholders, added in the 2026-02-27/28 perf pass [Maintainer claim, High]. **Spec-evolution subsystem:** `components/spec-evolution/` — `viewer.tsx` (~1,100 lines per AGENTS.md), a custom unified-diff `patch-engine.ts` (with its own unit tests), `viewer-loader.tsx` (dynamic import, suspense boundary), `constants.ts`, `types.ts`, `viewer.css`; state via the TanStack cluster; rendering via sql.js (WASM loaded at runtime, not bundled), diff2html, echarts, marked + DOMPurify [Code-verified, High]. The sql.js choice is architectural, not incidental: the dataset is a SQLite file and the site has no backend APIs by policy, so the database must run in the visitor's browser — WASM is the only way to honor both constraints [Inference, High]. The dataset (claim 11) is real and integrity-hashed (`dataset_hash`, `classification_hash`, `db_hash` in the `meta` table) [Verified, High]. **Dependency posture:** 20 runtime deps (Next 16.1.6, React 19.2.4, react-dom, framer-motion, d3 (+@types), clsx, dayjs, tailwind-merge, echarts, sql.js 1.14, diff2html, marked (+@types), dompurify, the TanStack quintet — react-query, react-store, react-table, react-virtual, store — lucide-react) + 17 dev deps (vitest 4, Playwright 1.58, tailwindcss 4 + postcss plugin, eslint 9 + eslint-config-next, TS 5, testing-library ×2, jsdom, @vitejs/plugin-react, @next/bundle-analyzer, @types ×4) [Counted from package.json, High]. `bun.lock` is 170,079 bytes; bun-only by policy (`"npm": "DO NOT USE NPM"`) [Code-verified, High]. Vendored: `public/frankenmermaid/` (mermaid JS + WASM diagram renderer, `.d.ts` + `.js` + `.wasm`), hero/webp images, the spec SQLite DB [Code-verified, High]. **Tests:** 4 unit files + 5 Playwright specs, 158 counted `test()`/`it()` call sites [Counted, High]. Unit tests cover content-model integrity, utils, and the patch engine; e2e covers smoke, mobile-responsive, performance baselines, viz interactions, setup. The content tests assert the marketing constants — including the stale ones (claim: tests enforce drift) [Code-verified, High]. **No CI executes any of this:** no `.github/workflows/` in the repo [Code-verified, High]. **The asupersync question (Rulebook §6, adapted):** the website has no dependency on asupersync — it is a TypeScript frontend with no relation to the engine's async runtime. Correctly, the site never mentions it [Code-verified, High]. (The engine itself runs on asupersync 0.5.0 per the sibling packet — the coupling is real there, absent here.) ## 4.5 The maintainer's stated case **The pitch, in the site's own structure:** 1. **Concurrent writers via MVCC** — "completely eliminating the SQLITE_BUSY wall," hero stat "8 concurrent writers / x throughput via MVCC," changelog "up to 8x throughput improvement" [Maintainer claim]. Audit: the writer count is real (engine `BEGIN CONCURRENT` [Verified]); the throughput framing descends from a disavowed number family ("Do not cite its rows for concurrent-writer speed claims"; the "4.72×" was a sequential-vs-multithreaded artifact) [Maintainer claim, High]. The site cites no benchmark artifact — violating the engine's own documentation invariant that "every numeric performance claim in README.md must name the benchmark or artifact that measures it" (engine AGENTS.md) [Maintainer claim, High]. The site holds its engine to a lower evidence standard than the engine holds itself. 2. **Self-healing storage (RaptorQ)** — "Bit rot and disk corruption trigger automatic recovery. No external backups needed" [Maintainer claim]. Audit: the engine README says RaptorQ self-healing is "not yet reachable from the public API" and the compat WAL reader never calls the decoder [Maintainer claim, High]. A marketing claim the engine's own docs contradict. 3. **Zero unsafe** — hero stat "0 / Pure safe Rust throughout," FAQ: "The entire 26-crate workspace enforces `#![forbid(unsafe_code)]`… memory bugs are structurally impossible" [Maintainer claim]. Audit: 41 unsafe blocks in `fsqlite-vfs`, FFI boundary in `fsqlite-c-api`, 2 of 28 crates with local `allow` overrides [Verified, High]. ("Structurally impossible" also overclaims what safe Rust guarantees — logic bugs and panics remain — but the census alone falsifies the "0".) 4. **Full SQL + file compatibility** — "100% SQLite-compatible," "reads and writes standard .sqlite3 files," "drop-in migration" [Maintainer claim]. Audit: the engine's 100% is an explicit *target*/release gate, not a measured result [Maintainer claim, High]; file-format compatibility is the genuine non-negotiable [Verified, Medium]. The FAQ's own concession ("The Rust API is different from the C API") quietly deflates "drop-in." 5. **Encryption, time-travel, learned indexes, ARC, structured concurrency** — feature cards + code examples [Maintainer claim]. Audit: encryption unwired (claim 6); time-travel syntax real but the example's `fsqlite_current_csn()` nonexistent (claim 8); learned-index/cracking code exists in 2 files with zero docs (claim 9); ARC real in engine (5 docs + 5 crate files [Counted]); "structured concurrency (Cx + budgets)" in the comparison table mirrors the engine's asupersync `Cx` model [sibling packet, Verified] — this row is the comparison table's most accurate technical claim [Inference, Medium]. **Benchmark reproduction cost:** the site originates zero benchmarks — every number it publishes about engine performance is an engine number repeated without the engine's methodology docs. That absence is itself a finding: there is no site-side table to reproduce, only site-side claims to trace, and the trace for "up to 8x" ends at a disavowed family. Reproducing the *site* requires `bun install` + `bun run build` (never executed by the analyst) and the 170 KB lockfile's dependency tree [Inference, Medium]. The site's own test suite (158 tests) is the closest thing to a verification gate, and it currently *locks in* two stale claims (26 crates ×2 assertions) [Code-verified, High]. ## 4.6 Competitors The site competes in two lanes: (a) *project websites for solo-maintainer database rewrites* and (b) *interactive technical documentation*. Its honest competitors are not other marketing sites but the engine's own README and docs.rs — both more current and more hedged than the site. - **The engine's own README (187 KB):** the incumbent for "learning FrankenSQLite." It wins on currency (28 crates), honesty (the L2800 disclaimer, the bench-methodology disavowals, the encryption foot-gun documented), and the documentation invariant (numeric claims name artifacts). The website loses to its own README on every factual dimension while winning on interactivity [Inference, High]. - **docs.rs/fsqlite (footer-linked, 200):** owns the API-reference lane; generated from the code, so it cannot drift the way hand-written marketing copy does [Inference, Medium]. - **Typical database project sites (libsql, DuckDB, Valkey):** the incumbents in "database marketing site." They win on the only metric that matters for a marketing site — describing a product you can actually adopt today — because their products are deployed and their claims are boring [Inference, Medium]. - **The site's only competitive advantage, stated crisply:** interactivity. No competitor lets you *watch* an MVCC race or page through 137 spec revisions in-browser; everything the site does that the engine README does not is demonstration, and everything it does worse is assertion. The site wins exactly where it shows and loses exactly where it tells [Inference, Medium]. - **Unoccupied lane:** an *interactive, claim-audited* docs surface — 36 executable visualizations plus a machine-checked claim manifest — has no direct occupant. The site's viz suite gestures at it, but without the claim-sync machinery it is a demo gallery, not an audited surface. The defense for the lane being real: the engine already maintains machine-readable contracts (`parity_score_contract.toml`, `supported_surface_matrix.toml`) that a claim manifest could be generated from — the raw material exists, only the site-side wiring does not [Inference, Medium]. ## 4.7 Skeptic's take *Citation convention: weaknesses are numbered 1–8 below; elsewhere "§4.7.N" means weakness N.* **Strengths (substantive):** 1. **The spec-evolution viewer is a genuinely novel artifact.** A real 137-revision, integrity-hashed SQLite database of the engine's spec history, reconstructed in-browser via a custom diff patch engine with its own unit tests — not a mockup. Nothing else in the FrankenSuite program gives you browsable spec archaeology [Verified, High]. 2. **Unusual marketing candor in the comparison table.** The site grades its own product "Production Maturity: Early" against C SQLite's "20+ years," marks FrankenSQLite "Analytical Queries: Basic" against DuckDB's "First-class," and the FAQ says "under active development… should be evaluated carefully for production workloads." Most marketing sites do not publish their own losing rows [Code-verified, High]. 3. **The content model is the site's most auditable decision.** Every marketing claim lives in `lib/content.tsx` — one file, typed, unit-tested. The entire drift audit in §4.3 was a single-file read. Marketing claims *should* be this greppable [Inference, High]. 4. **Real frontend craft.** 36 interactive visualizations, deferred loading with skeletons, per-route OG images, sitemap/robots, 158 tests across unit + Playwright, a CHANGELOG that links every hash, accessibility passes on viz components. As a Next.js artifact it is well above the "thrown-together project site" bar [Code-verified, High]. **Weaknesses (each substantive — capable of sinking the site's credibility on its own):** 1. **[HIGH] The zero-unsafe claim is false as stated.** "0 unsafe blocks / pure safe Rust throughout / the entire 26-crate workspace enforces `#![forbid(unsafe_code)]`" vs 41 counted unsafe blocks in `fsqlite-vfs` plus the `fsqlite-c-api` FFI boundary and 2 local `allow` overrides. The engine's actual posture (unsafe confined to vfs/c-api) is good and honestly documented *in the engine* — the site chose the absolute version, which is the version that's wrong [Verified, High]. 2. **[HIGH] The 26-crate count is stale and test-enforced.** 28 crates at the engine pin (the site omits `fsqlite-wasm` and `beads-doctor`); the staleness is baked into `content.test.ts` (`toHaveLength(26)` ×2), so the test suite would fail a correction. Drift with a regression test defending it [Verified, High]. 3. **[HIGH] Two flagship features are marketed as shipped while the engine README says they are not reachable.** Self-healing ("No external backups needed") and page-level encryption (with copy-paste `PRAGMA fsqlite.key` / `fsqlite.repair_ratio` examples) vs engine README: "page encryption plus RaptorQ self-healing are not yet reachable from the public API" — and the encryption foot-gun (unrecognized PRAGMAs silently ignored, so `PRAGMA key` *succeeds while leaving the database unencrypted*) makes the site's example actively dangerous to copy [Counted + Maintainer claim, High]. 4. **[MEDIUM] The site's code examples call APIs that do not exist.** `fsqlite_current_csn()`, `PRAGMA fsqlite.key`, `PRAGMA fsqlite.repair_ratio`: zero engine-wide occurrences at same-day currency [Counted, High]. Tutorial code on the official site that cannot run. 5. **[MEDIUM] The "up to 8x throughput improvement" descends from a disavowed number.** The engine's bench-methodology doc: "Do not cite its rows for concurrent-writer speed claims"; the "4.72× faster at 8 writers" was "not a FrankenSQLite win." The site cites no artifact at all — violating the engine's own documentation invariant [Maintainer claim, High]. 6. **[MEDIUM] No license, no CI, stale CHANGELOG.** No LICENSE file → default all-rights-reserved (the only one of the two repos assessed in this packet's cross-checks with *no* license grant at all) [Code-verified, High]. No `.github/workflows` — the README's pre-push checks (`tsc`, `lint`, `build`, unit + e2e) are honor-system; deployment is push-to-Vercel [Code-verified, High]. The CHANGELOG documents 17 of 29 commits; the 12-commit 2026-09-21 refresh is undocumented [Verified, High]. 7. **[MEDIUM] "100% SQLite-compatible" presents a target as a result.** The engine's 100% is an explicit aspirational target and release gate with no published scorecard [Maintainer claim, High]. A hero stat should not be a roadmap item. 8. **[LOW] Link and metadata rot.** Footer `crates.io/crates/fsqlite` → 404 to automated clients (API confirms the crate exists at 0.4.4) [Verified, High]; flywheel star counts stale +30–40% on both spot-checks [External, High]; getting-started's `# fsqlite = "0.1"` vs actual 0.4.4 [Code-verified, High]; OG share image bakes "26 CRATES / ZERO" into pixels that will outlive any content fix [Code-verified, Medium]. **Bear-case steelman (strongest counter-case):** frankensqlite.com is the least honest artifact in the most honest program. The engine's README is a model of adversarial self-scrutiny — disavowed benchmarks, documented foot-guns, explicit aspirational labels — and the website systematically un-hedges it: absolute zero-unsafe, shipped encryption, shipped self-healing, 8x throughput, 100% compatibility, each stated without the artifact the engine's own rules require. An evaluator who reads only the site will believe in a product that does not exist yet; an evaluator who then reads the engine README will wonder what else the maintainer's marketing is willing to say. The site's rational use is as a *demo reel for the viz components and the spec viewer*, not as a source of claims — cite the engine README instead. Its most likely end state is continued drift: the engine moves at ~16 commits/day in bursts, the site is refreshed in one-day bursts every six months, and the gap between them compounds until someone runs the site's own examples and they fail. [Inference, Medium — deliberately uncharitable; the counter-evidence is the site's genuine candor rows (§4.7 strengths 2) and the real craft (§4.7 strengths 1, 4).] ## 4.8 Maintenance & succession **Bus factor: 1.** All 12 commits in the 2026-09-21 refresh authored by Jeff Emanuel / Dicklesworthstone (same person) [External (GitHub API), High]. No second committer, no foundation, no succession plan [Inference, Medium — absence of evidence across assessed materials]. **Contribution policy: closed.** README "About Contributions" (quoted in full): *"Please don't take this the wrong way, but I do not accept outside contributions for any of my projects… Feel free to submit issues, and even PRs if you want to illustrate a proposed fix, but know I won't merge them directly."* [Maintainer claim, High]. Combined with 0 open issues and 4 stars / 3 forks, there is no community surface to succeed the maintainer [External, High]. **License (material, quoted verbatim).** There is no LICENSE file. The README's License section reads, in full: *"No explicit license file is currently included in this repository snapshot. Unless or until a license is added by the project owner, default copyright protections apply."* The badge reads `License: Unspecified` [Code-verified, High]. Classification: **no license grant at all — default all-rights-reserved**, which is *more* restrictive than the engine's MIT+AI-lab rider and is non-OSI by absence rather than by rider. The rider question (Rulebook §6) answers itself here: there is no rider because there is no grant; the excluded party is everyone [Inference, High]. As strategy this is presumably inadvertence rather than posture — the engine carries the full MIT+rider text — which makes it a governance gap, not a stance [Inference, Medium]. **Velocity vs. review depth:** 29 commits total; 17 in the Feb–Mar 2026 launch burst, then silence, then 12 commits on a single day (2026-09-21) refreshing landing/OG/architecture/chrome/tests. No tags, no GitHub Releases ("This project has no tagged releases or GitHub Releases" — CHANGELOG) [Maintainer claim, High]. The CHANGELOG itself is stale by the entire refresh (17 of 29 commits documented) [Verified, High]. If velocity decays further, the first thing that breaks is claim-sync with the engine — which is already broken (§4.3) [Inference, High]. ## 4.9 NODUS factsheet | Criterion | Scale | Score + one-line justification | |---|---|---| | Technology readiness | TRL 1–9 | **8** — live production website, all five routes HTTP 200 [Verified]; docked one level because the analyst never built it and no CI gates it | | Strategic relevance | 1–5 | **2** — a marketing surface for an Explore-ring engine; the spec-evolution viewer is the only component with standalone strategic interest | | Impact potential | 1–5 | **2** — reputational impact on the engine's credibility (positive via craft, negative via drift); upside if the viewer becomes a reusable program artifact | | Implementation feasibility | 1–5 | **5** — already built, deployed, and serving | | Time to mainstream | 1–5 | **5** — already live at frankensqlite.com; no adoption ramp remains | | Collaboration potential | 1–5 | **1** — no contributions merged, no license grant, bus factor 1 | **Ring: Monitor** [Inference, High]. The Rulebook is explicit — *"Monitor is for websites, retired artifacts, and plan-stage work"* — and the assignment rules say to ring down when in doubt. A website does not become Pilot by being well-built; there is no bounded workload to pilot *on*. The ring is about the artifact class, and the artifact class is a website. ## 4.10 Wardley placement - **Commodity:** Next.js 16 + React 19 + Tailwind 4 + Vercel hosting + bun package management — pure utility, nothing custom [Inference, High]. *Mover: framework upgrades; nothing the maintainer does moves this.* - **Custom-built (product):** the 36-component visualization suite, the 47-term jargon glossary system, the centralized `content.tsx` model, per-route OG generation — differentiated but not novel in kind [Inference, Medium]. *Mover: extraction into a documented component library, or adoption by a second project — either would be observable as an import outside this repo.* - **Genesis:** the in-browser spec-evolution viewer — spec-history-as-queryable-database with a custom patch engine and integrity hashes; no comparable artifact observed in the program [Inference, Medium]. *Mover: a second FrankenSuite repo's spec rendering in it unmodified — the exact event next step 3 names as its done-when — would move it from genesis experiment to custom-built tool.* - **The site's claims about the engine** sit in Wardley terms at *custom-built marketing resting on a genesis-stage engine* — the map's warning is that the marketing layer is evolving faster toward polish than the engine is toward the marketed capabilities [Inference, Medium]. *Mover for the claims layer specifically: generating `content.tsx`'s engine facts from the engine pin (next step 1) would move the claims from hand-written custom to generated-commodity — the drift dies when the map position changes.* ## 4.11 Trajectory (12 / 24 / 60 months) **[Inference — all of §4.11 is analyst judgment.]** **Base case:** the site continues as a burst-maintained veneer. The engine keeps its ~16-commit/day bursts; the site gets refreshed in one-day bursts every few months; the claim gap (§4.3) compounds — the next engine release (0.5.x) adds crates the site doesn't list, and the "26 crates / zero unsafe" copy hardens into folklore. The spec viewer stays a demo. The site remains useful as a viz gallery and misleading as a fact source. Confidence: **Medium**. **Upside bifurcation:** the maintainer adopts the claim-manifest discipline (next step 1) and the site becomes the program's first *machine-checked* marketing surface — every engine release regenerates the crate catalog, unsafe posture, and feature flags from the engine pin, and the site's honesty starts compounding instead of its drift. The spec viewer gets extracted and a second repo's spec renders in it. Confidence: **Low** — it requires process the maintainer has not shown appetite for (no CI even for `tsc`). **Decay:** the engine's next honest README revision widens the gap (e.g., the encryption foot-gun gets louder), someone runs the site's `fsqlite_current_csn()` example against 0.4.4 and it fails publicly, and the site becomes a liability the maintainer has to disclaim. Or simpler: the domain lapses or the Vercel project is abandoned, and frankensqlite.com rots at the 2026-09-21 snapshot. Confidence: **Medium** for continued drift; **Low** for outright abandonment. **Revisit triggers (concrete, observable):** (1) a LICENSE file appears (ring unchanged, but §4.8 rewritten); (2) the crate count on the site moves 26 → 28 (drift repair in progress); (3) any `.github/workflows/` file appears (CI exists); (4) the engine ships a release where page encryption or RaptorQ healing becomes reachable from the public API (the site's two flagship claims become true); (5) a second human committer appears; (6) the spec viewer renders a second repo's spec (genesis → custom-built). ## 4.12 Limitations and open questions (analyst-facing) **Not done:** the site was never built (`bun install` / `next build` never run — dependency resolution, build greenness, and bundle behavior are all unestablished); vitest and Playwright suites never executed (the 158 counted tests are call sites, not results); the sql.js/WASM spec viewer was never run in a browser (its interactivity is code-read, not observed); the Vercel deployment pipeline was never inspected (auto-deploy is a maintainer claim); 12 of 14 flywheel star counts were not individually re-verified; the crates.io footer-link 404 was observed under two user agents but the root cause (bot-gating vs broken route) was not determined; engine-side facts (41 unsafe blocks, 28 crates, README disclaimers) are inherited from the sibling packet's verified counts plus direct re-greps — a cross-check, not independent validation; no web search for independent coverage of the site was performed beyond link resolution. **Open questions that would most change the verdict:** (1) Does `next build` succeed at the pin, and do the 158 tests pass? (A red build would drop TRL to 6 and harden §4.7.) (2) Is the crates.io 404 UA-gating or a genuinely broken footer link? (3) Who is the site's audience in practice — is anyone evaluating the engine via the site rather than the README? (No analytics available to the analyst.) (4) Will the maintainer accept the claim-manifest discipline, or is the drift structural to burst maintenance? (5) Does the engine's next release wire encryption/RaptorQ to the public API, which would convert the packet's two heaviest drift findings into true claims? --- ## Deepening questions — Rulebook §5's binding eight, one paragraph each 1. **Provenance.** The site records almost nothing about who produced what: 29 commits by one human, no CI attestations, no signed builds, no SBOM; the one provenance-strong artifact is the spec-evolution database, whose `meta` table carries `dataset_hash`, `classification_hash`, `db_hash`, `base_commit`, and a 137-commit manifest — content-addressed history for the *spec*, surrounded by a site with no build provenance at all [Verified, High]. Making attestation portable would require the missing CI (build + test + sign on every push) and pinning the dataset hashes in the repo rather than only inside the SQLite file [Inference, Medium]. 2. **The embeddable unit.** The spec-evolution viewer — `viewer.tsx` + `patch-engine.ts` + the sql.js loading pattern — is the smallest useful piece adoptable without the whole site; it is already dynamically imported behind a suspense boundary, so its seams are clean [Code-verified, High]. Adoption cost is the dependency cluster it drags: the TanStack quintet, diff2html, echarts, marked, DOMPurify, and sql.js — 10 of the site's 20 runtime dependencies for one route [Counted, High]. 3. **Unexercised option value.** The 36 viz components are executable pedagogy for engine concepts (MVCC races, conflict ladders, RaptorQ healing) that currently serve only marketing; wired to the engine's conformance harness they could become *verified* interactive documentation — diagrams generated from the same differential oracle that grades the engine [Inference, Medium]. The vendored `frankenmermaid` WASM renderer is exercised on two routes (home preview, architecture diagram) [Code-verified, High]; its unexercised option is the *authoring* side — a diagram-as-code pipeline that renders architecture diagrams from the engine's crate graph at each release instead of hand-maintained diagram sources [Inference, Low]. 4. **Benchmark honesty.** Of the site's numbers, the ones that would survive an independent rerun are the ones about the site itself: 28,784 lines [Counted], 36 viz components [Counted], 137 spec patches [Verified via sqlite3], 10,000+ engine tests (conservative vs 25,684 counted) [External]. The ones that would not: 26 crates (28), 0 unsafe (41 blocks + FFI), "up to 8x" (disavowed family), 100% SQL (aspirational target), flywheel stars (stale) [Verified/Counted, High]. The load-bearing number for the site's thesis — that the engine is production-shaped — is "Production Maturity: Early," the comparison table's most honest row [Inference, Medium]. 5. **The governance path.** There is no credible route from one maintainer to an institution visible in this repo: contributions are explicitly not merged, there is no license grant to build on, no CI to hand over, and the CHANGELOG is maintained by hand (already 12 commits stale) [Verified, High]. If velocity decays, claim-sync breaks first — it already has, with nobody noticing for the six months the engine moved from 26 to 28 crates [Inference, High]. The site's own test suite defending the stale count is the canary: automation currently *protects* the drift. 6. **The license as strategy.** There is no rider and no grant: default all-rights-reserved, the most restrictive posture observed in this packet's cross-checks — more restrictive than the engine's MIT+AI-lab rider, which at least grants rights to non-restricted parties [Code-verified, High]. Who it excludes: everyone, including the evaluator reading the marketing site. It cannot serve the stated mission (marketing an open engine) and most plausibly reflects inadvertence — the engine's LICENSE was written with care, the website's was never written at all — which makes it a fixable governance gap rather than a stance, but the gap is real today [Inference, Medium]. 7. **Agent-era fit.** The concrete agent workload that would pick this site over the engine README is *learning the engine's concepts*: the viz suite and the spec-evolution viewer are genuinely better pedagogy than 187 KB of README, and the centralized `content.tsx` is trivially machine-readable — an agent can extract every claim in one file read, which is exactly what this packet did [Inference, Medium]. What would have to become true first: the claims must be machine-*checked*, not just machine-readable — otherwise the agent learns the drift, including the nonexistent `fsqlite_current_csn()`. 8. **The kill test.** Run the site's own code examples against the engine at its current release: `SELECT fsqlite_current_csn()`, `PRAGMA fsqlite.key = '…'`, `PRAGMA fsqlite.repair_ratio = 0.2` [Code-verified, High]. If the examples fail — and at the pin, all three identifiers have zero engine occurrences — the site's core thesis ("this page teaches you the engine") is falsified for the tutorial surface, which is the surface a new adopter touches first. The experiment costs one `cargo check` and the maintainer's own documentation invariant already demands it [Inference, High].