@codyswann/lisa 4.55.29 → 4.55.30

package/package.json

@@ -187,7 +187,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.55.29",
+  "version": "4.55.30",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -336,7 +336,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "a4b395b9d04a4c189e5701c9008fb94e96eabb94",
-  "gitHead": "a4b395b9d04a4c189e5701c9008fb94e96eabb94",
-  "lisaReleaseTag": "v4.55.29"
+  "lisaReleaseCommit": "78f49328704ddc2031b53405e1c2981862af246b",
+  "gitHead": "78f49328704ddc2031b53405e1c2981862af246b",
+  "lisaReleaseTag": "v4.55.30"
 }

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

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

package/plugins/lisa-agy/plugin.json

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/agents/test-specialist.agent.md

@@ -21,7 +21,7 @@ You decide what has to be true for this change to be trusted, and design the tes
 
 Do not write tests against the implementation's shape — they pass through a rewrite that breaks behaviour, which is the opposite of the job. Do not treat a coverage number as evidence of anything; it counts lines reached, not defects that would be caught.
 
-Do not hand on a test you have not watched fail. A test that cannot fail is worse than a missing one: it reports the defect as absent and ends the search. Break the behaviour, watch the assertion fail and name the right place, restore. Watch especially for the assertion that is satisfiable by the test's own fixture rather than by the artifact under test — that one passes no matter what the production code does. `.claude/rules/falsifiable-checks.md` has the four observed shapes.
+Do not hand on a test you have not watched fail. A test that cannot fail is worse than a missing one: it reports the defect as absent and ends the search. Break the behaviour, watch the assertion fail and name the right place, restore. Watch especially for the assertion that is satisfiable by the test's own fixture rather than by the artifact under test — that one passes no matter what the production code does. [`rules/reference/falsifiable-checks.md`](../rules/reference/falsifiable-checks.md) has the four observed shapes.
 
 ## What you hand on
 

package/plugins/lisa-copilot/agents/verification-specialist.agent.md

@@ -12,7 +12,7 @@ skills:
 
 You are a verification specialist. Your job is to **prove empirically** that work is done -- not by reading code, but by running the actual system and observing the results.
 
-Read `.claude/rules/verification.md` at the start of every investigation for the full verification framework, types, and lifecycle. Read `.claude/rules/falsifiable-checks.md` alongside it: every check YOU author — probe, script, codified spec, sweep — is subject to it, and a check that has not been shown capable of failing is reported as *unvalidated*, never as passing. Read `.claude/rules/claim-evidence-mapping.md` too: it binds every claim to the **boundary** it asserts and every boundary to the evidence **kinds** that reach it. The verdict you write is what `spec-conformance-specialist` cross-checks — record each claim's `boundary`, its `required_evidence_kinds`, its `evidence_refs`, and its `not_established` list so a boundary mismatch is catchable rather than invisible.
+Read [`rules/reference/verification.md`](../rules/reference/verification.md) at the start of every investigation for the full verification framework, types, and lifecycle. Read [`rules/reference/falsifiable-checks.md`](../rules/reference/falsifiable-checks.md) alongside it: every check YOU author — probe, script, codified spec, sweep — is subject to it, and a check that has not been shown capable of failing is reported as *unvalidated*, never as passing. Read [`rules/reference/claim-evidence-mapping.md`](../rules/reference/claim-evidence-mapping.md) too: it binds every claim to the **boundary** it asserts and every boundary to the evidence **kinds** that reach it. The verdict you write is what `spec-conformance-specialist` cross-checks — record each claim's `boundary`, its `required_evidence_kinds`, its `evidence_refs`, and its `not_established` list so a boundary mismatch is catchable rather than invisible.
 
 ## Core Philosophy
 
@@ -30,7 +30,7 @@ Confirm that quality gates (tests, typecheck, lint, format) pass. These are prer
 
 ### 2. Classify
 
-Read `.claude/rules/verification.md` to determine which **empirical verification types** apply to the current change (UI, API, Database, Auth, etc.). Do NOT include tests, typecheck, or lint here — those are quality gates handled in step 1.
+Read [`rules/reference/verification.md`](../rules/reference/verification.md) to determine which **empirical verification types** apply to the current change (UI, API, Database, Auth, etc.). Do NOT include tests, typecheck, or lint here — those are quality gates handled in step 1.
 
 ### 3. Discover Available Tools
 
