@codyswann/lisa 2.332.0 → 2.332.2

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.9"
   },
   "name": "@codyswann/lisa",
-  "version": "2.332.0",
+  "version": "2.332.2",
   "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.332.0",
+  "version": "2.332.2",
   "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.332.0",
+  "version": "2.332.2",
   "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

@@ -914,9 +914,45 @@ async function main() {
       "lisa-secrets-access",
       "materialize-secrets.mjs"
     );
-    execFileSync("node", dryRun ? [materialize, "--dry-run"] : [materialize], {
-      stdio: "inherit",
-    });
+    // A failure here is fatal only when nothing else will try again.
+    //
+    // On a surface that materializes at BOTH setup and session start, this run
+    // is the floor and the hook is the authority. The two run in different
+    // environments: a cloud vendor can expose its configured variables to the
+    // agent session while the setup phase — which runs earlier, during image
+    // construction — never sees them. That is not an error state, it is the
+    // normal shape of `materializeAt: "both"`, and the hook materializes
+    // correctly moments later.
+    //
+    // Treating it as fatal cost an entire environment: setup.sh `exec`s this
+    // script, so a non-zero exit fails the vendor's setup step and Claude Code
+    // never starts at all. Trading "secrets arrive one phase later" for "the
+    // container will not boot" is a bad trade, and it regressed a case that
+    // used to work — before this surface materialized at setup, setup simply
+    // never attempted it.
+    //
+    // Every other case keeps the hard failure: an explicit `--phase=secrets`
+    // (the hook's own authoritative run) and a setup-only surface such as
+    // codex-cloud both have no second chance, so a silent pass there would
+    // hand back a session with no credentials and call it ready.
+    const retried = !requested && materializesAtSessionStart(materializeAt);
+    try {
+      execFileSync(
+        "node",
+        dryRun ? [materialize, "--dry-run"] : [materialize],
+        { stdio: "inherit" }
+      );
+    } catch (err) {
+      if (!retried) throw err;
+      console.log(
+        `\n  Secrets were not materialized during setup, and that is not fatal ` +
+          `here.\n  This surface also materializes at session start, which runs ` +
+          `with the\n  session's own environment — the usual reason setup cannot ` +
+          `see the\n  bootstrap credential. The session-start hook will retry.\n` +
+          `  If secrets are still missing INSIDE a session, that run is the one ` +
+          `to debug.`
+      );
+    }
   } else if (!requested) {
     console.log(
       `\nSecrets: materialized from a session-start hook on "${surface}", ` +

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.
  *
@@ -373,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, release-binary, 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

@@ -914,9 +914,45 @@ async function main() {
       "lisa-secrets-access",
       "materialize-secrets.mjs"
     );
-    execFileSync("node", dryRun ? [materialize, "--dry-run"] : [materialize], {
-      stdio: "inherit",
-    });
+    // A failure here is fatal only when nothing else will try again.
+    //
+    // On a surface that materializes at BOTH setup and session start, this run
+    // is the floor and the hook is the authority. The two run in different
+    // environments: a cloud vendor can expose its configured variables to the
+    // agent session while the setup phase — which runs earlier, during image
+    // construction — never sees them. That is not an error state, it is the
+    // normal shape of `materializeAt: "both"`, and the hook materializes
+    // correctly moments later.
+    //
+    // Treating it as fatal cost an entire environment: setup.sh `exec`s this
+    // script, so a non-zero exit fails the vendor's setup step and Claude Code
+    // never starts at all. Trading "secrets arrive one phase later" for "the
+    // container will not boot" is a bad trade, and it regressed a case that
+    // used to work — before this surface materialized at setup, setup simply
+    // never attempted it.
+    //
+    // Every other case keeps the hard failure: an explicit `--phase=secrets`
+    // (the hook's own authoritative run) and a setup-only surface such as
+    // codex-cloud both have no second chance, so a silent pass there would
+    // hand back a session with no credentials and call it ready.
+    const retried = !requested && materializesAtSessionStart(materializeAt);
+    try {
+      execFileSync(
+        "node",
+        dryRun ? [materialize, "--dry-run"] : [materialize],
+        { stdio: "inherit" }
+      );
+    } catch (err) {
+      if (!retried) throw err;
+      console.log(
+        `\n  Secrets were not materialized during setup, and that is not fatal ` +
+          `here.\n  This surface also materializes at session start, which runs ` +
+          `with the\n  session's own environment — the usual reason setup cannot ` +
+          `see the\n  bootstrap credential. The session-start hook will retry.\n` +
+          `  If secrets are still missing INSIDE a session, that run is the one ` +
+          `to debug.`
+      );
+    }
   } else if (!requested) {
     console.log(
       `\nSecrets: materialized from a session-start hook on "${surface}", ` +

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.
  *
@@ -373,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, release-binary, npm-global.`
+      `Supported: ${INSTALL_METHODS.join(", ")}.`
   );
 }

package/plugins/lisa-agy/plugin.json

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

@@ -914,9 +914,45 @@ async function main() {
       "lisa-secrets-access",
       "materialize-secrets.mjs"
     );
-    execFileSync("node", dryRun ? [materialize, "--dry-run"] : [materialize], {
-      stdio: "inherit",
-    });
+    // A failure here is fatal only when nothing else will try again.
+    //
+    // On a surface that materializes at BOTH setup and session start, this run
+    // is the floor and the hook is the authority. The two run in different
+    // environments: a cloud vendor can expose its configured variables to the
+    // agent session while the setup phase — which runs earlier, during image
+    // construction — never sees them. That is not an error state, it is the
+    // normal shape of `materializeAt: "both"`, and the hook materializes
+    // correctly moments later.
+    //
+    // Treating it as fatal cost an entire environment: setup.sh `exec`s this
+    // script, so a non-zero exit fails the vendor's setup step and Claude Code
+    // never starts at all. Trading "secrets arrive one phase later" for "the
+    // container will not boot" is a bad trade, and it regressed a case that
+    // used to work — before this surface materialized at setup, setup simply
+    // never attempted it.
+    //
+    // Every other case keeps the hard failure: an explicit `--phase=secrets`
+    // (the hook's own authoritative run) and a setup-only surface such as
+    // codex-cloud both have no second chance, so a silent pass there would
+    // hand back a session with no credentials and call it ready.
+    const retried = !requested && materializesAtSessionStart(materializeAt);
+    try {
+      execFileSync(
+        "node",
+        dryRun ? [materialize, "--dry-run"] : [materialize],
+        { stdio: "inherit" }
+      );
+    } catch (err) {
+      if (!retried) throw err;
+      console.log(
+        `\n  Secrets were not materialized during setup, and that is not fatal ` +
+          `here.\n  This surface also materializes at session start, which runs ` +
+          `with the\n  session's own environment — the usual reason setup cannot ` +
+          `see the\n  bootstrap credential. The session-start hook will retry.\n` +
+          `  If secrets are still missing INSIDE a session, that run is the one ` +
+          `to debug.`
+      );
+    }
   } else if (!requested) {
     console.log(
       `\nSecrets: materialized from a session-start hook on "${surface}", ` +

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.
  *
@@ -373,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, release-binary, npm-global.`
+      `Supported: ${INSTALL_METHODS.join(", ")}.`
   );
 }

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

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