@codyswann/lisa 2.247.3 → 2.250.1

package/plugins/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/rails/copy-overwrite/lefthook.yml

@@ -17,13 +17,23 @@ pre-commit:
       # inside a git worktree (the inherited GIT_DIR points at the wrong repo).
       run: env -u GIT_DIR -u GIT_WORK_TREE bundle exec bundler-audit check --update
 
+prepare-commit-msg:
+  commands:
+    work-item-trailer:
+      run: node scripts/lisa-work-item.mjs prepare-commit-msg {1} {2} {3}
+
 commit-msg:
   commands:
+    work-item:
+      run: node scripts/lisa-work-item.mjs validate-commit {1}
     conventional-commit:
       run: 'head -1 {1} | grep -qE "^(feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert)(\(.+\))?: .+" || (echo "Commit message must follow conventional format" && exit 1)'
 
 pre-push:
   commands:
+    work-item:
+      run: node scripts/lisa-work-item.mjs validate-push {1}
+      use_stdin: true
     rspec:
       run: bundle exec rspec
     brakeman:

package/scripts/lisa-work-item.mjs

@@ -0,0 +1,5 @@
+#!/usr/bin/env node
+
+// The installed copy lives under all/copy-overwrite. Keeping this tiny entrypoint
+// makes the exact same implementation available to Lisa's own hooks and CI.
+await import("../all/copy-overwrite/scripts/lisa-work-item.mjs");

package/typescript/copy-contents/.husky/commit-msg

@@ -20,29 +20,15 @@ fi
 # Get the commit message file path
 COMMIT_MSG_FILE=$1
 
-# Get the current branch name
-BRANCH_NAME=$(git branch --show-current)
-
-# Extract Jira key from branch name if present
-# Default pattern matches common Jira project keys (2-10 uppercase letters followed by a hyphen and numbers)
-# Can be overridden with JIRA_PROJECT_KEY environment variable (e.g., JIRA_PROJECT_KEY="SE|PROJ|ABC")
-JIRA_PROJECT_KEY=${JIRA_PROJECT_KEY:-"[A-Z]{2,10}"}
-
-# Extract Jira key from branch name using grep
-# Matches patterns like: feat/SE-2397-description, SE-2397-description, chore/PROJ-123-something
-JIRA_KEY=$(echo "$BRANCH_NAME" | grep -E "(^|/)($JIRA_PROJECT_KEY)-[0-9]+" | grep -E "($JIRA_PROJECT_KEY)-[0-9]+" -o | head -1)
-
-if [ -n "$JIRA_KEY" ]; then
-  # Read the current commit message
-  COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")
-  
-  # Check if the Jira key is already in the commit message
-  if ! echo "$COMMIT_MSG" | grep -q "\[$JIRA_KEY\]"; then
-    # Append the Jira key to the commit message
-    echo "$COMMIT_MSG [$JIRA_KEY]" > "$COMMIT_MSG_FILE"
-    echo "🎫 Auto-appended Jira key: [$JIRA_KEY]"
-  fi
+WORK_ITEM_SCRIPT="scripts/lisa-work-item.mjs"
+if [ ! -f "$WORK_ITEM_SCRIPT" ]; then
+  WORK_ITEM_SCRIPT="all/copy-overwrite/scripts/lisa-work-item.mjs"
+fi
+if ! command -v node >/dev/null 2>&1; then
+  echo "❌ Commit blocked: Node.js is required to validate tracker work items."
+  exit 1
 fi
+node "$WORK_ITEM_SCRIPT" validate-commit "$COMMIT_MSG_FILE" || exit 1
 
 echo "📝 Validating commit message with commitlint..."
 $EXECUTOR commitlint --edit $1
@@ -98,4 +84,4 @@ if ! echo "$COMMIT_MSG" | grep -Eiq "Co-authored-by:.*(Claude|Codex)"; then
   exit 1
 fi
 
-# END: AI GUARDRAILS
+# END: AI GUARDRAILS

package/typescript/copy-contents/.husky/pre-push

@@ -1,5 +1,15 @@
 # BEGIN: AI GUARDRAILS
 
+WORK_ITEM_SCRIPT="scripts/lisa-work-item.mjs"
+if [ ! -f "$WORK_ITEM_SCRIPT" ]; then
+  WORK_ITEM_SCRIPT="all/copy-overwrite/scripts/lisa-work-item.mjs"
+fi
+if ! command -v node >/dev/null 2>&1; then
+  echo "❌ Push blocked: Node.js is required to validate tracker work items."
+  exit 1
+fi
+node "$WORK_ITEM_SCRIPT" validate-push "${1:-origin}" || exit 1
+
 # Detect package manager (check if tool is available before using it)
 # Priority: bun > yarn > npm (bun first since package.json engines prefer it)
 if ([ -f "bun.lockb" ] || [ -f "bun.lock" ]) && command -v bun >/dev/null 2>&1; then

package/typescript/copy-contents/.husky/prepare-commit-msg

@@ -0,0 +1,15 @@
+# BEGIN: AI GUARDRAILS
+
+WORK_ITEM_SCRIPT="scripts/lisa-work-item.mjs"
+if [ ! -f "$WORK_ITEM_SCRIPT" ]; then
+  WORK_ITEM_SCRIPT="all/copy-overwrite/scripts/lisa-work-item.mjs"
+fi
+
+if ! command -v node >/dev/null 2>&1; then
+  echo "❌ Commit blocked: Node.js is required to link commits to tracker work items."
+  exit 1
+fi
+
+node "$WORK_ITEM_SCRIPT" prepare-commit-msg "$@"
+
+# END: AI GUARDRAILS