@codyswann/lisa 4.74.9 → 4.75.1

package/plugins/lisa-devin/skills/lisa-setup-remote-env/scripts/verify-remote-env.mjs

@@ -0,0 +1,250 @@
+#!/usr/bin/env node
+/**
+ * Prove a remote environment is actually configured the way it was meant to be.
+ *
+ * This runs identically whatever provisioned the environment — an API, a driven
+ * browser, or a human pasting emitted config. That is the point: trust comes
+ * from the read-back, not from the mechanism, so the weakest provisioning tier
+ * ends up as trustworthy as the strongest.
+ *
+ * Every assertion is made **without printing a value**. Presence, mode, and
+ * shape are all checkable without revealing content, and an environment proof
+ * that leaks the thing it is proving is not a proof worth having.
+ *
+ * One rule this encodes the hard way: never verify against a vendor's own UI.
+ * A dashboard counter reported zero tasks for an environment that had
+ * demonstrably completed one, because the underlying records carried no
+ * environment identifier. Assert against durable state instead.
+ *
+ * Usage:
+ *   verify-remote-env.mjs
+ * @module verify-remote-env
+ */
+
+import { fileURLToPath } from "node:url";
+import { existsSync, readFileSync, statSync, realpathSync } from "node:fs";
+import { join } from "node:path";
+
+import { probe, readRemoteEnvConfig } from "./setup-remote-env.mjs";
+import { planToolchain } from "./toolchain.mjs";
+
+import { boundedChildOutput } from "../../lisa-setup-workstation/scripts/bounded-child.mjs";
+
+/** Collected results, so every check runs before anything reports failure. */
+const results = [];
+
+/**
+ * Record one assertion.
+ * @param {boolean} ok Whether it held.
+ * @param {string} label What was checked.
+ * @param {string} [detail] Extra context, never a secret value.
+ */
+function check(ok, label, detail = "") {
+  results.push({ ok, label, detail });
+}
+
+/**
+ * Assert a path exists with an exact permission mode.
+ *
+ * The mode is the assertion, not merely existence. A world-readable secrets
+ * file is present and wrong, and "present" is what a weaker check would report.
+ * @param {string} path Filesystem path.
+ * @param {number} mode Expected permission bits.
+ * @param {string} label What this path is.
+ */
+function checkMode(path, mode, label) {
+  if (!existsSync(path)) {
+    check(false, label, "absent");
+    return;
+  }
+  const actual = statSync(path).mode & 0o777;
+  check(
+    actual === mode,
+    label,
+    actual === mode
+      ? `mode ${mode.toString(8)}`
+      : `mode ${actual.toString(8)}, expected ${mode.toString(8)}`
+  );
+}
+
+/**
+ * Run a sibling skill's script and capture its output.
+ * @param {string[]} args Node arguments.
+ * @returns {{ok: boolean, out: string}} Result.
+ */
+function node(args) {
+  try {
+    const out = boundedChildOutput("node", args, {
+      encoding: "utf8",
+      stdio: ["ignore", "pipe", "pipe"],
+    });
+    return { ok: true, out: out.trim() };
+  } catch (err) {
+    // KEPT: `ok: false` fails the check either way, and a killed child's
+    // `err.message` already reads "... ETIMEDOUT", so the timeout names
+    // itself. This is the shape the others are being moved toward.
+    return { ok: false, out: String(err.stderr ?? err.message).trim() };
+  }
+}
+
+/**
+ * Assert each declared tool is present at its pinned or minimum version.
+ *
+ * Delegates every decision to `planToolchain` rather than probing here. This
+ * function used to run its own loop, and the copy silently forgot `minVersion`:
+ * a `require` entry passed as long as the binary answered `--version` at all,
+ * so a container verified clean against a node older than the manifest
+ * demanded. The plan-side check rejected exactly what this one accepted.
+ *
+ * That is the same failure the note validators had before one shared module
+ * replaced them, and it recurs for the same reason — two implementations of one
+ * question cannot be kept in step by intention. There is now one.
+ * @param {object} tools Toolchain manifest.
+ */
+function verifyToolchain(tools) {
+  for (const step of planToolchain(tools, probe, "remote")) {
+    check(step.action === "present", `tool ${step.name}`, step.reason);
+  }
+}
+
+/**
+ * Assert that a declared credential is genuinely readable, not a proxy stand-in.
+ *
+ * A surface may keep a credential outside the sandbox entirely and substitute
+ * the real value at egress. The variable is then present and non-empty, so a
+ * presence check passes — and a script that reads the variable and puts it in a
+ * header sends the placeholder and fails somewhere far from here, with an error
+ * that points at the service rather than at the environment.
+ *
+ * Reported without printing any value: the placeholder is compared, and a real
+ * credential is only ever reported as present.
+ *
+ * Takes its reporter as an argument rather than writing to this module's
+ * results array, so the rule can be exercised against a synthetic environment
+ * without a container and without leaking findings between runs.
+ * @param {string[]} required Declared credential names.
+ * @param {Record<string, string|undefined>} env Environment to inspect.
+ * @param {(ok: boolean, label: string, detail: string) => void} report Collector.
+ */
+export function verifyNotProxied(required, env, report) {
+  for (const name of required) {
+    const value = (env[name] ?? "").trim();
+    if (!value) {
+      report(false, `credential ${name}`, "declared but not present");
+      continue;
+    }
+    report(
+      value !== "proxy-injected",
+      `credential ${name}`,
+      value === "proxy-injected"
+        ? 'reads as "proxy-injected" — substituted at egress, so anything ' +
+            "reading this variable directly receives the placeholder"
+        : "present"
+    );
+  }
+}
+
+/**
+ * Assert the working tree is clean.
+ *
+ * A remote environment that starts dirty will carry unrelated changes into
+ * whatever it produces, and the resulting diff is no longer attributable to the
+ * task that ran.
+ */
+function verifyCleanCheckout() {
+  try {
+    const out = boundedChildOutput("git", ["status", "--porcelain"], {
+      encoding: "utf8",
+      stdio: ["ignore", "pipe", "ignore"],
+    });
+    check(
+      out.trim() === "",
+      "clean checkout",
+      out.trim() ? "working tree is dirty" : ""
+    );
+  } catch {
+    check(false, "clean checkout", "not a git repository");
+  }
+}
+
+/**
+ * Read the credential names the project declares it needs.
+ * @param {string} [cwd] Repository root.
+ * @returns {string[]} Declared names, or none when unconfigured.
+ */
+function readRequired(cwd = process.cwd()) {
+  const path = join(cwd, ".lisa.config.json");
+  if (!existsSync(path)) return [];
+  const required = JSON.parse(readFileSync(path, "utf8")).secrets?.require;
+  if (required == null) return [];
+  if (!Array.isArray(required)) {
+    throw new Error("secrets.require must be an array when present");
+  }
+  return required;
+}
+
+function main() {
+  const cfg = readRemoteEnvConfig();
+  const secretsDir = process.argv[2];
+
+  verifyToolchain(cfg.tools);
+  verifyNotProxied(readRequired(), process.env, check);
+
+  const surface = node([
+    new URL(
+      "../../lisa-secrets-access/scripts/resolve-secret.mjs",
+      import.meta.url
+    ).pathname,
+    "surface",
+  ]);
+  check(surface.ok, "surface detected", surface.out);
+
+  if (secretsDir) {
+    checkMode(secretsDir, 0o700, "secrets directory");
+    checkMode(`${secretsDir}/secrets.env`, 0o600, "values file");
+    checkMode(`${secretsDir}/secret-notes.json`, 0o600, "notes file");
+  }
+
+  verifyCleanCheckout();
+
+  let failed = 0;
+  for (const r of results) {
+    if (!r.ok) failed += 1;
+    console.log(
+      `  ${r.ok ? "ok  " : "FAIL"} ${r.label.padEnd(28)} ${r.detail}`
+    );
+  }
+  if (failed) throw new Error(`${failed} environment check(s) failed`);
+  console.log("\nRemote environment verified without revealing any value.");
+}
+
+/**
+ * Whether this module is the one node was asked to run.
+ *
+ * Both sides are realpath'd: a raw URL comparison answers "no" through a
+ * symlinked checkout, a git worktree, or a /tmp path on macOS, so the module
+ * loads, runs nothing and exits 0 — a silent no-op that reads as success.
+ *
+ * A local copy rather than an import: plugin payload scripts ship standalone,
+ * with no `lib/` sibling to import from once installed.
+ * @param {string} moduleUrl - The caller's own `import.meta.url`.
+ * @param {string | undefined} [argv1] - Entry path; defaults to `process.argv[1]`.
+ * @returns {boolean} Whether the caller should run its CLI body.
+ */
+function invokedAsScript(moduleUrl, argv1 = process.argv[1]) {
+  if (!argv1) return false;
+  try {
+    return realpathSync(argv1) === realpathSync(fileURLToPath(moduleUrl));
+  } catch {
+    return false;
+  }
+}
+
+if (invokedAsScript(import.meta.url)) {
+  try {
+    main();
+  } catch (err) {
+    console.error(err.message);
+    process.exit(1);
+  }
+}

