@codyswann/lisa 4.4.15 → 4.4.17

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

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

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

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

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

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

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

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

package/plugins/lisa-rails/.codex-plugin/skills/improve-code-complexity/SKILL.md

@@ -17,8 +17,11 @@ Reduces the CyclomaticComplexity threshold by 2 and fixes all violations.
    bundle exec rubocop --only Metrics/CyclomaticComplexity,Metrics/PerceivedComplexity --format json 2>&1
    ```
    ```bash
-   bundle exec flog --all --group app/ 2>&1 | head -50
+   status=0
+   bundle exec flog --all --group app/ >flog.log 2>&1 || status=$?
+   head -n 50 flog.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `head` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 4. **Note for each violation**:
    - File path and line number
    - Method name

package/plugins/lisa-rails/.codex-plugin/skills/improve-test-coverage/SKILL.md

@@ -16,8 +16,11 @@ If no argument provided, prompt the user for a target.
 1. **Find coverage config** (`.simplecov` or `spec/spec_helper.rb`)
 2. **Run test suite with coverage** to get current state:
    ```bash
-   bundle exec rspec 2>&1 | tail -50
+   status=0
+   bundle exec rspec >rspec.log 2>&1 || status=$?
+   tail -n 50 rspec.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `tail` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 3. **Check SimpleCov output** in `coverage/index.html` or console output
 4. **Identify the 20 files with lowest coverage**, noting:
    - File path

package/plugins/lisa-rails/.codex-plugin/skills/ops-verify-telemetry/SKILL.md

@@ -58,7 +58,36 @@ grep -i "otel\|opentelemetry\|trace_id" log/development.log | tail -10
 ### Check Collector Sidecar (if using Docker Compose)
 
 ```bash
-docker compose logs otel-collector 2>/dev/null | tail -20 || echo "No otel-collector service in Docker Compose"
+# Capture the status BEFORE the pipe. A pipeline reports its LAST stage's exit
+# code, so `docker compose logs ... | tail -20 || echo "No otel-collector"`
+# never prints the fallback: `tail` succeeds even when there is no such
+# service, and the absent sidecar reads as a silent pass.
+#
+# `|| status=$?`, not `; status=$?`: under `set -e` the `;` form exits before
+# the assignment, so the branch that reports the failure never runs.
+#
+# Ask whether the service EXISTS separately from whether its logs could be
+# read. `docker compose logs` also exits non-zero for a stopped daemon, a
+# permission failure, and an unparseable compose file; answering all of those
+# with "No otel-collector service" turns a broken telemetry stack into a
+# reassuring sentence — the same silent-measurement failure one level up.
+services_status=0
+services=$(docker compose config --services 2>&1) || services_status=$?
+if [ "$services_status" -ne 0 ]; then
+  echo "FAILED ($services_status) — docker compose config could not be read:"
+  printf '%s\n' "$services"
+elif ! printf '%s\n' "$services" | grep -qx otel-collector; then
+  echo "No otel-collector service in Docker Compose"
+else
+  logs_status=0
+  docker compose logs otel-collector >otel.log 2>&1 || logs_status=$?
+  if [ "$logs_status" -eq 0 ]; then
+    tail -n 20 otel.log
+  else
+    echo "FAILED ($logs_status) — otel-collector is configured but its logs could not be read:"
+    cat otel.log
+  fi
+fi
 ```
 
 ## Remote Verification (AWS X-Ray)

package/plugins/lisa-rails/skills/improve-code-complexity/SKILL.md

@@ -17,8 +17,11 @@ Reduces the CyclomaticComplexity threshold by 2 and fixes all violations.
    bundle exec rubocop --only Metrics/CyclomaticComplexity,Metrics/PerceivedComplexity --format json 2>&1
    ```
    ```bash
-   bundle exec flog --all --group app/ 2>&1 | head -50
+   status=0
+   bundle exec flog --all --group app/ >flog.log 2>&1 || status=$?
+   head -n 50 flog.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `head` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 4. **Note for each violation**:
    - File path and line number
    - Method name

package/plugins/lisa-rails/skills/improve-test-coverage/SKILL.md

@@ -16,8 +16,11 @@ If no argument provided, prompt the user for a target.
 1. **Find coverage config** (`.simplecov` or `spec/spec_helper.rb`)
 2. **Run test suite with coverage** to get current state:
    ```bash
