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](https://www.inkandswitch.com/essay/local-first/), 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](https://joplinapp.org/help/dev/spec/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](https://joplinapp.org/help/dev/spec/sync/).
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](https://joplinapp.org/help/apps/conflict/).
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](https://obsidian.md/help/sync/troubleshoot).
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](https://obsidian.md/help/backup).
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](JoplinConflictScreen.json)). 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](ObsidianConflictScreen.json)). 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](../candidates/ConflictCopy.md)
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.