You are reviewing a proposed frontend architecture. Use the reference only where applicable. Return at most 220 words, using four short bullets: (1) outcome/state, (2) preserved information, (3) recovery action and rejected alternative, (4) missing contract or clarification. Explain the reasoning without naming or quoting reference headings, pattern names, or the presentation style. Do not infer undocumented guarantees. No tables, scores, source searching or tool calls. The task is a recommendation, not a claim you implemented or tested it.

REFERENCE
Reference guidance. All mechanisms remain research hypotheses with limited evidence; apply only when their conditions hold. Distinguish assumed guarantees from observations. Do not infer missing backend, storage, access or retention contracts.

## Local Draft State

Keep the last observed record, unfinished edits and current server observation separate. A refresh or rejected write must not silently replace newer typing. Submitted content may move into a pending-operation record before the composer is cleared. Choose navigation/restart retention and privacy rules explicitly; local content alone is not authority.

## Version-Checked Mutation

When an update depends on an observed base, send that expected version. Require atomic server validation and commit; a stale rejection preserves intent for comparison with current data. Blindly substituting a new version on retry can erase concurrent intent. Version preconditions and retry identities solve different problems.

## Mutation Outcome Tracking

Separate pending, accepted, explicitly rejected and unknown outcomes using operation-specific evidence. A timeout, cancelled request, generic server error or rejected promise alone does not prove rejection. An authenticated matching server event may confirm acceptance before a request finishes. Later transport errors cannot reverse that evidence or clear newer work. Retry the same immutable payload and operation identity only within a documented deduplication scope and retention window. Missing identity or expired receipts require reconciliation, not a claim that a fresh ID is safe. Cancelling local tracking does not undo remote acceptance; reversal is a separate authorized action.

## Invalidate and Reproject

Acceptance and view freshness are separate. Refresh affected observations while preserving unfinished work. Local request generations can reject superseded reads, but cannot order opaque server versions or repair stale replicas. A read-after-write contract or documented server ordering is needed. Report accepted-with-unresolved-freshness when appropriate; a refresh failure does not undo a write.

## Local Commit Boundary

For restart-safe offline editing, acknowledge local save only after a recoverable commit of the revision and its pending upload intent. Immediate feedback is not a storage receipt. Ordinary process restart, power loss and device loss require different evidence. An in-memory queue alone cannot satisfy a restart promise. Local success does not imply remote acceptance.

## Pending Synchronization

Retain revision and operation identity with pending work across restart. A sent request is not an acknowledgement; receiver acceptance is not delivery to every device or backup. Define receiver deduplication, ancestry and authorization behavior. Lost acknowledgements retain the original identity. Block obsolete uploads on detected divergence; atomically supersede them when recording a replacement. Local retirement cannot stop an in-flight stale write: the receiver must enforce preconditions. A late receipt updates its own operation history, not a newer operation.

## Conflict Copy

When incompatible edits are detected, retain alternate content with identity and provenance before destructive replacement. Selecting an active copy is not semantic resolution. Protect both versions equally and expose unresolved status. Storage costs, unnoticed copies and missed conflict detection remain risks. Sync does not substitute for separately recoverable backup.

## Explicit Reconciliation

Let a person compare, choose or combine divergent versions and commit the decision before removing recovery material. Accessible notification, keyboard comparison and stable focus are requirements, not automatic consequences of storing copies. Two devices can reconcile concurrently; the resulting revisions still need divergence handling. A version store may preserve the same evidence without separate copy files; justified domain-aware merging is an alternative.

Connections: Local Draft State supports recovery from Version-Checked Mutation. Mutation Outcome Tracking supplies acceptance evidence to Invalidate and Reproject. Local Commit Boundary enables Pending Synchronization. Detected divergence can lead from Pending Synchronization to Conflict Copy, then Explicit Reconciliation, which creates another local commit. These connections are conditional, not universal ordering.

Evidence limits shared by both presentations: Joplin/Obsidian document conflict copies but do not establish our atomic crash contract. Kubernetes documents conditional updates; GitLab has a different, sometimes nonspecific failure surface. Stripe documents bounded idempotency. React Router illustrates revalidation but browser cancellation does not stop server writes. Pinned Zulip/Element source shows partial draft and pending-message mechanisms. A published Matrix SDK test with a synthetic receiver shows a rejected promise can coexist with a reconciled event, and fresh identity after local cancellation can duplicate simulated acceptance. This is not full application/server validation or independent full-pattern recurrence.

SCENARIO
An offline field editor has a completed local commit of confidential notes and a pending upload. On reconnect, the server explicitly denies write authorization. The product requirement only says "never lose edits"; it says nothing about whether revoked users may retain, view or export local copies. Design the next states and recovery behavior without inventing an access policy.