-   bundle exec rspec 2>&1 | tail -50
+   status=0
+   bundle exec rspec >rspec.log 2>&1 || status=$?
+   tail -n 50 rspec.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `tail` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 3. **Check SimpleCov output** in `coverage/index.html` or console output
 4. **Identify the 20 files with lowest coverage**, noting:
    - File path

package/plugins/lisa-rails/skills/ops-verify-telemetry/SKILL.md

@@ -58,7 +58,36 @@ grep -i "otel\|opentelemetry\|trace_id" log/development.log | tail -10
 ### Check Collector Sidecar (if using Docker Compose)
 
 ```bash
-docker compose logs otel-collector 2>/dev/null | tail -20 || echo "No otel-collector service in Docker Compose"
+# Capture the status BEFORE the pipe. A pipeline reports its LAST stage's exit
+# code, so `docker compose logs ... | tail -20 || echo "No otel-collector"`
+# never prints the fallback: `tail` succeeds even when there is no such
+# service, and the absent sidecar reads as a silent pass.
+#
+# `|| status=$?`, not `; status=$?`: under `set -e` the `;` form exits before
+# the assignment, so the branch that reports the failure never runs.
+#
+# Ask whether the service EXISTS separately from whether its logs could be
+# read. `docker compose logs` also exits non-zero for a stopped daemon, a
+# permission failure, and an unparseable compose file; answering all of those
+# with "No otel-collector service" turns a broken telemetry stack into a
+# reassuring sentence — the same silent-measurement failure one level up.
+services_status=0
+services=$(docker compose config --services 2>&1) || services_status=$?
+if [ "$services_status" -ne 0 ]; then
+  echo "FAILED ($services_status) — docker compose config could not be read:"
+  printf '%s\n' "$services"
+elif ! printf '%s\n' "$services" | grep -qx otel-collector; then
+  echo "No otel-collector service in Docker Compose"
+else
+  logs_status=0
+  docker compose logs otel-collector >otel.log 2>&1 || logs_status=$?
+  if [ "$logs_status" -eq 0 ]; then
+    tail -n 20 otel.log
+  else
+    echo "FAILED ($logs_status) — otel-collector is configured but its logs could not be read:"
+    cat otel.log
+  fi
+fi
 ```
 
 ## Remote Verification (AWS X-Ray)

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

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

package/plugins/lisa-rails-agy/skills/improve-code-complexity/SKILL.md

@@ -17,8 +17,11 @@ Reduces the CyclomaticComplexity threshold by 2 and fixes all violations.
    bundle exec rubocop --only Metrics/CyclomaticComplexity,Metrics/PerceivedComplexity --format json 2>&1
    ```
    ```bash
-   bundle exec flog --all --group app/ 2>&1 | head -50
+   status=0
+   bundle exec flog --all --group app/ >flog.log 2>&1 || status=$?
+   head -n 50 flog.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `head` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 4. **Note for each violation**:
    - File path and line number
    - Method name

package/plugins/lisa-rails-agy/skills/improve-test-coverage/SKILL.md

@@ -16,8 +16,11 @@ If no argument provided, prompt the user for a target.
 1. **Find coverage config** (`.simplecov` or `spec/spec_helper.rb`)
 2. **Run test suite with coverage** to get current state:
    ```bash
-   bundle exec rspec 2>&1 | tail -50
+   status=0
+   bundle exec rspec >rspec.log 2>&1 || status=$?
+   tail -n 50 rspec.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `tail` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 3. **Check SimpleCov output** in `coverage/index.html` or console output
 4. **Identify the 20 files with lowest coverage**, noting:
    - File path

package/plugins/lisa-rails-agy/skills/ops-verify-telemetry/SKILL.md

@@ -58,7 +58,36 @@ grep -i "otel\|opentelemetry\|trace_id" log/development.log | tail -10
 ### Check Collector Sidecar (if using Docker Compose)
 
 ```bash
