# 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](https://kubernetes.io/docs/reference/using-api/api-concepts/#updates-to-existing-resources), 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](https://docs.gitlab.com/api/repository_files/#update-a-file-in-a-repository), 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](https://docs.stripe.com/api/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](https://reactrouter.com/explanation/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](https://reactrouter.com/start/framework/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](../walkthroughs/VC01-TransactionalAdministration.md).
Combined with four offline drafts this gives eight research hypotheses, not eight
admitted patterns. [Cross-case review](VC01-VC02-Comparison.md) 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](TransactionalLiveReview.yaml). The manual claims above
remain independently bounded by their primary sources.