[Feat] Add bounded Jev screenshot preparation

[roomote-roomote]

​Created by Roomote. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• Added an opt-in prepare_screenshot Roomote MCP tool and authenticated task-run API route for bounded screenshot preparation.
• Sent structured page state, non-secret observed values, viewport geometry, evidence goals, and caller-provided allowed actions to the existing server-side Jev adapter; only a validated allowed action can be returned.
• Added fixed action, time, state-size, and one-recapture limits with conservative fallback, sensitive-value redaction, visual-judge correction feedback, acceptance/false-acceptance counters, token usage, and explicit unavailable USD cost reporting.
• Enforced redaction of URL query/fragment/userinfo and secret-like path patterns, plus sensitive visible-text lines and credential formats, before constructing Jev state.
• Applied the same URL sanitization to caller-provided navigate action descriptions before they enter the allowed-action state sent to Jev.
• Added a deterministic benchmark:screenshot-preparation harness with a fixed 1280x800 fixture requiring tab selection, form fill, dialog opening, below-fold scroll, and final save, plus explicit DOM/image acceptance and JSON timing output.
• Preserved one returned preparation loopId across all benchmark phases and recorded the independently accepted capture through the bounded record path.
• Added an explicit final capture-ready Jev decision on that same loop before screenshot acceptance and record accepted.
• Gated record accepted on an explicit post-run visual inspection result; otherwise the harness reports DOM acceptance and visual-inspection-required without recording success.
• Replaced the generation-time boolean with an exact-PNG result manifest handshake: the harness waits for a per-run result containing the exact capturePath, accepted, and post-capture inspectedAt timestamp.
• Accepted recording remains allowed after the 30-second preparation budget when capture-ready was reached; post-capture inspection still stays within the bounded loop TTL.
• Kept agent-browser as the real UI executor and exact final screenshot inspection as the acceptance gate; documented the prototype in the capture workflow and environment configuration.

Why this change was made

Jev is text-only but accepts structured JSON state, so it can help choose relevant bounded browser preparation actions without putting screenshots or browser execution behind the decision model. The existing visual-proof flow remains the default, the prototype is disabled unless both the deployment flag and task opt-in are present, and state sanitization now enforces the no-secret boundary rather than relying on prompt guidance.

Impact

The new path is isolated to screenshot preparation and fails back to the existing capture flow when Jev is unavailable, uncertain, stale, or over budget. The complex develop baseline completed 5/5 runs with visually accepted final PNGs; warm medians were 845.9 ms preparation, 78.4 ms capture, and 2,585.2 ms total. The PR prototype reached four genuine Jev-guided actions, consuming 6,723 input and 178 output tokens in the diagnostic attempt, but stopped at the final save action because the model remained low-confidence; no valid Jev-guided comparison or speedup claim is reported. The harness now explicitly requests capture-ready, permits post-capture recording after the preparation budget when capture-ready was reached, and only records acceptance after a post-capture exact-PNG result manifest; DOM-only runs remain unrecorded. The provider probe used a temporary process-only OpenRouter selection; no TypeSafe key, stored judgment selection, or persistent prototype flag is configured. The JSON baseline report is attached as a task artifact, and USD pricing is not inferred when the provider does not report it.

[roomote-community]

No new code issues found. See task

• Redact secret-bearing page URL and visible text before sending screenshot state to Jev.
• Redact secret-bearing navigation action URLs before sending screenshot state to Jev.
• packages/cloud-agents/scripts/screenshot-preparation-benchmark.mts:127 Parse the agent-browser snapshot's @eN button reference before attempting the benchmark action.
• packages/cloud-agents/scripts/screenshot-preparation-benchmark.mts:457 Request capture-ready before recording the accepted capture, so the benchmark exercises one complete bounded preparation loop.
• Gate benchmark record accepted on an explicit visual-acceptance input rather than DOM text alone.
• Collect a post-capture visual acceptance result for each PNG before recording it.
• packages/cloud-agents/scripts/screenshot-preparation-benchmark.mts:576 Allow a capture-ready loop to record a valid external inspection result after the 30-second preparation budget expires.

_{Reviewed e29910b}

[roomote-roomote]

Final lifecycle/visual acceptance fix is in [commit e29910b](https://github.com/RooCodeInc/Roomote/commit/e29910b2ed9d93c025dd06eb46b193a4d880bd7f).

• The harness preserves one loop through all phases, requests capture-ready, and waits for post-capture exact-PNG result manifests before recording accepted.
• Accepted recording remains permitted after the 30-second preparation budget once capture-ready has been reached, within the loop TTL; new preparation/rejection work remains budget-bound.
• Missing, stale, mismatched, or rejected visual results leave the loop unrecorded and report DOM acceptance separately.
• Full typechecks, focused tests, lint, and pre-push gates pass. Current Jev diagnostics remain low-confidence before capture-ready, so no comparison claim is made.

The review thread is resolved. The PR remains a draft. See the associated task: https://community.roomote.ai/task/27wpnvcecmzbg?utm_source=github-comment&utm_medium=link&utm_campaign=github_pr_review