@codyswann/lisa 2.176.1 → 2.176.3

package/package.json

@@ -91,7 +91,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.176.1",
+  "version": "2.176.3",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

@@ -25,9 +25,10 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     resolve review comments, dismiss stale review gates — drive until merged.
   - **`report`** (diagnose & mechanically nudge only): perform just the safe,
     idempotent, non-destructive actions — ensure auto-merge is enabled and, if the
-    PR is `BEHIND` but otherwise clean, run `gh pr update-branch`. For **anything**
-    that would require editing code, resolving threads, or dismissing a review,
-    **do not act** — stop and return a structured blocker classification
+    PR is `BEHIND` but otherwise clean, run `gh pr update-branch` only when the
+    base branch requires strict up-to-date checks. For **anything** that would
+    require editing code, resolving threads, or dismissing a review, **do not
+    act** — stop and return a structured blocker classification
     (`merged` / `will-merge-after-resync` / `blocked:<conflict|checks|changes_requested|deploy>`)
     so the caller applies its own policy. This is the mode `repair-intake` and the
     build-intake skills use to diagnose-and-route without fixing in place.
@@ -60,8 +61,33 @@ apply; for any of (b)–(e) do not act — classify the blocker and return per t
 contract above.
 
 ### a. Branch behind base (`mergeStateStatus == BEHIND`)
-Once required checks are green, run `gh pr update-branch <pr>` and keep watching the
-new head while checks rerun.
+Before proactively syncing a clean `BEHIND` PR, check whether the base branch
+actually requires up-to-date branches:
+
+```bash
+owner_repo=$(gh repo view --json nameWithOwner -q .nameWithOwner)
+base=$(gh pr view <pr> --json baseRefName -q .baseRefName)
+strict=$(gh api "repos/$owner_repo/rules/branches/$base" \
+  --jq '[.[] | select(.type == "required_status_checks") | .parameters.strict_required_status_checks_policy // false] | any')
+```
+
+If that rules endpoint is unavailable, fall back to classic branch protection:
+
+```bash
+strict=$(gh api "repos/$owner_repo/branches/$base/protection/required_status_checks" \
+  --jq '.strict // false')
+```
+
+Only when `strict == true`, once required checks are green, run
+`gh pr update-branch <pr>` and keep watching the new head while checks rerun.
+If `strict == false`, do **not** update the branch solely because the base moved:
+continue the mergeability loop and let GitHub merge the existing head once the
+checks/reviews are acceptable. This avoids cancellation storms in repos whose CI
+uses `concurrency.cancel-in-progress: true`.
+
+Still sync when it is necessary to resolve a genuine merge conflict, and it is
+acceptable to perform one final sync immediately before a direct merge if the
+merge attempt proves the head must be updated.
 
 ### b. Sync/merge conflict
 If `gh pr update-branch` reports a conflict (or `mergeStateStatus == DIRTY`):

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

