Reduce research calls with screened reuse and draft VC-02 walkthrough

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9

research/candidates/PendingSynchronization.md

@@ -0,0 +1,34 @@
+---
+title: Pending Synchronization
+status: draft
+maturity: hypothesis
+families: [synchronization]
+scales: [L2, L6]
+admission: research-candidate-only
+---
+
+# Pending Synchronization
+
+Context: edits persist while connectivity is absent or intermittent. Problem: local
+success does not establish a remote receipt. `offline-usability` competes with
+`freshness`; retries add `reconciliation-complexity`.
+
+Proposed solution: retain stable revision/operation identity and pending work across
+restart, retry on reconnection, and distinguish queued, sent and acknowledged states.
+A sent request alone never means synchronized. Define deduplication and the acknowledgement
+scope at the receiver before retrying. Do not infer that every other device has seen it.
+
+Result: progress can resume after interruption without relying on volatile UI state.
+A lost response leaves the same operation pending; an idempotent retry or lookup must
+resolve uncertainty. Infinite retries, expired authorization and sync-disabled items
+need explicit observable states rather than a permanent spinner.
+
+Evidence: [expansion review](../reviews/LocalFirstEvidenceExpansion.md) E05/E06 documents
+Joplin's distinct sync process and per-item progress metadata. The precise retry protocol
+here is a hypothesis, not a verified implementation description. Known uses of the full
+contract and recurrence: unknown. Alternative: server-required writes, which sacrifice
+offline operation; untracked best-effort upload, which lacks restart recovery.
+
+Proposed connections: [Local Commit Boundary](LocalCommitBoundary.md) provides a
+persistent origin; detected divergence may create context for [Conflict Copy](ConflictCopy.md).
+Neither relation implies every sync needs a conflict copy. See the VC-02 walkthrough.