# FrankenMarkdown Website — RULEBOOK v1.0 Assessment Packet v2

**Repository:** `Dicklesworthstone/franken_markdown_website` · **Language:** static HTML/CSS/JS + vendored WASM [Code-verified, High] · **Pinned commit:** `c9574d3b101a3bb820c25de6b95a1a7ffe25166a` (2026-09-22 00:29:52 −0400 / 04:29:52 UTC, [Git-observed, High]) · **Last push:** 2026-09-22 (pin date; the pin is the latest push confirmed in this assessment) [Git-observed, High] · **Scope:** the pinned commit only. No tags, no releases on this repo [External, High]. *Cold-reader note: this packet assesses the marketing/demo website for the FrankenMarkdown engine (engine repo: `Dicklesworthstone/franken_markdown`), not the engine itself — the site's own terms are the audit surface, and drift between the site's copy and the engine it ships is a first-class finding. ("v1" below = the first draft of this packet, superseded.)*

**Method (analyst):** shallow clone of HEAD at the pin under `~/workspace/.scratch/franken_markdown_website-verify` (74 files, 28 MB, verified non-empty). Read: README (full), LICENSE (verbatim), `index.html` (894 lines, full), all five `assets/js/*.js` (1,867 lines), `_headers`, `package.json`, `robots.txt`, `.nojekyll`, `dev/e2e.mjs` (349 lines), `dev/failure-and-stress.mjs`, `dev/firefox-smoke.mjs`, `dev/webkit-smoke.mjs`, `dev/refresh-engine-wasm.sh`. Counted: files, lines, `check()` invocations in e2e (definition line excluded — it doesn't match the `check(` pattern), fonts bytes, wasm raw/gzip sizes per tree, sha256 of all six wasm trees. Verified live: `https://franken-markdown.com` fetched and read 2026-09-22 [Verified]. GitHub API: repo metadata (stars/forks/created/pushed), engine repo `scripts/check-wasm-package.sh` existence, engine releases list, website-repo `.github` absence (404). npm registry API: `@franken-suite/franken-markdown` metadata (latest 0.4.4). Executed (analyst-side, no browser): decoded the README's own example `zdoc` share URL — 202 payload chars decompress to 197 bytes of Markdown, proving the share format beyond code-read. **Ran the packet's kill test:** `node dev/verify-live-assets.mjs` against https://franken-markdown.com — 8 stale assets of those checked, exit nonzero (see claim 21). Fetched the engine repo's `release-wasm.yml` and confirmed it invokes `scripts/check-wasm-package.sh release` (L32), completing the delegation chain for the parity-gate claim. **Not done:** no test suite was executed (no browser automation in this sandbox — `bun run test`, `test:live`, `test:stress`, smokes all unrun); the wasm binary was never executed; CSS was not rebuilt; crates.io could not be reached (API returned empty 200s; page fetches 403 to non-browser clients — treated as unverified, not absent); the shallow history is a single commit, so commit-velocity and authorship-over-time analysis were impossible. Assessment date: 2026-09-22.

**Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — with 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/site copy, not independently executed; **[External]** independent sources (GitHub/npm APIs); **[Inference]** analyst judgment, always labeled. Confidence: **High** / **Medium** / **Low**.

---

## Hook

A marketing site whose demo *is* the product [Code-verified, High]: the playground runs the actual FrankenMarkdown engine, compiled to WebAssembly in a Web Worker — not a screenshot, not a lookalike. Its credibility apparatus is unusually honest — a "Lab Notes · Honest scar tissue" strip confessing partial CommonMark coverage, caching docs recording the maintainer's own stale-deploy incidents, a `verify:live` script that sha256-compares every production asset [all Code-verified, High]. The catch: the honesty machinery has drifted from what it ships — the Lab Notes strip says the page runs engine **0.3.5** while the pinned tree wires in **0.4.2** and production serves **0.4.1** [all Verified, High] — and the live page contradicts *itself*, header claiming 0.4.1 while its body text still says 0.3.5 [Verified, High].

---

## TL;DR

- **What it is:** The static demo/marketing site for the FrankenMarkdown engine — a single-page scroll narrative (894-line `index.html`) plus a two-pane Markdown→HTML/PDF playground that runs the real Rust engine as a wasm-bindgen module inside a module Web Worker, with serverless URL-fragment document sharing. Deployed on Cloudflare Pages at franken-markdown.com via manual `wrangler pages deploy` (not Git-connected) [Code-verified + Maintainer claim, High].
- **Strongest evidence:** The core pitch verifies from the code: `render-worker.js` imports `../wasm/0.4.2/franken_markdown.js` and speaks a real worker protocol with transferable `ArrayBuffer`s [Code-verified, High]; zero external script/stylesheet URLs and zero analytics identifiers across the tree [Code-verified, High]; self-hosted fonts measured 88,660 bytes vs the claimed "87 KB" [Counted, High]; the share-link format is exactly as documented (deflate-raw → base64url in the `#` fragment; fragment never sent to the server) [Code-verified, High]; the README's 0.3.5 artifact receipt re-derives exactly on two of three legs — sha256 `1da66d98…` and raw 4,028,677 bytes match; the gzip leg (1,803,496 claimed vs 1,806,855 measured, 0.19% off) does not, a gzip-version artifact [Counted, High]; the Knuth–Plass visualization implements a genuine total-fit dynamic program [Code-verified, High].
- **Strongest doubts:** There is no CI in this repo (`.github` 404s; every verification script is a manual `bun run`) — and the kill test was executed, not hypothesized: `verify:live` run against production reports 8 stale assets with the wasm glue matching no committed tree, exit nonzero [Verified, High]; the Lab Notes honesty strip and the README's deploy section are two engine versions stale (0.3.5 claimed vs 0.4.2 shipped vs 0.4.1 live), and the live page simultaneously claims both 0.4.1 and 0.3.5 [Verified, High]; production lags the pin (manual deploys) while npm already installs 0.4.4 — the "try it here, install it there" coherence is broken [Verified, High]; the repo carries six wasm trees (23 of 28 MB) of which five are dead weight, and two different binaries both wear the 0.3.5 label [Counted, High]; the site's headline engine numbers are re-published from the engine repo — this site cannot re-prove them [Inference, High].
- **NODUS ring: Monitor** [Inference, High] — the Rulebook's explicit bucket for web properties. The site is a finished, deployed, live artifact (TRL 8 — see §4.9), but as a research-program object it is *support infrastructure for the engine's credibility story*, not an advancement candidate. Its durable export is the verifiability pattern (prove-don't-promise marketing), not the pages.

---

## Quick Links

All links verified resolving 2026-09-22 [Verified, High]; pin-relative GitHub links use `blob/c9574d3b101a3bb820c25de6b95a1a7ffe25166a`:

1. [Repository](https://github.com/Dicklesworthstone/franken_markdown_website)
2. [README (at pin)](https://github.com/Dicklesworthstone/franken_markdown_website/blob/c9574d3b101a3bb820c25de6b95a1a7ffe25166a/README.md)
3. [License — MIT + OpenAI/Anthropic rider (at pin)](https://github.com/Dicklesworthstone/franken_markdown_website/blob/c9574d3b101a3bb820c25de6b95a1a7ffe25166a/LICENSE)
4. [Live site](https://franken-markdown.com) — read live 2026-09-22; header strip reports "Renderer v0.4.1 in this page" while body copy still says "In this 0.3.5 WASM"
5. [Engine repository](https://github.com/Dicklesworthstone/franken_markdown) — the upstream whose CI gate this site cites
6. [Engine wasm parity gate script](https://github.com/Dicklesworthstone/franken_markdown/blob/main/scripts/check-wasm-package.sh) — the "byte-identical" gate, in the engine repo
7. [Engine wasm release workflow](https://github.com/Dicklesworthstone/franken_markdown/blob/main/.github/workflows/release-wasm.yml)
8. [`_headers` caching policy (at pin)](https://github.com/Dicklesworthstone/franken_markdown_website/blob/c9574d3b101a3bb820c25de6b95a1a7ffe25166a/_headers)
9. [npm registry metadata for `@franken-suite/franken-markdown`](https://registry.npmjs.org/@franken-suite%2Ffranken-markdown) — registry API, 200 with package data 2026-09-22; latest 0.4.4

*Not linked: the crates.io crate page — the API returned empty 200s and page fetches 403 to non-browser clients on 2026-09-22, so resolution could not be verified; see §4.13.*

---

## Did You Know

The README records a cryptographic receipt for the 0.3.5 engine artifact — sha256 `1da66d986365f627dce8a05483feb9c2d2d9d45a29e4474fbd057e01abe83662`, raw 4,028,677 bytes — and re-computing it from the vendored binary in the pinned tree reproduces **both values exactly** [Counted, High]. (The receipt's third leg, a gzip figure, misses by 0.19% — a gzip-version artifact, not a different binary; see claim 8.) The receipt predates the `verify:live` tooling and is the fossil of the site's core idea: marketing numbers you can re-derive with `sha256sum`.

---

## Franken-worthy next steps

1. **Make the stat cards self-falsifying.** Every engine number the page displays (379/652, "100% byte-identical", "1.8 MB gz") should be re-derived by a script and compared against the DOM at deploy time — the "verifiable marketing" pattern made executable instead of aspirational. *Done when:* a pre-deploy script fails the deploy if any displayed number disagrees with the measured artifact. [Inference, High — process proposal]
2. **Extract the fragment-share protocol as a micro-spec with a second implementation.** The deflate-raw → base64url → `#zdoc=` format is the site's most adoptable unit; a 50-line independent decoder in another language that round-trips a real share URL would prove it is a protocol, not a trick. *Done when:* the independent decoder round-trips a production share link byte-for-byte. [Inference, High]
3. **Schedule the gates the README already claims.** The e2e suite, `verify:live`, and the smokes exist and take URLs as arguments — the falsifiable novelty is not "add CI" (obvious) but *treating the README's testing table as a contract*: a scheduled workflow that runs the documented suites against production turns the packet's central criticism (gates nobody runs) into a standing experiment with public pass/fail. *Done when:* a scheduled run executes against franken-markdown.com with public results, and the first red run is investigated rather than muted. [Inference, High]
4. **Generate the Lab Notes strip from the wasm directory at deploy time.** The honesty strip's job is transparency, but it is hand-maintained copy that has lagged two engine bumps; a `dev/` script that stamps the strip from the wired wasm version and the engine's release API would make the drift class impossible. *Done when:* an engine bump lands and the strip updates in the same commit by construction. [Inference, High]
5. **Publish a drift ledger for the marketing surface.** A `DRIFT.md` listing copy-vs-artifact mismatches with dates (0.3.5 strip vs 0.4.2 binary; "28-check" vs 30 counted; "1.8 MB" vs 1.86 MB live payload; the two 0.3.5 binaries) would port the engine program's negative-evidence culture to the marketing layer — the scar tissue, versioned. *Done when:* the file exists and is updated on every engine bump. [Inference, High]

---

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** Markdown-renderer demos usually cheat — a canned screenshot, a server that renders for you, or a JavaScript lookalike library that is not the real engine. "None of that proves anything about the actual renderer" (README TL;DR) [Maintainer claim, High — quoted from the pinned README]. The site's answer is to run the actual FrankenMarkdown core, compiled to WebAssembly and hosted in a Web Worker, so the demo is evidence about the engine rather than advertising adjacent to it.

**Who feels the pain:** evaluators of the FrankenMarkdown engine (developers choosing a Markdown→HTML/PDF pipeline, and — explicitly courted on the page — AI agents: the site has an "Agent-First CLI" section and the engine exposes `capabilities --json`, `doctor --json`, `robot-docs`) who want to try the renderer without installing a toolchain [Inference, Medium].

**Why now / why this shape:** the engine already ships as a wasm-bindgen npm package (`@franken-suite/franken-markdown`, latest 0.4.4 on the npm registry [External, High]), so the marginal cost of a real-engine demo is one module worker and a versioned asset directory. The site is the engine's try-before-you-install surface and its credibility anchor: every claim the engine makes about determinism and zero dependencies is meant to be checkable from the page [Inference, Medium].

**Demand-side note:** the site has no analytics by design (claim 3), so usage demand is structurally unknowable — the packet cannot check whether anyone uses the demo, and neither can the maintainer. The site's success metric can only be indirect (npm installs, engine repo stars) [Inference, High]. **Adjacent context:** this is a support repo in the FrankenSuite program — the engine (`franken_markdown`) is the substantive artifact; this repo is its proof-of-work showroom. It is assessed on its own terms here: do the site's claims verify, and does the site drift from the engine it ships? [Inference, High — this packet's adopted scope].

## 4.2 What it is — repo TL;DR

A 74-file, 28 MB static site (no framework, no build step at deploy, no backend) [Counted, High]: an 894-line single-page scroll narrative, five hand-written JS modules (1,867 lines), committed compiled Tailwind CSS (3,133 lines), self-hosted fonts, and six versioned wasm trees — of which the pinned page actually wires in exactly one (`assets/wasm/0.4.2/`, imported by `assets/js/render-worker.js`) [Code-verified, High]. Around it: 24 `.mjs` dev scripts (1,197 lines) plus the wasm-refresh helper (77 lines) and the Tailwind source (522 lines), implementing a 30-check headless e2e suite, a `verify:live` sha256-compare deploy verifier, a 12-round stress suite, and Firefox/WebKit smokes — all manual `bun run` invocations, because the repo has no CI at all (no `.github` directory) [Code-verified, High]. Deploys are manual `wrangler pages deploy` to Cloudflare Pages; the site is deliberately not Git-connected [Maintainer claim + Code-verified, High].

One-line verdict: **a credibility machine for the FrankenMarkdown engine — the rare marketing site whose central claims re-derive from its own tree — currently undermined by the exact failure mode it was built to prevent: its transparency copy has drifted two engine versions behind the binary it ships.** [Inference, Medium] (NODUS: Monitor — see §4.9.)

## 4.3 Repo facts (claim inventory)

Every claim below was checked against the pinned commit (and, where noted, the live site) on 2026-09-22.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | The playground runs the real engine compiled to WASM, in a module Web Worker, off the main thread | demonstrated | `render-worker.js` imports `../wasm/0.4.2/franken_markdown.js`; worker protocol documented in-file (result bytes transferred as `ArrayBuffer`s, zero-copy); debounce 170 ms, at-most-one-render-per-format coalescing in `playground.js` | [Code-verified, High] |
| 2 | WASM output is byte-identical to the native binary, "gated in CI" | partially demonstrated (delegated) | The gate exists in the *engine* repo and the delegation chain is complete: `release-wasm.yml` invokes `scripts/check-wasm-package.sh release` (workflow L32), whose parity section renders a corpus through native and wasm builds and compares with `cmp -s` byte-for-byte (sha256-logged, size-budgeted). This repo never re-proves it and has no CI of its own — the site re-publishes another repo's wired gate | [External, High] on existence and wiring; gate execution/greenness [Not observed] |
| 3 | No backend, no analytics, no CDN dependencies; fully static | demonstrated | Zero external `src=` URLs in `index.html`; no analytics identifiers anywhere in the tree (the one "plausible" hit is an innocuous code comment in `md-highlight.js`); fonts self-hosted | [Code-verified, High] |
| 4 | Share links pack the document into the URL `#` fragment (deflate-raw + base64url), never touching a server | demonstrated (by execution) | `playground.js` L185–186 documents the format; L235–241 decode path, L551–553 encode path. Analyst decoded the README's own example share URL: 202 payload chars → raw-deflate → 197 bytes of Markdown ("# Hello from a URL…"). The format is proven, not just read | [Verified, High] |
| 5 | "28-check headless e2e (Chromium)" | stale | 30 `check(` invocations counted in `dev/e2e.mjs` (the `const check =` definition at L38 does not match the `check(` pattern and is excluded) vs 28 claimed — the suite grew past its documentation | [Counted, High] |
| 6 | "Last production engine bump: 0.3.5 (2026-08-28)", worker cache-bust `playground.js?v=8` (README Deploying) | stale | Worker imports `../wasm/0.4.2/`; `index.html` references `playground.js?v=13`. Two engine bumps and five `?v=` bumps happened without the README section being updated | [Code-verified, High] |
| 7 | Lab Notes: "This page runs engine 0.3.5 WASM. crates.io latest is 0.4.0; npm is 0.3.2" | stale | Pinned tree ships 0.4.2; live site serves 0.4.1 ("Renderer v0.4.1 in this page", fetched 2026-09-22); npm registry latest is 0.4.4; engine GitHub releases reach v0.4.5. Every version number in the strip is wrong | [Verified, High] |
| 8 | "WASM Payload 1.8 MB gz" stat card; README artifact gzip 1,803,496 B | approximately demonstrated, stale-calibrated | Recomputed gzip of the receipt binary: 1,806,855 B vs README's 1,803,496 (0.19% off — a gzip-version/level artifact, not a different binary; sha and raw size match exactly). "1.8 MB" is consistent with both. Live payload (0.4.1 tree): gzip 1,859,952 B (1.86 MB) — the card is ~4% low against what production actually ships | [Counted, High] |
| 9 | Knuth–Plass visualization "runs a real total-fit DP" | demonstrated (with documented simplification) | `viz.js` L213–228: genuine total-fit dynamic program minimizing Σ(1 + badness/100)² over breakpoints; README Limitations discloses the simplification (no hyphenation/penalties/page-level concerns) | [Code-verified, High] |
| 10 | Fonts "self-hosted … 87 KB total" | demonstrated | `assets/fonts/*.woff2` total 88,660 bytes (86.6 KiB) — rounds to the claim | [Counted, High] |
| 11 | 0.3.5 artifact receipt: sha256 `1da66d98…`, raw 4,028,677 B | demonstrated | Recomputed from `assets/wasm/pkg/franken_markdown_bg.wasm`: sha matches exactly; `stat` reports exactly 4,028,677 bytes | [Counted, High] |
| 12 | Deploy is manual `wrangler pages deploy`; not Git-connected; `.nojekyll` for GH Pages | demonstrated | `.nojekyll` present; `_headers` Cloudflare-specific; README documents the manual flow and the non-connected state | [Code-verified + Maintainer claim, High] |
| 13 | Caching discipline: `max-age=0, must-revalidate` + `?v=` bumps on content change | demonstrated | `_headers` carries explicit rules for all six wasm paths (the "add a rule per version dir" instruction was followed); `index.html` uses `?v=13/9/6/2` across assets | [Code-verified, High] |
| 14 | Refresh workflow copies only parity-gated builds (`dev/refresh-engine-wasm.sh`) | partially demonstrated | Helper script exists (77 lines) and encodes the versioned-directory + `?v=`-bump discipline; the parity gate it trusts lives in the engine repo and its execution was not observed here | [Code-verified, Medium] on the script; gate [Not observed] |
| 15 | "I do not accept outside contributions" | demonstrated (policy, not code) | README "About Contributions" section states it verbatim; bus factor 1 by declaration | [Maintainer claim, High] |
| 16 | "CommonMark coverage … 379/652 examples (64.1% of in-scope)" | partially demonstrated (engine claim, re-published) | 379/652 = 58.1% raw; 64.1% decodes to ~591 in-scope examples (raw-HTML passthrough excluded as a stated non-goal: 379/591 = 64.13%). The "CI-ratcheted floor" half is delegated to the engine repo's CI | [Inference, Medium] on the arithmetic decode; ratchet [Not observed here] |
| 17 | The versioned `assets/wasm/0.3.5/` tree holds the README-documented 0.3.5 artifact | disproven | `assets/wasm/0.3.5/pkg/franken_markdown_bg.wasm`: sha256 `5c0135b3…`, raw 4,151,165 B — matches neither the receipt sha nor its byte count. Two different binaries in the tree both wear the 0.3.5 label; only the unversioned `assets/wasm/` tree matches the receipt (claim 11) | [Counted, High] |
| 18 | The live page consistently reports its engine version | disproven | Fetched 2026-09-22: the header strip says "Renderer v0.4.1 in this page" and body copy says "In this 0.4.1 WASM" — while the Lab Notes section on the same page says "This page runs engine 0.3.5 WASM." The live page contradicts itself | [Verified, High] |
| 19 | "Try it here, install it there" coherence: the page demos what npm installs | disproven | The page's install section points at `@franken-suite/franken-markdown`; the npm registry's latest is 0.4.4 while the page runs 0.4.1. A visitor who tries the demo then installs gets a different engine than the one they evaluated | [External + Verified, High] |
| 20 | Title-derived downloads (`# My Great Doc!` → `my_great_doc.html` / `.pdf`) | demonstrated | `playground.js` L590 documents the rule; L622–630 implement the slug (lowercase, underscores for spaces); L650 sets `link.download`; fallback `franken-playground` for untitled docs | [Code-verified, High] |
| 21 | Production matches the pinned tree (the kill test) | disproven (executed) | Ran `node dev/verify-live-assets.mjs` 2026-09-22: 8 stale of the refs checked — all five JS modules, `site.css`, and the 0.4.2 wasm wrapper + glue differ from the pin; fonts, og.png, and the 0.4.2 wasm **binary** match. The live wrapper/glue shas match *no* committed tree (neither 0.4.1's nor 0.4.2's) — production was deployed from a working tree that exists nowhere in the repo. Edge-transformation is ruled out: Cloudflare Pages does not rewrite asset bytes by default, and fonts, og.png, and the wasm binary all match exactly | [Verified, High] |

**What the inventory says in aggregate:** claims about *this site's own mechanics* (worker, share format — now proven by decoding a real share URL, static purity, caching, receipts, download naming) verify at High confidence — the site is, unusually, checkable. Claims about *currency* (which engine version, which `?v=`, how many checks) are stale across the board: documentation cadence lags code cadence by roughly two engine bumps. Claims about *engine properties* (parity, CommonMark ratchet) are delegated to the engine repo and re-published here without local re-proof. And the version-labeling itself is unreliable: two binaries share the 0.3.5 name (claim 17). The kill test was executed rather than merely proposed (claim 21): production is not reproducible from the pin — or from any commit.

## 4.4 Codebase tour

**Topology (74 files, [Counted, High]):** `index.html` (894 lines — the entire scroll narrative: hero, stat cards, playground section, pipeline explorer, typography lab, font surgery, dependency-graph comparison, comparison table, install/API docs, Lab Notes); `assets/css/site.css` (3,133 lines, committed compiled Tailwind v4 + custom design system); five JS modules (1,867 lines): `main.js` (317 — header, reveals, glitch text, hero terminal), `playground.js` (755 — editor, HTML/PDF toggle, maximize, share, downloads), `render-worker.js` (61 — the wasm host), `md-highlight.js` (211 — editor overlay highlighter), `viz.js` (523 — four visualizations); `assets/wasm/` (six version trees: 0.3.1, 0.3.2, 0.3.5, 0.4.1, 0.4.2, plus an unversioned tree that matches the README's 0.3.5 artifact receipt — apparently a legacy pre-versioning layout, [Inference, Medium]); `assets/fonts/` (2 woff2); `dev/` (24 `.mjs` scripts at 1,197 lines, the wasm-refresh helper, Tailwind source, plus screenshot/OG tooling); `screenshots/` (4 webp, "captured from production" per README — provenance not independently verified); `assets/img/og.png` (511 KB social-preview image); `_headers`, `robots.txt` (`Allow: /`), `.nojekyll`, `package.json` (bun scripts only; no runtime deps — `private: true`).

**Data flow, playground:** keystrokes → `playground.js` (textarea + overlay highlighter, char-for-char match; debounce 170 ms, per-format latest-wins coalescing, at most one render in flight) → `postMessage` → `render-worker.js` (module worker; `init()` once, then `renderHtml`/`renderPdf` per message) → `franken_markdown.wasm` (parser, theme, layout, fonts, DEFLATE, PDF writer) → transferable `ArrayBuffer`s back → HTML into a sandboxed `<iframe srcdoc>`, PDF into a Blob URL in the browser's native viewer (fallback "open PDF" button where inline viewing is unavailable, e.g. most mobile browsers) [Code-verified, High].

**Dependency posture:** zero runtime dependencies — no npm packages ship to the browser, no CDN, no analytics (see claim 3). Dev-only: Tailwind v4 CLI, playwright-core, sharp, fontsource-variable (for the CSS build), mri — all in `devDependencies`, none in the deploy path (the compiled CSS is committed; `dist/` for Pages is `index.html + assets + _headers + robots.txt + .nojekyll`) [Code-verified, High]. The wasm side: wasm-bindgen glue + binary, version-pinned in trio directories so wrapper/glue/binary update atomically — the design explicitly defeats edge-cache skew (old glue + new binary), and `_headers` carries a per-version MIME rule [Code-verified, High].

**Deploy pipeline:** `bun run css` → commit → `wrangler pages deploy dist` → Cloudflare Pages edge. Not Git-connected: a GitHub push does not deploy; production state is whatever a human last pushed via wrangler. Post-deploy verification is two manual commands: `until bun run verify:live; do sleep 10; done` (sha256-compares every live asset against the local tree — "verify content, not headers") and `bun dev/e2e.mjs https://franken-markdown.com/` [Maintainer claim, High — documented in README; execution not observed]. There is no `.github` directory: nothing in this repo runs on a schedule or on push [Code-verified, High].

**The six wasm trees (the weight finding):** 0.3.1 (3.2 MB), 0.3.2 (3.2 MB), 0.3.5 (4.1 MB), 0.4.1 (4.1 MB), 0.4.2 (4.1 MB), unversioned `assets/wasm/` (3.9 MB) — ~23 MB of the repo's 28 MB total [Counted, High]. Only `0.4.2` is referenced (by `render-worker.js`); five trees are unreachable dead weight, committed because the "atomic trio" discipline versions by directory instead of by tag. The 0.3.5 duplication (claim 17) is the sharpest edge of the discipline: directory-versioning without a manifest lets two different binaries share one version label with no record of which one production served.

## 4.5 Benchmark and conformance audit

There are no benchmarks in this repo. The auditable numbers are the site's *verification* claims, separated per the Rulebook:

**Maintainer-produced (this repo's own machinery):**

| Check | Methodology doc | Controls | Would it survive an independent rerun? |
|---|---|---|---|
| 30-check e2e (`bun run test`, Chromium headless vs localhost:8899) | `dev/e2e.mjs` is the doc; README table describes what each suite proves | All 30 checks run sequentially at top level (single early-exit if no Chrome binary found); "no console errors" assertion; share round-trip re-renders; maximize/escape; viz init checks | Yes — cheap to rerun (bun + playwright-core + one Chromium download). **But it was not run in this assessment, and nothing runs it on push** |
| `verify:live` (sha256 of every live asset vs local tree) | The 67-line script is its own doc; README Deploying section | Transitive closure: regex-scrapes `href/src="assets/…"` + og-image URLs from `index.html`, then follows the JS import chain (`from "…"` specifiers and `new URL(…, import.meta.url)`) and the wasm-bindgen glue to the `.wasm` binary — so a new reference can't silently escape verification. `?v=` is stripped for local reads but kept for remote fetches (verifying the cache-bust strings themselves); fetches use `cache: no-store` and report `cf-cache-status`; 12-char sha256 prefixes compared; nonzero exit on any stale asset. Compares content, not headers — explicitly defeats the propagation-window trap the maintainer was bitten by | Yes — and it was executed in this assessment (via node; the script is runtime-agnostic): 8 stale assets against production, exit nonzero — see claim 21. The tool works; what it reports is that production is not the pin |
| Stress (`bun run test:stress`): wasm-block sentinel (`WASM FAILED`, never hang) + 12 rounds interleaved typing/toggles | `dev/failure-and-stress.mjs` (76 lines) | Sentinel-based: failure must surface, never hang; ends consistent | Plausibly — small, self-contained |
| Firefox/WebKit smokes | `dev/firefox-smoke.mjs`, `dev/webkit-smoke.mjs` | Error-collection with nonzero exit on any error; Firefox runs with pdf.js off to exercise the PDF fallback path | Plausibly — needs one `bunx playwright install` per engine |

*Table convention: "Would it survive" judgments are the analyst's [Inference, Medium] unless marked; methodology and controls are [Code-verified, High] from the scripts themselves.*

**Re-published (engine repo's machinery, cited here):** "100% byte-identical HTML+PDF, gated in CI" and the 379-example CommonMark ratchet. Methodology, now read rather than assumed: `release-wasm.yml` L32 runs `scripts/check-wasm-package.sh release`, whose native↔wasm parity section renders a corpus through both the native binary and the generated wasm module and compares with `cmp -s`, logging byte counts and sha256 prefixes ("matches native byte-for-byte") plus a size-budget check [External, High — gate logic read, not just its filename]. Controls and rerun-survival: unassessed from this repo — this site cannot re-derive either number; it displays them. **Never cite the site's stat cards as results; they are citations of another repo's CI** [Inference, High].

**Reproduction cost (this repo's own claims):** `git clone` (28 MB), `bun install` (devDeps only), `bun run serve` (or any static server — `file://` fails on module+wasm), one `bunx playwright install chromium` for the browser binaries, then `bun run test`. Minutes, one machine, no credentials — with the caveat that the browser download is the only non-trivial step [Inference, High]. The site's *own* verifiability is its best property — and its least exercised, since no automation runs it [Inference, High].

**Independent numbers:** none exist for this repo (4 stars, 1 fork, zero third-party coverage found) [External, High within recall caveats]. The npm registry confirms `@franken-suite/franken-markdown` exists (latest 0.4.4, 5 versions) [External, High] — the package the site tells visitors to `npm install`.

## 4.6 Comparison: who owns the lane

The lane is *developer-tool marketing sites with live in-browser demos* — owned, in buyer perception, by Vercel/Next.js template sites, Docusaurus/Starlight docs sites, and the "playground" pattern (TypeScript Playground, Rust Playground, Go Playground, Tailwind Play): the incumbent wins on ecosystem, themes, and zero-effort deployment, in one paragraph [Inference, Medium]. Adjacent: wasm-pack demo pages and Observable notebooks own the "run real code in the page" sub-lane with far less hand-rolled infrastructure [Inference, Medium].

What is genuinely unoccupied: **the verifiable marketing site** — a product page whose every number is bound to a re-runnable check (sha receipts, a deploy verifier that diffs content rather than headers, a Lab Notes strip that confesses the gaps). No incumbent bothers, because no buyer currently selects tooling on "the demo's claims re-derive" — buyers select on the demo existing at all [Inference, Medium]. This repo's differentiation is therefore real but unpriced: it out-proves every competitor on a dimension the market does not shop for. The honest threat is not a competitor but the maintainer's own cadence: the verifiability story rots the moment the checks stop being run, and with no CI, "stop being run" is the default state [Inference, High].

## 4.7 Skeptic's take

**Strengths (substantive):**

1. **The demo is the product.** The playground doesn't simulate the engine — it *is* the engine, wasm-compiled, in a worker, with transferable buffers and a documented protocol. Most "live demo" marketing is a screenshot with extra steps; this one is evidence [Code-verified, High].
2. **Negative-evidence culture ported to marketing.** The Lab Notes strip, the Limitations section, and the `_headers` caching note (which records the maintainer's own stale-deploy incidents and their mechanism) are the marketing equivalent of `NEGATIVE_EVIDENCE.md`: confessed weaknesses with dates and mechanisms. Nobody in the lane does this [Code-verified, High].
3. **`verify:live` is a genuinely good deployment check.** A 67-line script that computes the transitive closure of everything the page references (index.html asset refs → JS import chain → wasm-bindgen glue → binary), fetches each live with `cache: no-store`, and compares sha256 — with the explicit rationale "verify content, not headers," and `cf-cache-status` reported per asset so edge-vs-origin staleness is distinguishable. Sharper than most teams' deploy verification [Code-verified, High].
4. **Privacy architecture, not privacy copy.** Share links work *because* URL fragments are never sent to the server and there is no backend to receive them — the property holds even if you distrust the operator. The ~30k-character ceiling and the "not encryption" disclaimer are stated plainly [Code-verified, High].

**Weaknesses (each substantive):**

1. **[HIGH] The transparency copy has drifted from the shipped binary — and the live page contradicts itself.** Lab Notes says 0.3.5; the tree ships 0.4.2; production serves 0.4.1; npm is at 0.4.4; the engine's GitHub releases reach v0.4.5. The component whose job is honesty is wrong about every version number it names, and the live page simultaneously claims 0.4.1 (header) and 0.3.5 (body) [Verified, High].
2. **[HIGH] No CI: the verification machinery is decorative until run.** Thirty e2e checks, a deploy verifier, a stress suite, two browser smokes — and no workflow file runs any of them, ever. The README's testing table reads as a gate; it is a set of manual incantations. Any regression between now and the next manual run ships silently [Code-verified, High].
3. **[MEDIUM] 23 of 28 MB is wasm, and 5 of 6 trees are dead — with two binaries sharing the 0.3.5 label.** The versioned-trio discipline versions by directory, so every engine bump permanently commits ~4 MB of unreachable binary, and claim 17 shows the labeling can silently fork: two different 0.3.5 binaries, no manifest saying which one production served [Counted, High].
4. **[HIGH] Production is not reproducible from the repo — and npm has lapped them both.** The kill test (claim 21) executed: 8 assets stale vs the pin, and the live wasm wrapper/glue match *no* committed tree — the atomic-trio discipline (wrapper+glue+binary update as one unit) is defeated at the deploy layer, not the edge cache: production pairs the 0.4.2 binary with glue from a working tree that exists nowhere in the repo. Manual `wrangler` deploys mean the repo cannot regenerate production's bytes. Meanwhile the page's install section points at npm, whose latest is 0.4.4. "Try it here, install it there" evaluates one engine and delivers another [Verified + External, High].
5. **[MEDIUM] The site re-publishes engine claims it cannot re-prove.** "100% byte-identical, gated in CI" and the 379/652 ratchet are citations of another repository's CI, displayed as the site's own stat cards. If the engine's gate ever weakens, this site's numbers go stale with no local sensor — the same drift class as weakness 1, one level up [Inference, High].
6. **[LOW] "No analytics" is an absence claim no visitor can verify.** The code supports it today (zero external URLs, zero identifiers), but a future commit could add a tracker and no check in the repo asserts its absence — the property is unguarded [Inference, Medium].
7. **[LOW] The rider on a billboard.** The MIT+OpenAI/Anthropic rider bars named labs (and anyone acting for them) from even *analyzing* the site's code — while the page's own "Agent-First CLI" copy courts AI agents as users. The exclusion is mostly symbolic for a marketing site, but the tension is real: the likeliest agent-evaluators are named Restricted Parties [Inference, Medium].

**Bear-case steelman (strongest counter-case):** This is a billboard with unusually good plumbing, not infrastructure. Its research value is exhausted the moment you accept that a static site's claims are only as fresh as its last manual verification run — and nothing here runs on its own. The drift ledger (stale Lab Notes, stale README deploy section, stale stat card, production lagging the pin, npm lapping them both, five dead wasm trees, two binaries sharing one version label) shows the maintainer's documentation cadence already can't keep up with his engine cadence *within a single quarter*, on a repo whose entire pitch is that nothing is faked. The rational response is to mine it for patterns (`verify:live`, fragment-share, versioned wasm trios, honest scar tissue) and treat the page itself as a depreciating asset: the moment the engine's interesting development moves elsewhere, this becomes 28 MB of pinned wasm history with a pretty scroll narrative on top. [Inference, Medium — deliberately uncharitable; the counter-evidence is that every stale item is *mechanically fixable* (generated strip, one workflow file, a pruning policy, a version manifest) rather than architecturally hard.]

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

**License text (read verbatim at the pin):** MIT License with OpenAI/Anthropic rider (`LicenseRef-MIT-OpenAI-Anthropic-Rider`), copyright 2026 Jeffrey Emanuel, "matching the engine repo." The rider's scope, quoted: **Restricted Parties** are "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)"; "no rights are granted to any Restricted Party" absent the author's express prior written permission; barred "use" "includes, without limitation: copying, modifying, merging, publishing, distributing, sublicensing, selling, transferring, making available, hosting, deploying, executing, benchmarking, testing, analyzing, indexing, or incorporating the Software or any Derivative Works into any dataset, training corpus, evaluation harness, or pipeline for machine learning or other automated systems"; breach "automatically and immediately terminates" all permissions, with injunctive relief and prevailing-party attorneys' fees; "Affiliate" = >50% voting control or power to direct management/policies. **Classification: non-OSI, source-available** — the named-party discrimination fails OSD §5 and the benchmarking/analysis bar fails OSD §6 [Inference, High — legal conclusion, not legal advice]. One point in this repo's favor versus its sibling: the README's license badge reads "MIT + OpenAI/Anthropic rider" — the rider is disclosed in the badge itself, not buried [Code-verified, High]. For the record: this assessment's analyst is not a Restricted Party and acts for the research program, not for or at the direction of any named lab — the rider's "analyzing" bar does not facially cover this packet, though its expansive "acting for the benefit of" prong is the same ambiguity the engine packet confronts [Inference, Medium — legal conclusion, not legal advice].

**Governance:** bus factor 1 by explicit declaration — "I do not accept outside contributions for any of my projects… it's my name on the thing" (README, quoted in substance). Issues and illustrative PRs welcome; merges are not. Single human author on the pinned commit; 4 stars / 1 fork [External, High]. Deploys are manual (`wrangler pages deploy`, not Git-connected), so the production site is whatever the maintainer last pushed — the 0.4.1-live vs 0.4.2-pin lag is the observable consequence [Verified, High]. No succession plan, no second committer, no foundation. Deploys are not reproducible from the repo: the kill test shows production's JS layer matching no commit, so "the pin" is not a buildable description of the live site — there is no deploy provenance at all [Verified, High]. **What breaks first if velocity decays:** the version-sensitive copy (already broken — Lab Notes, README deploy section, stat card), then the manual verification loop (already never automated), then the wasm trees go stale while the page keeps claiming currency. The decay sensor is the pin-vs-production version gap [Inference, Medium].

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness | **TRL 8** | Complete system deployed and serving at franken-markdown.com with local test/verify suites — but production (0.4.1) lags the assessed pin (0.4.2) and no automation runs the suites [Inference, Medium] |
| Strategic relevance | 2/5 | The engine's credibility surface, not program infrastructure — it markets the thesis rather than advancing it [Inference, Medium] |
| Impact potential | 2/5 | The *pattern* (verifiable marketing) is the exportable impact; the page itself moves no market [Inference, Medium] |
| Implementation feasibility | 5/5 | Scored on the website object: static files, and the patterns (`verify:live`, fragment-share, versioned wasm trios) are copy-paste adoptable at trivial cost [Inference, High] |
| Time to mainstream | 5/5 | Scored on the website object: it is live now; the open question is maintenance, not arrival [Inference, High] |
| Collaboration potential | 1/5 | Contributions explicitly refused; bus factor 1; the rider bars the likeliest agent-collaborators from analyzing the code [Inference, High] |

**Ring: Monitor** [Inference, High]. The Rulebook assigns websites to Monitor explicitly, and the factsheet earns it independently: a finished, deployed, genuinely checkable artifact whose program value is methodological rather than advancement-track. No Rulebook amendment; v1.0 stands. The honest alternative reading — "it's deployed and working, ring it higher" — confuses *artifact maturity* with *program advancement candidacy*: there is nothing to pilot here, only something to learn from [Inference, High].

**Methodology fit (for the FrankenSuite):** adopt the patterns, not the page — `verify:live` (content-compared deploy verification), the fragment-share privacy architecture, the versioned wasm-trio discipline, and the Lab Notes negative-evidence strip are directly importable into how the program presents the other 43 repositories' results. Do not depend on the page's engine numbers: the stat cards are citations of the engine repo's CI, and the strip displaying them is two versions stale.

## 4.10 Wardley placement

Placing the *components*, not the repo:

- **Commodity — static hosting, WASM as a delivery vehicle, Tailwind.** Cloudflare Pages, `application/wasm` MIME, utility CSS: table stakes. Moves only if the platform moves (a Pages behavior change is exactly what the `_headers` scar tissue documents) [Inference, Medium].
- **Custom-built, product — the playground/worker integration + `verify:live` loop.** The module-worker protocol with transferable buffers and the sha-compared deploy verifier are the repo's real engineering. Moves right if extracted as documented patterns other FrankenSuite repos adopt; stays repo-local tooling while there is no CI to run it [Inference, Medium].
- **Custom-built, closest to a standard — the fragment-share URL format.** `zdoc=`/`doc=` + `view=`/`fmt=` params are a small, complete, backendless sharing protocol. Moves right if a second implementation exists (next step 2); otherwise it is a one-site trick [Inference, Medium].
- **Genesis — verifiable marketing as a discipline.** Every displayed number bound to a re-derivable artifact, scar tissue published as content, deployment verified by content-hash rather than header-poll. No DevTools-marketing incumbent does this. Moves right if the stat cards become self-falsifying (next step 1); stagnates as a pretty page with a stale honesty strip if the drift class is not mechanized away [Inference, Medium].

**Residual product gaps:**

1. The Lab Notes strip is hand-maintained copy — the drift class has no sensor.
2. No CI: the e2e/verify/stress/smoke suites are manual-only.
3. Dead wasm trees accumulate (~4 MB per bump, no pruning policy) — and two binaries share the 0.3.5 label with no manifest.
4. Production-vs-pin lag is invisible to visitors (only the "Renderer vX" strip hints at it).
5. Engine-claim citations (parity, CommonMark ratchet) have no local re-proof.
6. The "no analytics" property is unguarded by any check.
7. Mobile PDF is a fallback button, not a preview (documented, accepted).
8. Share links cap at ~30k characters (documented, accepted).

## 4.11 Trajectory (12 / 24 / 60 months)

All horizons **[Inference]** — forecasts, not findings; confidence Low unless noted.

**12-month base case [Inference, Medium]:** the engine keeps shipping; the site absorbs bumps by hand; the Lab Notes strip lags further (it is already two versions behind); production keeps trailing the pin by one manual deploy; npm keeps lapping the page; wasm dead weight grows ~4 MB per bump. The `verify:live` script keeps working because it is simple. Ring: Monitor, unchanged.

**24-month base case [Inference, Low]:** either the drift class gets mechanized (generated strip, one workflow file, pruning policy, version manifest — all cheap, all named in this packet) and the site becomes the durable template for the program's public evidence surfaces; or the engine's development arc completes and the site freezes as a 28-plus-MB monument to v0.4.x. The base case leans toward the second shape on bus-factor-1 priors — unless the mechanization happens, the scar tissue keeps accumulating.

**60-month base case [Inference, Low]:** the page is either the long-lived front door of a mature engine (in which case the verifiability patterns have been copied widely and the original is a historical artifact) or a frozen demo whose wasm no longer matches any shipping engine. The patterns outlive the page either way.

**Bifurcation — what the upside requires:** (a) the Lab Notes strip generated from the wired wasm version at deploy time; (b) one scheduled workflow running e2e + `verify:live` against production; (c) a wasm-tree pruning policy; (d) a version manifest binding each wasm tree to its engine commit and sha. All four are hours of work, not architecture — the upside is gated on the maintainer spending an afternoon on plumbing, which is why it might actually happen [Inference, Medium].

**Bifurcation — what decay looks like:** the pin-vs-production gap widens past one version, the strip's version numbers go three-plus stale, `verify:live` stops being run because the `?v=` discipline slips, and the page becomes exactly what its TL;DR mocks: a pretty claim about an engine, adjacent to the evidence rather than made of it. Decay is the default for hand-maintained marketing with no automation [Inference, Medium].

**Revisit triggers (observable, falsifiable):**

1. **A `.github/workflows` directory appears** — the manual-only finding flips; re-audit what the automation actually runs.
2. **The Lab Notes strip matches the wired wasm version** — the drift class is being managed; check whether by generation or by hand.
3. **Production's "Renderer vX" matches the repo's wired version** — the deploy-lag finding closes.
4. **Wasm trees pruned, or a pruning policy / version manifest documented** — the dead-weight and dual-0.3.5 findings close.
5. **Rider narrowed or removed** — LICENSE diff; flips the agent-collaborator exclusion (relevant because the page courts agents).
6. **Contributions policy changes** — README "About Contributions" amended; flips bus-factor-1 governance.
7. **Site archived or domain lapsed** — re-ring to retired artifact; the patterns remain the export.

## 4.12 Verdict & NODUS ring

**NODUS ring: Monitor.** The Rulebook's website bucket, and the factsheet earns it independently: a finished, deployed, genuinely checkable artifact whose program value is methodological rather than advancement-track. There is nothing to pilot — no bounded workload, no release artifact in the software sense — and nothing to explore in the maturity sense (it is already deployed). What the program should do with it is stated in §4.9: extract the patterns (`verify:live`, fragment-share, versioned trios, Lab Notes strip), and treat the page as a standing worked example of prove-don't-promise marketing — while noting, honestly, that the example is currently failing its own standard on currency [Inference, High]. No Rulebook amendment; v1.0 stands.

**The one-paragraph case:** The FrankenMarkdown website is the rare marketing site whose central technical claims re-derive from its own tree — the playground really is the wasm engine in a worker, the share format is exactly as documented, the 0.3.5 artifact receipt re-computes on sha and byte count, and the caching docs confess real production incidents. But the credibility apparatus it sells has no automation behind it (no CI; every check is a manual `bun run`), its honesty strip is two engine versions stale, the live page contradicts itself on which engine it runs, two different binaries in the tree share the 0.3.5 label — and the packet's kill test was executed, not hypothesized: `verify:live` against production reports 8 stale assets with the wasm glue matching no commit, exit nonzero. A billboard with excellent plumbing and no plumber on schedule: mine it for patterns, enjoy the demo, and don't mistake the Lab Notes for a live instrument. [Inference, Medium]

## 4.13 Limitations and open questions (analyst-facing)

**What was not done:** no test suite was executed (`bun run test`, `test:live`, `test:stress`, both smokes — no browser automation in this sandbox); the wasm binary was never executed (the "runs the real engine" claim is verified by import-graph and protocol inspection, not by rendering); the CSS was not rebuilt; the engine repo's `check-wasm-package.sh` gate was confirmed to exist but its execution/greenness was not observed; the crates.io crate page could not be fetched (API returned empty 200s; page fetches 403 to non-browser clients) — npm registry data was used instead; the live site was read as fetched text only (no interaction, no console observation); git history beyond the shallow pin was not examined (single commit — velocity/authorship-over-time analysis impossible); `playground.js` was read selectively (share format, debounce, worker protocol), not line-by-line.

**Open questions that would most change the verdict, in order of load-bearing weight:**

1. **Do the 30 e2e checks pass against production right now?** A single `bun run test:live` would falsify or confirm the whole "prove-don't-promise" thesis in minutes — and this assessment could not run it. This is the packet's kill test (deepening question 8).
2. **Is the engine's wasm parity gate actually green?** The site's "100% byte-identical, gated in CI" card cites the engine repo's `release-wasm.yml`; if that gate is red or skipped, the site's flagship stat is a citation of a failing check.
3. **Which 0.3.5 binary did production serve, and why do two exist?** The versioned tree and the receipt-matching unversioned tree differ (claim 17); a version manifest or the maintainer's answer would settle whether this is deliberate archiving or forgotten cleanup.
4. **What is the 379/652 CommonMark methodology?** The "64.1% of in-scope" decode is arithmetic, not evidence; the ratchet's definition of in-scope lives in the engine repo.
5. **Does the maintainer run `verify:live` after every deploy?** Partially answered: the script runs cleanly (executed in this assessment), but production's state — 8 stale assets, glue from no commit — shows it was either not run after the last deploy or was run against a different tree than the pin. Either way the loop is not closed.
6. **What does the crates.io page actually show?** Unverifiable from this sandbox; the Lab Notes' "crates.io latest is 0.4.0" could not be checked against the registry page.

---

## Deepening questions — Rulebook §5's binding eight, one paragraph each

*§5→location mapping: Provenance ← the versioned wasm trios + artifact receipt (claims 11, 14, 17); Embeddable unit ← the fragment-share protocol (claim 4); Unexercised option value ← the unrunnable-in-CI suites + dead wasm trees; Benchmark honesty ← §4.5 plus the gzip-leg audit in Q4; Governance path ← §4.8 + §4.7 weakness 2; License as strategy ← §4.8 + §4.7 weakness 7; Agent-era fit ← the page's "Agent-First CLI" copy vs the rider; Kill test ← §4.7's steelman + §4.13 open question 1.*

**1. Provenance.** The repo records *what* produced each artifact better than most marketing sites: wasm lives in version-named trios so wrapper, glue, and binary update atomically; the README pins the 0.3.5 artifact's sha256 and byte counts (sha and raw size re-derived exactly in this assessment; the gzip leg misses by 0.19%, a compression-version artifact); and `verify:live` re-derives every production asset's hash at deploy time [Counted, High]. What nothing records is *which engine commit* a wasm binary was built from — there is no build attestation, no SLSA-style provenance, no link from `assets/wasm/0.4.2/` back to a `franken_markdown` commit or CI run; the refresh helper copies files out of a local `target/` directory, so the chain of custody is the maintainer's laptop — and claim 17 (two different 0.3.5 binaries, no manifest) shows the labeling can fork silently [Code-verified, High]. Portable attestation would require the engine repo's `release-wasm.yml` to emit signed provenance binding each published wasm to its source commit, which the site could then display the way it displays the sha receipt — the receipt pattern is already the right UI, it just attests to the wrong end of the pipeline (the vendored file, not its build) [Inference, Medium].

**2. The embeddable unit.** The smallest useful piece adoptable without the whole repo is the fragment-share protocol: ~40 lines of `playground.js` (deflate-raw via `CompressionStream`, base64url, `#zdoc=`/`#doc=` + `#view=`/`#fmt=` params) implement backendless document sharing with a genuine privacy property (fragments are never sent to the server) [Code-verified, High]. Adoption cost is near zero — copy the encode/decode pair, no server, no dependency — and the format is proven interoperable by construction: the analyst decoded the README's example URL with stock Python (`urlsafe_b64decode` + raw inflate), no project code involved. The adopter inherits two undocumented constraints: the ~30k-character practical URL ceiling (stated in the README, untested here) and the absence of a version marker in the format itself (a future `zdoc` variant would need one) [Inference, Medium]. The runner-up is the module-worker + transferable-`ArrayBuffer` render protocol in `render-worker.js` (61 lines), the minimal pattern for off-main-thread wasm with zero-copy result delivery [Code-verified, High].

**3. Unexercised option value.** Three held capabilities. First, the e2e/verify/stress/smoke suites are CI-ready in every respect except the one file that would run them — playwright-core works headless, the suites take URLs as arguments (`test:live` already targets production), and the repo's own README describes them as gates; a single scheduled workflow would convert manual incantations into actual gates [Inference, High]. Second, the six wasm trees are an accidental version archive — with a manifest (version → engine commit → sha → live-or-retired) it becomes a reproducible history of the engine's web-facing releases instead of 23 MB of unexplained binaries, and the manifest would have prevented the dual-0.3.5 fork of claim 17 [Inference, Medium]. Third, the OG-image tooling (`dev/og-render.mjs`, `og.html`) exists but `assets/img/og.png` is a static file — the social-preview image could be regenerated per engine bump the way screenshots are claimed to be ("captured from production") [Inference, Low]. What unlocks each: one YAML file; a `WASM_MANIFEST.md`; wiring the existing render script into the refresh helper [Inference, Medium].

**4. Benchmark honesty.** The numbers most likely to survive an independent rerun are the site's *own* mechanical claims, and the audit is encouraging with one honest blemish: the 0.3.5 sha256 and 4,028,677-byte count re-derived exactly, but the receipt's gzip leg (1,803,496 claimed vs 1,806,855 measured, 0.19% off) does not reproduce — gzip output varies by version and level, so the figure was never re-derivable in the first place, and the packet's v1 draft overstated the receipt as fully exact [Counted, High]. The font total (88,660 B vs "87 KB"), the zero-external-URL / zero-analytics findings, and the share-format mechanics are re-derivable by anyone with the clone [Code-verified, High]. The numbers that would *not* survive exactly: "28-check" (30 counted), "1.8 MB gz" (1.86 MB for the live 0.4.1 payload — approximately right, stale-calibrated), and every version number in the Lab Notes strip (all wrong). Which numbers are load-bearing for the thesis? Two: "the playground runs the real engine" (verified via the import graph and worker protocol — the load-bearing claim, and it holds) and "byte-identical, gated in CI" (delegated to the engine repo; the gate exists but its greenness is unobserved — the thesis's single point of faith) [Inference, High]. No independent reproduction of anything on this page is known to exist [External, High within recall caveats].

**5. The governance path.** There is no credible route from one maintainer to an institution, because the maintainer has explicitly closed it: "I do not accept outside contributions for any of my projects" (README) [Maintainer claim, High]. The realistic paths are therefore succession-by-fork (anyone may fork; the license permits it, rider and all) or institutional adoption of the *patterns* without the repo — both of which are already available and neither of which needs the maintainer [Inference, Medium]. What breaks first if velocity decays is already observable: version-sensitive copy (Lab Notes, README deploy section, stat card — all stale today), then the manual verification loop (never automated, so "decay" just means "stops"), then the wasm trees freeze while the page keeps asserting currency — the pin-vs-production gap is the sensor, currently reading one version [Inference, Medium].

**6. The license as strategy.** The rider excludes exactly: OpenAI, L.L.C.; Anthropic, PBC; their affiliates (>50% voting control or direction power); and anyone acting for, benefiting, or directed by them — barring "use" defined to include "executing, benchmarking, testing, analyzing, indexing" plus training-corpus incorporation, with automatic termination and injunctive relief [Code-verified (license text), High]. On a marketing site the exclusion is near-symbolic as *strategy*: nobody adopts a billboard as a dependency, so the practical cost is not adoption but *scrutiny* — the named labs and their agents may not analyze the demo's code, which is awkward because the page explicitly courts AI agents ("Agent-First CLI," `robot-docs`, JSON CLIs) as evaluators [Inference, Medium]. Does it serve or sabotage the stated mission? For the engine, the rider is defensive (deny training corpora curated code); for the *website*, it is pure posture — it costs nothing in adoption while creating a visible tension with the agent-facing copy. The one unambiguous service: the badge discloses the rider ("MIT + OpenAI/Anthropic rider") rather than printing a bare "MIT" — the exclusion is at least honest [Code-verified, High].

**7. Agent-era fit.** The concrete agent workload that would pick this page over the incumbent (a GitHub README, a Docusaurus site) is *evaluation*: an agent benchmarking Markdown renderers can drive the real wasm engine in a real browser, read structured parser diagnostics from the worker protocol, and share repro cases as self-contained URLs — the page is already shaped like an eval harness with marketing on top [Inference, Medium]. What would have to become true first: the rider narrowed (the likeliest agent operators — the named labs — are currently barred from even *analyzing* the code, though driving the public page in a browser is arguably use rather than analysis, a distinction the rider's expansive "use" definition deliberately blurs) and the version drift fixed (an eval pinned to "0.3.5" per the Lab Notes would actually execute 0.4.1 — a provenance failure in an evaluation context) [Inference, Medium]. The fit is real but self-sabotaged: the site courts agents as users while its license names their operators as Restricted Parties [Inference, High].

**8. The kill test.** The single experiment that would falsify the core thesis — that this is prove-don't-promise marketing rather than promise marketing — is the one the repo built for itself and never automates: run `verify:live` and `test:live` against franken-markdown.com and publish the pass/fail. **It was executed in this assessment** (`node dev/verify-live-assets.mjs`, 2026-09-22): 8 stale assets, exit nonzero — the thesis fails its own machinery at the production layer, while the engine binary itself (the load-bearing claim) matches byte-for-byte. The honest reading is split: "the playground runs the real engine" survives (the 0.4.2 binary is live); "every deploy is verified" does not (the surrounding layer is from no commit) [Verified, High]. `test:live` (the 30 e2e checks against production) remains unrun — no browser automation in this sandbox — and is the still-open half of the kill test [Inference, High]. The secondary falsifier is the engine's parity gate: if `release-wasm.yml` in the engine repo is red or skipped, the "100% byte-identical" stat card is a citation of a failing check and the flagship number falls [Inference, Medium]. The production checklist — what "prove it" requires, scored at the pin: CI workflow present (no), Lab Notes matching the wired engine (no), production matching the pin (no — 0.4.1 vs 0.4.2), `?v=`/trio discipline followed (yes), artifact receipts re-derivable (yes, modulo the gzip leg), engine gate observed green (unobserved). Score: 2 of 6 fully met, 1 unobserved [Inference, Medium].