@codyswann/lisa 2.323.1 → 2.324.1

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.323.1",
+  "version": "2.324.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": "2.323.1",
+  "version": "2.324.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": "2.323.1",
+  "version": "2.324.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": "2.323.1",
+  "version": "2.324.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": "2.323.1",
+  "version": "2.324.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": "2.323.1",
+  "version": "2.324.1",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

package/plugins/src/base/rules/eager/tracked-work.md

@@ -2,6 +2,6 @@
 
 Before the first durable project mutation (code, tests, config, docs, committed research/plans/findings, commits, or PRs), establish exactly one live tracker leaf through `lisa-track`. Read-only discussion and orientation are exempt only while they produce no durable artifact.
 
-The mandatory order is: live-validate an explicit ref, or conservatively search and create exactly one valid leaf through `lisa-tracker-write` when no unique match exists; idempotently claim it through `lisa-tracker-claim`; then persist and verify the worktree-local binding with `node scripts/lisa-work-item.mjs bind <ref>`. Any tracker, claim, or binding failure blocks durable work.
+The mandatory order is: live-validate an explicit ref, or conservatively search and create exactly one valid leaf through `lisa-tracker-write` when no unique match exists; idempotently claim it through `lisa-tracker-claim`; then persist and verify the worktree-local binding with `node scripts/lisa-work-item.mjs bind <ref>`. A tracker that answers no, and any claim or binding failure, blocks durable work; a tracker that cannot be reached does not block a commit — the offline checks still run, the skip is loud on stderr, and the required `Work-Item Traceability` check re-runs the live checks with credentials before anything merges.
 
 Carry that canonical ref through the branch, every ordinary commit's `Work-Item:` trailer, the PR, usage/evidence, and `lisa-tracker-sync`. Hooks and CI never create tickets. Keep the binding through interruptions or blocked outcomes; run `node scripts/lisa-work-item.mjs clear` only after merge/deploy/verification, two-way linkage/evidence, and the tracker item have all reached true terminal completion.

package/plugins/src/base/rules/reference/tracked-work.md

@@ -11,7 +11,7 @@ Use `lisa-track` as the single entry point:
 3. Idempotently claim the resolved leaf through `lisa-tracker-claim`, which reuses the vendor build-intake claim semantics and post-read verifies the claimed-or-later state.
 4. Before any durable repository work, persist the canonical reference with `node scripts/lisa-work-item.mjs bind <ref>` and verify the worktree-local binding.
 
-The sequence is strict: **live validate/create -> claim -> bind -> durable work**. A failed tracker read/write, claim, or binding blocks the work. Tracker availability must be proven; tool presence or stale session text is not access.
+The sequence is strict: **live validate/create -> claim -> bind -> durable work**. A tracker answer of no, and any claim or binding failure, blocks the work. A tracker that cannot be reached — `gh` absent, or its credential refused — does not block a commit: the offline checks still run, the skip is loud on stderr, and the required `Work-Item Traceability` check re-runs the live checks with credentials before anything merges. Any other tracker failure still blocks. Tool presence or stale session text is not access.
 
 ## One canonical identity
 

package/plugins/src/base/skills/lisa-setup-remote-env/SKILL.md

@@ -107,6 +107,14 @@ The selection comes from the surface's `materializeAt` capability in `lisa-secre
           "url": "https://<vendor>/releases/download/bws-v2.1.0/bws-<platform>-2.1.0.zip",
           "sha256": "<sha256 published with that exact release>"
         },
