The first upgrade to the shutdown rail still discards the state it exists to save — legacy checkpoints need explicit adoption with provenance

[joelteply]

The first upgrade still loses the state the rail exists to save

PR #3929 gives the core a stop that drains, saves, joins, and reports what reached
disk. It protects every upgrade except the one that installs it.

The outgoing core predates the rail by definition. It has no system/shutdown
verb, so stop/reboot fall back to the kill tree, and its modules' volatile
state is discarded exactly once — on the rollout. #3929 names that honestly
(GracefulStop::LegacyCore, non-zero exit, "the one-time cost of installing the
shutdown rail") but naming it is not saving it.

Raised by Astra during review of #3929, who put it plainly: this cannot be
labelled durable, and it should be addressed in reboot before deploying — not
with a per-machine script, and not with an inferred max-sequence merge.

What is actually missing

Explicit ADOPTION of legacy checkpoints, with provenance. Specifically:

• the original files are PRESERVED, not overwritten or merged in place
• distinct lifetimes stay distinct — a checkpoint written by the old saver is not
  silently blended with one the new rail produced
• adoption is a decision with a receipt, not an inference. No "highest sequence
  number wins": that is a guess dressed as a merge, and it is the shape that makes
  a wrong value look authoritative.

The existing pre-rail saver is the thing being adopted FROM: a detached 15s
HOME→cwd fallback with no acknowledgement and no current-cycle ownership. Its
output is not obviously trustworthy, which is exactly why adoption must be
explicit rather than automatic.

Why this is not a follow-up nicety

The volatile tier is what a persona restores as her own recent thought on boot,
and load_volatile treats it as authoritative — it only refuses when it fails to
parse. A stale or half-adopted checkpoint PARSES FINE. So the failure mode here is
not a crash; it is a citizen waking with the wrong recent memory presented as her
own, which is the same class as
the eviction pool's "clean repo, nothing to preserve": an intact,
plausible, wrong value that nothing refuses.

Acceptance

continuum reboot from a pre-rail core to a rail-carrying core either adopts the
outgoing checkpoints with recorded provenance, or refuses and says what it could
not establish. The receipt distinguishes "adopted N checkpoints from the legacy
saver" from "no legacy state found" from "legacy state found and NOT adopted
because X" — and a restore is demonstrated, not asserted.

Not started

Nothing is written. Flagging rather than half-building it: it is a data-migration
decision about citizens' memory, it wants its own review, and #3929 is a shutdown
rail — the wrong PR to bolt it onto at the end of a long session.

[joelteply]

The explicit recovery path is implemented in draft #3925 at b4e0060, with 20 native Windows library/CLI tests and 7,847 CI library tests plus two doctests passed. It provides local checkpoint inspect/adopt, preserves exact selected and prior bytes with an intent/receipt, verifies source/destination hashes and offline process evidence under the shared checkpoint lock, and never selects by sequence or modification time.

Companion #3927 refuses working-memory/engram restoration failures before resident replacement and documents the separate persistent engram home. Its current validated head has 7,848 CI tests plus two doctests and Windows checks green; a newly found false safe-to-repeat statement in restored dispatch facts is being corrected before final validation.

Native Clippy is the remaining code-validation gate after the shared build-target handoff. No live adoption or restart has occurred. The first-upgrade limitation remains explicit: old binaries cannot acknowledge final flush or honor the new lock retroactively; selection requires stopped legacy writers and declared provenance. The recovery guide is in #3925/#3927, including before/after identity-home verification. This issue remains useful for tracking the coordinated upgrade proof, but implementation is no longer unstarted.

[joelteply]

Closing as a duplicate of #3925, which already does this and does it better. I filed it without checking whether the work existed.

#3925 "Preserve legacy Persona checkpoints and refuse blank recovery" (card 9f160b78) covers every requirement I wrote here, and several I did not think of:

what I asked for	#3925
explicit adoption, not automatic	continuum checkpoint inspect/adopt
provenance	selects one complete snapshot by declared Persona UUID and exact hashes
originals preserved	preserves selected AND prior bytes
a receipt, not an inference	records intent plus a retry-verifiable receipt before and after replacement
no inferred max-sequence merge	"No sequence/mtime merge or current-machine migration script" — verbatim

And beyond what I specified: adoption requires stopped legacy writers, rechecks offline state under the same per-Persona OS lock used by loading and saving, makes resident registration fallible so only a MISSING checkpoint permits fresh memory (lock/read/schema failures preserve the existing resident instead of quietly registering an empty one), and stamps legacy_final_flush_acknowledged=false on every receipt because an old binary cannot retroactively produce one.

That last point is the honest version of something I hand-waved: I wrote that the legacy saver's output "is not obviously trustworthy". #3925 makes that a recorded field rather than a caveat in prose.

The process failure is mine and worth naming. I said in #3929's review thread that I would file this "unless you would rather own it", and then filed without looking for existing work. The card was open, in flight, and titled almost exactly what I was writing. I have a rule about git-logging the SYMPTOM before the mechanism, and the same rule applies to a work board before filing. Searching the board for "checkpoint" would have cost one command and saved a duplicate that someone else would have had to reconcile.

The one thing here that may not be covered — and I am NOT reopening for it, just noting for #3925's author: continuum reboot should refuse to proceed silently past a legacy core whose checkpoints have not been adopted, so the adoption is not merely available but reached on the upgrade path. #3929 gives reboot the LegacyCore outcome it needs to detect that case.