frontend-patterns/research/reviews/LocalFirstEvidenceExpansion.md

Local-first evidence expansion

Date: 2026-09-25. Reviewer: codex, editorial self-review. Owner: FEP-WP-0002-T02. Documentation evidence, not an implementation audit.

Question before collection

Can local persistence, synchronization, conflict resolution and disaster recovery be treated as separate responsibilities? Hypothesis: acknowledging a local write cannot by itself establish remote convergence or preservation against device loss. A documented implementation coupling all four guarantees to one acknowledgement would challenge that decomposition. Assume personal notes rather than globally exclusive reservations. Do not assume the two applications share implementation code.

Located evidence

All new pages are living official documentation accessed 2026-09-25. Publication and exact release revisions are unknown; findings describe these editions only. Source IDs identify pages; claim IDs below are local to this review.

SRC-0002 — Local-first software (2019)

Original essay, authors already recorded in SourceCatalog. Expanded reading: ideals 1, 3, 5 and 7.

• E01: Ideal 1 separates local disk operations from background device synchronization.
• E02: Ideal 3 permits offline work, with synchronization after reconnection.
• E03: Ideal 7 assigns users responsibility for protecting and backing up their data.
• Limit: these are architectural ideals, not guarantees about every implementation; the essay's document/personal-data scope excludes several centralized services.

SRC-0003 — Joplin architecture

Official architecture, Joplin project / Laurent Cozic. Locator: User applications, Back end → Database bullet.

• E04: The clients store notes and other application data in a local SQLite database.
• Limit: the page does not specify the write acknowledgement, flush policy, crash boundary or storage-failure behavior. SQLite's name alone proves none of those.

SRC-0004 — Joplin synchronisation

Official synchronization specification. Locators: introductory paragraph; General process; Code architecture, sync_items.

• E05: Local storage precedes a synchronization process exchanging device changes; deletions also propagate.
• E06: Uploads follow edits; downloads are polled separately. Per-item synchronization metadata records progress and may disable synchronization for certain items.
• Limit: synchronization scheduling does not establish an atomic all-device commit or bounded completion under disconnection.

SRC-0005 — Joplin, What is a conflict?

Official conflict guide. Locators: How to resolve a conflict?, first paragraph; How to avoid conflicts?.

• E07: For a detected note conflict, Joplin preserves the local version in a separate notebook, puts the remote version in the active note, and supports manual recovery of differences. Disconnected editing can precede such conflicts.
• Limit: preservation described here is not proof that every concurrency failure is detected or that all attachments follow identical recovery mechanics.

SRC-0006 — Obsidian, Troubleshoot Obsidian Sync

Official troubleshooting. Locators: Conflict resolution options; Conflict file naming pattern; Sync deleted a note I just created on two devices.

• E08: An optional conflict-copy setting preserves the detecting device's edits in another file while the original retains remote content. Configuration is per device.
• E09: Automatic merging is another option; the guide notes possible duplicated text or formatting problems. Other file types use a different resolution policy.
• E10: A documented near-simultaneous creation case may retain remote content without merging; the guide points to file recovery for the local version.
• Limit: scope to the documented option and file behavior. Do not generalize conflict copies as the default or as a guarantee against every loss scenario.

SRC-0007 — Obsidian, Back up your Obsidian files

Official backup guide. Locators: introductory paragraphs; Syncing is not a backup.

• E11: Notes are locally stored. Local storage remains susceptible to loss/corruption; the guide distinguishes synchronization from a separately recoverable backup copy.
• E12: A chosen backup device is an operational convention, not global device authority assigned by synchronization.
• Limit: no tested recovery-point objective, restoration exercise or power-loss guarantee is established by this review.

Synthesis (our inference)

Two independently published application guides document the same narrow mechanism: preserve divergent local content separately while selecting a working version, then leave semantic reconciliation to a person. This supports a candidate Conflict Copy, not a universal rule that local data always wins or that manual merge is mandatory. The shared mechanism has two located documented uses; broader recurrence, implementation independence at code level and operational effectiveness remain untested.

Local Authority should mean a scoped role in accepting local work, not supremacy of one device in all later merges. Persistence, propagation, conflict resolution and backup require distinct evidence and observable states. These distinctions are ready for a synthetic restart/reconnect walkthrough once the seed drafts are prepared.

Scope and access limits

No application was installed, modified or fault-tested. No code revision was audited. Two guessed Obsidian detail URLs (file-recovery, how-obsidian-stores-data) were not accessible through browsing; their contents are not used as evidence. The accessible backup and troubleshooting pages support the limited claims above. Multiple Joplin pages count as one implementation, not multiple known uses.

Assisted investigations and editorial disposition

Two source-isolated runs used llm-connect, custodian-triage-balanced resolving to Gemini 2.5 Flash, at most four requests each and 3,000 completion tokens per response. Both completed four stages with stop finish reasons; no retries by the client. Packets contain short original quotations with editorial boundaries. Broader manual claims above were not supplied to the source-isolated model runs.

• Joplin: structural screen passed (receipt). Retain P01 for editorial synthesis, but reject inferred guarantees of uninterrupted sync or prevention of all data loss. Its family/scale prose is not a canonical schema record.
• Obsidian: structural screen blocked (receipt). Reject P01→C01/C02 requires edges: claim IDs are evidence, not candidate endpoints. The assisted critique wrongly endorsed them. Also reject its unconditional no-loss language. Its empty known-use ledger misses the named implementation; editorial evidence E08 supplies a documented use without altering the generated ledger.
• Both assisted critiques overstate direct applicability to transactional administration. A preserved copy cannot establish global transaction validity. The Joplin critique also infers server authority from remote-version selection; these are distinct.

Merged the overlapping concepts into Conflict Copy as a research draft. No FEP IDs, canonical patterns or graph edges were admitted. This editorial draft keeps the mechanism, explicit competing forces and documented uses while removing unsupported guarantees and separating proposal from observation.

T02 remains in progress: exact durability boundaries, independently exercised uses, accessibility and security behavior still need evidence. T03's draft corpus and formal walkthroughs remain pending; the candidate includes a concrete next scenario.

joplin-conflicts-01: 8134 reported total tokens.

obsidian-conflicts-01: 7961 reported total tokens.