@codyswann/lisa 4.22.8 → 4.22.10

package/plugins/lisa-copilot/skills/lisa-setup-workstation/scripts/bounded-child.mjs

@@ -83,6 +83,15 @@ import { execFileSync, spawnSync } from "node:child_process";
  */
 export const CHILD_BUDGET_MS = 30_000;
 
+/**
+ * Deadline for setup operations that legitimately include downloads, package
+ * installation, secret-provider calls, or a project-declared hook.
+ *
+ * Kept separate from {@link CHILD_BUDGET_MS}: probes should still fail quickly,
+ * while a cold network install must not be killed by the probe budget.
+ */
+export const SETUP_OPERATION_BUDGET_MS = 10 * 60_000;
+
 /**
  * Whether this value is a child that was killed at its deadline.
  *

package/plugins/lisa-copilot/skills/lisa-setup-workstation/scripts/workstation.mjs

@@ -36,7 +36,10 @@
 import { existsSync, lstatSync, mkdirSync, rmSync, symlinkSync } from "node:fs";
 import { join } from "node:path";
 
-import { boundedChildOutput } from "./bounded-child.mjs";
+import {
+  boundedChildOutput,
+  SETUP_OPERATION_BUDGET_MS,
+} from "./bounded-child.mjs";
 
 import {
   AGENTS,
@@ -387,7 +390,9 @@ export function installEntry(entry, row, deps = {}) {
 
   try {
     if (entry.kind === "npm-global") {
-      run("npm", ["install", "-g", entry.package]);
+      run("npm", ["install", "-g", entry.package], {
+        timeout: SETUP_OPERATION_BUDGET_MS,
+      });
     } else if (entry.kind === "vendor-script") {
       if (!entry.script) {
         return {
@@ -410,12 +415,11 @@ export function installEntry(entry, row, deps = {}) {
       // exit status is the SHELL's, not curl's, so a 404 feeds an empty script
       // to bash, bash exits 0, and a tool that was never installed is reported
       // as installed. That is exactly what `sonarsource.com/install` did.
-      run("bash", [
-        "-o",
-        "pipefail",
-        "-c",
-        `curl -fsSL ${entry.script} | bash`,
-      ]);
+      run(
+        "bash",
+        ["-o", "pipefail", "-c", `curl -fsSL ${entry.script} | bash`],
+        { timeout: SETUP_OPERATION_BUDGET_MS }
+      );
     } else if (entry.kind === "aws-cli") {
       // macOS ships a .pkg that wants an administrator, which a headless run
       // has no business prompting for. Reported as manual with the one-line
@@ -436,20 +440,24 @@ export function installEntry(entry, row, deps = {}) {
       const url = `https://awscli.amazonaws.com/awscli-exe-linux-${
         process.arch === "arm64" ? "aarch64" : "x86_64"
       }.zip`;
-      run("bash", [
-        "-o",
-        "pipefail",
-        "-c",
+      run(
+        "bash",
         [
-          "set -e",
-          'tmp="$(mktemp -d)"',
-          `curl -fsSL "${url}" -o "$tmp/awscli.zip"`,
-          'unzip -q "$tmp/awscli.zip" -d "$tmp"',
-          `"$tmp/aws/install" --install-dir "${home}/.local/aws-cli" ` +
-            `--bin-dir "${home}/.local/bin" --update`,
-          'rm -rf "$tmp"',
-        ].join("\n"),
-      ]);
+          "-o",
+          "pipefail",
+          "-c",
+          [
+            "set -e",
+            'tmp="$(mktemp -d)"',
+            `curl -fsSL "${url}" -o "$tmp/awscli.zip"`,
+            'unzip -q "$tmp/awscli.zip" -d "$tmp"',
+            `"$tmp/aws/install" --install-dir "${home}/.local/aws-cli" ` +
+              `--bin-dir "${home}/.local/bin" --update`,
+            'rm -rf "$tmp"',
+          ].join("\n"),
+        ],
+        { timeout: SETUP_OPERATION_BUDGET_MS }
+      );
     } else if (CHECKSUMMED.has(entry.kind)) {
       // The pinned, checksummed path belongs to the remote-env installer. It is
       // borrowed rather than reimplemented so the pins and checksums cannot

package/plugins/lisa-copilot/skills/lisa-sonarcloud-access/SKILL.md

@@ -63,9 +63,9 @@ read_sonar_secret() {
   local name="$1"
   [ -n "${!name:-}" ] && { echo "${!name}"; return; }
   #
-  # Ordered repo-first, ending at the plugin's own copy. Repo-relative rungs
-  # lead because a project that vendors the resolver has declared which copy it
-  # wants used, and that decision must survive this change untouched. The plugin
+  # Ordered across trusted machine-managed substrates, ending at the installed
+  # package. Checkout-local paths are deliberately absent: a familiar generated
+  # destination is still repository-controlled executable code. The plugin
   # rungs are the floor: `resolve-secret.mjs` ships beside this skill, so a rung
   # pointing at it is reachable from anywhere the plugin itself is installed.
   # Without one, a consumer repository that vendors none of the leading paths
@@ -74,12 +74,9 @@ read_sonar_secret() {
   # lookups. This LADDER is identical in every skill that resolves a credential
   # and `credential-resolver-ladder` fails if any copy diverges. Only what
   # happens AFTER the ladder may differ between them.
-  local candidates=(
-    .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs
-    .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs
-    .opencode/skills/lisa/lisa-secrets-access/scripts/resolve-secret.mjs
-    .codex/skills/lisa/lisa-secrets-access/scripts/resolve-secret.mjs
-  )
+  # Execute only machine-managed plugin/package resolvers. Checkout-local
+  # candidates are repository-controlled code, not trusted merely by path.
+  local candidates=()
   if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
     candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
   fi
@@ -98,7 +95,7 @@ read_sonar_secret() {
       local via_lisa
       via_lisa=$(node "$resolver" get "$name" 2>/dev/null) \
         && [ -n "$via_lisa" ] && { echo "$via_lisa"; return; }
-      break
+      # Empty/error means this substrate had no answer; try the next trusted one.
     fi
   done
   # Name every path. A bare `return 1` sends the next reader hunting for a

package/plugins/lisa-copilot/skills/lisa-tracker-sync/SKILL.md

@@ -58,7 +58,7 @@ The state machine (first match wins, evaluated over the **required** leaves only
 | else any leaf has **started** (claimed or in review, or shipped while a sibling has not) | active / in-progress | `claimed` (or `review` where supported) |
 | else (leaves exist, none started) | unchanged | — |
 
-- **Blocked dominates** — one blocked leaf surfaces blocked on the parent even while others progress. It never says *which* child or *which kind* of hold; run `scripts/rollup-blocker-classification.mjs` over the resolved child graph and carry its per-class report — blocking leaf, path, and who must act — into the rollup note. A non-zero exit means it classified nothing; that is a failure to report, never an all-clear. See `leaf-only-lifecycle` → **Classifying a hold**.
+- **Blocked dominates** — one blocked leaf surfaces blocked on the parent even while others progress. It never says *which* child or *which kind* of hold. Resolve the shared classifier from `${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/rollup-blocker-classification.mjs` (the current-directory fallback supports a Lisa checkout), run it over the resolved child graph, and carry its per-class report — blocking leaf, path, and who must act — into the rollup note. A missing classifier or non-zero exit is a strict **no-write** result for every vendor: no lifecycle mutation and no rollup-comment mutation. Report the failure, never an all-clear. See `leaf-only-lifecycle` → **Classifying a hold**.
 - **Least-advanced env wins** — a parent reaches an env only once all required leaves have reached at least that env (all `On Stg` → `On Stg`; mixed dev/staging → the dev value). Native terminal closure fires only at the production `done`, never at an intermediate env.
 - **The parent never carries `ready`** — `ready` is a human "claim this leaf" signal; rollup only moves a parent between non-ready container states.
 - **Rollup is recursive** — an Epic rolls up from its Stories, each of which rolls up from its own leaves. Evaluate bottom-up.

package/plugins/lisa-cursor/.claude-plugin/plugin.json

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

package/plugins/lisa-cursor/hooks/parity-safety-net.sh

@@ -1064,8 +1064,38 @@ readonly AGENT_CREDENTIAL='(\.(claude|codex|cursor|copilot|gemini|antigravity)/[
 # 15d. Dotenv files. `.env.example`, `.sample`, `.template`, `.dist` and
 # `.schema` are checked-in documentation of which keys exist, never the values,
 # so they are excluded — that collision is the one this rule most had to avoid.
-readonly DOTENV_SECRET='(^|[[:space:]='"$qc"'./])\.env(\.[[:alnum:]_-]+)?([[:space:]'"$qc"']|$)'
-readonly DOTENV_PUBLIC='\.env\.(example|sample|template|dist|schema|defaults)([[:space:]'"$qc"']|$)'
+# Decide dotenv privacy per PATH, never by subtracting one command-wide match
+# from another. A command that names `.env.example` and `.env` contains both a
+# public path and a private one; seeing the former cannot authorize the latter.
+#
+# The one write-only shape this guard has always allowed remains explicit:
+# seeding a private dotenv destination from one public template. This is safe
+# because the private path is the destination, not a value being read back.
+has_private_dotenv_path() {
+  dotenv_scan_status=0
+  dotenv_candidates="$(printf '%s' "$normalized_command_str" \
+    | grep -Eio -- '(^|[[:space:]='"$qc"'./])\.env(\.[[:alnum:]_-]+)?')" \
+    || dotenv_scan_status=$?
+  if [ "$dotenv_scan_status" -gt 1 ]; then
+    block "dotenv path classification failed; denying the credential-store read fail-closed."
+  fi
+
+  while IFS= read -r candidate; do
+    [ -n "$candidate" ] || continue
+    candidate="$(printf '%s' "$candidate" \
+      | tr '[:upper:]' '[:lower:]' \
+      | grep -Eo -- '\.env(\.[[:alnum:]_-]+)?')"
+    case "$candidate" in
+      .env.example | .env.sample | .env.template | .env.dist | .env.schema | .env.defaults) ;;
+      *) return 0 ;;
+    esac
+  done <<EOF
+$dotenv_candidates
+EOF
+  return 1
+}
+
+readonly SAFE_DOTENV_SEED='^[[:space:]]*(cp|mv)[[:space:]]+\.env\.(example|sample|template|dist|schema|defaults)[[:space:]]+\.env(\.[[:alnum:]_-]+)?[[:space:]]*$'
 
 if matches "$SECRET_READ_VERB"; then
   if matches "$SSH_PRIVATE_KEY"; then
@@ -1077,10 +1107,10 @@ if matches "$SECRET_READ_VERB"; then
   if matches "$AGENT_CREDENTIAL"; then
     block "reading, copying or transmitting a coding-agent or package-registry credential store. These tokens impersonate the operator to every service the agent can reach."
   fi
-  # `.env` only when the path is NOT one of the public example forms. Ordered as
-  # an exclusion rather than a narrower pattern so a new example suffix is one
-  # word to add, and so the reason a file is exempt stays readable.
-  if matches "$DOTENV_SECRET" && ! matches "$DOTENV_PUBLIC"; then
+  # A public path elsewhere in the command never exempts a private path. The
+  # narrow public-template -> private-destination seed is write-only and remains
+  # allowed; every other command containing a private dotenv path is refused.
+  if has_private_dotenv_path && ! matches "$SAFE_DOTENV_SEED"; then
     block "reading, copying or transmitting a dotenv file holding real values. \`.env.example\`, \`.env.sample\`, \`.env.template\` and \`.env.dist\` are readable, and WRITING a .env is unaffected — only reading one back is refused."
   fi
   # Fail-closed, narrowly. A read whose DIRECTORY is a known credential store

package/plugins/lisa-cursor/hooks/threshold-ratchet-families.mjs

@@ -92,11 +92,11 @@ export const FAMILIES = [
  * Unknown keys stay unwatched until their direction is explicit here.
  * @type {Readonly<Record<string, "min"|"max">>}
  */
