@codyswann/lisa 4.27.0 → 4.27.1

package/dist/core/nightly-e2e-guard-behavior-certificate.js

@@ -20,9 +20,9 @@ export const NIGHTLY_E2E_GUARD_BEHAVIOR_CERTIFICATES = Object.freeze({
     }),
     "312e8962e21be2f3c6c6c0235b0c6159b8dc39425508b4965c7df87fb1333380": Object.freeze({
         contractVersion: "1.9.0",
-        packageVersions: Object.freeze(["4.27.0"]),
+        packageVersions: Object.freeze(["4.27.1"]),
         provenances: Object.freeze([
-            "workspace package @codyswann/lisa@4.27.0 (typescript/copy-overwrite/scripts/check-nightly-e2e-health.mjs)",
+            "workspace package @codyswann/lisa@4.27.1 (typescript/copy-overwrite/scripts/check-nightly-e2e-health.mjs)",
         ]),
     }),
     "898ee0247806c7aa6e98328662d80bcff22ff067999298865462a58daef8bb22": Object.freeze({

package/dist/core/upstream-evidence-manifest.js

@@ -589,7 +589,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-jsdoc-best-practices/SKILL.md": "7cf0729966ac0afcab6e2c043f192772a9e9e7c72fae61e55b300e97308f970e",
     "plugins/src/base/skills/lisa-kane-browser/SKILL.md": "e082517cb42f437eeb22b3935aa0fef09299874736e55184e88d2b64f7860a7d",
     "plugins/src/base/skills/lisa-learnings-audit/SKILL.md": "98a1c4916f376a3f85008c43a4dde033c374ed0a6111a8094f72296973c5d21b",
-    "plugins/src/base/skills/lisa-linear-access/SKILL.md": "b4d1121a7d1938ccd1f24516eec12955bd6131523337bc1432ed7152750b9260",
+    "plugins/src/base/skills/lisa-linear-access/SKILL.md": "f6644b11ad2d730795471acf826e52b284e310de70923b65a78f14b58242cf15",
     "plugins/src/base/skills/lisa-linear-add-journey/SKILL.md": "0a9f2bd0e19fbaa4794537e436c22748c7621644253a91923d84bc77ca43f793",
     "plugins/src/base/skills/lisa-linear-build-intake/SKILL.md": "9c2d59a903ef2778ccf249136d8b561a6c381596631b6d35e6f469fd74497cee",
     "plugins/src/base/skills/lisa-linear-claim/SKILL.md": "d3fee9a0435e93402be53769313f971c77b847521826fbaee0d19a0bdbc34b93",

package/package.json

@@ -161,7 +161,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -305,6 +305,6 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "f6c60240380f0355137d58b67b745dfda9dcf06e",
-  "gitHead": "f6c60240380f0355137d58b67b745dfda9dcf06e"
+  "lisaReleaseCommit": "eafbdc0e2ad81b0b4a7a64024475332e0a06df95",
+  "gitHead": "eafbdc0e2ad81b0b4a7a64024475332e0a06df95"
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "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": "4.27.0",
+  "version": "4.27.1",
   "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

@@ -82,9 +82,43 @@ All GraphQL calls use:
 # or AWS has no path to the key at all — the ladder stopped at rung one, which
 # is also what left `/lisa:setup:linear` reading an OS keychain directly with
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
-read_linear_key() {
+read_linear_key() {  # $1=workspace slug; defaults to $WORKSPACE read from config
   [ -n "${LINEAR_API_KEY:-}" ] && { echo "$LINEAR_API_KEY"; return; }
 
+  # Per-workspace rung, matching `atlassian-access` and `notion-access` — and
+  # matching what `setup-linear` has always told the reader to export. This
+  # copy lacked it, so a key set the documented way validated during setup (the
+  # setup skill reads it) and was then ignored by every real Linear call, which
+  # silently fell through to whatever other credential it found. Nothing
+  # errored; the operation just ran as a different identity. The rung is also
+  # load-bearing headlessly: `analyze-claude-remote` reports Linear's env as
+  # `LINEAR_API_KEY` "or per-account `LINEAR_API_KEY_<ws-slug>`", and
+  # `generate-claude-remote-build-script` emits that suffixed name into cloud
+  # routine env templates — so a routine provisioned from those skills had no
+  # reachable key at all.
+  #
+  # An unset variable changes nothing: an empty workspace skips the rung
+  # entirely and the ladder below runs exactly as it did before.
+  local ws="${1:-${WORKSPACE:-}}"
+  if [ -n "$ws" ]; then
+    local slug; slug=$(echo "$ws" | tr '[:upper:]-' '[:lower:]_')
+    # Constrain the slug before it reaches `${!varname}`. Indirect expansion
+    # evaluates an array subscript, so a workspace carrying `[$(...)]` would
+    # RUN that command here — and `tr` above only folds case and dashes, it
+    # strips nothing. The slug's source is `.lisa.config.json`, which is
+    # repository-controlled input: exactly what this ladder already refuses to
+    # trust when it picks resolvers. A real workspace slug is lowercase
+    # alphanumerics and underscores, so anything else is not a slug we should
+    # be expanding — skip the rung and fall through rather than guessing.
+    case "$slug" in
+      ""|*[!a-z0-9_]*) ;;
+      *)
+        local varname="LINEAR_API_KEY_${slug}"
+        [ -n "${!varname:-}" ] && { echo "${!varname}"; return; }
+        ;;
+    esac
+  fi
+
   # 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
@@ -132,9 +166,10 @@ linear_graphql() {
   local query="$1"
   local variables="${2:-{}}"
   local key
-  key=$(read_linear_key) || {
-    echo "Error: no Linear API key. Set LINEAR_API_KEY, or store it as" >&2
-    echo "LINEAR_API_KEY in this project's secrets provider." >&2
+  key=$(read_linear_key "${WORKSPACE:-}") || {
+    echo "Error: no Linear API key. Set LINEAR_API_KEY (or the per-workspace" >&2
+    echo "LINEAR_API_KEY_<slug>), or store it as LINEAR_API_KEY in this" >&2
+    echo "project's secrets provider." >&2
     return 1
   }
   jq -n --arg query "$query" --argjson variables "$variables" \

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

@@ -82,9 +82,43 @@ All GraphQL calls use:
 # or AWS has no path to the key at all — the ladder stopped at rung one, which
 # is also what left `/lisa:setup:linear` reading an OS keychain directly with
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
-read_linear_key() {
+read_linear_key() {  # $1=workspace slug; defaults to $WORKSPACE read from config
   [ -n "${LINEAR_API_KEY:-}" ] && { echo "$LINEAR_API_KEY"; return; }
 
+  # Per-workspace rung, matching `atlassian-access` and `notion-access` — and
+  # matching what `setup-linear` has always told the reader to export. This
+  # copy lacked it, so a key set the documented way validated during setup (the
+  # setup skill reads it) and was then ignored by every real Linear call, which
+  # silently fell through to whatever other credential it found. Nothing
+  # errored; the operation just ran as a different identity. The rung is also
+  # load-bearing headlessly: `analyze-claude-remote` reports Linear's env as
+  # `LINEAR_API_KEY` "or per-account `LINEAR_API_KEY_<ws-slug>`", and
+  # `generate-claude-remote-build-script` emits that suffixed name into cloud
+  # routine env templates — so a routine provisioned from those skills had no
+  # reachable key at all.
+  #
+  # An unset variable changes nothing: an empty workspace skips the rung
+  # entirely and the ladder below runs exactly as it did before.
+  local ws="${1:-${WORKSPACE:-}}"
+  if [ -n "$ws" ]; then
+    local slug; slug=$(echo "$ws" | tr '[:upper:]-' '[:lower:]_')
+    # Constrain the slug before it reaches `${!varname}`. Indirect expansion
+    # evaluates an array subscript, so a workspace carrying `[$(...)]` would
+    # RUN that command here — and `tr` above only folds case and dashes, it
+    # strips nothing. The slug's source is `.lisa.config.json`, which is
+    # repository-controlled input: exactly what this ladder already refuses to
+    # trust when it picks resolvers. A real workspace slug is lowercase
+    # alphanumerics and underscores, so anything else is not a slug we should
+    # be expanding — skip the rung and fall through rather than guessing.
+    case "$slug" in
+      ""|*[!a-z0-9_]*) ;;
+      *)
+        local varname="LINEAR_API_KEY_${slug}"
+        [ -n "${!varname:-}" ] && { echo "${!varname}"; return; }
+        ;;
+    esac
+  fi
+
   # 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
@@ -132,9 +166,10 @@ linear_graphql() {
   local query="$1"
   local variables="${2:-{}}"
   local key
-  key=$(read_linear_key) || {
-    echo "Error: no Linear API key. Set LINEAR_API_KEY, or store it as" >&2
-    echo "LINEAR_API_KEY in this project's secrets provider." >&2
+  key=$(read_linear_key "${WORKSPACE:-}") || {
+    echo "Error: no Linear API key. Set LINEAR_API_KEY (or the per-workspace" >&2
+    echo "LINEAR_API_KEY_<slug>), or store it as LINEAR_API_KEY in this" >&2
+    echo "project's secrets provider." >&2
     return 1
   }
   jq -n --arg query "$query" --argjson variables "$variables" \

package/plugins/lisa-agy/plugin.json

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

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

@@ -82,9 +82,43 @@ All GraphQL calls use:
 # or AWS has no path to the key at all — the ladder stopped at rung one, which
 # is also what left `/lisa:setup:linear` reading an OS keychain directly with
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
-read_linear_key() {
+read_linear_key() {  # $1=workspace slug; defaults to $WORKSPACE read from config
   [ -n "${LINEAR_API_KEY:-}" ] && { echo "$LINEAR_API_KEY"; return; }
 
+  # Per-workspace rung, matching `atlassian-access` and `notion-access` — and
+  # matching what `setup-linear` has always told the reader to export. This
+  # copy lacked it, so a key set the documented way validated during setup (the
+  # setup skill reads it) and was then ignored by every real Linear call, which
+  # silently fell through to whatever other credential it found. Nothing
+  # errored; the operation just ran as a different identity. The rung is also
+  # load-bearing headlessly: `analyze-claude-remote` reports Linear's env as
+  # `LINEAR_API_KEY` "or per-account `LINEAR_API_KEY_<ws-slug>`", and
+  # `generate-claude-remote-build-script` emits that suffixed name into cloud
+  # routine env templates — so a routine provisioned from those skills had no
+  # reachable key at all.
+  #
+  # An unset variable changes nothing: an empty workspace skips the rung
+  # entirely and the ladder below runs exactly as it did before.
+  local ws="${1:-${WORKSPACE:-}}"
+  if [ -n "$ws" ]; then
+    local slug; slug=$(echo "$ws" | tr '[:upper:]-' '[:lower:]_')
+    # Constrain the slug before it reaches `${!varname}`. Indirect expansion
+    # evaluates an array subscript, so a workspace carrying `[$(...)]` would
+    # RUN that command here — and `tr` above only folds case and dashes, it
+    # strips nothing. The slug's source is `.lisa.config.json`, which is
+    # repository-controlled input: exactly what this ladder already refuses to
+    # trust when it picks resolvers. A real workspace slug is lowercase
+    # alphanumerics and underscores, so anything else is not a slug we should
+    # be expanding — skip the rung and fall through rather than guessing.
+    case "$slug" in
+      ""|*[!a-z0-9_]*) ;;
+      *)
+        local varname="LINEAR_API_KEY_${slug}"
+        [ -n "${!varname:-}" ] && { echo "${!varname}"; return; }
+        ;;
+    esac
+  fi
+
   # 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
@@ -132,9 +166,10 @@ linear_graphql() {
   local query="$1"
   local variables="${2:-{}}"
   local key
-  key=$(read_linear_key) || {
-    echo "Error: no Linear API key. Set LINEAR_API_KEY, or store it as" >&2
-    echo "LINEAR_API_KEY in this project's secrets provider." >&2
+  key=$(read_linear_key "${WORKSPACE:-}") || {
+    echo "Error: no Linear API key. Set LINEAR_API_KEY (or the per-workspace" >&2
+    echo "LINEAR_API_KEY_<slug>), or store it as LINEAR_API_KEY in this" >&2
+    echo "project's secrets provider." >&2
     return 1
   }
   jq -n --arg query "$query" --argjson variables "$variables" \

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "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": "4.27.0",
+  "version": "4.27.1",
   "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": "4.27.0",
+  "version": "4.27.1",
   "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": "4.27.0",
+  "version": "4.27.1",
   "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": "4.27.0",
+  "version": "4.27.1",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -82,9 +82,43 @@ All GraphQL calls use:
 # or AWS has no path to the key at all — the ladder stopped at rung one, which
 # is also what left `/lisa:setup:linear` reading an OS keychain directly with
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
-read_linear_key() {
+read_linear_key() {  # $1=workspace slug; defaults to $WORKSPACE read from config
   [ -n "${LINEAR_API_KEY:-}" ] && { echo "$LINEAR_API_KEY"; return; }
 
+  # Per-workspace rung, matching `atlassian-access` and `notion-access` — and
+  # matching what `setup-linear` has always told the reader to export. This
+  # copy lacked it, so a key set the documented way validated during setup (the
+  # setup skill reads it) and was then ignored by every real Linear call, which
+  # silently fell through to whatever other credential it found. Nothing
+  # errored; the operation just ran as a different identity. The rung is also
+  # load-bearing headlessly: `analyze-claude-remote` reports Linear's env as
+  # `LINEAR_API_KEY` "or per-account `LINEAR_API_KEY_<ws-slug>`", and
+  # `generate-claude-remote-build-script` emits that suffixed name into cloud
+  # routine env templates — so a routine provisioned from those skills had no
+  # reachable key at all.
+  #
+  # An unset variable changes nothing: an empty workspace skips the rung
+  # entirely and the ladder below runs exactly as it did before.
+  local ws="${1:-${WORKSPACE:-}}"
+  if [ -n "$ws" ]; then
+    local slug; slug=$(echo "$ws" | tr '[:upper:]-' '[:lower:]_')
+    # Constrain the slug before it reaches `${!varname}`. Indirect expansion
+    # evaluates an array subscript, so a workspace carrying `[$(...)]` would
+    # RUN that command here — and `tr` above only folds case and dashes, it
+    # strips nothing. The slug's source is `.lisa.config.json`, which is
+    # repository-controlled input: exactly what this ladder already refuses to
+    # trust when it picks resolvers. A real workspace slug is lowercase
+    # alphanumerics and underscores, so anything else is not a slug we should
+    # be expanding — skip the rung and fall through rather than guessing.
+    case "$slug" in
+      ""|*[!a-z0-9_]*) ;;
+      *)
+        local varname="LINEAR_API_KEY_${slug}"
+        [ -n "${!varname:-}" ] && { echo "${!varname}"; return; }
+        ;;
+    esac
+  fi
+
   # 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
@@ -132,9 +166,10 @@ linear_graphql() {
   local query="$1"
   local variables="${2:-{}}"
   local key
-  key=$(read_linear_key) || {
-    echo "Error: no Linear API key. Set LINEAR_API_KEY, or store it as" >&2
-    echo "LINEAR_API_KEY in this project's secrets provider." >&2
+  key=$(read_linear_key "${WORKSPACE:-}") || {
+    echo "Error: no Linear API key. Set LINEAR_API_KEY (or the per-workspace" >&2
+    echo "LINEAR_API_KEY_<slug>), or store it as LINEAR_API_KEY in this" >&2
+    echo "project's secrets provider." >&2
     return 1
   }
   jq -n --arg query "$query" --argjson variables "$variables" \

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

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

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

@@ -82,9 +82,43 @@ All GraphQL calls use:
 # or AWS has no path to the key at all — the ladder stopped at rung one, which
 # is also what left `/lisa:setup:linear` reading an OS keychain directly with
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
-read_linear_key() {
+read_linear_key() {  # $1=workspace slug; defaults to $WORKSPACE read from config
   [ -n "${LINEAR_API_KEY:-}" ] && { echo "$LINEAR_API_KEY"; return; }
 
+  # Per-workspace rung, matching `atlassian-access` and `notion-access` — and
+  # matching what `setup-linear` has always told the reader to export. This
+  # copy lacked it, so a key set the documented way validated during setup (the
+  # setup skill reads it) and was then ignored by every real Linear call, which
+  # silently fell through to whatever other credential it found. Nothing
+  # errored; the operation just ran as a different identity. The rung is also
+  # load-bearing headlessly: `analyze-claude-remote` reports Linear's env as
+  # `LINEAR_API_KEY` "or per-account `LINEAR_API_KEY_<ws-slug>`", and
+  # `generate-claude-remote-build-script` emits that suffixed name into cloud
+  # routine env templates — so a routine provisioned from those skills had no
+  # reachable key at all.
+  #
+  # An unset variable changes nothing: an empty workspace skips the rung
+  # entirely and the ladder below runs exactly as it did before.
+  local ws="${1:-${WORKSPACE:-}}"
+  if [ -n "$ws" ]; then
+    local slug; slug=$(echo "$ws" | tr '[:upper:]-' '[:lower:]_')
+    # Constrain the slug before it reaches `${!varname}`. Indirect expansion
+    # evaluates an array subscript, so a workspace carrying `[$(...)]` would
+    # RUN that command here — and `tr` above only folds case and dashes, it
+    # strips nothing. The slug's source is `.lisa.config.json`, which is
+    # repository-controlled input: exactly what this ladder already refuses to
+    # trust when it picks resolvers. A real workspace slug is lowercase
+    # alphanumerics and underscores, so anything else is not a slug we should
+    # be expanding — skip the rung and fall through rather than guessing.
+    case "$slug" in
+      ""|*[!a-z0-9_]*) ;;
+      *)
+        local varname="LINEAR_API_KEY_${slug}"
+        [ -n "${!varname:-}" ] && { echo "${!varname}"; return; }
+        ;;
+    esac
+  fi
+
   # 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
@@ -132,9 +166,10 @@ linear_graphql() {
   local query="$1"
   local variables="${2:-{}}"
   local key
-  key=$(read_linear_key) || {
-    echo "Error: no Linear API key. Set LINEAR_API_KEY, or store it as" >&2
-    echo "LINEAR_API_KEY in this project's secrets provider." >&2
+  key=$(read_linear_key "${WORKSPACE:-}") || {
+    echo "Error: no Linear API key. Set LINEAR_API_KEY (or the per-workspace" >&2
+    echo "LINEAR_API_KEY_<slug>), or store it as LINEAR_API_KEY in this" >&2
+    echo "project's secrets provider." >&2
     return 1
   }
   jq -n --arg query "$query" --argjson variables "$variables" \

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.27.0",
+  "version": "4.27.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -82,9 +82,43 @@ All GraphQL calls use:
 # or AWS has no path to the key at all — the ladder stopped at rung one, which
 # is also what left `/lisa:setup:linear` reading an OS keychain directly with
 # nowhere to migrate to. Mirrors `atlassian-access` and `notion-access`.
-read_linear_key() {
+read_linear_key() {  # $1=workspace slug; defaults to $WORKSPACE read from config
   [ -n "${LINEAR_API_KEY:-}" ] && { echo "$LINEAR_API_KEY"; return; }
 
+  # Per-workspace rung, matching `atlassian-access` and `notion-access` — and
+  # matching what `setup-linear` has always told the reader to export. This
+  # copy lacked it, so a key set the documented way validated during setup (the
+  # setup skill reads it) and was then ignored by every real Linear call, which
+  # silently fell through to whatever other credential it found. Nothing
+  # errored; the operation just ran as a different identity. The rung is also
+  # load-bearing headlessly: `analyze-claude-remote` reports Linear's env as
+  # `LINEAR_API_KEY` "or per-account `LINEAR_API_KEY_<ws-slug>`", and
+  # `generate-claude-remote-build-script` emits that suffixed name into cloud
+  # routine env templates — so a routine provisioned from those skills had no
+  # reachable key at all.
+  #
+  # An unset variable changes nothing: an empty workspace skips the rung
+  # entirely and the ladder below runs exactly as it did before.
+  local ws="${1:-${WORKSPACE:-}}"
+  if [ -n "$ws" ]; then
+    local slug; slug=$(echo "$ws" | tr '[:upper:]-' '[:lower:]_')
+    # Constrain the slug before it reaches `${!varname}`. Indirect expansion
+    # evaluates an array subscript, so a workspace carrying `[$(...)]` would
+    # RUN that command here — and `tr` above only folds case and dashes, it
+    # strips nothing. The slug's source is `.lisa.config.json`, which is
+    # repository-controlled input: exactly what this ladder already refuses to
+    # trust when it picks resolvers. A real workspace slug is lowercase
+    # alphanumerics and underscores, so anything else is not a slug we should
+    # be expanding — skip the rung and fall through rather than guessing.
+    case "$slug" in
+      ""|*[!a-z0-9_]*) ;;
+      *)
+        local varname="LINEAR_API_KEY_${slug}"
+        [ -n "${!varname:-}" ] && { echo "${!varname}"; return; }
+        ;;
+    esac
+  fi
+
   # 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
@@ -132,9 +166,10 @@ linear_graphql() {
   local query="$1"
   local variables="${2:-{}}"
   local key
-  key=$(read_linear_key) || {
-    echo "Error: no Linear API key. Set LINEAR_API_KEY, or store it as" >&2
-    echo "LINEAR_API_KEY in this project's secrets provider." >&2
+  key=$(read_linear_key "${WORKSPACE:-}") || {
+    echo "Error: no Linear API key. Set LINEAR_API_KEY (or the per-workspace" >&2
+    echo "LINEAR_API_KEY_<slug>), or store it as LINEAR_API_KEY in this" >&2
+    echo "project's secrets provider." >&2
     return 1
   }
   jq -n --arg query "$query" --argjson variables "$variables" \