@codyswann/lisa 4.86.0 → 4.86.1

package/dist/opencode/plugin-templates/parity-safety-net.sh

@@ -3475,12 +3475,28 @@ if [ -f "$rules_file" ]; then
     # here — before the remaining rules ran, and with an exit status that is
     # not a refusal. The `||` puts the pipeline in a condition context, where
     # a non-zero status is expected rather than fatal.
-    # Consume the whole input: grep -q can close an early match while printf
-    # is still writing, making pipefail report SIGPIPE instead of the match.
+    # A here-string, never a pipe. With `printf | grep` under pipefail, a grep
+    # that stops at its first match (`-q`, and GNU grep whose stdout is
+    # /dev/null, which it treats as `-q`) closes the pipe while printf is still
+    # writing; printf takes SIGPIPE and the pipeline reports 141 instead of
+    # grep's 0. 141 lands in the `*)` arm below and a rule that MATCHED was
+    # reported as an invalid regex and not enforced (CodySwannGT/lisa#4564).
+    # A here-string has no writer process, so the status is grep's alone.
+    #
+    # The here-string is staged by the shell (a pipe, or a temp file for a
+    # large body or on Bash 3.2), and that staging can fail: no temp space,
+    # a file-size limit. A failed redirection on a bare `grep … <<<` returns
+    # 1, the same status as "no match", so the rule would silently pass. The
+    # brace group separates the two: grep's own status is captured INSIDE it,
+    # so the group itself only fails when the redirection could not be set up.
     rule_status=0
-    printf '%s' "$custom_command_str" | grep -Ei -- "$rule" >/dev/null || rule_status=$?
+    { grep -qEi -- "$rule" || rule_status=$?; } <<<"$custom_command_str" \
+      || rule_status=unstaged
     case "$rule_status" in
       0) block "matched a project custom safety rule (${rules_file##*/}): $rule" ;;
+      # Fail closed: the rule could not be evaluated at all, which is not the
+      # same thing as the rule not matching.
+      unstaged) block "could not stage the command to check project custom safety rule (${rules_file##*/}): $rule" ;;
       1) ;; # no match
       # grep exits 2 on a malformed ERE. Treated as no-match before, so a typo
       # in a project's rules file silently disabled that rule — a guard the

package/package.json

@@ -189,7 +189,7 @@
     "qs": "^6.16.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.86.0",
+  "version": "4.86.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -347,7 +347,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "e3e3be6b38115b41fb7f83de27d26f8438b2794e",
-  "gitHead": "e3e3be6b38115b41fb7f83de27d26f8438b2794e",
-  "lisaReleaseTag": "v4.86.0"
+  "lisaReleaseCommit": "9a3b3a837256383ba6101f74e1fcc457bd86f34d",
+  "gitHead": "9a3b3a837256383ba6101f74e1fcc457bd86f34d",
+  "lisaReleaseTag": "v4.86.1"
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.86.0",
+  "version": "4.86.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.86.0",
+  "version": "4.86.1",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-parity-sentry-sdk-setup/SKILL.md

@@ -179,8 +179,11 @@ once at module startup with the DSN from the environment. Await a finite positiv
 flush budget on both success and original-error paths. A false flush result or
 rejection must not turn successful queue work into a retry or replace its real
 error. Keep diagnostics local and non-throwing, and preserve the client for warm
