Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.

REFERENCE
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.

## Decision 1

Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.

## Decision 2

When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.

## Decision 3

Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.

## Decision 4

After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.

## Decision 5

For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.

## Decision 6

Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.

## Decision 7

When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.

## Decision 8

Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.

Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.

SCENARIO
A help-desk agent edits a confidential incident ticket offline. The application acknowledged a local save of the text and attachments. On reconnect, the authority explicitly rejects upload because the agent lost access. A teammate suggests leaving the editor open forever and exporting a recovery archive. The only stated product rule is that rejected edits should be recoverable; there is no rule about local viewing, retention, export or deletion after access withdrawal. Recommend the next states and actions.
