3.9 KiB
Fast Browser: unattended, caller-configured test sessions
This supersedes the original prototype's mandatory per-action approval and password-field exclusion. The user explicitly requested an automation tool controlled by an initiating model such as Astra, including local test-account login, configuration files/TUI, parallel isolated browsers and headless execution.
Contract
- The initiating model supplies the task, bounded steps, allowed origins and optional settings/credential bindings. Execution has no interactive approval layer, including in print mode.
- Preserve operational correctness: step/time budgets, current target/document checks, exact fill verification, explicit click postconditions, cancellation and unknown-outcome reporting. These are not user permission prompts.
- Credentials may be caller-provided literals, environment references, plain local files, or named top-level JSON file entries. Resolve only for the selected fill. Never insert resolved values into JEV state, generation prompts or result traces. Literal arguments remain present in the initiating Pi session's ordinary tool-call history; references avoid adding the value there.
- Password inputs are supported like other native inputs. No blanket login/test-account ban. Hidden controls and unsupported file upload/rich-text mechanics remain capability limits, not authentication policy.
Configuration
Precedence: per-call settings > project .pi/fast-browser.json > global agent-directory fast-browser.json > legacy environment defaults. File settings are reread for the next invocation. /fast-browser uses Pi's native selection/input UI to inspect/edit settings and choose project/global save scope; changes do not require restarting Pi.
Keep actual provider API keys out of settings. A Typesafe key may be selected through a local file/environment reference; ordinary Pi model authentication continues to use the model registry. Runtime endpoint/executable/model fields and declared credential references are caller-controlled, never selected by website content.
Browser sessions
- Add explicit open/observe/run/close session lifecycle. The initiating agent can retain an opaque session ID across calls, so login and navigation state survive until cleanup.
- Each launched session gets a distinct browser process, temporary user-data directory, CDP endpoint and browser-harness controller. Tabs in a shared profile are not treated as isolation.
- Support Vivaldi, Chrome and Chromium using the current CDP/browser-harness backend. A configured product never silently falls back to another product.
- A caller may override the executable path. Headless launch is explicit (
browser.headless: true); visible launch remains available for debugging. An attached browser's display mode was determined externally when it started. - Attach to an explicit compatible endpoint when requested, without closing the externally owned browser. Hold an exclusive endpoint lease for the session to reject competing automation on that same endpoint; attachment does not isolate cookies or local storage from other clients.
- Independent sessions can operate concurrently. Serialize operations within each session, not globally. Close only the requested owned session; extension shutdown cleans up owned resources.
- Firefox is explicitly deferred by the user. Reject unsupported engine selection honestly; a future Firefox backend must not pretend CDP compatibility.
Separate browser processes do not isolate application database records, accounts or server-side sessions. Parallel suites must choose suitable test accounts/data as well.
Validation boundaries
Use offline controller, credential, native-UI, process-lifecycle and worker tests first. Do not use modified repository code to bypass the currently loaded tool's mandatory action UI; live unattended checks require a future session with the updated tool contract. No real credentials, browsers or provider calls are required for this implementation's regression suite.