package/plugins/lisa-devin/skills/lisa-setup-sonar/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: lisa-setup-sonar
+description: "Configure the official SonarQube plugin + MCP as Lisa's single Sonar substrate across every supported coding agent. Installs/updates the SonarQube CLI, authenticates (browser login on a dev machine, or SONARQUBE_CLI_TOKEN headless), selects the Test Manager target, runs `sonar integrate <agent>` for each supported agent (Claude, Codex, Cursor, Copilot, Antigravity) and wires the MCP for OpenCode, then writes only non-secret policy to .lisa.config.json. Separate from the CI SonarCloud scan gate, which is unchanged."
+allowed-tools: ["Bash", "Read", "Write", "Edit", "AskUserQuestion", "Skill"]
+---
+
+# Set up SonarQube (official plugin + MCP)
+
+This is an explicit exterior setup gate. Run it **outside** any active Build, QA,
+Monitor, or Verify factory — authentication and MCP wiring must be complete before
+unattended factories run. It replaces Lisa's former hand-rolled SonarCloud REST
+access with the vendor's official token-authed MCP, which is Lisa's single Sonar
+substrate on both developer machines and headless cloud routines.
+
+This does **not** touch the CI static-security job in `quality.yml` or its
+`SONAR_TOKEN` secret — that enforcement gate is separate and stays as-is.
+
+## Supported agents
+
+Wire only Lisa's supported agents: **Claude Code, Codex, Cursor, GitHub Copilot,
+Antigravity (agy)** via `sonar integrate <agent>`, and **OpenCode** via its MCP
+config. **Never** wire Kiro or Gemini CLI even though the vendor supports them —
+they are not Lisa-supported agents.
+
+## 1. Install or update the SonarQube CLI
+
+Check `sonar` on PATH (`command -v sonar`). If present, update it (`sonar
+self-update`, or the package manager that owns it); if absent, install it and ask
+for confirmation before running the install:
+
+```bash
+# macOS/Linux (script) — default, works everywhere
+curl -o- https://raw.githubusercontent.com/SonarSource/sonarqube-cli/refs/heads/master/user-scripts/install.sh | bash
+# or Homebrew: brew install --cask sonarqube-cli
+# or mise:     mise use -g aqua:SonarSource/sonarqube-cli
+```
+
+A container runtime (Docker/Podman/Nerdctl) must be installed and running — the
+MCP runs as a container via `sonar run mcp`. Probe with `docker ps` (falling back
+to `podman ps` / `nerdctl ps`). If none succeed, tell the operator to start it and
+note the agent session must restart afterward for the MCP tools to load.
+
+## 2. Authenticate — token for factories, login for dev machines
+
+The MCP authenticates from environment variables — this is the headless path and
+the one factories use. **Never** write credentials to `.lisa.config.json` or
+`.lisa.config.local.json`; provide them as environment variables / CI secrets:
+
+- `SONARQUBE_CLI_TOKEN` — required.
+- `SONARQUBE_CLI_ORG` — for SonarQube Cloud.
+- `SONARQUBE_CLI_SERVER` — for a self-hosted SonarQube Server.
+
+On an interactive developer machine you may instead run `sonar auth login`
+(browser flow; token stored in the OS keychain). Do **not** use the keychain flow
+for headless/cloud-routine environments — provision the env token there instead
+(see `/lisa:generate-claude-remote-build-script`, which now installs the CLI,
+pre-pulls the MCP image, and sets `SONARQUBE_CLI_TOKEN`). Verify with `sonar auth
+status`; record the identity label only, never token material.
+
+## 3. Select the Test Manager target
+
+Use `sonar config project` (and optional `sonar config folder`), then `sonar
+config show`. Capture the non-secret project/organization identifiers.
+
+## 4. Integrate per supported agent
+
+Confirm the target scope (single-choice: current project / global), then for each
+supported agent detected on PATH run its non-interactive integrate:
+
+```bash
+sonar integrate claude       --non-interactive
+sonar integrate codex        --non-interactive
+sonar integrate cursor       --non-interactive
+sonar integrate copilot      --non-interactive
+sonar integrate antigravity  --non-interactive
+```
+
+For **OpenCode** (no vendor integrate path), wire the MCP through OpenCode's own
+MCP config so it launches `sonar run mcp`, authenticated from the same env token.
+
+Skip any agent whose CLI is not installed; never wire Kiro or Gemini.
+
+## 4a. Patch the generated shims — required, not optional
+
+Each integrate writes a five-line shim that pipes the hook payload to `sonar hook
+<event>` and passes the verdict through unchanged. That makes an
+**unauthenticated CLI refuse every prompt and every file read**, with a reason
+string that reads exactly like a real finding:
+
+```text
+SonarQube secret scanning is inactive: not authenticated. Run 'sonar auth login'.
+```
+
+The operator most likely to hit it is the one who just installed the CLI and has
+not logged in — so their very first prompt is rejected, before the session can
+say anything useful. Repoint every generated shim at Lisa's wrapper, which keeps
+real findings blocking, resolves `SONARQUBE_CLI_TOKEN` through
+`lisa-secrets-access` when the CLI reports it has none, and degrades the
+still-unauthenticated case to a warning:
+
+```bash
+if ! command -v sonar &> /dev/null; then
+  exit 0
+fi
+here="$(cd -- "$(dirname -- "$0")" && pwd)"
+exec bash "${here}/<relative-path>/scripts/lisa-hooks/sonar-secrets.sh" <vendor-event>
+```
+
+One wrapper serves every surface — it takes the vendor event name as its only
+argument. Known shim locations and their events:
+
+| Agent | Shim | Event |
+| --- | --- | --- |
+| Claude | `.claude/hooks/sonar-secrets/build-scripts/prompt-secrets.sh` | `claude-prompt-submit` |
+| Claude | `.claude/hooks/sonar-secrets/build-scripts/pretool-secrets.sh` | `claude-pre-tool-use` |
+| Codex | `.codex/hooks/sonar-secrets/build-scripts/prompt-secrets.sh` | `codex-prompt-submit` |
+| Copilot | `.github/hooks/sonar-secrets/build-scripts/pretool-secrets.sh` | `copilot-pre-tool-use` |
+| Antigravity | `.agents/sonar/hooks/pretool-secrets.sh` | `antigravity-pre-tool-use` |
+
+Compute the relative path from each shim's own directory rather than assuming a
+depth — Antigravity's is three levels up, the rest are four.
+
+**Re-running an integrate overwrites the shim with the vendor's original**, so
+re-apply this patch whenever you re-run step 4, and say so in the summary. Leave
+a comment at the top of each patched shim naming the wrapper, so the next reader
+does not mistake the delegation for drift.
+
+## 5. Write non-secret policy config
+
+Merge only non-secret identifiers into committed `.lisa.config.json`, preserving
+every unrelated key (never credentials):
+
+```json
+{
+  "verification": {
+    "sonar": {
+      "enabled": true,
+      "edition": "cloud",
+      "organization": "<org-key>",
+      "projectKey": "<project-key>"
+    }
+  }
+}
+```
+
+Use `"edition": "server"` with a `"serverUrl"` for a self-hosted Server.
+
+## 6. Prove readiness
+
+Run the `lisa-sonarcloud-access` probe (an `mcp__sonarqube__*` project search) and
+confirm a `mcp__sonarqube__*` tool answers. Then run `lisa doctor` and confirm the
+Sonar provider check is green. If the MCP tools do not appear, verify the container
+runtime is running and restart the agent session.

