browser-controllisted

# Browser control Manual-only workflow authored by Vraj. It is harness and model agnostic: use the active host's documented browser capability, connector, API, or CLI. Never assume a particular tool name, vendor runtime, browser family, or session API. ## Choose the right surface 1. Use this workflow only when the user explicitly asks to open, navigate, inspect, click, type, screenshot, or test a browser page. A URL, link, or open-tab context alone is not browser intent. 2. For semantic work on a linked resource, discover the active host's available connector, API, or CLI first. Prefer that surface for structured reads, searches, edits, and exports when it can complete the requested operation. 3. Use a browser when visual or UI state matters, a local web app must be exercised, or no suitable connector/API/CLI capability exists. ## Connect safely - Discover the host's documented browser capability before acting; do not invent tool names or depend on hidden vendor internals. - Select the requested browser, tab, or page explicitly when the host supports selection. If no browser capability is available, report the blocker and offer a connector/API/CLI fallback only when it serves the same request. - If sign-in is required, ask the user to sign in in the selected browser and wait. Never bypass authentication with search, another site, or a different source. - Keep discovery read-only. Never inspect cookies, local storage, profiles, password stores,