tegwick
cfa249ab13
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
1.7 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.