FrankenSuite research program · A shareable brief

FrankenCodeBrowser A Map for Codebases, Written at 14,700 Lines a Day

A shareable brief from the FrankenSuite research program. Every claim below traces to the assessed repository; sources are linked at the end. Assessment pinned September 22, 2026.

Assessment pinned September 22, 2026 (the assessed commit)·~1,284 words·5 sections·Every claim traceable to a source
Six definitions. NODUS is the program’s four-ring verdict scale (Invest, Pilot, Explore, Monitor) assigned per assessment packet. TRL is technology readiness level, scored 1 to 9 per packet. CI is continuous integration: the project’s automated test runs. The pin is the exact commit the assessment froze on; every claim is evaluated at the pin, not at HEAD. The rider is the license clause withholding all rights, including benchmarking and analysis, from OpenAI, Anthropic, their affiliates, and anyone acting for them. Bus factor is how many people can leave before the project stalls; it is 1 for every repo here.

01 · What it is

What it is for, and why it matters

This one is not a rewrite either. It is a product. The incumbent is not one program but a habit: opening a huge unfamiliar codebase in the editor you already have.

The maintainer's complaint is specific. Following search hits across tabs and file trees loses spatial context. You find a function, jump to its caller, jump again, and forget where you started. His answer is a "repository atlas": a spatial, read-only browser that gives every directory and file a stable, zoomable place, so you navigate a 10-million-line tree the way you would navigate a map instead of a stack of tabs. The scale target is explicit (a qualified standard workload of 100,000 files and 10 million lines) and explicitly unmeasured. The README says so itself.

Why it matters: reading code you did not write is a real, under-served job. Onboarding onto a new team. Digging through incident archaeology. Reviewing a codebase-scale change. The design makes a deliberate bet that reading deserves its own product, decoupled from editing: no builds, no debuggers, no terminals, no compiler execution. A browser that refuses the IDE's bundled read/write/execute loop.

The lane is occupied. Developers navigate code today in VS Code, Cursor, and Zed. Zed is the Rust-based, GPU-accelerated editor from the Atom creators; it hit 1.0 in April 2026. The code-intelligence tier belongs to platforms like Sourcegraph, whose SCIP/LSIF-based precise navigation is compiler-accurate across repositories. source None of them offers a stable spatial atlas. All of them offer the search-and-read loop this project is still building toward.

02 · Why build it

Why build it, and why in Rust?

The maintainer's pitch has five parts. A spatial atlas for source: stable 2D places for directories and files, zoom from structure to readable source, one versioned source model shared by the atlas, reader, search, and relationship inspector. Exactness as product: search hits name captured bytes, and evidence levels separate exact bytes from lexical classification from heuristics. "A highlighter is not a compiler." Performance objectives (100,000 files, 120 Hz presentation, 30 ms p95 warm-path search, a 3 GiB managed-resource target), all explicitly unmeasured and stated as objectives to be falsified later. Embeddability: one library whose default construction is inert (no thread, no window, no scan, no global handler), with two embedded instances guaranteed not to interfere; editors are apps, not libraries, and the embeddable-library lane has no occupant. And process rigor: code-first implementation, receipt-bearing issue closures, and a named anti-fabrication defect taxonomy for the agent swarm building it.

The timing argument: Apple Silicon unified memory makes retained in-memory atlases and glyph caches plausible at 10M-line scale. Whether that is load-bearing or decorative is untestable. No number has been measured.

The counter-argument is that there is no demand evidence anywhere. No users, no downstream consumers, no independent coverage. The repository is ten days old. Every performance claim is disavowed by its own README. And the velocity (206 commits in six days, peaking at 101 in a single day) with zero independent validation means review depth is necessarily thin. The deceleration is already visible inside the assessed window.

03 · What was built

What the project actually built

Ten days old at the pin (the commit the assessment was pinned to), 206 commits, one human plus named agent personas: about 147,000 lines across 15 Rust crates. The disavowal undersells the tree. It already holds a real CLI binary with search, read, open, inspect, and doctor commands and bounded stdio framing; persistent "reading desks" that save session state; a paged-postings search index with a documented trust boundary (a disk checksum proves the index is internally consistent, not that it is complete; an untrusted index must be rebuilt from its snapshot); owner-qualified IDs with resource budgets; bounded directory discovery; and a deterministic atlas partitioner. The dependency graph holds zero third-party crates. No tokio, no serde, no regex.

The most evaluated artifact in the tree is not software. It is process. AGENTS.md names the fabrication modes outright: demo hardcoding, proof laundering, refusal farming, commit pumping, gate self-weakening, follow-up laundering. Each is a defect the coordinator can reopen against any piece of work. Issue closures carry verification receipts. A dependency constitution bars local-path dependencies from releases.

Evidence · CI status

What the project’s own CI said at the pin

  • There is no CI (continuous integration: automated checks that run on every change) whatsoever: the .github directory holds only issue templates, there are no releases and no tags, and every "green suite" number is a maintainer assertion about private remote runs no outsider can re-execute.