-export const LIGHTHOUSE_ASSERTION_DIRECTIONS = {
+export const LIGHTHOUSE_ASSERTION_DIRECTIONS = Object.freeze({
   minScore: "min",
   maxNumericValue: "max",
   maxLength: "max",
-};
+});
 
 /**
  * Extract numeric Lighthouse assertions with a direction chosen per key.
@@ -109,10 +109,22 @@ export const LIGHTHOUSE_ASSERTION_DIRECTIONS = {
  */
 export function extractLighthouseAssertions(conf) {
   const out = new Map();
-  const assertions =
+  const root =
     conf && typeof conf === "object" && !Array.isArray(conf)
-      ? /** @type {Record<string, unknown>} */ (conf).assertions
+      ? /** @type {Record<string, unknown>} */ (conf)
       : undefined;
+  const ci =
+    root?.ci && typeof root.ci === "object" && !Array.isArray(root.ci)
+      ? /** @type {Record<string, unknown>} */ (root.ci)
+      : undefined;
+  const assert =
+    ci?.assert && typeof ci.assert === "object" && !Array.isArray(ci.assert)
+      ? /** @type {Record<string, unknown>} */ (ci.assert)
+      : undefined;
+  // Lighthouse CI's canonical shape is `ci.assert.assertions`. Keep the
+  // historical top-level shape as a compatibility lane for already-generated
+  // project configs, but never merge the two into an ambiguous hybrid.
+  const assertions = assert?.assertions ?? root?.assertions;
   if (
     !assertions ||
     typeof assertions !== "object" ||
@@ -121,9 +133,21 @@ export function extractLighthouseAssertions(conf) {
     return out;
   }
   for (const [audit, spec] of Object.entries(assertions)) {
-    if (!spec || typeof spec !== "object" || Array.isArray(spec)) continue;
-    for (const [key, value] of Object.entries(spec)) {
-      const direction = LIGHTHOUSE_ASSERTION_DIRECTIONS[key];
+    const options =
+      Array.isArray(spec) &&
+      spec.length >= 2 &&
+      spec[1] &&
+      typeof spec[1] === "object" &&
+      !Array.isArray(spec[1])
+        ? /** @type {Record<string, unknown>} */ (spec[1])
+        : spec && typeof spec === "object" && !Array.isArray(spec)
+          ? /** @type {Record<string, unknown>} */ (spec)
+          : undefined;
+    if (!options) continue;
+    for (const [key, value] of Object.entries(options)) {
+      const direction = Object.hasOwn(LIGHTHOUSE_ASSERTION_DIRECTIONS, key)
+        ? LIGHTHOUSE_ASSERTION_DIRECTIONS[key]
+        : undefined;
       if (direction && typeof value === "number" && Number.isFinite(value)) {
         out.set(`${audit}.${key}`, { value, direction });
       }

package/plugins/lisa-cursor/rules/base-rules-reference.mdc

@@ -75,7 +75,7 @@ Testing Discipline:
 JIRA Discipline:
 - If working on a JIRA issue, make sure the branch you're working on references and is added to the JIRA issue.
 - If working on a JIRA issue, update the issue as you work through it. For example, if working on a Bug Triage, update the issue with your questions/feedback/suggestions.
-- When reading a JIRA issue, always read ALL comments on the ticket — not just the description. Comments contain critical context: stakeholder decisions, scope changes, blockers, triage findings from other repos, and implementation notes. Use the Atlassian MCP or first resolve the project root from `$CLAUDE_PROJECT_DIR` or `git rev-parse --show-toplevel`, then run `jira --config "$PROJECT_ROOT/.lisa/jira-cli/.config.yml" issue view <TICKET_ID> --comments 100`. If that project config is absent, omit `--config` to use the machine's own `~/.config/.jira/.config.yml`.
+- When reading a JIRA issue, always read ALL comments on the ticket — not just the description. Comments contain critical context: stakeholder decisions, scope changes, blockers, triage findings from other repos, and implementation notes. Use the Atlassian MCP or first resolve the project root from `$CLAUDE_PROJECT_DIR` or `git rev-parse --show-toplevel`. When `$PROJECT_ROOT/.lisa/jira-cli/.config.yml` exists, run both `jira --config "$PROJECT_ROOT/.lisa/jira-cli/.config.yml" issue view <TICKET_ID>` and `jira --config "$PROJECT_ROOT/.lisa/jira-cli/.config.yml" issue comment list <TICKET_ID>`; the dedicated comment-list command returns the complete comment collection instead of a fixed recent-comment window. If that project config is absent, omit `--config` from both commands to use the machine's own `~/.config/.jira/.config.yml`.
 - When requesting clarification on a JIRA issue, post the question as a comment using ADF (Atlassian Document Format) and @mention the Reporter so they receive a notification.
 - When creating JIRA tickets, establish issue link relationships (e.g. "is blocked by", "blocks", "relates to", "is duplicated by") between tickets that have dependencies or logical connections. Do not leave related tickets unlinked. Relationship discovery is mandatory on every create and update — search BOTH the local git history (`git log --all --grep=<keyword>`, `git log -- <path>`) AND Jira (JQL by component, keyword, label, epic siblings) before declaring "no related work." Record the searches you ran and their outcomes in the description (or a comment) so a reviewer can see the search was real.
 - Ticket scope by type: Bug, Task, and Sub-task tickets MUST be single-repo (one work unit, one repo). Epic, Spike, and Story tickets MAY span multiple repos. If a Bug/Task/Sub-task crosses repos, split it per the `repo-scope-split` rule — at PRD-decomposition time via `task-decomposition` step 1.5 (parent Story + per-repo children); at work-time (an existing ticket an agent is about to implement) via the work-time split procedure (narrow the original to one repo, spin off a sibling per additional repo cloning its metadata, link the producer→consumer dependency, then proceed). A cross-repo work unit is a decomposition error the agent fixes by splitting, not a reason to bounce the ticket to the reporter.

package/plugins/lisa-cursor/rules/config-resolution-reference.mdc

@@ -904,19 +904,10 @@ read_notion_token() {
   # and the surface ladder. An agent following this reference must try it before
   # any keychain — a second reader is how one credential ends up in two places.
   #
-  # Ordered repo-first, ending at the plugin's own copy. Repo-relative rungs
-  # lead because a project that vendors the resolver has declared which copy it
-  # wants used. The plugin rungs are the floor: `resolve-secret.mjs` ships
-  # beside the skill, so a rung pointing at it is reachable from anywhere the
-  # plugin itself is installed. Without one, a consumer repository that vendors
-  # none of the leading paths never reaches a resolver at all — and an agent
-  # copying a two-rung ladder out of THIS reference reproduces that.
-  local candidates=(
-    .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs
-    .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs
-    .opencode/skills/lisa/lisa-secrets-access/scripts/resolve-secret.mjs
-    .codex/skills/lisa/lisa-secrets-access/scripts/resolve-secret.mjs
-  )
+  # Resolver scripts are executable code, so a familiar checkout-local path is
+  # not provenance. Use only machine-managed plugin roots and the installed
+  # package; never execute repository-controlled candidates from this ladder.
+  local candidates=()
   if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
     candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
   fi
@@ -935,7 +926,7 @@ read_notion_token() {
       local via_lisa
       via_lisa=$(node "$resolver" get NOTION_API_TOKEN 2>/dev/null) \
         && [ -n "$via_lisa" ] && { echo "$via_lisa"; return; }
-      break
+      # Empty/error means this substrate had no answer; try the next trusted one.
     fi
   done
   # Legacy fallback: the OS keychain written by the guided setup flow, for

package/plugins/lisa-cursor/scripts/install-remote-agent-aws.mjs

@@ -329,12 +329,16 @@ the complete bundle from the shared account. Do not extract or distribute its
 individual access-key fields:
 
 \`\`\`bash
-aws --profile shared secretsmanager get-secret-value \\
+aws secretsmanager get-secret-value \\
   --secret-id ${secretName} \\
   --query SecretString \\
   --output text
 \`\`\`
 
+This uses the ambient AWS identity. Add \`--profile <source-profile>\` only when
+this project requires a named source profile to read the emission; \`shared\` is
+not an implicit requirement.
+
 Store that exact output as the masked secret \`LISA_AWS_BOOTSTRAP_JSON\` on each
 remote-agent platform. Run the setup command and require its live
 \`sts:GetCallerIdentity\` check to pass before considering the platform ready.

package/plugins/lisa-cursor/scripts/rollup-blocker-classification.mjs

@@ -293,6 +293,8 @@ function collectHolds(children, context, path, seen, tally) {
  *   container?: { ref?: unknown, type?: unknown }
  *   readError?: unknown
  *   children?: unknown
+ *   renderedState?: unknown
+ *   childTally?: unknown
  *   blockedStates?: unknown
  *   markerNames?: { specDefect?: unknown, humanNeeded?: unknown }
  * }} input
@@ -339,6 +341,10 @@ export function classifyRollupBlockers(input = {}) {
       blockers.filter(blocker => blocker.class === name),
     ]).filter(([, group]) => group.length > 0)
   );
+  const renderedState = trimmedString(input.renderedState);
+  const childTally =
+    trimmedString(input.childTally) ||
+    `examined=${tally.examined}, held=${blockers.length}, unreadable=${tally.unexaminable.length}`;
 
   return {
     ok: true,
@@ -348,6 +354,8 @@ export function classifyRollupBlockers(input = {}) {
     blockers,
     byClass,
     unexaminable: tally.unexaminable,
+    renderedState,
+    childTally,
   };
 }
 
@@ -433,8 +441,8 @@ export function renderRollupBlockerReport(result) {
 }
 
 /**
- * A stable identity for a rollup verdict: the container, plus every held item
- * and its class, sorted.
+ * A stable identity for a rollup note: the rendered lifecycle state, child
+ * tally, container, and every held item plus its class, sorted.
  *
  * This is what lets a repeat cycle stay quiet. 32 identical hold comments over
  * six weeks was the same verdict restated on a schedule; comparing this string
@@ -451,7 +459,14 @@ export function rollupBlockerFingerprint(result) {
     .map(blocker => `${blocker.ref}:${blocker.class}`)
     .sort((left, right) => left.localeCompare(right));
 
-  return `container=${result.container.ref};verdict=${result.verdict};examined=${result.examined};holds=${pairs.join(",")}`;
+  return [
+    `container=${result.container.ref}`,
+    `verdict=${result.verdict}`,
+    `rendered=${JSON.stringify(trimmedString(result.renderedState))}`,
+    `tally=${JSON.stringify(trimmedString(result.childTally))}`,
+    `examined=${result.examined}`,
+    `holds=${pairs.join(",")}`,
+  ].join(";");
 }
 
 /**

package/plugins/lisa-cursor/skills/lisa-atlassian-access/SKILL.md

@@ -57,9 +57,9 @@ read_atlassian_token() {
   # OS keychain here — a second reader is how the same credential ends up living
   # in two places and drifting.
   #
-  # Ordered repo-first, ending at the plugin's own copy. Repo-relative rungs
-  # lead because a project that vendors the resolver has declared which copy it
-  # wants used, and that decision must survive this change untouched. The plugin
+  # Ordered across trusted machine-managed substrates, ending at the installed
+  # package. Checkout-local paths are deliberately absent: a familiar generated
+  # destination is still repository-controlled executable code. The plugin
   # rungs are the floor: `resolve-secret.mjs` ships beside this skill, so a rung
   # pointing at it is reachable from anywhere the plugin itself is installed.
   # Without one, a consumer repository that vendors none of the leading paths
@@ -68,12 +68,9 @@ read_atlassian_token() {
   # lookups. This LADDER is identical in every skill that resolves a credential
   # and `credential-resolver-ladder` fails if any copy diverges. Only what
   # happens AFTER the ladder may differ between them.
-  local candidates=(
-    .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs
-    .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs
-    .opencode/skills/lisa/lisa-secrets-access/scripts/resolve-secret.mjs
-    .codex/skills/lisa/lisa-secrets-access/scripts/resolve-secret.mjs
-  )
+  # Executable resolvers are a code boundary. Checkout-local copies are mutable
+  # repository content, so use only machine-managed plugin/package locations.
+  local candidates=()
   if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
     candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
   fi
@@ -92,7 +89,7 @@ read_atlassian_token() {
       local via_lisa
       via_lisa=$(node "$resolver" get ATLASSIAN_API_TOKEN 2>/dev/null) \
         && [ -n "$via_lisa" ] && { echo "$via_lisa"; return; }
-      break
+      # Empty/error means this substrate had no answer; try the next trusted one.
     fi
   done
   # Legacy fallback: the OS keychain written by the guided /lisa:setup:atlassian
@@ -152,7 +149,7 @@ public static class LisaCred {
   echo "Error: could not resolve ATLASSIAN_API_TOKEN through lisa-secrets-access or the legacy keychain." >&2
   echo "Tried, in order (relative paths are from $PWD):" >&2
   printf '  %s\n' "${tried[@]}" >&2
-  echo "  <OS keychain> service=lisa-atlassian account=$email" >&2
+  echo "  <OS keychain> service=lisa-atlassian account=<configured>" >&2
   return 1
 }
 TOKEN=$(read_atlassian_token "$EMAIL")
@@ -288,7 +285,7 @@ if [ -n "$site" ] && [ "$current_site" != "$site" ]; then
 fi
 
 if [ -n "$email" ] && [ -n "$current_email" ] && [ "$current_email" != "$email" ]; then
-  echo "Error: acli active account is '$current_email', but .lisa.config.json requires '$email'. Run /lisa:setup:atlassian to add or repair the matching profile." >&2
+  echo "Error: acli active account does not match the configured Atlassian account. Run /lisa:setup:atlassian to add or repair the matching profile." >&2
   exit 1
 fi
 ```
@@ -310,7 +307,7 @@ if [ -z "$me_email" ]; then
   exit 1
 fi
 if [ "$me_email" != "$email" ]; then
-  echo "Error: ATLASSIAN_API_TOKEN belongs to '$me_email', but .lisa.config.local.json declares '$email'. Multi-account misconfiguration." >&2
+  echo "Error: ATLASSIAN_API_TOKEN identity does not match the configured Atlassian account. Multi-account misconfiguration; re-run /lisa:setup:atlassian." >&2
   exit 1
 fi
 ```

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

@@ -480,8 +480,8 @@ against both enforcing surfaces on paths a machine already takes:
 | the shipped ruleset template a repository is provisioned from | `lisa doctor` (one operator-readable line) and `lisa doctor --json` → `declarationDrift.templates` | no |
 | the live branch-protection ruleset | `lisa doctor --json` → `declarationDrift.live`, and the `github.declared-checks` check in `lisa health` | yes |
 
-Both report one verdict per required context, and the vocabulary is six values rather than
-matched/unmatched, because four of the mismatches need four different actions:
+Both report one verdict per required context, and the vocabulary is seven values rather than
+matched/unmatched, because the mismatches and an unreadable surface need different actions:
 
 - `matched` — declared `required`, and the surface requires it.
 - `declared-not-enforced` — the settings file says it must pass and nothing requires it. The
@@ -495,6 +495,8 @@ matched/unmatched, because four of the mismatches need four different actions:
 - `enforced-not-lisa-owned` — protection requires it and no registry gate produces it. Third-party
   checks are required by construction and declared by nobody; this bucket exists so they can be told
   apart from a Lisa gate that fell out of the settings file, never so they can be removed.
+- `unproven` — the surface could not be read, so no enforcement comparison was made. It is never a
+  match and never drift; the operator fixes access/availability and reruns the observation.
 
 `enforced-declared-off` and `declared-not-enforced` fail the health check; the two gaps warn. No
 remedy in that vocabulary removes a required context — the type has no such member, so the

package/plugins/lisa-cursor/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -343,9 +343,18 @@ auto-merge armed (section 1); when it returns, re-read `headRefOid` and reset
 
 **Merging past a rate-limited CodeRabbit is permitted — but ONLY when CodeRabbit
 is the sole gate still blocking the merge.** When the CodeRabbit context reports
-`Review rate limited` (or stays pending/queued because of the vendor cap) and it
-is the *only* thing standing between the PR and `MERGED`, do not wait it out:
-with `auto_merge=true` the PR already has auto-merge enabled (section 1), so
+`Review rate limited` and it is the *only* thing standing between the PR and
+`MERGED`, do not wait it out. Prove that vendor-cap signal from the live check
+description; `statusCheckRollup` does not carry enough detail, so read it with:
+
+```bash
+gh pr checks <pr> --json name,state,description,bucket \
+  --jq '.[] | select(.name == "CodeRabbit")'
+```
+
+A merely pending or queued CodeRabbit check is not proof of a vendor cap and
+must keep polling. Once that signal is explicit, and with `auto_merge=true`, the
+PR already has auto-merge enabled (section 1), so
 leave the latch armed and merge directly with `gh pr merge <pr> --<merge_method>`
 (pass `--admin` only if branch protection lists the rate-limited context as
 required and refuses the plain merge). "Sole gate" means every one of these is
@@ -355,7 +364,15 @@ from memory:
 - every other required check in `statusCheckRollup` is green (no FAILURE, no
   other PENDING);
 - zero unresolved review threads (human or bot);
-- `reviewDecision` is not `CHANGES_REQUESTED`;
+- the repository's human-approval requirement is demonstrably satisfied at the
+  current head: read the live branch/ruleset requirement, and when it requires
+  one or more approvals require `reviewDecision == APPROVED` plus the current
+  **effective** non-dismissed approval count. Compute effective reviews from the
+  latest non-dismissed review per reviewer, ordered by `submitted_at` then id;
+  an older approval from a reviewer never satisfies a later `CHANGES_REQUESTED`
+  from that reviewer. If the required count is zero, record that live
+  policy result. `REVIEW_REQUIRED`, `CHANGES_REQUESTED`, and `null` never stand
+  in for this proof before an admin merge;
 - `mergeable == MERGEABLE` and `mergeStateStatus` is not `BEHIND`/`DIRTY`;
 - no pending auto-fix PR into this branch (step f).
 
@@ -380,6 +397,14 @@ Some org rulesets allow 0 approvals yet a bot `CHANGES_REQUESTED` still blocks
 auto-merge — dismissing the stale review after resolving all threads is what
 unblocks it.
 
+When reading review history, derive the current review set rather than counting
+the whole array. One reproducible REST shape is:
+
+```bash
+gh api --paginate repos/<owner>/<repo>/pulls/<pr>/reviews --slurp \
+  --jq 'add | map(select(.state != "DISMISSED")) | sort_by(.submitted_at, .id) | reduce .[] as $review ({}; .[$review.user.login] = $review) | [.[]]'
+```
+
 ### f. Pending auto-fix PR into this branch
 If an open PR from `claude-auto-fix-<headRefName>` targets this PR's head
 branch (the CI auto-fix workflow engaged before this session took the lease),

package/plugins/lisa-cursor/skills/lisa-github-sync/SKILL.md

@@ -113,10 +113,15 @@ If the `subIssues` field is unavailable (older GHES), fall back to body parentag
 - **Blocked dominates — and the rollup must say which child and which kind** — a single blocked child surfaces `status:blocked` on the parent even while siblings progress, so a human sees the parent needs attention. `status:blocked` alone is a single bit and cannot tell a child waiting on an external event from one whose acceptance criteria are unbuildable; the second never clears on its own. Run the shared classifier over the resolved child graph before writing the label or the comment:
 
 ```bash
-node "${CLAUDE_PLUGIN_ROOT}/scripts/rollup-blocker-classification.mjs" --input=<graph.json>
+CLASSIFIER_ROOT="${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}"
+node "${CLASSIFIER_ROOT}/scripts/rollup-blocker-classification.mjs" --input=<graph.json>
 ```
 
-  Its report names, per class, the blocking leaf, the path to it (`#1495 -> #1515 -> #1547`) and **who must act** — that text goes in the rollup comment verbatim. It exits non-zero when it classified nothing (unreadable graph, no children, no readable child): treat that as a rollup that could not be derived and fall through to the **Safe default** below, never to "no blocked children". Never infer a class from prose and never apply the `spec_defect` marker from a flow — see `leaf-only-lifecycle` → **Classifying a hold**.
+The current-directory `plugins/lisa` fallback is for a Lisa checkout where no
+plugin-root variable is injected; it must be tried before declaring the shared
+classifier absent.
+
+  Its report names, per class, the blocking leaf, the path to it (`#1495 -> #1515 -> #1547`) and **who must act** — that text goes in the rollup comment verbatim. It exits non-zero when it classified nothing (unreadable graph, no children, no readable child): that is a strict **no-write** result. Do not change a label and do not post/update a rollup comment; report the classifier failure to the caller. Never fall through to "no blocked children", infer a class from prose, or apply the `spec_defect` marker from a flow — see `leaf-only-lifecycle` → **Classifying a hold**.
 - **Least-advanced env wins** — the parent reaches an env only when every required child has reached at least that env; it never sits ahead of its laggard child. Native closure (`gh issue close --reason completed`) fires only when the resolved env is the production `status:done`, never at `status:on-dev`/`status:on-stg`.
 - **"Required" children only** — a child labelled won't-do / optional does not hold the parent open; only leaves that must ship count toward the env-rollup check.
 - **Recursive** — a parent reaches an env only when its children have all reached at least that env; an Epic reaches it only when its Stories have themselves rolled up to it. Evaluate bottom-up.
@@ -131,7 +136,7 @@ gh issue edit <parent-number> --repo <org>/<repo> \
   --remove-label "<current status:*>" --add-label "<derived status:*>"
 ```
 
-**Safe default.** If rollup cannot be applied automatically (e.g. ambiguous required-set, GraphQL hierarchy unavailable, or a derived terminal that the env logic cannot resolve), this skill does **not** guess — it posts the derived suggestion as a comment and leaves the parent's label untouched. No unsafe transition is ever made.
+**Safe default.** If a successfully-read rollup cannot be applied automatically (e.g. ambiguous required-set or a derived terminal that the env logic cannot resolve), this skill does **not** guess — it posts the derived suggestion as a comment and leaves the parent's label untouched. A classifier/read failure is stricter: it writes neither label nor comment. No unsafe transition is ever made.
 
 ## Important Notes
 

package/plugins/lisa-cursor/skills/lisa-jam-access/SKILL.md

@@ -48,9 +48,9 @@ export PATH="$HOME/.local/bin:$PATH"
 read_jam_pat() {
   [ -n "${JAM_PAT:-}" ] && { echo "$JAM_PAT"; return; }
   #
-  # Ordered repo-first, ending at the plugin's own copy. Repo-relative rungs
-  # lead because a project that vendors the resolver has declared which copy it
-  # wants used, and that decision must survive this change untouched. The plugin
+  # Ordered across trusted machine-managed substrates, ending at the installed
+  # package. Checkout-local paths are deliberately absent: a familiar generated
+  # destination is still repository-controlled executable code. The plugin
   # rungs are the floor: `resolve-secret.mjs` ships beside this skill, so a rung
   # pointing at it is reachable from anywhere the plugin itself is installed.
   # Without one, a consumer repository that vendors none of the leading paths
@@ -59,12 +59,9 @@ read_jam_pat() {
   # lookups. This LADDER is identical in every skill that resolves a credential
   # and `credential-resolver-ladder` fails if any copy diverges. Only what
   # happens AFTER the ladder may differ between them.
-  local candidates=(
-    .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs
-    .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs
-    .opencode/skills/lisa/lisa-secrets-access/scripts/resolve-secret.mjs
-    .codex/skills/lisa/lisa-secrets-access/scripts/resolve-secret.mjs
-  )
+  # Execute only machine-managed plugin/package resolvers. Checkout-local
+  # candidates are repository-controlled code, not trusted merely by path.
+  local candidates=()
   if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
     candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
   fi
@@ -83,7 +80,7 @@ read_jam_pat() {
       local via_lisa
       via_lisa=$(node "$resolver" get JAM_PAT 2>/dev/null) \
         && [ -n "$via_lisa" ] && { echo "$via_lisa"; return; }
-      break
+      # Empty/error means this substrate had no answer; try the next trusted one.
     fi
   done
   # Name every path. A bare `return 1` sends the next reader hunting for a

package/plugins/lisa-cursor/skills/lisa-jira-journey/SKILL.md

@@ -35,6 +35,11 @@ Run the parser script to extract the Validation Journey from the JIRA ticket des
 python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
 ```
 
+The parser resolves Jira configuration from the checkout first: it searches
+`$CLAUDE_PROJECT_DIR/.lisa/jira-cli/.config.yml`, then the current directory and
+its parents, and only then falls back to `~/.config/.jira/.config.yml`. Do not
+copy project settings into the home-level file just to make this step work.
+
 The script outputs JSON with: `ticket`, `prerequisites`, `steps`, `viewports`, `assertions`.
 
 Note: `viewports` may be empty for TypeScript tickets — that is expected.