@@ -393,9 +393,12 @@ drive-pr-to-merge  pr=<n>  on_blocker=report
 ```
 
 In report mode it ensures auto-merge is enabled and runs `gh pr update-branch <n>` only when the
-PR is `BEHIND`-but-clean; it never edits code, resolves threads, or dismisses reviews. It returns a
-classification (`merged` / `will-merge-after-resync` / `blocked:<reason>`). On a `merged` /
-`will-merge-after-resync` result,
+PR is `BEHIND`-but-clean **and** the base branch's ruleset or classic branch protection requires
+strict up-to-date status checks (`strict_required_status_checks_policy` / `required_status_checks.strict`).
+If strict checks are off, it does not update the branch solely because the base moved; that avoids
+CI cancellation storms in repos where updating the PR head restarts and cancels in-flight runs. It
+never edits code, resolves threads, or dismisses reviews. It returns a classification (`merged` /
+`will-merge-after-resync` / `blocked:<reason>`). On a `merged` / `will-merge-after-resync` result,
 record this as a repair write (`resynced`), keep the item `claimed`, and move on — a later cycle sees
 the now-`CLEAN` (or merged) PR and either lets auto-merge finish or applies the merged-PR recovery in
 step 2. Only if `gh pr update-branch` itself reports a conflict it cannot apply does the PR become a

package/plugins/lisa-agy/plugin.json

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

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

@@ -25,9 +25,10 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     resolve review comments, dismiss stale review gates — drive until merged.
   - **`report`** (diagnose & mechanically nudge only): perform just the safe,
     idempotent, non-destructive actions — ensure auto-merge is enabled and, if the
-    PR is `BEHIND` but otherwise clean, run `gh pr update-branch`. For **anything**
-    that would require editing code, resolving threads, or dismissing a review,
-    **do not act** — stop and return a structured blocker classification
+    PR is `BEHIND` but otherwise clean, run `gh pr update-branch` only when the
+    base branch requires strict up-to-date checks. For **anything** that would
+    require editing code, resolving threads, or dismissing a review, **do not
+    act** — stop and return a structured blocker classification
     (`merged` / `will-merge-after-resync` / `blocked:<conflict|checks|changes_requested|deploy>`)
     so the caller applies its own policy. This is the mode `repair-intake` and the
     build-intake skills use to diagnose-and-route without fixing in place.
@@ -60,8 +61,33 @@ apply; for any of (b)–(e) do not act — classify the blocker and return per t
 contract above.
 
 ### a. Branch behind base (`mergeStateStatus == BEHIND`)
-Once required checks are green, run `gh pr update-branch <pr>` and keep watching the
-new head while checks rerun.
+Before proactively syncing a clean `BEHIND` PR, check whether the base branch
+actually requires up-to-date branches:
+
+```bash
+owner_repo=$(gh repo view --json nameWithOwner -q .nameWithOwner)
+base=$(gh pr view <pr> --json baseRefName -q .baseRefName)
+strict=$(gh api "repos/$owner_repo/rules/branches/$base" \
+  --jq '[.[] | select(.type == "required_status_checks") | .parameters.strict_required_status_checks_policy // false] | any')
+```
+
+If that rules endpoint is unavailable, fall back to classic branch protection:
+
+```bash
+strict=$(gh api "repos/$owner_repo/branches/$base/protection/required_status_checks" \
+  --jq '.strict // false')
+```
+
+Only when `strict == true`, once required checks are green, run
+`gh pr update-branch <pr>` and keep watching the new head while checks rerun.
+If `strict == false`, do **not** update the branch solely because the base moved:
+continue the mergeability loop and let GitHub merge the existing head once the
+checks/reviews are acceptable. This avoids cancellation storms in repos whose CI
+uses `concurrency.cancel-in-progress: true`.
+
+Still sync when it is necessary to resolve a genuine merge conflict, and it is
+acceptable to perform one final sync immediately before a direct merge if the
+merge attempt proves the head must be updated.
 
 ### b. Sync/merge conflict
 If `gh pr update-branch` reports a conflict (or `mergeStateStatus == DIRTY`):

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

@@ -393,9 +393,12 @@ drive-pr-to-merge  pr=<n>  on_blocker=report
 ```
 
 In report mode it ensures auto-merge is enabled and runs `gh pr update-branch <n>` only when the
-PR is `BEHIND`-but-clean; it never edits code, resolves threads, or dismisses reviews. It returns a
-classification (`merged` / `will-merge-after-resync` / `blocked:<reason>`). On a `merged` /
-`will-merge-after-resync` result,
+PR is `BEHIND`-but-clean **and** the base branch's ruleset or classic branch protection requires
+strict up-to-date status checks (`strict_required_status_checks_policy` / `required_status_checks.strict`).
+If strict checks are off, it does not update the branch solely because the base moved; that avoids
+CI cancellation storms in repos where updating the PR head restarts and cancels in-flight runs. It
+never edits code, resolves threads, or dismisses reviews. It returns a classification (`merged` /
+`will-merge-after-resync` / `blocked:<reason>`). On a `merged` / `will-merge-after-resync` result,
 record this as a repair write (`resynced`), keep the item `claimed`, and move on — a later cycle sees
 the now-`CLEAN` (or merged) PR and either lets auto-merge finish or applies the merged-PR recovery in
 step 2. Only if `gh pr update-branch` itself reports a conflict it cannot apply does the PR become a

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

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

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

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

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

@@ -25,9 +25,10 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     resolve review comments, dismiss stale review gates — drive until merged.
   - **`report`** (diagnose & mechanically nudge only): perform just the safe,
     idempotent, non-destructive actions — ensure auto-merge is enabled and, if the
