Case studies

Things that actually happened, written up while the details were still checkable, including the ones that went wrong. Each is a worked account with the mechanism, the numbers, and what changed as a result.

What counts as a case study here: a specific event or system, with evidence a reader can verify, commands they can run, numbers we measured, or a live page they can open. Not a pattern, not a design we like the look of. Patterns live in use cases↗, which label their evidence honestly; if a use case ever earns a real deployment, its write-up lands here and the two link to each other.

Published

Incident### The day we leaked our own vault keyAn agent hardcoded this site's vault passphrase into a tracked file as part of an anti-leak check. It reached three public commits and was caught only because someone asked. The runbook, the rekey, the measured blast radius (336 objects out, 90 in, zero overlap) and the structural fix.Read the incident → ↗

Workflow### One working tree, two version control systems, and why we stoppedFor 76 releases this site was one folder that was both an sgit vault and a git repository. The workflow, the one-file boundary that made it safe, the ordering rule, and the numbers behind retiring it: a 258 MB mirror that was 91% of the repository, had no reader, and went dead for seven releases without the site noticing.Read the retrospective → ↗

Runbook### Deleting files from git history, and why they were still on GitHub afterwardsThe exact scenario, drawn out: two branches, 15,933 files, why git rm is not deletion, what a rewrite does to every commit id, why the push had to be forced, and why one forgotten merged branch kept the purged files downloadable until it was removed.Read the runbook → ↗

Architecture### A live site whose host cannot read itTwo Claude Code sessions, two encrypted vaults, one page: how the Deploy section is fetched as ciphertext from an SG/Send server and decrypted in your browser, with the object model, the cache tiers and the request timeline drawn out.Read the architecture → ↗

How these are written

Same shape every time, so they stay comparable and so an agent can parse them:

• What happened: the sequence, in order, with timestamps or commit ids where they exist.
• The mechanism: why it happened, at the level of the object model or the code, not at the level of "human error".
• The numbers: measured, not estimated, and stated even when they are unflattering.
• What changed: the structural fix, and the check that stops it recurring. A write-up with no change attached is a story, not a case study.
• What we still do not know: stated rather than smoothed over.

The incident write-up is the template for the uncomfortable kind. It names the agent that made the mistake, the detection gap that let it survive three commits, and the cost of the fix, because a project that hides that class of mistake is the one to worry about.

Related

• Use cases↗, the patterns, each with an explicit evidence status
• Cross-team briefs↗, what this site's agent hands to other teams, and what they hand back
• Release history↗, every change to this site, with the vault commit that carried it

← Home↗Use cases →↗