security-state-recoverylisted

# Security State Recovery Turn the target's recovery contract into observable state-transition tests. Use repository contracts and supported failure models; do not invent stronger durability or rollback guarantees. ## Establish The Contract Identify the operation's owner, authorization scope, persisted state, external effects and commit point. Separate what the caller was told from what actually committed. An error or timeout can leave an indeterminate operation. Record the target revision, platform, storage implementation, allowed fixtures, fault budget and intended evidence location. Existing authorization covers local reversible tests in scope; it does not authorize killing unrelated processes or faulting live storage. Use isolated fixture stores and owned child processes. Write allowed pre-state and post-state combinations before injecting faults. For example, when a contract requires persist-before-acknowledge, an acknowledgement without the corresponding durable receive state is forbidden. Some outbox contracts allow duplicate delivery and require receiver deduplication; do not demand globally exactly-once side effects from a local transaction. ## Exercise Transitions 1. Trace validation, reservation, mutation, durable commit, publication and acknowledgement. Mark where authority is consumed and which component owns it. 2. Inject faults before and after meaningful boundaries, including a committed operation whose response is lost. Prefer deterministic fault