# FrankenCodeBrowser — RULEBOOK v1.0 Assessment Packet v5

**Repository:** `Dicklesworthstone/franken_code_browser` · **Language:** Rust [Code-verified, High] · **Pinned commit:** `cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e` (2026-09-22 10:39:48 −0400 / 14:39:48 UTC, [Git-observed, High]) · **Last push:** 2026-09-22 15:20:17 UTC per GitHub API [External, High] · **Repo created:** 2026-09-12T19:29:20Z — the repository is ten days old at the pin [External, High] · **Scope:** the pinned commit only. No tags, no releases [External, High]. *Cold-reader note: "v5" = fifth and final draft of this packet (rewrite-loop round 5); the repo's own "G0–G7" are product gates, not packet versions. A "bead" is this repo's issue-tracker work item.*

**Method (analyst):** shallow clone checked out at the pin under `~/workspace/.scratch/fcb` (489 `.rs` files / 147,429 lines counted over `crates/`, verified non-empty); history deepened to 206 commits for the velocity/authorship sample only — the working tree stayed at the pin. Read: README.md (all 232 lines), LICENSE (verbatim), ARCHITECTURE.md, IMPLEMENTATION_STATUS.md (snapshot dated 2026-09-14), ROADMAP.md, CHANGELOG.md, DEPENDENCY_CONSTITUTION.md, AGENTS.md, root `Cargo.toml`, all 15 workspace manifests, `Cargo.lock`, per-crate `src/lib.rs` heads, `fcb-bridge/src/atlas_ffi.rs` and `lib.rs` and `Cargo.toml`, `fcb-app/src/main.rs`/`args.rs`/`desk.rs`, `fcb-store/src/lib.rs`, `fcb-render/src/lib.rs`, `fcb/src/lib.rs` + `fcb/src/search.rs` + `fcb-search/src/lib.rs` + `fcb/src/search/snapshot_index.rs` heads, `.beads/issues.jsonl` (438 issues sampled), the "delivered retained Metal renderer" and "tile-memory renderer" commit diffs (`--stat` only), and plan §9.9/§21.9 ("multi-resolution" context). One web search run for Rust peer code browsers. Counted: `.rs` files/lines per crate, `forbid(unsafe_code)` gates, `unsafe` occurrences excluding lint gates. **Not done:** no Rust toolchain exists on the analyst VM (`cargo`/`rustc` not installed) — the workspace was never compiled, no test suite was executed, no benchmark was reproduced; all test-count and "green suite" claims below are therefore [Maintainer claim], never verified by the analyst. GitHub API read for stars/forks/releases/tags only. Assessment date: 2026-09-22.

**Tier legend (Rulebook §1):** **[Verified]** direct inspection of the pinned clone or a live page read by the analyst — flavors **[Counted]** (I ran the count), **[Git-observed]** (git metadata), **[Code-verified]** (source read); **[CI-observed]** is Tier 2 (seen executing on live CI pages — attests the suite *runs*, not that it is green); **[Maintainer claim]** asserted in README/docs/beads, not independently executed; **[External]** independent sources; **[Inference]** analyst judgment, always labeled. Confidence: **High** / **Medium** / **Low**.

---

## Hook

A 147,429-line [Counted, High], ten-day-old source browser — about 14,700 lines per day of repo age (~24,600 per day over the six-day commit window) [Counted, High; the rates are arithmetic] — whose own README disavows every headline feature ("no application, executable, installer, or benchmark result yet") [Code-verified, High]. The disavowal is honest, and it undersells the tree: the pin already contains a real CLI binary, persistent reading desks, a paged-postings search index with a documented trust boundary, and 206 commits of foundation code [Code-verified, High]. But the same repo hides two breaks the disavowal doesn't cover: its C-ABI bridge crate ships real `pub unsafe extern "C" fn` functions in direct violation of the project's non-negotiable "all crates forbid unsafe" contract [Code-verified, High], and the Metal renderer whose delivery was "recorded" on September 21 lives in a sibling repository with no configured remote — the recording commits are docs-only [Git-observed, High]. The honest README is the most candid self-description assessed in this program to date [Inference, Medium — comparative judgment over the packets completed so far, not a measured ranking]; the governance it describes is the weakest.

## TL;DR

- **What it is:** A clean-room Rust source browser and embeddable library (15 workspace crates, 147,429 first-party lines at the pin [Counted, High]) aiming at a spatial, read-only, Metal-native macOS code atlas. Single human maintainer (Jeffrey Emanuel) with named agent personas, under extreme-velocity development: 206 commits across 2026-09-17→22, peaking at 101 commits on 2026-09-17 and already decelerating to 4 on pin day, with a zero-commit gap on 09-20 [Git-observed, High].
- **Strongest evidence:** The README's self-disavowal is total and specific (quoted verbatim in claim 2) — this is the only assessed repo that cannot be caught in README drift *by construction*, because it claims nothing is built. The anti-fabrication engineering culture is written into agent instructions (AGENTS.md names "demo hardcoding," "proof laundering," "refusal farming," and "commit pumping" as reopenable defects) [Code-verified, High]. 438 tracked issues, 231 closed [Counted, High], with verification receipts recorded as bead comments.
- **Strongest doubts:** No product exists that a third party can run: no CI workflows (the `.github` directory contains only issue templates [Verified, High]), no tagged release, no signed artifact; all "green suite" claims rest on the maintainer's "strict remote" runs, which no outsider can reproduce or audit. The unsafe-code constitution is already violated in-tree (claim 12). The design's named foundations are absent from the dependency graph: asupersync has **zero** Cargo edges anywhere in the tree [Counted, High], FrankenSQLite has zero, and franken_markdown is a local-path dev dep (`../../../franken_markdown`) [Code-verified, High] that the constitution itself bars from release. The "facade" crate is really a 31,916-line feature-gated integration monolith, and the native shell routes through the *application* crate — two layering inversions of the documented architecture (claims 19, 20).
- **Brief corrections (the parent brief is stale on four points):** the repo contains zero mentions of FrankenRedis (storage is plain-file cache namespaces, claim 10); "multi-resolution" in the plan means atlas LOD summaries, not semantic indexing (claim 18); the only latency figure is an explicitly unmeasured objective (claim 14); and the repo has 2 stars, not ~11 (claim 13) [Code-verified/External, High].
- **NODUS ring: Explore** [Inference, Medium] (TRL 2–3 — see §4.9). Substantive-but-unproven is the textbook Explore case; the rider is an advancement blocker (Explore-with-a-ceiling), not a ring qualifier. The methodology to track is the *anti-fabrication process discipline*, not the software.

