@codyswann/lisa 2.317.3 → 2.317.5

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

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

package/plugins/lisa-copilot/scripts/remote-agent-aws-setup.sh

@@ -3,8 +3,14 @@
 # source copied into every generated Lisa agent plugin.
 #
 # Required secret:
-#   LISA_AWS_BOOTSTRAP_JSON  Complete SecretString emitted by cdkstarter's
-#                            remote-agent IAM kit.
+#   LISA_AWS_BOOTSTRAP_JSON  The complete remote-agent bootstrap bundle, as one
+#                            JSON value. cdkstarter's IAM kit emits it, but this
+#                            script neither knows nor cares which store it came
+#                            from — resolve it through lisa-secrets-access like
+#                            any other secret. Note that a project whose
+#                            provider is AWS Secrets Manager cannot keep it
+#                            there: reading it would need the very credential it
+#                            contains.
 # Optional plain variables:
 #   LISA_REMOTE_AGENT       claude | codex | cursor | copilot | agy | opencode
 #   LISA_AWS_DEFAULT_PROFILE  Defaults to dev, then the first available profile.

package/plugins/lisa-copilot/skills/lisa-secrets-access/SKILL.md

@@ -198,6 +198,13 @@ Values never enter that process, so its output cannot leak one even if logged.
 | `aws` | `aws secretsmanager get-secret-value --secret-id <name>` | not implemented |
 | `vault` | `vault kv get -field=<name> <path>` | not implemented |
 
+**A provider cannot hold its own bootstrap.** With `provider: "aws"`, reading any
+secret needs AWS credentials — so the AWS bootstrap bundle
+(`LISA_AWS_BOOTSTRAP_JSON`, see `lisa-setup-remote-aws`) cannot live there:
+resolving it would require the very credential it contains. Keep that one in a
+different provider. The same applies to any provider whose own access key is a
+secret you would otherwise store inside it.
+
 Unimplemented providers fail with a message naming where to add them, rather than failing obscurely. Do not claim support that does not exist.
 
 Cache **in-process only**. Never write a resolved value to disk except through the materialization contract above.

package/plugins/lisa-copilot/skills/lisa-setup-remote-aws/SKILL.md

@@ -30,16 +30,41 @@ Install the vendor-neutral AWS bootstrap into the current repository.
    `.github/workflows/copilot-setup-steps.yml`; and it always writes
    `docs/remote-agent-aws.md`.
 4. Run `bash -n scripts/remote-agent-aws-setup.sh`.
-5. Never write or request the actual bootstrap SecretString in repository
-   files. Tell the operator to retrieve the `remote-agent-credentials` secret
-   from the shared AWS account and paste its complete SecretString into the
-   platform secret named `LISA_AWS_BOOTSTRAP_JSON`. The default cdkstarter
-   secret name is `remote-agent-credentials`; downstream infrastructure may
-   configure a different name. Pass that name with `--secret-name` so the
-   generated runbook contains the exact retrieval command.
+5. Never write or request the actual bootstrap bundle in repository files. Tell
+   the operator where to obtain it and where to put it — see **Where the bundle
+   lives** below. Pass `--secret-name` when the source names it something other
+   than `remote-agent-credentials`, so the generated runbook contains the exact
+   retrieval command.
 6. Report the external step that remains: configure that one secret in the
    remote environment and launch a smoke session.
 
+## Where the bundle lives
+
+`LISA_AWS_BOOTSTRAP_JSON` is **just another secret**, and it belongs wherever
+the project keeps its secrets — resolved through `lisa-secrets-access` like
+everything else. It is not tied to any one store.
+
+Whoever provisions the IAM user emits the bundle somewhere. `cdkstarter` writes
+it to AWS Secrets Manager as `remote-agent-credentials`, but that is where it is
+*emitted*, not where it must *live*. Copy it once into the project's configured
+provider and read it from there.
+
+**Do not keep it in two stores.** A bundle sitting in Secrets Manager *and* in
+the platform's secret store is two live copies of one credential: rotate the
+IAM key and whichever copy you forget keeps authenticating until it doesn't,
+with nothing to say which is current. That is the drift the single-store rule in
+`lisa-secrets-access` exists to prevent, and this credential is not exempt.
+
+**One provider cannot serve this particular secret.** If `secrets.provider` is
+`aws`, reading the bundle requires AWS credentials — and the bundle *is* the AWS
+credential. Anything else works: Bitwarden, 1Password, Doppler, Vault, or a
+platform secret store. Pick the one that is not the thing being bootstrapped.
+
+On a surface that materializes (see `lisa-secrets-access`), the bundle arrives
+in `secrets.env` with everything else, so the project hook can run this setup
+script after materialization with no extra plumbing. On a surface that reads
+through live, resolve it at the point of use.
+
 ## Contract
 
 A future coding agent is supported without an AWS change when its remote

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

