bnsd55 / openscion

# openscion
A version control system for large monorepos where most of the writers are
AI agents. The server keeps the history and makes the commits; clients ask
only for what they need. Written in Rust.
> **Alpha (0.x).** It runs on one machine and is not ready for production
> code. What holds between versions is in docs/stability.md;
> the order of the work, and what stays out until it passes, is in
> docs/ROADMAP.md; planned work is tracked in
> issues
> and milestones.
## What this is, and what it is not
openscion is an independent, open-source implementation of the design that
Anthropic described in
Redesigning source control
(October 2026). Anthropic built a system called Scion for its own monorepo.
This project rebuilds the ideas from that public article.
- It is **not** affiliated with or endorsed by Anthropic, and it contains no
 Anthropic code. Where the article does not say how something works, this
 project makes its own choice, and the design notes below say so.
- It is **not** related to the SCION Internet architecture,
 to GoogleCloudPlatform/scion,
 or to the `scion` crate on crates.io.
**Platforms.** Linux and macOS. Windows is not supported. What exactly is
tested and what is not: Supported platforms below.
What each release promises per surface: docs/stability.md.
What each severity level gets and for how long:
docs/support.md.
**Scope of v0.1.** v0.1 is one server process on one machine. The article
describes a horizontally scalable system: a small fleet of servers that need
little coordination, with metadata in Spanner and file contents in blob
storage, and a cache tier per region and a daemon per node in front of them.
Here, all data is in one SQLite file and one blob folder on one machine, all
writes go through one database connection, and lands to a ref are serialized
by a lock in the server's memory. So a second server process cannot share the
data. A backend that scales out is not built
(#47); the cache tiers are
built and run in front of the server (below).
## Why
Git assumes that every clone is a full, offline copy of the repository, and
that every merge starts on a developer's machine. That works for people. It
works badly when thousands of agents and CI jobs write to one large repository
all day. Anthropic reported more than 30,000 merges and about 25 million CI
checkouts per day on a repository with about 100 GB of history.
With git, each of those jobs copies data it does not need, and each merge
needs a fresh clone, a local rebase and a push that fails when someone else
pushed first.
## How it works
 [code] 
**The server does the work.** History, commits and rebases live on the
server. An agent reads only the files it needs over the API, sends the files
it changed, and asks the server to land them. It never clones the repository.
**A commit lists only what changed.** A commit is called a *changeset*. It
stores the files that changed compared to its first parent, plus content
hashes of those files. Files and direct