@codyswann/lisa 3.54.2 → 3.54.4

package/package.json

@@ -141,7 +141,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "3.54.2",
+  "version": "3.54.4",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

package/plugins/lisa/.codex-plugin/plugin.json

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

package/plugins/lisa/.codex-plugin/skills/lisa-linear-access/SKILL.md

@@ -84,9 +84,37 @@ All GraphQL calls use:
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
 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`
+  # 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
+  )
+  if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
+    candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  if [ -n "${PLUGIN_ROOT:-}" ]; then
+    candidates+=("$PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  # Last rung deliberately needs no environment variable: an agent that was
+  # never handed a plugin root still has the installed package to fall back on.
+  candidates+=(node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs)
+
   local resolver
-  for resolver in .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs \
-                  .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs; do
+  local tried=()
+  for resolver in "${candidates[@]}"; do
+    tried+=("$resolver")
     if [ -f "$resolver" ]; then
       local via_lisa
       via_lisa=$(node "$resolver" get LINEAR_API_KEY 2>/dev/null) \
@@ -94,6 +122,13 @@ read_linear_key() {
       break
     fi
   done
+
+  # Name every path. A bare `return 1` sends the next reader hunting for a
+  # resolver they cannot see the absence of; the enumeration turns that into a
+  # seconds-long diagnosis. Paths only — never any resolved value.
+  echo "Error: could not resolve LINEAR_API_KEY through lisa-secrets-access." >&2
+  echo "Tried, in order (relative paths are from $PWD):" >&2
+  printf '  %s\n' "${tried[@]}" >&2
   return 1
 }
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-linear/SKILL.md

@@ -92,10 +92,43 @@ read_linear_key() {  # $1=workspace slug
   # Preferred path: the single secrets chokepoint. It owns the one-store rule
   # and the surface ladder, so anything it can answer must not be read out of an
   # OS keychain here — a second reader is how the same credential ends up living
-  # in two places and drifting. Keep this identical to `linear-access`.
+  # in two places and drifting.
+  #
+  # The CANDIDATE LADDER below must stay identical to `linear-access`. What may
+  # differ is only what happens after it: `linear-access` has nowhere else to
+  # go and fails loudly, whereas this skill falls through to the legacy keychain
+  # rung. Stating the invariant as "the ladder" rather than "this function" is
+  # deliberate — the previous wording said to keep the whole thing identical,
+  # which is not achievable, and a rule that cannot be followed is a rule that
+  # gets ignored. That is exactly how this copy kept the two-rung ladder while
+  # `linear-access` grew to seven, leaving `/lisa:setup:linear` unable to reach
+  # a key that `lisa-linear-access` could read from the same repository.
+  #
+  # 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 this skill, so a rung pointing at it is reachable from anywhere the
+  # plugin itself is installed.
+  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
+  )
+  if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
+    candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  if [ -n "${PLUGIN_ROOT:-}" ]; then
+    candidates+=("$PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  # Last rung deliberately needs no environment variable: an agent that was
+  # never handed a plugin root still has the installed package to fall back on.
+  candidates+=(node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs)
+
   local resolver
-  for resolver in .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs \
-                  .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs; do
+  local tried=()
+  for resolver in "${candidates[@]}"; do
+    tried+=("$resolver")
     if [ -f "$resolver" ]; then
       local via_lisa
       via_lisa=$(node "$resolver" get LINEAR_API_KEY 2>/dev/null) \
@@ -106,15 +139,16 @@ read_linear_key() {  # $1=workspace slug
   # Legacy fallback: the OS keychain written by the guided flow below, for
   # projects that have not adopted a credentials provider. Reached only when the
   # chokepoint is absent or has no entry.
+  local from_keychain=""
   case "$(uname -s)" in
-    Darwin)  security find-generic-password -s lisa-linear -a "$ws" -w 2>/dev/null ;;
-    Linux)   command -v secret-tool >/dev/null && secret-tool lookup service lisa-linear account "$ws" 2>/dev/null ;;
+    Darwin)  from_keychain=$(security find-generic-password -s lisa-linear -a "$ws" -w 2>/dev/null) ;;
+    Linux)   command -v secret-tool >/dev/null && from_keychain=$(secret-tool lookup service lisa-linear account "$ws" 2>/dev/null) ;;
     MINGW*|MSYS*|CYGWIN*)
       # `cmdkey /generic ... /pass:` stores the secret in Windows Credential Manager, but
       # `cmdkey /list` never prints stored passwords (by design). Read the CredentialBlob
       # back via the Win32 CredRead API through PowerShell; pass the target name via an env
       # var to dodge nested quoting, and strip the CRLF powershell.exe appends.
-      LISA_CRED_TARGET="lisa-linear-${ws}" powershell.exe -NoProfile -NonInteractive -Command '
+      from_keychain=$(LISA_CRED_TARGET="lisa-linear-${ws}" powershell.exe -NoProfile -NonInteractive -Command '
 Add-Type -TypeDefinition @"
 using System;
 using System.Runtime.InteropServices;
@@ -140,8 +174,20 @@ public static class LisaCred {
   }
 }
 "@
-[LisaCred]::Read($env:LISA_CRED_TARGET)' 2>/dev/null | tr -d '\r' ;;
+[LisaCred]::Read($env:LISA_CRED_TARGET)' 2>/dev/null | tr -d '\r') ;;
   esac
+  [ -n "$from_keychain" ] && { echo "$from_keychain"; return; }
+
+  # Name every path, the same way `linear-access` does — the diagnostics are
+  # part of the parity, not decoration. A silent empty return sends the next
+  # reader hunting for a resolver they cannot see the absence of; the
+  # enumeration turns that into a seconds-long diagnosis. Paths and store
+  # coordinates only — never any resolved value, on any path.
+  echo "Error: could not resolve LINEAR_API_KEY 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-linear account=$ws" >&2
+  return 1
 }
 
 KEY=$(read_linear_key "$WORKSPACE")

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

@@ -53,8 +53,25 @@ import {
  * Standard git locations, checked in order so the executable comes from a
  * fixed, unwriteable directory rather than a PATH lookup. The bare "git"
  * fallback keeps unusual layouts (e.g. Windows git-bash) working.
+ *
+ * Order within that constraint is set by measurement, not by convention. On
+ * macOS `/usr/bin/git` is not git: it is Apple's `xcrun` shim, which locates a
+ * developer directory and re-executes the real binary there. Dispatching
+ * through it costs a **median 33 ms against 15 ms** for either
+ * developer-directory git, and **100 ms against 21 ms at p90** — randomized
+ * call order, fixed inter-call gaps, `git rev-parse --show-toplevel`, n=30 each
+ * (lisa#2898). The call does no work at all; the difference is the dispatch.
+ *
+ * The two entries promoted ahead of it are the developer-directory gits the
+ * shim itself re-executes. Both are `root:wheel` files in system locations, so
+ * this is the same trust class as `/usr/bin/git` and not a relaxation: the
+ * user-writable `/usr/local` and Homebrew entries stay behind it, exactly where
+ * they already were. Neither promoted path exists on Linux, so every CI runner
+ * resolves precisely what it resolved before.
  */
 const GIT_LOCATIONS = [
+  "/Library/Developer/CommandLineTools/usr/bin/git",
+  "/Applications/Xcode.app/Contents/Developer/usr/bin/git",
   "/usr/bin/git",
   "/usr/local/bin/git",
   "/opt/homebrew/bin/git",

package/plugins/lisa/scripts/plugin-sync-explain.mjs

@@ -33,7 +33,33 @@ export const PLUGIN_SYNC_CLASSIFICATIONS = [
 const PLUGINS_DIR = "plugins";
 const SOURCE_ROOT = "plugins/src";
 const MARKETPLACE = ".claude-plugin/marketplace.json";
-const GIT_BIN = "/usr/bin/git";
+/**
+ * Fixed absolute git locations, tried in order rather than a bare command name
+ * so a writeable directory early on `PATH` cannot decide which binary runs.
+ *
+ * Order within that constraint is set by measurement, not by convention. On
+ * macOS `/usr/bin/git` is not git: it is Apple's `xcrun` shim, which locates a
+ * developer directory and re-executes the real binary there. Dispatching
+ * through it costs a **median 33 ms against 15 ms** for either
+ * developer-directory git, and **100 ms against 21 ms at p90** — randomized
+ * call order, fixed inter-call gaps, `git rev-parse --show-toplevel`, n=30 each
+ * (lisa#2898). The call does no work at all; the difference is the dispatch.
+ *
+ * The two entries promoted ahead of it are the developer-directory gits the
+ * shim itself re-executes. Both are `root:wheel` files in system locations, so
+ * this is the same trust class as `/usr/bin/git` and not a relaxation: the
+ * user-writable `/usr/local` and Homebrew entries stay behind it, exactly where
+ * they already were. Neither promoted path exists on Linux, so every CI runner
+ * resolves precisely what it resolved before.
+ */
+const GIT_LOCATIONS = [
+  "/Library/Developer/CommandLineTools/usr/bin/git",
+  "/Applications/Xcode.app/Contents/Developer/usr/bin/git",
+  "/usr/bin/git",
+  "/usr/local/bin/git",
+  "/opt/homebrew/bin/git",
+];
+const GIT_BIN = GIT_LOCATIONS.find(candidate => existsSync(candidate)) ?? "git";
 
 /**
  * @typedef {{

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

@@ -84,9 +84,37 @@ All GraphQL calls use:
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
 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`