-invocations: `close()` disables it. The following helper wraps the host's existing
-business operation; it neither mutates context nor adds a Lambda callback.
+invocations: `close()` disables it. A warm container reuses the same process, so
+run each invocation inside `Sentry.withIsolationScope()`: tags, user and
+breadcrumbs that one invocation sets then stay with that invocation instead of
+leaking into the next one's events. The following helper wraps the host's existing
+business operation; it neither mutates the Lambda context nor adds a Lambda callback.
 
 <!-- lisa-node24-unwrapped-example:start -->
 ```ts
@@ -202,24 +205,28 @@ export async function withSentryFlush<T>(
   if (!Number.isFinite(timeoutMs) || timeoutMs <= 0) {
     throw new RangeError("Choose a finite positive Sentry flush budget");
   }
-  try {
-    return await work();
-  } catch (originalError) {
-    try {
-      Sentry.captureException(originalError);
-    } catch {
-      // Preserve the original handler error even if capture fails.
-    }
-    throw originalError;
-  } finally {
+  // A fresh isolation scope per invocation: scope data set by one warm
+  // invocation must not be attached to the next invocation's events.
+  return Sentry.withIsolationScope(async () => {
     try {
-      if (!(await Sentry.flush(timeoutMs))) {
-        reportFlushProblem("Sentry flush did not finish in time");
+      return await work();
+    } catch (originalError) {
+      try {
+        Sentry.captureException(originalError);
+      } catch {
+        // Preserve the original handler error even if capture fails.
+      }
+      throw originalError;
+    } finally {
+      try {
+        if (!(await Sentry.flush(timeoutMs))) {
+          reportFlushProblem("Sentry flush did not finish in time");
+        }
+      } catch {
+        reportFlushProblem("Sentry flush rejected");
       }
-    } catch {
-      reportFlushProblem("Sentry flush rejected");
     }
-  }
+  });
 }
 ```
 <!-- lisa-node24-unwrapped-example:end -->

package/plugins/lisa/.codex-plugin/skills/lisa-secrets-access/scripts/validate-config.mjs

@@ -712,6 +712,31 @@ function validateNotify(notify) {
       ];
 }
 
+/**
+ * Maps under `sessionManager` whose KEYS are names chosen by the project, not
+ * config field names. `repos.entries` is keyed by child repository directory,
+ * so a repo called `token-service` or `secrets-manager` is a name, not a
+ * credential field; testing it against CREDENTIAL_KEY made `init-config
+ * --write` emit a block that `validate` then refused (CodySwannGT/lisa#4564).
+ * Their VALUES are still walked, so a token placed inside an entry is caught.
+ */
+const NAME_KEYED_MAPS = [["repos", "entries"]];
+
+/**
+ * Whether a key trail below `sessionManager` is exactly a name-keyed map.
+ * Compared segment by segment, never as a dotted string: a literal key
+ * `"repos.entries"` would otherwise borrow the exemption.
+ * @param {readonly string[]} segments Object keys from the block root.
+ * @returns {boolean} True for a map whose keys are names.
+ */
+function isNameKeyedMap(segments) {
+  return NAME_KEYED_MAPS.some(
+    map =>
+      map.length === segments.length &&
+      map.every((segment, i) => segment === segments[i])
+  );
+}
+
 /**
  * Walk the block for anything that looks like a credential.
  *
@@ -721,10 +746,12 @@ function validateNotify(notify) {
  * configured), so a token here is both leaked and unused. The value is never
  * echoed.
  * @param {unknown} value Subtree.
- * @param {string} path Dotted path so far.
+ * @param {string} path Dotted path so far, for messages.
+ * @param {readonly string[] | null} [segments] Object keys from the block root;
+ *   `null` once an array is crossed, since no name-keyed map lives there.
  * @returns {string[]} Problems found.
  */
