The scenario
Typing an old query then a new query can leave the old response visible if it arrives last.
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
It names response ordering and supplies a failing sequence that can distinguish a real fix from a cosmetic change.
A concrete outcome
Ensure the results shown belong to the latest query when responses arrive out of order.
The result can be assessed against an observable task rather than prompt length or confidence.
Boundaries and a method
Inspect existing cancellation or request-identity conventions and fix the narrow race. Preserve empty-query behavior and existing loading/error presentation.
This leaves implementation judgment while constraining the changes that would exceed the task.
Evidence that can disagree
Simulate a slow old response and a fast new response; verify that the new results remain visible. Also check clearing the query during a request.
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.