@codyswann/lisa 3.17.3 → 3.18.1

package/plugins/lisa-copilot/scripts/plugin-sync-explain.mjs

@@ -19,6 +19,8 @@ import {
 import { tmpdir } from "node:os";
 import path from "node:path";
 import process from "node:process";
+import { realpathSync } from "node:fs";
+import { fileURLToPath } from "node:url";
 
 export const PLUGIN_SYNC_CLASSIFICATIONS = [
   "SOURCE_NOT_BUILT",
@@ -556,7 +558,41 @@ function linkedWorktreeGitDir(root) {
   return path.isAbsolute(gitDir) ? gitDir : path.resolve(root, gitDir);
 }
 
-if (import.meta.url === `file://${process.argv[1]}`) {
+/**
+ * True when `moduleUrl` names the module node was asked to run.
+ *
+ * Both sides are realpath'd. The previous spelling compared `import.meta.url`
+ * against a `file://` string built from `process.argv[1]`, which pits a real
+ * path against whatever the caller typed — so reached through a symlinked
+ * checkout, a git worktree, or a `/tmp` path on macOS the two disagreed, the
+ * body never ran, and the process exited 0 having done nothing. Every
+ * Lisa-driven agent runs in a worktree, so that is the routine path, not an
+ * exotic one.
+ *
+ * Written out rather than imported: this ships inside a plugin payload, which
+ * has no `./lib/` to resolve against. Same rule and same reasoning as
+ * `scripts/lib/invoked-as-script.mjs`.
+ *
+ * Realpathing BOTH sides matters under `--preserve-symlinks-main`, which tells
+ * node not to resolve the main entry: normalizing only `argv[1]` then compares
+ * a real path against a symlinked one and answers false for an entry point that
+ * WAS invoked directly. Any resolution error returns false — node loaded the
+ * entry from that path moments earlier, so a path that will not resolve now is
+ * not the path this module came through.
+ * @param {string} moduleUrl - The caller's own `import.meta.url`.
+ * @param {string | undefined} [argv1] - Entry path; defaults to `process.argv[1]`.
+ * @returns {boolean} Whether the caller should run its CLI body.
+ */
+export function invokedAsScript(moduleUrl, argv1 = process.argv[1]) {
+  if (!argv1) return false;
+  try {
+    return realpathSync(argv1) === realpathSync(fileURLToPath(moduleUrl));
+  } catch {
+    return false;
+  }
+}
+
+if (invokedAsScript(import.meta.url)) {
   try {
     const report = explainPluginSync(process.argv[2] ?? process.cwd());
     process.stdout.write(report.text);

package/plugins/lisa-copilot/skills/lisa-github-build-intake/SKILL.md

@@ -216,6 +216,21 @@ The classifier returns `trusted`, `untrusted`, `unknownProvenance`, and a per-la
 - a candidate whose `$READY` is **untrusted** is **not claimable** — skip it and leave it for a human to flip genuinely ready; report it in the summary rather than dispatching it;
 - a candidate whose `$CLAIMED` is **untrusted** is **not claimed** — if its `$READY` is trusted it stays a normal candidate, exactly as if the bot label were absent.
 
+#### 2c. A trusted claim is a skip reason
+
+The scan filters on `--label "$READY"` alone, so an issue carrying **both** `$READY` and `$CLAIMED` comes back as a candidate. The rules above rescue the case where a *bot* applied the claim; they say nothing about the case where a **human** did — which is the strongest claim signal there is, and the one that was being ignored. An issue a person marked in-progress is somebody's active work, and dispatching a second agent onto it is how two branches end up fixing the same thing.
+
+The classifier answers this directly, so the skill does not have to reason about it:
+
+```json
+{ "claimable": false,
+  "reason": "already carries a trusted \"status:in-progress\", so somebody is working it; intake must not dispatch a second agent onto the same issue" }
+```
+
+**A candidate with `claimable: false` is skipped and reported with its `reason`.** It is not an error and not a stall — it is the queue working. Never strip the claim to make it claimable: that is the label-flap the section above refuses, aimed at a human this time.
+
+`claimable` is computed from the **trusted** set, not the raw labels, which is what keeps it from undoing 2b — a bot-applied claim leaves the issue claimable exactly as if it were absent.
+
 **Never unlabel to correct this.** The bot re-applies its label on each subsequent review event, so reverting produces a label-flap loop that is worse than the defect. The guard is that intake stops *believing* the label; it writes nothing. Distrust is idempotent and cannot race.
 
 A label whose provenance cannot be established (applied at creation, which GitHub records no `labeled` event for) is trusted but listed in `unknownProvenance` — failing closed there would ignore the human `status:ready` that opens the queue. Report that list; do not silently drop it.

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

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

package/plugins/lisa-cursor/scripts/automation-run-record.mjs

@@ -8,6 +8,8 @@
 
 import { mkdir, readFile, rename, writeFile } from "node:fs/promises";
 import path from "node:path";
+import { realpathSync } from "node:fs";
+import { fileURLToPath } from "node:url";
 
 export const AUTOMATION_RUN_OUTCOMES = [
   "nothing-needed",
@@ -396,7 +398,41 @@ export async function runAutomationRunRecordCli(argv) {
 }
 
 // CLI entrypoint.
-if (import.meta.url === `file://${process.argv[1]}`) {
+/**
+ * True when `moduleUrl` names the module node was asked to run.
+ *
+ * Both sides are realpath'd. The previous spelling compared `import.meta.url`
+ * against a `file://` string built from `process.argv[1]`, which pits a real
+ * path against whatever the caller typed — so reached through a symlinked
+ * checkout, a git worktree, or a `/tmp` path on macOS the two disagreed, the
+ * body never ran, and the process exited 0 having done nothing. Every
+ * Lisa-driven agent runs in a worktree, so that is the routine path, not an
+ * exotic one.
+ *
+ * Written out rather than imported: this ships inside a plugin payload, which
+ * has no `./lib/` to resolve against. Same rule and same reasoning as
+ * `scripts/lib/invoked-as-script.mjs`.
+ *
+ * Realpathing BOTH sides matters under `--preserve-symlinks-main`, which tells
+ * node not to resolve the main entry: normalizing only `argv[1]` then compares
+ * a real path against a symlinked one and answers false for an entry point that
+ * WAS invoked directly. Any resolution error returns false — node loaded the
+ * entry from that path moments earlier, so a path that will not resolve now is
+ * not the path this module came through.
+ * @param {string} moduleUrl - The caller's own `import.meta.url`.
+ * @param {string | undefined} [argv1] - Entry path; defaults to `process.argv[1]`.
+ * @returns {boolean} Whether the caller should run its CLI body.
+ */
+export function invokedAsScript(moduleUrl, argv1 = process.argv[1]) {
+  if (!argv1) return false;
+  try {
+    return realpathSync(argv1) === realpathSync(fileURLToPath(moduleUrl));
+  } catch {
+    return false;
+  }
+}
+
+if (invokedAsScript(import.meta.url)) {
   runAutomationRunRecordCli(process.argv.slice(2)).then(
     code => {
       process.exitCode = code;

package/plugins/lisa-cursor/scripts/cross-pollinate.mjs

@@ -37,6 +37,8 @@
 import { createHash } from "node:crypto";
 import fs from "node:fs";
 import path from "node:path";
+import { realpathSync } from "node:fs";
+import { fileURLToPath } from "node:url";
 
 const LOCKFILE_REL = path.join(".lisa", "cross-pollination.lock.json");
 const LOCK_VERSION = 1;
@@ -704,7 +706,41 @@ export function renderReport(p, result) {
 }
 
 // CLI entrypoint.
-if (import.meta.url === `file://${process.argv[1]}`) {
+/**
+ * True when `moduleUrl` names the module node was asked to run.
+ *
+ * Both sides are realpath'd. The previous spelling compared `import.meta.url`
+ * against a `file://` string built from `process.argv[1]`, which pits a real
+ * path against whatever the caller typed — so reached through a symlinked
+ * checkout, a git worktree, or a `/tmp` path on macOS the two disagreed, the
+ * body never ran, and the process exited 0 having done nothing. Every
+ * Lisa-driven agent runs in a worktree, so that is the routine path, not an
+ * exotic one.
+ *
+ * Written out rather than imported: this ships inside a plugin payload, which
+ * has no `./lib/` to resolve against. Same rule and same reasoning as
+ * `scripts/lib/invoked-as-script.mjs`.
+ *
+ * Realpathing BOTH sides matters under `--preserve-symlinks-main`, which tells
+ * node not to resolve the main entry: normalizing only `argv[1]` then compares
+ * a real path against a symlinked one and answers false for an entry point that
+ * WAS invoked directly. Any resolution error returns false — node loaded the
+ * entry from that path moments earlier, so a path that will not resolve now is
+ * not the path this module came through.
+ * @param {string} moduleUrl - The caller's own `import.meta.url`.
+ * @param {string | undefined} [argv1] - Entry path; defaults to `process.argv[1]`.
+ * @returns {boolean} Whether the caller should run its CLI body.
+ */
+export function invokedAsScript(moduleUrl, argv1 = process.argv[1]) {
+  if (!argv1) return false;
+  try {
+    return realpathSync(argv1) === realpathSync(fileURLToPath(moduleUrl));
+  } catch {
+    return false;
+  }
+}
+
+if (invokedAsScript(import.meta.url)) {
   const args = process.argv.slice(2);
   const root = path.resolve(args.find(a => !a.startsWith("-")) ?? ".");
   const dryRun = args.includes("--dry-run") || !args.includes("--write");

package/plugins/lisa-cursor/scripts/design-source-gate.mjs

@@ -35,7 +35,8 @@
  * Exit 0 = PASS, 1 = FAIL (any violation, or anything unresolvable), 2 = usage.
  */
 import { execFileSync } from "node:child_process";
-import { readFileSync } from "node:fs";
+import { readFileSync, realpathSync } from "node:fs";
+import { fileURLToPath } from "node:url";
 
 /** The one designated marker for UI deliberately not captured in Figma. */
 export const DESIGN_SOURCE_NONE_MARKER = "DESIGN-SOURCE: none — not in Figma";
@@ -534,6 +535,36 @@ export function runCli(argv) {
   return result.verdict === "PASS" ? 0 : 1;
 }
 
-if (process.argv[1]?.endsWith("design-source-gate.mjs")) {
+/**
+ * True when `moduleUrl` names the module node was asked to run.
+ *
+ * The previous spelling tested whether `process.argv[1]` ENDED WITH this
+ * module's basename, which is looser still than the `file://` comparison the
+ * sibling modules used: any path ending in `design-source-gate.mjs` satisfied
+ * it, including a different copy of this file in another checkout, and a
+ * rename silently turned the guard off with nothing to notice.
+ *
+ * Both sides are realpath'd instead. Reached through a symlinked checkout, a
+ * git worktree, or a `/tmp` path on macOS the naive comparisons disagree, the
+ * body never runs, and the process exits 0 having done nothing — and every
+ * Lisa-driven agent runs in a worktree, so that is the routine path.
+ *
+ * Written out rather than imported: this ships inside a plugin payload, which
+ * has no `./lib/` to resolve against. Same rule and reasoning as
+ * `scripts/lib/invoked-as-script.mjs`.
+ * @param {string} moduleUrl - The caller's own `import.meta.url`.
+ * @param {string | undefined} [argv1] - Entry path; defaults to `process.argv[1]`.
+ * @returns {boolean} Whether the caller should run its CLI body.
+ */
+export function invokedAsScript(moduleUrl, argv1 = process.argv[1]) {
+  if (!argv1) return false;
+  try {
+    return realpathSync(argv1) === realpathSync(fileURLToPath(moduleUrl));
+  } catch {
+    return false;
+  }
+}
+
+if (invokedAsScript(import.meta.url)) {
   process.exit(runCli(process.argv.slice(2)));
 }

package/plugins/lisa-cursor/scripts/lifecycle-label-trust.mjs

@@ -39,6 +39,9 @@
  * `status:` PREFIX and terminality is resolved from live config.
  */
 
+import { realpathSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+
 /** Lifecycle labels are identified by this prefix, never by a pinned set. */
 export const LIFECYCLE_LABEL_PREFIX = "status:";
 
@@ -217,6 +220,62 @@ export function terminalLifecycleLabels(config) {
   return [DEFAULT_TERMINAL_LIFECYCLE_LABEL];
 }
 
+/** The claimed role's label when config names none. */
+const DEFAULT_CLAIMED_LIFECYCLE_LABEL = "status:in-progress";
+
+/**
+ * The lifecycle label that means "somebody is already on this", from config.
+ * @param {unknown} config a parsed `.lisa.config.json`-shaped object
+ * @returns {string} the claimed role's label
+ */
+export function claimedLifecycleLabel(config) {
+  const claimed = readPath(config, ["github", "labels", "build", "claimed"]);
+  return typeof claimed === "string" && claimed.trim().length > 0
+    ? claimed.trim()
+    : DEFAULT_CLAIMED_LIFECYCLE_LABEL;
+}
+
+/**
+ * Whether intake may claim this issue, and why not when it may not.
+ *
+ * The scan filters on the ready role alone, so an issue carrying BOTH ready and
+ * claimed comes back as a candidate. Trust resolution then rescues the case
+ * where a bot applied the claim — but says nothing about the case where a
+ * *human* did, which is the strongest claim signal there is and the one that
+ * was being ignored. An issue a person marked in-progress is somebody's active
+ * work; dispatching a second agent onto it is how two branches end up fixing
+ * the same thing.
+ *
+ * Returned as a verdict rather than left to the skill's prose. This repository
+ * has measured the difference: executable controls hold, prose rules are
+ * followed by roughly nobody, including their own author. The scan already
+ * calls this classifier, so the answer arrives where the decision is made.
+ *
+ * A claim is only believed when TRUSTED, which is what keeps this from undoing
+ * the bot fix: a reflexive bot label leaves the issue claimable exactly as if
+ * it were absent.
+ * @param {object} options inputs
+ * @param {readonly string[]} options.trusted labels the classifier believes
+ * @param {unknown} options.config a parsed `.lisa.config.json`-shaped object
+ * @returns {{claimable: boolean, reason: string|null}} the verdict
+ */
+export function resolveClaimability({ trusted, config }) {
+  const claimed = claimedLifecycleLabel(config);
+  const normalizedClaimed = claimed.toLowerCase();
+  const hasTrustedClaim = (trusted ?? []).some(
+    label => String(label).trim().toLowerCase() === normalizedClaimed
+  );
+  if (!hasTrustedClaim) {
+    return { claimable: true, reason: null };
+  }
+  return {
+    claimable: false,
+    reason:
+      `already carries a trusted "${claimed}", so somebody is working it; ` +
+      `intake must not dispatch a second agent onto the same issue`,
+  };
+}
+
 /**
  * Detect lifecycle labels that contradict native state, in BOTH directions.
  *
@@ -482,11 +541,48 @@ async function main() {
     terminalLabels: terminalLifecycleLabels(payload.config),
     excludeLabels: trust.untrusted.map(entry => entry.label),
   });
+  // Computed from `trust.trusted`, never from the raw label set: a bot-applied
+  // claim must leave the issue claimable exactly as if it were absent, which is
+  // the whole point of the trust pass above.
+  const claim = resolveClaimability({
+    trusted: trust.trusted,
+    config: payload.config,
+  });
 
-  process.stdout.write(`${JSON.stringify({ ...trust, ...drift }, null, 2)}\n`);
+  process.stdout.write(
+    `${JSON.stringify({ ...trust, ...drift, ...claim }, null, 2)}\n`
+  );
+}
+
+/**
+ * True when `moduleUrl` names the module node was asked to run.
+ *
+ * Both sides are realpath'd. The previous spelling compared `import.meta.url`
+ * against a `file://` string built from `process.argv[1]`, which compares a
+ * real path against whatever the caller typed — so reached through a symlinked
+ * checkout, a git worktree, or a `/tmp` path on macOS the two disagreed and
+ * `main()` never ran. This module writes its verdict to stdout, so a no-op
+ * leaves the caller parsing an empty payload: no untrusted labels, no
+ * unclaimable verdict, everything believed. A guard that fails open on the
+ * component whose job is deciding what to believe.
+ *
+ * Written out rather than imported: this is a plugin payload, which has no
+ * `./lib/` to resolve against. Same rule and same reasoning as
+ * `scripts/lib/invoked-as-script.mjs`.
+ * @param {string} moduleUrl - The caller's own `import.meta.url`.
+ * @param {string | undefined} [argv1] - Entry path; defaults to `process.argv[1]`.
+ * @returns {boolean} Whether the caller should run its CLI body.
+ */
+export function invokedAsScript(moduleUrl, argv1 = process.argv[1]) {
+  if (!argv1) return false;
+  try {
+    return realpathSync(argv1) === realpathSync(fileURLToPath(moduleUrl));
+  } catch {
+    return false;
+  }
 }
 
-if (import.meta.url === `file://${process.argv[1]}`) {
+if (invokedAsScript(import.meta.url)) {
   main().catch(error => {
     process.stderr.write(`${error.message}\n`);
     process.exitCode = 1;

package/plugins/lisa-cursor/scripts/plugin-sync-explain.mjs

@@ -19,6 +19,8 @@ import {
 import { tmpdir } from "node:os";
 import path from "node:path";
 import process from "node:process";
+import { realpathSync } from "node:fs";
+import { fileURLToPath } from "node:url";
 
 export const PLUGIN_SYNC_CLASSIFICATIONS = [
   "SOURCE_NOT_BUILT",
@@ -556,7 +558,41 @@ function linkedWorktreeGitDir(root) {
   return path.isAbsolute(gitDir) ? gitDir : path.resolve(root, gitDir);
 }
 
-if (import.meta.url === `file://${process.argv[1]}`) {
+/**
+ * True when `moduleUrl` names the module node was asked to run.
+ *
+ * Both sides are realpath'd. The previous spelling compared `import.meta.url`
+ * against a `file://` string built from `process.argv[1]`, which pits a real
+ * path against whatever the caller typed — so reached through a symlinked
+ * checkout, a git worktree, or a `/tmp` path on macOS the two disagreed, the
+ * body never ran, and the process exited 0 having done nothing. Every
+ * Lisa-driven agent runs in a worktree, so that is the routine path, not an
+ * exotic one.
+ *
+ * Written out rather than imported: this ships inside a plugin payload, which
+ * has no `./lib/` to resolve against. Same rule and same reasoning as
+ * `scripts/lib/invoked-as-script.mjs`.
+ *
+ * Realpathing BOTH sides matters under `--preserve-symlinks-main`, which tells
+ * node not to resolve the main entry: normalizing only `argv[1]` then compares
+ * a real path against a symlinked one and answers false for an entry point that
+ * WAS invoked directly. Any resolution error returns false — node loaded the
+ * entry from that path moments earlier, so a path that will not resolve now is
+ * not the path this module came through.
+ * @param {string} moduleUrl - The caller's own `import.meta.url`.
+ * @param {string | undefined} [argv1] - Entry path; defaults to `process.argv[1]`.
+ * @returns {boolean} Whether the caller should run its CLI body.
+ */
+export function invokedAsScript(moduleUrl, argv1 = process.argv[1]) {
+  if (!argv1) return false;
+  try {
+    return realpathSync(argv1) === realpathSync(fileURLToPath(moduleUrl));
+  } catch {
+    return false;
+  }
+}
+
+if (invokedAsScript(import.meta.url)) {
   try {
     const report = explainPluginSync(process.argv[2] ?? process.cwd());
     process.stdout.write(report.text);

package/plugins/lisa-cursor/skills/lisa-github-build-intake/SKILL.md

@@ -216,6 +216,21 @@ The classifier returns `trusted`, `untrusted`, `unknownProvenance`, and a per-la
 - a candidate whose `$READY` is **untrusted** is **not claimable** — skip it and leave it for a human to flip genuinely ready; report it in the summary rather than dispatching it;
 - a candidate whose `$CLAIMED` is **untrusted** is **not claimed** — if its `$READY` is trusted it stays a normal candidate, exactly as if the bot label were absent.
 
+#### 2c. A trusted claim is a skip reason
+
+The scan filters on `--label "$READY"` alone, so an issue carrying **both** `$READY` and `$CLAIMED` comes back as a candidate. The rules above rescue the case where a *bot* applied the claim; they say nothing about the case where a **human** did — which is the strongest claim signal there is, and the one that was being ignored. An issue a person marked in-progress is somebody's active work, and dispatching a second agent onto it is how two branches end up fixing the same thing.
+
+The classifier answers this directly, so the skill does not have to reason about it:
+
+```json
+{ "claimable": false,
+  "reason": "already carries a trusted \"status:in-progress\", so somebody is working it; intake must not dispatch a second agent onto the same issue" }
+```
+
+**A candidate with `claimable: false` is skipped and reported with its `reason`.** It is not an error and not a stall — it is the queue working. Never strip the claim to make it claimable: that is the label-flap the section above refuses, aimed at a human this time.
+
+`claimable` is computed from the **trusted** set, not the raw labels, which is what keeps it from undoing 2b — a bot-applied claim leaves the issue claimable exactly as if it were absent.
+
 **Never unlabel to correct this.** The bot re-applies its label on each subsequent review event, so reverting produces a label-flap loop that is worse than the defect. The guard is that intake stops *believing* the label; it writes nothing. Distrust is idempotent and cannot race.
 
 A label whose provenance cannot be established (applied at creation, which GitHub records no `labeled` event for) is trusted but listed in `unknownProvenance` — failing closed there would ignore the human `status:ready` that opens the queue. Report that list; do not silently drop it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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