@@ -10,17 +10,27 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **two one-line calls into the repository**. Nothing is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       bash scripts/lisa-remote-env/setup.sh
-maintenance: bash scripts/lisa-remote-env/setup.sh
+setup:       <install> && bash scripts/lisa-remote-env/setup.sh
+maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
 ```
 
-They are the same script. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
+`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+
+They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
 The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
 
+### Why the install has to come first
+
+**A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
+
+`node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
+
+Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+
 ## The three phases
 
 1. **Toolchain** — assert what must already be present, install what is not.
@@ -110,8 +120,11 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      bash scripts/lisa-remote-env/setup.sh
-Maintenance:       bash scripts/lisa-remote-env/setup.sh
+Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
+Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
+                   (<install> is the project's own: bun install, npm ci, ...
+                   It must precede the script — on a fresh container
+                   node_modules is the only copy of the skills present.)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -136,7 +149,7 @@ Checked when setup runs, not at 3am:
 
 - the environment exists and is bound to **this** repository as its default checkout;
 - the bootstrap credential resolves;
-- Lisa has been applied to the repository, so its skills are present in that checkout.
+- either a checkout-local Lisa skill is present, or the project dependency install has made the pinned `@codyswann/lisa` package available under `node_modules`.
 
 Fail with a message naming what is missing. Never provision-and-hope.
 

package/plugins/lisa-copilot/skills/lisa-setup-remote-env/assets/setup.sh

@@ -23,13 +23,26 @@ if ! command -v node >/dev/null 2>&1; then
   exit 1
 fi
 
-# The skill ships under whichever agent directory this project uses. Search
-# rather than hardcode, so one entrypoint serves every supported harness.
+# Where the skill lives depends on how this project's harness receives it, and
+# the two delivery models differ in a way that matters here.
+#
+# OpenCode and Antigravity get skills written INTO the checkout by `lisa apply`,
+# so a clone already carries them. Claude and Codex receive them as an installed
+# plugin, which lives in the user's home directory and is emphatically NOT part
+# of a clone. A fresh remote container is the second case every time: it clones
+# the repository and has never run a plugin install.
+#
+# So the agent directories are searched first — they are the cheapest hit and
+# need nothing installed — and the npm package is the fallback that makes the
+# plugin-delivered harnesses work at all. Lisa is a dependency of every project
+# it is applied to, so `node_modules` carries the same skill at the version that
+# project pins, which is the version its setup should run.
 runner=""
 for candidate in \
   ".claude/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".agents/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
-  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
+  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
+  "node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
   if [ -f "$candidate" ]; then
     runner="$candidate"
     break
@@ -37,8 +50,19 @@ for candidate in \
 done
 
 if [ -z "$runner" ]; then
-  echo "Cannot find the lisa-setup-remote-env skill in this checkout." >&2
-  echo "Run 'lisa apply' so the skills are present, then re-run setup." >&2
+  echo "Cannot find the lisa-setup-remote-env skill." >&2
+  echo >&2
+  echo "Searched the agent skill directories and node_modules. On a remote" >&2
+  echo "container the usual cause is that dependencies have not been installed" >&2
+  echo "yet: Claude and Codex receive Lisa skills as an installed plugin, which" >&2
+  echo "is not part of a clone, so node_modules is the only copy present." >&2
+  echo >&2
+  echo "Install dependencies before this script runs. The environment's setup" >&2
+  echo "command should be the install and this script together, for example:" >&2
+  echo "  bun install && bash scripts/lisa-remote-env/setup.sh" >&2
+  echo >&2
+  echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
+  echo "present, then re-run setup." >&2
   exit 1
 fi
 

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

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

package/plugins/lisa-cursor/scripts/remote-agent-aws-setup.sh

@@ -3,8 +3,14 @@
 # source copied into every generated Lisa agent plugin.
 #
 # Required secret:
-#   LISA_AWS_BOOTSTRAP_JSON  Complete SecretString emitted by cdkstarter's
-#                            remote-agent IAM kit.
+#   LISA_AWS_BOOTSTRAP_JSON  The complete remote-agent bootstrap bundle, as one
+#                            JSON value. cdkstarter's IAM kit emits it, but this
+#                            script neither knows nor cares which store it came
+#                            from — resolve it through lisa-secrets-access like
+#                            any other secret. Note that a project whose
+#                            provider is AWS Secrets Manager cannot keep it
+#                            there: reading it would need the very credential it
+#                            contains.
 # Optional plain variables:
 #   LISA_REMOTE_AGENT       claude | codex | cursor | copilot | agy | opencode
 #   LISA_AWS_DEFAULT_PROFILE  Defaults to dev, then the first available profile.

package/plugins/lisa-cursor/skills/lisa-secrets-access/SKILL.md

@@ -198,6 +198,13 @@ Values never enter that process, so its output cannot leak one even if logged.
 | `aws` | `aws secretsmanager get-secret-value --secret-id <name>` | not implemented |
 | `vault` | `vault kv get -field=<name> <path>` | not implemented |
 
+**A provider cannot hold its own bootstrap.** With `provider: "aws"`, reading any
+secret needs AWS credentials — so the AWS bootstrap bundle
+(`LISA_AWS_BOOTSTRAP_JSON`, see `lisa-setup-remote-aws`) cannot live there:
+resolving it would require the very credential it contains. Keep that one in a
+different provider. The same applies to any provider whose own access key is a
+secret you would otherwise store inside it.
+
 Unimplemented providers fail with a message naming where to add them, rather than failing obscurely. Do not claim support that does not exist.
 
 Cache **in-process only**. Never write a resolved value to disk except through the materialization contract above.

package/plugins/lisa-cursor/skills/lisa-setup-remote-aws/SKILL.md

@@ -30,16 +30,41 @@ Install the vendor-neutral AWS bootstrap into the current repository.
    `.github/workflows/copilot-setup-steps.yml`; and it always writes
    `docs/remote-agent-aws.md`.
 4. Run `bash -n scripts/remote-agent-aws-setup.sh`.
-5. Never write or request the actual bootstrap SecretString in repository
-   files. Tell the operator to retrieve the `remote-agent-credentials` secret
-   from the shared AWS account and paste its complete SecretString into the
-   platform secret named `LISA_AWS_BOOTSTRAP_JSON`. The default cdkstarter
-   secret name is `remote-agent-credentials`; downstream infrastructure may
-   configure a different name. Pass that name with `--secret-name` so the
-   generated runbook contains the exact retrieval command.
+5. Never write or request the actual bootstrap bundle in repository files. Tell
+   the operator where to obtain it and where to put it — see **Where the bundle
+   lives** below. Pass `--secret-name` when the source names it something other
+   than `remote-agent-credentials`, so the generated runbook contains the exact
+   retrieval command.
 6. Report the external step that remains: configure that one secret in the
    remote environment and launch a smoke session.
 
+## Where the bundle lives
+
+`LISA_AWS_BOOTSTRAP_JSON` is **just another secret**, and it belongs wherever
+the project keeps its secrets — resolved through `lisa-secrets-access` like
+everything else. It is not tied to any one store.
+
+Whoever provisions the IAM user emits the bundle somewhere. `cdkstarter` writes
+it to AWS Secrets Manager as `remote-agent-credentials`, but that is where it is
+*emitted*, not where it must *live*. Copy it once into the project's configured
+provider and read it from there.
+
+**Do not keep it in two stores.** A bundle sitting in Secrets Manager *and* in
+the platform's secret store is two live copies of one credential: rotate the
+IAM key and whichever copy you forget keeps authenticating until it doesn't,
+with nothing to say which is current. That is the drift the single-store rule in
+`lisa-secrets-access` exists to prevent, and this credential is not exempt.
+
+**One provider cannot serve this particular secret.** If `secrets.provider` is
+`aws`, reading the bundle requires AWS credentials — and the bundle *is* the AWS
+credential. Anything else works: Bitwarden, 1Password, Doppler, Vault, or a
+platform secret store. Pick the one that is not the thing being bootstrapped.
+
+On a surface that materializes (see `lisa-secrets-access`), the bundle arrives
+in `secrets.env` with everything else, so the project hook can run this setup
+script after materialization with no extra plumbing. On a surface that reads
+through live, resolve it at the point of use.
+
 ## Contract
 
 A future coding agent is supported without an AWS change when its remote

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

@@ -10,17 +10,27 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **two one-line calls into the repository**. Nothing is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       bash scripts/lisa-remote-env/setup.sh
-maintenance: bash scripts/lisa-remote-env/setup.sh
+setup:       <install> && bash scripts/lisa-remote-env/setup.sh
+maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
 ```
 
