@codyswann/lisa 4.52.1 → 4.53.0

package/plugins/lisa-cursor/scripts/blocker-edge-resolution.mjs

@@ -0,0 +1,150 @@
+#!/usr/bin/env node
+/**
+ * What to do with a dependency edge once its blocker has been judged.
+ *
+ * ## The gap this fills
+ *
+ * `blocker-containment` decides ONE question — given an edge, is it satisfied —
+ * and says so in its own words: it "does not decide when a dependency edge
+ * should exist, dissolve an edge once satisfied, or govern what a surface does
+ * after clearing". Nothing else claimed that job. So a repair pass that ruled a
+ * dependency satisfied moved the STATE and left the EDGE, recording the ruling
+ * as a comment; the next reader parses relations, not prose, and blocks again
+ * (CodySwannGT/lisa#3472). The durable artifact of "this is satisfied" had no
+ * mechanical effect.
+ *
+ * Measured on this repository while writing this: of 11 open `status:blocked`
+ * items carrying a parsable `Blocked by #N`, 5 were held behind blockers that
+ * were all closed.
+ *
+ * ## Why closure is not the test, and neither is "it is finished"
+ *
+ * Two different mistakes converge on the same wrong answer.
+ *
+ * The first is testing a state NAME. That half is already fixed: the triage
+ * gate now clear-checks by containment, because a promotion workflow types its
+ * merged-and-deployed rungs `started`, so `Done` strands every dependent behind
+ * work already merged where the dependent needs it.
+ *
+ * The second is treating CLOSED as satisfied. An `is blocked by` edge is a
+ * DEVELOPMENT dependency: it is satisfied when the blocker's code is on the
+ * branch this work builds from. A blocker can be closed with no code — and a
+ * blocker closed `NOT_PLANNED` is the sharp case, because it means the thing
+ * depended on will never be built. Dissolving that edge silently converts "what
+ * we needed is cancelled" into "we are unblocked", which is the same wrong-write
+ * family as CodySwannGT/lisa#3479, where a reason-blind repair would have
+ * stamped a production terminal on abandoned work. So an abandoned blocker
+ * ESCALATES to a human rather than dissolving or silently holding forever:
+ * somebody has to decide whether the dependent still makes sense.
+ *
+ * ## What this module does not decide
+ *
+ * How an edge is dissolved on a given tracker. That is vendor work with its own
+ * hazard: on Linear, `issueRelationCreate` CONVERTS an existing relation rather
+ * than adding one (CodySwannGT/lisa#3605), so a writer that "updates" an edge
+ * can destroy a different one. This module returns a decision; the vendor
+ * surface performs it and reads it back.
+ * @module blocker-edge-resolution
+ */
+
+/** Every action a surface may take on a judged edge. */
+export const EDGE_ACTIONS = Object.freeze(["dissolve", "keep", "escalate"]);
+
+/** GitHub's closure reason for work that will deliberately not be done. */
+const NOT_PLANNED = "not_planned";
+
+/**
+ * Decide what happens to one `is blocked by` edge.
+ *
+ * `contained` is the containment verdict — the blocker's merged code is an
+ * ancestor of the branch this work builds from — and it is deliberately the
+ * ONLY positive signal. Everything else here exists to keep a non-containment
+ * signal from being mistaken for one.
+ * @param {{
+ *   contained?: boolean | null,
+ *   blockerState?: string,
+ *   blockerReason?: string,
+ * }} input The containment verdict and the blocker's tracker state.
+ * @returns {{action: string, reason: string}} What to do, and why.
+ */
+export function resolveBlockerEdge(input = {}) {
+  const state = String(input.blockerState ?? "")
+    .trim()
+    .toLowerCase();
+  const reason = String(input.blockerReason ?? "")
+    .trim()
+    .toLowerCase();
+
+  // Checked BEFORE containment, because an abandoned blocker whose branch
+  // happens to contain some earlier commit of its own is still abandoned. The
+  // question a human has to answer is whether the dependent still makes sense,
+  // and a containment true would silently answer it for them.
+  if (state === "closed" && reason === NOT_PLANNED) {
+    return {
+      action: "escalate",
+      reason:
+        "the blocker was closed as NOT PLANNED, so the work this item depends on will never be " +
+        "delivered. Dissolving the edge would read as 'unblocked' when nothing was built, and " +
+        "holding it forever hides a decision somebody has to make: does this item still make sense " +
+        "without its blocker? That is a human call, not a sweep's.",
+    };
+  }
+
+  if (input.contained === true) {
+    return {
+      action: "dissolve",
+      reason:
+        "the blocker's merged code is present on the branch this item builds from, so the " +
+        "development dependency is satisfied. Remove the edge in the same write that records the " +
+        "ruling, and read it back — a state move plus a comment is a claim about a clearance, not " +
+        "a clearance, and the next reader parses relations rather than prose.",
+    };
+  }
+
+  if (input.contained === null || input.contained === undefined) {
+    return {
+      action: "escalate",
+      reason:
+        "containment could not be computed for this blocker, so whether the dependency is satisfied " +
+        "is unknown. An unknown is not a clearance: dissolving here would be a guess in the " +
+        "direction that releases work, which is the direction nothing downstream re-checks.",
+    };
+  }
+
+  return {
+    action: "keep",
+    reason:
+      state === "closed"
+        ? "the blocker is closed but its code is not on the branch this item builds from. Closing an " +
+          "item is not the same as shipping it, and an `is blocked by` edge is a development " +
+          "dependency, not a bookkeeping one."
+        : "the blocker's code is not yet on the branch this item builds from, so the dependency " +
+          "still holds.",
+  };
+}
+
+/**
+ * Decide a whole set of edges, and say whether the item can proceed.
+ *
+ * An item proceeds only when every edge dissolves. One escalation holds the
+ * item — reporting it, rather than proceeding on the majority verdict, is what
+ * keeps a single unanswerable edge from being rounded away.
+ * @param {readonly object[]} edges Per-edge inputs, in the item's own order.
+ * @returns {{
+ *   proceed: boolean,
+ *   decisions: {action: string, reason: string}[],
+ *   escalations: number,
+ * }} The per-edge decisions and whether the item is free to move.
+ */
+export function resolveBlockerEdges(edges = []) {
+  const decisions = (edges ?? []).map(edge => ({
+    ...edge,
+    ...resolveBlockerEdge(edge),
+  }));
+  return {
+    proceed:
+      decisions.length > 0 && decisions.every(one => one.action === "dissolve"),
+    decisions,
+    escalations: decisions.filter(one => one.action === "escalate").length,
+  };
+}