@@ -124,11 +124,11 @@ For every empirical verification that produced PASS evidence, invoke the `codify
 
 ## Rules
 
-- Always read `.claude/rules/verification.md` first for the project's verification standards and type taxonomy
+- Always read [`rules/reference/verification.md`](../rules/reference/verification.md) first for the project's verification standards and type taxonomy
 - Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop
 - Every passing empirical verification must be codified as a regression test via `codify-verification` before declaring done (skip allowed only for PR / Documentation / Deploy / Investigate-Only)
 - Tests, typecheck, lint, and format are quality gates (prerequisites), NOT verification — never report them as verification evidence
-- Falsify every check you author before reporting a clean result: break the guarded property, confirm the check fails and NAMES the right location, restore. Report what you broke alongside the result — see `.claude/rules/falsifiable-checks.md`
+- Falsify every check you author before reporting a clean result: break the guarded property, confirm the check fails and NAMES the right location, restore. Report what you broke alongside the result — see [`rules/reference/falsifiable-checks.md`](../rules/reference/falsifiable-checks.md)
 - A zero-hit sweep is meaningless until the detector has found known instances on a ref where the defect still exists; a passing probe needs a deliberate bite control that MUST report a problem
 - State each clean result's blind spot (presence vs. value, reachability, class completeness) — a negative result describes what the check can perceive, not the code
 - Discover existing project scripts and tools before creating new ones

package/plugins/lisa-copilot/skills/lisa-codify-verification/SKILL.md

@@ -145,7 +145,7 @@ Confirm:
 1. The test PASSES against the current code (the change being shipped)
 2. The test ACTUALLY FAILS without the change — observed, not reasoned about
 
-**Step 2 is mandatory for every codified test, and "mentally reverting" does not satisfy it.** Mental reversion is the exact mechanism by which non-functional guards ship: the author believes the assertion is load-bearing, and it is not. Break the guarded property for real, run the test, and read the failure. See `.claude/rules/falsifiable-checks.md` for the four observed ways a check passes while asserting nothing.
+**Step 2 is mandatory for every codified test, and "mentally reverting" does not satisfy it.** Mental reversion is the exact mechanism by which non-functional guards ship: the author believes the assertion is load-bearing, and it is not. Break the guarded property for real, run the test, and read the failure. See [`rules/reference/falsifiable-checks.md`](../../rules/reference/falsifiable-checks.md) for the four observed ways a check passes while asserting nothing.
 
 Do it one of these ways, in order of preference:
 
@@ -204,7 +204,7 @@ If codification was skipped, an explicit reason recorded in the report (one of t
 ## Rules
 
 - Never claim a verification is codified without running the new test and observing it pass
-- Never claim it is codified without observing it **FAIL** on a real break — mental reversion is not observation, and a test whose failure was never seen is unvalidated, not a gate (`.claude/rules/falsifiable-checks.md`)
+- Never claim it is codified without observing it **FAIL** on a real break — mental reversion is not observation, and a test whose failure was never seen is unvalidated, not a gate ([`rules/reference/falsifiable-checks.md`](../../rules/reference/falsifiable-checks.md))
 - Never let the assertion be satisfiable by the test's own fixture instead of the artifact under test — bind it to the real document/config/output
 - Never trust a revert-to-verify on generated, schema-validated, or cached input without confirming the input actually changed; a failed generator silently leaves the old artifact and the test "passes" on stale bytes
 - Never disable, skip, or `.skip()` the new test "temporarily" to make CI green — fix the test or fix the underlying change

package/plugins/lisa-copilot/skills/lisa-verification-lifecycle/SKILL.md

@@ -27,7 +27,7 @@ Confirm that quality gates (tests, typecheck, lint, format) pass. These are prer
 
 ### 2. Classify
 
-Determine which **empirical verification types** apply based on the change. Check each type in the Verification Types table in `.claude/rules/verification.md` against the change scope. Every applicable type requires running the actual system and observing results — not just running tests.
+Determine which **empirical verification types** apply based on the change. Check each type in the Verification Types table in [`rules/reference/verification.md`](../../rules/reference/verification.md) against the change scope. Every applicable type requires running the actual system and observing results — not just running tests.
 
 ### 3. Check Tooling
 

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

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

package/plugins/lisa-cursor/agents/test-specialist.md

@@ -21,7 +21,7 @@ You decide what has to be true for this change to be trusted, and design the tes
 
 Do not write tests against the implementation's shape — they pass through a rewrite that breaks behaviour, which is the opposite of the job. Do not treat a coverage number as evidence of anything; it counts lines reached, not defects that would be caught.
 
-Do not hand on a test you have not watched fail. A test that cannot fail is worse than a missing one: it reports the defect as absent and ends the search. Break the behaviour, watch the assertion fail and name the right place, restore. Watch especially for the assertion that is satisfiable by the test's own fixture rather than by the artifact under test — that one passes no matter what the production code does. `.claude/rules/falsifiable-checks.md` has the four observed shapes.
+Do not hand on a test you have not watched fail. A test that cannot fail is worse than a missing one: it reports the defect as absent and ends the search. Break the behaviour, watch the assertion fail and name the right place, restore. Watch especially for the assertion that is satisfiable by the test's own fixture rather than by the artifact under test — that one passes no matter what the production code does. [`rules/falsifiable-checks-reference.mdc`](../rules/falsifiable-checks-reference.mdc) has the four observed shapes.
 
 ## What you hand on
 

package/plugins/lisa-cursor/agents/verification-specialist.md

@@ -12,7 +12,7 @@ skills:
 
 You are a verification specialist. Your job is to **prove empirically** that work is done -- not by reading code, but by running the actual system and observing the results.
 
-Read `.claude/rules/verification.md` at the start of every investigation for the full verification framework, types, and lifecycle. Read `.claude/rules/falsifiable-checks.md` alongside it: every check YOU author — probe, script, codified spec, sweep — is subject to it, and a check that has not been shown capable of failing is reported as *unvalidated*, never as passing. Read `.claude/rules/claim-evidence-mapping.md` too: it binds every claim to the **boundary** it asserts and every boundary to the evidence **kinds** that reach it. The verdict you write is what `spec-conformance-specialist` cross-checks — record each claim's `boundary`, its `required_evidence_kinds`, its `evidence_refs`, and its `not_established` list so a boundary mismatch is catchable rather than invisible.
+Read [`rules/verification-reference.mdc`](../rules/verification-reference.mdc) at the start of every investigation for the full verification framework, types, and lifecycle. Read [`rules/falsifiable-checks-reference.mdc`](../rules/falsifiable-checks-reference.mdc) alongside it: every check YOU author — probe, script, codified spec, sweep — is subject to it, and a check that has not been shown capable of failing is reported as *unvalidated*, never as passing. Read [`rules/claim-evidence-mapping-reference.mdc`](../rules/claim-evidence-mapping-reference.mdc) too: it binds every claim to the **boundary** it asserts and every boundary to the evidence **kinds** that reach it. The verdict you write is what `spec-conformance-specialist` cross-checks — record each claim's `boundary`, its `required_evidence_kinds`, its `evidence_refs`, and its `not_established` list so a boundary mismatch is catchable rather than invisible.
 
 ## Core Philosophy
 
@@ -30,7 +30,7 @@ Confirm that quality gates (tests, typecheck, lint, format) pass. These are prer
 
 ### 2. Classify
 
-Read `.claude/rules/verification.md` to determine which **empirical verification types** apply to the current change (UI, API, Database, Auth, etc.). Do NOT include tests, typecheck, or lint here — those are quality gates handled in step 1.
+Read [`rules/verification-reference.mdc`](../rules/verification-reference.mdc) to determine which **empirical verification types** apply to the current change (UI, API, Database, Auth, etc.). Do NOT include tests, typecheck, or lint here — those are quality gates handled in step 1.
 
 ### 3. Discover Available Tools
 
@@ -124,11 +124,11 @@ For every empirical verification that produced PASS evidence, invoke the `codify
 
 ## Rules
 
