A snapshot is a restore plan

A snapshot that captures how things look proves nothing you can act on. Retasked to capture state — git-restore images, file contracts, the fleet manifest — it becomes the thing that rebuilds the machine. And the audit that produces it becomes an engine for removing dependencies.

The weakness

The fleet already took daily snapshots — of pages. Screenshots and captures that proved a surface looked right on a given day. Useful for spotting visual regressions, useless for the one question that actually matters about a single Mac running everything: if this machine dies tonight, can a new one be brought up tomorrow?

A page snapshot answers "did it render." It cannot answer "where does this code live, is it pushed anywhere, what scheduled jobs exist, which secrets must be re-seeded, what folders must exist." All the state that actually constitutes the machine was held only in the machine's own head.

The reframe

A snapshot is not a record of the past. It is a restore plan for the future — and you should judge it by exactly one test: could someone act on it to rebuild the system? That flips what it must capture. Not pixels — state: a git-restore image of every repository, the filesystem contract, the inventory of scheduled jobs, and the checklist of secrets to re-inject. An actionable runbook, plus an ongoing drift-guard that fails loud when reality and the plan diverge.

The question a snapshot must answer isn't "what did this look like?" It's "what would it take to make this exist again, on a machine that has never seen it?"

The proof it was capturing the wrong thing

The retasked snapshot earned its keep on the first run, by surfacing a restore-killer no page capture could ever see.

Nearly a quarter of the codebase was one disk failure from non-existence — and the daily page snapshots had been cheerfully green throughout. That is the difference between a snapshot of appearance and a snapshot of state: only one of them tells you the truth about whether you could come back.

The engine: every snapshot is a list of dependencies to remove

Here's the antifragile turn. A restore-readiness snapshot doesn't just record fragility — it itemises it. Each thing it flags as "can't be reproduced" is a coupling to the physical machine, and each one becomes a target:

• Code that lives only here → push it to an origin. The repository no longer depends on this disk. (Thirteen of them, in the first pass.)
• Scheduled jobs that live only here → lift the machine-local job definitions into a version-controlled manifest with an installer, so a fresh machine reinstalls the whole fleet from source.
• A folder layout that lives only here → make it a contract a setup script provisions (see field note № 5). The paths stop being an accident.
• Secrets that live only here → reference them, don't store them; capture a re-seed checklist instead of the values.
• Data that lives only here → tag it: regenerable (carry the recapture method) or genuinely durable (route it into tracked git). Most state, examined honestly, can be re-fetched — as long as the snapshot records how.

Run that loop and the machine gets steadily more disposable. Not more backed-up — more reproducible. The goal isn't a bigger copy of the Mac; it's a Mac you could throw away on a Tuesday and reconstitute by Wednesday, because nothing important is uniquely bound to it any more.

The principle, generalised

One audit on one machine, but the moves aren't about Macs:

• Snapshot state, not appearance. If a snapshot can't rebuild the thing, it's documentation, not a restore plan. Judge every snapshot by whether someone could act on it.
• The best snapshot is one that makes itself smaller. A restore-readiness check that surfaces dependencies you then remove means each run has less to capture — the system converges toward reproducible-from-source.
• "Lives only here" is the thing to hunt. Every asset bound uniquely to one machine — code, jobs, paths, secrets, data — is a single point of failure wearing a different hat. Name them, then remove the binding.
• Restorable must never mean exposed. Making state reproducible can't smuggle credentials into the open; gate it. Reference secrets, don't replicate them.
• Measure readiness by rebuild time, and shrink it on purpose. "How fast could I stand up a new instance?" is the real health metric. Every dependency you remove moves the number down.