-They are the same script. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
+`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+
+They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
 The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
 
+### Why the install has to come first
+
+**A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
+
+`node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
+
+Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+
 ## The three phases
 
 1. **Toolchain** — assert what must already be present, install what is not.
@@ -110,8 +120,11 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      bash scripts/lisa-remote-env/setup.sh
-Maintenance:       bash scripts/lisa-remote-env/setup.sh
+Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
+Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
+                   (<install> is the project's own: bun install, npm ci, ...
+                   It must precede the script — on a fresh container
+                   node_modules is the only copy of the skills present.)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -136,7 +149,7 @@ Checked when setup runs, not at 3am:
 
 - the environment exists and is bound to **this** repository as its default checkout;
 - the bootstrap credential resolves;
-- Lisa has been applied to the repository, so its skills are present in that checkout.
+- either a checkout-local Lisa skill is present, or the project dependency install has made the pinned `@codyswann/lisa` package available under `node_modules`.
 
 Fail with a message naming what is missing. Never provision-and-hope.
 

package/plugins/lisa-cursor/skills/lisa-setup-remote-env/assets/setup.sh

@@ -23,13 +23,26 @@ if ! command -v node >/dev/null 2>&1; then
   exit 1
 fi
 
-# The skill ships under whichever agent directory this project uses. Search
-# rather than hardcode, so one entrypoint serves every supported harness.
+# Where the skill lives depends on how this project's harness receives it, and
+# the two delivery models differ in a way that matters here.
+#
+# OpenCode and Antigravity get skills written INTO the checkout by `lisa apply`,
+# so a clone already carries them. Claude and Codex receive them as an installed
+# plugin, which lives in the user's home directory and is emphatically NOT part
+# of a clone. A fresh remote container is the second case every time: it clones
+# the repository and has never run a plugin install.
+#
+# So the agent directories are searched first — they are the cheapest hit and
+# need nothing installed — and the npm package is the fallback that makes the
+# plugin-delivered harnesses work at all. Lisa is a dependency of every project
+# it is applied to, so `node_modules` carries the same skill at the version that
+# project pins, which is the version its setup should run.
 runner=""
 for candidate in \
   ".claude/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".agents/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
-  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
+  ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
+  "node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
   if [ -f "$candidate" ]; then
     runner="$candidate"
     break
@@ -37,8 +50,19 @@ for candidate in \
 done
 
 if [ -z "$runner" ]; then
-  echo "Cannot find the lisa-setup-remote-env skill in this checkout." >&2
-  echo "Run 'lisa apply' so the skills are present, then re-run setup." >&2
+  echo "Cannot find the lisa-setup-remote-env skill." >&2
+  echo >&2
+  echo "Searched the agent skill directories and node_modules. On a remote" >&2
+  echo "container the usual cause is that dependencies have not been installed" >&2
+  echo "yet: Claude and Codex receive Lisa skills as an installed plugin, which" >&2
+  echo "is not part of a clone, so node_modules is the only copy present." >&2
+  echo >&2
+  echo "Install dependencies before this script runs. The environment's setup" >&2
+  echo "command should be the install and this script together, for example:" >&2
+  echo "  bun install && bash scripts/lisa-remote-env/setup.sh" >&2
+  echo >&2
+  echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
+  echo "present, then re-run setup." >&2
   exit 1
 fi
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "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.317.3",
+  "version": "2.317.5",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"