package/plugins/lisa-cursor/scripts/install-remote-agent-aws.mjs

@@ -342,6 +342,20 @@ so rather than repointing every unqualified \`aws\` command. Pass
 Production and shared profiles are observer-only. Production repair remains a
 human-driven local-workstation operation.
 
+Observer-only names what those profiles may READ, not only what they may not
+write. Prove that half — a role that can read nothing satisfies every deny-side
+assertion ever made about it:
+
+\`\`\`bash
+LISA_AWS_VERIFY_OBSERVER_READS=1 bash scripts/remote-agent-aws-setup.sh
+\`\`\`
+
+It runs one representative read per observability surface against every observer
+profile — deployment stacks, compute inventory, alarm state, delivery pipelines,
+builds, functions, logs, http endpoints, queues, workflows — and refuses to
+report ready if any is denied, naming all of them at once. Every action is
+read-only, so widening the role's policy to satisfy it grants no write anywhere.
+
 After the infrastructure pipeline deploys the remote-agent IAM stacks, retrieve
 the complete bundle from the shared account. Do not extract or distribute its
 individual access-key fields:

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

@@ -27,6 +27,11 @@
 #   LISA_AWS_VERIFY_ALL_PROFILES
 #                           1 to prove every stage's account, not just the
 #                           default's.
+#   LISA_AWS_VERIFY_OBSERVER_READS
+#                           1 to prove the ALLOW side of every observer-only
+#                           profile: one representative read per observability
+#                           surface must succeed. A role that can read nothing
+#                           fails here instead of at verification time.
 #   LISA_AWS_CLAIM_DEFAULT_PROFILE
 #                           1 to take over a `[default]` this project does not
 #                           already own. Off by default: silently repointing
@@ -337,6 +342,120 @@ assert_profile_account() {
     "profile ${profile} (stage ${stage}) resolved to AWS account ${actual}, but this project expects ${expected}. The credentials authenticate; they are not this project's account. Refusing to report ready."
 }
 
+# What an observer-only role must be able to READ.
+#
+# "Observer-only" was defined entirely by what it must not do, and the proof
+# prescribed for it tested only the deny side. A role that can read NOTHING
+# passes a deny-side check perfectly, so the read surface of a headless verifier
+# was being discovered one `AccessDenied` at a time, mid-verification, and
+# granted one ticket at a time. Three consecutive incidents in one consumer had
+# that exact shape: instance discovery, alarm reads, and pipeline definition
+# reads — none of those services appeared in the shipped starter policy at all,
+# because that policy enumerated the services the stack happened to deploy
+# rather than answering "what must a verifier be able to read?".
+#
+# So the surfaces below are derived from the ROLE'S PURPOSE, not from any one
+# stack's topology. Each row is a surface, the read that represents it, and the
+# question an observer cannot answer without it. Every action is read-only:
+# widening the allow side generously is far cheaper than rediscovering it by
+# denial, and it grants no write anywhere.
+#
+# Each probe takes no resource name, which is what lets it run against a fresh
+# account with nothing deployed — these ask an IAM question, not an inventory
+# one, and an empty result is a pass. The limitation that buys: a surface whose
+# list action is granted while its detail action is not still passes here. That
+# is exactly incident three, where the role could list pipeline executions but
+# could not read the pipeline definition, so the table names both halves in the
+# question column and the docs state the requirement; the probe proves the
+# surface is reachable, not that every action on it is granted.
+OBSERVER_READ_SURFACES=$(
+  cat <<'SURFACES'
+deployment stacks	cloudformation describe-stacks	what is deployed, and did the last change apply or roll back
+compute inventory	ec2 describe-instances	what is actually running, and is it healthy
+alarm state	cloudwatch describe-alarms	is anything alarming right now, and since when
+delivery pipelines	codepipeline list-pipelines	what the pipeline does and where this change stopped, definition as well as executions
+builds	codebuild list-projects	did the build run, and what did it say
+functions	lambda list-functions	is the handler deployed, and at which version
+logs	logs describe-log-groups	what it printed when it failed
+http endpoints	apigateway get-rest-apis	is the endpoint published and reachable
+queues	sqs list-queues	is work backing up or dead-lettering
+workflows	stepfunctions list-state-machines	did the orchestrated run complete or stall
+SURFACES
+)
+
+# Stages whose profile is observer-only, per the contract's own words.
+#
+# The bootstrap bundle carries no observer field today, so this reads one if a
+# bundle supplies it and otherwise falls back to the definition the contract
+# already states in prose: dev and staging may repair, production and shared are
+# observer-only. Deriving it is what makes "observer" exist anywhere other than
+# a sentence in a document — until now nothing in the data or the code could
+# answer which profiles the word applied to.
+is_observer_stage() {
+  local stage declared
+  stage="$1"
+  # `has` rather than `.observer // empty`: jq's alternative operator treats
+  # `false` as absent, so a stage that explicitly declared itself NOT an
+  # observer fell through to the name-based default and was probed anyway —
+  # the declaration was accepted only when it agreed with the guess.
+  declared="$(printf '%s' "$profiles_json" | jq -r --arg s "$stage" '
+    .[$s] | if type == "object" and has("observer") then (.observer | tostring) else empty end
+  ')"
+  if [ -n "$declared" ]; then
+    [ "$declared" = "true" ]
+    return
+  fi
+  case "$stage" in
+    production | shared) return 0 ;;
+    *) return 1 ;;
+  esac
+}
+
+# Prove the ALLOW side of an observer profile.
+#
+# Reports every surface it could not read rather than stopping at the first,
+# because an operator repairing a policy wants the whole list — the same reason
+# the toolchain planner reports every unresolvable tool at once. One ticket, not
+# three in a row.
+#
+# Denied and unreachable are kept apart. A read that fails because the service
+# could not be reached says nothing about the policy, and folding it into
+# "denied" would send someone to widen a policy that was already correct; a pass
+# is never claimed from either.
+assert_observer_reads() {
+  local profile stage denied unreachable surface probe question output status
+  profile="$1"
+  stage="$2"
+  denied=""
+  unreachable=""
+
+  while IFS="$(printf '\t')" read -r surface probe question; do
+    [ -n "$surface" ] || continue
+    set +e
+    output="$(AWS_PAGER="" aws --profile "$profile" $probe 2>&1)"
+    status=$?
+    set -e
+    [ "$status" -eq 0 ] && continue
+    case "$output" in
+      *AccessDenied* | *UnauthorizedOperation* | *not\ authorized*)
+        denied="${denied}
+  ${surface} — \`aws ${probe}\` was denied, so this role cannot answer: ${question}"
+        ;;
+      *)
+        unreachable="${unreachable}
+  ${surface} — \`aws ${probe}\` did not return an authorization answer at all: ${output}"
+        ;;
+    esac
+  done <<<"$OBSERVER_READ_SURFACES"
+
+  if [ -n "$unreachable" ]; then
+    fail "profile ${profile} (stage ${stage}) could not be checked against the observer read surface, so nothing about its permissions was proved:${unreachable}"
+  fi
+  if [ -n "$denied" ]; then
+    fail "profile ${profile} (stage ${stage}) is observer-only but cannot read the surfaces an observer exists to read. Widen the role's read-only policy to cover them; every action below is read-only and none grants a write:${denied}"
+  fi
+}
+
 # Who currently owns `[default]`.
 #
 # `default` is the one name that cannot be namespaced, so it is the one place
@@ -530,6 +649,21 @@ if [ "${LISA_AWS_SKIP_VERIFY:-0}" != "1" ]; then
   else
     assert_profile_account "$default_profile" "$default_expected_account" "$default_stage"
   fi
+  # Ordered after the account assertions on purpose, and it is the ordering that
+  # makes either half mean anything. `AccessDenied` is what an unassumed role, a
+  # misconfigured profile and a correctly-scoped observer all return, so a
+  # boundary check run before identity is bound passes on a credential that
+  # reached the wrong account entirely — the same class of vacuous pass this
+  # script already refuses for `sts:GetCallerIdentity`. Binding the profile to
+  # its expected account first is what turns the reads below into a statement
+  # about THIS role.
+  if [ "${LISA_AWS_VERIFY_OBSERVER_READS:-0}" = "1" ]; then
+    while IFS= read -r stage; do
+      [ -n "$stage" ] || continue
+      is_observer_stage "$stage" || continue
+      assert_observer_reads "${PROFILE_NAMESPACE}-agent-${stage}" "$stage"
+    done < <(printf '%s' "$profiles_json" | jq -r 'keys[]')
+  fi
 fi
 
 if [ -n "$legacy_names" ]; then

package/plugins/lisa-cursor/skills/lisa-repair-intake/SKILL.md

@@ -566,10 +566,29 @@ condition observed, filed under the wrong heading, and overridden.
    **deployed / runtime verification failure**, by an **ambiguity**, or by more than one at once.
    Re-check **every** class present — do not stop at "no `is blocked by` links, therefore nothing
    to do." A self-block has zero dependencies by definition, yet is fully re-checkable.
-2. **Dependency cleared** — if every parsed `is blocked by` dependency is **cleared** → move
-   `blocked → claimed`, then run the same agent-dispatch + post-agent `claimed → done` sequence as
-   the stalled-`claimed` path above (one-cycle recovery). If the agent re-blocks, move back to
-   `blocked` — a valid outcome.
+2. **Dependency cleared** — decide each parsed `is blocked by` edge with
+   `scripts/blocker-edge-resolution.mjs`, feeding it the `blocker-containment` verdict plus the
+   blocker's state and closure reason. It returns `dissolve` / `keep` / `escalate` per edge.
+   **Dissolve the edge in the SAME write that records the ruling, then read the relation back and
+   confirm it is gone.** Only when every edge dissolves → move `blocked → claimed`, then run the
+   same agent-dispatch + post-agent `claimed → done` sequence as the stalled-`claimed` path above
+   (one-cycle recovery). If the agent re-blocks, move back to `blocked` — a valid outcome.
+
+   **Moving the state without removing the edge is not a clearance, it is a claim about one.** That
+   was the defect (CodySwannGT/lisa#3472): the pass moved the state and left the relation, recording
+   the ruling as a comment, and the next reader parses relations rather than prose — so the block
+   re-formed every cycle and a human had to break the loop. Reading the relation back is what makes
+   "I removed the link" distinguishable from "I meant to".
+
+   **An `escalate` verdict holds the item and reports it — never dissolve on it.** The sharp case is
+   a blocker closed `NOT PLANNED`: the work depended on will never be delivered, so dissolving reads
+   as "unblocked" when nothing was built, and holding silently hides a decision only a human can
+   make. Treating closure as satisfaction is the same reason-blind wrong write as
+   CodySwannGT/lisa#3479. A single escalation among otherwise-dissolving edges holds the item.
+
+   **On Linear, dissolve with a relation DELETE.** Do not "update" an edge:
+   `issueRelationCreate` CONVERTS an existing relation rather than adding one
+   (CodySwannGT/lisa#3605), so a writer reaching for it can destroy a different edge.
 3. **Validation / quality-gate self-block re-check** — if the block reason is a pre-flight
    `verify`/`validate` gate failure (its `[lisa-*]` block note carries a gate marker + a "Missing
    requirements" list and there is **no** open `is blocked by` dependency), re-run the **same gate**

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.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": "4.52.1",
+  "version": "4.53.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"