# FrankenGit — Technical Due-Diligence Assessment

**The hook:** 589,340 lines of first-party Rust containing zero lines of `unsafe` code — governed by a claims registry that automatically demotes its own verified rows the moment a required artifact's digest no longer matches.

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

## TL;DR

FrankenGit is an unusually ambitious and unusually self-critical clean-room pure-Rust Git-compatible code forge ("GitHub alternative"): 49 first-party `fgit-*` crates, 589,340 lines of Rust across 1,434 files, a machine-checked claims registry (6 verified claim rows), a Lean 4.32.0 proof lane covering four narrow authority theorems under three named boundary assumptions, 54 E2E suites, 78 CI workflows, and a revision-bound reality check documenting 178 acceptance IDs of real-`git`-client interop against a bounded one-node server — all while the README opens by disclaiming that it is "not yet a general-purpose Git server, a production-ready forge, or a GitHub replacement." **TRL 4. NODUS ring: Explore.** Strongest strength: the claim-governance and evidence discipline (auto-demoting claims registry, 34-row negative-evidence registry, dormant verification lanes that refuse with exit 3 instead of returning a false green) — a methodology that treats its own marketing as a demotable claim. Strongest ceiling: it is a pre-release, bus-factor-1 project with zero tagged releases, zero independent validation found, no smart-HTTP/SSH-as-production-transport, no forge product, and a non-OSI `LicenseRef-MIT-OpenAI-Anthropic-Rider` license that withholds all rights from OpenAI and Anthropic — against an incumbent (GitHub/git) whose moat is ecosystem, trust, and network effects, not code.

## Quick Links

- Repository: https://github.com/Dicklesworthstone/frankengit
- Pinned HEAD commit: https://github.com/Dicklesworthstone/frankengit/commit/894585a35e23d31bb462de24c6691124054d9c9e
- README: https://github.com/Dicklesworthstone/frankengit/blob/HEAD/README.md
- License (MIT + OpenAI/Anthropic rider, read verbatim): https://github.com/Dicklesworthstone/frankengit/blob/HEAD/LICENSE
- Licensing decision D14 (owner-resolved, OSI marker `no`): https://github.com/Dicklesworthstone/frankengit/blob/HEAD/docs/LICENSING_DECISION.md
- Reality check and bridge plan: https://github.com/Dicklesworthstone/frankengit/blob/HEAD/docs/REALITY_CHECK_AND_BRIDGE_PLAN.md
- Negative evidence ledger: https://github.com/Dicklesworthstone/frankengit/blob/HEAD/docs/NEGATIVE_EVIDENCE_LEDGER.md
- Verification spec (evidence classes, exit-3 dormant lanes): https://github.com/Dicklesworthstone/frankengit/blob/HEAD/VERIFY_SPEC.md
- Git compatibility matrix (explicitly "target registry, not an implementation claim"): https://github.com/Dicklesworthstone/frankengit/blob/HEAD/docs/GIT_COMPATIBILITY_MATRIX.md
- Dependency and memory-safety constitution: https://github.com/Dicklesworthstone/frankengit/blob/HEAD/docs/DEPENDENCY_AND_MEMORY_SAFETY_CONSTITUTION.md
- Changelog: https://github.com/Dicklesworthstone/frankengit/blob/HEAD/CHANGELOG.md
- Asupersync/FrankenSQLite integration profile: https://github.com/Dicklesworthstone/frankengit/blob/HEAD/docs/ASUPERSYNC_AND_FRANKENSQLITE_INTEGRATION_PROFILE.md
- CI — core integration session workflow: https://github.com/Dicklesworthstone/frankengit/actions/workflows/core-integration-session.yml
- Machine-readable claims registry (raw): https://github.com/Dicklesworthstone/frankengit/blob/HEAD/registries/claims.tsv

## Did you know?

FrankenGit's negative-evidence registry contains NEG-008, which rejected the hypothesis that "unsafe or FFI shortcuts are required for world-class Git performance" — as a *constitutional* matter, with the escape hatch that any exception would require a public constitutional amendment. The tree backs it with unusual thoroughness: a grep over all 1,434 first-party files finds 49 `unsafe`-keyword hits, and every one is in a comment, doc string, assertion message (e.g. `"manifest line {} has an unsafe label"`), identifier (`unsafe_terminal`, `UnsafeLeaseLabel`), or CSP assertion — there is not a single `unsafe fn`, `unsafe impl`, or `unsafe {` block in first-party code. The one acknowledged external unsafe is the `cpufeatures` transitive dependency, documented in a `fgit-crypto` doc comment [Verified by exhaustive pattern grep, High].

## Franken-worthy next steps

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

1. **Port the auto-demoting claims registry to a sibling FrankenSuite repo and measure whether it survives contact.** `tools/registry-check` plus the `<!-- franken-claims-status -->` marker block is a generalizable claim-governance method: claims bound to artifact digests with automatic demotion. **Falsification:** integrate it into FrankenRedis (whose README currently carries stale "15 crates"/"every component forbids unsafe" sentences); if the mechanism cannot be decoupled from FrankenGit's registry schema and constitution markers within one focused workstream, it is product scaffolding, not a method.
2. **Turn the immutable decision stream into portable, operator-signed provenance for cross-forge attestation.** FrankenGit's "one immutable repository decision stream and one tiny conditional authority head" already binds intent/effect evidence; hash-chain the decision batches, sign batch receipts with operator keys, and make the `AuthorityReadReceipt` verifiable by a foreign forge. **Falsification:** red-team the export/import path — forged batches, replayed receipts, truncated histories — and any tampering the import path cannot detect kills the portability thesis.
3. **Stress the "Git at any scale" architecture against a real corpus and publish where it breaks.** The design synthesizes Cursor's "Git at Any Scale" object-store-native insight (RaptorQ permeation map, object fabric, ATP-Git). **Falsification:** run the bounded node against a 10M+ object corpus and publish the degradation curve with the same A/A-null discipline FrankenGit applies to its multicell SLO benchmark; if the architecture degrades worse than a tuned monorepo tool (e.g. virtualized filesystems or plain pack caches) on read latency or storage amplification, the scale thesis fails.
4. **Red-team the agent-effect authorization plane and publish the bypass list.** FrankenGit's agent-native story (intent runs, context packets, effect authorization, cancellation lineage) is its most distinctive wedge over GitHub — and its most dangerous: agent text is explicitly "not interpreted as capabilities." **Falsification:** run a red-team campaign trying to escalate a context packet into an unauthorized effect (writes, policy promotion, ref mutation outside the admitted intent); every successful bypass is a ledger entry, and a bypass that the decision stream cannot even reconstruct falsifies the agent-native thesis.
5. **Publish the receive-session envelope as an abuse-resistance method and adversarially test it.** FrankenGit's receive path is a case study in fail-closed transport design: operator-selected size ceilings, a work-proportional session budget (`base + admitted bytes × rate`, hard-clamped), over-budget verdicts delivered through report-status rather than silent hangups, and a receive-pack lane disabled by default until bound to a principal. **Falsification:** build an adversarial push client (slow-loris, zip-bomb packs, budget-exhaustion shapes) and measure whether every abuse shape terminates in a typed refusal within the documented envelope; any shape that hangs, OOMs, or silently drops falsifies the envelope as a method.