## Quick Links

Pin-relative links (`blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e`); all returned HTTP 200 when fetched 2026-09-22 [Verified, High]:

1. [Repository](https://github.com/Dicklesworthstone/franken_code_browser)
2. [README (the disavowal)](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/README.md)
3. [License (MIT + OpenAI/Anthropic rider)](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/LICENSE)
4. [Implementation status (snapshot 2026-09-14 — note staleness)](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/IMPLEMENTATION_STATUS.md)
5. [Architecture](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/ARCHITECTURE.md)
6. [Dependency constitution](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/DEPENDENCY_CONSTITUTION.md)
7. [Roadmap (G0–G7 product gates, all pending)](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/ROADMAP.md)
8. [Local qualification and release](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/LOCAL_QUALIFICATION_AND_RELEASE.md)
9. [Agent instructions (the anti-fabrication rules)](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/AGENTS.md)
10. [Comprehensive plan (309 KB, 97 work packages)](https://github.com/Dicklesworthstone/franken_code_browser/blob/cc8330d18b8da7b4ebd3571458fd51ef5d9d0a3e/COMPREHENSIVE_PLAN_FOR_FRANKEN_CODE_BROWSER.md)

*Deliberately absent from this list:* there are **no CI workflows** to link — `.github/` holds only issue templates [Verified, High]; there is **no changelog of shipped features** (CHANGELOG.md covers only the documentation bootstrap [Code-verified, High]); there are **no releases** [External, High].

## Did You Know

The commit that "delivered" the retained Metal renderer on September 21 (`8a9b7e5`) changed exactly **one file** — `.beads/issues.jsonl`, the internal issue tracker [Git-observed, High]. The actual native renderer code lives in a sibling repository, `franken_macos`, which the commit message itself admits "has no configured remote" [Git-observed, High]. A delivered native renderer with no repository you can clone: this is the project's process machinery working exactly as designed (evidence recorded as tracker receipts) and simultaneously the cleanest possible illustration of why that machinery is not a substitute for auditable artifacts. [Inference, Medium on the characterization; the file facts are High.]

## Franken-worthy next steps

1. **Export the anti-fabrication defect list into the program's QA protocol.** AGENTS.md names demo hardcoding, proof laundering, refusal farming, commit pumping, gate self-weakening, and follow-up laundering as coordinator-reopened defects. FrankenRedis showed us the negative-evidence ledger; this repo shows the *fabrication taxonomy*. *Done when:* the six named anti-patterns are written into the FrankenSuite assessment protocol as automatic packet red flags. [Inference, High — process proposal]
2. **Run the closure-audit probe suite against one sibling repo.** `tests/test_closure_probe.py`, `test_closure_probe_adversarial.py`, and `test_extension_ledger.py` are Python probes that audit dependency closure and extension ledgers [Code-verified, High on existence; behavior not executed]. *Done when:* the probes execute against a second FrankenSuite repo and produce a machine-readable closure report, proving the tooling generalizes. [Inference, Medium]
3. **Falsify the "real CLI" claim on target hardware.** `fcb-app` ships `main.rs` calling `fcb_app::run`, and `args.rs` parses Search/Read/Open/Inspect/Doctor/Capabilities/Launch with bounded stdio framing — but no analyst has compiled or run it, and execution is unobserved by any third party [Code-verified, High on the source; execution unobserved]. *Done when:* an unaffiliated party on Apple Silicon builds the pin and runs `fcb search`/`fcb doctor --json` against a real corpus, recording pass/fail per command. [Inference, High]
4. **Adopt the "inert by construction" facade as an embeddability conformance test.** The `fcb` crate's additive `FeatureSet` with empty defaults, host-selected services, and no process-global side effects on construction is a stricter embeddability contract than most libraries publish [Code-verified, High on the design]. *Done when:* the existing two-instance isolation test (`examples/fcb-two-instance-host/tests/two_instance_isolation.rs`) is executed and passes inside a genuinely foreign host process — not merely present in-tree. [Inference, Medium]
5. **Measure the status-doc half-life.** IMPLEMENTATION_STATUS.md's 2026-09-14 snapshot already contradicts the tree on 2026-09-22 (it says "standalone `fcb` executable not implemented"; `fcb-app/src/main.rs` exists). Track README-vs-code drift *as a velocity tax* across the program. *Done when:* a repeat audit of this repo in 30 days re-measures doc staleness in days, establishing whether the process machinery (which updates beads) systematically under-updates human-readable docs. [Inference, Medium]

## 4.1 Why it exists — the market problem

**The problem, as the maintainer frames it:** following search hits across tabs and file trees loses spatial context; a "repository atlas" that gives directories and files stable places, with zoom from structure down to readable source, would keep a developer oriented in very large trees [Maintainer claim, Medium]. The plan's scale target is explicit: a qualified standard workload of ~100,000 files / 10 million lines, with stress qualification at ~1M files and 10–20 GiB of source [Maintainer claim, High — README "Performance objectives"]. This is a reading-and-navigation problem, not an editing one: the product is deliberately read-only, with no builds, debuggers, terminals, or compiler execution in scope for the initial release [Maintainer claim, High].

**Who feels the pain:** developers navigating unfamiliar massive codebases — onboarding, incident archaeology, codebase-scale code review [Inference, Medium]. The human-developer framing in the maintainer's plan is explicit (the README positions it as a browsing product, not an agent tool) — note the deliberate tension with Q7 below, where the analyst argues the strongest *future* fit is agent-shaped; the maintainer's positioning and the analyst's inference are labeled separately throughout.

**Why now:** Apple Silicon unified memory (the first GUI targets M4/M5 with ≥24 GB) makes retained in-memory atlases and glyph caches plausible at 10M-line scale [Maintainer claim, Medium]. Whether that hardware argument is load-bearing or decorative is untestable — no performance number in the repo has been measured (README: "**None of these numbers has been measured in FCB**") [Maintainer claim, High].

**Demand-side check:** there is no market demand evidence anywhere in the assessed materials — no users, no issues from outsiders, no downstream consumers, no independent coverage of the repo beyond the repository itself [External, Medium within recall caveats — one web search run 2026-09-22]. The repository is ten days old [External, High]. Demand is pure maintainer thesis [Inference, High].

**Adjacent context:** this is one entry in the solo-maintainer FrankenSuite of clean-room Rust reimplementations, but unlike the storage/runtime siblings it is a *product* (a browser), not infrastructure. Its named dependencies are the suite's own: Asupersync (runtime orchestration), FrankenMarkdown (document engine), FrankenSQLite (persistence), FrankenTUI/FrankenNetworkX/FrankenTerm/FrankenManim/FrankenThreeD (narrow utilities), and CASS (evidence-selection policy) [Maintainer claim, Medium]. None of these dependencies exists as a Cargo edge in the pinned tree (see claims 9–11) — the ecosystem integration is design, not code [Code-verified, High].

## 4.2 What it is — repo TL;DR

The purpose in one sentence: a foundation layer for a spatial, read-only, Metal-native source browser — a "repository atlas" that gives directories and files stable zoomable places instead of tabs. The structure: a 15-crate Cargo workspace (root `Cargo.toml` verified at the pin [Counted, High]) plus one workspace-excluded crate (`fcb-reader` — a 436-line exact-source reading lens, FCB-019.A, kept out of the workspace with its own `Cargo.lock`, apparently an extraction experiment [Code-verified, High]). The crate named `fcb` is **not** the "inert public facade" the README/ARCHITECTURE.md describe — at 31,916 lines [Counted, High] it is a feature-gated integration monolith: facade re-exports *plus* full `search/`, `map/`, `ui/` implementation modules, `glyph_atlas`, and `frame_plan` behind `#[cfg(feature)]` flags. The engine crates sit behind optional deps (`search = ["source", "dep:fcb-search"]`): `fcb-search` (6,741 lines — the actual index engine), `fcb-map` (7,174), `fcb-ui` (2,605) coexist with the `fcb`-inline integration modules, so the component boundaries ARCHITECTURE.md draws are aspirational, not architectural [Code-verified, High — see claim 19]. Around it: typed IDs and resource budgets (`fcb-core`, 6,887 lines), a CLI application with argument parsing and stdio framing (`fcb-app`, 27,068 lines, real `main.rs`), source provider and capture seams (`fcb-source`, 17,458 lines), document integration (`fcb-document`, 13,409 lines), runtime seam (`fcb-runtime`, 5,865 lines), cache-namespace store (`fcb-store`, 4,618 lines), a C-ABI FFI bridge (`fcb-bridge`, 4,713 lines — the unsafe exception), CPU-reference render semantics (`fcb-render`, 3,793 lines), analysis (`fcb-analysis`, 4,546 lines), conformance (`fcb-conformance`, 3,449 lines), and test-support evidence tooling (`fcb-test-support`, 3,402 lines) [all Counted, High]. Development velocity is extreme: 206 commits over 2026-09-17→22 (~34/day mean; 101 on 09-17 alone, decelerating to 4 on pin day, with zero commits on 09-20) [Git-observed, High]. The code at the pin substantially outruns the September-14 status document and parts of the README (claims 3–5), while the design's named foundations (asupersync, FrankenSQLite, franken-macos) are absent from the tree.

One-line verdict: **the most candid self-description assessed in this program to date [Inference, Medium — the in-packet evidence base is the README's front-page total disavowal plus the named anti-fabrication defect taxonomy; "most" is a comparative judgment over the packets completed so far, not a measured ranking], attached to a ten-day-old, ~14.7k-lines-per-day foundation codebase with no CI, no release, one human, an unsafe-code policy already violated in-tree, and an architecture whose documented component boundaries do not match the code.** (NODUS: Explore — see §4.9.)

## 4.3 Repo facts (claim inventory)

Every claim below was checked against the pinned commit on 2026-09-22. **Status** is the Rulebook's audit verdict per claim.

| # | Claim | Status | Evidence | Tier, Confidence |
|---|-------|--------|----------|------------------|
| 1 | 15 workspace crates (+1 workspace-excluded `fcb-reader`); 489 `.rs` files / 147,429 lines across `crates/` | demonstrated | Fresh clone at the pin; root `Cargo.toml` members enumerated; per-crate file/line counts | [Counted, High] |
| 2 | README disavows all product claims: "There is no application, executable, installer, or benchmark result yet… Features and commands below describe the planned product" | demonstrated | README.md (232 lines) read verbatim at the pin | [Code-verified, High] |
| 3 | A real CLI binary exists: `fcb-app/src/main.rs` (16 lines, `#![forbid(unsafe_code)]`) calls `fcb_app::run` with bounded stdio; `args.rs` parses Help/Capabilities/Doctor/Inspect/Open/Read/Search/Launch | demonstrated (existence); execution unobserved by any third party | `main.rs`, `args.rs` read at the pin | [Code-verified, High] |
| 4 | `IMPLEMENTATION_STATUS.md` (snapshot 2026-09-14) is stale: it says "the standalone `fcb` executable … not implemented" and "Native Metal renderer / atlas UI — Not implemented," while the pin has `main.rs` and beads record retained-Metal-renderer delivery (native code in sibling `franken_macos`) | demonstrated | Status doc vs. tree at the pin; bead commit messages `8a9b7e5`, `375f991` | [Code-verified + Git-observed, High] |
| 5 | Reading desks, atlas partition layout, and bounded directory discovery are implemented in-tree (`fcb-app/src/desk/`, `fcb-map`, `fcb-source` `BoundedDiscovery`) | demonstrated (existence; test greenness not independently verified) | `desk.rs` ("real headless consumer… no shell, source writes…"), `fcb-map`, `fcb-source` read | [Code-verified, High] |
| 6 | The "delivered retained Metal renderer" commits (`8a9b7e5`, `375f991`) are docs-only: each changes exactly one file, `.beads/issues.jsonl`; native source commits live in `franken_macos`, "which has no configured remote" | demonstrated | `git show --stat` at the pin | [Git-observed, High] |
| 7 | 206 commits 2026-09-17→22 (peak 101 on 09-17; 4 on pin day; zero on 09-20); 127 by the noreply GitHub identity, 79 by jeff141421@gmail.com; 2 Antigravity (Google) + 1 Claude Co-Authored-By trailers | demonstrated | Deepened history (depth 200) | [Git-observed, High] |
| 8 | Zero GitHub Actions workflows: `.github/` holds only issue templates; no CI executes anywhere | demonstrated | `.github` tree read at the pin | [Verified, High] |
| 9 | asupersync has **zero** Cargo dependency edges in the tree (no mention in any `Cargo.toml` or `.rs` file) despite AGENTS.md naming it "the sole FCB orchestration foundation" | demonstrated | `Cargo.lock` package list + tree-wide grep | [Counted, High] |
| 10 | FrankenSQLite has zero Cargo edges; `fcb-store` is plain-file cache namespaces (`CacheNamespace`, FCB-081.A), not a database — and the repo contains zero mentions of FrankenRedis | demonstrated | `Cargo.lock` + tree-wide grep + `fcb-store/src/lib.rs` | [Counted, High] |
| 11 | `franken_markdown` is a local-path dev dependency (`../../../franken_markdown`) in `fcb-conformance` only; the constitution bars local paths from release deps | demonstrated (the dependency); the release-bar is the constitution's rule | `fcb-conformance/Cargo.toml` + DEPENDENCY_CONSTITUTION.md | [Code-verified, High] |
| 12 | `fcb-bridge` violates the unsafe contract: `atlas_ffi.rs` (and siblings) expose real `pub unsafe extern "C" fn` FFI with `unsafe` blocks; `fcb-bridge` and `fcb-render` `src/lib.rs` lack `#![forbid(unsafe_code)]` (they carry only `#![deny(unsafe_op_in_unsafe_fn)]`) | demonstrated | `atlas_ffi.rs`, both `lib.rs` heads read; 401 files carry the forbid gate, these two crates' roots do not | [Code-verified, High] |
| 13 | No tags, no releases, 2 stars, 1 fork (not ~11 stars as the program brief suggested); CHANGELOG.md covers only the documentation bootstrap ("No executable, library implementation or release is claimed") | demonstrated | GitHub API 2026-09-22; CHANGELOG read | [External, High] on stars/releases; [Code-verified, High] on CHANGELOG |
| 14 | Performance objectives (100k files/10M lines, 120 Hz, 30 ms p95 warm-path search, 3 GiB managed target) are explicitly unmeasured: "**None of these numbers has been measured in FCB**" | demonstrated (the disavowal) | README "Performance objectives" section, verbatim | [Code-verified, High] |
| 15 | All 97 work packages and gates G0–G7: "All gates remain pending" — no product gate has passed | demonstrated | README + ROADMAP at the pin | [Code-verified, High] |
| 16 | 438 tracked issues, 231 closed; verification receipts recorded as bead comments; test counts cited per-crate (e.g., fcb-core "61+ tests," fcb-test-support 33) rest on maintainer's "strict remote" runs | demonstrated (counts); greenness is maintainer-asserted | `.beads/issues.jsonl` counted; IMPLEMENTATION_STATUS.md | [Counted, High] on counts; [Maintainer claim, Medium] on test outcomes |
| 17 | License: MIT + OpenAI/Anthropic rider — bars OpenAI/Anthropic, affiliates, and anyone acting for them from use incl. benchmarking/analyzing/training; breach = automatic termination | demonstrated | LICENSE read verbatim at pin | [Code-verified (license text), High] |
| 18 | "Multi-resolution" in the plan means atlas LOD summary pyramids (§9.9), not semantic search indexing; no vector/embedding/neural search exists in-tree (ROADMAP: "Optional neural search… remain separately justified enhancements") | demonstrated | Plan §9.9 + ROADMAP + tree-wide grep (zero hits for embeddings/vector index in `.rs`) | [Code-verified, High] |
| 19 | The `fcb` crate is a feature-gated integration monolith, not a facade: `src/` contains full `search/`, `map/`, `ui/` modules, `glyph_atlas`, `frame_plan`; engine crates (`fcb-search`, `fcb-map`, `fcb-ui`) sit behind optional deps (`search = ["source", "dep:fcb-search"]`) and coexist with the inline integration modules | demonstrated | `crates/fcb/src/lib.rs`, `crates/fcb/src/search.rs`, `crates/fcb/Cargo.toml` read | [Code-verified, High] |
| 20 | Layering inversion: `fcb-bridge`'s manifest states "search/read go through fcb-app's own command routing, so the shell and the CLI share one implementation" — the native shell depends on the *application* crate, contradicting AGENTS.md's "the app consumes the same supported APIs as external hosts" | demonstrated | `crates/fcb-bridge/Cargo.toml` comment + `Cargo.lock` (`fcb-bridge` deps include `fcb-app`) | [Code-verified, High] |

**What the inventory says in aggregate:** this section's function is inverted relative to the Rulebook's norm — there is no README marketing for it to kill, so it measures how far the code has *outrun* the disavowal instead. Claims about *process and self-description* verify at High confidence; claims about *capability outcomes* are either explicitly disavowed by the maintainer or rest on unobservable remote runs. The load-bearing facts for the verdict are claims 8 (no CI), 9–10 (absent named foundations), 12 (unsafe-policy violation), and 19–20 (documented architecture ≠ code architecture). The parent brief's four anchors — FrankenRedis storage, semantic indexing, sub-100 ms, ~11 stars — are all falsified against the tree (claims 10, 18, 14, 13).

## 4.4 Codebase tour

**Workspace topology (15 members + 1 excluded, [Counted, High]):** `fcb`, `fcb-core`, `fcb-app`, `fcb-runtime`, `fcb-source`, `fcb-map`, `fcb-search`, `fcb-store`, `fcb-test-support`, `fcb-conformance`, `fcb-analysis`, `fcb-document`, `fcb-render`, `fcb-ui`, `fcb-bridge`; `fcb-reader` is excluded from the workspace with its own `Cargo.lock`. Line-count leaders: `fcb` 31,916 / `fcb-app` 27,068 / `fcb-source` 17,458 / `fcb-document` 13,409 [Counted, High]. The honest structural description, replacing v1's "facade" shorthand: `fcb` is a feature-gated integration monolith. Its `lib.rs` re-exports `fcb-core` types and `frame_plan`/`glyph_atlas`, then gates `search`, `map`, `ui`, `analysis`, `markdown`, `snapshot` behind Cargo features; the engine crates are optional deps. So "search" exists twice by design: `fcb-search` (the engine — `EphemeralIndex`, `SnapshotPostings`, `ReferenceScanOracle`, bounded decoding windows, incremental matcher) and `fcb/src/search/` (the headless consumer wiring — reading windows, extents, trails, snapshot export — "through the public `fcb` facade"). Whether this split is clean layering or accretion is unjudged; what is judged is that ARCHITECTURE.md's component table ("`fcb` owns: curated public facade… must not own: implicit startup") describes an aspiration, because the same crate owns the integration logic [Code-verified, High].

**Dependency posture:** `Cargo.lock` lists 18 packages, all first-party (`fcb-*`, `franken_markdown`, `fmd-font`, `fmd-math`) [Counted, High]. Zero third-party crates — no tokio, no serde, no regex, no tree-sitter — consistent with the constitution's closure rule [Code-verified, High]. Two deviations: `franken_markdown` resolves via a local path (`../../../franken_markdown`, claim 11) — permitted in development by the constitution but barred from release; and **asupersync is absent entirely** (claim 9), even though the design names it the sole orchestration foundation.

**Data flow, end to end (as designed; execution never observed):**

- **Ingress — `fcb-app` CLI → `fcb`:** `main.rs` collects argv (bounded: `MAX_ARGUMENTS` 64, `MAX_ARGUMENT_BYTES` 65,536), locks stdio, calls `fcb_app::run` with an injectable clock/cancel predicate; output is one complete versioned JSON object per request on stdout, diagnostics on stderr [Code-verified, High].
- **Source truth — `fcb-source`:** provider/capture seam with immutable complete vs. extent captures (holes explicit), bounded directory discovery (`BoundedDiscovery`: descriptor/depth/path/batch/queue caps, deterministic paged publication, incomplete-scan semantics that do not tombstone unseen entries), symlink confinement (`SymlinkPolicy::DisallowAll`), checked `u64` offsets separating byte/UTF-8/UTF-16/grapheme/visual positions [Code-verified, High].
- **Identity — `fcb-core`:** owner-qualified IDs (`IdAllocator` with persisted-counter collision rejection), resource budgets (ordinary/terminal/retirement reservation classes, global acquisition order), bounded event rings, clock-domain adapters [Maintainer claim, Medium — test counts asserted in status doc, not executed by analyst].
- **Layout — `fcb-map`:** deterministic retained partition tree: parent-local rectangles, frozen raw-path child order (deliberately *not* size-sorted squarify), capped-log byte weights, unknown placeholders, reserved slack, `LayoutRevision` restore; local repair/repack explicitly not implemented (FCB-013.B) [Code-verified, High].
- **Search — `fcb-search` engine + `fcb/src/search/` wiring:** the engine builds an `EphemeralIndex` over immutable captures and a paged postings snapshot index (`SnapshotPostings`, `PostingCandidates`, `POSTINGS_SCHEMA`, `MAX_POSTINGS_BYTES`) with a stated **trust boundary**: a disk checksum proves internal consistency, *not* completeness — `decode_pinned` requires a separately supplied digest of a trusted-host-built artifact, and an untrusted index must be rebuilt from its independently validated snapshot [Code-verified, High]. Query surface: multi-term saved-source expressions with document-wide predicates evaluated in bounded matcher quanta, streaming needles, path indexes, and extent queries; every candidate hit is verified against captured bytes [Code-verified, High]. No embeddings, no vector index (claim 18).
- **Documents — `fcb-document`:** thin integration over FrankenMarkdown output (flow + source maps), plus lens/reading state; the constitution forbids any FCB-local Markdown engine [Code-verified, High].
- **Analysis — `fcb-analysis`:** language-scoped structural outlines, symbol candidates (`SymbolCandidate`, `SymbolLanguage`), references, comparisons; evidence levels carried on facts [Code-verified, High].
- **Sessions — `fcb-app/src/desk/`:** explicit persistent stdio reading sessions — repository/document/comparison/saved/code/reading command groups over bounded TAB-separated UTF-8 frames; checkpoint files only on explicit save [Code-verified, High].
- **Render — `fcb-render`:** CPU-reference semantics of the shader color/alpha/clip/depth ABI (`display_mapping`, `shader_abi`, `host_target`); the root `lib.rs` exports a `BoundedGlyphAtlas` with `UnifiedMemoryAccounting`, `RasterScaleTier`, `SubpixelBin` — the glyph memory-accounting model is concrete and nameable even though no GPU code ships here. The *actual* Metal renderer is in the sibling `franken_macos` repo, not this tree (claim 6) [Code-verified, High].
- **Bridge — `fcb-bridge`:** C-ABI marshaling (`atlas_ffi`, `reader_ffi`, `text_layout_ffi`, `source_cache_ffi`, `saved_ffi`) over `fcb_app::host` worker services — note *app*, not library services (claim 20); panic-to-null boundaries; the tree's only real unsafe code (claim 12) [Code-verified, High].
- **Store — `fcb-store`:** root-confined cache namespaces with pinned generations; plain files, no secure-erasure promise (claim 10) [Code-verified, High].
- **Conformance/test-support — `fcb-conformance`, `fcb-test-support`:** deterministic corpus fixtures with digests, scenario-receipt codec, Python closure probes (`tests/test_closure_probe*.py`, `test_extension_ledger.py`) [Code-verified, High on existence].

**Unsafe arithmetic, stated explicitly:** 401 `.rs` files carry `#![forbid(unsafe_code)]` [Counted, High]; every other genuine `unsafe` occurrence in the tree traces to `fcb-bridge`'s FFI surface (22 in `atlas_ffi.rs` alone [Counted, High]). Two crate roots lack the gate (`fcb-bridge`, `fcb-render`); `fcb-render` contains no unsafe today but the missing gate is a standing exception [Code-verified, High].

## 4.5 The maintainer's stated case

**The pitch, in the maintainer's own structure:**

1. **A spatial atlas for source:** stable 2D places for directories/files; zoom from structure to readable source; the atlas, reader, search, Markdown, and relationship inspector share one versioned source model [Maintainer claim, Medium].
2. **Exactness as product:** search hits name captured bytes; bookmarks keep source anchors; evidence levels separate exact bytes from lexical classification from heuristics — "a highlighter is not a compiler" [Maintainer claim, Medium].
3. **Performance objectives:** 100k files / 10M lines standard workload; 120 Hz presentation; warm-path search within 30 ms p95; 3 GiB managed-resource target with 6 GiB admission guard — **all explicitly unmeasured** (claim 14) [Maintainer claim, High on the disavowal]. Auditing the bundle for internal consistency: the load-bearing objective is the 30 ms p95 warm-path search at 10M lines — it is the only one that is falsifiable without exotic hardware (a corpus plus a timer on a Mac suffices), and the packet records it as the number to watch when measurement begins [Inference, Medium].
4. **Embeddability:** one library (`fcb`), one app; default construction inert (no thread, window, scan, or global handler); hosts own event loop/device; two embedded instances must not interfere [Maintainer claim, Medium] — with the caveat that "one library" is really a feature-gated monolith (claim 19) and the bridge routes through the app crate (claim 20).
5. **Process rigor:** code-first implementation, batch verification pending, independent review lanes, receipt-bearing bead closures, and the anti-fabrication defect taxonomy [Maintainer claim, Medium].

**The disavowal — quoted and located precisely:** the README opens with a `[!IMPORTANT]` block: *"This repository contains the comprehensive design and project documentation plus the first foundation crates (typed core, inert facade, runtime/source seams, test-support tooling) with batch-verified test suites. There is no application, executable, installer, or benchmark result yet: the atlas, source reader, search, Markdown integration and native renderer described below remain unimplemented."* [Code-verified, High]. A second disavowal sits in Performance objectives: "**None of these numbers has been measured in FCB.**" [Code-verified, High]. Unlike FrankenRedis's buried disavowal, these are front-page and unambiguous — which is precisely why claim 4's staleness matters: parts of the disavowed set (the executable) now partially exist, and the README's own inventory sentence ("the first foundation crates (typed core, inert facade, runtime/source seams, test-support tooling)") understates the tree, which has grown a CLI, desks, search, analysis, and a bridge crate [Code-verified, High].

**Benchmark reproduction cost:** there is nothing to reproduce — no benchmark exists, no measured number is claimed [Code-verified, High]. Building the tree requires a dated nightly Rust toolchain on Apple Silicon (per AGENTS.md; "Do not invent a successful toolchain pin"), a neighboring `franken_markdown` checkout for `fcb-conformance`, and (for native qualification) the `franken_macos` sibling repo, which has no configured remote [Maintainer claim, High]. The analyst could not compile: no toolchain on the assessment VM [Verified, High].

## 4.6 Competitors

The incumbent for "open a huge codebase and search it" is the editor the developer already has; FrankenCodeBrowser's only uncontested edge would be a purpose-built spatial atlas — which does not exist yet as a runnable product [Inference, Medium].

- **VS Code / Cursor / Zed:** own the "navigate and search code" lane by every observable measure (installed base, extension ecosystems, ripgrep-backed search). Zed positions itself in the Rust-native performance lane [Inference, Medium]. None offers a stable spatial atlas; all offer the search/read loop FCB is still building toward.
- **Sourcegraph / Kythe:** own the "code intelligence at scale" lane (cross-repo search, LSIF/SCIP semantic indexes, reference navigation) with real deployments [External, Medium]. FCB's structural-facts-with-evidence-levels is a pale, local-only cousin of this lane.
- **Understand (SciTools), Source Insight:** the legacy "code browser as product" lane — static-analysis browsers sold to exactly the audience FCB describes [External, Medium]. Their continued existence suggests the lane is real but niche.
- **Tree-sitter-based tooling, ctags/cscope, `broot`/`eza` TUI explorers:** the free, composable lane. FCB's explicit ban on tree-sitter ("No … Tree-sitter" in AGENTS.md) is a deliberate differentiation that also forfeits the ecosystem's best-tested incremental parser [Inference, Medium].
- **Rust peers:** no direct Rust-native spatial code browser surfaced in a web search run 2026-09-22 (the "atlas"-named hits were unrelated Tauri apps) [External, Medium within recall caveats]. The lane may genuinely be empty — or just unindexed.
- **Unoccupied lane:** a memory-safe, read-only, embeddable source-browsing *library* with audited byte-exactness contracts and an inert-construction guarantee has no direct occupant — editors are apps, not libraries, and Sourcegraph is a service [Inference, Medium]. Whether any host application wants to embed a code browser rather than build search itself is the unproven bet [Inference, Medium].

## 4.7 Skeptic's take

*Citation convention: weaknesses numbered 1–9; "§4.7.N" = weakness N.*

1. **[FATAL] No independently verifiable artifact exists.** No CI, no release, no tags; every "green suite" number (61+ tests here, 33 there) is a maintainer assertion about remote runs no outsider can re-execute. A codebase whose entire verification story is "trust my worker fleet" is, to a third party, indistinguishable from an untested one [Inference, High].
2. **[FATAL] The unsafe contract is already broken.** The constitution's non-negotiable — "All authoritative FCB source… use `#![forbid(unsafe_code)]`" — fails at the pin: `fcb-bridge` ships genuine `pub unsafe extern "C" fn` FFI with unsafe blocks, in the one crate whose whole job is a trust boundary. A safety contract violated in week two of a ten-day repo is not a contract [Inference, High].
3. **[HIGH] The named foundations are design fiction in the dependency graph.** asupersync ("sole orchestration foundation"), FrankenSQLite (persistence), and the `franken-macos` bridge (native unsafe boundary) have zero Cargo edges in the tree. The architecture's load-bearing walls are documented intentions, not code [Inference, High].
4. **[HIGH] The documented architecture does not match the code.** ARCHITECTURE.md's component table says `fcb` "owns: curated public facade… must not own: implicit startup" — but the crate is a 31,916-line integration monolith containing the search/map/ui integration modules (claim 19). And the bridge that should sit atop the library routes through the *application* crate instead (claim 20). Two layering inversions in a project whose pitch is strict boundaries [Inference, High].
5. **[MEDIUM] The status doc is stale after eight days, and the process machinery is the cause.** IMPLEMENTATION_STATUS.md's 2026-09-14 snapshot contradicts the tree at the pin, while beads receipts are current — the swarm updates the tracker, not the human-readable record. Documentation half-life is measured in days; a cold reader trusting the status doc gets the wrong product [Code-verified, High].
6. **[MEDIUM] "Delivered" is a bead comment, not an artifact.** The retained-Metal-renderer delivery commits change only `issues.jsonl`; the native code is in a sibling repo with no configured remote. Verification receipts that cannot be audited are receipts in name only [Inference, Medium].
7. **[MEDIUM] The dependency constitution's release bar is currently unmeetable.** Accepted release dependencies "must resolve to committed compatible versions without a neighboring dirty checkout" — but `franken_markdown` is a local path dep and asupersync/FrankenSQLite don't exist as deps at all. The G7 release gate's own admission policy cannot be satisfied by the current tree [Inference, Medium].
8. **[MEDIUM] One human, ten days, 206 commits, no review depth — and the curve is already bending.** The velocity (~34/day mean, 101 on 09-17, 4 on pin day, zero on 09-20) with a no-outside-contributions policy and agent-authored commits means review depth is necessarily thin, and the deceleration is visible *inside* the assessed window. The anti-fabrication taxonomy is admirable, but a coordinator that reopens defects is still one person's coordinator [Inference, Medium].
9. **[LOW] The license rider poisons the well it drinks from.** The MIT+OpenAI/Anthropic rider bars the two AI labs (and affiliates, and anyone acting for them) from use, benchmarking, analysis, and training-data incorporation — the exact activities that would validate or adopt a developer tool in the agent era. Two of the 206 commits' Co-Authored-By trailers name Google's Antigravity and Claude (Anthropic) [Git-observed, High]; the clean-room/authorship implications are untested [Inference, Medium].

**Bear-case steelman (strongest counter-case):** FrankenCodeBrowser is a ten-day-old process-performance project about *how to run an agent swarm*, not a browser. No outsider can build it (no toolchain pin, a path-dep on a sibling checkout, native code in a remote-less repo), run it (no release, no CI, no qualification on record), or validate its headline claims (the maintainer disavows them all himself). The 147k lines are foundation contracts for a product whose first user-visible loop (G1: open a real tree, read real source) has not passed its own gate; the velocity is commit-pumping-shaped even if the taxonomy forbids calling it that — and the taxonomy's own forbidden list reads like a confession of what the swarm is tempted to do. The documented architecture already diverges from the code in two places the constitution calls non-negotiable. Its most likely end state is not a shipped browser but a frozen monument to September 2026's agent-swarm methods — useful as a case study in anti-fabrication process, never as software. [Inference, Medium — deliberately uncharitable; the counter-evidence is the honest disavowal culture and the real in-tree CLI/desk/search code, which are more than most ten-day repos achieve.]

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

**License text (verbatim scope):** MIT License with the FrankenSuite "OpenAI/Anthropic Rider." The rider defines "Restricted Parties" as OpenAI, L.L.C.; Anthropic, PBC; their Affiliates (control = >50% voting securities or power to direct management); 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. It grants **no rights** to any Restricted Party ("Any purported license… is null and void"), and "use" is defined to include "copying, modifying, … benchmarking, testing, analyzing, indexing, or incorporating the Software … into any dataset, training corpus, evaluation harness, or pipeline." Breach triggers automatic, immediate termination with destruction of copies; the rider "controls" over any conflicting license term. **OSI status: non-OSI** — the named-party field-of-use restriction violates OSD §5 (no discrimination against persons/groups) and §6 (no field-of-use restriction) [Code-verified (license text), High].

**Governance:** bus factor 1 — Jeffrey Emanuel, sole human; outside contributions explicitly refused ("I do not accept outside contributions for any of my projects"; PRs will not be merged; Claude/Codex triage instead) [Maintainer claim, High]. Agent personas (BlackCedar coordinates; EmeraldStorm, RoseHawk named in commits) operate under AGENTS.md's defect taxonomy [Git-observed, High]. Commit velocity: 206 commits over 2026-09-17→22, decelerating within the window [Git-observed, High]. No foundation, no succession plan, no second committer. If the maintainer stops, the project freezes [Inference, High].

**Governance signal from the unsafe break (claim 12):** the constitution calls the unsafe rule "non-negotiable," yet `fcb-bridge` landed with real unsafe FFI and no gate. Either the rule was knowingly waived for the bridge (undocumented waiver) or the swarm outran its own constitution — both are governance findings, and the packet records the ambiguity rather than resolving it [Inference, Medium].

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness | **TRL 2–3** | Technology concept + experimental proof: foundation crates and a CLI exist in-tree, but no product gate (G0) has passed, nothing measured, nothing released [Inference, Medium] |
| Strategic relevance | **2/5** | A read-only browsing library is adjacent to agent-era code-comprehension tooling, but no agent workload is designed around it yet [Inference, Medium] |
| Impact potential | **2/5** | If the atlas+evidence-level ideas land, the embeddable-library lane is unoccupied; currently the impact is process-methodology, not product [Inference, Medium] |
| Implementation feasibility | **3/5** | Foundations are landing fast with strict contracts, but the load-bearing dependencies (asupersync, FrankenSQLite, franken-macos remote) are absent from the graph [Inference, Medium] |
| Time to mainstream | **2/5** | G0–G7 all pending; the plan's own sequencing puts qualified distribution years out at honest velocity [Inference, Medium] |
| Collaboration potential | **1/5** | Outside contributions explicitly refused; rider bars the two AI labs; bus factor 1 [Inference, High] |

**Ring: Explore** [Inference, Medium]. Substantive-but-unproven is the textbook Explore case: 147k lines of real foundation code with strict contracts, an honest disavowal culture, and extreme velocity — but no gate passed, no CI, no release, no independent validation. Ring down, not up: the evidence does not support Pilot (no release artifact, no bounded real workload demonstrated to a third party), and Monitor would underweight the in-tree substance. The rider is an advancement ceiling, not a ring qualifier.

## 4.10 Wardley placement

- **Commodity surface:** CLI argument parsing, stdio JSON framing, file discovery, text search — commodity; FCB rebuilds them with custom contracts rather than buying them (a deliberate cost) [Inference, Medium].
- **Custom-built reimplementation:** the source-capture/identity model (immutable captures, owner-qualified IDs, checked offset domains), the deterministic atlas partitioner, and the paged-postings search index with its checksum trust boundary — custom-built, mid-evolution toward product [Inference, Medium].
- **Genesis-stage novel elements:** (a) the anti-fabrication verification process (code-first → batch-pending → independent receipt closure with a named defect taxonomy) — genesis, and the most exportable artifact; (b) the "inert by construction" embeddability contract — genesis, no occupant in the code-browser lane [Inference, Medium].

**What would move each:** the commodity surface moves if the swarm adopts off-the-shelf parsing/search (the constitution forbids this — a values lock); the custom core moves right as G1/G2 gates pass with real qualification; the genesis elements move right if another FrankenSuite repo (or an outside team) adopts the receipt-closure process or the inert-facade contract [Inference, Medium].

**Cross-cutting lenses, stated explicitly:** *The decoupling lens* — FCB represents the decoupling of the **reading surface from the editing surface**: a browser that refuses the IDE's bundled read/write/execute loop, betting that navigation deserves its own product. *The methodology-export lens* — if the product fails, what survives is the anti-fabrication process machinery (receipt-closure workflow, named defect taxonomy, closure-probe tooling), which is already the most evaluated artifact in the tree. *The asupersync question* — answered in claim 9: zero Cargo edges; the "sole orchestration foundation" is design fiction at the pin. *The rider question* — answered in §4.8: it excludes the two AI labs from the exact validation activities a developer tool needs, sabotaging the mission it claims to protect [all Inference, Medium except where tiered above].

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

**Base case:** the swarm continues at high velocity through the foundation crates, G0 passes in months on the maintainer's Mac with bead-recorded receipts, but no independent party ever builds or runs the tree (no CI, no toolchain pin published, path-dep on a sibling checkout). The repo becomes a 500k-line, well-contracted foundation library used by exactly one person, with the status doc permanently a week behind the code. The rider keeps AI labs from evaluating it, and the refused-contributions policy keeps everyone else from joining.

**Bifurcation — upside:** the maintainer publishes a toolchain pin, stands up real CI (even self-hosted on his Mac), and cuts a first tagged release of the headless CLI; an outside host (a TUI file manager, a review tool) embeds `fcb` and the inert-facade contract proves its worth. The process machinery (receipt closures, anti-fabrication taxonomy) gets adopted by two or more sibling repos. Ring moves toward Pilot on the library, not the app.

**Bifurcation — decay:** velocity collapses when the September campaign ends — the deceleration is already visible inside the assessed window (101 commits on 09-17 → 4 on pin day, with a zero-commit 09-20); the native `franken_macos` sibling never gets a remote, so the Metal half of the product is permanently unauditable; doc staleness compounds until the README's disavowal — the repo's best asset — rots into misdescription. The tree freezes as an unbuildable monument.

**Revisit triggers:** (1) first tagged release or published toolchain pin; (2) first CI workflow executing on a third-party-visible runner; (3) a `franken_macos` remote appearing with the native renderer auditable; (4) a second human committer or an outside host embedding `fcb`; (5) an independent benchmark of any kind — the 30 ms p95 warm-path search objective is the falsifiable one to watch; (6) asupersync or FrankenSQLite appearing as a real Cargo edge.

## 4.12 Limitations and open questions

**Not done:** the workspace was never compiled (no Rust toolchain on the assessment VM); no test suite was executed, so all "green suite" figures are maintainer-asserted; no benchmark was reproduced (none exists to reproduce); the 309 KB comprehensive plan was sampled (§§9.9, 21.9, the product thesis via web search, and the work-package graph), not read in full; the `franken_macos` sibling repo was not inspected (no remote); web coverage was limited to one peer-search query (recall caveats apply); bead comments beyond sampled native-lane entries were not individually audited.

**Open questions that would most change the verdict:**
1. Does the tree compile at the pin, and do the asserted test suites actually pass? (A single `cargo test` on the maintainer's lane would move TRL.)
2. Was the `fcb-bridge` unsafe waiver knowingly granted, and is the constitution updated to reflect it?
3. What is the real asupersync integration status — is `fcb-runtime`'s "bounded desktop-profile seam" backed by asupersync code anywhere?
4. Is there a private CI or DSR lane behind the "strict remote" claims, and can any of its receipts be made auditable?
5. Does the maintainer intend the README's disavowal to be updated as features land, or is the honest-README asset decaying by design?
6. Is the `fcb` mega-crate / engine-crate split (claim 19) deliberate layering or accretion — and which side owns new search/map work?

---

## The eight deepening questions (one paragraph each)

1. **Provenance.** The system records bead IDs, actor names, source revisions, and verification receipts as bead comments — `ledger-receipts/unittest.log` and `.beads/issues.jsonl` are the provenance store [Code-verified, High on existence]. But receipts are maintainer-controlled tracker entries, not cryptographic attestations: making them portable would require signing receipts at creation (the maintainer already uses minisig-style signing language elsewhere in the suite) and publishing the verification commands so a third party can re-execute them [Inference, Medium]. Today the provenance is complete *as a narrative* and unverifiable *as evidence*.

2. **The embeddable unit.** The smallest useful piece is the `fcb` crate's inert core: typed IDs, source captures, and search against caller-provided bytes, with empty default features and no process-global side effects on construction [Code-verified, High on the design]. Adoption cost is currently prohibitive for outsiders: no published crate, no toolchain pin, and `fcb-conformance`'s path-dep on a neighboring `franken_markdown` checkout leaks the dev environment into any consumer's build [Inference, High].

3. **Unexercised option value.** The architecture holds three unused capabilities: the `fcb-bridge` C-ABI surface (a complete FFI ready for non-Rust hosts, currently serving no consumer — and currently routing through the app crate, claim 20), the Python closure-probe suite (an executable dependency-audit tool with no second repo audited), and the deterministic corpus fixtures in `fcb-test-support` (a benchmark-corpus governance pattern with no benchmark) [Code-verified, High]. Each is unlocked by a single external consumer or a single cross-repo run [Inference, Medium].

4. **Benchmark honesty.** There are no benchmarks and no measured numbers — the README disavows the entire category [Code-verified, High]. This is the strongest benchmark-honesty posture in the program by default: nothing to disavow except the objectives themselves. The load-bearing numbers are therefore not benchmarks but *test counts* (61+ here, 33 there), which are maintainer-asserted and would not survive an independent rerun today because no outsider can execute them [Inference, High].

5. **The governance path.** The credible route from one maintainer to an institution runs through the process machinery, not the code: the bead/receipt/verification-lane system is the only part of the project that is already multi-actor (named agent personas with a coordinator that reopens defects) [Inference, Medium]. What breaks first if velocity decays is documentation currency — the status doc is already eight days stale at a ten-day-old repo, and nothing in the machinery updates human-readable docs [Code-verified, High on the staleness; the forecast is Inference, Medium].

6. **The license as strategy.** The rider excludes OpenAI, Anthropic, their affiliates, and anyone acting for them from use, benchmarking, analyzing, indexing, and training-data incorporation — with automatic termination and injunctive-relief language [Code-verified (license text), High]. For a *developer tool* whose natural evaluators and distributors in the agent era are AI companies and their agents, the exclusion sabotages the stated mission: the two entities most likely to benchmark, embed, or distribute a code browser may not touch it [Inference, High]. It serves exactly one strategy — the maintainer's personal control — which the contributions policy states outright [Inference, Medium].

7. **Agent-era fit.** The concrete workload that would pick this over the incumbent is an agent that needs bounded, provenance-carrying source context: "assemble an evidence pack of exact captured bytes with omissions declared" (the reading-trail export the plan specifies) is a genuinely agent-shaped primitive that ripgrep and VS Code do not offer as a library [Inference, Medium]. What must become true first: the `fcb` crate must be buildable by a third party, the trail export must exist beyond the plan, and an agent harness must be able to depend on it — none of which holds at the pin [Code-verified, High on the absences].

8. **The kill test.** Ship one outside-built binary: publish a toolchain pin and a build script, and have an unaffiliated party compile the pin and run `fcb doctor --json` and `fcb search` against a real corpus [Inference, High]. If the tree does not compile, or the CLI commands fail on real input, the "real CLI / real desks / real search" reading of the code collapses and the repo reverts to plan-stage. Conversely, a green third-party build falsifies weaknesses 1 and 6 and moves TRL to 4 in a single experiment.

---

*Packet v5 (FINAL) — assessment date 2026-09-22. Five grade→revise rounds complete; stop conditions met (round 4). Graders G/H confirmed all sections ≥9 and 13/13 QA.*