@codyswann/lisa 2.324.0 → 2.325.0

package/plugins/src/base/skills/lisa-detect-tooling/scripts/detect-tooling.mjs

@@ -0,0 +1,311 @@
+#!/usr/bin/env node
+/**
+ * Find the command-line tools a project needs but never declares.
+ *
+ * Lisa provisions tooling through several unrelated mechanisms — npm
+ * devDependencies from a stack template, MCP servers, a dedicated installer for
+ * Sonar, and the pinned `remoteEnv.tools` manifest. Only the last one puts a
+ * binary on PATH, and nothing populates it. So a project can ship npm scripts
+ * that invoke `maestro`, wire an MCP server whose CLI it also shells out to, and
+ * declare Playwright coverage thresholds, while the manifest that actually
+ * provisions binaries stays empty and every one of those fails at the moment of
+ * use rather than at setup.
+ *
+ * This program only ever *proposes*. It writes nothing, installs nothing, and
+ * emits manifest entries with the fields a human still has to fill — a pinned
+ * version, a URL, a checksum. That boundary is the point: a tool should reach a
+ * machine because someone reviewed a pinned entry, never because a detector was
+ * confident. Detection is evidence; the manifest is the decision.
+ *
+ * Usage:
+ *   detect-tooling.mjs [--json]
+ * @module detect-tooling
+ */
+
+import { existsSync, readFileSync } from "node:fs";
+import { join } from "node:path";
+
+/**
+ * Tools Lisa or its templates invoke, and how to recognise a need for them.
+ *
+ * Deliberately conservative. A false positive costs a human a moment's review;
+ * a false negative is the failure this exists to prevent, so the signals are
+ * ones that only appear when the tool is genuinely used.
+ */
+const KNOWN_TOOLS = Object.freeze({
+  maestro: {
+    why: "Expo's template ships npm scripts that invoke `maestro`, and nothing installs the binary.",
+    mcpFallback: "maestro",
+  },
+  gh: {
+    why: "The work-item guardrails shell out to `gh` for every tracker read.",
+  },
+  bws: {
+    why: "The Bitwarden CLI is how every secret is resolved.",
+  },
+  "sonar-scanner": {
+    why: "Sonar analysis runs a scanner binary, which the Sonar installer configures but does not place on PATH.",
+  },
+  playwright: {
+    why: "Playwright drives browser E2E and its coverage thresholds are configured.",
+    viaNpm: "@playwright/test",
+  },
+  linear: {
+    why: "Linear is wired as an MCP server, which needs browser OAuth and so cannot authenticate in a container.",
+    mcpFallback: "linear-server",
+  },
+});
+
+/**
+ * Read a JSON file, treating absence or damage as "no signal".
+ *
+ * A detector that throws on a malformed config is worse than one that misses a
+ * signal: it blocks the very command an operator runs to find out what is wrong.
+ * @param {string} path File to read.
+ * @returns {object|null} Parsed contents, or null.
+ */
+function readJson(path) {
+  if (!existsSync(path)) return null;
+  try {
+    return JSON.parse(readFileSync(path, "utf8"));
+  } catch {
+    return null;
+  }
+}
+
+/**
+ * Tools named by npm scripts, which is the strongest signal there is.
+ *
+ * A script that runs `maestro test` is a project stating it needs Maestro, in
+ * executable form. Word-boundary matched so `maestro:test` as a script *name*
+ * does not count while `maestro test` as its body does — the name is a label,
+ * the body is a dependency.
+ * @param {object|null} pkg Parsed package.json.
+ * @returns {Map<string, string>} Tool name to the script that proves it.
+ */
+export function toolsFromScripts(pkg) {
+  const found = new Map();
+  const scripts = pkg?.scripts ?? {};
+  for (const [name, body] of Object.entries(scripts)) {
+    if (typeof body !== "string") continue;
+    for (const tool of Object.keys(KNOWN_TOOLS)) {
+      const pattern = new RegExp(`(^|[\\s;&|(])${tool}(\\s|$)`, "u");
+      if (pattern.test(body) && !found.has(tool)) {
+        found.set(tool, `npm script "${name}": ${body.trim().slice(0, 60)}`);
+      }
+    }
+  }
+  return found;
+}
+
+/**
+ * Tools implied by MCP servers that also have a CLI.
+ *
+ * An MCP server is not a substitute for the binary. Several authenticate by
+ * browser OAuth, which a container cannot do at all, so a project relying on one
+ * remotely has no integration rather than a degraded one — the CLI is the form
+ * that survives the trip.
+ * @param {object|null} mcp Parsed .mcp.json.
+ * @returns {Map<string, string>} Tool name to the server that implies it.
+ */
+export function toolsFromMcp(mcp) {
+  const found = new Map();
+  const servers = Object.keys(mcp?.mcpServers ?? {});
+  for (const [tool, meta] of Object.entries(KNOWN_TOOLS)) {
+    if (!meta.mcpFallback) continue;
+    const server = servers.find(name => name.includes(meta.mcpFallback));
+    if (server) {
+      found.set(
+        tool,
+        `MCP server "${server}" (browser OAuth cannot run remotely)`
+      );
+    }
+  }
+  return found;
+}
+
+/**
+ * Tools named in credential usage notes.
+ *
+ * A note explaining what a token is *for* usually names the program that
+ * consumes it, and those notes are already readable without touching a value —
+ * `read-secret-note.mjs` exists precisely so an agent can learn a credential's
+ * blast radius safely. That makes them a first-class detection input rather than
+ * a clever trick.
+ * @param {object|null} notes Parsed secret-notes.json.
+ * @returns {Map<string, string>} Tool name to the credential that names it.
+ */
+export function toolsFromSecretNotes(notes) {
+  const found = new Map();
+  const entries = Object.entries(notes?.notes ?? notes ?? {});
+  for (const [secret, note] of entries) {
+    const text = typeof note === "string" ? note : JSON.stringify(note ?? "");
+    for (const tool of Object.keys(KNOWN_TOOLS)) {
+      const pattern = new RegExp(
+        `(^|[^A-Za-z0-9-])${tool}([^A-Za-z0-9-]|$)`,
+        "iu"
+      );
+      if (pattern.test(text) && !found.has(tool)) {
+        found.set(tool, `usage note on credential "${secret}"`);
+      }
+    }
+  }
+  return found;
+}
+
+/**
+ * Tools implied by quality configuration.
+ * @param {object|null} config Parsed .lisa.config.json.
+ * @returns {Map<string, string>} Tool name to the setting that implies it.
+ */
+export function toolsFromQuality(config) {
+  const found = new Map();
+  if (config?.quality?.e2eCoverage?.playwright) {
+    found.set("playwright", "quality.e2eCoverage.playwright is configured");
+  }
+  if (config?.quality?.sonar || config?.sonar) {
+    found.set("sonar-scanner", "Sonar analysis is configured");
+  }
+  return found;
+}
+
+/**
+ * Everything already declared, by name, so proposals exclude them.
+ * @param {object|null} config Parsed .lisa.config.json.
+ * @returns {Set<string>} Declared tool names.
+ */
+export function declaredTools(config, surface = "remote") {
+  const tools = config?.remoteEnv?.tools ?? {};
+  const applies = tool => {
+    const surfaces = tool.surfaces;
+    if (!Array.isArray(surfaces) || surfaces.length === 0) return true;
+    return surfaces.includes(surface);
+  };
+  // Filtered by surface, because a declaration that applies somewhere else is
+  // not coverage here. A local-only `require` entry would otherwise suppress
+  // the proposal for a tool genuinely missing from the remote manifest — the
+  // detector reporting "already declared" about the one surface where it is
+  // not.
+  return new Set(
+    [...(tools.require ?? []), ...(tools.install ?? [])]
+      .filter(applies)
+      .map(tool => tool.name)
+  );
+}
+
+/**
+ * Collect every signal and subtract what the manifest already covers.
+ * @param {string} [cwd] Project root.
+ * @returns {Array<{name: string, why: string, evidence: string[]}>} Proposals.
+ */
+export function detectTooling(cwd = process.cwd()) {
+  const config = readJson(join(cwd, ".lisa.config.json"));
+  const pkg = readJson(join(cwd, "package.json"));
+  const mcp = readJson(join(cwd, ".mcp.json"));
+  const notes = readJson(join(cwd, ".lisa", "secret-notes.json"));
+
+  const declared = declaredTools(config);
+  const signals = [
+    toolsFromScripts(pkg),
+    toolsFromMcp(mcp),
+    toolsFromSecretNotes(notes),
+    toolsFromQuality(config),
+  ];
+
+  const merged = new Map();
+  for (const signal of signals) {
+    for (const [tool, evidence] of signal) {
+      if (declared.has(tool)) continue;
+      const entry = merged.get(tool) ?? { evidence: [] };
+      entry.evidence.push(evidence);
+      merged.set(tool, entry);
+    }
+  }
+
+  return [...merged.entries()]
+    .map(([name, entry]) => ({
+      name,
+      why: KNOWN_TOOLS[name]?.why ?? "",
+      evidence: entry.evidence,
+    }))
+    .sort((a, b) => a.name.localeCompare(b.name));
+}
+
+/**
+ * The manifest entries an operator can paste, with the parts only they supply.
+ *
+ * Returns both lists because a platform-specific archive needs both: an
+ * `install` entry for the surface it is built for, and a `require` entry so the
+ * other surface still asserts the tool instead of silently ignoring it.
+ * @param {{name: string}} proposal One detected tool.
+ * @returns {{install: object[], require: object[]}} Manifest skeletons.
+ */
+export function proposedEntries(proposal) {
+  const viaNpm = KNOWN_TOOLS[proposal.name]?.viaNpm;
+  if (viaNpm) {
+    // npm resolves per platform, so one entry serves every surface.
+    return {
+      install: [
+        {
+          name: proposal.name,
+          install: "npm-global",
+          package: viaNpm,
+          version: "<pin>",
+        },
+      ],
+      require: [],
+    };
+  }
+  // A release archive is built for one platform, so it is proposed as
+  // remote-install plus a local `require`. Proposing only the install entry
+  // produced a manifest that either offered a Linux binary to a laptop or —
+  // once narrowed to remote — stopped checking for the tool locally at all.
+  // Both halves or neither.
+  return {
+    install: [
+      {
+        name: proposal.name,
+        version: "<pin>",
+        install: "release-tar",
+        url: "<release url for this exact version, for the remote platform>",
+        sha256: "<sha256 published with that release>",
+        surfaces: ["remote"],
+      },
+    ],
+    require: [{ name: proposal.name, surfaces: ["local"] }],
+  };
+}
+
+if (process.argv[1] && import.meta.url === `file://${process.argv[1]}`) {
+  const proposals = detectTooling();
+  if (process.argv.includes("--json")) {
+    console.log(JSON.stringify(proposals, null, 2));
+  } else if (proposals.length === 0) {
+    console.log(
+      "Every tool this project appears to use is already declared in remoteEnv.tools."
+    );
+  } else {
+    console.log(
+      `${proposals.length} tool(s) look required but are not declared:\n`
+    );
+    for (const proposal of proposals) {
+      console.log(`  ${proposal.name}`);
+      console.log(`    why: ${proposal.why}`);
+      for (const evidence of proposal.evidence) {
+        console.log(`    evidence: ${evidence}`);
+      }
+      const entries = proposedEntries(proposal);
+      for (const entry of entries.install) {
+        console.log(`    tools.install: ${JSON.stringify(entry)}`);
+      }
+      for (const entry of entries.require) {
+        console.log(`    tools.require: ${JSON.stringify(entry)}`);
+      }
+      console.log("");
+    }
+    console.log(
+      "Nothing has been written or installed. Confirm each entry, supply the\n" +
+        "pin and checksum, and add it to remoteEnv.tools in .lisa.config.json."
+    );
+  }
+}

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

