@codyswann/lisa 2.175.2 → 2.176.0

package/plugins/lisa-cursor/rules/security-audit-handling-reference.mdc

@@ -5,20 +5,29 @@ alwaysApply: false
 
 # Security Audit Handling
 
-If `git push` fails because the pre-push hook reports security vulnerabilities, follow these steps. Never use `--no-verify`, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
+If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Only one rung pauses to ask a human. Never use `--no-verify`, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
 
-## Fix before ignore
+## The decision ladder
 
-1. Fix the root cause first: upgrade or override the actually-vulnerable leaf package to a patched compatible version, regenerate the lockfile, and retry the gate.
-2. Only if no safe fix exists, ask the user to make the risk-acceptance decision. Add a narrow documented ignore for the specific advisory, package, and reason.
-3. Never add a blanket audit bypass, lower an audit level, or self-approve a new risk-acceptance entry.
+The remediation for any high/critical advisory is a simple, ordered decision — not a question to forward to the user. For each advisory, take the **first** action that is possible:
+
+1. **Update the offending package** to a patched version.
+2. **If that's not possible**, force a resolution/override on the vulnerable leaf package.
+3. **If that's not possible**, evaluate whether the advisory actually affects the project.
+4. **If it affects the project** (and 1 and 2 weren't possible), ask a human what to do.
+5. **If it doesn't affect the project**, add it to the ignore list yourself.
+
+Steps 1, 2, 3, and 5 are autonomous. Do not stop and ask the user except at step 4, and only after you have genuinely attempted steps 1 and 2 and performed the step-3 evaluation.
 
 ## Node.js Projects (GHSA advisories)
 
-1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output
-2. Check the advisory URL to determine if a patched version of the vulnerable package exists
-3. If a patched version exists: add a resolution/override in package.json to force the patched version (add to both `resolutions` and `overrides` sections), then run the package manager install command to regenerate the lockfile, commit the changes, and retry the push
-4. If no patched version exists and the vulnerability is safe for this project (e.g., transitive dependency with no untrusted input, devDeps only, or build tool only): ask the user to make the risk-acceptance decision, then add an exclusion entry to `audit.ignore.local.json` with the format `{"id": "GHSA-xxx", "package": "pkg-name", "reason": "why this is safe for this project"}`, then commit and retry the push
+1. Note the GHSA ID(s), affected package(s), and advisory URL from the error output.
+2. Check the advisory URL to determine whether a patched version of the vulnerable package exists.
+3. **Step 1 — update:** If a patched version exists and is compatible, add a resolution/override in `package.json` to force the patched version (add to **both** `resolutions` and `overrides`), run the package manager install to regenerate the lockfile, commit, and retry the push.
+4. **Step 2 — force override:** If no straight upgrade lands the patched version but a compatible patched version exists somewhere on the graph, pin it via `resolutions` + `overrides` on the **leaf** package (see "Override the vulnerable package, not its parent" below), regenerate the lockfile, commit, and retry.
+5. **Step 3 — evaluate impact:** If neither an upgrade nor an override is possible (no fixed version exists, or every compatible pin breaks a dependent), determine whether the vulnerability actually affects this project. Consider: is the vulnerable code path reachable from this project's usage? Does it process untrusted input? Is the dependency runtime, or dev/build-only? Record the conclusion.
+6. **Step 4 — escalate:** If the evaluation shows the vulnerability **does** affect the project and neither step 1 nor step 2 was possible, ask the user what to do. This is the only step that pauses for a human.
+7. **Step 5 — ignore:** If the evaluation shows the vulnerability **does not** affect the project, add an exclusion entry to `audit.ignore.local.json` yourself, in the format `{"id": "GHSA-xxx", "package": "pkg-name", "reason": "<impact evaluation: why this advisory does not affect this project>"}`, then commit and retry the push. No human approval is required for this step — the `reason` field is the record of your evaluation.
 
 ### Critical: Override the vulnerable package, not its parent
 
@@ -26,16 +35,26 @@ When the audit output shows a dependency chain like `@expo/cli › glob › mini
 
 **Never override a parent package to force a lower major version** — other packages in the project may depend on a newer major version, and a resolution/override forces ALL installations to the specified version. For example, overriding `glob` to `^8.1.0` will break `@expo/cli` which requires `glob@^13.0.0`, causing `expo prebuild` to fail with `files.map is not a function`.
 
-Before adding a resolution/override, verify:
-- You are targeting the **actually vulnerable package**, not a parent in the chain
-- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`)
-- The override does not **downgrade** a package across a major version boundary that other dependencies require
+Before adding a resolution/override (step 2), verify:
+- You are targeting the **actually vulnerable package**, not a parent in the chain.
+- The override version is **compatible with all dependents** (check with `bun why <package>` or `npm ls <package>`).
+- The override does not **downgrade** a package across a major version boundary that other dependencies require.
+
+If any of these checks fail, the override is "not possible" for the purposes of the ladder — drop to step 3 (evaluate impact).
+
+### Never
+
+- Never add a blanket audit bypass or lower the configured audit level.
+- Never jump to step 4 (ask a human) before genuinely attempting steps 1–3.
+- Never add a step-5 ignore entry without an impact evaluation recorded in its `reason`.
 
 ## Rails Projects (bundler-audit)
 
