@codyswann/lisa 2.331.3 → 2.332.1

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.9"
   },
   "name": "@codyswann/lisa",
-  "version": "2.331.3",
+  "version": "2.332.1",
   "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": "2.331.3",
+  "version": "2.332.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": "2.331.3",
+  "version": "2.332.1",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -76,13 +76,37 @@ function bindingsFor(surface) {
 /**
  * Install methods the toolchain runner supports.
  *
- * `release-tar` was missing here while the runner had supported it for as long
- * as gh has been pinned — so this validator would have rejected the project's
- * own manifest, and the only reason nobody hit it is that nothing ran the two
- * against each other. Kept in step with `assertPinned` in `toolchain.mjs`,
- * which is the list that actually decides.
+ * This is a deliberate copy of `INSTALL_METHODS` in `toolchain.mjs`, which is
+ * the list that actually decides. Skills are distributed as self-contained
+ * directories and nothing imports across a skill boundary, so importing the
+ * authority here would couple two skills' distribution for one array.
+ *
+ * The copy has drifted twice. First `release-tar` was missing while the runner
+ * had supported it for as long as gh has been pinned. Then `release-tree` and
+ * `release-binary` were both missing, which rejected a valid `jq` pin. Each
+ * time the only safeguard was a comment asking the next author to remember.
+ * A conformance test now compares the two sets directly, so adding a kind on
+ * either side fails until both know it.
  */
-const INSTALL_METHODS = new Set(["release-zip", "release-tar", "npm-global"]);
+const INSTALL_METHODS = new Set([
+  "release-zip",
+  "release-tar",
+  "release-tree",
+  "release-binary",
+  "npm-global",
+]);
+
+/**
+ * Download kinds — every method that fetches a URL, so every one that needs a
+ * checksum. Spelled as "not npm-global" rather than as a list, because the next
+ * download kind should inherit the obligation by default; the drift above came
+ * from lists that had to be remembered.
+ * @param {string} method An install method.
+ * @returns {boolean} Whether the method fetches a pinned artifact.
+ */
+function isDownloadKind(method) {
+  return INSTALL_METHODS.has(method) && method !== "npm-global";
+}
 
 /**
  * Validate the `secrets` block.
@@ -171,19 +195,28 @@ function validateInstallArtifact(label, entry, problems) {
     );
     return;
   }
-  // Both archive kinds, not just zip. A tarball pinned without a checksum
-  // trusts whatever the URL serves today exactly as much as a zip does, and
-  // checking only one of them meant the tool Lisa's guardrails shell out to —
-  // gh, which ships a tarball on Linux — was the one going unverified.
-  if (
-    (entry.install === "release-zip" || entry.install === "release-tar") &&
-    !(entry.url && entry.sha256)
-  ) {
+  // Every download kind, not an enumerated few. A tarball pinned without a
+  // checksum trusts whatever the URL serves today exactly as much as a zip
+  // does, and checking only one of them meant the tool Lisa's guardrails shell
+  // out to — gh, which ships a tarball on Linux — was the one going unverified.
+  // A `release-binary` matters most of all: the artifact is directly
+  // executable, so a wrong one needs no unpacking step to run.
+  if (isDownloadKind(entry.install) && !(entry.url && entry.sha256)) {
     problems.push(
       `remoteEnv install ${label} needs both url and sha256. A pinned ` +
         `version with no checksum still trusts whatever the URL serves today.`
     );
   }
+  // A tree is the one kind with no sane default entry point: the archive root
+  // is a directory, so an omitted `binary` would install a directory as a
+  // command. The runner refuses it, and a validator that accepted it would just
+  // move the failure from review to provisioning.
+  if (entry.install === "release-tree" && !entry.binary) {
+    problems.push(
+      `remoteEnv install ${label} needs "binary" — the path to the entry ` +
+        `point INSIDE the archive, such as "maestro/bin/maestro".`
+    );
+  }
   if (entry.install === "npm-global" && !entry.package) {
     problems.push(`remoteEnv install ${label} needs a package`);
   }

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs

@@ -300,6 +300,44 @@ function installReleaseTree(tool, binDir) {
   }
 }
 
+/**
+ * Install a pinned artifact that IS the binary, with no archive around it.
+ *
+ * Several tools worth pinning publish a raw executable rather than an archive —
+ * jq ships `jq-linux-amd64` and a `sha256sum.txt`, which is ideal material for a
+ * checksummed pin and fits none of the archive kinds.
+ *
+ * Without this the only entry that passes `assertPinned` is `release-zip`, which
+ * then fails at install when `unzip` is handed a binary. A manifest entry that
+ * validates and cannot install is worse than one that is rejected outright: the
+ * error arrives during provisioning rather than during review.
+ *
+ * There is no `binary` field here, deliberately — the download is the binary,
+ * so there is nothing inside it to name.
+ * @param {object} tool Manifest entry.
+ * @param {string} binDir Directory to install into.
+ */
+function installReleaseBinary(tool, binDir) {
+  const temporary = join(binDir, `.${tool.name}-download`);
+  mkdirSync(temporary, { recursive: true });
+  try {
+    const artifact = join(temporary, tool.name);
+    execFileSync("curl", ["-fsSL", tool.url, "-o", artifact], {
+      stdio: "inherit",
+    });
+    // Verify before it reaches a directory on PATH. For this kind that ordering
+    // matters more than for the archives: the downloaded file is directly
+    // executable, so a wrong artifact placed first is a wrong artifact that can
+    // be run.
+    verifyChecksum(artifact, tool.sha256, tool.name);
+    execFileSync("install", ["-m", "0755", artifact, join(binDir, tool.name)], {
+      stdio: "inherit",
+    });
+  } finally {
+    rmSync(temporary, { recursive: true, force: true });
+  }
+}
+
 /**
  * Install a pinned global npm package.
  * @param {object} tool Manifest entry.
@@ -328,6 +366,8 @@ export function installTool(tool, binDir) {
   if (tool.install === "release-zip") installReleaseZip(tool, binDir);
   else if (tool.install === "release-tar") installReleaseTar(tool, binDir);
   else if (tool.install === "release-tree") installReleaseTree(tool, binDir);
+  else if (tool.install === "release-binary")
+    installReleaseBinary(tool, binDir);
   else installNpmGlobal(tool);
 }
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/scripts/toolchain.mjs

@@ -301,6 +301,24 @@ export function planToolchain(
   return plan;
 }
 
+/**
+ * Every install method the runner can execute — the authoritative list.
+ *
+ * `validate-config.mjs` maintains its own copy because skills are distributed
+ * as self-contained directories and nothing else imports across a skill
+ * boundary. A comment saying "keep these in step" has now failed twice — first
+ * for `release-tar`, then for `release-tree` and `release-binary` together — so
+ * the pairing is enforced by a conformance test against this export instead.
+ * Adding a kind here fails that test until the validator learns it too.
+ */
+export const INSTALL_METHODS = Object.freeze([
+  "release-zip",
+  "release-tar",
+  "release-tree",
+  "release-binary",
+  "npm-global",
+]);
+
 /**
  * Reject a manifest entry that could install something unverifiable.
  *
@@ -354,6 +372,18 @@ export function assertPinned(tool) {
     }
     return;
   }
+  // The download IS the binary, so there is no `binary` path to require — but
+  // the checksum matters more here than anywhere else, because the artifact is
+  // directly executable rather than something that has to be unpacked first.
+  if (tool.install === "release-binary") {
+    if (!tool.url || !tool.sha256) {
+      throw new Error(
+        `${tool.name}: a release-binary install needs both url and sha256.\n` +
+          `A version bump must move the checksum in the same reviewed commit.`
+      );
+    }
+    return;
+  }
   if (tool.install === "npm-global") {
     if (!tool.package)
       throw new Error(`${tool.name}: npm-global install needs a package`);
@@ -361,6 +391,6 @@ export function assertPinned(tool) {
   }
   throw new Error(
     `${tool.name}: unknown install method "${tool.install}".\n` +
-      `Supported: release-zip, release-tar, release-tree, npm-global.`
+      `Supported: ${INSTALL_METHODS.join(", ")}.`
   );
 }

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

@@ -76,13 +76,37 @@ function bindingsFor(surface) {
 /**
  * Install methods the toolchain runner supports.
  *
- * `release-tar` was missing here while the runner had supported it for as long
- * as gh has been pinned — so this validator would have rejected the project's
- * own manifest, and the only reason nobody hit it is that nothing ran the two
- * against each other. Kept in step with `assertPinned` in `toolchain.mjs`,
- * which is the list that actually decides.
+ * This is a deliberate copy of `INSTALL_METHODS` in `toolchain.mjs`, which is
+ * the list that actually decides. Skills are distributed as self-contained
+ * directories and nothing imports across a skill boundary, so importing the
+ * authority here would couple two skills' distribution for one array.
+ *
+ * The copy has drifted twice. First `release-tar` was missing while the runner
+ * had supported it for as long as gh has been pinned. Then `release-tree` and
+ * `release-binary` were both missing, which rejected a valid `jq` pin. Each
+ * time the only safeguard was a comment asking the next author to remember.
+ * A conformance test now compares the two sets directly, so adding a kind on
+ * either side fails until both know it.
  */
-const INSTALL_METHODS = new Set(["release-zip", "release-tar", "npm-global"]);
+const INSTALL_METHODS = new Set([
+  "release-zip",
+  "release-tar",
+  "release-tree",
+  "release-binary",
+  "npm-global",
+]);
+
+/**
+ * Download kinds — every method that fetches a URL, so every one that needs a
+ * checksum. Spelled as "not npm-global" rather than as a list, because the next
+ * download kind should inherit the obligation by default; the drift above came
+ * from lists that had to be remembered.
+ * @param {string} method An install method.
+ * @returns {boolean} Whether the method fetches a pinned artifact.
+ */
+function isDownloadKind(method) {
+  return INSTALL_METHODS.has(method) && method !== "npm-global";
+}
 
 /**
  * Validate the `secrets` block.
@@ -171,19 +195,28 @@ function validateInstallArtifact(label, entry, problems) {
     );
     return;
   }
-  // Both archive kinds, not just zip. A tarball pinned without a checksum
-  // trusts whatever the URL serves today exactly as much as a zip does, and
-  // checking only one of them meant the tool Lisa's guardrails shell out to —
-  // gh, which ships a tarball on Linux — was the one going unverified.
-  if (
-    (entry.install === "release-zip" || entry.install === "release-tar") &&
-    !(entry.url && entry.sha256)
-  ) {
+  // Every download kind, not an enumerated few. A tarball pinned without a
+  // checksum trusts whatever the URL serves today exactly as much as a zip
+  // does, and checking only one of them meant the tool Lisa's guardrails shell
+  // out to — gh, which ships a tarball on Linux — was the one going unverified.
+  // A `release-binary` matters most of all: the artifact is directly
+  // executable, so a wrong one needs no unpacking step to run.
+  if (isDownloadKind(entry.install) && !(entry.url && entry.sha256)) {
     problems.push(
       `remoteEnv install ${label} needs both url and sha256. A pinned ` +
         `version with no checksum still trusts whatever the URL serves today.`
     );
   }
+  // A tree is the one kind with no sane default entry point: the archive root
+  // is a directory, so an omitted `binary` would install a directory as a
+  // command. The runner refuses it, and a validator that accepted it would just
+  // move the failure from review to provisioning.
+  if (entry.install === "release-tree" && !entry.binary) {
+    problems.push(
+      `remoteEnv install ${label} needs "binary" — the path to the entry ` +
+        `point INSIDE the archive, such as "maestro/bin/maestro".`
+    );
+  }
   if (entry.install === "npm-global" && !entry.package) {
     problems.push(`remoteEnv install ${label} needs a package`);
   }

package/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs

@@ -300,6 +300,44 @@ function installReleaseTree(tool, binDir) {
   }
 }
 
+/**
+ * Install a pinned artifact that IS the binary, with no archive around it.
+ *
+ * Several tools worth pinning publish a raw executable rather than an archive —
+ * jq ships `jq-linux-amd64` and a `sha256sum.txt`, which is ideal material for a
+ * checksummed pin and fits none of the archive kinds.
+ *
+ * Without this the only entry that passes `assertPinned` is `release-zip`, which
+ * then fails at install when `unzip` is handed a binary. A manifest entry that
+ * validates and cannot install is worse than one that is rejected outright: the
+ * error arrives during provisioning rather than during review.
+ *
+ * There is no `binary` field here, deliberately — the download is the binary,
+ * so there is nothing inside it to name.
+ * @param {object} tool Manifest entry.
+ * @param {string} binDir Directory to install into.
+ */
+function installReleaseBinary(tool, binDir) {
+  const temporary = join(binDir, `.${tool.name}-download`);
+  mkdirSync(temporary, { recursive: true });
+  try {
+    const artifact = join(temporary, tool.name);
+    execFileSync("curl", ["-fsSL", tool.url, "-o", artifact], {
+      stdio: "inherit",
+    });
+    // Verify before it reaches a directory on PATH. For this kind that ordering
+    // matters more than for the archives: the downloaded file is directly
+    // executable, so a wrong artifact placed first is a wrong artifact that can
+    // be run.
+    verifyChecksum(artifact, tool.sha256, tool.name);
+    execFileSync("install", ["-m", "0755", artifact, join(binDir, tool.name)], {
+      stdio: "inherit",
+    });
+  } finally {
+    rmSync(temporary, { recursive: true, force: true });
+  }
+}
+
 /**
  * Install a pinned global npm package.
  * @param {object} tool Manifest entry.
@@ -328,6 +366,8 @@ export function installTool(tool, binDir) {
   if (tool.install === "release-zip") installReleaseZip(tool, binDir);
   else if (tool.install === "release-tar") installReleaseTar(tool, binDir);
   else if (tool.install === "release-tree") installReleaseTree(tool, binDir);
+  else if (tool.install === "release-binary")
+    installReleaseBinary(tool, binDir);
   else installNpmGlobal(tool);
 }
 

package/plugins/lisa/skills/lisa-setup-remote-env/scripts/toolchain.mjs

@@ -301,6 +301,24 @@ export function planToolchain(
   return plan;
 }
 
+/**
+ * Every install method the runner can execute — the authoritative list.
+ *
+ * `validate-config.mjs` maintains its own copy because skills are distributed
+ * as self-contained directories and nothing else imports across a skill
+ * boundary. A comment saying "keep these in step" has now failed twice — first
+ * for `release-tar`, then for `release-tree` and `release-binary` together — so
+ * the pairing is enforced by a conformance test against this export instead.
+ * Adding a kind here fails that test until the validator learns it too.
+ */
+export const INSTALL_METHODS = Object.freeze([
+  "release-zip",
+  "release-tar",
+  "release-tree",
+  "release-binary",
+  "npm-global",
+]);
+
 /**
  * Reject a manifest entry that could install something unverifiable.
  *
@@ -354,6 +372,18 @@ export function assertPinned(tool) {
     }
     return;
   }
+  // The download IS the binary, so there is no `binary` path to require — but
+  // the checksum matters more here than anywhere else, because the artifact is
+  // directly executable rather than something that has to be unpacked first.
+  if (tool.install === "release-binary") {
+    if (!tool.url || !tool.sha256) {
+      throw new Error(
+        `${tool.name}: a release-binary install needs both url and sha256.\n` +
+          `A version bump must move the checksum in the same reviewed commit.`
+      );
+    }
+    return;
+  }
   if (tool.install === "npm-global") {
     if (!tool.package)
       throw new Error(`${tool.name}: npm-global install needs a package`);
@@ -361,6 +391,6 @@ export function assertPinned(tool) {
   }
   throw new Error(
     `${tool.name}: unknown install method "${tool.install}".\n` +
-      `Supported: release-zip, release-tar, release-tree, npm-global.`
+      `Supported: ${INSTALL_METHODS.join(", ")}.`
   );
 }

package/plugins/lisa-agy/plugin.json

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

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

@@ -76,13 +76,37 @@ function bindingsFor(surface) {
 /**
  * Install methods the toolchain runner supports.
  *
- * `release-tar` was missing here while the runner had supported it for as long
- * as gh has been pinned — so this validator would have rejected the project's
- * own manifest, and the only reason nobody hit it is that nothing ran the two
- * against each other. Kept in step with `assertPinned` in `toolchain.mjs`,
- * which is the list that actually decides.
+ * This is a deliberate copy of `INSTALL_METHODS` in `toolchain.mjs`, which is
+ * the list that actually decides. Skills are distributed as self-contained
+ * directories and nothing imports across a skill boundary, so importing the
+ * authority here would couple two skills' distribution for one array.
+ *
+ * The copy has drifted twice. First `release-tar` was missing while the runner
+ * had supported it for as long as gh has been pinned. Then `release-tree` and
+ * `release-binary` were both missing, which rejected a valid `jq` pin. Each
+ * time the only safeguard was a comment asking the next author to remember.
+ * A conformance test now compares the two sets directly, so adding a kind on
+ * either side fails until both know it.
  */
-const INSTALL_METHODS = new Set(["release-zip", "release-tar", "npm-global"]);
+const INSTALL_METHODS = new Set([
+  "release-zip",
+  "release-tar",
+  "release-tree",
+  "release-binary",
+  "npm-global",
+]);
+
+/**
+ * Download kinds — every method that fetches a URL, so every one that needs a
+ * checksum. Spelled as "not npm-global" rather than as a list, because the next
+ * download kind should inherit the obligation by default; the drift above came
+ * from lists that had to be remembered.
+ * @param {string} method An install method.
+ * @returns {boolean} Whether the method fetches a pinned artifact.
+ */
+function isDownloadKind(method) {
+  return INSTALL_METHODS.has(method) && method !== "npm-global";
+}
 
 /**
  * Validate the `secrets` block.
@@ -171,19 +195,28 @@ function validateInstallArtifact(label, entry, problems) {
     );
     return;
   }
-  // Both archive kinds, not just zip. A tarball pinned without a checksum
-  // trusts whatever the URL serves today exactly as much as a zip does, and
-  // checking only one of them meant the tool Lisa's guardrails shell out to —
-  // gh, which ships a tarball on Linux — was the one going unverified.
-  if (
-    (entry.install === "release-zip" || entry.install === "release-tar") &&
-    !(entry.url && entry.sha256)
-  ) {
+  // Every download kind, not an enumerated few. A tarball pinned without a
+  // checksum trusts whatever the URL serves today exactly as much as a zip
+  // does, and checking only one of them meant the tool Lisa's guardrails shell
+  // out to — gh, which ships a tarball on Linux — was the one going unverified.
+  // A `release-binary` matters most of all: the artifact is directly
+  // executable, so a wrong one needs no unpacking step to run.
+  if (isDownloadKind(entry.install) && !(entry.url && entry.sha256)) {
     problems.push(
       `remoteEnv install ${label} needs both url and sha256. A pinned ` +
         `version with no checksum still trusts whatever the URL serves today.`
     );
   }
+  // A tree is the one kind with no sane default entry point: the archive root
+  // is a directory, so an omitted `binary` would install a directory as a
+  // command. The runner refuses it, and a validator that accepted it would just
+  // move the failure from review to provisioning.
+  if (entry.install === "release-tree" && !entry.binary) {
+    problems.push(
+      `remoteEnv install ${label} needs "binary" — the path to the entry ` +
+        `point INSIDE the archive, such as "maestro/bin/maestro".`
+    );
+  }
   if (entry.install === "npm-global" && !entry.package) {
     problems.push(`remoteEnv install ${label} needs a package`);
   }

package/plugins/lisa-agy/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs

@@ -300,6 +300,44 @@ function installReleaseTree(tool, binDir) {
   }
 }
 
+/**
+ * Install a pinned artifact that IS the binary, with no archive around it.
+ *
+ * Several tools worth pinning publish a raw executable rather than an archive —
+ * jq ships `jq-linux-amd64` and a `sha256sum.txt`, which is ideal material for a
+ * checksummed pin and fits none of the archive kinds.
+ *
+ * Without this the only entry that passes `assertPinned` is `release-zip`, which
+ * then fails at install when `unzip` is handed a binary. A manifest entry that
+ * validates and cannot install is worse than one that is rejected outright: the
+ * error arrives during provisioning rather than during review.
+ *
+ * There is no `binary` field here, deliberately — the download is the binary,
+ * so there is nothing inside it to name.
+ * @param {object} tool Manifest entry.
+ * @param {string} binDir Directory to install into.
+ */
+function installReleaseBinary(tool, binDir) {
+  const temporary = join(binDir, `.${tool.name}-download`);
+  mkdirSync(temporary, { recursive: true });
+  try {
+    const artifact = join(temporary, tool.name);
+    execFileSync("curl", ["-fsSL", tool.url, "-o", artifact], {
+      stdio: "inherit",
+    });
+    // Verify before it reaches a directory on PATH. For this kind that ordering
+    // matters more than for the archives: the downloaded file is directly
+    // executable, so a wrong artifact placed first is a wrong artifact that can
+    // be run.
+    verifyChecksum(artifact, tool.sha256, tool.name);
+    execFileSync("install", ["-m", "0755", artifact, join(binDir, tool.name)], {
+      stdio: "inherit",
+    });
+  } finally {
+    rmSync(temporary, { recursive: true, force: true });
+  }
+}
+
 /**
  * Install a pinned global npm package.
  * @param {object} tool Manifest entry.
@@ -328,6 +366,8 @@ export function installTool(tool, binDir) {
   if (tool.install === "release-zip") installReleaseZip(tool, binDir);
   else if (tool.install === "release-tar") installReleaseTar(tool, binDir);
   else if (tool.install === "release-tree") installReleaseTree(tool, binDir);
+  else if (tool.install === "release-binary")
+    installReleaseBinary(tool, binDir);
   else installNpmGlobal(tool);
 }
 

package/plugins/lisa-agy/skills/lisa-setup-remote-env/scripts/toolchain.mjs

@@ -301,6 +301,24 @@ export function planToolchain(
   return plan;
 }
 
+/**
+ * Every install method the runner can execute — the authoritative list.
+ *
+ * `validate-config.mjs` maintains its own copy because skills are distributed
+ * as self-contained directories and nothing else imports across a skill
+ * boundary. A comment saying "keep these in step" has now failed twice — first
+ * for `release-tar`, then for `release-tree` and `release-binary` together — so
+ * the pairing is enforced by a conformance test against this export instead.
+ * Adding a kind here fails that test until the validator learns it too.
+ */
+export const INSTALL_METHODS = Object.freeze([
+  "release-zip",
+  "release-tar",
+  "release-tree",
+  "release-binary",
+  "npm-global",
+]);
+
 /**
  * Reject a manifest entry that could install something unverifiable.
  *
@@ -354,6 +372,18 @@ export function assertPinned(tool) {
     }
     return;
   }
+  // The download IS the binary, so there is no `binary` path to require — but
+  // the checksum matters more here than anywhere else, because the artifact is
+  // directly executable rather than something that has to be unpacked first.
+  if (tool.install === "release-binary") {
+    if (!tool.url || !tool.sha256) {
+      throw new Error(
+        `${tool.name}: a release-binary install needs both url and sha256.\n` +
+          `A version bump must move the checksum in the same reviewed commit.`
+      );
+    }
+    return;
+  }
   if (tool.install === "npm-global") {
     if (!tool.package)
       throw new Error(`${tool.name}: npm-global install needs a package`);
@@ -361,6 +391,6 @@ export function assertPinned(tool) {
   }
   throw new Error(
     `${tool.name}: unknown install method "${tool.install}".\n` +
-      `Supported: release-zip, release-tar, release-tree, npm-global.`
+      `Supported: ${INSTALL_METHODS.join(", ")}.`
   );
 }

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

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