-docker compose logs otel-collector 2>/dev/null | tail -20 || echo "No otel-collector service in Docker Compose"
+# Capture the status BEFORE the pipe. A pipeline reports its LAST stage's exit
+# code, so `docker compose logs ... | tail -20 || echo "No otel-collector"`
+# never prints the fallback: `tail` succeeds even when there is no such
+# service, and the absent sidecar reads as a silent pass.
+#
+# `|| status=$?`, not `; status=$?`: under `set -e` the `;` form exits before
+# the assignment, so the branch that reports the failure never runs.
+#
+# Ask whether the service EXISTS separately from whether its logs could be
+# read. `docker compose logs` also exits non-zero for a stopped daemon, a
+# permission failure, and an unparseable compose file; answering all of those
+# with "No otel-collector service" turns a broken telemetry stack into a
+# reassuring sentence — the same silent-measurement failure one level up.
+services_status=0
+services=$(docker compose config --services 2>&1) || services_status=$?
+if [ "$services_status" -ne 0 ]; then
+  echo "FAILED ($services_status) — docker compose config could not be read:"
+  printf '%s\n' "$services"
+elif ! printf '%s\n' "$services" | grep -qx otel-collector; then
+  echo "No otel-collector service in Docker Compose"
+else
+  logs_status=0
+  docker compose logs otel-collector >otel.log 2>&1 || logs_status=$?
+  if [ "$logs_status" -eq 0 ]; then
+    tail -n 20 otel.log
+  else
+    echo "FAILED ($logs_status) — otel-collector is configured but its logs could not be read:"
+    cat otel.log
+  fi
+fi
 ```
 
 ## Remote Verification (AWS X-Ray)

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

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

package/plugins/lisa-rails-copilot/skills/improve-code-complexity/SKILL.md

@@ -17,8 +17,11 @@ Reduces the CyclomaticComplexity threshold by 2 and fixes all violations.
    bundle exec rubocop --only Metrics/CyclomaticComplexity,Metrics/PerceivedComplexity --format json 2>&1
    ```
    ```bash
-   bundle exec flog --all --group app/ 2>&1 | head -50
+   status=0
+   bundle exec flog --all --group app/ >flog.log 2>&1 || status=$?
+   head -n 50 flog.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `head` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 4. **Note for each violation**:
    - File path and line number
    - Method name

package/plugins/lisa-rails-copilot/skills/improve-test-coverage/SKILL.md

@@ -16,8 +16,11 @@ If no argument provided, prompt the user for a target.
 1. **Find coverage config** (`.simplecov` or `spec/spec_helper.rb`)
 2. **Run test suite with coverage** to get current state:
    ```bash
-   bundle exec rspec 2>&1 | tail -50
+   status=0
+   bundle exec rspec >rspec.log 2>&1 || status=$?
+   tail -n 50 rspec.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `tail` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 3. **Check SimpleCov output** in `coverage/index.html` or console output
 4. **Identify the 20 files with lowest coverage**, noting:
    - File path

package/plugins/lisa-rails-copilot/skills/ops-verify-telemetry/SKILL.md