-1. Note the advisory ID, affected gem, and advisory URL from the error output
-2. Check if a patched version of the gem exists
-3. If a patched version exists:
-   - If the gem is a **direct dependency** (listed in Gemfile): update its version constraint in Gemfile, run `bundle update <gem>`, commit the changes, and retry the push
-   - If the gem is a **transitive dependency** (not in Gemfile, only in Gemfile.lock): run `bundle update <gem>` to pull the patched version without changing the Gemfile, commit the lockfile change, and retry the push
-4. If no patched version exists and the vulnerability is safe for this project: document the exception and retry the push
+Same ladder, bundler mechanics:
+
+1. Note the advisory ID, affected gem, and advisory URL from the error output.
+2. Check whether a patched version of the gem exists.
+3. **Step 1 — update:** If a patched version exists:
+   - **Direct dependency** (in Gemfile): update its version constraint, run `bundle update <gem>`, commit, retry.
+   - **Transitive dependency** (only in Gemfile.lock): run `bundle update <gem>` to pull the patched version without changing the Gemfile, commit the lockfile change, retry.
+4. **Steps 3–5 — no patch:** If no patched version exists, evaluate whether the advisory affects the project. If it **does** and no fix is possible, ask the user (step 4). If it **does not**, document the exception and retry (step 5).

package/plugins/lisa-cursor/rules/security-audit-handling.mdc

@@ -5,36 +5,41 @@ alwaysApply: true
 
 # Security Audit Handling (load-bearing)
 
-If `git push` fails because the pre-push hook reports security vulnerabilities, follow the rules below. **Never use `--no-verify`**, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
+If `git push` fails because the pre-push hook reports security vulnerabilities, work the decision ladder below **autonomously**. Do not stop to ask the user except at the one rung that explicitly requires it. **Never use `--no-verify`**, `HUSKY=0`, `core.hooksPath`, or any other hook bypass to skip the security audit.
 
-## Fix before ignore
+## Decision ladder (do not skip rungs)
 
-1. Fix the root cause first: upgrade or override the actually-vulnerable leaf package to a patched compatible version, regenerate the lockfile, and retry the gate.
-2. Only if no safe fix exists, ask the user to make the risk-acceptance decision. Add a narrow documented ignore for the specific advisory, package, and reason.
-3. Never add a blanket audit bypass, lower an audit level, or self-approve a new risk-acceptance entry.
+For each high/critical advisory the gate reports, take the **first** action that is possible:
 
