Checkout is too large a hammer
Checking a live vault out to an old commit to recover one sentence erases every legitimate change since that point. In a vault written by several devices, a historical snapshot may always be unaware of part of the present.
Even checking out one file can overwrite meaning without comparing current and historical states. The easier a restore button looks, the more users imagine time reversal while the operation actually deletes somebody else's present.
Read the past only as evidence
A safe restore reads a historical blob, displays its diff against current truth, and applies approved content as a new write. That write passes the same permission, stale guard, atomic replacement, and semantic ledger as any edit.
The old words may return, but history moves forward. A new commit records who restored what from which point, and the restoration can itself be corrected. Recovery never disappears from the audit trail.
Partial restoration is the default
A memory note can contain a newly added valid paragraph beside one badly changed sentence. Whole-blob restore forces the user to sacrifice one. At minimum, the interface needs current, historical, and proposed views.
Text may merge without syntactic conflict while carrying the wrong meaning. A tool can propose a patch, but a live session remains responsible for deciding whether the memory is true.
Rehearse without touching the real source
Recovery code is rarely used and therefore often the most dangerous path. Build temporary source and history, then test blob selection, stale detection, forward commit, and audit provenance end to end.
In operation, preview the exact target and result and show the new head after application. A success toast alone proves neither which bytes returned nor which record captured the event.