@codyswann/lisa 3.42.0 → 3.43.1

package/expo/create-only/.github/workflows/playwright-e2e.yml

@@ -31,6 +31,11 @@ name: 🎭 Playwright Web E2E
 #     }
 #   }
 #
+# READ THE SHARDING NOTE BELOW BEFORE DECLARING IT AT THIS MOMENT. Declaring the
+# gate `required` here is NOT free: it moves the suite off the shard matrix onto
+# a single runner. That is a real trade, and for a suite of any size it is
+# usually the wrong one — see "SHARDING" below for what actually happens.
+#
 # The gate's task is `test:e2e`, so the project needs that script in
 # package.json — Lisa resolves the PROPERTY ("browser journeys pass end to
 # end"), never the tool.
@@ -91,6 +96,14 @@ on:
 # visible way to stop requiring a check — as opposed to a job that silently
 # stops running. Nothing inside this file can enforce it; the only defence is
 # that whoever seeds it knows.
+#
+# **`pull-request: off` ALONE is enough to stop the duplicate run**, and it is
+# what most projects should write. The `continuous:*` half above is shown for
+# completeness, not as a recommendation: declaring the gate at the nightly
+# moment costs you the shard matrix. If this project's suite takes long enough
+# to shard, declare `off` at `pull-request` and leave the nightly moment
+# UNDECLARED — an undeclared gate keeps Lisa's built-in sharded run, which is
+# the behaviour you already have.
 
 permissions:
   contents: read
@@ -143,10 +156,20 @@ jobs:
       # out; that is a visible decision, which a silent skip is not.
       prepare_environment: 'development'
       prepare_verbs: 'reset,reseed'
-      # Applies only while `e2e-browser` is undeclared: Lisa cannot append
-      # `--shard` to a command whose shape it does not know, and the `--`
-      # passthrough differs between npm, yarn and bun. A declared gate runs on
-      # one runner; shard inside the project's own `test:e2e` script instead.
+      # Applies only while `e2e-browser` is undeclared at THIS workflow's
+      # moment. Lisa cannot append `--shard` to a command whose shape it does
+      # not know, and the `--` passthrough differs between npm, yarn and bun.
+      #
+      # The consequence is bigger than it sounds and it is silent: once the
+      # gate resolves to a task, EVERY shard concludes "Shard idle — the
+      # e2e-browser gate owns this suite" and the aggregate job runs the whole
+      # suite by itself. A four-shard nightly becomes a one-runner nightly with
+      # no error and no warning, while still holding whatever concurrency group
+      # the other suites join. Measured on a consumer whose ~25-minute sharded
+      # suite would have become a single serial run.
+      #
+      # So: shard inside the project's own `test:e2e` script if you declare the
+      # gate here, or leave this moment undeclared and keep the matrix.
       playwright_shards: 2
       # Leave false unless the cache key has been checked against this project's
       # layout. Lisa's key is a fingerprint of build inputs, and a key that

package/package.json

@@ -132,7 +132,7 @@
     "ws": ">=8.21.0"
   },
   "name": "@codyswann/lisa",
-  "version": "3.42.0",
+  "version": "3.43.1",
   "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": "3.42.0",
+  "version": "3.43.1",
   "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": "3.42.0",
+  "version": "3.43.1",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -470,6 +470,56 @@ matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
 Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
 merge, confirming that sync ran satisfies this step.
 