-## Core rule
+1. **Update the offending package.** Upgrade the actually-vulnerable leaf package to a patched compatible version, regenerate the lockfile, retry the gate. Done.
+2. **If an upgrade isn't possible** (no compatible patched version on the dependency graph): **force a resolution/override** on the vulnerable leaf package (both `resolutions` and `overrides`), regenerate the lockfile, retry. Done.
+3. **If an override isn't possible either** (would break a dependent, or no fixed version exists anywhere): **evaluate whether the advisory actually affects this project** — is the vulnerable code path reachable, does it process untrusted input, is it runtime vs. dev/build-only?
+4. **If it does affect the project** and neither (1) nor (2) was possible: **ask a human** what to do. This is the only rung that pauses for a person.
+5. **If it does not affect the project**: **add a documented exclusion yourself** to `audit.ignore.local.json` (`{"id", "package", "reason"}` — reason states the impact evaluation), commit, retry. No human approval needed.
+
+Steps 1, 2, 3, and 5 are autonomous. Only step 4 escalates.
+
+## Core override rule
 
 Override the actually-vulnerable **leaf package**, not its parent. The audit chain shows `parent › intermediate › vulnerable` — only the vulnerable leaf needs the override.
 
 **Never override a parent package to force a lower major version.** Other packages may depend on the newer major; a forced downgrade breaks them.
 
-Before adding any override, verify:
+Before adding any override (step 2), verify:
 - You are targeting the actually-vulnerable package, not a parent in the chain.
 - The override is compatible with all dependents (check via `bun why <pkg>` or `npm ls <pkg>`).
 - The override does not downgrade across a major version boundary other deps require.
 
-## Node.js (GHSA)
+If those checks fail, the override is "not possible" — drop to step 3.
+
+## Never
 
-1. Note GHSA ID, package, advisory URL.
-2. If a patched version exists: add a resolution AND override in `package.json` for the leaf package, regenerate the lockfile, commit, retry.
-3. If no patch but safe (transitive, no untrusted input, dev/build only): ask the user to make the risk-acceptance decision, then add an exclusion to `audit.ignore.local.json` with `{"id", "package", "reason"}`, commit, retry.
+- Never add a blanket audit bypass or lower the configured audit level.
+- Never escalate to a human (step 4) before genuinely attempting steps 1–3.
+- Never add an ignore entry (step 5) without an impact evaluation recorded in its `reason`. (This is a policy requirement enforced by convention. The `reason` field is not programmatically validated by Lisa tooling, so its presence relies on Claude following this rule faithfully.)
 
 ## Rails (bundler-audit)
 
-1. Note advisory ID, gem, URL.
-2. If direct dep with patch: update Gemfile constraint, `bundle update <gem>`, commit, retry.
-3. If transitive with patch: `bundle update <gem>` to bump the lockfile only, commit, retry.
-4. If no patch but safe: document the exception, retry.
+Same ladder. Note advisory ID, gem, URL. (1) Direct dep with patch → update Gemfile constraint, `bundle update <gem>`, retry. (2) Transitive with patch → `bundle update <gem>` to bump the lockfile only, retry. (3) No patch → evaluate impact. (4) Affects the project → ask a human. (5) Doesn't affect → document the exception, retry.
 
 Full procedure with examples: [reference/security-audit-handling.md](security-audit-handling-reference.mdc).

package/plugins/lisa-cursor/rules/upstream-to-lisa-reference.mdc

