The scenario
The form currently allows a second submission during an in-flight request. Normal success, failure and retry behavior must remain usable.
Required context: a selected repository matching this scenario, relevant task evidence, and access to its instructions and checks. Use redacted or synthetic data where appropriate.
Adapt the complete prompt
Edits stay in this browser tab. Saving bookmarks the original example; export your edited version to keep it elsewhere.
Why this is a strong example
The pending-request invariant and failure recovery are more precise than asking to disable a button briefly.
A concrete outcome
Prevent a double-click on Submit from creating two records while the first request is pending.
The result can be assessed against an observable task rather than prompt length or confidence.
Boundaries and a method
Reproduce the sequence, inspect request handling and choose a narrow fix. Do not rely solely on a fixed delay or silently change server retry semantics.
This leaves implementation judgment while constraining the changes that would exceed the task.
Evidence that can disagree
Check rapid double-clicks, a slow request, failure followed by retry, and normal submission. Show that the regression fails without the fix.
These checks describe what would make acceptance justified; asking for them does not mean they ran.
A safe way to encounter uncertainty
If the repository contradicts these assumptions, required access is unavailable, or a consequential product decision is missing, explain the conflict and pause the dependent work. Preserve unrelated changes.
Consequential uncertainty stays visible rather than being converted into an invented requirement.