Durability and recovery
Understand preparation, synchronized journal writes, uncertain outcomes and safe recovery.
Status: Foundation. The local journal and prepared state modules have explicit failure contracts. The current whole-project build and complete application recovery workflow remain unfinished.
Acknowledge the right boundary
The intended durable owner follows three steps:
Prepare the candidate state and receipt, completing validation and allocation.
Append the exact intent at its expected sequence and synchronize the journal.
Publish the prepared roots without another allocation step.
The state module's commit only publishes memory. It cannot prove that step two happened. The journal's successful append proves its configured OS synchronization boundary, not application-wide correctness on its own.
Understand an unknown outcome
A write or synchronization error can occur after some or all bytes reached storage. The journal returns an unknown-outcome error, records the known previous boundary and refuses normal continuation.
Similarly, a process can stop after a durable commit but before the caller sees a success reply. Retrying the same scoped identity must return the original result instead of repeating the effect. Idempotency is part of recovery, not just a convenience for unreliable networks.
Preserve evidence when recovery is uncertain
The journal checks its header, sequence continuity and frame integrity on open. An incomplete suffix may be an interrupted append, external truncation or damage to a previously acknowledged frame. Its bytes alone do not identify which history occurred.
RURAL therefore does not silently skip, truncate or search past malformed reopened data. Recovery-required state preserves the bytes and reports the first problematic boundary.
A narrow same-handle repair exists for an append that this still-running owner knows never returned success. That proof does not survive process restart. It is not a general license to truncate an old journal.
Know the failure envelope
The current local-sync direction uses the operating system's file synchronization facility. The documented macOS implementation uses ordinary fsync, not F_FULLFSYNC. Fault-injection and reopen tests establish specific behavior; they are not universal physical power-cut certification.
One local copy cannot survive destruction of the only host or disk. Replication, off-host backups and disaster recovery require their own implementation and evidence.
The journal also has a configured total-size limit. Current replay loads a bounded log image into memory. Rotation, compaction and long-term retention are separate work, and capacity exhaustion must be explicit.
Read journal and framing for format boundaries and backup and portability for the complete-state requirement.