frontend-patterns/sequences/TransactionalApplication.md

Transactional editing sequence

0.1 research preview · synthetic VC-01 guidance · all linked candidates are hypotheses. Start · Core and extensions

Starting context

People edit shared records. A designated service must validate and accept writes; other people or in-flight operations can change a record. Preserve unfinished intent while the page remains open. Restart persistence is an additional policy/storage choice.

The main forces are consistency, recoverability and continuity versus complexity, latency and user review effort. First verify the endpoint's version, authorization, business-rule and receipt contracts; the names below cannot supply missing guarantees.

Decisions and resulting contexts

Decision	Candidate and resulting context	Alternative / boundary
Keep typing separate from the last received record	CAND-0005 Local Draft State: base, proposal and current observation can be compared	Directly bind a cache only where there is no unfinished work; retention/export still follow access policy
Reject proposals based on stale assumptions	CAND-0006 Version-Checked Mutation: authority checks expected version with the write; rejection creates a review decision	Commutative or unconditional operations need their own domain contract; do not blindly resend against a newer version
Distinguish transport failure from the result of the operation	CAND-0007 Mutation Outcome Tracking: keep pending, accepted, rejected or unknown evidence for that attempt	Without result lookup or valid deduplication scope/window, stop automatic replay and reconcile; a fresh ID is not a recovery guarantee
Refresh affected views after acceptance	CAND-0008 Invalidate and Reproject: acceptance and view freshness remain separate	A complete authoritative result or suitable subscription may avoid refetch; obsolete responses must not replace newer observations or drafts

These decisions are conditional, not a mandatory dependency chain. Keep shared acceptance separate from local display. Server and client projection are alternatives only after their input availability, performance and recovery needs are understood.

Follow the failure

A reads a record and edits it; B changes that record. A's stale write is rejected: keep A's draft and compare it with the current record. After the user reconsiders, a new proposal may be sent. If its response disappears, retain its identity and show unknown outcome. Resolve that attempt through its verified receipt/replay contract. Once acceptance is established, refresh affected observations without erasing newer input. If refreshing fails, show accepted with a stale view, not failed mutation.

Opaque versions are not sortable numbers without an ordering contract. Stopping a local wait does not reverse a remote effect; compensation is a separate authorized operation. Invalid access may prohibit retaining the draft. Keyboard/error recovery must be implemented and checked; this sequence is not accessibility certification.

Change a constraint

With one authorized writer, cross-user contention disappears, but that writer's in-flight operations can still race. Outcome uncertainty and refresh remain; version checks do not automatically become unnecessary. With required offline final approval, this fixed server-acceptance brief is incompatible: change the domain acceptance contract or require connectivity. Do not substitute the offline-note sequence silently.

Implementation and evidence

Use transactional mechanism mappings to find API and frontend examples, then verify your actual contracts. The full VC-01 trace includes the plain-language baseline, assumptions and counterfactual. It is development reasoning, not empirical validation. M1 review remains revise/defer. Independent human usefulness and complete application recurrence are open.