+  # 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
+  )
+  if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
+    candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  if [ -n "${PLUGIN_ROOT:-}" ]; then
+    candidates+=("$PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  # Last rung deliberately needs no environment variable: an agent that was
+  # never handed a plugin root still has the installed package to fall back on.
+  candidates+=(node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs)
+
   local resolver
-  for resolver in .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs \
-                  .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs; do
+  local tried=()
+  for resolver in "${candidates[@]}"; do
+    tried+=("$resolver")
     if [ -f "$resolver" ]; then
       local via_lisa
       via_lisa=$(node "$resolver" get LINEAR_API_KEY 2>/dev/null) \
@@ -94,6 +122,13 @@ read_linear_key() {
       break
     fi
   done
+
+  # Name every path. A bare `return 1` sends the next reader hunting for a
+  # resolver they cannot see the absence of; the enumeration turns that into a
+  # seconds-long diagnosis. Paths only — never any resolved value.
+  echo "Error: could not resolve LINEAR_API_KEY through lisa-secrets-access." >&2
+  echo "Tried, in order (relative paths are from $PWD):" >&2
+  printf '  %s\n' "${tried[@]}" >&2
   return 1
 }
 

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

@@ -92,10 +92,43 @@ read_linear_key() {  # $1=workspace slug
   # Preferred path: the single secrets chokepoint. It owns the one-store rule
   # and the surface ladder, so anything it can answer must not be read out of an
   # OS keychain here — a second reader is how the same credential ends up living
-  # in two places and drifting. Keep this identical to `linear-access`.
+  # in two places and drifting.
+  #
+  # The CANDIDATE LADDER below must stay identical to `linear-access`. What may
+  # differ is only what happens after it: `linear-access` has nowhere else to
+  # go and fails loudly, whereas this skill falls through to the legacy keychain
+  # rung. Stating the invariant as "the ladder" rather than "this function" is
+  # deliberate — the previous wording said to keep the whole thing identical,
+  # which is not achievable, and a rule that cannot be followed is a rule that
+  # gets ignored. That is exactly how this copy kept the two-rung ladder while
+  # `linear-access` grew to seven, leaving `/lisa:setup:linear` unable to reach
+  # a key that `lisa-linear-access` could read from the same repository.
+  #
+  # 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 this skill, so a rung pointing at it is reachable from anywhere the
+  # plugin itself is installed.
+  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
+  )
+  if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
+    candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  if [ -n "${PLUGIN_ROOT:-}" ]; then
+    candidates+=("$PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  # Last rung deliberately needs no environment variable: an agent that was
+  # never handed a plugin root still has the installed package to fall back on.
+  candidates+=(node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs)
+
   local resolver
-  for resolver in .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs \
-                  .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs; do
+  local tried=()
+  for resolver in "${candidates[@]}"; do
+    tried+=("$resolver")
     if [ -f "$resolver" ]; then
       local via_lisa
       via_lisa=$(node "$resolver" get LINEAR_API_KEY 2>/dev/null) \
@@ -106,15 +139,16 @@ read_linear_key() {  # $1=workspace slug
   # Legacy fallback: the OS keychain written by the guided flow below, for
   # projects that have not adopted a credentials provider. Reached only when the
   # chokepoint is absent or has no entry.
+  local from_keychain=""
   case "$(uname -s)" in
-    Darwin)  security find-generic-password -s lisa-linear -a "$ws" -w 2>/dev/null ;;
-    Linux)   command -v secret-tool >/dev/null && secret-tool lookup service lisa-linear account "$ws" 2>/dev/null ;;
+    Darwin)  from_keychain=$(security find-generic-password -s lisa-linear -a "$ws" -w 2>/dev/null) ;;
+    Linux)   command -v secret-tool >/dev/null && from_keychain=$(secret-tool lookup service lisa-linear account "$ws" 2>/dev/null) ;;
     MINGW*|MSYS*|CYGWIN*)
       # `cmdkey /generic ... /pass:` stores the secret in Windows Credential Manager, but
       # `cmdkey /list` never prints stored passwords (by design). Read the CredentialBlob
       # back via the Win32 CredRead API through PowerShell; pass the target name via an env
       # var to dodge nested quoting, and strip the CRLF powershell.exe appends.