+        {
+          "name": "gh",
+          "version": "2.83.0",
+          "install": "release-tar",
+          "url": "https://<vendor>/releases/download/v2.83.0/gh_2.83.0_linux_amd64.tar.gz",
+          "sha256": "<sha256 published with that exact release>",
+          "binary": "gh_2.83.0_linux_amd64/bin/gh"
+        },
         {
           "name": "codex",
           "version": "0.144.6",
@@ -133,6 +141,22 @@ The selection comes from the surface's `materializeAt` capability in `lisa-secre
 
 Expected shape for most projects: a short `require` list, an empty or near-empty `install` list, and the provider CLI as the only thing always provisioned.
 
+### The three `install` methods
+
+| `install` | Required fields | Use it when |
+| --- | --- | --- |
+| `release-zip` | `url` **and** `sha256` | The vendor publishes a Linux zip of the release. |
+| `release-tar` | `url` **and** `sha256` — plus `binary` in practice | The vendor publishes no zip for Linux, only a `.tar.gz`. |
+| `npm-global` | `package` | The tool ships on the npm registry. |
+
+Anything else is rejected by name at plan time, so a typo fails loudly rather than silently installing nothing.
+
+Both archive kinds carry the **same** obligation and differ only in how they are unpacked: `url` and `sha256` are both mandatory, the checksum is verified *before* the archive is unpacked, and a version bump must move the checksum in the same reviewed commit. Neither is a weaker path than the other — `release-tar` exists because some tools worth pinning simply do not publish a zip. `gh` is the case that forced it: it ships `.deb`, `.rpm` and `.tar.gz` and nothing else, so a zip-only installer could not pin the CLI that Lisa's own commit guardrails shell out to.
+
+**`binary` means something different for a tarball.** It defaults to the tool's `name` and is resolved relative to the unpacked directory. Release tarballs almost always nest their contents under a versioned top-level directory, so for `release-tar` it must be the path *within* the archive — `gh_2.83.0_linux_amd64/bin/gh`, not `gh`. A bare name there resolves to nothing after a download that otherwise succeeded, and the install fails at the copy step rather than at the fetch, which reads as a broken release when it is a manifest mistake. Bump the version and this path moves with it, alongside the `url` and the `sha256`.
+
+Because `release-tar` unpacks with `tar` rather than `unzip`, a project using it should assert `tar` in its `require` list the same way a zip-installing project asserts `unzip` — the base image providing it is an assumption, not a contract.
+
 ### Rules
 
 - **The base image is not a contract.** A vendor can change it. A project quietly depending on a preinstalled `jq` should break loudly at setup when that happens, not mysteriously mid-task weeks later. `require` is what converts an implicit assumption into an explicit check.

package/plugins/src/base/skills/lisa-setup-remote-env/assets/session-start.sh

@@ -27,4 +27,21 @@ if [ "${CLAUDE_CODE_REMOTE:-}" != "true" ]; then
 fi
 
 here="$(CDPATH='' cd -- "$(dirname -- "$0")" && pwd)"
+
+# The toolchain first, for the same reason the secrets are here at all.
+#
+# It used to run only from the environment setup script, which a cached
+# environment skips — so a tool added to remoteEnv.tools was invisible until the
+# cache expired about a week later, or until someone edited the vendor's setup
+# field to force a rebuild. Neither is a thing a project can rely on, and the
+# symptom is a container missing a tool its own committed config pins.
+#
+# It is cheap to repeat: the plan probes each tool and installs only what is
+# absent or below its pinned version, so on a warm container this is a handful
+# of --version calls and nothing else.
+#
+# Before secrets, because materializing needs the provider CLI that this step
+# installs. A failure here is fatal for the same reason: continuing would report
+# a missing credential when the real fault was a missing binary.
+bash "${here}/setup.sh" --phase=toolchain "$@"
 exec bash "${here}/setup.sh" --phase=secrets "$@"

package/plugins/src/base/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs

@@ -153,6 +153,42 @@ function installReleaseZip(tool, binDir) {
   }
 }
 