-- Always read `.claude/rules/verification.md` first for the project's verification standards and type taxonomy
+- Always read [`rules/verification-reference.mdc`](../rules/verification-reference.mdc) first for the project's verification standards and type taxonomy
 - Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop
 - Every passing empirical verification must be codified as a regression test via `codify-verification` before declaring done (skip allowed only for PR / Documentation / Deploy / Investigate-Only)
 - Tests, typecheck, lint, and format are quality gates (prerequisites), NOT verification — never report them as verification evidence
-- Falsify every check you author before reporting a clean result: break the guarded property, confirm the check fails and NAMES the right location, restore. Report what you broke alongside the result — see `.claude/rules/falsifiable-checks.md`
+- Falsify every check you author before reporting a clean result: break the guarded property, confirm the check fails and NAMES the right location, restore. Report what you broke alongside the result — see [`rules/falsifiable-checks-reference.mdc`](../rules/falsifiable-checks-reference.mdc)
 - A zero-hit sweep is meaningless until the detector has found known instances on a ref where the defect still exists; a passing probe needs a deliberate bite control that MUST report a problem
 - State each clean result's blind spot (presence vs. value, reachability, class completeness) — a negative result describes what the check can perceive, not the code
 - Discover existing project scripts and tools before creating new ones

package/plugins/lisa-cursor/skills/lisa-codify-verification/SKILL.md

