Status: design repository only. This repository contains the target-state README, comprehensive architecture plan, normative registries, threat model, schemas, and a validation harness. It does not yet contain a working forge or Git server. The present tense below describes the system this project intends to build, not functionality that already ships.
Brand warning. The Git Project's trademark policy prohibits using “Git” as a syllable in a new product or service name without written permission. “FrankenGit” is therefore a research codename, not a cleared commercial brand. Gate G0 requires either written permission or a new product name before public launch.
An agent-native, self-hostable software forge whose authoritative repository state lives in an append-only object-store ledger while ordinary Git repositories on local NVMe act as disposable, elastically replicated materialized views.
Stock Git over SSH and HTTPS. Issues, pull requests, reviews, merge queues, CI, releases, packages, code search, audit, and enterprise identity. No fixed repository replica count. No network filesystem under Git. No database projection more authoritative than the repository ledger. Every important transition is attributable, replayable, and independently checkable.
Git itself is not the problem. Git's object model, packfiles, reachability machinery, commit graph, bitmaps, partial-clone protocol, and local execution paths remain extraordinarily effective. The scaling problem appears when a forge treats a mutable bare repository on one or more servers as the durable primary and then tries to make those filesystem trees highly available.
That architecture creates a permanent compromise. A small repository still occupies a configured number of full replicas. A hot monorepo cannot exceed that fixed replica set without a bespoke migration. Repacking work is repeated on replicas or coordinated around a primary. Repositories become stateful pets whose placement, repair, backup, and failover dominate operations.
FrankenGit reverses the authority relationship:
- The Repository Ledger is authoritative. It is an append-only chain of immutable ingress packs, ref transactions, policy decisions, collaboration events, and verified checkpoints. A tiny root pointer is the only mutable object, and publication is a conditional compare-and-swap.
- A Materializer is a normal Git repository on local NVMe. It is fast because Git is fast on local storage. It is disposable because every byte and ref can be reconstructed from the ledger. An idle repository can have zero warm materializers; a hot repository can have as many as traffic requires.
- The Forge Ledger shares the same per-repository transaction boundary for semantic transitions that must be atomic with refs. A merge can advance the protected branch, close the pull request, consume a merge-queue position, bind exact check results, and record the policy epoch in one repository transaction.
- The Agent Plane exposes capabilities Git hosting never designed for: checkoutless workspaces, path- and ref-scoped authority, reproducible context capsules, batch tree reads, semantic retrieval, provenance receipts, and branch-per-agent isolation.
- The Bulk Plane uses systematic RaptorQ coding selectively for large packs, bundles, CI artifacts, cold archives, and multi-donor hydration. It never uses fountain coding as a substitute for linearizable publication or cryptographic integrity.
- The Evidence Plane uses deterministic simulation, bounded model checking, differential conformance, e-processes, and conformal calibration according to a strict claim taxonomy. Statistical evidence can trigger a rollback or fail a promotion gate; it can never prove an invariant.
The result is not “Git rewritten in Rust.” It is a forge that preserves Git's compatibility and execution strengths while replacing the operational assumptions around it.
| Bet | Statement | Consequence |
|---|---|---|
| B1 · Ledger authority | The durable truth is an immutable repository transaction stream plus a conditionally updated root pointer. | Local Git repositories, SQL projections, search indexes, and graph indexes are rebuildable views. |
| B2 · Git as execution kernel | Upstream Git remains the compatibility oracle and hot-path pack/reachability engine until a replacement proves byte- and protocol-level parity. | Stock clients work; the project does not spend its first years recreating pack negotiation badly. |
| B3 · Elastic materialization | A repository has zero to many disposable NVMe materializers according to current demand. | Replica count becomes a cache-allocation decision rather than a durability contract. |
| B4 · One semantic transaction | Ref updates and the forge effects that logically depend on them publish together. | A merged pull request can never be closed without its target ref update, or vice versa. |
| B5 · Agent-native by construction | Workspaces, context, authority, provenance, and review are first-class typed objects rather than conventions layered over branches. | Thousands of agents can work concurrently without thousands of full clones or ambient write tokens. |
| B6 · Progressive intelligence | Exact lexical and symbol retrieval returns first; semantic and graph refinement arrive progressively with explicit freshness and explanation. | Humans get fast deterministic results; agents can request richer context without losing provenance. |
| B7 · Information-theoretic bulk resilience | Large immutable objects may be served and repaired from any sufficient set of authenticated RaptorQ symbols. | Edge caches and storage donors cooperate without replica-specific ownership or whole-object retransmission. |
| B8 · Evidence before adjectives | Every reliability, compatibility, performance, and security claim names its proof class and evidence. | “Linearizable,” “compatible,” “self-healing,” and “deterministic” cannot appear as unscoped marketing language. |
No individual bet is sufficient. The leapfrog comes from their composition.
FrankenGit is a complete software forge with three deployment postures sharing one semantic state machine:
- Single-node self-hosted. One binary, one local data directory, an embedded SQL projection, a POSIX root backend, and an optional local runner. The operator can install it without Kubernetes, an external database, or an object-storage account.
- Highly available self-hosted. Stateless API and Git frontends, a materializer pool, an S3-compatible object store with strong conditional writes, an external identity provider, and optional isolated runner fleets. A small embedded Raft root service is available when the chosen object store cannot provide the required single-key compare-and-swap contract.
- Hosted service. Multi-tenant control planes, regional materializer and runner pools, CDN/edge bundle delivery, tenant-scoped encryption keys, public transparency witnesses, metering, support, compliance, and private networking. The hosted service runs the same open-source core rather than a deliberately crippled community edition.
The 1.0 product contract includes Git hosting, organizations and teams, issues, pull requests, code review, protected branches and rulesets, merge queues, CI workflows, releases, packages, Git LFS, search, audit, webhooks, REST and GraphQL compatibility surfaces, migration tooling, and the native agent API. Social-network features, hosted development environments, broad package-ecosystem breadth, and federation are intentionally post-1.0 unless a deployment needs them earlier.
┌────────────────────────────────────────────────────────────────────────────┐
│ CLIENT SURFACES │
│ stock Git SSH/HTTPS · web UI · REST/GraphQL · CLI · MCP/JSONL agent API │
└──────────────────────────────────────┬─────────────────────────────────────┘
│
┌──────────────────────────────────────▼─────────────────────────────────────┐
│ GATEWAY + WARDEN │
│ identity · caveated capabilities · admission · budgets · policy epoch │
└───────────────┬──────────────────────┬──────────────────────┬───────────────┘
│ │ │
┌───────────────▼─────────────┐ ┌──────▼──────────────┐ ┌────▼───────────────┐
│ GIT SERVICE │ │ FORGE SERVICE │ │ AGENT SERVICE │
│ receive/upload-pack │ │ issues/PR/review │ │ virtual workspaces │
│ quarantine/fsck │ │ merge queue/checks │ │ context capsules │
│ protocol v2/bundle URIs │ │ releases/packages │ │ scoped tool calls │
└───────────────┬─────────────┘ └──────┬──────────────┘ └────┬───────────────┘
└──────────────────────┼──────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ REPOSITORY LEDGER │
│ immutable packs + typed transactions + signed receipts + checkpoints │
│ one conditional RootPointer publication orders each repository's state │
└───────────────┬─────────────────────────┬───────────────────────────────────┘
│ │
┌───────▼────────┐ ┌───────▼──────────────────┐
│ OBJECT STORE │ │ TRANSPARENCY / EVIDENCE │
│ packs, symbols │ │ hash chain · MMR · DSSE │
│ artifacts │ │ witnesses · replay packs │
└───────┬────────┘ └──────────────────────────┘
│
┌───────────────▼────────────────────────────────────────────────────────────┐
│ ELASTIC MATERIALIZERS │
│ ordinary bare Git repos on local NVMe · reftable · MIDX · bitmaps │
│ hydrate from checkpoint + tail · validate root before serving │
└───────────────┬─────────────────────────┬───────────────────────────────────┘
│ │
┌─────────▼───────────┐ ┌────────▼───────────────────┐
│ DERIVED PROJECTIONS │ │ CRUCIBLE CI / RUNNERS │
│ SQL · search · graph│ │ OCI/microVM/WASI isolation │
│ rebuildable by seq │ │ SLSA/in-toto provenance │
└─────────────────────┘ └────────────────────────────┘
The architectural line that matters is the one around the Repository Ledger. Anything below or beside it can be deleted and rebuilt without changing repository semantics.
A push is not acknowledged merely because git-receive-pack accepted bytes on one machine. It is acknowledged only after the incoming data and the ref transition are durably published in the ledger.
The normal push path is:
- The gateway authenticates the principal and mints a request capability containing tenant, repository, allowed ref patterns, path constraints when applicable, expiry, policy epoch, and resource budget.
- Upstream
git-receive-packaccepts the wire protocol and places incoming objects in Git's quarantine environment. No quarantined object is visible through a ref. - The ingress worker normalizes thin packs, indexes them, checks object-format consistency, runs connectivity and configured
fsckpolicy, computes storage digests, and records a deterministic validation receipt. - The complete immutable pack, indexes, and receipt are uploaded. Large objects may additionally receive a RaptorQ transfer manifest and repair symbols according to policy.
- The worker builds a
RepoTransactioncontaining the expected root generation, ref commands and expected old object IDs, immutable pack inventory, actor, request ID, policy and authorization digests, Git object format, collaboration effects, and evidence references. - The transaction is published by conditionally replacing the repository's tiny
RootPointer. A conflicting writer rereads the new root, revalidates expected refs, and either retries or returns a precise conflict. Non-conflicting prepared transactions may be group-published in one root transition while retaining a deterministic virtual order. - Only after successful publication does the server report success. A lost response is safe: the request ID and intended ref state make a retry idempotent.
- Materializers learn about the new generation, fetch the immutable pack, and apply the refs. This makes future reads fast, but materializer completion is not required for durability.
The root compare-and-swap is the linearization point. RaptorQ does not linearize anything. Gossip does not linearize anything. A SQL row does not linearize anything. A local ref update does not linearize anything.
A single root naturally serializes semantic transitions, which is necessary for atomic refs but can become a throughput limit. FrankenGit adds an optional, fenced publication combiner for repositories whose measured contention crosses a policy threshold. Prepared transactions enter a durable queue; the current sequencer validates a batch, assigns a virtual order, and publishes one segment and one root update. The sequencer is an optimization, not an authority: any node can acquire a higher epoch by compare-and-swap after failure, and queued transactions remain independently verifiable.
The performance target is therefore expressed relative to the backend's measured conditional-write rate: non-conflicting tiny transactions must achieve a configurable multiple of raw root-CAS throughput through safe batch publication, with an explicit p99 latency ceiling. The plan does not promise an invented pushes-per-second number before the backend, batch size, push shape, and durability profile are pinned.
A request is routed by rendezvous hashing to a preferred materializer, but routing is only a cache hint. Before serving a ref-sensitive request, the node validates its applied root generation against the authoritative root. A fresh node serves immediately. A stale node applies missing tail segments. A cold node hydrates from the newest verified PackEpoch checkpoint and then applies the tail.
Stock Git protocol v2 remains the client contract. FrankenGit uses existing extension points rather than inventing a private clone protocol:
- Bundle URIs let clients or CI farms bootstrap from immutable bundles served by a CDN or regional cache.
- Packfile URIs can move selected pack payloads off the origin response.
- Partial clone and promisor remotes let clients avoid fetching blobs they do not need.
- Commit graphs, multi-pack indexes, reachability bitmaps, and reftable are generated once per verified pack epoch and reused by materializers.
An enhanced Franken client can additionally request multi-donor RaptorQ symbols and resume interrupted hydration, but the origin gateway reconstructs ordinary packfiles for unmodified Git clients.
Git's loose objects and incremental packs are excellent for ingestion but accumulate work over time. A fenced compactor builds a candidate PackEpoch from an exact root generation:
- a normalized base pack set;
- multi-pack indexes and reachability bitmaps;
- commit graphs and changed-path Bloom filters;
- full and partial-clone bundle sets;
- object inventories and reachability witnesses;
- Git-version and option manifests;
- logical-equivalence and
fsckreceipts.
Pack bytes are not assumed to be deterministic across Git versions or thread schedules. The invariant is logical equivalence: the checkpoint must expose exactly the same refs and reachable object closure as the source generation. A candidate checkpoint becomes authoritative only after independent verification and root publication. Other materializers download the result instead of repacking independently.
Garbage collection is ledger-aware. An object cannot be retired while reachable from a live or protected ref, pull request, release, active agent workspace, CI lease, backup, legal hold, retention policy, or materializer generation that remains eligible to serve. Ref history and object-byte retention are separate contracts; indefinite rewind requires an archival policy and must not be implied by an event log whose payloads have already been deleted.
RaptorQ is a systematic fountain code standardized by RFC 6330. FrankenGit applies it to immutable bulk objects only when the expected transfer or durability gain exceeds its encoding, storage, and operational cost.
A CodedObjectManifest binds the encrypted object's digest and length to its RaptorQ object-transmission information, source-block layout, symbol size, symbol identifiers, donor policy, and cryptographic authentication. The original source symbols are directly usable; repair symbols can be generated or stored according to the durability profile. A recipient reconstructs the exact ciphertext from any sufficient authenticated symbol set and then verifies both the storage digest and the native Git or artifact digest.
Useful lanes include multi-region pack hydration, edge-assisted clones, large CI artifact distribution, cold archives spread across independent storage providers, and repair after sampled scrub failures. Tiny commits, ref roots, policy records, and normal issue events are not fountain-coded. Object-store replication and RaptorQ are complementary; neither is allowed to obscure which durability assumptions are actually being purchased.
Issues, pull requests, reviews, labels, rulesets, merge queues, releases, and final check conclusions are typed repository events. Query databases are projections of those events.
A pull-request merge transaction binds:
- the expected pull-request state and version;
- exact base and head commit object IDs;
- the merge method and resulting commit;
- required review decisions and CODEOWNERS evaluation;
- required check-run identities, workflow digests, and conclusions;
- policy, organization, team-membership, and key epochs;
- queue position and speculative-merge basis, when used;
- target ref expected-old and desired-new object IDs;
- the pull-request state transition and audit receipt.
All of those effects publish in one repository transaction. The web UI cannot display “merged” while the branch remains unchanged, and a successful ref update cannot leave the pull request open because an SQL commit failed later.
Cross-repository operations are intentionally not described as atomic. They use an explicit ChangeSet saga with prepared, committed, compensated, and manually resolved states. The UI and API expose those states instead of pretending a distributed transaction exists.
Traditional forges give an agent a personal access token and tell it to clone a repository. FrankenGit gives the agent a bounded workspace and exactly the authority and context it needs.
An agent workspace is a content-addressed overlay over a base commit, not a full clone. The native API supports batch tree listing, ranged blob reads, expected-OID writes, renames, patch application, object creation, diff computation, test requests, commit construction, and publication to a hidden agent ref or pull request. Every mutation names the blob or tree version it expects, so stale edits fail with structured conflicts rather than overwriting another agent's work.
Workspaces live under hidden refs/agents/<principal>/<workspace> only when a real Git ref is needed. Most intermediate state remains an overlay with a lease and retention policy. Path leases are advisory coordination unless a repository policy explicitly makes them mandatory.
Each agent call carries a short-lived capability whose caveats can restrict:
- tenant, repository, branch, and path prefixes;
- read, search, write, test, publish, review, or merge operations;
- maximum bytes, requests, tokens, CI minutes, and object writes;
- allowed tools, runners, network destinations, and secret classes;
- expiry, parent delegation, human-approval requirements, and policy epoch.
Authority is passed explicitly through request context rather than read from ambient process state. Budget reservation and commit are two-phase, so cancellation does not silently double-charge or leave half-published effects.
A ContextCapsule is a reproducible answer to “what did this agent know?” It records the base repository root and commit, index watermarks, exact blob object IDs and source spans, search queries and result ordering, dependency or provenance graph slices, policy epoch, retrieval profile, omissions, byte/token budget, and optional model/tool receipts. The capsule itself is immutable and content-addressed.
Exact and deterministic retrieval lanes can be replayed byte-for-byte. Model-dependent reranking is marked as such and records the model identity, inputs, output digest, and available seed/configuration; it is never relabeled deterministic merely because a temperature field was set to zero.
The forge understands that ten agents may attack one issue at once. It detects overlapping read/write sets, predicts textual and semantic conflict regions, queues independent changes together, and can run speculative merges and tests. Agent-generated conflict resolutions remain candidates with evidence, not silent truth. Repository policy decides when a human review, deterministic checker, or signed runtime attestation is required.
Search follows a progressive contract inspired by FrankenSearch but implemented independently under this repository's license:
- exact path, ref, symbol, and lexical results return first;
- BM25 and structural language indexes refine recall;
- vector retrieval and optional reranking refine semantic relevance;
- repository, dependency, ownership, review, and provenance graph expansion adds relational context;
- reciprocal-rank fusion combines eligible lanes with deterministic tie breaks.
Every response reports the repository root, index watermark, staleness, ranking profile, per-result evidence, and whether any nondeterministic model participated. Search and graph indexes are rebuildable; they never determine whether a ref update exists.
Markdown rendering uses one source-spanned AST for server HTML, browser/WASM preview, plain text, and release-document rendering. Raw HTML is policy-gated and sanitized. Given the same input, renderer version, policy, and SOURCE_DATE_EPOCH, deterministic profiles produce byte-stable output. Source spans remain available to review agents and security tooling.
Crucible parses supported GitHub Actions and native workflow syntax into a typed workflow IR. A compatibility report identifies unsupported or behaviorally different constructs; the system never silently pretends full GitHub Actions compatibility.
The scheduler uses structured concurrency: every workflow owns jobs, every job owns steps and service containers, cancellation drains the tree, and final state is not published until child obligations are resolved or explicitly abandoned under policy. Runners support local shell for trusted development, OCI containers by default, hardened microVM profiles for hosted untrusted workloads, and WASI for eligible hermetic steps.
Security-sensitive properties are control-plane enforced:
- action references resolve to exact commits or content digests;
- fork pull requests receive no write token or protected secret by default;
- job tokens are short-lived, least-privilege capabilities;
- OIDC workload identities replace stored cloud credentials where possible;
- secret values are not available to the provenance signer;
- final check conclusions bind the exact commit, workflow digest, runner profile, logs, artifacts, and policy epoch;
- caches and artifacts are content-addressed and scoped to prevent cross-tenant poisoning.
Build provenance uses in-toto Statement v1 and the current approved SLSA provenance predicate. DSSE is the signing envelope. Hosted deployments can publish signatures or attestations to Sigstore/Rekor or a private compatible transparency service. The trusted control plane, not the tenant-controlled build step, generates the attestation fields required by policy.
The default model assumes malicious repository content, compromised user tokens, hostile pull requests, untrusted CI workloads, stale or Byzantine caches, accidental operator deletion, object-store retries and reordering, and an administrator who may need to prove what happened later.
Core rules include:
- Git SHA-1 and SHA-256 repositories are supported as protocol identities; internal storage uses algorithm-tagged digest sets rather than assuming one hash forever.
- Incoming objects remain quarantined until validation and transaction publication.
- Authorization and ruleset decisions are immutable inputs to the transaction and name the exact policy epoch.
- Ref and policy changes form a hash chain and can be committed to a Merkle mountain range with signed, externally witnessed checkpoints.
- Data is envelope-encrypted with tenant-scoped key domains; cross-tenant deduplication is disabled by default because it conflicts with privacy and key isolation.
- Search, SQL, and graph projections cannot grant authority or make a stale write appear committed.
- Protected output, secrets, and audit records have explicit retention and redaction contracts.
- Security events are evidence with provenance, not mutable log lines on one node.
Enterprise identity includes OIDC, SAML, SCIM, passkeys/WebAuthn, SSH keys and certificates, organization teams, service accounts, workload identity, and break-glass procedures. Every deployment publishes its supported security and compliance profile rather than inheriting a blanket claim from the source tree.
FrankenGit distinguishes five often-confused ideas:
- Semantic determinism: the same authoritative state and command produce the same state transition.
- Replay determinism: a captured execution can be reproduced under the deterministic lab runtime.
- Byte determinism: an artifact is byte-identical under a pinned toolchain and environment.
- Statistical calibration: a threshold or interval has a stated empirical or distribution-free coverage contract under explicit assumptions.
- Safety invariants: properties that must hold for every execution in the defined model.
The repository carries registries for invariants, claims, evidence, formats, compatibility, operation costs, and risks. Each claim is classified as an invariant, mechanized model result, bounded model result, differential-conformance result, statistical result, benchmark, SLO, compatibility statement, or target.
E-processes monitor rates that may be inspected continuously, such as materializer-divergence reports, scrub failures, runner-leak signals, or authorization-oracle disagreements. Conformal prediction calibrates uncertain operational quantities such as hydration latency, compaction benefit, anomaly thresholds, and resource envelopes. Both require declared exchangeability or null assumptions, calibration windows, fallback behavior, and policy epochs. Neither can authorize a push, waive a signature, or prove that acknowledged data is durable.
FrankenGit does not claim “GitHub compatible” as one boolean. The compatibility registry tracks concrete surfaces and levels:
- Git wire protocol v0/v1/v2 over SSH and HTTPS;
- SHA-1 and SHA-256 object formats;
- smart HTTP, partial clone, bundle URI, packfile URI, Git LFS, signed commits and tags;
- GitHub REST API versions and endpoint families;
- GitHub GraphQL schema subsets;
- webhook event payloads and delivery semantics;
- GitHub Actions syntax, expressions, actions, events, services, matrices, reusable workflows, and permissions;
- import fidelity for repositories, LFS, issues, pull requests, reviews, releases, checks, workflows, packages, and audit history;
- reverse export so users can leave.
Each row is unsupported, parse-only, import-only, compatible-subset, conformant, or extension, with tests and known deviations. Unsupported behavior fails explicitly.
Forgejo is an excellent lightweight self-hosted forge and should remain the default answer for people who mainly need a small, conventional GitHub alternative. GitLab provides a mature enterprise platform and Gitaly Cluster provides strong consistency and failover for local-storage repository replicas. GitHub operates at extraordinary scale. FrankenGit is justified only if it delivers a meaningfully different architecture and user model:
- no fixed durable repository replica count;
- object-store-authoritative publication with disposable NVMe views;
- atomic ref-plus-forge transitions;
- agent workspaces and context as native primitives;
- evidence-typed claims and deterministic failure replay;
- selective multi-donor fountain-coded bulk transfer;
- an open hosted-service core without artificial community-edition feature gaps.
If those properties do not survive benchmarking and adversarial verification, this project should contribute the useful pieces upstream rather than becoming another under-maintained forge.
COMPREHENSIVE_PLAN_FOR_FRANKENGIT.md master design and convergence gates
README.md target-state product contract
docs/ARCHITECTURE.md condensed system architecture
docs/FOUNDATION_AUDIT.md adopt/adapt/reject analysis of source projects
docs/THREAT_MODEL.md assets, actors, boundaries, abuse cases
docs/BRAND_AND_LICENSE.md trademark, clean-room, and licensing posture
docs/AGENT_NATIVE.md workspaces, context capsules, capabilities
docs/COMPATIBILITY.md compatibility and migration doctrine
docs/HOSTED_SERVICE.md service architecture and economics
docs/adrs/ binding architectural decisions
registries/ claims, invariants, formats, costs, risks
schemas/ draft normative JSON schemas
scripts/validate_plan.py cross-document and registry validation
Run the design checks with:
make validateThe implementation is organized by convergence gates, not by disposable architecture:
- G0 — Constitutional contract: brand and license clearance; threat model; authority hierarchy; registries; backend contract; and binding ADRs.
- G1 — Repository truth: one stock-Git repository can push, publish, lose every local bare repository, rebuild from the ledger, and clone without acknowledged loss.
- G2 — Elastic materialization: conditional object authority, zero-to-many materializers, cold hydration, verified PackEpochs, retention, and explicit cost crossover evidence.
- G3 — HA fault proof: publication under destructive faults, idempotent retry, sequencer fencing, backup/restore, and qualified root backends.
- G4 — Minimal complete forge: identity, policy, issues, pull requests, review, checks, merge queues, webhooks, and atomic merges.
- G5 — Agent-native slice: virtual workspaces, caveated capabilities, ContextCapsules, batch source operations, provenance, and measured improvement over clone/token baselines.
- G6 — Native CI: workflow IR, fenced runners, artifacts, final checks, and independently verifiable build provenance.
- G7 — Self-hosted beta: install, upgrade, migration, backup/restore, security evidence, and a documented resource envelope.
- G8 — Hosted private beta: tenant isolation, metering, regional recovery, abuse controls, operational support, and measured unit economics.
- G9 — 1.0: stable native contracts and explicitly evidenced Git/forge/workflow compatibility at declared levels.
The complete workstream graph and exit criteria are in the comprehensive plan.
- Do not rewrite what Git already does well. Earn each replacement through conformance and measured benefit.
- One authority per fact. Refs and repository events come from the ledger; projections do not vote.
- Acknowledge after the linearization point. Fast lies are not performance.
- Keep correctness deterministic. Adaptive systems select policies only inside a safe deterministic envelope.
- Use advanced mathematics where it buys a named property. No ornamental RaptorQ, conformal prediction, topology, or martingales.
- Make agent actions more constrained than human actions, not less. Agents get narrow capabilities and exact evidence.
- Publish limitations next to claims. Target-state prose never masquerades as shipped evidence.
- Optimize total operator cost. A slightly slower primitive that deletes a repair playbook can be the superior system.
- Keep exit possible. Stock Git, documented formats, export, and open protocols prevent hosted lock-in.
- The managed service earns money by operating the system exceptionally well. The open-source edition is not intentionally broken.
The code and documentation are licensed under Apache License 2.0. Contributions use the Developer Certificate of Origin rather than copyright assignment.
The project does not copy or derive code from the referenced Franken repositories. Those repositories use an MIT license modified by an OpenAI/Anthropic rider, which is not an OSI-conformant permissive license and is incompatible with this project's goal of unrestricted open-source participation. Their public architecture and cited standards are treated as research inputs; implementations must be independently produced from public specifications and this repository's own contracts unless the relevant copyright holder grants a separate written license.
“FrankenGit” remains a working codename. The final service must use a cleared mark, or receive written permission from Software Freedom Conservancy for the Git mark. Domain registration is not a substitute for trademark permission.
- Cursor, Git at any scale
- Git Project, protocol v2, receive-pack quarantine, bundle URI, packfile URI, reftable, commit graph, and multi-pack index
- IETF, RFC 6330: RaptorQ Forward Error Correction Scheme for Object Delivery
- SLSA, v1.2 provenance
- in-toto, Attestation Framework
- Sigstore, Rekor transparency model
- Jeffrey Emanuel, asupersync, FrankenSQLite, FrankenFS, FrankenSearch, franken_markdown, and FrankenGraphDB
- GitLab, Gitaly Cluster
- Forgejo, documentation
The goal is not to build another place to put Git repositories. It is to build the source-of-truth infrastructure that humans and autonomous software will trust to change civilization's code.