@@ -0,0 +1,49 @@
+---
+description: "Upstream To Lisa"
+alwaysApply: false
+---
+
+# Upstream To Lisa
+
+When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project. This rule defines what to do so the fix is both unblocking *now* and durable *later*.
+
+## When this applies
+
+You are working in a downstream/host project (not the Lisa source repo) and you discover one of:
+
+- A bug or gap in a Lisa-distributed **template, rule, skill, agent, hook, or CI workflow**.
+- A **governance pattern** discovered here that should be generalized back into Lisa's templates so every project benefits.
+- Anything where the file you want to change is **Lisa-managed** — it carries Lisa governance markers, lives in a path Lisa owns, or any edit would be **overwritten on the next `lisa apply`**.
+
+The defining test: *if I fix this only here, does `lisa apply` wipe it out next time?* If yes, the root cause lives in Lisa and must be upstreamed.
+
+## What to do — both steps, always
+
+### 1. Fix it locally so you are not blocked
+
+Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land. Treat the local change as temporary — it will be clobbered when the upstream fix ships and Lisa re-applies. That is expected and fine; the upstream issue (step 2) is what makes it durable.
+
+### 2. File an upstream issue in the Lisa repository
+
+Use the `github-write-issue` skill (`lisa:github-write-issue`) to create a GitHub Issue **in Lisa's source repository `CodySwannGT/lisa`** — not in this project's own repo. The skill uses the `gh` CLI; the target repo must be `CodySwannGT/lisa` (e.g. `gh issue create --repo CodySwannGT/lisa ...`), because the agent's default repo is this host project.
+
+The issue should capture, following the skill's three-audience / acceptance-criteria conventions:
+
+- **Root cause** — which Lisa template/rule/skill/agent/hook/workflow is wrong or missing, with the path under `plugins/src/...` (or the relevant template source) if known.
+- **Symptom** — what broke or was missing in *this* project, and how it surfaced. Reference this project so the fix can be validated against a real case.
+- **Proposed durable fix** — the change to make in Lisa's source so it propagates to all projects on the next apply.
+- **Local stopgap applied** — note that a temporary local fix is in place here, so the maintainer knows the host project is unblocked and the local change will be superseded.
+
+## Do not
+
+- Do **not** only fix it locally and move on. The local fix is throwaway; without the upstream issue the root cause is lost and re-breaks for every project on the next apply.
+- Do **not** edit Lisa's templates from inside this project. You are not in the Lisa repo; those edits don't exist upstream and get overwritten — they create the illusion of a fix while the real source stays broken.
+- Do **not** file the issue in this project's own repo. The durable fix is tracked in `CodySwannGT/lisa`.
+
+## Access fallback
+
+If you lack permission to create an issue in `CodySwannGT/lisa`, do not silently drop it. Surface the situation to the user along with the fully-drafted issue contents (root cause, symptom, proposed fix, local stopgap), so a human can file it or grant access.
+
+## Not applicable inside the Lisa repo itself
+
+When you are already working **inside the Lisa source repo** (`CodySwannGT/lisa`), this rule does not apply — the fix is local to that repo, so make it directly in `plugins/src/...` (and rebuild artifacts) rather than filing an issue against yourself.

package/plugins/lisa-cursor/rules/upstream-to-lisa.mdc

@@ -0,0 +1,25 @@
+---
+description: "Upstream To Lisa (load-bearing)"
+alwaysApply: true
+---
+
+# Upstream To Lisa (load-bearing)
+
+When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. Tell-tale signs: the file you want to change is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns), and any edit you make here would be **overwritten on the next `lisa apply`**.
+
+When that happens, you have **two obligations — do both**:
+
+1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. Treat it as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies. Do not wait on the upstream fix.
+2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa:github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
+
+## Do not
+
+- Do **not** only fix it locally and move on — the local fix is throwaway; without the upstream issue the root cause is lost and re-breaks on the next apply.
+- Do **not** try to edit Lisa's templates from inside this project — you are not in the Lisa repo; those edits don't exist upstream and get overwritten.
+- Do **not** file the issue in this project's repo — it must land in `CodySwannGT/lisa`.
+
+If you lack access to file an issue in `CodySwannGT/lisa`, surface that to the user with the proposed issue contents rather than silently dropping it.
+
+> Not applicable when you are already working **inside the Lisa repo itself** — there the fix is local, so just make it directly.
+
+Full procedure: [reference/upstream-to-lisa.md](upstream-to-lisa-reference.mdc).

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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.175.2",
+  "version": "2.176.0",
   "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-cursor/.claude-plugin/plugin.json

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.175.2",
+  "version": "2.176.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.175.2",
+  "version": "2.176.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.175.2",
+  "version": "2.176.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.175.2",
+  "version": "2.176.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.175.2",
+  "version": "2.176.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"