-function findCredentials(value, path) {
+function findCredentials(value, path, segments = []) {
   if (typeof value === "string") {
     return TOKEN_VALUE.test(value.trim())
       ? [
@@ -736,18 +763,25 @@ function findCredentials(value, path) {
       : [];
   }
   if (Array.isArray(value)) {
-    return value.flatMap((item, i) => findCredentials(item, `${path}[${i}]`));
+    return value.flatMap((item, i) =>
+      findCredentials(item, `${path}[${i}]`, null)
+    );
   }
   if (!isPlainObject(value)) return [];
+  const keysAreNames = segments !== null && isNameKeyedMap(segments);
   return Object.entries(value).flatMap(([key, child]) =>
-    CREDENTIAL_KEY.test(key)
+    !keysAreNames && CREDENTIAL_KEY.test(key)
       ? [
           `${path}.${key} names a credential. Tokens and secrets never go in ` +
             `config: remove it, and keep the bot token in the project's ` +
             `secrets provider (session-manager.mjs store-token, run by ` +
             `/lisa:setup:session-manager).`,
         ]
-      : findCredentials(child, `${path}.${key}`)
+      : findCredentials(
+          child,
+          `${path}.${key}`,
+          segments === null ? null : [...segments, key]
+        )
   );
 }
 

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

@@ -3475,12 +3475,28 @@ if [ -f "$rules_file" ]; then
     # here — before the remaining rules ran, and with an exit status that is
     # not a refusal. The `||` puts the pipeline in a condition context, where
     # a non-zero status is expected rather than fatal.
-    # Consume the whole input: grep -q can close an early match while printf
-    # is still writing, making pipefail report SIGPIPE instead of the match.
+    # A here-string, never a pipe. With `printf | grep` under pipefail, a grep
+    # that stops at its first match (`-q`, and GNU grep whose stdout is
+    # /dev/null, which it treats as `-q`) closes the pipe while printf is still
+    # writing; printf takes SIGPIPE and the pipeline reports 141 instead of
+    # grep's 0. 141 lands in the `*)` arm below and a rule that MATCHED was
+    # reported as an invalid regex and not enforced (CodySwannGT/lisa#4564).
+    # A here-string has no writer process, so the status is grep's alone.
+    #
+    # The here-string is staged by the shell (a pipe, or a temp file for a
+    # large body or on Bash 3.2), and that staging can fail: no temp space,
+    # a file-size limit. A failed redirection on a bare `grep … <<<` returns
+    # 1, the same status as "no match", so the rule would silently pass. The
+    # brace group separates the two: grep's own status is captured INSIDE it,
+    # so the group itself only fails when the redirection could not be set up.
     rule_status=0
-    printf '%s' "$custom_command_str" | grep -Ei -- "$rule" >/dev/null || rule_status=$?
+    { grep -qEi -- "$rule" || rule_status=$?; } <<<"$custom_command_str" \
+      || rule_status=unstaged
     case "$rule_status" in
       0) block "matched a project custom safety rule (${rules_file##*/}): $rule" ;;
+      # Fail closed: the rule could not be evaluated at all, which is not the
+      # same thing as the rule not matching.
+      unstaged) block "could not stage the command to check project custom safety rule (${rules_file##*/}): $rule" ;;
       1) ;; # no match
       # grep exits 2 on a malformed ERE. Treated as no-match before, so a typo
       # in a project's rules file silently disabled that rule — a guard the

package/plugins/lisa/skills/lisa-parity-sentry-sdk-setup/SKILL.md

@@ -177,8 +177,11 @@ once at module startup with the DSN from the environment. Await a finite positiv
 flush budget on both success and original-error paths. A false flush result or
 rejection must not turn successful queue work into a retry or replace its real
 error. Keep diagnostics local and non-throwing, and preserve the client for warm