@@ -58,7 +58,36 @@ grep -i "otel\|opentelemetry\|trace_id" log/development.log | tail -10
 ### Check Collector Sidecar (if using Docker Compose)
 
 ```bash
-docker compose logs otel-collector 2>/dev/null | tail -20 || echo "No otel-collector service in Docker Compose"
+# Capture the status BEFORE the pipe. A pipeline reports its LAST stage's exit
+# code, so `docker compose logs ... | tail -20 || echo "No otel-collector"`
+# never prints the fallback: `tail` succeeds even when there is no such
+# service, and the absent sidecar reads as a silent pass.
+#
+# `|| status=$?`, not `; status=$?`: under `set -e` the `;` form exits before
+# the assignment, so the branch that reports the failure never runs.
+#
+# Ask whether the service EXISTS separately from whether its logs could be
+# read. `docker compose logs` also exits non-zero for a stopped daemon, a
+# permission failure, and an unparseable compose file; answering all of those
+# with "No otel-collector service" turns a broken telemetry stack into a
+# reassuring sentence — the same silent-measurement failure one level up.
+services_status=0
+services=$(docker compose config --services 2>&1) || services_status=$?
+if [ "$services_status" -ne 0 ]; then
+  echo "FAILED ($services_status) — docker compose config could not be read:"
+  printf '%s\n' "$services"
+elif ! printf '%s\n' "$services" | grep -qx otel-collector; then
+  echo "No otel-collector service in Docker Compose"
+else
+  logs_status=0
+  docker compose logs otel-collector >otel.log 2>&1 || logs_status=$?
+  if [ "$logs_status" -eq 0 ]; then
+    tail -n 20 otel.log
+  else
+    echo "FAILED ($logs_status) — otel-collector is configured but its logs could not be read:"
+    cat otel.log
+  fi
+fi
 ```
 
 ## Remote Verification (AWS X-Ray)

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

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

package/plugins/lisa-rails-cursor/skills/improve-code-complexity/SKILL.md

@@ -17,8 +17,11 @@ Reduces the CyclomaticComplexity threshold by 2 and fixes all violations.
    bundle exec rubocop --only Metrics/CyclomaticComplexity,Metrics/PerceivedComplexity --format json 2>&1
    ```
    ```bash
-   bundle exec flog --all --group app/ 2>&1 | head -50
+   status=0
+   bundle exec flog --all --group app/ >flog.log 2>&1 || status=$?
+   head -n 50 flog.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `head` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 4. **Note for each violation**:
    - File path and line number
    - Method name

package/plugins/lisa-rails-cursor/skills/improve-test-coverage/SKILL.md

@@ -16,8 +16,11 @@ If no argument provided, prompt the user for a target.
 1. **Find coverage config** (`.simplecov` or `spec/spec_helper.rb`)
 2. **Run test suite with coverage** to get current state:
    ```bash
-   bundle exec rspec 2>&1 | tail -50
+   status=0
+   bundle exec rspec >rspec.log 2>&1 || status=$?
+   tail -n 50 rspec.log; echo "exit=$status"
    ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `tail` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
 3. **Check SimpleCov output** in `coverage/index.html` or console output
 4. **Identify the 20 files with lowest coverage**, noting:
    - File path

package/plugins/lisa-rails-cursor/skills/ops-verify-telemetry/SKILL.md

@@ -58,7 +58,36 @@ grep -i "otel\|opentelemetry\|trace_id" log/development.log | tail -10
 ### Check Collector Sidecar (if using Docker Compose)
 
 ```bash