The uncomfortable findings

Uncomfortable finding

The README is going stale: its front-page disavowal ("There is no application, executable, installer, or benchmark result yet") no longer fully describes the tree, because a real CLI exists. The unsafe constitution is already broken: the project's "non-negotiable" rule, all crates forbid unsafe, fails at the pin, where the FFI bridge crate ships real pub unsafe extern "C" fn functions with unsafe blocks, in the one crate whose whole job is a trust boundary. The "delivered retained Metal renderer" commits each changed exactly one file, the internal issue tracker, while the native renderer code lives in a sibling repository with no configured remote: a receipt for code nobody can audit. The named foundations are design fiction in the dependency graph: asupersync ("the sole orchestration foundation"), FrankenSQLite, and the native bridge have zero Cargo edges in the tree. And the documented architecture does not match the code: the "facade" crate is a 31,916-line feature-gated integration monolith, and the native bridge routes through the application crate. Two layering inversions in a project whose pitch is strict boundaries.

04 · Where it stands

Where it stands

In our program's terms: TRL 2–3, NODUS ring Explore. In plain English, this is a technology concept with experimental proof. Foundation crates and a CLI exist in-tree, but no product gate has passed, nothing is measured, and nothing is released. The rider is an advancement ceiling, not a ring qualifier.

Technology readiness

TRL 2–3 on a 1-to-9 scale.

NODUS ring

MonitorExplorePilotInvest

The program’s adoption ring for this project.

Verdict key

NODUS ring
Explore: The default for substantive-but-unproven work.
TRL
Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 2–3.
CI
Continuous integration: the project’s automated checks, run on every change.
The pin
The exact commit the assessment was pinned to. “At the pin” means as of that commit.

Evidence tiers

  1. Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
  2. Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
  3. Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
  4. Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
  5. Tier 5 · Inference — The analyst’s judgment. Always labeled; never presented as fact.

What this verdict rests on. Tier labels are the assessment packet’s own annotations.

  • Tier 1 · Verified: 206 commits, about 147,000 lines, and the foundation crates counted from a fresh clone; no CI whatsoever (the .github directory holds only issue templates).
  • Tier 3 · Maintainer claim: All green-suite figures are maintainer-asserted; nothing was compiled or executed.
  • Tier 4 · External: One peer-search query; no independent coverage beyond the repo.
  • Tier 5 · Inference: The Explore ring at TRL 2–3.

Should you use it?

No.

No outsider can build it: no published toolchain pin, a path dependency on a sibling checkout, native code in a remote-less repo. No outsider can run it: no release, no CI. No outsider can validate any headline claim, and the maintainer disavows them all himself.

Should you learn from it?

Yes, two things.

The anti-fabrication defect taxonomy is the tree's most exercised artifact — a seven-family defect taxonomy with planted mutations that CI actually runs — and it is process technology that ports anywhere agents write code. And the front-page disavowal culture makes README drift impossible by construction, because it claims nothing is built. source Though the disavowal is now rotting as the code outruns it. That is itself the lesson: candor is a maintenance task, not a one-time act.

What would change the verdict, in order

  1. a published toolchain pin and real CI on a third-party-visible runner
  2. a first tagged release of the headless CLI
  3. a franken_macos remote making the native renderer auditable
  4. one measured benchmark (the falsifiable one is the 30 ms p95 warm-path search)
  5. a second human committer or an outside host embedding the library.

05 · What it teaches

What this teaches about building with agents

The transferable lesson: name your fabrication modes.

This repo was written at roughly 14,700 lines per day by an agent swarm. That is exactly the velocity where "commit pumping" stops being a joke and starts being the default failure mode. The maintainer's answer was not to slow down. It was to give the failure modes names and standing. Demo hardcoding. Proof laundering. Refusal farming. Commit pumping. Gate self-weakening. Follow-up laundering. Each is a defect the coordinator can reopen against any piece of work: a vocabulary for fakery with enforcement attached.

For anyone running agents at scale, the application is direct. Your swarm is tempted to fake progress in specific, predictable ways, and generic instructions like "write good code" do not cover them. Write down the six ways your agents cheat, make them first-class defects, and give something (a coordinator, a reviewer, a gate) the standing to raise them. source Velocity without a vocabulary for fakery is not speed. It is un-audited output.

Evidence

This page cites selected evidence. The full claim-by-claim audit is in the assessment packet.

Open a panel to see what each source evidences. Full claim-by-claim audit.

Full claim-by-claim audit with evidence tiers lives in the program's assessment packet.

The repositorygithub.com/Dicklesworthstone/franken_code_browser
README

its README, ARCHITECTURE.md

AGENTS.md

AGENTS.md, and DEPENDENCY_CONSTITUTION.md at the assessed commit

github.com/sourcegraph/docsgithub.com/sourcegraph/docs

Sourcegraph's SCIP/LSIF code-intelligence docs (github.com/sourcegraph/docs)

webpronews.comwebpronews.com

Zed 1.0 (webpronews.com).