@codyswann/lisa 2.341.0 → 2.341.1

package/package.json

@@ -118,7 +118,7 @@
     }
   },
   "name": "@codyswann/lisa",
-  "version": "2.341.0",
+  "version": "2.341.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.341.0",
+  "version": "2.341.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.341.0",
+  "version": "2.341.1",
   "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/SKILL.md

@@ -236,6 +236,41 @@ What the detector produces is a proposal with `<pin>`, `<release url>` and `<sha
 
 The other objections stay true and stay unfixed: most tooling has no credential and most credentials imply no tool, so notes are one signal among four and the weakest of them. They are read *after* npm scripts and MCP servers, and a note alone should be the least persuasive reason to add anything.
 
+## One command, four surfaces
+
+`lisa environment <surface> --tenant=<name>` configures one surface for one
+tenant. The only difference between them is whether Lisa can execute there:
+
+| Surface | What happens | Materializes |
+| --- | --- | --- |
+| `local` | runs here: stores the bootstrap, materializes, installs AWS profiles | on request |
+| `container` | emits an image definition and a `docker run` line | at container start |
+| `claude-web` | emits text for the environment dialog | at setup **and** session start |
+| `codex-cloud` | emits text for the environment settings | at setup |
+
+None of it needs a checkout, which is the point: the surfaces most in need of
+configuration are the ones with no repository attached.
+
+`--tenant` is required on `local` because that path **writes**. Every namespace
+is a directory under `$XDG_CONFIG_HOME`, so resolving the wrong one puts one
+tenant's credentials where another tenant's sessions read — and on a machine
+serving several, the two would share a store. The named tenant also outranks any
+`.lisa.config.json` in the working directory: someone who typed `--tenant=acme`
+means acme, whichever repository they happen to be standing in.
+
+Re-running `environment local` is how a token is **rotated**. It is not an
+installer, so it does not reinstall agents to replace one credential; it reports
+that a bootstrap is already stored and leaves it alone unless `--rotate` says
+otherwise.
+
+`workstation` remains the separate question — what binaries does this machine
+have — with no tenant and no credentials.
+
+`remote-env --emit=<surface>` still works, and is the older spelling of the same
+thing. It named the machinery rather than the task: from a laptop it reads as
+"prepare the remote environment I am currently in", which is the opposite of
+configuring a cloud environment.
+
 ## Provisioning tiers
 
 Preference order, falling back:

package/plugins/lisa/skills/lisa-setup-remote-env/SKILL.md

@@ -236,6 +236,41 @@ What the detector produces is a proposal with `<pin>`, `<release url>` and `<sha
 
 The other objections stay true and stay unfixed: most tooling has no credential and most credentials imply no tool, so notes are one signal among four and the weakest of them. They are read *after* npm scripts and MCP servers, and a note alone should be the least persuasive reason to add anything.
 
+## One command, four surfaces
+
+`lisa environment <surface> --tenant=<name>` configures one surface for one
+tenant. The only difference between them is whether Lisa can execute there:
+
+| Surface | What happens | Materializes |
+| --- | --- | --- |
+| `local` | runs here: stores the bootstrap, materializes, installs AWS profiles | on request |
+| `container` | emits an image definition and a `docker run` line | at container start |
+| `claude-web` | emits text for the environment dialog | at setup **and** session start |
+| `codex-cloud` | emits text for the environment settings | at setup |
+
+None of it needs a checkout, which is the point: the surfaces most in need of
+configuration are the ones with no repository attached.
+
+`--tenant` is required on `local` because that path **writes**. Every namespace
+is a directory under `$XDG_CONFIG_HOME`, so resolving the wrong one puts one
+tenant's credentials where another tenant's sessions read — and on a machine
+serving several, the two would share a store. The named tenant also outranks any
+`.lisa.config.json` in the working directory: someone who typed `--tenant=acme`
+means acme, whichever repository they happen to be standing in.
+
+Re-running `environment local` is how a token is **rotated**. It is not an
+installer, so it does not reinstall agents to replace one credential; it reports
+that a bootstrap is already stored and leaves it alone unless `--rotate` says
+otherwise.
+
+`workstation` remains the separate question — what binaries does this machine
+have — with no tenant and no credentials.
+
+`remote-env --emit=<surface>` still works, and is the older spelling of the same
+thing. It named the machinery rather than the task: from a laptop it reads as
+"prepare the remote environment I am currently in", which is the opposite of
+configuring a cloud environment.
+
 ## Provisioning tiers
 
 Preference order, falling back:

package/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.341.0",
+  "version": "2.341.1",
   "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/SKILL.md

