@codyswann/lisa 4.84.6 → 4.84.8

package/plugins/lisa-devin/hooks/block-host-name-leak.mjs

@@ -287,8 +287,16 @@ export function publishableText(tokens, cwd, noun) {
       const value = valueAt(tokens, index);
       // On `gh api`, `-F` is `--field`: `key=@path` or `key=value`. Read as a
       // bare path, `body=@file` named no file and published unchecked (#4462).
-      if (noun === "api" && /^[\w.[\]-]+=/u.test(value))
-        return [fieldSource(value, cwd)];
+      if (
+        (noun === "api" || (noun === undefined && bare === "-F")) &&
+        /^[\w.[\]-]+=/u.test(value)
+      ) {
+        const field = fieldSource(value, cwd);
+        if (noun === "api") return [field];
+        // An unresolved noun may become api or issue/pr. Inspect both possible
+        // meanings of -F without evaluating the expansion or certifying routing.
+        return [field, { origin: value, text: readIfPresent(value, cwd) }];
+      }
       const file = value.replace(/^@/u, "");
       return [{ origin: file, text: readIfPresent(file, cwd) }];
     }
@@ -414,20 +422,24 @@ export async function evaluate(command, projectDir) {
     // protection, and name the unread input instead of claiming the text clean.
     if (
       context.cwd === undefined &&
-      [...context.flags].some(([flag, item]) => {
+      [
+        ...context.flags,
+        ...(context.noun === "api" || context.noun === undefined
+          ? context.fieldOccurrences
+          : []),
+      ].some(([flag, item]) => {
         const field =
-          context.noun === "api" && FIELD_FLAGS.has(flag)
+          (context.noun === "api" || context.noun === undefined) &&
+          FIELD_FLAGS.has(flag)
             ? /^([^=]+)=@(.+)$/u.exec(item.value)
             : null;
-        const file =
-          field !== null
-            ? PROSE_FIELDS.has(field[1])
-              ? field[2]
-              : undefined
-            : FILE_FLAGS.has(flag)
-              ? item.value.replace(/^@/, "")
-              : undefined;
-        return file !== undefined && !path.isAbsolute(file);
+        const files = [
+          field !== null && PROSE_FIELDS.has(field[1]) ? field[2] : undefined,
+          FILE_FLAGS.has(flag) && (context.noun !== "api" || field === null)
+            ? item.value.replace(/^@/, "")
+            : undefined,
+        ];
+        return files.some(file => file !== undefined && !path.isAbsolute(file));
       })
     ) {
       return {

package/plugins/lisa-devin/hooks/host-name-command-context.mjs

@@ -103,6 +103,7 @@ function words(command) {
  */
 function argumentsOf(input) {
   const flags = new Map(),
+    fieldOccurrences = [],
     positional = [],
     tokens = [];
   // Any expansion can add/replace routing arguments after shell word splitting.
@@ -139,23 +140,34 @@ function argumentsOf(input) {
         flag === "-R" ? "--repo" : flag === "-X" ? "--method" : flag,
         value
       );
+      // API fields are additive even though routing options use last values.
+      if (FIELD_FLAGS.has(flag)) fieldOccurrences.push([flag, value]);
       tokens.push(value.value);
     } else if (!word.value.startsWith("-")) positional.push(word);
     else if (!word.literal) certain = false;
   }
-  const noun = positional[0]?.value,
-    verb = positional[1]?.value;
+  const nounWord = positional[0],
+    verbWord = positional[1];
+  const noun = nounWord?.literal ? nounWord.value : undefined,
+    verb = verbWord?.value;
+  // Command-name expansions can supply several argv words. A following
+  // read-looking literal does not prove that the expanded command is a read.
+  const uncertainName =
+    nounWord?.literal === false ||
+    (["issue", "pr"].includes(noun) && verbWord?.literal === false);
   const method = flags.get("--method");
   const writes =
-    noun === "api"
+    uncertainName ||
+    (noun === "api"
       ? method
         ? !method.literal || METHODS.has(method.value.toUpperCase())
         : [...FIELD_FLAGS].some(flag => flags.has(flag)) ||
           Boolean(flags.get("--input")?.value)
       : ["issue", "pr"].includes(noun) &&
-        ["create", "comment", "edit"].includes(verb);
+        ["create", "comment", "edit"].includes(verb));
   return {
     flags,
+    fieldOccurrences,
     positional,
     tokens: ["gh", ...tokens],
     noun,

package/plugins/lisa-devin/hooks/parity-safety-net.sh

@@ -3475,8 +3475,10 @@ if [ -f "$rules_file" ]; then
     # here — before the remaining rules ran, and with an exit status that is
     # not a refusal. The `||` puts the pipeline in a condition context, where
     # a non-zero status is expected rather than fatal.
+    # Consume the whole input: grep -q can close an early match while printf
+    # is still writing, making pipefail report SIGPIPE instead of the match.
     rule_status=0
-    printf '%s' "$custom_command_str" | grep -Eiq -- "$rule" || rule_status=$?
+    printf '%s' "$custom_command_str" | grep -Ei -- "$rule" >/dev/null || rule_status=$?
     case "$rule_status" in
       0) block "matched a project custom safety rule (${rules_file##*/}): $rule" ;;
       1) ;; # no match

package/plugins/lisa-devin/rules/eager/00-rule-index.md

@@ -46,6 +46,7 @@ Paths are relative to this file.
 | `bdd-e2e-coverage` | the work item adds or changes a user-observable surface | [../reference/bdd-e2e-coverage.md](../reference/bdd-e2e-coverage.md) |
 | `reset-seed-coverage` | the work item adds or changes persistent state | [../reference/reset-seed-coverage.md](../reference/reset-seed-coverage.md) |
 | `claim-evidence-mapping` | citing evidence for a claim, or reviewing evidence someone cited | [../reference/claim-evidence-mapping.md](../reference/claim-evidence-mapping.md) |
+| `completion-authorization` | publishing proof or completing work items | [../reference/completion-authorization.md](../reference/completion-authorization.md) |
 | `observability-audit` | running the `lisa-monitor` audit-and-file arm | [../reference/observability-audit.md](../reference/observability-audit.md) |
 | `readiness-rubric` | judging whether an unattended fleet may run in a repository | [../reference/readiness-rubric.md](../reference/readiness-rubric.md) |
 

package/plugins/lisa-devin/rules/reference/completion-authorization.md

@@ -0,0 +1,10 @@
+# Accepted completion proof
+
+Read the single maintained contract at
+`skills/lisa-tracker-evidence/references/completion-authorization.md`, relative
+to the Lisa plugin root. The tracker-evidence skill resolves it as its own
+`references/completion-authorization.md` companion.
+
+The contract travels with skill resources on every supported agent, including
+Antigravity, whose native plugin intentionally omits the rules tree. The shared
+Node producer and completion guard enforce the same contract for every agent.

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

@@ -1353,7 +1353,8 @@ Four properties make the command safe to run unconditionally:
    above does, and for the same reason. A merged pull request is not evidence
    on its own: the writer resolves `<baseRefName>` through `.lisa.config.json`
    `deploy.branches` and applies only the role that base earned. A merge into
-   the production deploy branch is terminal and closes the item; a merge into a
+   the production deploy branch becomes eligible for terminal completion only
+   after canonical accepted-for-completion proof passes; a merge into a
    branch mapping to a lower env records that env's role and leaves the item
    open; a merge into a branch the project does not deploy at all — an
    integration/stack branch — records nothing, closes nothing, and reports the
@@ -1375,6 +1376,19 @@ 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.
 
+`work-item pending-proof` is a normal nonterminal outcome: the merge does not
+prove the configured whole delivery run, runtime behavior, typed attachments,
+CONFORMS, canonical Verify usage, exact linkage and acceptance. Keep the item
+owned/open, finish canonical Verify and `lisa-tracker-evidence`, and use its
+shipped `publish-completion-proof` producer after actual uploads/readbacks.
+Then retry canonical completion. Read the sibling skill companion
+`../lisa-tracker-evidence/references/completion-authorization.md` relative to this
+skill directory; it is the portable `completion-authorization` reference.
+Publish an immutable required pending-state journey artifact first; append the
+real native terminal readback/acceptedAt afterward. Never require the future
+close event as its own authorization. A configured bot publisher's still-running
+pinned attempt keeps completion pending until that exact attempt succeeds.
+
 **The backstop, for the ones that still slip:** `lisa-work-item.mjs sweep`
 reports every open item — in the **ready** lane as well as the **claimed** one —
 that a commit on a deploy branch DECLARES via its `Work-Item:` trailer, and

package/plugins/lisa-devin/skills/lisa-tracker-evidence/SKILL.md

@@ -14,6 +14,11 @@ Apply `lisa-tracker-sync` — **Agent attribution** when composing evidence comm
 
 ## Workflow
 
+The portable accepted-completion contract is this skill's own
+`references/completion-authorization.md` companion. Read that file when preparing
+or publishing completion proof. It ships with the skill even on runtimes that
+omit the plugin rules tree; do not assume a runtime-specific rules directory.
+
 1. Resolve tracker config (same logic as `lisa-tracker-write`).
 2. Missing / empty → stop and report `"No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."`
 3. Before dispatching, update the generated evidence artifact through `lisa-usage-accounting` so the comment body / PR evidence section carries a direct `lisa-verify` usage entry in the canonical `## Lisa Usage` section. If the originating work item's parentage or child refs are already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise still write the direct entry, and if trustworthy runtime usage is unavailable, write `source: unavailable` with nullable token/cost fields instead of skipping the row.
@@ -22,7 +27,8 @@ Apply `lisa-tracker-sync` — **Agent attribution** when composing evidence comm
    - `github` → invoke `lisa-github-evidence` with `$ARGUMENTS` verbatim. Arg shape: `<ISSUE_REF> <EVIDENCE_DIR> <PR_NUMBER>` where `ISSUE_REF` is `org/repo#<number>` or a GitHub issue URL.
    - `linear` → invoke `lisa-linear-evidence` with `$ARGUMENTS` verbatim. Arg shape: `<IDENTIFIER> <EVIDENCE_DIR>` where `IDENTIFIER` is a Linear Issue identifier (e.g., `ENG-123`).
    - Anything else → stop and report `"Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."`
-5. Pass through the vendor skill's output.
+5. For supported GitHub/Linear production completion, after actual uploads and exact native readbacks, prepare the accepted-for-completion input from the observed source/delivery, schema2 verdicts, actual typed attachment pointers, complete requirement conjunction map, structured CONFORMS report, canonical Verify usage, linkage and explicit acceptance. Apply the shipped `completion-authorization` reference; the executable validates the contract in every installed host. Run `node scripts/lisa-work-item.mjs publish-completion-proof --ref <exact-work-item> --record <evidence-dir>/completion-record.json`. It uploads immutable hash-named acceptance bytes to the implementation repository's `pr-assets`, reads them back and publishes the exact-item native locator. Never construct a locator manually or treat a narrative evidence comment as acceptance. Jira completion remains unsupported.
+6. Pass through both the vendor output and actual producer category. `published/pending-producer` means the pinned configured automation attempt must finish successfully before completion; do not rewrite the asset after the job or invent a successful future outcome. A User publisher does not require a producer workflow run. Only after accepted publication may the canonical lifecycle owner retry `complete`; pending proof preserves ownership and state and names the Verify/evidence action. Capture actual terminal readback/usage acceptedAt afterward, not as a circular publication prerequisite. A required pending-state journey artifact is immutable Phase-A proof captured before completion; the later actual terminal readback is a separate Phase-B supplement.
 
 ## Rules
 

package/plugins/lisa-devin/skills/lisa-tracker-evidence/references/completion-authorization.md

@@ -0,0 +1,193 @@
+# Accepted completion proof
+
+Merging a pull request makes work available for delivery. It does not authorize
+closing the work item. The canonical `scripts/lisa-work-item.mjs complete` and
+GitHub applying sweep require the same accepted-for-completion record before
+adding a terminal label, removing competing lifecycle labels, closing an issue,
+or changing a Linear item to its terminal state. Jira completion remains
+unsupported. Intermediate deployment roles retain their existing behavior.
+
+An absent record or pending delivery leaves the item open with its current owner
+and labels. The command names the pending obligation and asks for canonical
+Verify/evidence. An invalid record, unreadable provider, or failed write is a
+different outcome. A workflow must not file a delivery-failure issue merely
+because verification has not finished.
+
+## Publish after verification
+
+The canonical tracker-evidence skill performs these steps after real evidence
+uploads and exact readbacks:
+
+1. Capture the delivered behavior, required hosted checks, actual configured
+   delivery, and every local typed evidence marker. Keep historical RED captures
+   and expected refusal exits as captures; current required claims and criteria
+   must independently pass.
+2. Write canonical Verify usage, including explicit unavailable metrics when
+   needed. The future native completion time (`acceptedAt`) remains null.
+3. Prepare the record input below from actual native source and uploaded asset
+   identities. Attach a structured CONFORMS report for the complete requirement
+   conjunctions and current full specification.
+4. Execute the shipped producer:
+
+   ```sh
+   node scripts/lisa-work-item.mjs publish-completion-proof \
+     --ref acme/code#42 --record evidence/completion-record.json
+   ```
+
+   Linear uses its configured identifier and implementation GitHub repository.
+   Both providers use the implementation repository's existing `pr-assets`
+   release. The producer reads current native requirements/configuration,
+   validates the actual attachment bytes and source/delivery, uploads a uniquely
+   hash-named JSON asset without replacement, reads it back, then posts and reads
+   back an exact native-item locator. The locator alone proves nothing.
+5. Run canonical completion. Record the real native terminal readback and usage
+   acceptance afterward. A pending result is retryable after its named proof
+   obligation is satisfied; it does not authorize a manual close.
+
+For a journey requiring a pending-state screenshot or state dump, capture and
+upload that nonempty Phase-A artifact before publication/completion. Keep it
+immutable. Append the later real terminal readback as a separate Phase-B
+postcondition. Historical pending text in the earlier artifact is valid.
+
+When a final requirement includes the terminal event itself, retain its claim
+as an explicit pending postcondition in the complete phase ledger. The
+accepted record's conjunctions and CONFORMS report cover only actual transition
+inputs; they do not claim the future event passed. Keep the full final-spec
+report PARTIAL until native Phase B, then attach the actual readback and update
+the final required claim. Never fabricate a future closed state to obtain
+pre-transition CONFORMS.
+
+## Record contract
+
+Schema version 1 has kind `lisa-completion-authorization`. The producer derives
+the stable record ID, monotonic revision, predecessor digest, capture timestamp,
+native item ID/provider/scope, repository ID/name, publisher ID, production
+environment/branch and current `spec_sha256`. Input supplies:
+
+- `state`: `accepted-for-completion`, `pending`, or `revoked`. A newer trusted
+  pending, revoked or malformed revision never falls back to an older accepted
+  record. Untrusted comments cannot select or revoke a record.
+- `source`: primary `pull_request`, `pr_head`, actual `tested_head`, `merge_sha`,
+  `declaring_commits`, `production_snapshot_sha`, and `delivered_sha`. These are
+  distinct identities with native reconciliation, not a requirement that all
+  SHAs be equal. The primary PR and source commits must declare this exact work
+  item. A supplied `--pr-url` must identify that primary PR. Timeline mentions
+  and a different work item's accepted record cannot substitute.
+- `evidence`: rows with `evidence_id`, canonical `kind`, native `asset_id`, actual
+  `bytes`, `sha256`, `captured_at`, and `artifact_head_sha`.
+- `manifest`: one `{name, kind, evidence_id}` row for every local marker.
+  `EVIDENCE-REF` is non-claiming and cannot satisfy a local marker.
+- `verdicts`: actual native JSON asset pointers (`asset_id`, `bytes`, `sha256`)
+  with role `remote` or `quality`. Each is schema2 PASS with passing criteria,
+  positively established required claims, attached reaching evidence and
+  `not_established_reviewed: true`. Each claim's evidence must also occur in its
+  own verdict's evidence list with the same execution head and digest.
+- `requirements`: unique `{requirement_id, operator: "all", claim_ids}` rows.
+  Every required conjunct must be a validated required established claim.
+  Canonical `required_evidence_kinds` remain alternatives; an explicit
+  `evidence_operator: "all"` requires each listed kind.
+- `obligations`: exactly `remote`, `conformance`, `typed_manifest`, `delivery`,
+  `usage`, `linkage`, and `acceptance`. Each has an explicit boolean `required`
+  and applicable status. Required values are `pass`, except conformance uses
+  `CONFORMS` and acceptance uses `accepted-for-completion`.
+
+The conformance obligation includes `requirement_ids` and a native `report`
+asset pointer. Its JSON is `{verdict: "CONFORMS", work_item, spec_sha256,
+requirements, scenario_names}`. Requirement rows include status `pass` and must
+match the record's complete conjunction map; every primary acceptance scenario
+must be covered. The usage obligation lists the actual canonical `entry_ids`.
+The remote obligation lists empirical required `claim_ids` against the delivered
+environment/source, beyond code-unit checks.
+
+Runtime leaves require remote and delivery proof. Explicit doc-only,
+config-only and type-only no-runtime declarations permit their corresponding
+N/A reasons; no-local-markers permits only the empty manifest exemption.
+Missing or duplicate environment declarations cannot grant an exemption.
+Childless Story/Spike work remains a leaf. Container rollup is a separate path;
+older blanket container wording in evidence guidance does not grant a new
+terminal-writer bypass.
+
+Attachments must be nonempty bounded actual native assets in this repository's
+`pr-assets` release, with matching byte counts and SHA256. Canonical kinds are
+screenshot, recording, http-transcript, cli-output, log-snippet, db-query-output,
+perf-trace, test-run-log, deploy-log and state-dump. The reader validates actual
+captured structure/header, not an extension. HTTP HEAD/204 and empty query rows
+can be legitimate observations. Structure checks do not claim to evaluate the
+visual truth of an image or the business meaning of every captured line.
+
+Native JSON reads use a separate 16 MiB ceiling per response, including the
+complete slurped output of a paginated listing. The immutable proof record
+remains limited to 2 MiB. Page and row limits are additional bounds: a listing
+with at most 100 pages or 10,000 comments can still exceed its byte ceiling and
+must fail closed without a lifecycle write. Visible local evidence markers
+claim attachments; fenced or indented examples and HTML comments do not.
+
+An ordinary pending result from `complete` or the applying sweep exits zero
+because it preserves the nonterminal state. A refused `publish-completion-proof`
+exits nonzero when no locator was published. A successful bot publication with
+category `published/pending-producer` remains a successful publication; only
+completion waits for its pinned producer attempt.
+
+## Delivery and publisher configuration
+
+Configure the actual production delivery mechanism under
+`verification.completion.delivery.<environment>`. For GitHub Actions, use
+`mechanism: "github-actions"`, exact `workflow_path`, and permitted native
+`events`. Records pin each actual run's `run_id`, `workflow_id`, `workflow_path`,
+`event`, `attempt` and `head_sha`. The whole configured post-merge run must
+finish successfully and reconcile with delivered source. Pre-merge CI and an
+auxiliary green workflow cannot replace it. Artifact or external-deployment
+projects declare their applicable mechanism and empirical attached
+`evidence_refs`; npm, browser, cloud and device checks are not universal.
+
+User publishers require fresh native repository write/maintain/admin permission
+and matching stable native asset-uploader identity. Association labels, display
+names and issue edit access are insufficient. `automationPublishers` defaults
+to an empty array. A configured automation row requires stable Bot `user_id`,
+`type: "Bot"`, `repository_id`, exact `workflow_id`, `workflow_path`, allowed
+`events`, and branch `ref`. Its record producer additionally pins
+`workflow_run_id`, `workflow_attempt`, and `workflow_head`.
+
+The native asset belongs to the repository and uploader; exact native run
+repository, workflow, ref, head, attempt and upload interval corroborate that
+configured automation policy. This is not a cryptographic claim about which
+step uploaded the asset. A bot can publish during its pinned attempt and gets
+`published/pending-producer`. Completion remains pending until that exact native
+attempt succeeds, without rewriting the asset. A failed/cancelled/timed-out
+attempt cannot be upgraded by a later successful rerun. User records do not
+gain an unnecessary producer-run requirement.
+
+## Freshness and readbacks
+
+The full primary specification is hashed except positively recognized canonical
+accounting lines/tokens and closed-schema machine metadata. Unknown visible
+prose and table rows inside the usage section remain hashed, including text
+before its rollup. Fenced examples cannot declare runtime scope or machine
+blocks. Duplicate declarations are refused.
+
+Precisely delimited `lisa:completion-authorization` blocks exclude only the
+JSON locator's six exact fields: `schema_version`, `record_id`, `revision`,
+`repository`, `asset_id`, `sha256`. `lisa:completion-postcondition` blocks exclude
+only JSON with `schema_version: 1`, `provider`, canonical `ref`, real `native_id`,
+`record_sha256`, UTC `completed_at`, and native terminal `state` (`CLOSED` for
+GitHub, `completed` for Linear). Unknown keys, prose, or visible requirements
+inside either block remain part of the specification. These bookkeeping fields
+must use the exact canonical compact or two-space JSON serialization; duplicate
+keys and other raw forms remain hashed. These bookkeeping fields
+never authorize completion or replace the actual native readback; publish them
+only after observing the real terminal event. Do not add outside prose or
+spacing as if it were part of the machine metadata block.
+
+The reader checks the accepted production snapshot against a fresh native
+branch tip and fully paginates native compare commits. Newer source declaring
+this same item anywhere from delivered source through the accepted snapshot to
+the current tip requires fresh proof; unrelated newer work does not invalidate
+it. It re-reads the trusted record, native scope, canonical usage, backlink and
+lifecycle state immediately before mutation, preserving freshly observed owner
+and unrelated labels. This is bounded authoritative rereading and post-write
+verification, not a distributed atomic transaction.
+
+The shipped Node usage parser is the same implementation used by the TypeScript
+facade and works in a host without application `dist`. Local advisory Stop-hook
+files cannot authorize production writes. Protocol version 1.2.0 adds these
+verdict semantics; normal generator checks maintain its dependent versions.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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.84.6",
+  "version": "4.84.8",
   "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"