-docker compose logs otel-collector 2>/dev/null | tail -20 || echo "No otel-collector service in Docker Compose"
+# Capture the status BEFORE the pipe. A pipeline reports its LAST stage's exit
+# code, so `docker compose logs ... | tail -20 || echo "No otel-collector"`
+# never prints the fallback: `tail` succeeds even when there is no such
+# service, and the absent sidecar reads as a silent pass.
+#
+# `|| status=$?`, not `; status=$?`: under `set -e` the `;` form exits before
+# the assignment, so the branch that reports the failure never runs.
+#
+# Ask whether the service EXISTS separately from whether its logs could be
+# read. `docker compose logs` also exits non-zero for a stopped daemon, a
+# permission failure, and an unparseable compose file; answering all of those
+# with "No otel-collector service" turns a broken telemetry stack into a
+# reassuring sentence — the same silent-measurement failure one level up.
+services_status=0
+services=$(docker compose config --services 2>&1) || services_status=$?
+if [ "$services_status" -ne 0 ]; then
+  echo "FAILED ($services_status) — docker compose config could not be read:"
+  printf '%s\n' "$services"
+elif ! printf '%s\n' "$services" | grep -qx otel-collector; then
+  echo "No otel-collector service in Docker Compose"
+else
+  logs_status=0
+  docker compose logs otel-collector >otel.log 2>&1 || logs_status=$?
+  if [ "$logs_status" -eq 0 ]; then
+    tail -n 20 otel.log
+  else
+    echo "FAILED ($logs_status) — otel-collector is configured but its logs could not be read:"
+    cat otel.log
+  fi
+fi
 ```
 
 ## Remote Verification (AWS X-Ray)

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "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": "4.4.15",
+  "version": "4.4.17",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/hooks/threshold-ratchet-compare.mjs

@@ -9,6 +9,7 @@
 import {
   extractAllowEntries,
   extractK6Constraints,
+  extractLighthouseAssertions,
   extractNumericLeaves,
   extractRubocopThresholds,
   extractStrykerConstraints,
@@ -296,6 +297,12 @@ export function compareFile(relPath, baselineText, currentText) {
       return compareStryker(relPath, base, current);
     case "k6":
       return compareK6(relPath, base, current);
+    case "lighthouse":
+      return compareConstraints(
+        relPath,
+        extractLighthouseAssertions(base),
+        extractLighthouseAssertions(current)
+      );
     case KIND_ALLOW_LIST:
       return compareAllowList(relPath, base, current);
     default:

package/plugins/src/base/hooks/threshold-ratchet-families.mjs

@@ -77,8 +77,61 @@ export const FAMILIES = [
     match: /(^|\/)\.lisa\.config\.json$/,
     kind: "allow-list",
   },
+  {
+    id: "lighthouse",
+    match: /(^|\/)lighthouserc-config\.json$/,
+    kind: "lighthouse",
+  },
 ];
 
+/**
+ * Which way each Lighthouse assertion key ratchets.
+ *
+ * Lighthouse mixes floors and ceilings in one file, so assigning one direction
+ * to the whole family would silently approve half of the possible weakenings.
+ * Unknown keys stay unwatched until their direction is explicit here.
+ * @type {Readonly<Record<string, "min"|"max">>}
+ */
+export const LIGHTHOUSE_ASSERTION_DIRECTIONS = {
+  minScore: "min",
+  maxNumericValue: "max",
+  maxLength: "max",
+};
+
+/**
+ * Extract numeric Lighthouse assertions with a direction chosen per key.
+ *
+ * A malformed array is deliberately ignored instead of being walked as an
+ * object whose numeric indices look like audit names.
+ * @param {unknown} conf Parsed lighthouserc-config.json
+ * @returns {Map<string, { value: number, direction: "min"|"max" }>} Dotted
+ *   `assertion.key` path to numeric constraint
+ */
+export function extractLighthouseAssertions(conf) {
+  const out = new Map();
+  const assertions =
+    conf && typeof conf === "object" && !Array.isArray(conf)
+      ? /** @type {Record<string, unknown>} */ (conf).assertions
+      : undefined;
+  if (
+    !assertions ||
+    typeof assertions !== "object" ||
+    Array.isArray(assertions)
+  ) {
+    return out;
+  }
+  for (const [audit, spec] of Object.entries(assertions)) {
+    if (!spec || typeof spec !== "object" || Array.isArray(spec)) continue;
+    for (const [key, value] of Object.entries(spec)) {
+      const direction = LIGHTHOUSE_ASSERTION_DIRECTIONS[key];
+      if (direction && typeof value === "number" && Number.isFinite(value)) {
+        out.set(`${audit}.${key}`, { value, direction });
+      }
+    }
+  }
+  return out;
+}
+
 /**
  * Find the family a repo-relative path belongs to.
  * @param {string} relPath Repo-relative path (forward slashes)

package/plugins/src/base/rules/eager/falsifiable-checks.md

@@ -6,7 +6,7 @@ A passing test, a clean lint run, a zero-hit sweep, a green ratchet: each is evi
 
 This is the instrument-validity counterpart to the `verification` rule (which proves the *software* behaves) and `empirical-inquiry` (which proves a *fact*). All three reject "it looks correct." This one rejects "the check said so."
 
-## The four ways a check silently measures nothing
+## The five ways a check silently measures nothing
 
 Each has been observed in real runs; each reported success while asserting nothing:
 
@@ -14,9 +14,24 @@ Each has been observed in real runs; each reported success while asserting nothi
 2. **Fixture-validated assertion** — the assertion reads the test's own fixture rather than the artifact under test. Common when the production path consumes a *raw* input the fixture supplies directly.
 3. **Stale-artifact pass** — the revert-to-verify step silently failed (generator errored, cache served old output, build skipped), so the check re-read unchanged input and "passed".
 4. **Wrong-baseline sweep** — the detector ran against already-fixed state, so its zero is uninformative. Validate detectors against a ref where the defect still exists.
+5. **Pager-shadowed status** — the check ran and FAILED, but its result was read through a pipe. A shell pipeline's exit status is its LAST stage's, so `gate | tail -4; echo $?` reports `tail`'s success. Shortening output is exactly what one does while checking whether a gate passed, and the failure line is exactly what the shortening drops.
 
 ## Mandatory
 
+- **Read the command's own status, never a pipeline's.** When the answer decides whether you are blocked, redirect first and read the status before shortening anything — one spelling, portable to every shell including POSIX `sh`:
+
+  ```sh
+  status=0
+  gate >gate.log 2>&1 || status=$?    # `||`, not `;` — see below
+  tail -n 20 gate.log                 # shorten for reading, not for deciding
+  [ "$status" -eq 0 ] || echo "FAILED ($status) — full output in gate.log"
+  ```
+
+  `|| status=$?` rather than `; status=$?`, because the `;` form is itself a silent-measurement bug under `set -e`: errexit kills the shell on the failing command and the assignment never runs, so the branch that reports the failure is unreachable in exactly the case it exists for. The left side of `||` is exempt from errexit, which is why this spelling survives both `set -e` and its absence — and why `status` is initialized, since on success nothing assigns it.
+
+  When the block's **own** status is what gets read — a hook, a CI step, a script someone runs with `&&` — end it with `exit "$status"` (or `return "$status"` in a function). Without that, the last command is the `echo` and the block exits 0 after printing `FAILED`: the same pager-shadowing one line further out.
+
+  This form is preferred over the alternatives because it is the only one that both survives `sh` and keeps the full output, which is what you need the moment the status says the gate failed. `set -o pipefail` is correct where it exists but is **not POSIX `sh`** — dash has no such option, and this repository runs hooks under `sh`. `${PIPESTATUS[0]}` is **bash-only** (zsh spells it `$pipestatus[1]`, 1-indexed) and is overwritten by the very next command, so it must be read immediately. Never report a gate as green from a status read through `| tail`, `| head`, or `| tee`.
 - **Falsify before reporting.** No clean result is reportable until the check has been shown to fail on a deliberate break. **"Mentally reverting" does not count** — reasoning that the assertion *would* fail is precisely the step that lets a non-functional guard ship, because the author already believes it is load-bearing. Run the break.
 - **Mutation-prove the guard, then read the cardinality.** Neuter the protection **in production code**, run the **whole suite**, count the failures and **read their names**, then revert. **Zero** ⇒ the guard is inert (one pinning a single field shipped with all 50 tests green while the regression walked through). **Many, unrelated** ⇒ over-broad; its next failure will not name the cause. **Exactly one, or several all named for the same regression** ⇒ load-bearing and correctly scoped. A **zero is robust to contention** — load only ever adds failures — so only the non-zero counts need a quiet machine.
 - **Never scope the probe by filename, and never infer absent coverage from a grep.** Suites split at the line cap, so a protection's tests often sit in a sibling file: a filename-scoped probe reported cardinality 0 on a live security fix that a whole-suite run showed failing 4 tests, every one named for it.