After running an action once, a caller may ask to verify another sentence in its result. Reusing earlier success skips the new condition; treating it as a new action can send the same input twice. Northstar's Gemini path separates action identity from verification identity to avoid both mistakes.
The action and the completion question are different information
The action key contains current intent and selected actions, new-chat choice and confirmed target. It does not include waiting and completion options in the same way. VerificationHash separately contains completion, resultText and expectedDraft. What was done and what must be established before finishing become different records.
Hashing every option together can make a longer wait or revised completion phrase look like a new action. Dropping verification options altogether lets earlier success answer a new question without evidence. The system needs both a boundary preventing duplication and a criterion establishing sufficient verification. One identity cannot safely stand in for both purposes.
Compare a new condition with the earlier confirmed receipt
When a confirmed receipt belongs to the current target or result URL, the path compares verificationHash. A mismatch stops with GEMINI_REUSE_VERIFICATION_REQUIRED, directing the caller to read the original result without resending the action. Earlier success is not relabeled as evidence that the revised condition also matched.
This branch is not a universal automatic re-verifier for every new condition. A caller must still inspect the appropriate current text or media. The error communicates two facts together: another verification is needed and another action is not. A useful failure result distinguishes those next steps instead of encouraging an indiscriminate rerun.
Changing only waiting time does not change the action
With the same verification criteria, changing timeout leaves the action key and verificationHash unchanged, allowing the earlier confirmation to be reused. Existing tests vary waiting settings and require only one input effect or send. More time to observe should not itself produce another effect.
Reused here means reuse of an earlier confirmed receipt for the same condition. It does not mean every part of the current page was freshly reverified. The code's receipt and URL association should be described within its actual scope. Previous confirmation, present observation and new-condition verification are different evidence, rather than three interchangeable forms of fresh success.
Do not promote legacy receipts to every new verification
A legacy receipt without verificationHash has a narrow default exception: completion is the default changed and neither resultText nor expectedDraft adds a condition. A new draft precondition or expected phrase cannot use that exception. Backward compatibility is not permission to relax the verification standard for new requests.
A dispatched receipt instead stops as OUTCOME_UNCERTAIN, leaving original-result inspection necessary. Changing a verification hash or inventing a fresh action key to bypass that protection is inappropriate. New identity alone does not make unresolved work safe. The implementation keeps legacy interpretation, known confirmation and uncertainty as separate states.
Tests cover false reuse and duplicate effects together
An existing test confirms a field action, then requests another completion phrase for the same action. The new verification is refused while fill remains at one. Another preserves the legacy default receipt but rejects a changed expectedDraft without resending. The checks establish both refusal of false verification reuse and avoidance of another effect.
This task read those functions and tests without resending an original AI-service request. The independent generation observer does not implement this entire receipt/hash reuse system. Its thirty-two tests concern observation states, a different scope from receipt-change verification. Related shared code should not be promoted into a claim that every surrounding feature is reproduced.
Stricter verification should not mean more execution
It is natural for a customer to ask for a closer check of a result. If adding a condition repeats a question, upload or edit, even requesting inspection becomes risky. Preserve the original effect and separate the additional evidence still needed.
I want to retain this distinction between identity of execution and identity of verification. The account describes the particular Gemini path rather than assuming identical key construction across all services. A caller needs to read both which request must not be sent again and which completion condition remains unproven. Those facts make careful verification possible without multiplying work.