@@ -236,6 +236,41 @@ What the detector produces is a proposal with `<pin>`, `<release url>` and `<sha
 
 The other objections stay true and stay unfixed: most tooling has no credential and most credentials imply no tool, so notes are one signal among four and the weakest of them. They are read *after* npm scripts and MCP servers, and a note alone should be the least persuasive reason to add anything.
 
+## One command, four surfaces
+
+`lisa environment <surface> --tenant=<name>` configures one surface for one
+tenant. The only difference between them is whether Lisa can execute there:
+
+| Surface | What happens | Materializes |
+| --- | --- | --- |
+| `local` | runs here: stores the bootstrap, materializes, installs AWS profiles | on request |
+| `container` | emits an image definition and a `docker run` line | at container start |
+| `claude-web` | emits text for the environment dialog | at setup **and** session start |
+| `codex-cloud` | emits text for the environment settings | at setup |
+
+None of it needs a checkout, which is the point: the surfaces most in need of
+configuration are the ones with no repository attached.
+
+`--tenant` is required on `local` because that path **writes**. Every namespace
+is a directory under `$XDG_CONFIG_HOME`, so resolving the wrong one puts one
+tenant's credentials where another tenant's sessions read — and on a machine
+serving several, the two would share a store. The named tenant also outranks any
+`.lisa.config.json` in the working directory: someone who typed `--tenant=acme`
+means acme, whichever repository they happen to be standing in.
+
+Re-running `environment local` is how a token is **rotated**. It is not an
+installer, so it does not reinstall agents to replace one credential; it reports
+that a bootstrap is already stored and leaves it alone unless `--rotate` says
+otherwise.
+
+`workstation` remains the separate question — what binaries does this machine
+have — with no tenant and no credentials.
+
+`remote-env --emit=<surface>` still works, and is the older spelling of the same
+thing. It named the machinery rather than the task: from a laptop it reads as
+"prepare the remote environment I am currently in", which is the opposite of
+configuring a cloud environment.
+
 ## Provisioning tiers
 
 Preference order, falling back:

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.341.0",
+  "version": "2.341.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.341.0",
+  "version": "2.341.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.341.0",
+  "version": "2.341.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.341.0",
+  "version": "2.341.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.341.0",
+  "version": "2.341.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.341.0",
+  "version": "2.341.1",
   "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/SKILL.md

@@ -236,6 +236,41 @@ What the detector produces is a proposal with `<pin>`, `<release url>` and `<sha
 
 The other objections stay true and stay unfixed: most tooling has no credential and most credentials imply no tool, so notes are one signal among four and the weakest of them. They are read *after* npm scripts and MCP servers, and a note alone should be the least persuasive reason to add anything.
 
+## One command, four surfaces
+
+`lisa environment <surface> --tenant=<name>` configures one surface for one
+tenant. The only difference between them is whether Lisa can execute there:
+
+| Surface | What happens | Materializes |
+| --- | --- | --- |
+| `local` | runs here: stores the bootstrap, materializes, installs AWS profiles | on request |
+| `container` | emits an image definition and a `docker run` line | at container start |
+| `claude-web` | emits text for the environment dialog | at setup **and** session start |
+| `codex-cloud` | emits text for the environment settings | at setup |
+
+None of it needs a checkout, which is the point: the surfaces most in need of
+configuration are the ones with no repository attached.
+
+`--tenant` is required on `local` because that path **writes**. Every namespace
+is a directory under `$XDG_CONFIG_HOME`, so resolving the wrong one puts one
+tenant's credentials where another tenant's sessions read — and on a machine
+serving several, the two would share a store. The named tenant also outranks any
+`.lisa.config.json` in the working directory: someone who typed `--tenant=acme`
+means acme, whichever repository they happen to be standing in.
+
+Re-running `environment local` is how a token is **rotated**. It is not an
+installer, so it does not reinstall agents to replace one credential; it reports
+that a bootstrap is already stored and leaves it alone unless `--rotate` says
+otherwise.
+
+`workstation` remains the separate question — what binaries does this machine
+have — with no tenant and no credentials.
+
+`remote-env --emit=<surface>` still works, and is the older spelling of the same
+thing. It named the machinery rather than the task: from a laptop it reads as
+"prepare the remote environment I am currently in", which is the opposite of
+configuring a cloud environment.
+
 ## Provisioning tiers
 
 Preference order, falling back:

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.341.0",
+  "version": "2.341.1",
   "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/SKILL.md

@@ -236,6 +236,41 @@ What the detector produces is a proposal with `<pin>`, `<release url>` and `<sha
 
 The other objections stay true and stay unfixed: most tooling has no credential and most credentials imply no tool, so notes are one signal among four and the weakest of them. They are read *after* npm scripts and MCP servers, and a note alone should be the least persuasive reason to add anything.
 
+## One command, four surfaces
+
+`lisa environment <surface> --tenant=<name>` configures one surface for one
+tenant. The only difference between them is whether Lisa can execute there:
+
+| Surface | What happens | Materializes |
+| --- | --- | --- |
+| `local` | runs here: stores the bootstrap, materializes, installs AWS profiles | on request |
+| `container` | emits an image definition and a `docker run` line | at container start |
+| `claude-web` | emits text for the environment dialog | at setup **and** session start |
+| `codex-cloud` | emits text for the environment settings | at setup |
+
+None of it needs a checkout, which is the point: the surfaces most in need of
+configuration are the ones with no repository attached.
+
+`--tenant` is required on `local` because that path **writes**. Every namespace
+is a directory under `$XDG_CONFIG_HOME`, so resolving the wrong one puts one
+tenant's credentials where another tenant's sessions read — and on a machine
+serving several, the two would share a store. The named tenant also outranks any
+`.lisa.config.json` in the working directory: someone who typed `--tenant=acme`
+means acme, whichever repository they happen to be standing in.
+
+Re-running `environment local` is how a token is **rotated**. It is not an
+installer, so it does not reinstall agents to replace one credential; it reports
+that a bootstrap is already stored and leaves it alone unless `--rotate` says
+otherwise.
+
+`workstation` remains the separate question — what binaries does this machine
+have — with no tenant and no credentials.
+
+`remote-env --emit=<surface>` still works, and is the older spelling of the same
+thing. It named the machinery rather than the task: from a laptop it reads as
+"prepare the remote environment I am currently in", which is the opposite of
+configuring a cloud environment.
+
 ## Provisioning tiers
 
 Preference order, falling back:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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