"Losing resume/preferences is annoying but recoverable; it must never alter NAS, Recall, or Pippa state."
Two Tiers of State, Graded by What Loss Costs
Ashen Reel holds state in two very different tiers, and the whole recovery design comes from never confusing them. There's truth — the NAS bytes, Recall's transcripts, cwkPippa's conversations — where loss is catastrophic and irreversible. And there's convenience — resume positions, preferences, recent items — where loss is merely annoying. The local SQLite database holds only the second kind, and it's designed so that throwing all of it away costs nothing the archive would miss.
This grading isn't a detail; it's the safety property. Because local state is known to be disposable, its failure modes can be blunt and safe: when in doubt, reset. You could never reset Recall's transcripts. You can always reset a resume position. Knowing which tier you're in tells you how violent your recovery is allowed to be.
Corruption: Preserve, Then Reset — Never Patch
When the state DB is corrupt, Ashen Reel does not try to surgically repair it. It preserves the damaged database and diagnostics for forensics, then reinitializes fresh convenience state. It never pulls values from Recall or the NAS to 'fix' the local DB — those systems don't owe the player its state, and reaching into truth to repair convenience is exactly the boundary violation this whole track forbids.
The recovery path is short precisely because the state is disposable:
Migrations Move Forward, With a Net
Even disposable state deserves care when its shape changes. Schema migrations are forward-only and tested from every version the app has ever shipped, so a user upgrading from an old build lands cleanly. And before any destructive migration step, the old database is backed up — because 'disposable' means 'safe to lose in a crash,' not 'careless to lose during an upgrade.' The state is throwaway, but you still don't throw it away by accident.