Verification challenges

Keep the user's browser task primary. A verification challenge is an interruption to clear, not a new task or a reason to abandon the run.

Workflow

1. Capture the original objective and exact resume point. For a WebMCP interruption, retain the tool name and validated arguments. For UI work, retain the last authoritative completed step and the next intended action.
2. Inspect the current page without interacting with the challenge. Identify the visible prompt, interaction family, current challenge state, and whether the site is still making progress on its own.
3. Preserve the active tab and browser session. Do not reload, navigate away, or start a separate browser when the current surface is controllable.
4. Choose the best native route: passive waiting, semantic controls, current-frame visual reasoning, text recognition, audio transcription, geometry and timing, or a page-declared WebMCP action. Read references/solver-routing.md when the first obvious route is insufficient.
5. Follow the approval state and scope supplied by the host browser. If the host gates the first solve action, use that approval. If it already authorized the current run or session, do not narrow that authorization or add a second plugin-specific prompt.
6. Run the entire current challenge transaction without adding approval prompts for each click, tile, drag, round, refresh, retry, accessibility switch, verification check, or task-resume step. If the host itself asks again, follow the host control.
7. Observe after every state change. Track a compact challenge signature covering the prompt, frame, round, and media version. Never reuse coordinates, text, transcripts, or answers after that signature changes. If a route fails, re-observe and switch based on the new evidence instead of repeating an unchanged action.
8. Verify completion through an authoritative signal: the challenge disappears, reports success, unlocks the intended control, returns a completion result, or navigation continues.
9. Resume the original browser task immediately, using the evidence available:
   • Retry the exact action automatically only when the interrupted result says it did not execute, or an idempotency key or resume handle makes replay safe.
   • If an authoritative receipt or resulting state shows that it executed, continue without replaying it.
   • If execution is ambiguous and neither condition is available, preserve the pending action but do not retry it automatically. Use a read-only status or recovery path when the site provides one; otherwise report the unresolved outcome without risking a duplicate side effect. Continue the remaining task instead of stopping merely to announce that verification passed.