-      LISA_CRED_TARGET="lisa-linear-${ws}" powershell.exe -NoProfile -NonInteractive -Command '
+      from_keychain=$(LISA_CRED_TARGET="lisa-linear-${ws}" powershell.exe -NoProfile -NonInteractive -Command '
 Add-Type -TypeDefinition @"
 using System;
 using System.Runtime.InteropServices;
@@ -140,8 +174,20 @@ public static class LisaCred {
   }
 }
 "@
-[LisaCred]::Read($env:LISA_CRED_TARGET)' 2>/dev/null | tr -d '\r' ;;
+[LisaCred]::Read($env:LISA_CRED_TARGET)' 2>/dev/null | tr -d '\r') ;;
   esac
+  [ -n "$from_keychain" ] && { echo "$from_keychain"; return; }
+
+  # Name every path, the same way `linear-access` does — the diagnostics are
+  # part of the parity, not decoration. A silent empty return sends the next
+  # reader hunting for a resolver they cannot see the absence of; the
+  # enumeration turns that into a seconds-long diagnosis. Paths and store
+  # coordinates only — never any resolved value, on any path.
+  echo "Error: could not resolve LINEAR_API_KEY 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-linear account=$ws" >&2
+  return 1
 }
 
 KEY=$(read_linear_key "$WORKSPACE")

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/scripts/plugin-sync-explain.mjs

