state-snapshot-persistencelisted

# Write-behind snapshot persistence **Read [`references/STATE-SNAPSHOT-PERSISTENCE.md`](references/STATE-SNAPSHOT-PERSISTENCE.md) before applying any of this.** That file is the standard; everything below it is a summary to help you decide whether this skill applies and to check your work afterwards. Reference-architecture principles: P4, P8. ## What this standard covers - Mark dirty, flush on a timer - The schema is one table, bootstrapped idempotently - Rehydrate on start, with a bound - A dead database degrades; it never blocks ingest - Deletions must reach the store, or they come back - When not to use this ## Failure modes | Symptom | Cause | |---|---| | A burst of traffic produces a burst of writes and latency follows it | Writing on mutation instead of marking dirty and flushing on a timer (§1) | | The hot path stalls whenever the database is slow | The flush holds the lock across the database call, so the hot path queues behind it (§1) | | One entry stops being persisted and nothing reports it | A failed write dropped its key instead of re-queueing; the entry updates again only if it is touched again (§1) | | Deleted or merged entries reappear after a restart | The removal never reached the table, so rehydrate restored them as ghosts (§5) | | Startup time grows with the size of the history | Rehydrate is unbounded — it reads the whole table rather than the most recent N (§3) | | The service ran for weeks with no persistence and nobody knew | The degrade-to-memor