-invocations: `close()` disables it. The following helper wraps the host's existing
-business operation; it neither mutates context nor adds a Lambda callback.
+invocations: `close()` disables it. A warm container reuses the same process, so
+run each invocation inside `Sentry.withIsolationScope()`: tags, user and
+breadcrumbs that one invocation sets then stay with that invocation instead of
+leaking into the next one's events. The following helper wraps the host's existing
+business operation; it neither mutates the Lambda context nor adds a Lambda callback.
 
 <!-- lisa-node24-unwrapped-example:start -->
 ```ts
@@ -200,24 +203,28 @@ export async function withSentryFlush<T>(
   if (!Number.isFinite(timeoutMs) || timeoutMs <= 0) {
     throw new RangeError("Choose a finite positive Sentry flush budget");
   }
-  try {
-    return await work();
-  } catch (originalError) {
-    try {
-      Sentry.captureException(originalError);
-    } catch {
-      // Preserve the original handler error even if capture fails.
-    }
-    throw originalError;
-  } finally {
+  // A fresh isolation scope per invocation: scope data set by one warm
+  // invocation must not be attached to the next invocation's events.
+  return Sentry.withIsolationScope(async () => {
     try {
-      if (!(await Sentry.flush(timeoutMs))) {
-        reportFlushProblem("Sentry flush did not finish in time");
+      return await work();
+    } catch (originalError) {
+      try {
+        Sentry.captureException(originalError);
+      } catch {
+        // Preserve the original handler error even if capture fails.
+      }
+      throw originalError;
+    } finally {
+      try {
+        if (!(await Sentry.flush(timeoutMs))) {
+          reportFlushProblem("Sentry flush did not finish in time");
+        }
+      } catch {
+        reportFlushProblem("Sentry flush rejected");
       }
-    } catch {
-      reportFlushProblem("Sentry flush rejected");
     }
-  }
+  });
 }
 ```
 <!-- lisa-node24-unwrapped-example:end -->

package/plugins/lisa/skills/lisa-secrets-access/scripts/validate-config.mjs

@@ -712,6 +712,31 @@ function validateNotify(notify) {
       ];
 }
 
+/**
+ * Maps under `sessionManager` whose KEYS are names chosen by the project, not
+ * config field names. `repos.entries` is keyed by child repository directory,
+ * so a repo called `token-service` or `secrets-manager` is a name, not a
+ * credential field; testing it against CREDENTIAL_KEY made `init-config
+ * --write` emit a block that `validate` then refused (CodySwannGT/lisa#4564).
+ * Their VALUES are still walked, so a token placed inside an entry is caught.
+ */
+const NAME_KEYED_MAPS = [["repos", "entries"]];
+
+/**
+ * Whether a key trail below `sessionManager` is exactly a name-keyed map.
+ * Compared segment by segment, never as a dotted string: a literal key
+ * `"repos.entries"` would otherwise borrow the exemption.
+ * @param {readonly string[]} segments Object keys from the block root.
+ * @returns {boolean} True for a map whose keys are names.
+ */
+function isNameKeyedMap(segments) {
+  return NAME_KEYED_MAPS.some(
+    map =>
+      map.length === segments.length &&
+      map.every((segment, i) => segment === segments[i])
+  );
+}
+
 /**
  * Walk the block for anything that looks like a credential.
  *
@@ -721,10 +746,12 @@ function validateNotify(notify) {
  * configured), so a token here is both leaked and unused. The value is never
  * echoed.
  * @param {unknown} value Subtree.
- * @param {string} path Dotted path so far.
+ * @param {string} path Dotted path so far, for messages.
+ * @param {readonly string[] | null} [segments] Object keys from the block root;
+ *   `null` once an array is crossed, since no name-keyed map lives there.
  * @returns {string[]} Problems found.
  */
