@codyswann/lisa 4.22.8 → 4.22.10

package/plugins/lisa-copilot/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-copilot/rules/reference/base-rules.md

@@ -70,7 +70,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-copilot/rules/reference/config-resolution.md

@@ -899,19 +899,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
@@ -930,7 +921,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-copilot/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-copilot/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-copilot/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-copilot/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-copilot/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-copilot/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-copilot/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-copilot/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.

package/plugins/lisa-copilot/skills/lisa-jira-journey/scripts/parse-plan.py

@@ -41,9 +41,43 @@ from pathlib import Path
 LOCAL_EVIDENCE_PATTERN = re.compile(r'\[(SCREENSHOT|EVIDENCE):\s*([^\]]+)\]')
 
 
+def jira_config_candidates():
+    """Return project-first jira-cli config candidates without duplicates."""
+    roots = []
+    project_dir = os.environ.get("CLAUDE_PROJECT_DIR", "").strip()
+    if project_dir:
+        roots.append(Path(project_dir).expanduser().resolve())
+
+    current = Path.cwd().resolve()
+    roots.extend([current, *current.parents])
+
+    candidates = []
+    seen = set()
+    for root in roots:
+        candidate = root / ".lisa" / "jira-cli" / ".config.yml"
+        key = str(candidate)
+        if key not in seen:
+            candidates.append(candidate)
+            seen.add(key)
+
+    home_candidate = (Path.home() / ".config" / ".jira" / ".config.yml").resolve()
+    if str(home_candidate) not in seen:
+        candidates.append(home_candidate)
+    return candidates
+
+
+def resolve_jira_config_path():
+    """Resolve the first existing project config, then the home fallback."""
+    candidates = jira_config_candidates()
+    for candidate in candidates:
+        if candidate.exists():
+            return candidate
+    return candidates[-1]
+
+
 def get_jira_config():
-    """Read JIRA server and login from jira-cli config."""
-    config_path = Path.home() / ".config" / ".jira" / ".config.yml"
+    """Read JIRA server and login from the project-first jira-cli config."""
+    config_path = resolve_jira_config_path()
     if not config_path.exists():
         print(f"ERROR: jira-cli config not found at {config_path}", file=sys.stderr)
         sys.exit(1)

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

@@ -94,7 +94,7 @@ When invoked with `--rollup`, this skill **derives a parent/container ticket's s
 | else any child has **started** (`In Progress` / `Code Review`, or shipped to an env while a sibling has not) | `claimed` | `In Progress` |
 | else (children exist, none started) | — | unchanged — parent keeps its non-ready container status |
 
-- **Blocked dominates** — a single blocked child surfaces `Blocked` on the parent even while siblings 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** — a single blocked child surfaces `Blocked` on the parent even while siblings progress. It never says *which* child or *which kind* of hold; resolve and run the shared classifier exactly as `lisa-tracker-sync` specifies, then 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: do not transition the parent and do not post/update a rollup comment; report the failure, never an all-clear. 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. Apply native terminal resolution (the `leaf-only-lifecycle` Terminal native closure) only when the resolved env is the production `Done`, never at `On Dev`/`On Stg`.
 - **"Required" children only** — won't-do / optional children do not hold the parent open.
 - **Recursive** — an Epic reaches an env only when its Stories have themselves rolled up to at least that env; a Story reaches it only when its Sub-tasks have. Evaluate bottom-up.

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

@@ -85,22 +85,18 @@ All GraphQL calls use:
 read_linear_key() {
   [ -n "${LINEAR_API_KEY:-}" ] && { echo "$LINEAR_API_KEY"; return; }
 
-  # The ladder is ordered repo-first and ends 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 rungs are the floor: `resolve-secret.mjs`
+  # The ladder is ordered across trusted machine-managed substrates and ends 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 repo that vendors
   # none of the leading paths has no route to the key at all — which is what
   # every consumer of this skill in a `.opencode`-layout repository actually
   # hit, and why agents started improvising their own key lookups.
-  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
@@ -119,7 +115,7 @@ read_linear_key() {
       local via_lisa
       via_lisa=$(node "$resolver" get LINEAR_API_KEY 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
 

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

@@ -140,7 +140,7 @@ When the caller passes `--rollup`, this skill **derives a parent/container's wor
 | else any child has **started** (at the `claimed` state, at the `review` state where the project configures one, or shipped to an env while a sibling has not) | `claimed` | the configured `claimed` state |
 | else (children exist, none started) | — | unchanged — parent keeps its non-ready container state |
 
-- **Blocked dominates** — one blocked child surfaces `Blocked` on the parent even while siblings 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 child surfaces `Blocked` on the parent even while siblings progress. It never says *which* child or *which kind* of hold; resolve and run the shared classifier exactly as `lisa-tracker-sync` specifies, then 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: do not save parent state and do not post/update a rollup comment; report the failure, never an all-clear. 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 completion (moving the workflow `state` to Done) fires only when the resolved env is the production `Done`, never at `On Dev`/`On Stg`.
 - **"Required" children only** — won't-do / optional (e.g. `Canceled`) children do not hold the parent open.
 - **Recursive** — a Project reaches an env only when its Issues have themselves rolled up to at least that env. Evaluate bottom-up.

package/plugins/lisa-copilot/skills/lisa-nightly-lower-code-complexity/SKILL.md

@@ -25,8 +25,14 @@ The caller provides pre-computed context:
 9. Run the project's typecheck script with the provided package manager to catch type errors early — same reasoning as step 7, so `npm run typecheck` / `yarn typecheck` / `bun run typecheck`, falling back to `./node_modules/.bin/tsc --noEmit` rather than `npx tsc`:
 
    ```sh
+   case "$PACKAGE_MANAGER" in
+     npm)  runner=(npm run) ;;
+     yarn) runner=(yarn) ;;
+     bun)  runner=(bun run) ;;
+     *) echo "unsupported package manager: $PACKAGE_MANAGER" >&2; exit 2 ;;
+   esac
    status=0
-   bun run typecheck >tsc.log 2>&1 || status=$?
+   "${runner[@]}" typecheck >tsc.log 2>&1 || status=$?
    head -n 30 tsc.log; echo "exit=$status"
    ```
 

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

@@ -58,9 +58,9 @@ read_notion_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
@@ -69,12 +69,9 @@ read_notion_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
-  )
+  # 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
@@ -93,7 +90,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 /lisa:setup:notion

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

@@ -49,9 +49,9 @@ POSTHOG_HOST=${POSTHOG_HOST:-https://app.posthog.com}
 read_posthog_key() {
   [ -n "${POSTHOG_PERSONAL_API_KEY:-}" ] && { echo "$POSTHOG_PERSONAL_API_KEY"; 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
@@ -60,12 +60,9 @@ read_posthog_key() {
   # 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
@@ -84,7 +81,7 @@ read_posthog_key() {
       local via_lisa
       via_lisa=$(node "$resolver" get POSTHOG_PERSONAL_API_KEY 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