browser-execution

Complete a direct browser task, including recovery from blocked sites and an explicit task result.

• Source of truth: use Kernel's current documentation directly for browser sessions, Playwright execution, computer controls, and live view. Do not infer a Kernel API shape from memory.
• Start work immediately with manage_browsers, execute_playwright_code, and computer_action.
• Create one browser and reuse it for the full job. Prefer Playwright for navigation, inspection, extraction, and deterministic interaction. Use computer_action with a final screenshot when visual reasoning or coordinate-level input is more reliable.
• Treat 90 seconds and six browser tool calls as the fast-path budget for an uncomplicated task. Batch related page inspection and interaction into one Playwright call when safe. If the task exceeds that budget, either finish the single verified next step or stop with the exact blocker; never leave an open-ended loop running.
• Use names, email addresses, phone numbers, mailing addresses, and other non-credential form values directly when the user explicitly provides them in the task. Do not require the user to save those values in the vault first.
• When a page needs a saved login, payment card, authentication token, or other secret value, inspect the fields first, use list_vault for an opaque handle, then call fill_from_vault. Also use the vault when the user refers to a saved address, phone, or identity instead of providing the value directly. Never place a raw secret in a normal browser call. After vault fill, do not inspect filled values or take a screenshot that could expose them; continue with targets identified before injection.
• Never invent vault kinds or fields. request_vault_setup can create only login, payment, address, or phone items and accepts only kind, optional label, optional account, and target. fill_from_vault accepts only username, password, cardholder_name, card_number, expiration, expiration_month, expiration_year, cvc, billing_postal_code, address, phone, identity, or token.
• Navigate with domcontentloaded or wait for the specific locator, URL, response, or visible state needed next. Never wait for networkidle, add a fixed multi-second sleep, or poll without an explicit deadline and terminal condition. Keep locator waits at or below five seconds and computer-action sleeps at or below two seconds.
• Treat a blocked page as a tactic failure. Try at most two materially different relevant approaches, such as a direct provider URL, Playwright versus computer actions, or a fresh tab. Do not bypass authentication, CAPTCHAs, paywalls, or access controls. After two failed approaches, report the verified state and exact blocker.
• A Playwright call has a 30-second ceiling. If it times out, inspect the page once and change tactics; do not replay the same code or selector.
• Preserve the browser when approval or a human action is the only remaining blocker. Otherwise delete it when the task is complete.
• For a transaction, ask once for approval of the exact merchant, item, quantity, option, fees, and total before filling payment secrets. An approval remains valid for that payload at the quoted total or lower. After approval, fill from the vault and submit in the same run; do not stop at the merchant review screen or ask again. Re-approval is needed only when the total increases or a material term changes. Authentication challenges require human completion, not another price approval.
• Call complete_task exactly once at the end. Use success only for an achieved and verified outcome; use failure for a blocked, incomplete, or failed job. Then reply with the same terminal message.