-function findCredentials(value, path) {
+function findCredentials(value, path, segments = []) {
   if (typeof value === "string") {
     return TOKEN_VALUE.test(value.trim())
       ? [
@@ -736,18 +763,25 @@ function findCredentials(value, path) {
       : [];
   }
   if (Array.isArray(value)) {
-    return value.flatMap((item, i) => findCredentials(item, `${path}[${i}]`));
+    return value.flatMap((item, i) =>
+      findCredentials(item, `${path}[${i}]`, null)
+    );
   }
   if (!isPlainObject(value)) return [];
+  const keysAreNames = segments !== null && isNameKeyedMap(segments);
   return Object.entries(value).flatMap(([key, child]) =>
-    CREDENTIAL_KEY.test(key)
+    !keysAreNames && CREDENTIAL_KEY.test(key)
       ? [
           `${path}.${key} names a credential. Tokens and secrets never go in ` +
             `config: remove it, and keep the bot token in the project's ` +
             `secrets provider (session-manager.mjs store-token, run by ` +
             `/lisa:setup:session-manager).`,
         ]
-      : findCredentials(child, `${path}.${key}`)
+      : findCredentials(
+          child,
+          `${path}.${key}`,
+          segments === null ? null : [...segments, key]
+        )
   );
 }
 

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

@@ -3475,12 +3475,28 @@ if [ -f "$rules_file" ]; then
     # here — before the remaining rules ran, and with an exit status that is
     # not a refusal. The `||` puts the pipeline in a condition context, where
     # a non-zero status is expected rather than fatal.
-    # Consume the whole input: grep -q can close an early match while printf
-    # is still writing, making pipefail report SIGPIPE instead of the match.
+    # A here-string, never a pipe. With `printf | grep` under pipefail, a grep
+    # that stops at its first match (`-q`, and GNU grep whose stdout is
+    # /dev/null, which it treats as `-q`) closes the pipe while printf is still
+    # writing; printf takes SIGPIPE and the pipeline reports 141 instead of
+    # grep's 0. 141 lands in the `*)` arm below and a rule that MATCHED was
+    # reported as an invalid regex and not enforced (CodySwannGT/lisa#4564).
+    # A here-string has no writer process, so the status is grep's alone.
+    #
+    # The here-string is staged by the shell (a pipe, or a temp file for a
+    # large body or on Bash 3.2), and that staging can fail: no temp space,
+    # a file-size limit. A failed redirection on a bare `grep … <<<` returns
+    # 1, the same status as "no match", so the rule would silently pass. The
+    # brace group separates the two: grep's own status is captured INSIDE it,
+    # so the group itself only fails when the redirection could not be set up.
     rule_status=0
-    printf '%s' "$custom_command_str" | grep -Ei -- "$rule" >/dev/null || rule_status=$?
+    { grep -qEi -- "$rule" || rule_status=$?; } <<<"$custom_command_str" \
+      || rule_status=unstaged
     case "$rule_status" in
       0) block "matched a project custom safety rule (${rules_file##*/}): $rule" ;;
+      # Fail closed: the rule could not be evaluated at all, which is not the
+      # same thing as the rule not matching.
+      unstaged) block "could not stage the command to check project custom safety rule (${rules_file##*/}): $rule" ;;
       1) ;; # no match
       # grep exits 2 on a malformed ERE. Treated as no-match before, so a typo
       # in a project's rules file silently disabled that rule — a guard the

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-parity-sentry-sdk-setup/SKILL.md

@@ -177,8 +177,11 @@ once at module startup with the DSN from the environment. Await a finite positiv
 flush budget on both success and original-error paths. A false flush result or
 rejection must not turn successful queue work into a retry or replace its real
 error. Keep diagnostics local and non-throwing, and preserve the client for warm
-invocations: `close()` disables it. The following helper wraps the host's existing
-business operation; it neither mutates context nor adds a Lambda callback.
+invocations: `close()` disables it. A warm container reuses the same process, so
+run each invocation inside `Sentry.withIsolationScope()`: tags, user and
+breadcrumbs that one invocation sets then stay with that invocation instead of
+leaking into the next one's events. The following helper wraps the host's existing
+business operation; it neither mutates the Lambda context nor adds a Lambda callback.
 
 <!-- lisa-node24-unwrapped-example:start -->
 ```ts
@@ -200,24 +203,28 @@ export async function withSentryFlush<T>(
   if (!Number.isFinite(timeoutMs) || timeoutMs <= 0) {
     throw new RangeError("Choose a finite positive Sentry flush budget");
   }
-  try {
-    return await work();
-  } catch (originalError) {
-    try {
-      Sentry.captureException(originalError);
-    } catch {
-      // Preserve the original handler error even if capture fails.
-    }
-    throw originalError;
-  } finally {
+  // A fresh isolation scope per invocation: scope data set by one warm
+  // invocation must not be attached to the next invocation's events.
+  return Sentry.withIsolationScope(async () => {
     try {
-      if (!(await Sentry.flush(timeoutMs))) {
-        reportFlushProblem("Sentry flush did not finish in time");
+      return await work();
+    } catch (originalError) {
+      try {
+        Sentry.captureException(originalError);
+      } catch {
+        // Preserve the original handler error even if capture fails.
+      }
+      throw originalError;
+    } finally {
+      try {
+        if (!(await Sentry.flush(timeoutMs))) {
+          reportFlushProblem("Sentry flush did not finish in time");
+        }
+      } catch {
+        reportFlushProblem("Sentry flush rejected");
       }
-    } catch {
-      reportFlushProblem("Sentry flush rejected");
     }
-  }
+  });
 }
 ```
 <!-- lisa-node24-unwrapped-example:end -->

