@codyswann/lisa 2.247.2 → 2.250.0

package/plugins/lisa/skills/lisa-monitor/SKILL.md

@@ -122,6 +122,8 @@ Execute the **Monitor** sub-flow as defined in the `intent-routing` rule (loaded
 
 The **Rails** ops-specialist composes a different subset (`ops-run-local`, `ops-deploy`, `ops-check-logs`, `ops-verify-jobs`, `ops-verify-telemetry` — X-Ray/CloudWatch traces and metrics via `ops-verify-telemetry`). When no `ops-specialist` overlay is present (e.g. NestJS, CDK, or a generic TypeScript repo), fall back to **stack-agnostic base probing** — read manifests/config to discover what's wired, then probe live sources directly (Sentry CLI/REST, `aws logs` / `aws cloudwatch` / `aws xray`, the Playwright MCP for client-side console/network), exactly as the `observability-audit` "read-then-probe" detection prescribes. The agent decides which subset to run based on the env, the repo profile, and any extra context.
 
+For a configured non-production DOM environment with mutation policy `full`, `ops-browser-uat` or the stack-agnostic fallback may invoke `lisa-kane-browser` after `lisa kane probe` succeeds. Use the normalized outcome and local evidence pack; a Kane tool/auth/upload/schema failure is `PRESENT (unverified)` or a tooling warning, never an application anomaly. Under `--report-only`, Kane remains report-only too and cannot file tickets directly.
+
 ## Ticket filing (standalone only)
 
 After report, file what was found — **only when run standalone**, never under `--report-only`/`--dry-run` and never when nested inside `lisa-verify` (which passes `--report-only`):

package/plugins/lisa/skills/lisa-parity-coderabbit/SKILL.md

@@ -34,6 +34,12 @@ For each changed file, `Read` the surrounding code and use `Grep`/`Glob` to foll
 
 ## Step 3: Review across all dimensions
 
+Apply the `convergent-review` rule before deciding severity or whether a finding
+blocks merge. Bias toward merge: block only concrete correctness, security,
+data-loss, or contract-violation failures with evidence. Lint-owned style,
+formatting, taste, and speculative maintainability improvements are non-blocking
+unless the work item or repository rules explicitly make them release criteria.
+
 Walk every meaningful hunk and evaluate each dimension. A finding in any dimension is fair game.
 
 1. **Correctness / bugs** — Logic errors, off-by-one, inverted conditions, missing `await`, null/undefined handling, type coercion, broken control flow, incorrect defaults, mutation of shared state, race conditions, broken or missing tests for new behavior.
@@ -59,6 +65,9 @@ Group as **Critical → Major → Minor → Nit**. Every finding includes:
 - **What** — the issue, and which dimension it falls under (bug / security / perf / maintainability / tests).
 - **Where** — `path/to/file.ts:line`.
 - **Why** — the concrete consequence, with a triggering example where relevant.
+- **Blocking** — `yes` only for concrete correctness/security/data-loss/contract failures; otherwise `no`.
+- **Failure scenario** — the concrete user, operator, security, or factory outcome if the change ships as-is.
+- **Evidence** — the cited file, observed behavior, command output, or contract that proves the scenario is reachable.
 - **Fix** — a concrete suggestion or code snippet.
 
 ### Walkthrough (optional but encouraged)
@@ -71,6 +80,7 @@ Call out what's done well. A credible review is balanced, not only critical.
 
 - **Cover the whole diff.** If you deprioritize anything for size, say which files and why — never imply full coverage you didn't give.
 - **Ground every finding in the code.** No generic checklists detached from the actual change; no speculative findings you can't point to.
+- **Malformed blockers do not block.** If you cannot name a concrete failure scenario and evidence, report it as non-blocking context or omit it.
 - **Concrete fixes only.** "Consider improving error handling" is not a finding; "wrap the `fetch` in try/catch and return a 502 on network error at `api/proxy.ts:31`" is.
 - **No external review service.** Use only local git/tooling and the model — this is an independent review, not a CodeRabbit proxy.
 - **Review-only.** Report findings; do not edit files. Route fixes through the implementation flow, `parity-code-simplifier` (quality), or a follow-up.

package/plugins/lisa/skills/lisa-product-walkthrough/SKILL.md

@@ -36,6 +36,8 @@ Write this list down. If you can't, the PRD is too vague — note it as a covera
 
 **Invoke `use-the-product`** to detect the type, resolve the environment + mutation policy, and discover personas — then drive the surfaces from step 1 through its per-type playbook (browser for DOM, `curl` for an API, canvas+input for a game, `cdk synth`/`diff` for IaC). Capture evidence as you go: for a DOM app, a `browser_snapshot` (accessibility tree — best for reasoning) and a `browser_take_screenshot` (visual) per surface and per state, plus `browser_console_messages` / `browser_network_requests` after interactions; for an API, representative request/response pairs; for a game, screenshots of each state. If the project defines personas, walk the surfaces as the relevant archetype(s).
 
+When the resolved DOM environment is non-production with mutation policy `full` and the configured Kane provider passes `lisa kane probe`, `use-the-product` may delegate the bounded journey to `lisa-kane-browser`. Extract its screenshot, HAR/network, console, and result artifacts into the normal Current Product evidence. Never use the expiring Test Manager link as the only evidence. A walkthrough that resolves `read-only` stays on a directly controlled browser backend during the initial Kane rollout.
+
 Honor the mutation gate: on a `read-only` env, observe without submitting; never walk a `forbidden` env (production defaults to forbidden). Treat console errors, 4xx/5xx, and unexpected calls as findings.
 
 ## 3. Record findings

package/plugins/lisa/skills/lisa-review-local/SKILL.md

@@ -6,6 +6,14 @@ disable-model-invocation: false
 
 Provide a code review for the local changes on the current branch compared to the main branch.
 
+Apply the `convergent-review` rule throughout this skill: reviewers bias toward
+merge, block only concrete correctness/security/data-loss/contract failures, and
+must label every finding with severity, blocking status, failure scenario,
+evidence, and fix. Lint-owned style, formatting, taste, and speculative
+maintainability feedback are non-blocking unless a repository rule or work item
+explicitly makes them release criteria. A blocking finding without a concrete
+failure scenario is malformed and must be filtered out.
+
 To do this, follow these steps precisely:
 
 1. Use a Haiku agent to check the current git state:
@@ -24,6 +32,7 @@ To do this, follow these steps precisely:
    c. Agent #3: Read the git blame and history of the code modified, to identify any bugs in light of that historical context
    d. Agent #4: Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current changes.
    e. Agent #5: Read code comments in the modified files, and make sure the changes comply with any guidance in the comments.
+   Each agent must apply the severity bar from `convergent-review` and return only findings that include a concrete failure scenario and evidence. Non-blocking observations may be summarized separately, but must not be presented as required changes.
 5. For each issue found in #4, launch a parallel Haiku agent that takes the diff, issue description, and list of CLAUDE.md files (from step 2), and returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
    a. 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
    b. 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
@@ -31,6 +40,7 @@ To do this, follow these steps precisely:
    d. 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
    e. 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
 6. Filter out any issues with a score less than 80.
+6a. Filter out any blocking issue that does not name a concrete failure scenario in one of the `convergent-review` blocker classes. Keep it only as non-blocking context if it is useful.
 7. Write the review to claude-review.md. When writing your review, keep in mind to:
    a. Keep your output brief
    b. Avoid emojis
@@ -44,6 +54,7 @@ Examples of false positives, for steps 4 and 5:
 - Pedantic nitpicks that a senior engineer wouldn't call out
 - Issues that a linter, typechecker, or compiler would catch (eg. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself -- it is safe to assume that they will be run separately as part of CI.
 - General code quality issues (eg. lack of test coverage, general security issues, poor documentation), unless explicitly required in CLAUDE.md
+- Findings that restate lint-owned style, formatting, taste, or speculative cleanup as blockers without a concrete failure scenario
 - Issues that are called out in CLAUDE.md, but explicitly silenced in the code (eg. due to a lint ignore comment)
 - Changes in functionality that are likely intentional or are directly related to the broader change
 - Real issues, but on lines that were not modified in the current branch

package/plugins/lisa/skills/lisa-setup-kane/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: lisa-setup-kane
+description: "Configure TestMu Kane CLI as an optional Lisa empirical-browser provider. Performs the exterior human approval gate for mandatory cloud uploads, verifies the pinned CLI version, provisions local/CI authentication, selects a Test Manager project/folder, runs a disposable synthetic check, and writes only non-secret policy identifiers to Lisa config."
+allowed-tools: ["Bash", "Read", "Write", "Edit", "AskUserQuestion"]
+---
+
+# Setup Kane CLI
+
+This is an explicit exterior setup gate. It may involve a human because authentication and cloud
+data approval must be complete before unattended factories run. Never invoke setup from inside an
+active Build, QA, Monitor, or Verify factory.
+
+## 1. Explain the data boundary and obtain approval
+
+Explain that every authored Kane session uploads screenshots, the objective, action logs, variables
+in scope, metadata, and packaged run artifacts to TestMu Test Manager. Explain that share links are
+secondary evidence and can be accessible outside project membership for their validity window.
+Clarify that this is privacy and data-egress approval, not purchase authorization: Lisa's adapter
+uses local Chrome rather than TestMu's paid remote grid, while Test Manager upload remains the
+default for local runs and Kane's AI features still require available account credits.
+
+Ask exactly one approval question: approve TestMu cloud upload for disposable dev/staging test data,
+or decline. On decline, leave configuration unchanged and report that Lisa's native controllers
+remain available.
+
+## 2. Install and pin
+
+Require Kane CLI `0.6.3`, the version covered by Lisa's adapter contract:
+
+```bash
+kane-cli --version
+npm install -g @testmuai/kane-cli@0.6.3  # only after setup approval if missing/wrong
+```
+
+Do not use `npx @testmuai/kane-cli-skill` and do not append vendor content to `AGENTS.md`.
+
+## 3. Authenticate outside the factory
+
+- Developer machine: run `kane-cli login --oauth` and let the operator complete browser consent.
+- CI/headless: provision a dedicated TestMu service identity using the platform's secret store. Do
+  not put username/access key in `.lisa.config.json`, command history, a ticket, or chat.
+
+Verify with `kane-cli whoami`. Record the identity label, never token material.
+
+## 4. Select the Test Manager target
+
+Use `kane-cli config project` and optional `kane-cli config folder`, then `kane-cli config show`.
+Capture the non-secret project/folder identifiers. Use a dedicated Lisa pilot project with access
+restricted to the engineering/QA operators who may view uploaded artifacts.
+
+## 5. Write policy configuration
+
+Merge this shape into committed `.lisa.config.json`, preserving every unrelated key:
+
+```json
+{
+  "verification": {
+    "browser": {
+      "kane": {
+        "enabled": true,
+        "version": "0.6.3",
+        "cloudUploadApproved": true,
+        "allowedEnvironments": ["dev", "staging"],
+        "projectId": "<project-id>",
+        "folderId": "<optional-folder-id>",
+        "timeoutSeconds": 120
+      }
+    }
+  }
+}
+```
+
+Production environments are invalid. Developer-specific overrides may live in
+`.lisa.config.local.json`, but shared provider policy and Test Manager identifiers belong in the
+committed config. Never write credentials to either file.
+
+## 6. Prove readiness
+
+Run `lisa kane probe . --json`, then run a harmless synthetic journey against a disposable local or
+dev fixture with mutation policy `full`. Confirm the normalized result, evidence pack, Test Manager
+link, screenshot, HAR, and console record. If any is missing, setup is incomplete.
+
+## 7. Prepare the controlled pilot
+
+Create a pilot manifest from `docs/kane-cli-pilot.example.json`, point it at at least two disposable
+downstream web applications, set the start timestamp and credit budget, then run:
+
+```bash
+lisa kane pilot <manifest>
+lisa kane pilot <manifest> --report-only
+```
+
+The pilot remains `collecting` until at least 30 days, 50 runs, and two observations per case exist.
+After the full window, an exterior security/privacy reviewer adds
+`policyReview: { "reviewedAt": "<ISO timestamp>", "incidents": <count> }` to the manifest. Never
+pre-attest zero incidents at pilot start. Only an `adopt` verdict permits wider enablement.

package/plugins/lisa/skills/lisa-setup-kane/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Setup Kane"
+short_description: "Configure TestMu Kane CLI as an optional Lisa empirical-browser provider"
+default_prompt:
+  - "Use $lisa-setup-kane: Configure TestMu Kane CLI as an optional Lisa empirical-browser provider."

package/plugins/lisa/skills/lisa-track/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: lisa-track
+description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Track Work: $ARGUMENTS
+
+Establish the tracked-work invariant before any durable project mutation. Discussion and read-only orientation may proceed without this skill; code, configuration, documentation, research artifacts, plans, investigation findings, tests, commits, and pull requests may not.
+
+This flow must return exactly one canonical `(tracker_provider, work_item_ref)` pair or fail closed. It never returns an unvalidated textual guess.
+
+## Phase 1 — Resolve tracker and classify input
+
+1. Resolve merged `.lisa.config.local.json` over `.lisa.config.json` exactly as `lisa-tracker-read` / `lisa-tracker-write` do. Missing, unknown, or incomplete tracker configuration is a blocking error.
+2. Classify `$ARGUMENTS` as exactly one of:
+   - an explicit reference matching the configured tracker (`KEY-123`, `org/repo#123` or issue URL, Linear team identifier);
+   - an existing file path containing a specification (read the entire file, without offset/limit);
+   - plain-text work description.
+3. Preserve the full resolved specification for the caller. Do not treat a ticket-like token for a different provider/project as plain text; report the mismatch.
+
+## Phase 2 — Resolve one live work item
+
+### Explicit reference
+
+Invoke `lisa-tracker-read <ref>` and require a live result from the configured project. Reject nonexistent, inaccessible, closed/resolved/terminal, wrong-project, wrong-repository, or container items. This live read is mandatory even if caller context already includes ticket text.
+
+### File or plain text
+
+Search conservatively before creating:
+
+1. Normalize the requested outcome and derive a short keyword set; never search with the whole prompt or secrets.
+2. Search only open/non-terminal items in the configured project and current repository through the configured provider's documented read surface:
+   - GitHub: `gh issue list --repo <org>/<repo> --state open --search "<keywords> in:title,body"`.
+   - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL.
+   - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace.
+3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, cross-repo, and materially different outcomes.
+4. Reuse only when **exactly one** live leaf is a high-confidence semantic match for the same requested outcome and repository. A shared keyword or similar title is not enough. Record the search queries, candidates, and rejection reasons in the returned resolution evidence.
+5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true`. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
+6. Live-read the writer's canonical returned reference with `lisa-tracker-read`. A create response without a verified live leaf is failure.
+
+This is intentionally conservative: ambiguity creates one explicit work item instead of silently attaching work to the wrong existing item. Across the entire invocation, at most one new work item may be created.
+
+## Phase 3 — Claim and bind
+
+1. Invoke `lisa-tracker-claim <canonical-ref>`. Require its post-read verified `claim_outcome: claimed|reused`; no binding may be written after a failed/unverified claim.
+2. Persist only the canonical reference in worktree-local machine state:
+
+   ```bash
+   node scripts/lisa-work-item.mjs bind <canonical-ref>
+   ```
+
+3. Read the binding back through `node scripts/lisa-work-item.mjs current` and require it to equal the canonical reference. If binding fails, stop before durable project work.
+   - A detached-HEAD worktree is valid at this stage: the binding records `branch: null` as a pending state. Create the feature branch only after the gate succeeds, then run `node scripts/lisa-work-item.mjs attach-branch`. Commit preparation and validation fail closed until that attachment succeeds.
+4. Return this structured result plus the full resolved work-item context:
+
+   ```text
+   tracker_provider: jira|github|linear
+   work_item_ref: <canonical-ref>
+   resolution_outcome: explicit|reused|created
+   claim_outcome: claimed|reused
+   binding_outcome: verified
+   ```
+
+## Lifecycle
+
+- The binding is worktree-local, uncommitted machine state. Never write it into tracked source files.
+- Branch setup may call `node scripts/lisa-work-item.mjs attach-branch` after the feature branch exists.
+- Keep the binding across ordinary interruptions and blocked outcomes so resumed work remains attributable.
+- Clear it only after true terminal completion — merged, deployed/verified where required, tracker evidence/backlink complete, and the work item terminal — by running `node scripts/lisa-work-item.mjs clear` and verifying no current binding remains.
+- A tracker outage, invalid item, failed claim, or failed binding blocks durable work. Never continue untracked and never ask a Git hook to create the item.

package/plugins/lisa/skills/lisa-track/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Track"
+short_description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in…"
+default_prompt:
+  - "Use $lisa-track: Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in…."

package/plugins/lisa/skills/lisa-tracker-claim/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: lisa-tracker-claim
+description: "Vendor-neutral dispatcher for idempotently claiming one already live-validated leaf work item. Reads the required tracker from .lisa.config.json and delegates to lisa-jira-claim, lisa-github-claim, or lisa-linear-claim. The vendor skill owns the post-read leaf/open guard, ready-to-claimed mutation, attributable assignment, and post-write verification."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Tracker Claim: $ARGUMENTS
+
+Thin dispatcher. `$ARGUMENTS` must contain exactly one canonical work-item reference. The caller must have already fetched it with `lisa-tracker-read`; each vendor claim skill independently repeats the live read before mutation and verifies the claim afterward so stale caller context cannot authorize a write.
+
+## Workflow
+
+1. Resolve merged tracker config exactly as `lisa-tracker-write` does:
+
+   ```bash
+   local_tracker=$(jq -r '.tracker // empty' .lisa.config.local.json 2>/dev/null)
+   global_tracker=$(jq -r '.tracker // empty' .lisa.config.json 2>/dev/null)
+   tracker="${local_tracker:-$global_tracker}"
+   ```
+
+2. Dispatch without changing `$ARGUMENTS`:
+   - Missing / empty -> stop and report `"No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."`
+   - `jira` -> invoke `lisa-jira-claim`.
+   - `github` -> invoke `lisa-github-claim`.
+   - `linear` -> invoke `lisa-linear-claim`.
+   - Anything else -> stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
+3. Return the vendor result unchanged. Success must include `tracker_provider`, canonical `work_item_ref`, `claim_outcome: claimed|reused`, and the post-write live-read evidence.
+
+## Contract
+
+- Claim only an open/unresolved, current-repository leaf per `leaf-only-lifecycle` and `repo-scope-split`. Never claim a container, terminal item, inaccessible item, or item from a different configured project.
+- Preserve later active lifecycle states. If the item is already in the configured claimed role or a later non-terminal role, return `reused`; never move it backward.
+- A fresh claim uses the same idempotency lock as the three build-intake Phase 3b flows: move configured ready to configured claimed, or place an unlaned backlog leaf directly in claimed; assign to the authenticated user only when unassigned; never replace an existing owner.
+- Fail closed if the mutation or post-write read cannot prove the claimed-or-later state. A tracker outage is a blocker, not permission to work untracked.
+- This skill claims existing work only. It never creates a ticket and never writes the worktree binding.

package/plugins/lisa/skills/lisa-tracker-claim/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Tracker Claim"
+short_description: "Vendor-neutral dispatcher for idempotently claiming one already live-validated leaf work item"
+default_prompt:
+  - "Use $lisa-tracker-claim: Vendor-neutral dispatcher for idempotently claiming one already live-validated leaf work item."

package/plugins/lisa/skills/lisa-use-the-product/SKILL.md

@@ -66,7 +66,7 @@ Look for the project's personas: `wiki/personas/**` (target-player archetypes, s
 
 Apply the interface's *read-only* actions always; the *mutate* actions only when the policy is `full`.
 
-- **DOM web app** — a real browser controlled interactively through any capable backend (in-app Browser/Chrome, Playwright MCP/API/ad hoc script, CDP, computer use, or equivalent). Land cold on the entry page, then click / type / select / submit visible controls and attempt real tasks; sweep viewport widths. The controller is an implementation detail; a missing preferred backend is not a blocker when another can drive the same live journey. A Playwright test run alone is not this evidence. *(The caller's lens supplies the specific things to look for.)*
+- **DOM web app** — a real browser controlled interactively through any capable backend (in-app Browser/Chrome, Playwright MCP/API/ad hoc script, CDP, computer use, the opt-in Lisa-owned Kane adapter, or equivalent). Land cold on the entry page, then click / type / select / submit visible controls and attempt real tasks; sweep viewport widths. The controller is an implementation detail; a missing preferred backend is not a blocker when another can drive the same live journey. A Playwright test run alone is not this evidence. Kane is selected only via `lisa-kane-browser`, only after `lisa kane probe` succeeds, and only for an allowed non-production env whose mutation policy is `full`; use a more directly controlled backend for `read-only` journeys. *(The caller's lens supplies the specific things to look for.)*
 - **HTTP / API backend** — the consumer is a client, not a browser. Read-only: read the OpenAPI/routes and call safe `GET`s (`curl`/`httpie`). Mutate: exercise representative `POST`/`PUT`/`DELETE` flows with test data as the `identity`; check status codes, payload shapes, and error responses.
 - **Canvas game** — a real browser, but the UI is **drawn to a canvas, not the DOM**. Boot it (e.g. `bun run dev` + Playwright), drive via **keyboard/pointer into the canvas**, and read state **visually via screenshots** (not the accessibility tree). Mutation is usually local save state. Judge readability, game-feel, and input responsiveness — not DOM breakpoints.
 - **CLI / library** — the interface is the command / public API. Read-only: `--help`, read-only commands, dry-runs. Mutate: run state-changing commands with disposable inputs.

package/plugins/lisa/skills/lisa-verification-lifecycle/SKILL.md

@@ -35,7 +35,9 @@ For each required verification type, discover what tools are available in the pr
 
 Report what is available for each required type. If a required type has no available tool, proceed to step 4.
 
-For UI verification, treat the browser controller as implementation-neutral. Check for an in-app Browser/Chrome tool, interactive Playwright control (MCP, API, or ad hoc script), CDP, computer use, or an equivalent controller that can drive a real browser session. Do not require one named backend, and do not declare a tooling block while any capable interactive controller is available. Running an automated Playwright or Maestro test is not a substitute for this live interaction; it becomes the regression gate only after the empirical journey passes.
+For UI verification, treat the browser controller as implementation-neutral. Check for an in-app Browser/Chrome tool, interactive Playwright control (MCP, API, or ad hoc script), CDP, computer use, the optional Lisa-owned Kane CLI adapter, or an equivalent controller that can drive a real browser session. Do not require one named backend, and do not declare a tooling block while any capable interactive controller is available. Running an automated Playwright or Maestro test is not a substitute for this live interaction; it becomes the regression gate only after the empirical journey passes.
+
+Kane is eligible only when `verification.browser.kane.enabled` and `cloudUploadApproved` are true, `lisa kane probe` passes, the target is an explicitly allowed non-production environment, and `use-the-product` resolves mutation policy `full`. Invoke `lisa-kane-browser`; never install or follow the vendor's broad `agents.md` instructions. A Kane tool/auth/upload/schema failure is a tooling blocker, not a product failure. Kane evidence may prove the empirical journey, but project-native Playwright/Cypress/Maestro remains the codified regression authority.
 
 If a required verification type needs sign-in or other credentials, exhaust credential sources before declaring the verification blocked. Check credential sources in this order:
 

package/plugins/lisa/skills/lisa-verify/SKILL.md

@@ -41,6 +41,7 @@ Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via
 4. **Review loop** — handle CodeRabbit / human review comments via `lisa-pull-request-review`
 5. **Merge** when CI is green
 6. **Remote verification** — invoke the `lisa-monitor` skill against the target environment **in report-only mode** (`lisa-monitor <env> --report-only`) to confirm the deploy actually works (health endpoints, recent logs/errors, Validation Journey replay if defined). `--report-only` is required here: it keeps the post-deploy check a pure health/audit report and prevents monitor's standalone ticket-filing from creating issues during a verify run. If remote verification surfaces a behavioral gap that the existing codified tests do not guard, invoke `codify-verification` to add coverage and open a follow-up PR.
+   - When the Validation Journey is DOM-web, the target is an allowed non-production environment with mutation policy `full`, and `lisa kane probe` succeeds, verification may invoke `lisa-kane-browser`. Import the local evidence pack into Lisa's evidence flow; the Test Manager URL is secondary. Kane does not replace the pre-flight Playwright/Maestro codification gate.
    - When remote verification needs credentials, follow the shared `verification-lifecycle` credential lookup order before declaring them missing: project e2e / Playwright config and fixtures first, then `.lisa.config.local.json` / environment variables, then documented ticket credentials such as a `Sign-in Required` section.
    - Should credentials remain genuinely unavailable after those sources are exhausted, do not complete the item on artifact-only evidence. Post a tracker comment stating what could not be verified and why, transition the work item to the configured blocked state, and apply the configured `needs-human` / `human-review` label, creating it if the tracker supports label creation and it is missing.
    - Evidence must explicitly distinguish `verified empirically` from `artifact-only / verification deferred`.

package/plugins/lisa-agy/agents/product-specialist.md

@@ -61,3 +61,5 @@ For each acceptance criterion:
 - If the changes are purely internal (refactoring, config, tooling), report "No user-facing impact" and explain why
 - Do not propose UX changes beyond what was described -- flag scope concerns instead
 - Assume the reviewer has no technical background
+- Apply the `convergent-review` rule: bias toward merge, block only concrete correctness/security/data-loss/contract failures, and mark lint-owned style or taste feedback as non-blocking.
+- For every finding, state severity, whether it blocks, the concrete user/operator failure scenario, evidence, and the smallest fix. A blocker without a failure scenario is malformed.

package/plugins/lisa-agy/agents/quality-specialist.md

@@ -24,7 +24,8 @@ For each changed file, evaluate:
 Rank findings by severity:
 
 ### Critical (must fix before merge)
-Broken logic or violates hard project rules.
+Broken logic, security exposure, data loss, or a hard contract violation with a
+concrete failure scenario.
 
 ### Warning (should fix)
 Could cause problems later or reduce maintainability.
@@ -54,3 +55,5 @@ For each finding:
 - Run the task's proof command to confirm the implementation works
 - Never approve code with failing tests
 - If no issues found, say so clearly -- do not invent problems
+- Apply the `convergent-review` rule: bias toward merge, block only concrete correctness/security/data-loss/contract failures, and do not block on lint-owned style, formatting, taste, or speculative maintainability improvements.
+- For every finding, state severity, whether it blocks, the concrete failure scenario, evidence, and the smallest fix. A blocker without a failure scenario is malformed.

package/plugins/lisa-agy/agents/verification-specialist.md

@@ -18,7 +18,7 @@ Read `.claude/rules/verification.md` at the start of every investigation for the
 
 **"If you didn't run it, you didn't verify it."** Code review is not verification. Reading a test file is not verification. **Running tests, typecheck, and lint is not verification either — those are quality gates (prerequisites).** Only executing the actual system and observing output counts as proof. Verification means making HTTP requests, clicking through the UI, running CLI commands, querying the database, or otherwise interacting with the running software as an end user would.
 
-For UI verification, control a live browser and perform the journey as a human would. The controller is implementation-neutral: an in-app Browser/Chrome tool, interactive Playwright control (MCP, API, or ad hoc script), CDP, computer use, or an equivalent browser controller all qualify. Do not block merely because a preferred backend is absent when another interactive controller is available. Running an automated Playwright or Maestro test alone does not qualify as the initial evidence; codify the journey in those runners only after the live interaction has passed.
+For UI verification, control a live browser and perform the journey as a human would. The controller is implementation-neutral: an in-app Browser/Chrome tool, interactive Playwright control (MCP, API, or ad hoc script), CDP, computer use, the optional Lisa-owned Kane adapter, or an equivalent browser controller all qualify. Kane is eligible only after `lisa kane probe` passes and the configured upload, environment, identity, and full-mutation gates are satisfied; invoke `lisa-kane-browser` and classify provider failures separately from product failures. Do not block merely because a preferred backend is absent when another interactive controller is available. Running an automated Playwright or Maestro test alone does not qualify as the initial evidence; codify the journey in those native runners only after the live interaction has passed, even when Kane supplied the empirical evidence.
 
 ## Verification Process
 
@@ -52,7 +52,7 @@ Before creating anything new, find what the project already has.
 
 **MCP tools:**
 - Check available MCP server tools for browser automation, observability, issue tracking, and other capabilities
-- For UI work, search for every capable interactive browser controller rather than requiring one named backend; interactive Playwright control is valid even though a Playwright test run alone is not verification
+- For UI work, search for every capable interactive browser controller rather than requiring one named backend; interactive Playwright control and policy-approved Kane are valid even though a prewritten test run alone is not verification
 
 ### 4. Plan the Verification
 

package/plugins/lisa-agy/commands/lisa/improve-harness.md

@@ -0,0 +1,6 @@
+---
+description: "Use after ONE run went wrong, to find the real cause and prove the fix worked. Investigates a single failed or expensive factory trajectory end to end: records the job contract, observes the baseline, locates the earliest failed handoff, classifies the gap (context | capability | domain-ownership | authority | proof | feedback-delivery | worker-limitation), makes the smallest owning intervention at the authoritative owner, verifies at both layers, and reruns in a fresh isolated session behind a relevance gate before deciding retain, revise, remove, or test-without. Files a proposed-intervention ticket and stops when the fix exceeds the smallest owning change. Unlike /lisa:debrief (mines a whole shipped initiative for learnings) and /lisa:rework-triage (fires only on QA/staging bounces), this runs on one trajectory, bounce or not."
+argument-hint: "<ticket URL | PR URL | session or run ref | described failure>"
+---
+
+Use the /lisa-improve-harness skill to run one bounded baseline → intervention → fresh-rerun loop on the given trajectory and post the result record to the originating work item. $ARGUMENTS

package/plugins/lisa-agy/commands/lisa/track.md

@@ -0,0 +1,6 @@
+---
+description: "Bind this worktree to one live work item in the configured tracker. Accepts an existing Jira, GitHub, or Linear reference, a specification file, or a plain-text description; validates or creates and claims exactly one leaf before persisting the local binding."
+argument-hint: "<work-item-url | key | spec-file | description>"
+---
+
+Use the /lisa-track skill to resolve, live-validate or create, claim, and bind exactly one configured-tracker leaf for this worktree. $ARGUMENTS

package/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.247.2",
+  "version": "2.250.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-agy/skills/lisa-codify-verification/SKILL.md

@@ -51,6 +51,8 @@ Before creating anything new, find what the project already has. Use the Tool Di
 
 Do NOT install a new framework if one already exists for the verification type. Use what's there.
 
+If the empirical proof came from Kane, consume its exact objective, observable assertions, URL, and local evidence pack as inputs. Do not commit Kane `_test.md` recordings, generated code, or auto-healed selectors as the authoritative regression. Encode the same behavior in the project's existing native runner under the deterministic rules below.
+
 ### 2. Map verification type → framework
 
 | Verification type | Preferred framework (use whichever the project already has) |

package/plugins/lisa-agy/skills/lisa-doctor/SKILL.md

@@ -66,6 +66,13 @@ as applicable to the current repo:
 7. **Optional wiki delegation** — when a repo-local `wiki/` exists, either summarize the
    specialized `lisa-wiki-doctor` verdict or explicitly report that deeper wiki checks are
    available there. The base doctor stays narrower than full wiki migration enforcement.
+8. **Optional Kane browser provider** — when `verification.browser.kane.enabled` is true, run the
+   Lisa-owned readiness probe. Require explicit cloud-upload approval, the contract-tested exact
+   version, a non-production environment allow-list, local Chrome/Chromium, Test Manager
+   project/folder targeting, `whoami` authentication, and nonzero/observable credit readiness.
+   Report missing executable/browser, auth failure, wrong target, zero credits, and control-plane
+   failure separately. If Kane is not enabled, report an informational `OK`/not enabled rather than
+   probing or installing it.
 
 If a check family is not applicable to the current repo, report `SKIP` with the reason.
 

package/plugins/lisa-agy/skills/lisa-exploratory-qa/SKILL.md

@@ -21,6 +21,7 @@ Experience the product the way a **brand-new end user** would: drive its real co
 ## 1. Set up
 
 - **Invoke `use-the-product`** to detect the product type, resolve the environment + mutation policy, and discover personas/subagents. Everything about *how* to drive the product, *where*, and *how much you may mutate* comes from there — do not re-derive it.
+- For a DOM web app whose resolved non-production environment has mutation policy `full`, check the optional Kane provider with `lisa kane probe`. If ready, invoke `lisa-kane-browser` for self-contained journeys and use its screenshots, HAR/network, console, and normalized verdict as evidence. Keep the run on a directly controlled browser for `read-only`/`forbidden` environments. Treat `tool_failed`/`timed_out` as provider findings, never as product bugs.
 - **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from `.lisa.config.json` (local overrides global). If unset, stop and report that the tracker must be configured (`/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file findings — do not silently fall back to a report file.
 - Read the `ready` flag (default `false`).
 
@@ -62,6 +63,8 @@ Whether you may create/edit/delete — and as which account — is set by the `u
 
 No report file. Every finding becomes a **leaf work item** via `lisa-tracker-write` (the vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never call a vendor `*-write-*` skill directly):
 
+Kane never files the work item itself. Even when it marks a failure as a confirmed product bug, run Lisa's marker-based duplicate search, apply the QA lens, and route the finding through `lisa-tracker-write` exactly as for every other controller.
+
 | Finding | `issue_type` | `build_ready` |
 |---|---|---|
 | User-visible **bug** (broken behavior) | `Bug` | the `ready` flag (default `false`) |

package/plugins/lisa-agy/skills/lisa-github-claim/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: lisa-github-claim
+description: "Idempotently claims one live GitHub leaf issue for direct Lisa work. Reuses github-build-intake Phase 3b semantics: configured ready-to-claimed relabel, assign-only-if-unassigned, stable managed comment, and post-write verification."
+allowed-tools: ["Bash", "Skill", "Read"]
+---
+
+# Claim GitHub Issue: $ARGUMENTS
+
+Claim exactly one canonical `org/repo#<number>` reference. This is the reusable direct-session counterpart of `lisa-github-build-intake` Phase 3b.
+
+1. Resolve merged `.github.org`, `.github.repo`, optional `.github.queueRepo`, and `github.labels.build` values from local-over-global config. Resolve current-repository identity independently using `repo-scope-split` / `config-resolution` (`.repo` -> `.github.repo` -> `git remote get-url origin` basename). The queue repository defaults to `<github.org>/<github.repo>`; it is only the tracker storage/scan target and never replaces current-repository identity. Resolve the ready and claimed roles from config (defaults `status:ready` and `status:in-progress`); do not hardcode lifecycle decisions.
+2. Require the ref's `org/repo` to equal the resolved queue repository. Invoke `lisa-github-read-issue <ref>` immediately before mutation. When the queue repository differs from the current repository, require exactly the current-repository scope (`repo:<current>`); reject an unlabeled issue, `repo:<other>`, or an ambiguous multi-repo leaf. Also reject a closed issue, an active blocker, any issue with open child work, or a childless Epic per `repo-scope-split` and `leaf-only-lifecycle`.
+3. Inspect the live build lifecycle labels:
+   - Already claimed, review, environment-done, or another configured later non-terminal role -> preserve it and set `claim_outcome: reused`.
+   - Ready or no build lifecycle label -> run `gh issue edit <number> --repo <org>/<repo>`, remove ready when present, and add claimed. This is the idempotency lock.
+   - Terminal label/state -> reject; completed work cannot be rebound as new work.
+4. If and only if the issue is unassigned, add `@me`; leave every existing assignee untouched.
+5. Post the stable marker comment once, deduped against all existing comments:
+
+   ```text
+   [lisa-tracker-claim] Claimed by Lisa. Starting implementation.
+   ```
+
+6. Invoke `lisa-github-read-issue <ref>` again. Success requires the issue to remain open, leaf/current-repo (including the explicit `repo:<current>` proof for an umbrella queue), and in claimed or a later non-terminal role. If the relabel or verification fails, return failure and do not authorize a binding.
+7. Return `tracker_provider: github`, canonical `work_item_ref: <org>/<repo>#<number>`, `claim_outcome: claimed|reused`, assignee outcome, and the post-write status evidence.
+
+Never create an issue here. Never call GitHub for a configured Jira or Linear project.