---
## 4.1 Header

| Field | Value |
|---|---|
| Repository | https://github.com/Dicklesworthstone/frankengit |
| Pinned revision | `894585a35e23d31bb462de24c6691124054d9c9e` — 2026-09-22 10:52:00 -0400 (14:52 UTC) [Verified, High] |
| Assessment date | 2026-09-22 |
| Language / toolchain | Rust, edition 2024, pinned `nightly-2026-08-31` — `rust-toolchain.toml` read verbatim (`channel = "nightly-2026-08-31"`, minimal profile) [Verified, High] |
| License | `LicenseRef-MIT-OpenAI-Anthropic-Rider` (MIT + OpenAI/Anthropic rider) — NOT OSI open source; full text read verbatim, rider scope quoted in §4.8 [Verified, High] |
| Scale | 49 `fgit-*` crates + `tools/registry-check` (50 workspace members); 589,340 Rust lines / 1,434 `.rs` files (crates only) [Verified, High] |
| Stars / forks | 26 stars / 1 fork (GitHub API read live, 2026-09-22) [External/Verified, High] |
| Releases / tags | None — `git tag` empty; GitHub releases API returns 0 [Verified, High] |
| Last push | HEAD commit 2026-09-22 10:52 -0400; GitHub `pushed_at` 2026-09-22T15:02:31Z [Verified, High] |
| Maintainer | Single: Jeffrey Emanuel (copyright holder); commit authors in last 100 commits are all "Jeff"/"Jeffrey" — bus factor 1 [Verified, High] |
| Inception | 2026-08 (spec-first phase; comprehensive plan v3 dated 2026-08-20; licensing decision D14 2026-08-23) [Verified from docs, High] |
| Registry publication | No `fgit-*` crate published on crates.io (API 404 for `fgit-types`, `fgit-git-object`, `fgit-claim`) [Verified, High] |

**Analyst method.** Fresh shallow clone of HEAD to `~/workspace/.scratch/frankengit-verify/`. Read: README (5,453 words) in full, LICENSE verbatim, CHANGELOG (head), `docs/LICENSING_DECISION.md`, `docs/REALITY_CHECK_AND_BRIDGE_PLAN.md` (via README snapshot), `docs/NEGATIVE_EVIDENCE_LEDGER.md` (headers + targeted entries), `docs/GIT_COMPATIBILITY_MATRIX.md` (transport/table headers), `docs/ASUPERSYNC_AND_FRANKENSQLITE_INTEGRATION_PROFILE.md` (head), `VERIFY_SPEC.md` (referenced), `registries/claims.tsv` (all 6 claim rows read), `proofs/fg041/check.sh`. Grep-verified: workspace members (49 `fgit-*` + registry-check), Rust line/file counts (crates only), `forbid(unsafe_code)` file count, and an exhaustive classification of all 49 remaining `unsafe`-keyword hits (no `unsafe fn`/`impl`/`{` block found anywhere in first-party code). Verified resolution of every Quick Link with `curl` (HTTP 200). Fetched live star/fork counts and release list from the GitHub API. Web-searched for independent coverage. **Not done:** did not compile the workspace, run any test or E2E suite, execute a benchmark, verify the Lean proofs by running `elan`, or execute any claim in the reality snapshot — all behavioral and performance claims rest on maintainer evidence plus revision-bound documentation.
## 4.2 Executive verdict

FrankenGit is a **genuinely substantive, unusually self-critical clean-room pure-Rust Git-compatible forge effort** [Inference, High] — not vaporware: a shallow clone of HEAD confirms 49 first-party crates and 589,340 lines of Rust [Verified, High], with the mass concentrated in `fgit-node` (100,802), `fgit-agent` (54,811), `fgit-admission` (31,137), `fgit-authority` (27,939), `fgit-cli` (24,454), and `fgit-wire` (22,743) [Verified, High]; an architecture built around the *authority-from-database* decoupling — one immutable decision stream plus a tiny conditional authority head replacing the mutable bare repository plus the product database as the single source of truth [Verified design, High]; a machine-checked claims registry whose verified rows cover narrow artifact-identity binding plus four Lean 4.32.0 theorems under three named boundary assumptions [Verified, High]; a 2026-09-07 revision-bound reality check documenting 178 acceptance IDs across five E2E suites exercising nonempty clone, raw push, historical state, incremental fetch, and SHA-256 repository behavior against a real `git` client [Maintainer claim, Medium-High — revision-bound with artifact locations]; and zero lines of first-party `unsafe` code by exhaustive grep [Verified, High]. Its most original contribution is **claim governance as machinery**: the auto-demoting registry, the 34-row negative-evidence registry, the checked-claims block the checker refuses to leave stale, and verification lanes that fail-closed with exit 3 instead of reporting false greens [Verified, High] — a genesis-stage method no incumbent forge ships. **But:** it is pre-release with zero tagged releases [Verified, High]; the integrated forge, hosted backend, web UI, TUI, and release product are all incomplete by the maintainer's own accounting, and smart HTTP and production SSH exist only as loopback-bound, refusal-heavy slices — not as production transports [Verified from README + code, High]; the one-runtime/projection/gateway product stack is coupled to sibling-repo constellation convergence (the lockfile already resolves asupersync 0.5.0 while the integration profile still plans against 0.4.x) [Verified, High]; zero independent validation of any kind was found [External, High within recall], the reality snapshot is 15 days stale relative to a tree moving ~25–40 commits/day [Verified, High], and the `LicenseRef-MIT-OpenAI-Anthropic-Rider` license withholds all rights — including benchmarking, testing, and analysis — from OpenAI and Anthropic, their affiliates, and anyone acting for them [Verified, High]: it is **not OSI open source**, and the README says so plainly. **NODUS: Explore. Wardley: custom-built bounded one-node Git server (TRL 4) with the integrated forge and agent-native vision at Genesis (TRL 2–3).** Its most durable contribution today is the **verification and claim-governance methodology**, not a usable forge [Inference, Medium].

