@codyswann/lisa 4.34.15 → 4.34.17

package/plugins/lisa-copilot/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -460,6 +460,50 @@ passed off as success.
   `blocked:unreviewed`. This fallback lives inside the gated section above —
   with `auto_merge=false` it never fires; the PR remains open awaiting a human.
 
+### The mergeability gate — never arm a PR that cannot merge
+
+The arm gate above asks *did the review context do work?* This one asks a
+different question — *is there a verdict standing in the way?* — and they are
+not the same. A `CHANGES_REQUESTED` review unambiguously **did work**, so it
+sails through the arm gate and the latch goes on over the top of it.
+
+**Read `reviewDecision` explicitly. Never infer it from a check count.**
+
+```bash
+gh pr view <pr> --json reviewDecision,reviewThreads \
+  --jq '{decision: .reviewDecision, unresolved: [.reviewThreads[]? | select(.isResolved == false)] | length}'
+```
+
+`reviewDecision` is **not part of `statusCheckRollup`**. That is the whole reason
+this stayed invisible: a failing-check count reads **zero** on a PR that can
+never merge, and the checks tab is entirely green. Any rule keyed on "no red
+checks" is satisfied by exactly the PR this gate exists to catch (#3720).
+
+**Do not arm while `reviewDecision == CHANGES_REQUESTED`.** Arming is a claim
+that this PR will merge, and that claim is false here. Clear the verdict through
+step (e) first — which discriminates a live objection from a stranded one by
+unresolved thread count, not by `reviewDecision` — and arm afterwards.
+
+**Two ruleset settings decide whether a standing verdict ever clears itself, and
+in this repository both say no.** Verify them for the repo you are in rather
+than assuming, with `gh api repos/<owner>/<repo>/rulesets`:
+
+- `dismiss_stale_reviews_on_push: false` — the review stays attached to the
+  commit it was made on, so **pushing the fix never clears it**. The intuition
+  that a new head resets the verdict is wrong here.
+- `required_approving_review_count: 0` — no approval is required to merge, so a
+  standing `CHANGES_REQUESTED` is not holding a slot for a review that would
+  otherwise arrive. Nothing is scheduled to clear it.
+
+Together those mean the block is **indefinite, not slow**. Waiting is not a
+strategy; something has to act.
+
+**Unresolved threads block independently of the verdict.** This repository sets
+`required_review_thread_resolution: true`, so a PR can have a clear
+`reviewDecision` and still be unmergeable on threads alone — a second blocker
+that is equally absent from the check rollup. Read both, and name whichever one
+is standing; reporting the wrong one sends the operator to the wrong place.
+
 ## 2. The watch loop
 
 Poll the live state each iteration:
@@ -1078,6 +1122,14 @@ Loop until one of:
   the one thing nobody would then do is investigate it. Usually a missing
   `issues: read` / label-read permission, which is fixable and invisible from
   the merge outcome alone.
+- **`blocked:armed-unmergeable`** — the PR is OPEN, auto-merge is ON, every check
+  is green, and it still cannot merge: `reviewDecision == CHANGES_REQUESTED`, or
+  unresolved review threads under `required_review_thread_resolution`. Report the
+  PR URL, **which** of the two is standing, and that it will not clear itself.
+  For example: *"PR #123 looks ready — every check is green and auto-merge is on
+  — but a review asked for changes and that is still on record, so it will sit
+  there forever. Someone needs to clear that review or resolve the open
+  comments."* Never report this PR as merging.
 - **`CLOSED`** → report (PR was closed without merge).
 - **Hard block needing a human**: an unresolvable conflict, a failing check that
   needs design input, or genuine unresolved human objection (not a bot gate). Stop
@@ -1087,6 +1139,44 @@ Loop until one of:
   adversarial-review substitute is posted (step d); it never extends to any
   other gate.
 
