lisa-kane-browser

name	lisa-kane-browser
description	Optional Lisa-owned adapter for…
allowed-tools	["Bash","Read","Glob","Grep","Skill"]

Kane empirical browser provider

Use this skill only when a parent Lisa workflow has already classified a DOM-web empirical verification and selected Kane from the available browser-controller providers. Kane is an optional implementation detail, not the owner of Lisa's verification verdict.

Hard preconditions

1. Read the effective .lisa.config.json + .lisa.config.local.json configuration.
2. Require verification.browser.kane.enabled: true.
3. Require verification.browser.kane.cloudUploadApproved: true. Kane uploads objectives, screenshots, action logs, variables in scope, metadata, and run artifacts to TestMu Test Manager. If approval is absent, do not run it and do not ask from inside a factory.
4. Require the selected environment in allowedEnvironments. prod and production are always rejected even if listed.
5. Require the use-the-product mutation policy to resolve to full. During the initial rollout, Kane must not receive a broad objective in read-only or forbidden environments.
6. Require a disposable test identity and cleanup plan. Never use real customer records.
7. Run lisa kane probe <project-root> --json. A failed probe is a tooling blocker, not a product failure. Do not start an interactive login from an unattended factory.

Execute

Build one self-contained objective from the parent workflow's Validation Journey. It must state the starting URL, identity/persona, actions, observable assertions, and cleanup expectation. Do not put credentials or secret values in the objective; use the project's existing Kane variable bindings.

Run:

lisa kane run <project-root> \
  --environment <environment> \
  --mutation full \
  --url <base-url> \
  --objective "<self-contained objective>" \
  --json

The Lisa adapter always adds Kane's non-interactive --agent --headless flags, bounds time and steps, and parses the evolving event stream behind a stable contract.

Interpret the normalized result

• passed — empirical journey passed. It is not complete until lisa-codify-verification encodes the same behavior in every supported native regression runner.
• product_failed — the live journey or assertion failed. Diagnose from evidence; a Kane confirmedProductBug flag is evidence, not permission to bypass Lisa's duplicate search or tracker-write gate.
• tool_failed — Kane installation, auth, schema, upload, Chrome, or control-plane failure. Never report this as a product regression.
• timed_out — provider timeout. Retry only under the parent workflow's bounded retry policy.

Progress events are informational and may change between Kane releases. Automation decisions use only Lisa's normalized result, which is derived from the terminal event and process exit code.

Evidence

Use the local evidence pack as the source artifact. Extract the screenshots, HAR/network log, console log, and result summary required by the ticket's evidence manifest. Route those artifacts through lisa-tracker-evidence so they become durable PR/ticket evidence. A Test Manager share URL is secondary convenience evidence and must never be the only proof because it can expire.

Do not commit Kane session directories, credentials, browser profiles, raw variable stores, or unreviewed recordings. Redact secrets and sensitive person-level data before attaching evidence.

Non-goals

• Do not install the vendor's global skill or append its agents.md to project instructions.
• Do not tell agents to prefer Kane for every browser task.
• Do not replace interactive native browser control when it is safer for the selected mutation policy.
• Do not replace Playwright, Cypress, Selenium, Maestro, or Detox regression coverage.
• Do not use kane-cli generate, testmd, code export, or auto-healing as an authoritative Lisa regression gate during the initial rollout.