@codyswann/lisa 2.247.3 → 2.250.0

package/plugins/lisa/.codex-plugin/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/.codex-plugin/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/.codex-plugin/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/.codex-plugin/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/.codex-plugin/skills/lisa-setup-kane/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: lisa-setup-kane
+description: "Configure TestMu Kane CLI as an…"
+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/.codex-plugin/skills/lisa-setup-kane/agents/openai.yaml

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

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

@@ -0,0 +1,71 @@
+---
+name: lisa-track
+description: "Resolves exactly one live…"
+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/.codex-plugin/skills/lisa-track/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Track"
+short_description: "Resolves exactly one live…"
+default_prompt:
+  - "Use $lisa-track: Resolves exactly one live…."

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

@@ -0,0 +1,35 @@
+---
+name: lisa-tracker-claim
+description: "Vendor-neutral dispatcher for…"
+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/.codex-plugin/skills/lisa-tracker-claim/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Tracker Claim"
+short_description: "Vendor-neutral dispatcher for…"
+default_prompt:
+  - "Use $lisa-tracker-claim: Vendor-neutral dispatcher for…."

package/plugins/lisa/.codex-plugin/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/.codex-plugin/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/.codex-plugin/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/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/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/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/commands/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/commands/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/rules/eager/config-resolution.md

@@ -37,6 +37,15 @@ through the contract's bounded projection, never read raw wholesale. Both
 writers and budget checks import the executable contract from
 `@codyswann/lisa/learnings`; they must not copy its numeric limits.
 
+## Optional Kane browser provider
+
+Kane is selected only through `verification.browser.kane`: require `enabled: true`, exact version
+`0.6.3`, `cloudUploadApproved: true`, an explicit non-production `allowedEnvironments` entry, a
+Test Manager `projectId`, and a resolved `exploration` mutation policy of `full`. Credentials never
+live in Lisa config. Run `lisa kane probe` before use and invoke only through `lisa-kane-browser`;
+provider/auth/upload/schema failures are tooling failures, not product failures. Kane supplies
+empirical evidence only—native Playwright/Cypress/Maestro remains the regression authority.
+
 ## Env → base branch
 
 For implementation work, map the work item's `## Target Backend Environment` to

package/plugins/lisa/rules/eager/convergent-review.md

@@ -0,0 +1,19 @@
+# Convergent Review
+
+Review exists to get correct work merged, not to keep a PR in review orbit.
+
+- Block only concrete correctness, security, data-loss, or contract-violation
+  failures. Lint-owned style, formatting, taste, and speculative improvements
+  are non-blocking unless the work item or repository rules make them release
+  criteria.
+- Every finding must state severity, blocking yes/no, a concrete failure
+  scenario, evidence, and the smallest actionable fix.
+- A blocking finding without a concrete failure scenario is malformed by
+  contract; downgrade it to non-blocking and ask for evidence.
+- Resolve each finding as `fixed`, `deferred`, or `pushed-back`. If the reviewer
+  cannot refute a pushback with fresh evidence, the author's disposition stands.
+- After suggestion implementation completes and gates pass, review does not
+  reopen absent new evidence: a relevant new commit, a failed gate, a newly cited
+  failure scenario, or a scope change.
+- Irreconcilable blocking disagreement becomes a blocked work item with both
+  positions summarized for the operator, not an endless loop.

package/plugins/lisa/rules/eager/tracked-work.md

@@ -0,0 +1,7 @@
+# Tracked Work
+
+Before the first durable project mutation (code, tests, config, docs, committed research/plans/findings, commits, or PRs), establish exactly one live tracker leaf through `lisa-track`. Read-only discussion and orientation are exempt only while they produce no durable artifact.
+
+The mandatory order is: live-validate an explicit ref, or conservatively search and create exactly one valid leaf through `lisa-tracker-write` when no unique match exists; idempotently claim it through `lisa-tracker-claim`; then persist and verify the worktree-local binding with `node scripts/lisa-work-item.mjs bind <ref>`. Any tracker, claim, or binding failure blocks durable work.
+
+Carry that canonical ref through the branch, every ordinary commit's `Work-Item:` trailer, the PR, usage/evidence, and `lisa-tracker-sync`. Hooks and CI never create tickets. Keep the binding through interruptions or blocked outcomes; run `node scripts/lisa-work-item.mjs clear` only after merge/deploy/verification, two-way linkage/evidence, and the tracker item have all reached true terminal completion.

package/plugins/lisa/rules/eager/verification.md

@@ -10,7 +10,7 @@
 
 - **Never claim success without runtime evidence.** "The code looks correct" is not evidence.
 - **If all you did was run tests, typecheck, and lint — you have NOT verified.**
