"Birth touches the world in stages. Every stage is remembered before the next one starts — so a crash leaves a save point, not a wreck."
Many External Effects, In Order
Birthing a repo isn't one action; it's a chain of real-world effects: prepare a scaffold, create a local Git repo, request a private remote, push the initial commit, publish, update the roster, update the network ledger, update the operation registry, verify. Each of those touches something outside the process — the filesystem, GitHub, ledger files. If any one fails halfway, you must not be left guessing which effects already happened. So Birth runs as a resumable state machine: an ordered set of states, each one persisted the moment it completes, before the next external effect begins.
Persist the Step, Then Take the Next
The discipline is simple and strict: persist every completed step before starting the next external effect. If the remote was created, that fact is durable before the push is attempted. So when the push fails, the run resumes from 'remote created' — it doesn't re-create the remote, doesn't re-init the repo, doesn't double anything. A failure leaves an explicit, resumable run parked at its last good state, and a retry continues from there rather than colliding with its own partial work. Birth is never called complete on partial state, and a normal retry never fights the leftovers of a previous attempt.
Stage, Publish Atomically, Then Verify
Two more safety moves bracket the chain. First, Birth builds the scaffold in a Firelink-owned staging location and only atomically publishes the new directory into place once local preparation fully succeeds — so a half-built shell never appears at the real path. Second, the final step doesn't trust its own bookkeeping: it rebuilds the new member through the FamilyRegistry and FamilyReconciler and confirms it composes correctly before reporting success. The birth isn't done because the steps ran; it's done because the composed, reconciled family actually contains the new member.