tegwick
642163a1ed
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2.4 KiB
| title | status | maturity | families | scales | admission | ||||
|---|---|---|---|---|---|---|---|---|---|
| Local Commit Boundary | draft | hypothesis |
|
|
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 when the transaction records the pending revision. This is a research relation, not an admitted canonical edge. Test: VC-02.
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.