@codyswann/lisa 3.54.3 → 3.54.5

package/plugins/src/base/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/src/base/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")