-    PR is `BEHIND` but otherwise clean, run `gh pr update-branch`. For **anything**
-    that would require editing code, resolving threads, or dismissing a review,
-    **do not act** — stop and return a structured blocker classification
+    PR is `BEHIND` but otherwise clean, run `gh pr update-branch` only when the
+    base branch requires strict up-to-date checks. For **anything** that would
+    require editing code, resolving threads, or dismissing a review, **do not
+    act** — stop and return a structured blocker classification
     (`merged` / `will-merge-after-resync` / `blocked:<conflict|checks|changes_requested|deploy>`)
     so the caller applies its own policy. This is the mode `repair-intake` and the
     build-intake skills use to diagnose-and-route without fixing in place.
@@ -60,8 +61,33 @@ apply; for any of (b)–(e) do not act — classify the blocker and return per t
 contract above.
 
 ### a. Branch behind base (`mergeStateStatus == BEHIND`)
-Once required checks are green, run `gh pr update-branch <pr>` and keep watching the
-new head while checks rerun.
+Before proactively syncing a clean `BEHIND` PR, check whether the base branch
+actually requires up-to-date branches:
+
+```bash
+owner_repo=$(gh repo view --json nameWithOwner -q .nameWithOwner)
+base=$(gh pr view <pr> --json baseRefName -q .baseRefName)
+strict=$(gh api "repos/$owner_repo/rules/branches/$base" \
+  --jq '[.[] | select(.type == "required_status_checks") | .parameters.strict_required_status_checks_policy // false] | any')
+```
+
+If that rules endpoint is unavailable, fall back to classic branch protection:
+
+```bash
+strict=$(gh api "repos/$owner_repo/branches/$base/protection/required_status_checks" \
+  --jq '.strict // false')
+```
+
+Only when `strict == true`, once required checks are green, run
+`gh pr update-branch <pr>` and keep watching the new head while checks rerun.
+If `strict == false`, do **not** update the branch solely because the base moved:
+continue the mergeability loop and let GitHub merge the existing head once the
+checks/reviews are acceptable. This avoids cancellation storms in repos whose CI
+uses `concurrency.cancel-in-progress: true`.
+
+Still sync when it is necessary to resolve a genuine merge conflict, and it is
+acceptable to perform one final sync immediately before a direct merge if the
+merge attempt proves the head must be updated.
 
 ### b. Sync/merge conflict
 If `gh pr update-branch` reports a conflict (or `mergeStateStatus == DIRTY`):

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