-- **Browser-controller neutrality.** For UI work, control a live browser and perform the Validation Journey as a human would. An in-app Browser/Chrome tool, interactive Playwright control (MCP, API, or ad hoc script), CDP, computer use, or an equivalent controller is acceptable. Do not block merely because one preferred backend is unavailable when another interactive controller can drive the browser. Running an automated Playwright or Maestro test alone is still a quality gate, not the initial empirical evidence; after the live journey passes, codify it in the applicable runner(s).
+- **Browser-controller neutrality.** For UI work, control a live browser and perform the Validation Journey as a human would. 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 controller is acceptable. Kane requires explicit upload approval, a passing `lisa kane probe`, an allow-listed non-production environment, and mutation policy `full`; its provider failure is not a product failure. Do not block merely because one preferred backend is unavailable when another interactive controller can drive the browser. Running an automated Playwright or Maestro test alone is still a quality gate, not the initial empirical evidence; after the live journey passes, codify it in the applicable native runner(s). Kane never replaces those regression gates.
 - **Before starting implementation, state your verification plan** — how you will USE the resulting software to prove it works. A plan that only lists `test`/`typecheck`/`lint` commands is not a plan. Do not begin until confirmed.
 - **After verifying empirically, codify it as a regression test** via the `codify-verification` skill — Playwright for UI, integration test for API/DB/auth, benchmark for performance. Codification is mandatory for every verification type except PR/Documentation/Deploy and Investigate-Only spikes. For **frontend work**, codification is dual-runner: a Playwright spec in the project's Playwright test runner AND a Maestro flow in the Maestro test runner whenever the project supports Maestro (`.maestro/` directory, `maestro:test` script, or Maestro CI workflow) — both encoding the same verified journey, neither a substitute for the other.
 - **The codified proof re-runs in CI.** Codified runtime verification lives where the project's e2e/Playwright tests live (`tests/e2e/**`) and runs as a required CI check for types with verification enforced — so the proof re-runs on every PR, not once by hand.

package/plugins/lisa/rules/reference/config-resolution.md

@@ -320,6 +320,30 @@ When `github.projects.v2` is present, later setup/doctor and writer preflight va
 | `linear.workspace` | `tracker = "linear"`, `source = "linear"`, or any `linear-*` skill is invoked | Linear workspace slug (e.g. `acme`). |
 | `linear.teamKey` | `tracker = "linear"` | Linear team key (e.g. `ENG`). The team owns the destination Issues. For source mode, projects are workspace-scoped or team-scoped per the URL passed. |
 
+#### `verification.browser.kane`
+
+Kane CLI is an optional empirical-browser provider. It is never enabled by executable discovery
+alone and never replaces native regression runners.
+
+| Field | Required when | Where it lives | Notes |
+|-------|---------------|----------------|-------|
+| `verification.browser.kane.enabled` | using Kane | **committed** | Must be literal `true`; absent/false means Lisa does not probe or select Kane. |
+| `verification.browser.kane.version` | enabled | **committed** | Exact contract-tested version, currently `0.6.3`. Version ranges and implicit latest are rejected. |
+| `verification.browser.kane.cloudUploadApproved` | enabled | **committed** | Exterior human approval that TestMu may receive objectives, screenshots, action logs, variables in scope, metadata, and packaged run artifacts from disposable test environments. |
+| `verification.browser.kane.allowedEnvironments` | enabled | **committed** | Non-empty environment allow-list. `prod` and `production` are invalid regardless of other config. Each environment must also resolve to `exploration.environments.<name>.mutation = full` at run time. |
+| `verification.browser.kane.projectId` | enabled | **committed** | Expected Test Manager project identifier. `lisa kane probe` verifies the active CLI config matches it. |
+| `verification.browser.kane.folderId` | no | **committed** | Optional expected Test Manager folder identifier, also verified by the probe. |
+| `verification.browser.kane.timeoutSeconds` | no | **committed** | Integer 1–600; defaults to 120. Lisa adds a small outer process-kill grace period. |
+
+Credentials never live in Lisa config. Developer OAuth state remains in Kane's protected local
+profile; CI uses its secret store and a dedicated service identity. Local config may override a
+Kane key per the normal per-key precedence, but shared upload policy, allow-list, and Test Manager
+target should be committed so teammates and automations see the same gate.
+
+Use `/lisa:setup-kane` only at the exterior setup gate. Factory workflows invoke
+`lisa-kane-browser`, which calls the Lisa adapter (`lisa kane probe/run`) rather than consuming the
+vendor's global skill or `agents.md`.
+
 #### `usage`
 
 `usage` is optional. It carries non-secret pricing metadata Lisa may use when runtime token counts are trustworthy but runtime monetary cost is absent.
@@ -677,6 +701,7 @@ The shim → vendor mapping is fixed:
 | `lisa-tracker-validate` | `lisa-jira-validate-ticket` | `lisa-github-validate-issue` | `lisa-linear-validate-issue` |
 | `lisa-tracker-verify` | `lisa-jira-verify` | `lisa-github-verify` | `lisa-linear-verify` |
 | `lisa-tracker-read` | `lisa-jira-read-ticket` | `lisa-github-read-issue` | `lisa-linear-read-issue` |
