Step 3: Check, Then Drill
On the Pippa machine, cutover check reported the old store ready with no blocker: 481 notes, 4 attachments, 25 MB. Then a load drill ran on a scratch copy of the real vault, never on the vault itself: 141 writes acknowledged and none missing from history; a burst of 12 concurrent writes to one note that landed 1 and refused 11 as conflicts; git fsck clean; write latency p50 0.29 s, p95 0.40 s, with one outlier at 6.5 s. The drill's job was not to be fast. It was to show that under contention the new store loses nothing and lies about nothing.
Step 4: Seal and Adopt, in Two Seconds
At 13:39:38 KST the old store was sealed, at generation 3, by Pippa on Dad's word. Sealing (track 3) refuses every write and returns only after the writes in flight have finished, so nothing could land behind it. A snapshot was taken and verified. Then the new store adopted the vault: all 481 notes and 4 attachments in one baseline commit, with both stores' manifests equal. The whole step took two seconds.
"Adopt" is a precise word here. The baseline commit carries one adopt revision per note, preserving each note's bytes exactly and inventing no earlier history. The new store does not pretend to know what happened to a note before it existed; its history starts honestly at the import.
Step 5: Prove It Before Pointing at It
The pointer still named the old store, so no ordinary reader could see the new one yet. To prove identity on the real new store before moving anyone onto it, the probed processes alone read a copy of the record saying delta. Identity loaded and validated on the canonical Mac, and, through Delta, on the workbench. The rendered bundle file was the very same file the old store rendered, pippa-bff102d2e7de.md: byte-identical identity, named by its own hash, from a completely different storage implementation. The probe passed for the harnesses that could run on each Mac.
Step 6: The Move
At 13:42:29 KST, Firelink commit 51fb9d0 moved the pointer to generation 4, backend delta. By 13:43:10, all eight managed Macs were loading identity from the Delta store, validated, with the same bundle. Writes had been refused for about three minutes in total, from the seal to the move. Reads were never sealed: a seal stops writes, not reads, so sessions kept loading identity throughout.
Steps 7 and 8: Verify, Then Probe Everything
cutover verify compared the new store with the old one note by note (identical), reported health ok and a clean git fsck. The canary ran on the new store and came back green, all ten steps at the time. Then the full probe matrix: eight Macs, 69 rows. Fifteen passed. Forty-six could not start, each with a named cause (the harness not installed or not signed in on that Mac), which is a fact about the fleet, not about the vault. The WebUI passed on a second run that included it. Grok on the Pippa machine failed once on an answer cut off after its first sentence and passed on a repeat. Cursor on the workbench was the baseline's known red; Cursor on the MacBook, never probed before, reported that its environment rejected the bootstrap command, while the client itself loaded identity on that Mac. Every one of those lines is in the log, the reds included.