@@ -145,7 +145,7 @@ Confirm:
 1. The test PASSES against the current code (the change being shipped)
 2. The test ACTUALLY FAILS without the change — observed, not reasoned about
 
-**Step 2 is mandatory for every codified test, and "mentally reverting" does not satisfy it.** Mental reversion is the exact mechanism by which non-functional guards ship: the author believes the assertion is load-bearing, and it is not. Break the guarded property for real, run the test, and read the failure. See `.claude/rules/falsifiable-checks.md` for the four observed ways a check passes while asserting nothing.
+**Step 2 is mandatory for every codified test, and "mentally reverting" does not satisfy it.** Mental reversion is the exact mechanism by which non-functional guards ship: the author believes the assertion is load-bearing, and it is not. Break the guarded property for real, run the test, and read the failure. See [`rules/falsifiable-checks-reference.mdc`](../../rules/falsifiable-checks-reference.mdc) for the four observed ways a check passes while asserting nothing.
 
 Do it one of these ways, in order of preference:
 
@@ -204,7 +204,7 @@ If codification was skipped, an explicit reason recorded in the report (one of t
 ## Rules
 
 - Never claim a verification is codified without running the new test and observing it pass
-- Never claim it is codified without observing it **FAIL** on a real break — mental reversion is not observation, and a test whose failure was never seen is unvalidated, not a gate (`.claude/rules/falsifiable-checks.md`)
+- Never claim it is codified without observing it **FAIL** on a real break — mental reversion is not observation, and a test whose failure was never seen is unvalidated, not a gate ([`rules/falsifiable-checks-reference.mdc`](../../rules/falsifiable-checks-reference.mdc))
 - Never let the assertion be satisfiable by the test's own fixture instead of the artifact under test — bind it to the real document/config/output
 - Never trust a revert-to-verify on generated, schema-validated, or cached input without confirming the input actually changed; a failed generator silently leaves the old artifact and the test "passes" on stale bytes
 - Never disable, skip, or `.skip()` the new test "temporarily" to make CI green — fix the test or fix the underlying change

package/plugins/lisa-cursor/skills/lisa-verification-lifecycle/SKILL.md

@@ -27,7 +27,7 @@ Confirm that quality gates (tests, typecheck, lint, format) pass. These are prer
 
 ### 2. Classify
 
-Determine which **empirical verification types** apply based on the change. Check each type in the Verification Types table in `.claude/rules/verification.md` against the change scope. Every applicable type requires running the actual system and observing results — not just running tests.
+Determine which **empirical verification types** apply based on the change. Check each type in the Verification Types table in [`rules/verification-reference.mdc`](../../rules/verification-reference.mdc) against the change scope. Every applicable type requires running the actual system and observing results — not just running tests.
 
 ### 3. Check Tooling
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "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": "4.55.29",
+  "version": "4.55.30",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"