frontend-patterns/research/reviews/TransactionalEvidenceExpansion.md

Transactional editing evidence review

Reviewed by Codex, 2026-09-25. Scope: bounded primary documentation, followed by editorial synthesis. No product UI was installed or fault-tested. API implementations are identifiable uses of server mechanisms, not verified uses of our frontend drafts. All pages are living documentation accessed on this date; exact revisions unknown.

Located evidence

Claim	Source and locator	Documented behavior	Boundary
T01	SRC-0008, Kubernetes API Concepts, Updates to existing resources, first two paragraphs	PUT supplies resourceVersion; stale versions receive 409	Conditional update behavior; not every PATCH or a frontend recovery design
T02	SRC-0009, GitLab repository files API, Update a file, attributes and failure paragraphs	Optional last_commit_id; concurrent branch update is one possible commit failure; failed commits return nonspecific 400	Cannot diagnose every 400 as concurrency or assume Kubernetes semantics
T03	SRC-0010, Stripe idempotent requests, paragraphs on saved results and key pruning	Same key replays saved status/body, including 500; parameters must match; keys may be removed after at least 24 hours	No perpetual deduplication; validation/concurrent execution failures before execution do not save results
T04	SRC-0011, React Router concurrency, Concurrent Submissions and Revalidation; Potential for Stale Data	Revalidation responses can be discarded; browser cancellation does not prevent a server mutation	Client response ordering alone is insufficient for write correctness
T05	SRC-0012, React Router Pending UI, Pending Form Submission and Optimistic UI	Per-form submission feedback and a task-state projection from submitted data	Framework examples, not two independent applications or a guarantee of domain acceptance

Kubernetes and GitLab establish two independent server implementations encountering concurrent writes, with materially different error information. Stripe adds a third implementation for a different mechanism: bounded retry identity. These are not three known uses of a complete frontend configuration. Two React Router pages count as one framework. None establishes draft persistence, accessible recovery or atomic business validation in our proposed application.

Candidate dispositions

Proposed name	Disposition and reason
Server Authority	Retain as context/decision in VC-01; too broad to add a new standalone record on this evidence
Local Draft State	New hypothesis draft: preserve intent separately from the last server observation; exact UI known uses unknown
Command Mutation	Narrow to Version-Checked Mutation; generic command dispatch does not specify concurrency behavior
Pending State	Narrow to Mutation Outcome Tracking: pending, unknown, rejected and accepted require different recovery
Optimistic Overlay	Defer standalone draft; T05 illustrates a technique, but domain conditions and independent uses remain weak
Invalidate and Reproject	New hypothesis draft; response ordering and draft preservation are explicit limits

The four new drafts connect through VC-01. Combined with four offline drafts this gives eight research hypotheses, not eight admitted patterns. Cross-case review records the contrast.

Research gaps and next bounded work

Within FEP-WP-0002 T02: find two actual frontend implementations with located source revisions showing draft preservation and unknown-outcome recovery. Test whether Mutation Outcome Tracking deserves a separate pattern or is a state model shared by several patterns. Within T03: independently review both walkthroughs against their plain-language baselines before M1 acceptance. Do not expand tooling to compensate for missing implementation evidence.

Live extraction and its editorial disposition are recorded in TransactionalLiveReview.yaml. The manual claims above remain independently bounded by their primary sources.