tegwick
96d11431dc
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
51 lines
4.4 KiB
Markdown
51 lines
4.4 KiB
Markdown
# 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.
|