+### d. Complete the work item
+
+Run this once the PR reports `MERGED` and the ancestry check has passed:
+
+```
+node scripts/lisa-work-item.mjs complete --ref <work-item>
+```
+
+resolving the script the usual three ways (installed package, host `scripts/`,
+this repo's own tree).
+
+**This step exists because the previous arrangement did not work, measured.**
+The instruction to move a work item to its terminal role lived in
+`lisa-git-submit-pr`, in a section reached *after* that skill delegates the
+entire merge loop to this one. So the skill that observes the merge was never
+told to close anything, and the skill that was told had already handed off. The
+result: **27 of 27** open items carrying the claimed role in this repository had
+a merged pull request — the claimed lane reported 27 things in flight when the
+real number was one.
+
+Three properties make the command safe to run unconditionally:
+
+1. **The terminal role is RESOLVED, never assumed.** `lifecycleContract` reads
+   `github.labels.build.done` (or the Jira/Linear equivalent), which is
+   environment-aware — a repository whose target is `dev` has a different
+   terminal role than one merging to production, and a hardcoded label would
+   apply the wrong one while looking correct in the repository it was written
+   in.
+2. **It refuses without evidence.** Completion requires a merged pull request in
+   the same repository. A command that closes whatever it is pointed at is a way
+   to make unfinished work disappear, and the closure is indistinguishable from
+   a real one afterwards. Cross-repository references do not count: a downstream
+   consumer's PR mentioning an upstream issue is not evidence the upstream issue
+   shipped.
+3. **It is idempotent**, so re-running after a retry converges rather than
+   accumulating.
+
+It also removes the claimed role rather than only adding the terminal one.
+Leaving both produces exactly the drift this step exists to end — an item that
+is closed *and* still reports as in progress.
+
+If the command refuses, do not close by hand. A refusal means the evidence is
+not there, and a lifecycle step performed by hand is one nothing can verify
+happened.
+
+**The backstop, for the ones that still slip:** `lisa-work-item.mjs sweep`
+reports every claimed item that already has a merged pull request, and
+`--apply` completes them. Reporting is the default deliberately — a sweep that
+closes things as a side effect of being run is not one anyone runs twice.
+
 ## 4. Terminal states
 
 Loop until one of:

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

@@ -470,6 +470,56 @@ matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
 Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
 merge, confirming that sync ran satisfies this step.
 
+### d. Complete the work item
+
+Run this once the PR reports `MERGED` and the ancestry check has passed:
+
+```
+node scripts/lisa-work-item.mjs complete --ref <work-item>
+```
+
+resolving the script the usual three ways (installed package, host `scripts/`,
+this repo's own tree).
+
+**This step exists because the previous arrangement did not work, measured.**
+The instruction to move a work item to its terminal role lived in
+`lisa-git-submit-pr`, in a section reached *after* that skill delegates the
+entire merge loop to this one. So the skill that observes the merge was never
+told to close anything, and the skill that was told had already handed off. The
+result: **27 of 27** open items carrying the claimed role in this repository had
+a merged pull request — the claimed lane reported 27 things in flight when the
+real number was one.
+
+Three properties make the command safe to run unconditionally:
+
+1. **The terminal role is RESOLVED, never assumed.** `lifecycleContract` reads
+   `github.labels.build.done` (or the Jira/Linear equivalent), which is
+   environment-aware — a repository whose target is `dev` has a different
+   terminal role than one merging to production, and a hardcoded label would
+   apply the wrong one while looking correct in the repository it was written
+   in.
+2. **It refuses without evidence.** Completion requires a merged pull request in
+   the same repository. A command that closes whatever it is pointed at is a way
+   to make unfinished work disappear, and the closure is indistinguishable from
+   a real one afterwards. Cross-repository references do not count: a downstream
+   consumer's PR mentioning an upstream issue is not evidence the upstream issue
+   shipped.
+3. **It is idempotent**, so re-running after a retry converges rather than
+   accumulating.
+
+It also removes the claimed role rather than only adding the terminal one.
+Leaving both produces exactly the drift this step exists to end — an item that
+is closed *and* still reports as in progress.
+
+If the command refuses, do not close by hand. A refusal means the evidence is
+not there, and a lifecycle step performed by hand is one nothing can verify
+happened.
+
+**The backstop, for the ones that still slip:** `lisa-work-item.mjs sweep`
+reports every claimed item that already has a merged pull request, and
+`--apply` completes them. Reporting is the default deliberately — a sweep that
+closes things as a side effect of being run is not one anyone runs twice.
+
 ## 4. Terminal states
 
 Loop until one of:

package/plugins/lisa-agy/plugin.json

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

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

@@ -470,6 +470,56 @@ matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
 Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
 merge, confirming that sync ran satisfies this step.
 
+### d. Complete the work item
+
+Run this once the PR reports `MERGED` and the ancestry check has passed:
+
+```
+node scripts/lisa-work-item.mjs complete --ref <work-item>
+```
+
+resolving the script the usual three ways (installed package, host `scripts/`,
+this repo's own tree).
+
+**This step exists because the previous arrangement did not work, measured.**
+The instruction to move a work item to its terminal role lived in
+`lisa-git-submit-pr`, in a section reached *after* that skill delegates the
+entire merge loop to this one. So the skill that observes the merge was never
+told to close anything, and the skill that was told had already handed off. The
+result: **27 of 27** open items carrying the claimed role in this repository had
+a merged pull request — the claimed lane reported 27 things in flight when the
+real number was one.
+
+Three properties make the command safe to run unconditionally:
+
+1. **The terminal role is RESOLVED, never assumed.** `lifecycleContract` reads
+   `github.labels.build.done` (or the Jira/Linear equivalent), which is
+   environment-aware — a repository whose target is `dev` has a different
+   terminal role than one merging to production, and a hardcoded label would
+   apply the wrong one while looking correct in the repository it was written
+   in.
+2. **It refuses without evidence.** Completion requires a merged pull request in
+   the same repository. A command that closes whatever it is pointed at is a way
+   to make unfinished work disappear, and the closure is indistinguishable from
+   a real one afterwards. Cross-repository references do not count: a downstream
+   consumer's PR mentioning an upstream issue is not evidence the upstream issue
+   shipped.
+3. **It is idempotent**, so re-running after a retry converges rather than
+   accumulating.
+
+It also removes the claimed role rather than only adding the terminal one.
+Leaving both produces exactly the drift this step exists to end — an item that
+is closed *and* still reports as in progress.
+
+If the command refuses, do not close by hand. A refusal means the evidence is
+not there, and a lifecycle step performed by hand is one nothing can verify
+happened.
+
+**The backstop, for the ones that still slip:** `lisa-work-item.mjs sweep`
+reports every claimed item that already has a merged pull request, and
+`--apply` completes them. Reporting is the default deliberately — a sweep that
+closes things as a side effect of being run is not one anyone runs twice.
+
 ## 4. Terminal states
 
 Loop until one of:

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

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

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

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

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

@@ -470,6 +470,56 @@ matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
 Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
 merge, confirming that sync ran satisfies this step.
 
+### d. Complete the work item
+
+Run this once the PR reports `MERGED` and the ancestry check has passed:
+
+```
+node scripts/lisa-work-item.mjs complete --ref <work-item>
+```
+
+resolving the script the usual three ways (installed package, host `scripts/`,
+this repo's own tree).
+
+**This step exists because the previous arrangement did not work, measured.**
+The instruction to move a work item to its terminal role lived in
+`lisa-git-submit-pr`, in a section reached *after* that skill delegates the
+entire merge loop to this one. So the skill that observes the merge was never
+told to close anything, and the skill that was told had already handed off. The
+result: **27 of 27** open items carrying the claimed role in this repository had
+a merged pull request — the claimed lane reported 27 things in flight when the
+real number was one.
+
+Three properties make the command safe to run unconditionally:
+
+1. **The terminal role is RESOLVED, never assumed.** `lifecycleContract` reads
+   `github.labels.build.done` (or the Jira/Linear equivalent), which is
+   environment-aware — a repository whose target is `dev` has a different
+   terminal role than one merging to production, and a hardcoded label would
+   apply the wrong one while looking correct in the repository it was written
+   in.
+2. **It refuses without evidence.** Completion requires a merged pull request in
+   the same repository. A command that closes whatever it is pointed at is a way
+   to make unfinished work disappear, and the closure is indistinguishable from
+   a real one afterwards. Cross-repository references do not count: a downstream
+   consumer's PR mentioning an upstream issue is not evidence the upstream issue
+   shipped.
+3. **It is idempotent**, so re-running after a retry converges rather than
+   accumulating.
+
+It also removes the claimed role rather than only adding the terminal one.
+Leaving both produces exactly the drift this step exists to end — an item that
+is closed *and* still reports as in progress.
+
+If the command refuses, do not close by hand. A refusal means the evidence is
+not there, and a lifecycle step performed by hand is one nothing can verify
+happened.
+
+**The backstop, for the ones that still slip:** `lisa-work-item.mjs sweep`
+reports every claimed item that already has a merged pull request, and
+`--apply` completes them. Reporting is the default deliberately — a sweep that
+closes things as a side effect of being run is not one anyone runs twice.
+
 ## 4. Terminal states
 
 Loop until one of:

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

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

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

@@ -470,6 +470,56 @@ matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
 Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
 merge, confirming that sync ran satisfies this step.
 
+### d. Complete the work item
+
+Run this once the PR reports `MERGED` and the ancestry check has passed:
+
+```
+node scripts/lisa-work-item.mjs complete --ref <work-item>
+```
+
+resolving the script the usual three ways (installed package, host `scripts/`,
+this repo's own tree).
+
+**This step exists because the previous arrangement did not work, measured.**
+The instruction to move a work item to its terminal role lived in
+`lisa-git-submit-pr`, in a section reached *after* that skill delegates the
+entire merge loop to this one. So the skill that observes the merge was never
+told to close anything, and the skill that was told had already handed off. The
+result: **27 of 27** open items carrying the claimed role in this repository had
+a merged pull request — the claimed lane reported 27 things in flight when the
+real number was one.
+
+Three properties make the command safe to run unconditionally:
+
+1. **The terminal role is RESOLVED, never assumed.** `lifecycleContract` reads
+   `github.labels.build.done` (or the Jira/Linear equivalent), which is
+   environment-aware — a repository whose target is `dev` has a different
+   terminal role than one merging to production, and a hardcoded label would
+   apply the wrong one while looking correct in the repository it was written
+   in.
+2. **It refuses without evidence.** Completion requires a merged pull request in
+   the same repository. A command that closes whatever it is pointed at is a way
+   to make unfinished work disappear, and the closure is indistinguishable from
+   a real one afterwards. Cross-repository references do not count: a downstream
+   consumer's PR mentioning an upstream issue is not evidence the upstream issue
+   shipped.
+3. **It is idempotent**, so re-running after a retry converges rather than
+   accumulating.
+
+It also removes the claimed role rather than only adding the terminal one.
+Leaving both produces exactly the drift this step exists to end — an item that
+is closed *and* still reports as in progress.
+
+If the command refuses, do not close by hand. A refusal means the evidence is
+not there, and a lifecycle step performed by hand is one nothing can verify
+happened.
+
+**The backstop, for the ones that still slip:** `lisa-work-item.mjs sweep`
+reports every claimed item that already has a merged pull request, and
+`--apply` completes them. Reporting is the default deliberately — a sweep that
+closes things as a side effect of being run is not one anyone runs twice.
+
 ## 4. Terminal states
 
 Loop until one of:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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