# Replicate Anthropic's approach (from the post only)

From the Ask It Something Hard explainer. Not produced or endorsed by Anthropic.
Source: https://www.anthropic.com/engineering/redesigning-source-control

Audit this repo, its CI and its agent setup against that post, your only source: back each recommendation with a verbatim quote; recommend nothing it does not describe. If you cannot read its full text (no web access, or a summarized fetch), ask me to paste it. Never quote from memory.

## Know the limits

- Scion is unreleased and "by no means a suitable replacement for git for general use"; it suits "truly enormous monorepos".
- "Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend." Weigh cost before proposing anything agent-heavy.
- "we don't expect our solution, or our considerations, to suit every case", though these problems may become "more commonplace over the next six to 12 months".
- Its git-side ideas (server-side RPCs) are for forges: list them as asks for your host.
- The post gives no git commands. Label every command you use "implementation choice, not from the post".

## Rules

- Before approval, only commit the report to a new local branch.
- Do not push, open a PR or trigger CI unless asked. Never force-push, rewrite history, delete refs or objects, or run gc or prune.
- Ask before touching anything shared: CI, runners, mirrors, caches, forge settings, branch protection, git config, hooks.
- Measure from existing logs; run no new clones. Mark gaps "unknown". Keep credentials and private URLs out of the report.

## Steps

1. **Scale.** After `git fetch`, count merges per day (`git rev-list --count --first-parent --since="30 days ago" origin/<default-branch>` over 30; unreliable if shallow), repo size (`git count-objects -vH`), and CI and agent checkouts per day. The post: "over 30,000" merges a day, history "almost 100 GB", "25 million code checkouts per day for CI". For most repos git "is the right design"; "not needed at this scale" is a good verdict.
2. **"Clients are always online."** List jobs fetching full history and which truly need it.
3. **Ask instead of cloning.** "in many cases jobs don't need a local repository at all." Find jobs cloning only to learn "who last changed a line or how two commits are related"; note what your host's API answers.
4. **Git's slice tools, the stopgap the post outgrew.** Shallow clones, sparse checkouts, promisor remotes, mirrors and seeds "bought us time", but seeds "fell further from the tip of main" and diff and blame on partial clones took "more and more care". Carry that caveat.
5. **Caches.** Git mirrors or object caches only. Its mirrors "no longer scaled"; it tiers caches "to isolate failure domains". Report only.
6. **Refs.** "The development lifecycle in Scion discourages refs", a concern of Scion's distributed server. Count `git ls-remote --heads --tags origin | wc -l`; report stale branches only.
7. **Merge queue.** "We haven't been able to effectively replicate the industry standard of a global repository lock on the merge queue", so it "invested in post-merge and pre-deploy automated testing", because "Claude can typically fix these conflicts faster than humans can even identify them". It still runs a merge queue. Never propose removing required checks, branch protection or the queue.
8. **Telling agents "no".** In CLAUDE.md, AGENTS.md, .cursor/rules and git or CI scripts, look for finding when a change merged "by linearly reading the commit log instead of asking" the review tool, and over-engineering "in response to hypothetical concerns".
9. **Review intent.** "Our team members still review every change request for the system, but they now examine the intent of the change". Never propose reducing human review. Check CODEOWNERS and review rules.
10. **Superfans and defences.** Claudes watching "telemetry and logs", plus "fuzzing": say where they would help and at what cost; set none up.

## Deliverable

1. `SOURCE-CONTROL-AUDIT.md`, about a page: step 1 numbers, then a numbered table of step / quote / verdict (applies, done, not needed) / proposed change / risk. Weakening a safeguard is high risk.
2. Stop. I reply with the row numbers to apply. If you cannot ask me, stop here.
3. Make only approved low-risk changes (scripts, docs, agent instructions), one commit each citing its principle; list shared changes awaiting approval. Nothing merges until I review.