+| `lisa-tracker-claim` | `lisa-jira-claim` | `lisa-github-claim` | `lisa-linear-claim` |
 | `lisa-tracker-evidence` | `lisa-jira-evidence` | `lisa-github-evidence` | `lisa-linear-evidence` |
 | `lisa-tracker-sync` | `lisa-jira-sync` | `lisa-github-sync` | `lisa-linear-sync` |
 | `lisa-tracker-add-journey` | `lisa-jira-add-journey` | `lisa-github-add-journey` | `lisa-linear-add-journey` |
@@ -689,7 +714,7 @@ The `tracker-source-artifacts` skill (formerly `tracker-source-artifacts`) is re
 ## Caller responsibilities
 
 - **PRD-source skills** (`notion-to-tracker`, `confluence-to-tracker`, `linear-to-tracker`, `github-to-tracker`) MUST invoke `tracker-write` and `tracker-validate` — never `jira-write-ticket` / `github-write-issue` / `linear-write-issue` directly. This is what makes a project's destination switchable via config.
-- **Lifecycle skills** (`implement`, `verify`, `monitor`) MUST invoke `tracker-read`, `tracker-evidence`, `tracker-sync` for ticket interaction — never the vendor-specific equivalents.
+- **Lifecycle skills** (`implement`, `verify`, `monitor`) MUST invoke `tracker-read`, `tracker-claim`, `tracker-evidence`, `tracker-sync` for ticket interaction — never the vendor-specific equivalents.
 - **Per-vendor PRD intake skills** (`notion-prd-intake`, `confluence-prd-intake`, `linear-prd-intake`, `github-prd-intake`) compose the PRD-source skills (which in turn invoke the shims) — they do not need to read `tracker` themselves.
 - **Vendor-specific destination skills** (`jira-*`, `github-*`, `linear-*`) read their own vendor config section directly. They do NOT consult `tracker` — they are the targets of dispatch, not the dispatchers.
 

package/plugins/lisa/rules/reference/convergent-review.md

@@ -0,0 +1,69 @@
+# Convergent Review
+
+Review exists to get correct work merged, not to keep a PR in review orbit.
+Apply this contract to every product, quality, local, bot-parity, and suggestion
+implementation pass.
+
+## Severity Bar
+
+Findings block only when they name a concrete failure scenario in one of these
+classes:
+
+- Correctness: shipped behavior violates the work item, breaks an existing
+  contract, or loses required data.
+- Security: the change creates or preserves an exploitable auth, input,
+  secret-handling, permission, or data-exposure flaw.
+- Data loss: a realistic path can delete, corrupt, overwrite, or strand user or
+  operational state.
+- Contract violation: the change breaks a public API, workflow, generated
+  artifact contract, tracker lifecycle, or documented factory invariant.
+
+Lint-owned style, formatting, taste, general maintainability preferences, and
+speculative improvements are non-blocking unless the repository rule or work
+item explicitly makes them release criteria.
+
+## Required Finding Shape
+
+Every finding must state:
+
+- Severity: `critical`, `major`, `minor`, or `nit`.
+- Blocking: `yes` or `no`.
+- Failure scenario: the concrete user, operator, security, or factory outcome
+  that occurs if the change ships as-is.
+- Evidence: the file, command output, observed behavior, ticket text, or
+  external constraint proving the scenario is reachable.
+- Fix: the smallest actionable correction, or the reason no code change is
+  needed.
+
+A finding marked blocking without a concrete failure scenario is malformed by
+contract. Downgrade it to non-blocking and ask for evidence instead of treating
+it as a merge blocker.
+
+## Dispositions
+
+The implementer resolves each finding with exactly one disposition:
+
+- `fixed`: code, tests, docs, or generated artifacts changed to remove the
+  failure scenario.
+- `deferred`: the issue is real but non-blocking; record the rationale and, when
+  useful, the follow-up work item.
+- `pushed-back`: the finding is not valid for this work because evidence,
+  scope, or existing project rules refute it; reply with that rationale.
+
+If a reviewer cannot refute a `pushed-back` disposition with fresh evidence, the
+author's disposition stands.
+
+## Stopping Rule
+
+After suggestion implementation completes and the required quality and
+verification gates pass, review does not reopen unless new evidence appears:
+
+- a new commit changes the reviewed behavior,
+- a gate fails,
+- a reviewer supplies a previously uncited failure scenario, or
+- the work item scope changes.
+
+Irreconcilable blocking disagreement is not an endless review loop. Move the
+work item to the configured blocked state, add the human-needed marker when the
+decision is human-only, and summarize both positions in operator-readable
+language.