+/**
+ * Install a pinned tarball, refusing anything whose checksum does not match.
+ *
+ * Same contract as the zip path and the same ordering — verify, then unpack —
+ * because an unexpected archive must fail before any of its contents reach a
+ * directory that is on PATH. It exists because several tools worth pinning
+ * publish no zip for Linux: gh ships .deb, .rpm and .tar.gz and nothing else.
+ * @param {object} tool Manifest entry.
+ * @param {string} binDir Directory to install into.
+ */
+function installReleaseTar(tool, binDir) {
+  const temporary = join(binDir, `.${tool.name}-download`);
+  mkdirSync(temporary, { recursive: true });
+  try {
+    const archive = join(temporary, "download.tar.gz");
+    execFileSync("curl", ["-fsSL", tool.url, "-o", archive], {
+      stdio: "inherit",
+    });
+    execFileSync("sha256sum", ["-c", "-"], {
+      input: `${tool.sha256}  ${archive}\n`,
+      stdio: ["pipe", "ignore", "inherit"],
+    });
+    execFileSync("tar", ["-xzf", archive, "-C", temporary], {
+      stdio: "inherit",
+    });
+    // Release tarballs usually nest under a versioned directory, so `binary` is
+    // a path within the archive rather than a bare name.
+    const binary = join(temporary, tool.binary ?? tool.name);
+    execFileSync("install", ["-m", "0755", binary, join(binDir, tool.name)], {
+      stdio: "inherit",
+    });
+  } finally {
+    rmSync(temporary, { recursive: true, force: true });
+  }
+}
+
 /**
  * Install a pinned global npm package.
  * @param {object} tool Manifest entry.
@@ -175,6 +211,7 @@ function installNpmGlobal(tool) {
 function installTool(tool, binDir) {
   assertPinned(tool);
   if (tool.install === "release-zip") installReleaseZip(tool, binDir);
+  else if (tool.install === "release-tar") installReleaseTar(tool, binDir);
   else installNpmGlobal(tool);
 }
 

package/plugins/src/base/skills/lisa-setup-remote-env/scripts/toolchain.mjs

@@ -148,10 +148,14 @@ export function planToolchain(tools, probe) {
  * @param {object} tool Manifest entry.
  */
 export function assertPinned(tool) {
-  if (tool.install === "release-zip") {
+  // Both archive kinds carry the same obligation, and differ only in how they
+  // are unpacked. gh, for one, publishes no zip for Linux at all — only .deb,
+  // .rpm and .tar.gz — so a zip-only installer could not pin the CLI that
+  // Lisa's own guardrails shell out to.
+  if (tool.install === "release-zip" || tool.install === "release-tar") {
     if (!tool.url || !tool.sha256) {
       throw new Error(
-        `${tool.name}: a release-zip install needs both url and sha256.\n` +
+        `${tool.name}: a ${tool.install} install needs both url and sha256.\n` +
           `A version bump must move the checksum in the same reviewed commit.`
       );
     }
@@ -164,6 +168,6 @@ export function assertPinned(tool) {
   }
   throw new Error(
     `${tool.name}: unknown install method "${tool.install}".\n` +
-      `Supported: release-zip, npm-global.`
+      `Supported: release-zip, release-tar, npm-global.`
   );
 }

package/scripts/build-plugins.sh

@@ -90,6 +90,38 @@ if [ -f "$SRC_DIR/base/hooks/threshold-ratchet.mjs" ]; then
   done
 fi
 
+# Enforcement guards for host projects.
+#
+# These three are declared in the Lisa plugin, so a container whose plugin
+# install fails runs with no PreToolUse enforcement at all — silently. Lisa
+# closes that with a repository hook, which reaches a cloud session because it
+# is part of the clone; a host project needs the same thing, and has no
+# plugins/ directory to fall back on.
+#
+# Synced rather than hand-copied, for the same reason the ratchet above is: a
+# unit test asserts byte-equality, so the shipped guard can never drift from the
+# reviewed one.
+HOST_GUARD_DIR="$ROOT_DIR/all/copy-overwrite/scripts/lisa-hooks"
+if [ -d "$SRC_DIR/base/hooks" ]; then
+  mkdir -p "$HOST_GUARD_DIR"
+fi
+for guard in block-no-verify parity-safety-net block-shell-json-parsing; do
+  if [ -f "$SRC_DIR/base/hooks/$guard.sh" ]; then
+    cp "$SRC_DIR/base/hooks/$guard.sh" "$HOST_GUARD_DIR/$guard.sh"
+    chmod +x "$HOST_GUARD_DIR/$guard.sh"
+  fi
+done
+# The dispatcher itself, so a host project gets the identical entry point.
+# Guarded like the ratchet above: this script is also run against isolated
+# fixtures that carry a source tree but none of the repository's own scripts,
+# and an unconditional copy fails the whole build there.
+if [ -f "$ROOT_DIR/scripts/lisa-enforcement-fallback.sh" ]; then
+  mkdir -p "$ROOT_DIR/all/copy-overwrite/scripts"
+  cp "$ROOT_DIR/scripts/lisa-enforcement-fallback.sh" \
+    "$ROOT_DIR/all/copy-overwrite/scripts/lisa-enforcement-fallback.sh"
+  chmod +x "$ROOT_DIR/all/copy-overwrite/scripts/lisa-enforcement-fallback.sh"
+fi
+
 # Stack-specific plugins (NO base copy)
 STACKS=(typescript expo nestjs cdk harper-fabric phaser rails)
 for stack in "${STACKS[@]}"; do

package/scripts/generate-upstream-evidence-manifest.mjs

@@ -42,18 +42,57 @@ const forbiddenBasenames = new Set([
   ".mcp.json",
   "audit.local",
 ]);
-const canonicalOriginUrls = new Set([
-  "https://github.com/CodySwannGT/lisa.git",
-  "https://github.com/CodySwannGT/lisa",
-  "git@github.com:CodySwannGT/lisa.git",
-]);
+/** The repository this manifest may be generated from. Not a URL — see below. */
+const canonicalRepository = "CodySwannGT/lisa";
 
-const originUrl = execFileSync("git", ["remote", "get-url", "origin"], {
-  cwd: repoRoot,
-  encoding: "utf8",
-}).trim();
-if (!canonicalOriginUrls.has(originUrl)) {
-  throw new Error(`Refusing non-canonical Lisa origin: ${originUrl}`);
+/**
+ * The `owner/repo` an origin URL points at, or null if it names none.
+ *
+ * The guard exists to refuse hash-pinning from a fork, which is a question
+ * about **identity**. It used to compare the whole origin URL against a list of
+ * spellings, which answers a question about **transport** instead — and the two
+ * come apart in ordinary situations, not just exotic ones. `remote.origin.url`
+ * and `remote.origin.pushurl` can differ, `url.<base>.insteadOf` rewrites what
+ * `git remote get-url` returns, and a cloud container clones through a local
+ * git proxy. All three are proxied checkouts of the real repository, and all
+ * three were refused before a single hash was checked.
+ *
+ * Comparing the path keeps the property that matters: a fork is
+ * `someone-else/lisa` and is still refused, while `https://…`, `git@…` and
+ * `http://local_proxy@127.0.0.1:PORT/git/…` all resolve to the same identity.
+ * @param {string} url Whatever `git remote get-url` returned.
+ * @returns {string|null} `owner/repo`, lowercased, or null.
+ */
+function repositoryPath(url) {
+  // scp-style (git@host:owner/repo.git) is not a URL, so it is handled first.
+  const scp = /^[^/]+@[^:/]+:(?<path>.+)$/u.exec(url);
+  const raw =
+    scp?.groups?.path ?? (URL.canParse(url) ? new URL(url).pathname : null);
+  if (raw === null) return null;
+  const segments = raw
+    .replace(/\.git$/u, "")
+    .split("/")
+    .filter(Boolean);
+  if (segments.length < 2) return null;
+  return segments.slice(-2).join("/").toLowerCase();
+}
+
+// The configured value rather than the resolved one, for the same reason the
+// comparison is by path: `url.<base>.insteadOf` rewrites what `git remote
+// get-url` returns, so it answers "how do I reach this" rather than "what is
+// this". Falls back to the resolved URL only if no value is configured.
+const originUrl = execFileSync(
+  "git",
+  ["config", "--get", "remote.origin.url"],
+  { cwd: repoRoot, encoding: "utf8" }
+).trim();
+if (repositoryPath(originUrl) !== canonicalRepository.toLowerCase()) {
+  throw new Error(
+    `Refusing to generate from a non-canonical repository.\n` +
+      `origin resolves to: ${repositoryPath(originUrl) ?? "(no owner/repo)"}\n` +
+      `expected:           ${canonicalRepository}\n` +
+      `(origin URL was: ${originUrl})`
+  );
 }
 
 const tracked = execFileSync("git", ["ls-files", "-z"], {

package/scripts/lisa-enforcement-fallback.sh

@@ -0,0 +1,71 @@
+#!/usr/bin/env bash
+#
+# Run Lisa's Bash enforcement guards when the plugin that normally provides them
+# is not installed.
+#
+# Every PreToolUse guard — block-no-verify, parity-safety-net,
+# block-shell-json-parsing — is declared in the Lisa plugin. A cloud session
+# installs plugins at session start from the marketplace the repository
+# declares, and when that does not happen the container runs with
+# `installed_plugins.json` empty and no enforcement whatsoever.
+#
+# That is how a dispatched session committed with `--no-verify`: not by evading
+# a guard, but in an environment where none existed. The guards failed open, and
+# silently, which is the worst of the three ways they could fail.
+#
+# A repository hook is the delivery that cannot fail this way. `.claude/settings.json`
+# is part of the clone, so it reaches a cloud session whether or not a plugin
+# ever installs.
+set -uo pipefail
+
+payload="$(cat)"
+
+repo_root="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null)}"
+[ -n "$repo_root" ] || exit 0
+
+# Skip when the plugin is installed, so a developer machine does not run every
+# guard twice and print every refusal twice. Absence is the interesting case and
+# the only one this exists for.
+#
+# Read from the plugin registry rather than from CLAUDE_PLUGIN_ROOT: that
+# variable is set for plugin hooks, and this hook is by definition not one.
+installed="${CLAUDE_CONFIG_DIR:-$HOME/.claude}/plugins/installed_plugins.json"
+if [ -f "$installed" ] && grep -q '"lisa@lisa"' "$installed" 2>/dev/null; then
+  exit 0
+fi
+
+# Where the guards live depends on which repository this is.
+#
+# `plugins/lisa/hooks/` exists only in the Lisa monorepo. A host project gets
+# the same three scripts written into its checkout by `lisa apply`, because a
+# host project whose plugin install fails has exactly the same hole and no
+# `plugins/` directory to fall back on.
+status=0
+for guard in block-no-verify parity-safety-net block-shell-json-parsing; do
+  script=""
+  for candidate in \
+    "$repo_root/scripts/lisa-hooks/$guard.sh" \
+    "$repo_root/plugins/lisa/hooks/$guard.sh"; do
+    if [ -f "$candidate" ]; then
+      script="$candidate"
+      break
+    fi
+  done
+  [ -n "$script" ] || continue
+  # 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
+  # not.
+  #
+  # The status is captured from the pipeline directly rather than through `if !`,
+  # where `$?` is the negation and every refusal read as success: the guard
+  # printed its objection and the command ran anyway, which is the same
+  # fail-open this file exists to close.
+  printf '%s' "$payload" | bash "$script"
+  guard_status=$?
+  if [ "$guard_status" -gt "$status" ]; then
+    status="$guard_status"
+  fi
+done
+
+exit "$status"

package/scripts/lisa-remote-env/session-start.sh

@@ -27,4 +27,21 @@ if [ "${CLAUDE_CODE_REMOTE:-}" != "true" ]; then
 fi
 
 here="$(CDPATH='' cd -- "$(dirname -- "$0")" && pwd)"
+
+# The toolchain first, for the same reason the secrets are here at all.
+#
+# It used to run only from the environment setup script, which a cached
+# environment skips — so a tool added to remoteEnv.tools was invisible until the
+# cache expired about a week later, or until someone edited the vendor's setup
+# field to force a rebuild. Neither is a thing a project can rely on, and the
+# symptom is a container missing a tool its own committed config pins.
+#
+# It is cheap to repeat: the plan probes each tool and installs only what is
+# absent or below its pinned version, so on a warm container this is a handful
+# of --version calls and nothing else.
+#
+# Before secrets, because materializing needs the provider CLI that this step
+# installs. A failure here is fatal for the same reason: continuing would report
+# a missing credential when the real fault was a missing binary.
+bash "${here}/setup.sh" --phase=toolchain "$@"
 exec bash "${here}/setup.sh" --phase=secrets "$@"