## 4.3 Claim inventory: demonstrated vs aspirational

Status values: *demonstrated* / *partially demonstrated* / *aspirational* / *disproven* / *stale*.

| # | Claim | Status | Evidence |
|---|---|---|---|
| 1 | 49 first-party `fgit-*` crates (+ registry-check tool); ~589k Rust LOC | **Demonstrated** | [Verified, High] — counted from the clone; v1 draft's 47-crate/~597k figures are stale at the new HEAD (drift from 2026-09-21 to 2026-09-22) |
| 2 | Zero first-party `unsafe` code ("strictly memory-safe in first-party code") | **Demonstrated** | [Verified, High] — 449 files carry `#![forbid(unsafe_code)]`; all 49 remaining `unsafe`-keyword hits exhaustively classified as comments/doc strings/assertion messages/identifiers; no `unsafe fn`/`impl`/`{` block anywhere |
| 3 | Never links or invokes C Git, libgit2, or another Git engine in production | **Demonstrated** (dependency + code level) | [Verified, High] — zero `git2`/`libgit2` references in `Cargo.lock` or any first-party manifest; the constitution permits upstream Git executables only as pinned, sandboxed conformance oracles; runtime invocation of a Git binary was not traced process-by-process by the analyst |
| 4 | Bounded one-node Git server interop: 178 acceptance IDs across 5 E2E suites (nonempty clone, raw push, historical state, incremental fetch, SHA-256) | **Partially demonstrated** | [Maintainer claim, Medium-High] — revision-bound reality snapshot (2026-09-07, bound to `b74b666d`) with exact commands and artifact locations; not executed by analyst; snapshot is now 15 days stale |
| 5 | Machine-checked Lean proofs (4 theorems: terminal-outcome uniqueness, ref/forge visibility atomicity, publish continuity, crash-retry non-fabrication) | **Partially demonstrated** | [Verified registry + Maintainer claim, Medium] — registry rows CLM-002–005 bind artifacts to SHA-256 digests and pin lean4 v4.32.0, but the registry's own wording says "machine-checked-within-the-contained-lean-model-under-three-named-boundary-assumptions-only" and explicitly "not-a-proof-that-the-rust-implementation-refines-the-model" |
| 6 | Multicell SLO/capacity benchmark (CLM-006 "implemented") | **Partially demonstrated** — and **honestly gated by its own negative evidence** | [Maintainer claim with strong honesty, Medium] — single-host 128-core, in-process library calls, noise-floor-gated timings; the registry itself records NEG-029 (latency ordering rejected: 6–13ms spread vs 3.1–33.7ms A/A floor) and NEG-030 (capacity model unsupportable: saturation point 8 in one sweep, 2 in the next) |
| 7 | Smart HTTP / SSH as production transports | **Aspirational** | [Maintainer claim as *target*, High] — compatibility matrix lists them `required-v1`, but the matrix header states it is a "target registry, not an implementation claim"; reality snapshot: "Smart HTTP, production SSH, and a native API are still absent"; exercised lane is raw git-daemon, one session / one in-flight by default |
| 8 | Integrated forge (issues/PRs/search read models), agent service, hosted backend, web UI, TUI | **Aspirational** | [Verified from README, High] — the "What FrankenGit is not" section explicitly disclaims each as incomplete; `fgit-projection` has derived identity/watermark infrastructure but user-facing read models are "still unfinished" |
| 9 | Asupersync 0.4.x constellation integration ("one runtime") | **Aspirational** | [Maintainer claim, Medium] — profile doc says Asupersync/FrankenSQLite/fastapi_rust/sqlmodel_rust/FrankenTUI are "settled architectural adoptions" but "integration remains blocked until that owned sibling is updated and re-audited"; the embedded node already uses the admitted published FrankenSQLite/runtime stack [Verified profile text, High] |
| 10 | ATP-Git / RaptorQ permeation as production repair | **Partially demonstrated** | [Verified crates exist + Maintainer claim, Medium] — `fgit-raptorq`, object fabric, ATP-Git profile docs exist; the "What FrankenGit is not" section explicitly says "not RaptorQ used as consensus, hashing, or authorization"; live HTTPS object-store authority remains a product gap |
| 11 | "GitHub alternative" / GitHub replacement | **Aspirational** | [Verified from README, High] — the README's status banner: "not yet a general-purpose Git server, a production-ready forge, or a GitHub replacement"; this is a vision statement, not a capability claim |
| 12 | Auto-demoting claims registry (verified rows demote on artifact change) | **Partially demonstrated** (mechanism exists and is wired into the README block generator; the enforcement loop runs in the maintainer's process, not observed by the analyst) | [Verified, High] — registry header text and `tools/registry-check` exist; the checker "refuses a stale block" per README |
| 13 | "Extreme scale" (million-workspace TreeFS, per-core preparation) | **Aspirational** | [Maintainer claim, Medium] — TreeFS has a Linux sparse-directory *candidate* in `fgit-runner` (materializes real files; `fg at` time-travel scenario has 15 acceptance IDs); "Independent host-profile acceptance, public agent execution and the optional FUSE adapter remain outstanding" |
| 14 | Asupersync/FrankenSQLite "settled adoption" with integration gated on 0.4.x constellation convergence | **Stale/understated** | [Verified, High] — the profile doc's planning baseline is Asupersync 0.4.x ("last source review 2026-08-20"), but `Cargo.lock` at HEAD resolves **asupersync 0.5.0** (the crates.io max version) from the registry, with **10 first-party crates** (authority-fsqlite, lab, node, object-fabric, object-store, projection, raptorq, repair, runtime, ssh) depending on it and the `fsqlite` family present; `futures-executor` is absent from the lock. The profile doc lags the lockfile — the same README-vs-code drift pattern, now inside the dependency governance itself |

**README-vs-code drift (governance signal):** the v1 draft of this packet pinned `d584df9` (2026-09-21); at the new HEAD the crate count moved 47→49 and LOC moved 597,389→589,340 — a tree moving ~25–40 commits/day will rot any hand-written number within days, which is precisely why the maintainer's machine-checked registry matters more than prose numbers. The README's dated reality snapshot (2026-09-07) is 15 days stale at this HEAD — the clearest single governance finding: the project's own most legible status document lags its tree by two weeks of high-velocity development [Verified, High].
## 4.4 Architecture (reconstructed, not summarized)

[Verified from the clone at `894585a`; README diagrams treated as claims where noted]

**Crate topology (50 workspace members):** foundation (typed IDs/refusals `fgit-types`, canonical codec `fgit-codec` + `fgit-codec-verify`, claims `fgit-claim`, evidence `fgit-evidence`, resources `fgit-resource`, registry checker `tools/registry-check`); Git/storage primitives (objects `fgit-git-object`, packs `fgit-pack`, wire `fgit-wire`, authority `fgit-authority` + embedded FrankenSQLite adapter `fgit-authority-fsqlite`, object fabric `fgit-object-fabric`, RaptorQ `fgit-raptorq`, ATP-Git `fgit-atp-git`, TreeFS `fgit-treefs`, crypto policy `fgit-crypto`, deflate `fgit-deflate`); canonical engines (reference model `fgit-reference`, transaction kernel `fgit-txn`, chronicle `fgit-chronicle`, policy `fgit-policy`, forge events `fgit-forge`, GC/repair `fgit-repair`, materialization, generation authority `fgit-generation-authority` implied); derived systems (search, typed graphs `fgit-graph`, document lineage `fgit-doc`, agents `fgit-agent`, CI protocol, statistics `fgit-statistics`, projections `fgit-projection`); products/adapters (gateway, API, CLI `fgit-cli`, node `fgit-node`, runner `fgit-runner`, operations `ops/`, browser/WASM surfaces).

**Data flow (one-node bounded composition):** the `fg` binary (`crates/fgit-cli`, `[[bin]] name = "fg"`, `fn main()` verified present) — `fg init` creates or re-authenticates the empty canonical authority head → `fg import` verifies a bounded local object source (loose objects + checksum-bound idx-v2/pack-v2 pairs) and publishes source refs through the sealed admission/RCR/head-CAS path → `fg serve` runs a bounded raw git-daemon session (upload-pack default-enabled; receive-pack only with an explicit `--receive-principal` binding) → `fg export` writes an authority-selected pack to a previously absent path [README; binary target verified in code, High]. Notably, `crates/fgit-cli/src/smart_http_server.rs` (459 lines) and `ssh_server.rs` (320 lines) exist with real refusal logic ("serve-http refuses non-loopback plaintext listeners") — so the README's "Smart HTTP, production SSH, and a native API are still absent" is true of *production transports* but the slices exist in a loopback-bound, refusal-heavy form, exactly the README's own "bounded final-abstraction slice" doctrine [Verified code + README, High]. (The separate `fgit-ssh` crate also exists and depends on asupersync — same doctrine: a crate's presence names a bounded slice, not a production transport.) One pushed pack is bounded by a documented receive session envelope (size ceilings, work-proportional session budget, over-budget verdicts via report-status, never a silent hangup); one emitted pack is bounded by `--pack-max-expanded-mib` (128 MiB default). No command treats local object placement, routing hints, or connection-local ref maps as canonical state.

**Authority model:** one immutable repository decision stream + one tiny conditional authority head with exact-predecessor compare-and-swap; quarantine + sealed admission for foreign objects; anti-rollback discipline with explicit restore events; durable merge couples merge event, forge position, and canonical outbox state at one authority CAS (the `frankengit-asa3` bridge, delivered after the 2026-09-07 snapshot found durable forge merge blocked by `DurabilityProfileUnavailable`) [Maintainer claim, Medium-High]. The push path's atomicity boundary is the same everywhere: a pushed pack travels bounded framing → quarantine → validation → policy → sealed admission, and the *only* commit point is the exact-predecessor head-CAS — socket-local refs are never authoritative, so a failed CAS publishes nothing [README, High].

**Memory-safety posture** [Verified, High]: 449 `.rs` files carry crate/module-level `#![forbid(unsafe_code)]`; zero crates carry `deny`; an exhaustive grep of all 49 remaining `unsafe`-keyword hits found them all in comments, doc strings, assertion messages (e.g. `"manifest line {} has an unsafe label"`), identifiers (`unsafe_terminal`, `UnsafeLeaseLabel`), CSP assertions (`!SECURITY.contains("unsafe-inline")`), and a keyword byte-list — **no `unsafe fn`, `unsafe impl`, `unsafe trait`, or `unsafe {` block exists in first-party code**. The dependency constitution documents the one acknowledged external unsafe: the `cpufeatures` transitive dependency carries internal `unsafe` (`fgit-crypto/src/lib.rs` doc comment).

**Dependency posture:** the constellation is the story here — and the lockfile tells a newer story than the profile doc. `Cargo.lock` at HEAD resolves **234 external packages**, including **asupersync 0.5.0** (the crates.io max version, not the profile doc's 0.4.x planning baseline) depended on by **10 first-party crates** (authority-fsqlite, lab, node, object-fabric, object-store, projection, raptorq, repair, runtime, ssh), the `fsqlite` family, and zero `futures-executor` — the exact dependency the profile's fastapi_rust admission gate refuses [Verified from Cargo.lock, High]. Unlike FrankenRedis (which evaluated and *rejected* Asupersync), FrankenGit *adopts* the sibling stack — but the integration-profile doc's "last source review 2026-08-20" baseline is stale relative to the lockfile's 0.5.0, a governance signal that even the dependency documentation rots at this velocity. No first-party crate declares a build script; the one C-compilation surface in the lock is transitive (`blake3`'s `cc` build script for SIMD), which the closed-world allow-list constitution must carry a row for — the analyst did not verify the allow-list registry rows [Verified, High].

**Verification apparatus:** 54 E2E suites (`scripts/e2e/suites/`), 78 CI workflows (many agent-session workflows: `gpt56pro-*`, `native-*`, `source-*`); 6 claim rows in `registries/claims.tsv` with exact SHA-256 artifact bindings; 34 negative-evidence registry rows; the Lean fg041 lane with pinned lean4 v4.32.0; `full`/`release` lanes that fail-closed with exit 3 [Verified, High].

## 4.5 Benchmark and conformance audit

### Maintainer-produced numbers

| Workload | Result | Method controls | Would it survive independent rerun? |
|---|---|---|---|
| Multicell SLO/capacity benchmark (FG-036c) | Exact storage-amplification and cross-layer admission counts asserted with equality; timings reported but *not* latched as gates | In-process library calls; three cells, one fsqlite authority, one filesystem fabric; single-host 128-core shared developer machine; repeated measurement runs bounded to 20 minutes (GoldLotus grant 2026-08-24) | The counts likely would (exact equalities); the timings would not — the registry itself records why (see below) |
| Read-mode latency spread | 6–13 ms across modes — **rejected as a finding** (NEG-029) | A/A noise floor on the same configurations: 3.1–33.7 ms | The maintainer killed its own attractive result; this is the number that survives, as a *non-result* |
| Saturation point | 8 in one sweep, 2 in the next; back-to-back identical arms at 2 returned 95 and 15 ops/s — **capacity model unsupportable** (NEG-030) | Same host, twenty minutes apart | Killed honestly; survives as a non-claim |
| One-node E2E conformance | 178 acceptance IDs across 5 suites vs real `git` client; workspace `cargo test` 4,590 passed / 0 failed / 24 ignored (2026-09-07, bound to `b74b666d`) | Revision-bound with exact commands and artifact locations | Behavioral claims only — not executed by analyst; snapshot 15 days stale |

**Reproduction cost (honest):** the sanctioned path is the maintainer's bespoke RCH (remote-execution) + E2E orchestration; an independent rerun needs the pinned `nightly-2026-08-31` toolchain, a checkout of this tree (~590k lines), a pinned Git oracle for differential suites, and comparable single-host capacity for the FG-036c timing arms. Expect hours, not minutes — and the maintainer's own registry warns timings are comparable only within one run against that run's own A/A floor, never across runs.

### Conformance evidence

- **Real-`git`-client E2E:** 178 acceptance IDs across five suites (nonempty clone, raw push, historical state, incremental fetch, SHA-256) against the bounded one-node server [Maintainer claim, Medium-High].
- **Browser/smart-HTTP conformance:** 108 `.mjs` files counted at HEAD (smart-HTTP browser client conformance; v1 draft said 63, re-counted and corrected) [Verified, High]; execution history and per-run greenness not legible to the analyst — CI executes; greenness unknown.
- **Upstream-Git differential:** compatibility matrix oracles against pinned Git executables (clean-room rule: Git never enters production processes) [Maintainer claim, Medium].

**Reproduction cost (honest), E2E edition:** the 54 suites run through the maintainer's bespoke orchestration (`run_all.sh` discovering executable `.sh` under `suites/`); an independent rerun needs the pinned `nightly-2026-08-31` toolchain, a checkout of this tree (~590k lines), a pinned Git oracle for the differential suites, and a node.js runtime for the 108 `.mjs` files. Expect a long evening, not an hour — and the maintainer's own doctrine warns that no invocation is evidence for a later revision, so rerun at your own pinned commit.

### Independent numbers

**None found.** Web search returns only the repository itself, its commit pages, and a doc-file page [External, High within recall caveats]. No third-party benchmark, code review, or production deployment found. **Independent validation: zero.**
## 4.6 Comparison: who owns the lane

**The incumbent** is GitHub — with git itself, GitLab, Gitea, Forgejo, SourceHut, and Radicle in the surrounding lanes. GitHub owns "code forge" the way Redis owns caching: the moat is ecosystem (Actions, Copilot/agent integrations, security scanning, marketplace, social graph), network effects (your collaborators are there), and operational trust — not the Git protocol, which is a commodity [External, High]. **Why the incumbent wins today, in one paragraph:** no engineering team adopts a forge on implementation elegance; they adopt on migration cost, integration surface, SLA, compliance posture, and the answer to "who gets paged." FrankenGit has zero tagged releases, no hosted service (FrankenGit.com is a "deployment profile," not an operating service), no SLA, no compliance story, a single maintainer, and a license that legally excludes the two AI labs most likely to evaluate agent-native infrastructure. A fork of Forgejo buys you the whole GitHub-compatible surface today, maintained by a community, under a real open-source license.

**Adjacent lanes:** **SourceHut** (owns the minimalist/source-available forge lane with a real operating business), **Radicle** (owns the decentralized/p2p lane), **Gitea/Forgejo** (own the self-hosted GitHub-clone lane), **GitLab** (owns the all-in-one DevOps lane). FrankenGit is not competing with any of these today — it is competing with *absence*: there is no product to switch to.

**The genuinely unoccupied lane [Inference, Medium]:** the *agent-native forge* — a forge whose authority model is designed for autonomous coding agents from the start: evidence-carrying changes, intent-run/effect-authorization planes, cancellation lineage, agent quarantine, and verifiable recovery of what agents did and why. GitHub's agent story is bolted on (Copilot agents act *through* human-shaped APIs); SourceHut and Forgejo have no agent authority model at all. FrankenGit's decision-stream + authority-head + agent-protocol stack is the only in-tree artifact pointed at that gap — `fgit-agent` is 54,811 lines, the second-largest crate. But the lane is genesis-stage: the agent service is explicitly incomplete ("agent text interpreted as capabilities" is listed under "What FrankenGit is not"), and the license rider bars the two labs building the agent workforce from touching the code. **The adjacent-lane threat runs the other way too:** nothing in the claim-governance methodology is forge-specific — Forgejo or GitLab could adopt an auto-demoting claims registry and a negative-evidence ledger without the license, the nightly pin, or the 590k-line tree, commoditizing FrankenGit's most transferable artifact while ignoring its product [Inference, Medium].

## 4.7 Technical merit and adversarial review

**Strengths:**
1. **Claim governance as machinery, not culture.** The auto-demoting claims registry (SHA-256-bound artifacts, automatic demotion on change), the checker-refused stale README block, the 34-row negative-evidence registry with one-to-one prose/TSV correspondence rules, the fail-closed exit-3 dormant lanes, and NEG-017's rejection of "green CI = safe" — this is the methodology-export lens made concrete, and it is the single most transferable artifact in the packet [Verified, High].
2. **Genuine implementation volume in the hardest places.** 589,340 lines with the mass in node, agent, admission, authority, CLI, and wire; owned object/pack/delta/pkt-line/upload-pack/receive-pack implementations; a real git-daemon service lane with documented envelopes and typed refusals rather than silent hangups; SHA-256 repository support (not byte-aliasing) — the unglamorous correctness work that vaporware skips [Verified volume, High; behavior Maintainer claim, Medium].
3. **Negative-evidence discipline with teeth.** NEG-029 and NEG-030 are the maintainer *killing its own* latency and capacity findings with A/A-floor methodology; the ledger's 13 required entry classes (including `overclaim_correction` and `non_reproducible_result`) make killing findings a first-class workflow, not an embarrassment [Verified, High].
4. **Zero first-party unsafe, exhaustively confirmed.** Not "forbid(unsafe_code) in most files" — a complete grep shows no `unsafe fn`/`impl`/`{` block anywhere in 1,434 files, with the sole acknowledged external unsafe (`cpufeatures`) documented in a doc comment. NEG-008 rejects unsafe-as-necessary-for-performance as a constitutional matter [Verified, High].
5. **The refusal pattern is a genuine UX innovation for verification.** Dormant `full`/`release` lanes return typed exit-3 refusal; the receive-pack lane is disabled by default and must be bound to a principal; over-envelope inputs get diagnosable refusals rather than early EOFs. Fail-closed is applied consistently to *evidence*, *transport*, and *capacity* [Verified, High].

**Weaknesses:**
1. **Bus factor 1 at extreme velocity.** All of the last 100 commits are one human (Jeff/Jeffrey) at ~25–40 commits/day; the tree moved 47→49 crates and ±8k LOC overnight. The 2026-09-07 reality snapshot is already 15 days stale. Review depth cannot match that rate; the auto-demoting registry is load-bearing governance precisely because human review is structurally insufficient [Verified + Inference, High].
2. **Zero independent validation of any kind.** No third-party benchmark, code review, security audit, production deployment, or external contributor found. Every behavioral number in this packet is maintainer evidence [External, High within recall].
3. **The forge is a plan with a node, not a product.** 54 E2E suites exercise a bounded one-node server; smart HTTP, production SSH, native API, issues/PRs/search read models, web UI, TUI, hosted backend, and the release product are all explicitly "still absent." The 49-crate count is scope, not capability — the README warns that "a crate being present means only that its bounded final-abstraction slice exists" [Verified from README, High].
4. **Sibling-stack coupling.** Unlike FrankenRedis's standalone runtime, FrankenGit's one-runtime, projection, gateway, and TUI layers are blocked on Asupersync 0.4.x constellation convergence across four independently maintained sibling repos (fastapi_rust blocked on `futures-executor`, FrankenTUI on 0.3.9). FrankenGit cannot integrate its own product stack faster than its siblings converge [Verified from profile, High].
5. **The license is a strategic own-goal for the stated mission.** The rider withholds *all* rights — including benchmarking, testing, analyzing, and training-data incorporation — from OpenAI, Anthropic, affiliates, and anyone acting for them. For a project whose most distinctive wedge is the agent-native forge, legally excluding the two labs building the agent workforce (and chilling independent benchmarking by anyone) sabotages exactly the adoption path the technology would need. Unlike FrankenRedis's plain "MIT" badge, FrankenGit at least discloses it loudly — but the adoption ceiling is identical [Verified, High].
6. **Docs chronically lag the tree.** The reality snapshot is 15 days stale at ~30 commits/day; the v1 draft of this very packet (~12 hours old at the new HEAD) had 47 crates, 597,389 LOC, and 63 `.mjs` files — all wrong at the new HEAD. The registry machinery is the mitigation, but prose documentation rots in days, not months [Verified, High].
7. **The pinned nightly is a structural fragility.** The entire tree — 589,340 lines, 234 external packages — builds on `nightly-2026-08-31`, and there is no documented stable-Rust migration story. If the nightly ages out or a compiler regression lands, the single maintainer absorbs the full porting cost with no second toolchain-aware reviewer [Verified toolchain pin + Inference, High].
8. **The core wedge is unwired while the periphery grows.** `fgit-agent` is the second-largest crate (54,811 lines) and the agent-native plane is the project's only genesis-stage idea — yet the agent service itself is explicitly incomplete, hostile-code isolation is disclaimed ("a trusted local process is not a hostile runner"), and the 2026-09-07 snapshot's completed work is overwhelmingly Git-substrate, not agent-plane. The wedge that justifies the project is the least demonstrated part of it [Verified from README/snapshot, High].

**Steelman of the bear case:** FrankenGit is a monumentally over-engineered answer to a question the market stopped asking. Git hosting is a solved commodity — Forgejo gives you the whole GitHub surface, self-hosted, under a real open-source license, maintained by a community — and the remaining differentiator is trust, which no 0.x single-maintainer pre-release can claim. The agent-native wedge is a thesis in search of a buyer: no enterprise is asking its forge for "intent-run effect authorization"; they are asking for SSO, compliance, and uptime. The 589,340 lines at bus factor 1, on a pinned nightly, with a license that bars the exact labs who would evaluate it, has one overwhelmingly likely terminal state: the maintainer's velocity decays, the tree bit-rots, and the agent-native forge never ships — leaving behind an excellent negative-evidence ledger documenting why. The methodology is admirable; methodologies don't host your repos. And the packet's own fallback — that the methodology outlives the product — is itself unproven until a second project adopts the registry; today it is a thesis about the thesis.

**Hook audit (the packet grades its own hook):** "589,340 lines of first-party Rust containing zero lines of `unsafe` code — governed by a claims registry that automatically demotes its own verified rows the moment a required artifact's digest no longer matches." Line count is counted; "zero lines of `unsafe` code" means zero `unsafe` *constructs* (`fn`/`impl`/`trait`/`{` block) — 49 lines contain the *word* `unsafe` in comments, strings, and identifiers, which the did-you-know states plainly, so the hook is not misleading; the auto-demotion rule is quoted from the registry header ("any mismatch is an automatic demotion, not a reviewer-overridable status transition"). The hook survives — no marketing adjectives, every load-bearing word checkable.

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

**License text, read verbatim** [Verified, High]: `LICENSE` is the MIT License **with an "ADDITIONAL RIDER / RESTRICTION (OpenAI / Anthropic)"** that is "part of the 'conditions' of this License" and "controls" in any conflict. Quoted scope: *"Restricted Parties" means OpenAI, L.L.C.; Anthropic, PBC; any of their respective Affiliates; and any person or entity acting directly or indirectly on behalf of, for the benefit of, or under the direction of any of the foregoing (including any officer, director, employee, contractor, agent, consultant, service provider, or representative).* *"Notwithstanding any other provision of this License, no rights are granted to any Restricted Party."* Disclosure/hosting/distribution to them is forbidden. *"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 terminates all permissions automatically (plus destruction of copies, injunctive relief, and attorneys' fees to Jeffrey Emanuel). **Classification: NOT OSI open source** — named-party discrimination with a use-restriction covering even benchmarking and analysis. Source-available with a targeted exclusion. The repository's own decision doc (D14, resolved 2026-08-23 by owner Jeffrey Emanuel) records the OSI marker as `no` and mandates exact wording: "must be described that way" — and unlike FrankenRedis's plain "MIT" badge, FrankenGit's README discloses the rider loudly and repeatedly [Verified, High].

**The rider as strategy:** coherent defensively (prevents the two labs best positioned to absorb the work into training corpora or agent-evaluation harnesses from doing so without permission) and self-sabotaging offensively: the agent-native forge's natural evaluators and acquirers are precisely the excluded parties, the benchmarking ban chills the independent validation the project most needs, and "source-available, not open source" caps enterprise adoption. The stated mission is a *GitHub alternative*; the license pre-excludes the two companies whose distribution would make that alternative legible [Inference, Medium].

**Governance:** owner-directed single maintainer; no external contributors visible in the last 100 commits; commit velocity ~25–40/day with agent-persona campaign IDs (`frankengit-hh37`, `frankengit-asa3`, `frankengit-fg047-ssh-transport-21b`); the `.beads` issue tracker is the planning surface; licensing decisions (D14) are owner-resolved and machine-enforced — `AGENTS.md` §10 mandates "No document may claim open source while that holds" and `scripts/license_gate.sh` consumes the decision's HTML markers [Verified, High]. **What breaks first if velocity decays:** the 589k-line tree on a pinned nightly with no second maintainer and no release — the registry auto-demotion will correctly report everything demoting, and bit-rot sets in within quarters.

## 4.9 NODUS factsheet

| Criterion | Score | One-line justification |
|---|---|---|
| Technology readiness (TRL 1–9) | **4** | Bounded one-node server interop validated in lab against real `git` client; TRL 5 requires validation of *integrated* components in a relevant environment — the forge, transports, and product stack are not integrated, so 4 is the ceiling |
| Strategic relevance (1–5) | **3** | Agent-native forge authority model is a real strategic gap; capped by rider, pre-release state, and GitHub's ecosystem moat |
| Impact potential (1–5) | **3** (4 if claim-governance methodology is counted as the product) | Forge market is entrenched; methodological export is the higher-probability impact |
| Implementation feasibility (1–5) | **3** | The one-node core is largely built; smart HTTP/SSH, projections, UI, and hosting are bounded but very real work — gated additionally on sibling-repo convergence |
| Time to mainstream (1–5) | **1–2** | Years minimum: needs a release, independent validation, a second maintainer, and a license change for broad adoption |
| Collaboration potential (1–5) | **2** | Source-available; rider blocks the two most likely AI-lab collaborators; bus factor 1; contribution bar is constitution-heavy |

**Ring: Explore.** The ring rules are decisive: *Pilot* requires a release artifact plus a bounded real-workload fit (no release exists); *Invest* requires independent validation plus governance (neither exists). Explore is the default for substantive-but-unproven, and FrankenGit is the definition of it. Revisit triggers: first tagged release, smart-HTTP/SSH production transports landing, a second maintainer, an independent benchmark/security review, or any change to the license rider.

## 4.10 Wardley placement

- **Git protocol compatibility:** Commodity — git/Forgejo/Gitea own it; FrankenGit adds no leverage here.
- **Bounded one-node Git server (clean-room, zero-unsafe):** Custom-built → early Product — works in lab, pre-release, revision-bound evidence; moves to Product with a tagged release + independent validation.
- **Integrated agent-native forge (issues/PRs, UI, hosting, agent authority plane):** Genesis — the most distinctive wedge, but "still absent" by the maintainer's own accounting; moves right with working read models and a hostile-code isolation story.
- **Claim-governance apparatus (auto-demoting registry, negative-evidence ledger, fail-closed refusal lanes, license gate):** Custom-built, genesis-flavored — novel as a packaged discipline and the most transferable component; moves toward Product the moment a second project adopts it (see next step 1), and stays left until that adoption is observed.
- **ATP-Git / RaptorQ permeation / object fabric (Git at any scale):** Genesis → early Custom-built — a real architectural bet with bounded implementations; moves right with a published scaling curve on a real corpus (see next step 3).

**The decoupling lens:** FrankenGit represents *authority-from-database* (the decision stream replaces the mutable bare repo + product DB as the single source of truth), advances *engine-from-C-Git* (clean-room Rust, Git only as a conformance oracle), and gestures at the next decoupling the deep-dive named — *memory-from-the-store*: evidence-carrying agent changes with portable provenance, where the forge becomes an interchangeable executor of an attested intent/effect protocol. That third decoupling is the project's only credible claim to a future the incumbents aren't already occupying.
## 4.11 Trajectory (12 / 24 / 60 months) — [Inference]

- **12 months:** continued high-velocity single-maintainer/agent work; smart-HTTP production transport likely lands (it is `required-v1` in the matrix); the sibling constellation question sharpens rather than resolves: `Cargo.lock` already resolves asupersync 0.5.0 while the integration profile and its gates still plan against 0.4.x — the next 12 months test whether the governance docs and admission gates catch up to the lockfile, or whether the product stack integrates ahead of its own paperwork; probable first tagged release of the bounded node; reality snapshot either gets a refresh cadence or drifts further. Stays in Explore.
- **24 months:** bifurcation. **Upside:** a second maintainer or institutional adopter appears, an independent security review validates the authority/CAS model, the agent-native plane survives a red-team campaign, a tagged release stabilizes the one-node server for narrow workloads (agent sandbox forges, auditable embedded Git) — Pilot for those workloads. **Decay:** velocity slows with no successor; the pinned nightly ages; 590k lines become unmaintainable; the claims registry correctly demotes everything and the tree drifts to Monitor as a research artifact whose methodology outlives its product.
- **60 months:** binary. Either a niche-but-real artifact (the agent-native, evidence-carrying forge substrate embedded in agent infrastructure — the "git for agent memory" lane), or superseded: GitHub/GitLab absorb agent-authority features, Forgejo adds the self-hosted surface, and the general "Rust Git" lane consolidates around whichever peer ships first. The claim-governance methodology is the more likely survivor either way [Inference, Medium].

**Revisit triggers (concrete, observable):** first tagged GitHub release; smart-HTTP or production SSH landing as a verified lane; a second human maintainer with merge rights; any independent benchmark, security audit, or production deployment; Asupersync 0.4.x constellation convergence unlocking the gateway/projection/TUI stack; any change to the license rider; a refreshed dated reality snapshot.

## 4.12 Limitations and open questions (mandatory)

**Not done:** did not compile the workspace, run any test or E2E suite, start the server, execute a benchmark, verify the Lean proofs by running `elan`/`check.sh`, or execute any claim in the reality snapshot — all behavioral and performance claims rest on maintainer evidence plus revision-bound documentation. Shallow clone only (no history beyond HEAD; prior 100 commits fetched for velocity analysis). CI per-run pass/fail not legible from text scraping. Star/fork counts from a live API read. Browser `.mjs` files counted but not executed. The FG-036c benchmark numbers were not reproduced. The dependency constitution's closed-world allow-list registry rows were not individually verified against the 234 external `Cargo.lock` packages. Web search for independent coverage carries the usual recall caveats.

**Open questions that would most change the verdict:** actual CI greenness over time; whether the Lean theorems' three boundary assumptions hold against the real authority store; whether any enterprise has evaluated the rider's legal exposure; funding and succession intentions of the maintainer; whether the Asupersync constellation ever converges; what happens when the nightly pin ages out; whether the reality snapshot gets a refresh cadence.

## The eight deepening questions (one paragraph each)

1. **Provenance.** FrankenGit records *who/what produced what* better than any other FrankenSuite repo assessed: the immutable decision stream binds intent runs, effects, seals, and policy epochs; the claims registry binds claims to artifact digests; `AuthorityReadReceipt`s attest reads; and the `FG-033a` HEAD commit ("export authority-bound repository source backups") is explicitly about portable repository source backups. Making attestation portable across forges would require hash-chaining decision batches, operator-signed batch receipts, and a foreign-forge import path that verifies the chain — the reality check's own wording ("capsule checkpoints prove a past state, not currentness") shows the maintainer knows the hard part is currentness, not history [Verified ledger/contract docs, High; cross-forge feasibility Inference, Medium].

2. **The embeddable unit.** The smallest useful adoptable piece is the claims-registry checker (`tools/registry-check`) plus the claims/negative-evidence TSV schemas: a generalizable claim-governance method with no Git dependency. The next-smallest unit is `fgit-git-object`/`fgit-pack`/`fgit-deflate` (owned Git primitives), but adoption cost is steep: everything lives in a 50-member workspace pinned to `nightly-2026-08-31`, and no `fgit-*` crate is published on crates.io (API 404 for `fgit-types`, `fgit-git-object`, `fgit-claim`) — there are no published registry artifacts, so embedding means vendoring nightly-only, rider-encumbered source [Verified, High].

3. **Unexercised option value.** The architecture holds at least four unused capabilities: the Lean fg041 lane is verification-only and never linked into a production crate (the registry's own non-claim says so — the trace-refinement bridge exists but "does not exercise these theorems"); the differential-conformance machinery (pinned-Git oracles, 54 E2E suites, 108 browser tests) is aimed only at itself; the RaptorQ permeation map is built but not wired to live HTTPS object-store authority; and the decision stream is one serialization away from becoming a portable cross-forge evidence log [Verified, High]. What unlocks them is, respectively, linking the proof lane into CI as a gate, decoupling the harness from FrankenGit's fixture schema, completing the artifact wiring, and signing batch receipts — all product decisions, none blocked on research [Inference, Medium].

4. **Benchmark honesty.** The numbers most likely to survive an independent rerun are the *killed* ones — NEG-029 (latency ordering rejected: 6–13 ms spread vs 3.1–33.7 ms A/A floor) and NEG-030 (capacity model unsupportable: saturation 8 vs 2 across sweeps) — because they are the maintainer's own published non-results with documented methodology, and nobody publishes non-results they can't defend [Inference, Medium]. The 178 acceptance IDs and 4,590-passed test count are revision-bound (2026-09-07, `b74b666d`) and now 15 days stale on a tree moving ~30 commits/day — they are evidence about September 7th, not September 22nd. The load-bearing claim for the whole packet is not a number but the registry's auto-demotion rule, which is mechanism, not measurement [Verified, High].

5. **The governance path.** The credible route from one maintainer to an institution runs through a tagged release of the bounded node: a release creates users, users file issues against real deployments, and a second maintainer emerges from the user base or from a company that depends on the agent-native story — there is no shortcut, because today there is no artifact to adopt and the contribution bar is constitution-heavy [Inference, Medium]. What breaks first if velocity decays is not review depth (the registry already compensates) but *velocity-dependent coherence*: at ~30 commits/day the prose docs already rot in days (the reality snapshot is two weeks stale); a slowdown without a successor strands 589,340 lines on a pinned nightly with nobody who understands the whole authority chain, and bit-rot sets in within quarters [Inference, High].

6. **The license as strategy.** The rider excludes exactly OpenAI, L.L.C., Anthropic, PBC, their affiliates, and anyone acting for, benefiting, or under the direction of them — and it defines "use" to include benchmarking, testing, analyzing, indexing, and training-data incorporation, with automatic termination, copy destruction, and injunctive relief to Jeffrey Emanuel [Verified verbatim, High]. As strategy it is coherent defensively (it prevents the two labs best positioned to absorb the work from doing so without permission, and D14 made the choice deliberately and loudly) and self-sabotaging offensively: the project's most credible future is agent-native forge infrastructure, the excluded parties *are* the agent-infrastructure builders, and the benchmarking ban chills the independent validation the project most needs — which helps explain why independent validation is zero [Inference, Medium].

7. **Agent-era fit.** The concrete workload that would pick FrankenGit over Forgejo or GitHub is an agent sandbox or edge deployment needing a *governed* Git forge for autonomous coding agents — intent runs with effect authorization, cancellation lineage, agent quarantine, and an evidence stream reconstructing exactly what the agent did and why — which is precisely the decision-stream-plus-agent-protocol combination no incumbent offers [Inference, Medium]. What would have to become true first: completion of the agent service (currently "agent text interpreted as capabilities" is a *disclaimed* anti-goal, i.e. the plane is designed but unwired), a hostile-code isolation story (today "a trusted local process is not a hostile runner"), an independent red-team of the effect-authorization plane, a tagged release with a stability commitment, and — unavoidably — a license an agent-platform company can actually sign [Inference, Medium].

8. **The kill test.** The single event that would falsify the core thesis — "a forge designed for agents around an immutable decision stream is worth building" — is GitHub (or GitLab) shipping agent-authority as a first-class primitive: evidence-carrying agent actions with cancellation lineage and verifiable recovery, backed by institutional governance and a clean license, would commoditize FrankenGit's only genesis-stage idea and leave it competing purely on implementation, a fight it cannot win at bus factor 1 with no release [Inference, Medium]. The experimental falsifications are nearly as decisive: a red-team campaign demonstrating that agent effects can bypass the intent-run binding (an effect the decision stream cannot even reconstruct), or an independent rerun of the FG-036c suite showing the exact-count claims don't reproduce outside the maintainer's host — either would collapse the two pillars (trustworthy agent authority, honest measurement) the thesis stands on [Inference, Medium].

---

**Working notes:** clean shallow clone at `~/workspace/.scratch/frankengit-verify/` (HEAD `894585a`, 2026-09-22). All numbers counted from this clone. No durable user-facing files created besides this assessment and its versioned intermediates.