@codyswann/lisa 2.324.0 → 2.325.0

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.324.0",
+  "version": "2.325.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.324.0",
+  "version": "2.325.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.324.0",
+  "version": "2.325.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.324.0",
+  "version": "2.325.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.324.0",
+  "version": "2.325.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.324.0",
+  "version": "2.325.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/commands/lisa/detect-tooling.md

@@ -0,0 +1,7 @@
+---
+description: "Find the command-line tools this project needs but never declares, and propose pinned manifest entries for them. Reads npm scripts, MCP servers, credential usage notes and quality configuration, subtracts what remoteEnv.tools already covers, and prints proposals with evidence. Writes nothing and installs nothing — a tool reaches a machine only once a human has reviewed a pinned, checksummed entry."
+allowed-tools: ["Skill"]
+argument-hint: "[--json]"
+---
+
+Use the /lisa-detect-tooling skill to find undeclared command-line tooling and propose manifest entries for it. $ARGUMENTS

package/plugins/lisa-copilot/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/lisa-copilot/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/lisa-copilot/skills/lisa-detect-tooling/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: lisa-detect-tooling
+description: "Find the command-line tools a project needs but never declares, and propose pinned manifest entries for them. Reads npm scripts, MCP servers, credential usage notes and quality configuration, subtracts whatever remoteEnv.tools already covers, and prints proposals with evidence. Writes nothing and installs nothing — a tool reaches a machine only when a human has reviewed a pinned, checksummed entry. Invoked by lisa-setup-remote-env before provisioning, and runnable on its own."
+allowed-tools: ["Bash", "Read", "AskUserQuestion"]
+---
+
+# Detect Tooling
+
+Lisa provisions tooling through four unrelated mechanisms, and only one of them puts a binary on `PATH`:
+
+| tool | how it arrives | what puts it on PATH |
+| --- | --- | --- |
+| playwright, stryker | npm devDependency from a stack template | nothing — a local `node_modules` binary |
+| maestro | npm **scripts** in the Expo template | **nothing** |
+| sonar | `src/sonar/sonar-installer.ts` | nothing |
+| linear | MCP server | nothing, and it needs browser OAuth |
+| bws, gh | `remoteEnv.tools` — pinned and checksummed | this, and only this |
+
+Nothing populates that last row. So a project can ship scripts that invoke `maestro`, wire an MCP server whose CLI it also shells out to, and configure Playwright 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.
+
+That is the same failure this repository has now paid for twice: `gh` was declared nowhere and a cloud session could not commit; `tar` was needed by an install method and asserted by nothing.
+
+## What it does
+
+Reads four signals, subtracts what `remoteEnv.tools` already declares, and prints what is left with the evidence for each:
+
+- **npm scripts** that invoke a binary. The strongest signal there is — a script running `maestro test` is the project stating a dependency in executable form. Matched on the script *body*, not its name, because the name is a label.
+- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one.
+- **Credential usage notes.** A note explaining what a token is for usually names the program that consumes it. `lisa-secrets-access` already exposes these without touching a value, which makes them a first-class input rather than a trick.
+- **Quality configuration**, where a threshold implies the tool that produces it.
+
+## What it will not do
+
+**It writes nothing and installs nothing.** Output is a proposal with `<pin>`, `<release url>` and `<sha256>` left for a human.
+
+That boundary is the whole design. A tool should reach a machine because someone reviewed a pinned entry with a checksum, never because a detector was confident. Detection is evidence; the manifest is the decision. An auto-writing detector would quietly become a second, unreviewed install path — exactly what `assertPinned` exists to prevent.
+
+## Surfaces
+
+One declaration per tool, with an optional `surfaces` list, rather than separate blocks per surface. Most tools are needed *everywhere* — a Maestro or Sonar CLI is as required on a laptop as in a container — and duplicated blocks drift.
+
+What genuinely differs is **consent**, not the list:
+
+- A remote container is disposable and nobody is watching, so it provisions silently.
+- A developer machine belongs to a person, so `--phase=toolchain` reports what is missing and installs nothing unless `--install-tools` is passed.
+
+Omitting `surfaces` means every surface, because that is true of most tools and the cost of forgetting should be a redundant check rather than a silent absence.
+
+A platform-specific pin is the exception worth knowing: a Linux release archive must be `surfaces: ["remote"]`, with a matching `require` entry for `local`, so a laptop asserts the tool without being offered a binary it cannot run.
+
+## Usage
+
+```sh
+node scripts/detect-tooling.mjs          # human-readable proposals
+node scripts/detect-tooling.mjs --json   # machine-readable
+```
+
+Confirm each proposal with the operator, then hand it to them to apply. **This skill does not hold `Edit`**, deliberately: a skill that both decides a tool is needed and writes the entry that installs it is the second unreviewed install path this design exists to avoid. Granting `Edit` while documenting "writes nothing" would have made the prose the only thing stopping it.
+
+When a proposal is wrong — the tool is genuinely unused, or arrives another way — say so and move on. A rejected proposal is a normal outcome, not a failure.

package/plugins/lisa-copilot/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/lisa-copilot/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/lisa-copilot/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")) {