@@ -33,7 +33,33 @@ export const PLUGIN_SYNC_CLASSIFICATIONS = [
 const PLUGINS_DIR = "plugins";
 const SOURCE_ROOT = "plugins/src";
 const MARKETPLACE = ".claude-plugin/marketplace.json";
-const GIT_BIN = "/usr/bin/git";
+/**
+ * Fixed absolute git locations, tried in order rather than a bare command name
+ * so a writeable directory early on `PATH` cannot decide which binary runs.
+ *
+ * Order within that constraint is set by measurement, not by convention. On
+ * macOS `/usr/bin/git` is not git: it is Apple's `xcrun` shim, which locates a
+ * developer directory and re-executes the real binary there. Dispatching
+ * through it costs a **median 33 ms against 15 ms** for either
+ * developer-directory git, and **100 ms against 21 ms at p90** — randomized
+ * call order, fixed inter-call gaps, `git rev-parse --show-toplevel`, n=30 each
+ * (lisa#2898). The call does no work at all; the difference is the dispatch.
+ *
+ * The two entries promoted ahead of it are the developer-directory gits the
+ * shim itself re-executes. Both are `root:wheel` files in system locations, so
+ * this is the same trust class as `/usr/bin/git` and not a relaxation: the
+ * user-writable `/usr/local` and Homebrew entries stay behind it, exactly where
+ * they already were. Neither promoted path exists on Linux, so every CI runner
+ * resolves precisely what it resolved before.
+ */
+const GIT_LOCATIONS = [
+  "/Library/Developer/CommandLineTools/usr/bin/git",
+  "/Applications/Xcode.app/Contents/Developer/usr/bin/git",
+  "/usr/bin/git",
+  "/usr/local/bin/git",
+  "/opt/homebrew/bin/git",
+];
+const GIT_BIN = GIT_LOCATIONS.find(candidate => existsSync(candidate)) ?? "git";
 
 /**
  * @typedef {{

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

@@ -84,9 +84,37 @@ All GraphQL calls use:
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
 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`
+  # 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
+  )
+  if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
+    candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  if [ -n "${PLUGIN_ROOT:-}" ]; then
+    candidates+=("$PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  # Last rung deliberately needs no environment variable: an agent that was
+  # never handed a plugin root still has the installed package to fall back on.
+  candidates+=(node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs)
+
   local resolver
-  for resolver in .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs \
-                  .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs; do
+  local tried=()
+  for resolver in "${candidates[@]}"; do
+    tried+=("$resolver")
     if [ -f "$resolver" ]; then
       local via_lisa
       via_lisa=$(node "$resolver" get LINEAR_API_KEY 2>/dev/null) \
@@ -94,6 +122,13 @@ read_linear_key() {
       break
     fi
   done
+
+  # Name every path. A bare `return 1` sends the next reader hunting for a
+  # resolver they cannot see the absence of; the enumeration turns that into a
+  # seconds-long diagnosis. Paths only — never any resolved value.
+  echo "Error: could not resolve LINEAR_API_KEY through lisa-secrets-access." >&2
+  echo "Tried, in order (relative paths are from $PWD):" >&2
+  printf '  %s\n' "${tried[@]}" >&2
   return 1
 }
 

package/plugins/lisa-agy/skills/lisa-setup-linear/SKILL.md

@@ -92,10 +92,43 @@ read_linear_key() {  # $1=workspace slug
   # Preferred path: the single secrets chokepoint. It owns the one-store rule
   # and the surface ladder, so anything it can answer must not be read out of an
   # OS keychain here — a second reader is how the same credential ends up living
-  # in two places and drifting. Keep this identical to `linear-access`.
+  # in two places and drifting.
+  #
+  # The CANDIDATE LADDER below must stay identical to `linear-access`. What may
+  # differ is only what happens after it: `linear-access` has nowhere else to
+  # go and fails loudly, whereas this skill falls through to the legacy keychain
+  # rung. Stating the invariant as "the ladder" rather than "this function" is
+  # deliberate — the previous wording said to keep the whole thing identical,
+  # which is not achievable, and a rule that cannot be followed is a rule that
+  # gets ignored. That is exactly how this copy kept the two-rung ladder while
+  # `linear-access` grew to seven, leaving `/lisa:setup:linear` unable to reach
+  # a key that `lisa-linear-access` could read from the same repository.
+  #
+  # 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 this skill, so a rung pointing at it is reachable from anywhere the
+  # plugin itself is installed.
+  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
+  )
+  if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
+    candidates+=("$CLAUDE_PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  if [ -n "${PLUGIN_ROOT:-}" ]; then
+    candidates+=("$PLUGIN_ROOT/skills/lisa-secrets-access/scripts/resolve-secret.mjs")
+  fi
+  # Last rung deliberately needs no environment variable: an agent that was
+  # never handed a plugin root still has the installed package to fall back on.
+  candidates+=(node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs)
+
   local resolver
-  for resolver in .claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs \
-                  .agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs; do
+  local tried=()
+  for resolver in "${candidates[@]}"; do
+    tried+=("$resolver")
     if [ -f "$resolver" ]; then
       local via_lisa
       via_lisa=$(node "$resolver" get LINEAR_API_KEY 2>/dev/null) \
@@ -106,15 +139,16 @@ read_linear_key() {  # $1=workspace slug
   # Legacy fallback: the OS keychain written by the guided flow below, for
   # projects that have not adopted a credentials provider. Reached only when the
   # chokepoint is absent or has no entry.
+  local from_keychain=""
   case "$(uname -s)" in
-    Darwin)  security find-generic-password -s lisa-linear -a "$ws" -w 2>/dev/null ;;
-    Linux)   command -v secret-tool >/dev/null && secret-tool lookup service lisa-linear account "$ws" 2>/dev/null ;;
+    Darwin)  from_keychain=$(security find-generic-password -s lisa-linear -a "$ws" -w 2>/dev/null) ;;
+    Linux)   command -v secret-tool >/dev/null && from_keychain=$(secret-tool lookup service lisa-linear account "$ws" 2>/dev/null) ;;
     MINGW*|MSYS*|CYGWIN*)
       # `cmdkey /generic ... /pass:` stores the secret in Windows Credential Manager, but
       # `cmdkey /list` never prints stored passwords (by design). Read the CredentialBlob
       # back via the Win32 CredRead API through PowerShell; pass the target name via an env
       # var to dodge nested quoting, and strip the CRLF powershell.exe appends.
-      LISA_CRED_TARGET="lisa-linear-${ws}" powershell.exe -NoProfile -NonInteractive -Command '
+      from_keychain=$(LISA_CRED_TARGET="lisa-linear-${ws}" powershell.exe -NoProfile -NonInteractive -Command '
 Add-Type -TypeDefinition @"
 using System;
 using System.Runtime.InteropServices;
@@ -140,8 +174,20 @@ public static class LisaCred {
   }
 }
 "@
-[LisaCred]::Read($env:LISA_CRED_TARGET)' 2>/dev/null | tr -d '\r' ;;
+[LisaCred]::Read($env:LISA_CRED_TARGET)' 2>/dev/null | tr -d '\r') ;;
   esac
+  [ -n "$from_keychain" ] && { echo "$from_keychain"; return; }
+
+  # Name every path, the same way `linear-access` does — the diagnostics are
+  # part of the parity, not decoration. A silent empty return sends the next
+  # reader hunting for a resolver they cannot see the absence of; the
+  # enumeration turns that into a seconds-long diagnosis. Paths and store
+  # coordinates only — never any resolved value, on any path.
+  echo "Error: could not resolve LINEAR_API_KEY 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-linear account=$ws" >&2
+  return 1
 }
 
 KEY=$(read_linear_key "$WORKSPACE")

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.54.2",
+  "version": "3.54.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.54.2",
+  "version": "3.54.4",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.54.2",
+  "version": "3.54.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.54.2",
+  "version": "3.54.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.54.2",
+  "version": "3.54.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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