package/plugins/lisa-agy/skills/lisa-secrets-access/scripts/validate-config.mjs

@@ -712,6 +712,31 @@ function validateNotify(notify) {
       ];
 }
 
+/**
+ * Maps under `sessionManager` whose KEYS are names chosen by the project, not
+ * config field names. `repos.entries` is keyed by child repository directory,
+ * so a repo called `token-service` or `secrets-manager` is a name, not a
+ * credential field; testing it against CREDENTIAL_KEY made `init-config
+ * --write` emit a block that `validate` then refused (CodySwannGT/lisa#4564).
+ * Their VALUES are still walked, so a token placed inside an entry is caught.
+ */
+const NAME_KEYED_MAPS = [["repos", "entries"]];
+
+/**
+ * Whether a key trail below `sessionManager` is exactly a name-keyed map.
+ * Compared segment by segment, never as a dotted string: a literal key
+ * `"repos.entries"` would otherwise borrow the exemption.
+ * @param {readonly string[]} segments Object keys from the block root.
+ * @returns {boolean} True for a map whose keys are names.
+ */
+function isNameKeyedMap(segments) {
+  return NAME_KEYED_MAPS.some(
+    map =>
+      map.length === segments.length &&
+      map.every((segment, i) => segment === segments[i])
+  );
+}
+
 /**
  * Walk the block for anything that looks like a credential.
  *
@@ -721,10 +746,12 @@ function validateNotify(notify) {
  * configured), so a token here is both leaked and unused. The value is never
  * echoed.
  * @param {unknown} value Subtree.
- * @param {string} path Dotted path so far.
+ * @param {string} path Dotted path so far, for messages.
+ * @param {readonly string[] | null} [segments] Object keys from the block root;
+ *   `null` once an array is crossed, since no name-keyed map lives there.
  * @returns {string[]} Problems found.
  */
-function findCredentials(value, path) {
+function findCredentials(value, path, segments = []) {
   if (typeof value === "string") {
     return TOKEN_VALUE.test(value.trim())
       ? [
@@ -736,18 +763,25 @@ function findCredentials(value, path) {
       : [];
   }
   if (Array.isArray(value)) {
-    return value.flatMap((item, i) => findCredentials(item, `${path}[${i}]`));
+    return value.flatMap((item, i) =>
+      findCredentials(item, `${path}[${i}]`, null)
+    );
   }
   if (!isPlainObject(value)) return [];
+  const keysAreNames = segments !== null && isNameKeyedMap(segments);
   return Object.entries(value).flatMap(([key, child]) =>
-    CREDENTIAL_KEY.test(key)
+    !keysAreNames && CREDENTIAL_KEY.test(key)
       ? [
           `${path}.${key} names a credential. Tokens and secrets never go in ` +
             `config: remove it, and keep the bot token in the project's ` +
             `secrets provider (session-manager.mjs store-token, run by ` +
             `/lisa:setup:session-manager).`,
         ]
-      : findCredentials(child, `${path}.${key}`)
+      : findCredentials(
+          child,
+          `${path}.${key}`,
+          segments === null ? null : [...segments, key]
+        )
   );
 }
 

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.86.0",
+  "version": "4.86.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.86.0",
+  "version": "4.86.1",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"