The Cutover

"A replacement isn't a merge. It's an identity operation, run in order, with a way back."

One Morning, in Order

On 2026-09-13 the replica stopped being a rehearsal. The cutover ran as a single ordered operation, and the order is the lesson: verified backups first (git bundles of both histories, data and support archives, the installed 3.1.0 bundles), then repository continuation — the Swift tree merged into the existing Rekindle repository with a merge commit whose first parent is the Tauri head, so both histories stay in the room — then identity unification, then the one-time data conversion on each Mac from a hash-checked backup with the originals archived, then install, then the Firelink version write, then family reconciliation and fleet deployment. Every step is reversible until the one that isn't, and by then the return path is already recorded: the archived 3.1.0 bundle plus the archived data roots.

Identity Is a List of Addresses

The part nobody enjoys is the part that can't be skipped. An app's identity isn't its name — it's every address the machine knows it by. The cutover table had to flip all of them: the bundle id (com.cwk.rekindle), the installed app path, the data root (~/cwk-dbs/rekindle-db/), the support and cache directories, the Keychain service namespace, the URL scheme, and — the one the family actually talks through — the Pippa host kind and brain-control app id, both becoming rekindle. The temporary Kindling identity left every active runtime. Historical documents keep the name they were written under; a rewrite of history is a different operation and nobody ordered one.

Why the Version Jumped 3.1.0 to 4.0.0

The version stayed pinned at 0.0.0 through the entire replica program — the product hadn't earned a number yet — and then jumped straight past where a minor would land. That's the family's versioning contract doing its job: a change of implementation with a one-time data conversion is a MAJOR change, and the human-facing version is written by the release owner (Firelink), not inferred from a tag. Build numbers, git commits, and schema revisions all advance on their own rails; the product version answers a different question — what did the user just agree to run? On 2026-09-13 the answer was: the same product, a new engine, and your data came with you.

Code

The cutover order — each step reversible until the next one lands·text

1. verified backups      git bundles (both histories), data archives,
                         the installed 3.1.0 app bundles
2. repository continuation  merge commit, first parent = Tauri head
                         -> both histories stay
3. identity unification   bundle id, data root, support dirs, Keychain
                         namespace, URL scheme, Pippa host kind
4. one-time conversion    per Mac, from a hash-checked backup,
                         originals archived
5. install + version      Firelink writes 4.0.0, family reconciled

# The return path is archived BEFORE it is needed, not assembled after.

Exercise

Pick an app on your machine and list every address the OS knows it by: bundle id, Application Support path, caches, keychain entries, URL schemes, login items. (Hunt: ~/Library is most of the answer.) Now imagine replacing that app with a rewrite. Which of those addresses would you keep, which would you retire, and what's your return path if the new one misbehaves on day one?

Hint

The list is longer than you think — that's the lesson. If your plan for the old version is 'it's still in the Trash,' you don't have a return path, you have a hope.