package/plugins/lisa-devin/skills/lisa-setup-workstation/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: lisa-setup-workstation
+description: "Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything."
+allowed-tools: ["Bash", "Read", "Skill"]
+---
+
+# Setup Workstation: $ARGUMENTS
+
+Get a machine ready to run agents. No checkout required.
+
+## Why this exists separately
+
+`lisa-setup-local-env` reads `remoteEnv.tools` — a **project's** declared toolchain — so it
+needs a checkout to exist before it can answer anything. That leaves a gap at the start:
+a bare laptop or an empty container has no repository yet, and therefore nothing to ask.
+
+This skill fills that gap and stops there. It describes a **machine**, never a project:
+
+```text
+workstation  ->  git clone  ->  lisa-detect-tooling  ->  lisa-setup-local-env
+```
+
+Project-scoped tools stay in `remoteEnv.tools` where they belong. Nothing here reads a
+repository, and nothing here duplicates that manifest.
+
+## Usage
+
+**Start here — this is the entry point that presumes nothing:**
+
+```sh
+npx -y @codyswann/lisa@latest workstation             # report what is present and missing
+npx -y @codyswann/lisa@latest workstation --install   # install what is missing
+```
+
+That form needs only Node. No checkout, no agent, no Lisa install — npx resolves
+the package into its own cache.
+
+**Why it matters:** this skill exists to prepare a machine with *no coding agent*
+and *no checkout*. But a skill can only be invoked by typing a slash command into
+an agent, and Lisa ships as a devDependency, so it does not exist until a repo is
+cloned and its dependencies installed. Both are exactly the state this is meant to
+create — so as a skill alone, the bootstrap was unreachable in the one scenario it
+was designed for. The CLI is the way in; the skill is the surface for people who
+already have an agent.
+
+Every flag is the same either way:
+
+```sh
+lisa workstation --install --agents=claude,codex   # only these agents
+lisa workstation --provider=bitwarden              # credential manager (asked if a TTY)
+lisa workstation --json                            # machine-readable plan
+lisa workstation --print-dockerfile                # an image that runs this same script
+```
+
+Inside an agent, `/lisa:setup:workstation` runs the identical script; and the
+script itself is directly runnable as `node scripts/cli.mjs …`.
+
+Nothing is installed or written without `--install`. Exit status is non-zero when a required
+tool is absent or an install fails, so this is usable as a gate.
+
+## Ephemerality is not a mode
+
+There is no Docker branch anywhere in this skill. A container gets a throwaway `$HOME` and
+dies with it; a laptop keeps its own. Same code path either way — so the rarely-run one
+cannot rot, which is the failure mode a second install path eventually always has.
+
+`--print-dockerfile` emits an image rather than shipping a committed one, so the image cannot
+drift from the catalogue it provisions. It deliberately bakes in **no repository**: clone
+inside the container, then run `lisa-detect-tooling` and `lisa-setup-local-env` for that
+project's own tools.
+
+```sh
+node scripts/cli.mjs --print-dockerfile --agents=claude,codex --provider=bitwarden > Dockerfile
+docker build -t lisa-workstation . && docker run --rm -it lisa-workstation
+```
+
+## Already-installed wins, however it got there
+
+A tool present by **any** means is reported and left alone. That dissolves the "Homebrew or
+`~/.local/bin`" question entirely: we never contend for ownership of a tool someone else's
+package manager installed, and never shadow it with an earlier PATH entry that would silently
+win over their upgrades. The report names where each tool came from so the operator can see
+why it was skipped.
+
+Running twice installs nothing the second time, and says so rather than going quiet — silence
+reads as "did nothing because it broke".
+
+## Install method is a per-tool property, not a global policy
+
+The obvious design — put every binary in `~/.local/bin` so one code path serves a laptop and a
+container alike — is wrong, and the agents show why:
+
+```text
+claude        -> ~/.local/share/claude/versions/2.1.221
+cursor-agent  -> ~/.local/share/cursor-agent/versions/2026.07.16-899851b
+codex         -> ~/.codex/packages/standalone/current/bin/codex
+```
+
+Each vendor manages its own version directory, and `~/.local/bin` holds only a **symlink**.
+Writing a raw binary there breaks the vendor's self-updater, which expects to swap a link
+target and would instead find a real file in its way.
+
+So each catalogue entry declares its own method, and the honest cost is recorded with it:
+
+| kind | pinned | checksummed | notes |
+| --- | --- | --- | --- |
+| `release-zip` / `release-tar` | yes | yes | reuses the remote-env installer |
+| `npm-global` | no | no | vendor registry |
+| `vendor-script` | no | no | pipes a fetched script to a shell |
+| `manual` | n/a | n/a | no headless installer published |
+| `required` | n/a | n/a | expected from the OS or base image |
+
+`vendor-script` is a real weakening of the guarantee `assertPinned` exists to provide, so the
+report **names every unchecksummed install** rather than blending them in. Installing them
+trusts the vendor's script at fetch time. The alternative — repackaging vendor binaries
+ourselves — would break the self-updaters that own those directories.
+
+## The credential manager is asked, never assumed
+
+`lisa-secrets-access` already treats the provider as an axis: Bitwarden, 1Password, Doppler,
+Vault, AWS, or plain environment variables. A bootstrap that installed `bws` unconditionally
+would contradict that — pushing every workstation onto one vendor and quietly making the
+others second-class.
+
+So the provider is a question, `none` is a first-class answer, and only the selected one is
+installed. Installing all of them would leave four unused credential CLIs on the machine,
+each an extra thing to keep patched for no benefit.
+
+Headless is the primary mode, so with no TTY and no `--provider`, the answer is `none` — not
+a prompt that would hang a container build forever. A misspelled provider stops the run
+instead of falling back, because quietly provisioning the wrong credential manager is worse
+than stopping.
+
+## What it will not do
+
+- **Read a repository.** That is the next step, not this one.
+- **Install a credential manager you did not pick.**
+- **Reinstall over a tool that is already there**, whatever installed it.
+- **Install anything without `--install`.**
+- **Install a tool whose vendor publishes no headless installer.** Such an entry is
+  reported as manual with a pointer, because "not installed" and "cannot be installed by
+  this tool" are different answers to the operator. No agent is currently in that state —
+  Antigravity was listed there in error and does publish a bootstrapper.