@codyswann/lisa 3.47.0 → 3.47.2

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "3.47.0",
+  "version": "3.47.2",
   "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": "3.47.0",
+  "version": "3.47.2",
   "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": "3.47.0",
+  "version": "3.47.2",
   "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": "3.47.0",
+  "version": "3.47.2",
   "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

@@ -28,7 +28,7 @@ const KIND_ALLOW_LIST = "allow-list";
  * @typedef {object} Finding
  * @property {string} file Repo-relative path of the gate file
  * @property {string} key Dotted key path within the file
- * @property {"weakened"|"removed"|"exemption-added"|"file-deleted"|"allow-added"|"unparseable"} type
+ * @property {"weakened"|"removed"|"exemption-added"|"file-deleted"|"allow-added"|"unparseable"|"unparseable-baseline"} type
  *   Which ratchet rule the change violated
  * @property {number|string} [base] Baseline value
  * @property {number|string} [current] Current value
@@ -49,6 +49,25 @@ function unparseable(relPath) {
   };
 }
 
+/**
+ * Build the "baseline could not be parsed" finding.
+ *
+ * Separate from `unparseable` because the two send an operator to different
+ * files. Told only that `vitest.thresholds.json` is not valid JSON, they open
+ * the current file, find it well-formed, and conclude the gate is broken; the
+ * defect is at the base ref.
+ * @param {string} relPath Repo-relative path
+ * @returns {Finding} The unparseable-baseline finding
+ */
+function unparseableBaseline(relPath) {
+  return {
+    file: relPath,
+    key: "*",
+    type: "unparseable-baseline",
+    message: `${relPath} is not valid JSON in the baseline — with no baseline to compare against, the ratchet cannot see a loosening in this file and will not see one in any later change either, until the baseline is repaired. A UTF-8 BOM, a trailing comma or an empty file all land here.`,
+  };
+}
+
 /**
  * Compare two constraint maps: report removals and direction violations.
  * @param {string} relPath Repo-relative path the constraints came from
@@ -242,7 +261,27 @@ export function compareFile(relPath, baselineText, currentText) {
 
   const base = parseJson(baselineText);
   const current = parseJson(currentText);
-  if (base === undefined) return [];
+  // Both sides are reported, and both used to not be. An unparseable baseline
+  // returned no findings at all, which did not merely miss one change: once a
+  // malformed threshold file is on the base branch, every later pull request
+  // compares against a baseline that yields no constraints, so the ratchet
+  // stops having an opinion about that file — permanently, and in silence.
+  //
+  // This is only reached for a file that EXISTS at the baseline and did not
+  // parse. A file absent from the base ref arrives as a null `baselineText`
+  // and returned above: new gate files have nothing to weaken, and the caller
+  // separates absent from present-but-unreadable with `cat-file -e` before
+  // calling.
+  //
+  // The allow-list carve-out is symmetric with the current side and holds for
+  // the same reason: an allow list nobody can read grants no exceptions, so an
+  // unreadable one on either side already fails closed. Reporting it would
+  // block every change touching the file without making anything safer.
+  if (base === undefined) {
+    return family.kind === KIND_ALLOW_LIST
+      ? []
+      : [unparseableBaseline(relPath)];
+  }
   if (current === undefined) {
     return family.kind === KIND_ALLOW_LIST ? [] : [unparseable(relPath)];
   }

package/rails/copy-overwrite/scripts/threshold-ratchet-compare.mjs

@@ -31,7 +31,7 @@ const KIND_ALLOW_LIST = "allow-list";
  * @typedef {object} Finding
  * @property {string} file Repo-relative path of the gate file
  * @property {string} key Dotted key path within the file
- * @property {"weakened"|"removed"|"exemption-added"|"file-deleted"|"allow-added"|"unparseable"} type
+ * @property {"weakened"|"removed"|"exemption-added"|"file-deleted"|"allow-added"|"unparseable"|"unparseable-baseline"} type
  *   Which ratchet rule the change violated
  * @property {number|string} [base] Baseline value
  * @property {number|string} [current] Current value
@@ -52,6 +52,25 @@ function unparseable(relPath) {
   };
 }
 
+/**
+ * Build the "baseline could not be parsed" finding.
+ *
+ * Separate from `unparseable` because the two send an operator to different
+ * files. Told only that `vitest.thresholds.json` is not valid JSON, they open
+ * the current file, find it well-formed, and conclude the gate is broken; the
+ * defect is at the base ref.
+ * @param {string} relPath Repo-relative path
+ * @returns {Finding} The unparseable-baseline finding
+ */
+function unparseableBaseline(relPath) {
+  return {
+    file: relPath,
+    key: "*",
+    type: "unparseable-baseline",
+    message: `${relPath} is not valid JSON in the baseline — with no baseline to compare against, the ratchet cannot see a loosening in this file and will not see one in any later change either, until the baseline is repaired. A UTF-8 BOM, a trailing comma or an empty file all land here.`,
+  };
+}
+
 /**
  * Compare two constraint maps: report removals and direction violations.
  * @param {string} relPath Repo-relative path the constraints came from
@@ -245,7 +264,27 @@ export function compareFile(relPath, baselineText, currentText) {
 
   const base = parseJson(baselineText);
   const current = parseJson(currentText);
-  if (base === undefined) return [];
+  // Both sides are reported, and both used to not be. An unparseable baseline
+  // returned no findings at all, which did not merely miss one change: once a
+  // malformed threshold file is on the base branch, every later pull request
+  // compares against a baseline that yields no constraints, so the ratchet
+  // stops having an opinion about that file — permanently, and in silence.
+  //
+  // This is only reached for a file that EXISTS at the baseline and did not
+  // parse. A file absent from the base ref arrives as a null `baselineText`
+  // and returned above: new gate files have nothing to weaken, and the caller
+  // separates absent from present-but-unreadable with `cat-file -e` before
+  // calling.
+  //
+  // The allow-list carve-out is symmetric with the current side and holds for
+  // the same reason: an allow list nobody can read grants no exceptions, so an
+  // unreadable one on either side already fails closed. Reporting it would
+  // block every change touching the file without making anything safer.
+  if (base === undefined) {
+    return family.kind === KIND_ALLOW_LIST
+      ? []
+      : [unparseableBaseline(relPath)];
+  }
   if (current === undefined) {
     return family.kind === KIND_ALLOW_LIST ? [] : [unparseable(relPath)];
   }

package/scripts/lisa-enforcement-fallback.sh

@@ -22,7 +22,25 @@ set -uo pipefail
 
 payload="$(cat)"
 
-repo_root="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null)}"
+# `:-` substitutes on unset and on set-but-empty, and on nothing else. A value
+# of " " is neither: `-n " "` is true, so it used to survive the emptiness test
+# below, every candidate path became " /scripts/lisa-hooks/..." , no file
+# matched, and every guard was skipped. That is the empty-string-fallback class
+# verbatim — a value that passes the truthiness test, normalizes to nothing, and
+# makes the downstream match find nothing.
+#
+# So the variable is trimmed FIRST and the substitution keyed off the trimmed
+# value. Whitespace then reaches `git rev-parse` exactly as an unset variable
+# does, instead of resolving to a root that cannot exist.
+repo_root="${CLAUDE_PROJECT_DIR-}"
+repo_root="${repo_root#"${repo_root%%[![:space:]]*}"}"
+repo_root="${repo_root%"${repo_root##*[![:space:]]}"}"
+if [ -z "$repo_root" ]; then
+  repo_root="$(git rev-parse --show-toplevel 2>/dev/null)"
+fi
+# No root at all means no repository to protect — a tool call outside any
+# checkout. That is a genuine absence of subject matter, not a missing guard,
+# and is the one case that still stands down.
 [ -n "$repo_root" ] || exit 0
 
 # There is deliberately no skip here, and that is the whole point.
@@ -66,6 +84,8 @@ repo_root="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null)}"
 # host project whose plugin install fails has exactly the same hole and no
 # `plugins/` directory to fall back on.
 status=0
+resolved=0
+missing=""
 for guard in block-no-verify parity-safety-net block-shell-json-parsing \
   block-instruction-file-edits block-direct-issue-create \
   block-managed-file-edits; do
@@ -78,7 +98,11 @@ for guard in block-no-verify parity-safety-net block-shell-json-parsing \
       break
     fi
   done
-  [ -n "$script" ] || continue
+  if [ -z "$script" ]; then
+    missing="${missing:+$missing, }$guard"
+    continue
+  fi
+  resolved=$((resolved + 1))
   # Each guard reads the tool payload on stdin and signals a refusal with exit
   # 2. The payload is replayed to every one of them, and the strongest refusal
   # is returned — a guard that declines must not be able to clear one that did
@@ -108,4 +132,56 @@ for guard in block-no-verify parity-safety-net block-shell-json-parsing \
   fi
 done
 
+# Zero guards resolved is a refusal, not a pass.
+#
+# Six `continue`s used to leave `status` at 0, so nothing distinguished "every
+# guard ran and none objected" from "no guard was found". That is the same
+# silent fail-open this file was written to close, reproduced one layer down: a
+# host whose `scripts/lisa-hooks/` was never written by `lisa apply`, or was
+# deleted, or drifted — precisely the state this file exists for — got the same
+# green as a clean session.
+#
+# Refusing rather than warning is a deliberate choice between two imperfect
+# options, and the reasons are these.
+#
+#   - The hook entry and the guards ship from the SAME `lisa apply`:
+#     `all/merge/.claude/settings.json` registers this dispatcher and
+#     `all/copy-overwrite/scripts/lisa-hooks/` writes the guards. "Registered
+#     but no guards" is therefore never a configuration anyone chose; it is
+#     always drift, deletion, or a partial apply.
+#   - Warning on exit 0 is barely louder than silence. Claude Code shows a
+#     zero-status hook's output to the user in transcript mode only and never
+#     to the agent, so "fail loud, exit unchanged" would have left the failure
+#     very nearly as invisible as it already was while claiming to have fixed
+#     it.
+#   - The blocking cost is bounded and recoverable without the agent. The
+#     refusal below names the guards, both searched paths, and the one command
+#     that repairs it, which a human runs in a terminal — no tool call needed.
+#
+# The scope is deliberately "zero", not "fewer than six". A partial resolution
+# means some enforcement ran, and version skew across an interrupted apply is a
+# real enough way to reach it that refusing there would trade a silent hole for
+# a noisy outage.
+if [ "$resolved" -eq 0 ]; then
+  cat >&2 <<EOF
+Blocked: Lisa's enforcement guards are missing from this repository, so this
+tool call was checked by nothing at all.
+
+This hook is registered in .claude/settings.json but resolved none of the
+guards it dispatches: $missing
+
+Searched:
+  $repo_root/scripts/lisa-hooks/<guard>.sh
+  $repo_root/plugins/lisa/hooks/<guard>.sh
+
+Refused rather than allowed on purpose. A dispatcher that resolves nothing is
+indistinguishable from one that was never installed, and letting the call
+through would be the silent fail-open this hook exists to close.
+
+To repair, run this in a terminal outside the agent session:
+  npx @codyswann/lisa apply
+EOF
+  exit 2
+fi
+
 exit "$status"

package/typescript/copy-overwrite/scripts/threshold-ratchet-compare.mjs

@@ -31,7 +31,7 @@ const KIND_ALLOW_LIST = "allow-list";
  * @typedef {object} Finding
  * @property {string} file Repo-relative path of the gate file
  * @property {string} key Dotted key path within the file
- * @property {"weakened"|"removed"|"exemption-added"|"file-deleted"|"allow-added"|"unparseable"} type
+ * @property {"weakened"|"removed"|"exemption-added"|"file-deleted"|"allow-added"|"unparseable"|"unparseable-baseline"} type
  *   Which ratchet rule the change violated
  * @property {number|string} [base] Baseline value
  * @property {number|string} [current] Current value
@@ -52,6 +52,25 @@ function unparseable(relPath) {
   };
 }
 
+/**
+ * Build the "baseline could not be parsed" finding.
+ *
+ * Separate from `unparseable` because the two send an operator to different
+ * files. Told only that `vitest.thresholds.json` is not valid JSON, they open
+ * the current file, find it well-formed, and conclude the gate is broken; the
+ * defect is at the base ref.
+ * @param {string} relPath Repo-relative path
+ * @returns {Finding} The unparseable-baseline finding
+ */
+function unparseableBaseline(relPath) {
+  return {
+    file: relPath,
+    key: "*",
+    type: "unparseable-baseline",
+    message: `${relPath} is not valid JSON in the baseline — with no baseline to compare against, the ratchet cannot see a loosening in this file and will not see one in any later change either, until the baseline is repaired. A UTF-8 BOM, a trailing comma or an empty file all land here.`,
+  };
+}
+
 /**
  * Compare two constraint maps: report removals and direction violations.
  * @param {string} relPath Repo-relative path the constraints came from
@@ -245,7 +264,27 @@ export function compareFile(relPath, baselineText, currentText) {
 
   const base = parseJson(baselineText);
   const current = parseJson(currentText);
-  if (base === undefined) return [];
+  // Both sides are reported, and both used to not be. An unparseable baseline
+  // returned no findings at all, which did not merely miss one change: once a
+  // malformed threshold file is on the base branch, every later pull request
+  // compares against a baseline that yields no constraints, so the ratchet
+  // stops having an opinion about that file — permanently, and in silence.
+  //
+  // This is only reached for a file that EXISTS at the baseline and did not
+  // parse. A file absent from the base ref arrives as a null `baselineText`
+  // and returned above: new gate files have nothing to weaken, and the caller
+  // separates absent from present-but-unreadable with `cat-file -e` before
+  // calling.
+  //
+  // The allow-list carve-out is symmetric with the current side and holds for
+  // the same reason: an allow list nobody can read grants no exceptions, so an
+  // unreadable one on either side already fails closed. Reporting it would
+  // block every change touching the file without making anything safer.
+  if (base === undefined) {
+    return family.kind === KIND_ALLOW_LIST
+      ? []
+      : [unparseableBaseline(relPath)];
+  }
   if (current === undefined) {
     return family.kind === KIND_ALLOW_LIST ? [] : [unparseable(relPath)];
   }