@@ -87,6 +87,14 @@ bash scripts/lisa-remote-env/session-start.sh   # guard; delegates to --phase=se
 
 The selection comes from the surface's `materializeAt` capability in `lisa-secrets-access`, not from its name, so adding a surface does not mean editing a branch. The hook is committed to the repository, so it also fires on a developer's machine — it exits `0` immediately there rather than failing, because a correct local session must not look broken.
 
+## Detect before you provision
+
+Run `/lisa:detect-tooling` first, every time. The manifest is the only thing that puts a binary on `PATH`, and nothing populates it — so a project ships npm scripts invoking `maestro`, wires an MCP server whose CLI it also shells out to, and configures Playwright thresholds, while `remoteEnv.tools` stays empty and each of those fails at the moment of use instead of at setup.
+
+This repository has paid for that twice: `gh` was declared nowhere and a cloud session could not commit anything; `tar` was needed by an install method and asserted by nothing.
+
+The detector proposes and a human decides. It writes nothing, so provisioning still only ever happens from a reviewed, pinned, checksummed entry.
+
 ## Toolchain manifest — two entry kinds
 
 ```json
@@ -165,9 +173,9 @@ Because `release-tar` unpacks with `tar` rather than `unzip`, a project using it
 - **Prefer what is there.** A second Node beside the image's creates PATH ambiguity and wastes container time.
 - **Pin and checksum together, in one reviewed commit.** A version bump that does not move the checksum fails before installation, not after. An archive is verified *before* it is unpacked, so unexpected contents never reach a directory on PATH.
 
-## Tooling is never derived from secret notes
+## Tooling is never *authorised* by secret notes
 
-Deliberately rejected:
+Deliberately rejected — notes may not cause an install:
 
 - Most tooling has **no credential** — `jq`, ripgrep, browsers, a linter — so notes could only ever cover a subset, and a second mechanism would be needed anyway.
 - Most credentials **imply no tool**: a webhook is curl'd, a REST key needs no CLI.
@@ -177,6 +185,14 @@ Deliberately rejected:
 
 **Notes are an assertion target instead.** At verify time, a tool that declares a credential which is not materialized is an **error**; a credential materialized with no declared consumer is a **warning**. The arrow points the safe way: the repository declares intent, and the provider is checked against it.
 
+### Reading a note as *evidence* is a different act
+
+`lisa-detect-tooling` does read notes, and this section is why it may. Every objection above is an objection to a note **causing** something: authorising an install, being the sole source, deciding a version. None of that changes.
+
+What the detector produces is a proposal with `<pin>`, `<release url>` and `<sha256>` left blank, printed for a human. It cannot install, cannot write config, and its output is inert until someone commits a pinned, checksummed entry that `assertPinned` then enforces. Provider write access therefore buys an attacker one line of text in a proposal a human reads — not arbitrary install access, which is the specific escalation this section exists to block.
+
+The other objections stay true and stay unfixed: most tooling has no credential and most credentials imply no tool, so notes are one signal among four and the weakest of them. They are read *after* npm scripts and MCP servers, and a note alone should be the least persuasive reason to add anything.
+
 ## Provisioning tiers
 
 Preference order, falling back:

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

@@ -221,8 +221,9 @@ function installTool(tool, binDir) {
  * @param {boolean} dryRun Whether to plan only.
  * @returns {Array<object>} The plan that was applied.
  */
-function applyToolchain(tools, dryRun) {
-  const plan = planToolchain(tools, probe);
+function applyToolchain(tools, dryRun, options = {}) {
+  const { surface = "remote", consent = true } = options;
+  const plan = planToolchain(tools, probe, surface);
   const blocked = plan.filter(
     p => p.action === "missing" || p.action === "invalid"
   );
@@ -234,6 +235,34 @@ function applyToolchain(tools, dryRun) {
   mkdirSync(binDir, { recursive: true, mode: 0o755 });
   const byName = new Map((tools.install ?? []).map(t => [t.name, t]));
 
+  // Installing is a different act on a laptop than in a container. A container
+  // is disposable and provisioning it silently is the whole point; a developer
+  // machine belongs to a person, and putting pinned binaries in their
+  // ~/.local/bin without being asked is not ours to decide. So the same
+  // manifest drives both, and only the consent differs.
+  //
+  // Reporting still happens either way — knowing the machine diverges from what
+  // the project declares is most of the value, and is what nothing did before.
+  if (!consent) {
+    const missing = plan.filter(step => step.action === "install");
+    if (missing.length === 0) {
+      console.log("  every declared tool is already present");
+      return plan;
+    }
+    console.log(
+      `  ${missing.length} declared tool(s) are missing or below their pin:`
+    );
+    for (const step of missing) {
+      const tool = byName.get(step.name);
+      console.log(`    ${step.name}${tool?.version ? ` ${tool.version}` : ""}`);
+    }
+    console.log(
+      "\n  Not installing without confirmation. Re-run with --install-tools\n" +
+        "  to provision them, or install them yourself."
+    );
+    return plan;
+  }
+
   // Installing a binary somewhere nothing looks is the same as not installing
   // it. `~/.local/bin` is on PATH by default on a developer workstation and is
   // NOT on a minimal container, so the toolchain step reported `install bws`,
@@ -526,6 +555,40 @@ export function emitClaudeWeb({ bootstrapKey }) {
   ].join("\n");
 }
 
+/**
+ * Report tooling the project appears to need but has not declared.
+ *
+ * Called before the toolchain is applied, because the manifest is the only
+ * thing that puts a binary on PATH and nothing populates it — so provisioning
+ * "the declared toolchain" happily succeeds while the tool a project actually
+ * uses is absent, and fails later at the moment of use instead of here.
+ *
+ * Informational, never blocking. The detector proposes and a human decides, so
+ * an undeclared tool must not stop a setup that was asked to provision what IS
+ * declared; failing here would make a advisory signal into a gate nobody chose.
+ * Its own absence is silent for the same reason: an older installed copy of the
+ * skills has no detector, and that is not a reason to refuse to provision.
+ * @param {Function} [exec] Seam for tests.
+ */
+function reportUndeclaredTooling(exec = execFileSync) {
+  let script;
+  try {
+    script = siblingScript("lisa-detect-tooling", "detect-tooling.mjs");
+  } catch {
+    return;
+  }
+  try {
+    const out = exec("node", [script], {
+      encoding: "utf8",
+      stdio: ["ignore", "pipe", "pipe"],
+    });
+    const text = String(out).trim();
+    if (text) console.log(`\n${text}\n`);
+  } catch {
+    // A detector that cannot run is a missing hint, not a failed setup.
+  }
+}
+
 /**
  * Decide which phases this invocation runs.
  *
@@ -640,8 +703,16 @@ async function main() {
   }
 
   if (phases.includes("toolchain")) {
+    reportUndeclaredTooling();
     console.log("Toolchain:");
-    applyToolchain(cfg.tools, dryRun);
+    // A remote container consents by construction: it is disposable, nobody is
+    // watching, and provisioning it is why the script exists. Locally the
+    // operator opts in per run.
+    const remote = Boolean(materializeAt);
+    applyToolchain(cfg.tools, dryRun, {
+      surface: remote ? "remote" : "local",
+      consent: remote || process.argv.includes("--install-tools"),
+    });
   }
 
   if (phases.includes("secrets")) {

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

@@ -124,18 +124,65 @@ function planInstallable(tool, found) {
   };
 }
 
+/** Surfaces a manifest entry may name. */
+const KNOWN_SURFACES = new Set(["local", "remote"]);
+
+/**
+ * Whether a manifest entry applies to the surface being provisioned.
+ *
+ * One declaration per tool, not one block per surface. Most tools a project
+ * needs are needed *everywhere* — a Maestro or Sonar CLI is as required on a
+ * laptop as in a container — and duplicated blocks drift, which this repository
+ * has paid for more than once. What actually differs between surfaces is the
+ * install method and, more importantly, consent: a disposable container may
+ * install silently, a developer's machine may not.
+ *
+ * Omitting `surfaces` means every surface, because that is true of most tools
+ * and the failure of forgetting it should be "checked somewhere unnecessary"
+ * rather than "silently absent where it was needed".
+ * @param {object} tool Manifest entry.
+ * @param {string} surface Surface being provisioned.
+ * @returns {boolean} Whether this entry applies.
+ */
+export function appliesToSurface(tool, surface) {
+  const surfaces = tool.surfaces;
+  if (surfaces === undefined) return true;
+  // A typo must not silently widen scope. Treating any non-array as "omitted"
+  // meant `surfaces: "remote"` — an easy thing to write — quietly applied the
+  // entry to every surface, which for a platform-specific archive means
+  // offering a Linux binary to a laptop. Absent means everywhere; malformed
+  // means stop.
+  if (!Array.isArray(surfaces)) {
+    throw new Error(
+      `${tool.name}: surfaces must be an array, got ${typeof surfaces}.\n` +
+        `Omit it to mean every surface; write ["remote"] or ["local"] to narrow.`
+    );
+  }
+  if (surfaces.length === 0) return true;
+  const unknown = surfaces.filter(entry => !KNOWN_SURFACES.has(entry));
+  if (unknown.length > 0) {
+    throw new Error(
+      `${tool.name}: unknown surface(s) ${unknown.join(", ")}.\n` +
+        `Known: ${[...KNOWN_SURFACES].join(", ")}.`
+    );
+  }
+  return surfaces.includes(surface);
+}
+
 /**
  * Produce the complete plan for a toolchain manifest.
  * @param {{require?: object[], install?: object[]}} tools Manifest.
  * @param {(name: string) => {version: string|null, present: boolean}} probe Version probe.
  * @returns {Array<{name: string, action: string, reason: string}>} Ordered decisions.
  */
-export function planToolchain(tools, probe) {
+export function planToolchain(tools, probe, surface = "remote") {
   const plan = [];
   for (const tool of tools.require ?? [])
-    plan.push(planRequired(tool, probe(tool.name)));
+    if (appliesToSurface(tool, surface))
+      plan.push(planRequired(tool, probe(tool.name)));
   for (const tool of tools.install ?? [])
-    plan.push(planInstallable(tool, probe(tool.name)));
+    if (appliesToSurface(tool, surface))
+      plan.push(planInstallable(tool, probe(tool.name)));
   return plan;
 }
 

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

@@ -34,10 +34,24 @@ 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="$repo_root/plugins/lisa/hooks/$guard.sh"
-  [ -f "$script" ] || continue
+  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