+### Before you stop: never leave a PR armed and unmergeable in silence
+
+**This applies at every exit that leaves the PR OPEN** — not only the terminal
+states above, but any point where this run concludes it is finished, hands back,
+or gives up. Re-read, from the live PR, immediately before reporting:
+
+```bash
+gh pr view <pr> --json state,autoMergeRequest,reviewDecision,reviewThreads \
+  --jq '{state, armed: (.autoMergeRequest != null), decision: .reviewDecision,
+         unresolved: [.reviewThreads[]? | select(.isResolved == false)] | length}'
+```
+
+If `state == OPEN` and `armed` and either `decision == "CHANGES_REQUESTED"` or
+`unresolved > 0`, the outcome is **`blocked:armed-unmergeable`** — never a
+success, and never silence.
+
+**Why this exists rather than trusting the loop.** While the loop runs this is
+already covered: the watch poll reads `reviewDecision` and step (e) handles it.
+The failure is a run that **stops** while the PR is armed and blocked — the
+session ends, or the agent decides the work is done because arming looked like
+completion. Measured (#3720): three PRs were left armed, green and permanently
+unmergeable, and every one was found only because a person queried
+`reviewDecision` by hand. An agent that arms auto-merge and reports "armed, will
+merge" is reporting something false and has no reason to know it.
+
+**Arming is not completion.** It is a claim about the future that this check is
+what makes honest. The claim costs nothing when true — one read, and the report
+says merging — and when false it is the only thing standing between a parked PR
+and nobody noticing for hours.
+
+**Read the two fields; do not substitute a check count.** Zero failing checks is
+the symptom, not the signal — that is precisely why this class was invisible.
+
+In `on_blocker=report` mode the same condition returns the existing
+`blocked:changes_requested` classification rather than this terminal state: that
+mode returns a blocker for the caller to act on, and does not drive. The two
+names describe the same PR seen from the two modes.
+
 At every terminal state, release the babysitter lease
 (`gh pr edit <pr> --remove-label "lisa:babysitter-on-duty"`) so the CI
 auto-fix workflow can take over as fixer of last resort if the branch goes

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

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

package/plugins/lisa-cursor/hooks/block-direct-issue-create.sh

@@ -1432,8 +1432,20 @@ EXEC_WRAPPERS = {
 }
 
 # Interpreter options that mean "no script file follows": a command string or a
-# module name, both of which the guard reads by other means or not at all.
-NO_SCRIPT_OPTIONS = {"-c", "-e", "-m", "--eval", "--command", "--module"}
+# module name, both of which the guard reads by other means or not at all. These
+# are interpreter-specific on purpose. `bash -e create.sh` and `sh -m create.sh`
+# still execute the following file; treating Python and Node flags as universal
+# silently stopped the scan before those shell operands.
+NO_SCRIPT_OPTIONS = {
+    "bun": {"-e", "--eval"},
+    "node": {"-e", "--eval"},
+    "nodejs": {"-e", "--eval"},
+    "perl": {"-e"},
+    "php": {"-r"},
+    "python": {"-c", "-m", "--command", "--module"},
+    "python3": {"-c", "-m", "--command", "--module"},
+    "ruby": {"-e"},
+}
 
 # Programs that READ their operands and never execute them as programs.
 #
@@ -1569,7 +1581,12 @@ def executed_operand(argv):
         if argument.startswith("-"):
             # A command string or a module name; no script file follows.
             head = argument.split("=", 1)[0]
-            if argument in NO_SCRIPT_OPTIONS or head in NO_SCRIPT_OPTIONS:
+            if program in {"bash", "dash", "ksh", "sh", "zsh"}:
+                # Shell `-c` may be clustered (`-ec`), while `-e` and `-m` are
+                # ordinary shell options and do not consume the script path.
+                if not head.startswith("--") and "c" in head[1:]:
+                    return None
+            elif head in NO_SCRIPT_OPTIONS.get(program, set()):
                 return None
             continue
         return argument

package/plugins/lisa-cursor/hooks/block-managed-file-edits.sh

@@ -90,7 +90,7 @@
 # from mine", and guessing "behind" is how a fork's stronger guard gets silently
 # replaced by a weaker upstream one. Add a name here in the same commit that
 # closes a vector.
-# lisa-guard-capabilities: managed-path-resolution, lisaignore-precedence, generated-path-rebuild, redirect-target, tee-target, sed-in-place-all-spellings, executed-script-reach, source-builtin-reach, stdin-redirect-reach, wrapper-positional-operand
+# lisa-guard-capabilities: managed-path-resolution, lisaignore-precedence, generated-path-rebuild, redirect-target, tee-target, sed-in-place-all-spellings, executed-script-reach, source-builtin-reach, stdin-redirect-reach, wrapper-positional-operand, direct-script-command-reach, analyzer-failure-visible
 set -euo pipefail
 
 input="$(cat)"
@@ -607,7 +607,9 @@ def command_word(statement):
         statement: One statement's tokens.
 
     Returns:
-        A pair (program, args); (None, []) when no program is named.
+        A triple (token, program, args); (None, None, []) when no program is
+        named. The raw token is retained because `./edit.sh` has no interpreter:
+        its command word is itself the executed script.
     """
     index = 0
     while index < len(statement):
@@ -617,7 +619,7 @@ def command_word(statement):
             continue
         program = token.rsplit("/", 1)[-1]
         if program not in FOLLOW_WRAPPERS:
-            return (program, statement[index + 1 :])
+            return (token, program, statement[index + 1 :])
         separate, positional = FOLLOW_WRAPPERS[program]
         index += 1
         while index < len(statement) and statement[index].startswith("-"):
@@ -627,7 +629,7 @@ def command_word(statement):
                 break
             index += 2 if option in separate else 1
         index += positional
-    return (None, [])
+    return (None, None, [])
 
 
 def shell_script_operand(args):
@@ -674,7 +676,7 @@ def write_targets(statement):
         Candidate paths this statement writes.
     """
     found = []
-    program, args = command_word(statement)
+    _token, program, args = command_word(statement)
     for index, token in enumerate(statement):
         if token in REDIRECT_OUT and index + 1 < len(statement):
             found.append(statement[index + 1])
@@ -697,7 +699,7 @@ def executed_script(statement):
     Returns:
         The operand token naming a script that will run, or None.
     """
-    program, args = command_word(statement)
+    token, program, args = command_word(statement)
     if program is None:
         return None
     if program in SHELL_PROGRAMS:
@@ -708,6 +710,12 @@ def executed_script(statement):
         return shell_script_operand(args)
     if program in SOURCE_BUILTINS:
         return args[0] if args else None
+    # A script in command position executes through its shebang. This also
+    # covers a direct path after wrappers such as `sudo ./edit.sh`; `command_word`
+    # deliberately keeps the raw token while using its basename for wrapper and
+    # shell classification.
+    if resolve(token) is not None:
+        return token
     return None
 
 
@@ -798,10 +806,27 @@ for target in targets:
     if cleaned:
         print(cleaned)
 PY
-    write_targets="$(printf '%s' "$analyzer" |
+    analyzer_stderr="$(mktemp "${TMPDIR:-/tmp}/lisa-managed-edit-analyzer.XXXXXX")" || {
+      printf 'block-managed-file-edits: could not allocate analyzer stderr capture; Bash write protection is NOT active\n' >&2
+      exit 0
+    }
+    if write_targets="$(printf '%s' "$analyzer" |
       MANAGED_EDIT_COMMAND="$command_str" \
         MANAGED_EDIT_PROJECT="$project_root" \
-        python3 - 2>/dev/null || true)"
+        python3 - 2>"$analyzer_stderr")"; then
+      analyzer_status=0
+    else
+      analyzer_status=$?
+    fi
+    if [ "$analyzer_status" -ne 0 ]; then
+      printf 'block-managed-file-edits: Bash analyzer failed (exit %s); Bash write protection is NOT active\n' "$analyzer_status" >&2
+      while IFS= read -r analyzer_line; do
+        [ -n "$analyzer_line" ] && printf '  python3: %s\n' "$analyzer_line" >&2
+      done <"$analyzer_stderr"
+      rm -f "$analyzer_stderr"
+      exit 0
+    fi
+    rm -f "$analyzer_stderr"
     while IFS= read -r token; do
       [ -n "$token" ] || continue
       if source_path="$(managed_source "$token")"; then

package/plugins/lisa-cursor/hooks/block-no-verify.sh

@@ -33,7 +33,7 @@
 # Add a name here in the same commit that closes a vector. A hardening that
 # forgets to is invisible to refresh, and shows up as an unexplained diff at
 # review time instead of a named capability.
-# lisa-guard-capabilities: no-verify-abbrev, husky-env, hookspath-allowlist, config-env, env-split-string, git-config-key, git-config-parameters, git-config-parameters-append, git-config-parameters-expansion, heredoc-shell-word, herestring-aware, no-verify-short, nested-shell-no-verify, nested-shell-long-options, env-split-string-abbrev, command-wrapper-normalization, executed-script-reach, source-builtin-reach, stdin-redirect-reach, wrapper-positional-operand, dispatcher-exec-position
+# lisa-guard-capabilities: no-verify-abbrev, husky-env, hookspath-allowlist, config-env, env-split-string, git-config-key, git-config-parameters, git-config-parameters-append, git-config-parameters-expansion, heredoc-shell-word, herestring-aware, no-verify-short, nested-shell-no-verify, nested-shell-long-options, env-split-string-abbrev, command-wrapper-normalization, executed-script-reach, source-builtin-reach, stdin-redirect-reach, wrapper-positional-operand, dispatcher-exec-position, tilde-script-reach, shell-option-stdin-reach
 #
 # Shell-token matching avoids false positives from issue bodies, heredocs, and
 # commit-message prose while still catching quoted real argv values such as
@@ -1007,7 +1007,7 @@ def resolve_script(token):
     """
     if COMPUTED_VALUE.search(token):
         return (None, "a computed path the guard cannot resolve before the shell does")
-    text = token.strip().strip("'\"")
+    text = os.path.expanduser(token.strip().strip("'\""))
     # `bash -` and a bare `-` read the script from stdin; there is no file.
     if not text or text == "-":
         return (None, None)
@@ -1029,6 +1029,48 @@ def resolve_script(token):
     return (None, "a script that does not exist or cannot be read")
 
 
+SHELL_COMMAND_STRING = object()
+SHELL_STDIN = object()
+
+
+def shell_execution_operand(args):
+    """The file a shell runs, or a sentinel for `-c` and stdin modes.
+
+    `shell_script_operand` intentionally collapses both cases to None for the
+    nested-command scanner. Reach cannot: `bash -c '...'` has already exposed
+    its text, while `bash -x`, `bash -e`, and `bash --` still await a script on
+    stdin and must remain linked to a following `< file` separator.
+    """
+    index = 0
+    opaque_option_seen = False
+    while index < len(args):
+        token = args[index]
+        if token == "--":
+            index += 1
+            break
+        if not token.startswith(("-", "+")):
+            if not opaque_option_seen:
+                break
+            index += 1
+            opaque_option_seen = False
+            continue
+        if token in SHELL_OPTIONS_SEPARATE_VALUE:
+            index += 2
+            continue
+        if token.startswith(SHELL_OPTIONS_INLINE_VALUE):
+            index += 1
+            continue
+        if token.startswith("--"):
+            if token not in SHELL_LONG_OPTIONS_NO_VALUE:
+                opaque_option_seen = True
+            index += 1
+            continue
+        if "c" in token[1:]:
+            return SHELL_COMMAND_STRING
+        index += 1
+    return args[index] if index < len(args) else SHELL_STDIN
+
+
 def executed_scripts(tokens):
     """The files a command line will RUN, and the executions it cannot follow.
 
@@ -1063,9 +1105,12 @@ def executed_scripts(tokens):
             if name in SOURCE_BUILTINS:
                 operand = arguments[0] if arguments else None
             elif name in SHELL_PROGRAMS:
-                operand = shell_script_operand(arguments)
-                if operand is None and not arguments:
+                operand = shell_execution_operand(arguments)
+                if operand is SHELL_STDIN:
                     previous_shell_awaiting_stdin = True
+                    continue
+                if operand is SHELL_COMMAND_STRING:
+                    continue
             else:
                 continue
             if operand is None:

package/plugins/lisa-cursor/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -460,6 +460,50 @@ passed off as success.
   `blocked:unreviewed`. This fallback lives inside the gated section above —
   with `auto_merge=false` it never fires; the PR remains open awaiting a human.
 
+### The mergeability gate — never arm a PR that cannot merge
+
+The arm gate above asks *did the review context do work?* This one asks a
+different question — *is there a verdict standing in the way?* — and they are
+not the same. A `CHANGES_REQUESTED` review unambiguously **did work**, so it
+sails through the arm gate and the latch goes on over the top of it.
+
+**Read `reviewDecision` explicitly. Never infer it from a check count.**
+
+```bash
+gh pr view <pr> --json reviewDecision,reviewThreads \
+  --jq '{decision: .reviewDecision, unresolved: [.reviewThreads[]? | select(.isResolved == false)] | length}'
+```
+
+`reviewDecision` is **not part of `statusCheckRollup`**. That is the whole reason
+this stayed invisible: a failing-check count reads **zero** on a PR that can
+never merge, and the checks tab is entirely green. Any rule keyed on "no red
+checks" is satisfied by exactly the PR this gate exists to catch (#3720).
+
+**Do not arm while `reviewDecision == CHANGES_REQUESTED`.** Arming is a claim
+that this PR will merge, and that claim is false here. Clear the verdict through
+step (e) first — which discriminates a live objection from a stranded one by
+unresolved thread count, not by `reviewDecision` — and arm afterwards.
+
+**Two ruleset settings decide whether a standing verdict ever clears itself, and
+in this repository both say no.** Verify them for the repo you are in rather
+than assuming, with `gh api repos/<owner>/<repo>/rulesets`:
+
+- `dismiss_stale_reviews_on_push: false` — the review stays attached to the
+  commit it was made on, so **pushing the fix never clears it**. The intuition
+  that a new head resets the verdict is wrong here.
+- `required_approving_review_count: 0` — no approval is required to merge, so a
+  standing `CHANGES_REQUESTED` is not holding a slot for a review that would
+  otherwise arrive. Nothing is scheduled to clear it.
+
+Together those mean the block is **indefinite, not slow**. Waiting is not a
+strategy; something has to act.
+
+**Unresolved threads block independently of the verdict.** This repository sets
+`required_review_thread_resolution: true`, so a PR can have a clear
+`reviewDecision` and still be unmergeable on threads alone — a second blocker
+that is equally absent from the check rollup. Read both, and name whichever one
+is standing; reporting the wrong one sends the operator to the wrong place.
+
 ## 2. The watch loop
 
 Poll the live state each iteration:
@@ -1078,6 +1122,14 @@ Loop until one of:
   the one thing nobody would then do is investigate it. Usually a missing
   `issues: read` / label-read permission, which is fixable and invisible from
   the merge outcome alone.
+- **`blocked:armed-unmergeable`** — the PR is OPEN, auto-merge is ON, every check
+  is green, and it still cannot merge: `reviewDecision == CHANGES_REQUESTED`, or
+  unresolved review threads under `required_review_thread_resolution`. Report the
+  PR URL, **which** of the two is standing, and that it will not clear itself.
+  For example: *"PR #123 looks ready — every check is green and auto-merge is on
+  — but a review asked for changes and that is still on record, so it will sit
+  there forever. Someone needs to clear that review or resolve the open
+  comments."* Never report this PR as merging.
 - **`CLOSED`** → report (PR was closed without merge).
 - **Hard block needing a human**: an unresolvable conflict, a failing check that
   needs design input, or genuine unresolved human objection (not a bot gate). Stop
@@ -1087,6 +1139,44 @@ Loop until one of:
   adversarial-review substitute is posted (step d); it never extends to any
   other gate.
 
+### Before you stop: never leave a PR armed and unmergeable in silence
+
+**This applies at every exit that leaves the PR OPEN** — not only the terminal
+states above, but any point where this run concludes it is finished, hands back,
+or gives up. Re-read, from the live PR, immediately before reporting:
+
+```bash
+gh pr view <pr> --json state,autoMergeRequest,reviewDecision,reviewThreads \
+  --jq '{state, armed: (.autoMergeRequest != null), decision: .reviewDecision,
+         unresolved: [.reviewThreads[]? | select(.isResolved == false)] | length}'
+```
+
+If `state == OPEN` and `armed` and either `decision == "CHANGES_REQUESTED"` or
+`unresolved > 0`, the outcome is **`blocked:armed-unmergeable`** — never a
+success, and never silence.
+
+**Why this exists rather than trusting the loop.** While the loop runs this is
+already covered: the watch poll reads `reviewDecision` and step (e) handles it.
+The failure is a run that **stops** while the PR is armed and blocked — the
+session ends, or the agent decides the work is done because arming looked like
+completion. Measured (#3720): three PRs were left armed, green and permanently
+unmergeable, and every one was found only because a person queried
+`reviewDecision` by hand. An agent that arms auto-merge and reports "armed, will
+merge" is reporting something false and has no reason to know it.
+
+**Arming is not completion.** It is a claim about the future that this check is
+what makes honest. The claim costs nothing when true — one read, and the report
+says merging — and when false it is the only thing standing between a parked PR
+and nobody noticing for hours.
+
+**Read the two fields; do not substitute a check count.** Zero failing checks is
+the symptom, not the signal — that is precisely why this class was invisible.
+
+In `on_blocker=report` mode the same condition returns the existing
+`blocked:changes_requested` classification rather than this terminal state: that
+mode returns a blocker for the caller to act on, and does not drive. The two
+names describe the same PR seen from the two modes.
+
 At every terminal state, release the babysitter lease
 (`gh pr edit <pr> --remove-label "lisa:babysitter-on-duty"`) so the CI
 auto-fix workflow can take over as fixer of last resort if the branch goes

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

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