@codyswann/lisa 2.332.1 → 2.332.2

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.9"
   },
   "name": "@codyswann/lisa",
-  "version": "2.332.1",
+  "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.1",
+  "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.1",
+  "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-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/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/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.332.1",
+  "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-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-cdk/.claude-plugin/plugin.json

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

package/plugins/lisa-copilot/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-cursor/.claude-plugin/plugin.json

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

package/plugins/lisa-cursor/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-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "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": "2.332.1",
+  "version": "2.332.2",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"