@@ -393,9 +393,12 @@ drive-pr-to-merge  pr=<n>  on_blocker=report
 ```
 
 In report mode it ensures auto-merge is enabled and runs `gh pr update-branch <n>` only when the
-PR is `BEHIND`-but-clean; it never edits code, resolves threads, or dismisses reviews. It returns a
-classification (`merged` / `will-merge-after-resync` / `blocked:<reason>`). On a `merged` /
-`will-merge-after-resync` result,
+PR is `BEHIND`-but-clean **and** the base branch's ruleset or classic branch protection requires
+strict up-to-date status checks (`strict_required_status_checks_policy` / `required_status_checks.strict`).
+If strict checks are off, it does not update the branch solely because the base moved; that avoids
+CI cancellation storms in repos where updating the PR head restarts and cancels in-flight runs. It
+never edits code, resolves threads, or dismisses reviews. It returns a classification (`merged` /
+`will-merge-after-resync` / `blocked:<reason>`). On a `merged` / `will-merge-after-resync` result,
 record this as a repair write (`resynced`), keep the item `claimed`, and move on — a later cycle sees
 the now-`CLEAN` (or merged) PR and either lets auto-merge finish or applies the merged-PR recovery in
 step 2. Only if `gh pr update-branch` itself reports a conflict it cannot apply does the PR become a

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

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

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

@@ -25,9 +25,10 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     resolve review comments, dismiss stale review gates — drive until merged.
   - **`report`** (diagnose & mechanically nudge only): perform just the safe,
     idempotent, non-destructive actions — ensure auto-merge is enabled and, if the
-    PR is `BEHIND` but otherwise clean, run `gh pr update-branch`. For **anything**
-    that would require editing code, resolving threads, or dismissing a review,
-    **do not act** — stop and return a structured blocker classification
+    PR is `BEHIND` but otherwise clean, run `gh pr update-branch` only when the
+    base branch requires strict up-to-date checks. For **anything** that would
+    require editing code, resolving threads, or dismissing a review, **do not
+    act** — stop and return a structured blocker classification
     (`merged` / `will-merge-after-resync` / `blocked:<conflict|checks|changes_requested|deploy>`)
     so the caller applies its own policy. This is the mode `repair-intake` and the
     build-intake skills use to diagnose-and-route without fixing in place.
@@ -60,8 +61,33 @@ apply; for any of (b)–(e) do not act — classify the blocker and return per t
 contract above.
 
 ### a. Branch behind base (`mergeStateStatus == BEHIND`)
-Once required checks are green, run `gh pr update-branch <pr>` and keep watching the
-new head while checks rerun.
+Before proactively syncing a clean `BEHIND` PR, check whether the base branch
+actually requires up-to-date branches:
+
+```bash
+owner_repo=$(gh repo view --json nameWithOwner -q .nameWithOwner)
+base=$(gh pr view <pr> --json baseRefName -q .baseRefName)
+strict=$(gh api "repos/$owner_repo/rules/branches/$base" \
+  --jq '[.[] | select(.type == "required_status_checks") | .parameters.strict_required_status_checks_policy // false] | any')
+```
+
+If that rules endpoint is unavailable, fall back to classic branch protection:
+
+```bash
+strict=$(gh api "repos/$owner_repo/branches/$base/protection/required_status_checks" \
+  --jq '.strict // false')
+```
+
+Only when `strict == true`, once required checks are green, run
+`gh pr update-branch <pr>` and keep watching the new head while checks rerun.
+If `strict == false`, do **not** update the branch solely because the base moved:
+continue the mergeability loop and let GitHub merge the existing head once the
+checks/reviews are acceptable. This avoids cancellation storms in repos whose CI
+uses `concurrency.cancel-in-progress: true`.
+
+Still sync when it is necessary to resolve a genuine merge conflict, and it is
+acceptable to perform one final sync immediately before a direct merge if the
+merge attempt proves the head must be updated.
 
 ### b. Sync/merge conflict
 If `gh pr update-branch` reports a conflict (or `mergeStateStatus == DIRTY`):

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

@@ -393,9 +393,12 @@ drive-pr-to-merge  pr=<n>  on_blocker=report
 ```
 
 In report mode it ensures auto-merge is enabled and runs `gh pr update-branch <n>` only when the
-PR is `BEHIND`-but-clean; it never edits code, resolves threads, or dismisses reviews. It returns a
-classification (`merged` / `will-merge-after-resync` / `blocked:<reason>`). On a `merged` /
-`will-merge-after-resync` result,
+PR is `BEHIND`-but-clean **and** the base branch's ruleset or classic branch protection requires
+strict up-to-date status checks (`strict_required_status_checks_policy` / `required_status_checks.strict`).
+If strict checks are off, it does not update the branch solely because the base moved; that avoids
+CI cancellation storms in repos where updating the PR head restarts and cancels in-flight runs. It
+never edits code, resolves threads, or dismisses reviews. It returns a classification (`merged` /
+`will-merge-after-resync` / `blocked:<reason>`). On a `merged` / `will-merge-after-resync` result,
 record this as a repair write (`resynced`), keep the item `claimed`, and move on — a later cycle sees
 the now-`CLEAN` (or merged) PR and either lets auto-merge finish or applies the merged-PR recovery in
 step 2. Only if `gh pr update-branch` itself reports a conflict it cannot apply does the PR become a

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.1",
+  "version": "2.176.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.1",
+  "version": "2.176.3",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.1",
+  "version": "2.176.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.1",
+  "version": "2.176.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.176.1",
+  "version": "2.176.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.176.1",
+  "version": "2.176.3",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

package/plugins/src/base/skills/drive-pr-to-merge/SKILL.md

@@ -25,9 +25,10 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     resolve review comments, dismiss stale review gates — drive until merged.
   - **`report`** (diagnose & mechanically nudge only): perform just the safe,
     idempotent, non-destructive actions — ensure auto-merge is enabled and, if the
