2026-09-25 08:43:32 +02:00
|
|
|
---
|
|
|
|
|
title: Local Commit Boundary
|
|
|
|
|
status: draft
|
|
|
|
|
maturity: hypothesis
|
|
|
|
|
families: [mutation, authority]
|
|
|
|
|
scales: [L2, L6]
|
|
|
|
|
admission: research-candidate-only
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Local Commit Boundary
|
|
|
|
|
|
|
|
|
|
Context: an offline editor must survive an ordinary process restart after it tells
|
|
|
|
|
the user an edit is saved. Problem: immediate visual feedback is faster than storage
|
|
|
|
|
completion. `perceived-responsiveness` competes with `recoverability`; atomic storage
|
|
|
|
|
adds `implementation-complexity`.
|
|
|
|
|
|
|
|
|
|
Proposed solution: distinguish visible input from acknowledged local commit. Persist
|
|
|
|
|
the document revision and its pending-sync intent in one recoverable transaction;
|
|
|
|
|
only then report saved locally. This is a proposed design contract, not a claim
|
|
|
|
|
about Joplin or Obsidian internals. A storage error leaves the edit visibly unsaved.
|
|
|
|
|
|
|
|
|
|
Result: restart can reconstruct acknowledged work and pending propagation under the
|
|
|
|
|
selected storage assumptions. Remote acceptance is still unknown. Power loss, disk
|
|
|
|
|
corruption, quota exhaustion and device loss need separate guarantees and recovery.
|
|
|
|
|
The alternative of saving only in memory cannot satisfy the stated restart requirement;
|
|
|
|
|
waiting for a server commit cannot satisfy offline editing.
|
|
|
|
|
|
|
|
|
|
Evidence: LocalFirstEvidenceExpansion E01/E04/E05 motivates local storage and separate
|
|
|
|
|
sync; it does not establish this transaction or its crash guarantees. Known uses of
|
|
|
|
|
this exact boundary: unknown. Recurrence: unknown. Hypothesis only.
|
|
|
|
|
|
|
|
|
|
Proposed connection: enables [Pending Synchronization](PendingSynchronization.md)
|
|
|
|
|
when the transaction records the pending revision. This is a research relation,
|
|
|
|
|
not an admitted canonical edge. Test: [VC-02](../walkthroughs/VC02-OfflineFieldNotes.md).
|
2026-09-26 21:22:53 +02:00
|
|
|
|
|
|
|
|
## Recovery evidence boundary — 2026-09-26
|
|
|
|
|
|
|
|
|
|
Name the storage transaction and acknowledgement assumptions, then test ordinary
|
|
|
|
|
restart, interrupted commit and any claimed power-loss/flush behavior separately.
|
|
|
|
|
An untested guarantee is unknown, not demonstrated impossible. Synchronization or
|
|
|
|
|
a second copy on the same device does not establish independent backup protection.
|
|
|
|
|
Define a separate backup retention/failure scope and test restoration to a clean
|
|
|
|
|
store, including pending operations and their reconciliation, before promising
|
|
|
|
|
recovery from device loss or replicated deletion. Respect access and retention
|
|
|
|
|
policy during backup and restore. See [shared guidance revision](../reviews/SharedGuidanceRevision.md).
|
