--- name: parked-mainrevert-cloudsave-compat description: "TOMBSTONE — planned compatibility check for a rollback of main that never happened and can no longer happen. Kept for the save-rollback invariant it established." metadata: node_type: project originSessionId: parked-mainrevert-cloudsave-compat --- # TOMBSTONE — CLOSED, the revert never happened Owner planned (2026-06-29) to roll `main` back to an earlier baseline, and worried that cloud saves written by the newer build would be dropped, corrupted, or refused as "from a future version" by the older code. A read-only investigation concluded **the saves were safe and no save surgery was needed** — the feared new fields did not actually exist, so there was nothing for the older code to fail to understand. The rollback was never executed and is no longer possible. **Nothing here is pending.** *Correction 2026-07-20: removed version numbers, tag and commit refs, the diff findings, and the file-level load-path description — all derivable from git and the source.* ## The durable invariant worth keeping **In any version rollback, the danger is not the LOAD — it is the SAVE-BACK.** Loading is forgiving: unknown extra fields survive a merge into older defaults. The permanent loss happens on the next write, when older code re-serializes only the fields it knows about and silently strips the rest. So the check to run before any rollback is *"what does the old code drop when it saves?"*, never *"can the old code open this?"* **Corollary, always step zero: export backups before rolling back.** A code rollback doesn't touch stored saves, so an export is a free, zero-risk safety net — take it every time regardless of how confident the compatibility analysis is.