-    PR is `BEHIND` but otherwise clean, run `gh pr update-branch`. For **anything**
-    that would require editing code, resolving threads, or dismissing a review,
-    **do not act** — stop and return a structured blocker classification
+    PR is `BEHIND` but otherwise clean, run `gh pr update-branch` only when the
+    base branch requires strict up-to-date checks. For **anything** that would
+    require editing code, resolving threads, or dismissing a review, **do not
+    act** — stop and return a structured blocker classification
     (`merged` / `will-merge-after-resync` / `blocked:<conflict|checks|changes_requested|deploy>`)
     so the caller applies its own policy. This is the mode `repair-intake` and the
     build-intake skills use to diagnose-and-route without fixing in place.
@@ -60,8 +61,33 @@ apply; for any of (b)–(e) do not act — classify the blocker and return per t
 contract above.
 
 ### a. Branch behind base (`mergeStateStatus == BEHIND`)
-Once required checks are green, run `gh pr update-branch <pr>` and keep watching the
-new head while checks rerun.
+Before proactively syncing a clean `BEHIND` PR, check whether the base branch
+actually requires up-to-date branches:
+
+```bash
+owner_repo=$(gh repo view --json nameWithOwner -q .nameWithOwner)
+base=$(gh pr view <pr> --json baseRefName -q .baseRefName)
+strict=$(gh api "repos/$owner_repo/rules/branches/$base" \
+  --jq '[.[] | select(.type == "required_status_checks") | .parameters.strict_required_status_checks_policy // false] | any')
+```
+
+If that rules endpoint is unavailable, fall back to classic branch protection:
+
+```bash
+strict=$(gh api "repos/$owner_repo/branches/$base/protection/required_status_checks" \
+  --jq '.strict // false')
+```
+
+Only when `strict == true`, once required checks are green, run
+`gh pr update-branch <pr>` and keep watching the new head while checks rerun.
+If `strict == false`, do **not** update the branch solely because the base moved:
+continue the mergeability loop and let GitHub merge the existing head once the
+checks/reviews are acceptable. This avoids cancellation storms in repos whose CI
+uses `concurrency.cancel-in-progress: true`.
+
+Still sync when it is necessary to resolve a genuine merge conflict, and it is
+acceptable to perform one final sync immediately before a direct merge if the
+merge attempt proves the head must be updated.
 
 ### b. Sync/merge conflict
 If `gh pr update-branch` reports a conflict (or `mergeStateStatus == DIRTY`):

package/plugins/src/base/skills/repair-intake/SKILL.md

@@ -393,9 +393,12 @@ drive-pr-to-merge  pr=<n>  on_blocker=report
 ```
 
 In report mode it ensures auto-merge is enabled and runs `gh pr update-branch <n>` only when the
-PR is `BEHIND`-but-clean; it never edits code, resolves threads, or dismisses reviews. It returns a
-classification (`merged` / `will-merge-after-resync` / `blocked:<reason>`). On a `merged` /
-`will-merge-after-resync` result,
+PR is `BEHIND`-but-clean **and** the base branch's ruleset or classic branch protection requires
+strict up-to-date status checks (`strict_required_status_checks_policy` / `required_status_checks.strict`).
+If strict checks are off, it does not update the branch solely because the base moved; that avoids
+CI cancellation storms in repos where updating the PR head restarts and cancels in-flight runs. It
+never edits code, resolves threads, or dismisses reviews. It returns a classification (`merged` /
+`will-merge-after-resync` / `blocked:<reason>`). On a `merged` / `will-merge-after-resync` result,
 record this as a repair write (`resynced`), keep the item `claimed`, and move on — a later cycle sees
 the now-`CLEAN` (or merged) PR and either lets auto-merge finish or applies the merged-PR recovery in
 step 2. Only if `gh pr update-branch` itself reports a conflict it cannot apply does the PR become a

package/typescript/package-lisa/package.lisa.json

@@ -31,6 +31,8 @@
       "esbuild": ">=0.28.1",
       "handlebars": ">=4.7.9",
       "lodash": ">=4.18.1",
+      "multer": ">=2.2.0",
+      "undici": ">=6.27.0",
       "vite": ">=8.0.16",
       "ws": ">=8.21.0",
       "form-data": ">=4.0.6"
@@ -41,6 +43,8 @@
       "esbuild": ">=0.28.1",
       "handlebars": ">=4.7.9",
       "lodash": ">=4.18.1",
+      "multer": ">=2.2.0",
+      "undici": ">=6.27.0",
       "vite": "^8.0.16",
       "ws": ">=8.21.0",
       "form-data": ">=4.0.6"