@codyswann/lisa 2.330.1 → 2.331.0

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "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.330.1",
+  "version": "2.331.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -563,7 +563,8 @@ export function proposedEntries(proposal) {
   // the checksum cannot vouch for, which is the one property that makes a
   // pinned entry worth reviewing.
   const archive = platform => ({
-    install: "<release-tar or release-zip, whichever this platform ships>",
+    install:
+      "<release-tar | release-zip | release-tree — tree when the archive is a directory whose entry point loads its own siblings>",
     url: `<release url for this exact version, for ${platform}>`,
     sha256: `<sha256 published with the ${platform} release>`,
   });

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

@@ -165,16 +165,28 @@ by platform. Before that existed, the only way to keep a Linux binary off a lapt
 
 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
+### The four `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`. |
+| `release-tree` | `url`, `sha256` **and** `binary` | The archive is a **directory**, not a single binary — an entry point that resolves its own siblings at run time. |
 | `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.
 
+**`release-tree` exists because the single-file kinds fail silently on a tree.** They extract the archive and copy *one* file onto PATH, which is right for a static binary and wrong for anything that locates its own resources. Maestro is the case that forced it — one 314 MB zip containing:
+
+```text
+maestro/bin/maestro     <- launcher
+maestro/lib/*.jar       <- 100+ MB of classpath
+```
+
+and a launcher that computes `CLASSPATH=$APP_HOME/lib/*` where `APP_HOME` is the parent of wherever the script itself sits. Declared as `release-zip` with `binary: maestro/bin/maestro`, the launcher lands in `~/.local/bin`, `APP_HOME` resolves to `~/.local`, and the classpath points at an empty directory. **The install reports success and the tool dies at first use** with `Could not find or load main class` — exactly the failure this manifest exists to turn into a loud setup error.
+
+So `release-tree` extracts the whole archive to `~/.local/share/<name>/<version>` and puts a **wrapper** on PATH that `exec`s the entry point in place. Not a copy, and deliberately not a symlink either: a launcher that does not resolve symlinks before computing its own location would read the link's directory as its home and look for its resources beside the link — the same broken install, narrowed to a subset of tools. `binary` has no default here, because the archive root is a directory and guessing would install a directory as a binary.
+
 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`.

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

@@ -212,6 +212,94 @@ function installReleaseTar(tool, binDir) {
   }
 }
 
+/**
+ * Where a tree-shaped tool's extracted contents live.
+ *
+ * Versioned so a re-pin lands beside the old copy rather than on top of it, and
+ * outside `binDir` because only the entry point belongs on PATH.
+ * @param {object} tool Manifest entry.
+ * @param {string} binDir Directory holding the symlink.
+ * @returns {string} Absolute prefix for this tool and version.
+ */
+export function treePrefix(tool, binDir) {
+  return join(binDir, "..", "share", tool.name, String(tool.version));
+}
+
+/**
+ * Install a pinned archive that is a DIRECTORY, not a single binary.
+ *
+ * `release-zip` and `release-tar` extract and then copy one file onto PATH,
+ * which is right for a static binary and silently wrong for anything that
+ * resolves its own siblings at run time. Maestro is the case that forced this:
+ *
+ *     maestro/bin/maestro   <- launcher
+ *     maestro/lib/*.jar     <- 100+ MB of classpath
+ *
+ * and the launcher computes `CLASSPATH=$APP_HOME/lib/*` where `APP_HOME` is the
+ * parent of wherever the script itself sits. Copy that launcher to
+ * `~/.local/bin` and APP_HOME becomes `~/.local`, so the classpath resolves to
+ * an empty directory. The install reports success and the tool fails at first
+ * use — the failure this manifest exists to turn into a loud setup error.
+ *
+ * So the whole tree is extracted and the entry point is SYMLINKED. A symlink,
+ * not a copy, precisely so that resolution walks back into the extracted tree.
+ * @param {object} tool Manifest entry.
+ * @param {string} binDir Directory to link the entry point into.
+ */
+function installReleaseTree(tool, binDir) {
+  const temporary = join(binDir, `.${tool.name}-download`);
+  const prefix = treePrefix(tool, binDir);
+  mkdirSync(temporary, { recursive: true });
+  try {
+    const archive = join(temporary, "download.archive");
+    execFileSync("curl", ["-fsSL", tool.url, "-o", archive], {
+      stdio: "inherit",
+    });
+    // Verify before unpacking, as everywhere else here: an unexpected archive
+    // must fail before any of its contents reach the filesystem.
+    verifyChecksum(archive, tool.sha256, tool.name);
+
+    // Replace rather than layer. Extracting over a previous version leaves both
+    // sets of jars on the classpath, which fails in a way that looks like a
+    // version bug rather than a stale install.
+    rmSync(prefix, { recursive: true, force: true });
+    mkdirSync(prefix, { recursive: true });
+    if (tool.url.endsWith(".zip")) {
+      execFileSync("unzip", ["-q", "-o", archive, "-d", prefix], {
+        stdio: "inherit",
+      });
+    } else {
+      execFileSync("tar", ["-xzf", archive, "-C", prefix], {
+        stdio: "inherit",
+      });
+    }
+
+    const entry = join(prefix, tool.binary);
+    if (!existsSync(entry)) {
+      throw new Error(
+        `${tool.name}: "binary" points at ${tool.binary}, which is not in the ` +
+          `archive.\nList the archive and use the path to the entry point ` +
+          `inside it, such as "maestro/bin/maestro".`
+      );
+    }
+    chmodSync(entry, 0o755);
+
+    // A WRAPPER, not a symlink. Both keep the tree intact, but a symlink only
+    // works for launchers that resolve symlinks before computing their own
+    // location — gradle's template does, and plenty of others do not. One that
+    // does not sees the link's directory as its home and looks for its
+    // classpath beside the link instead of beside itself, which is the same
+    // broken install this kind exists to prevent, reintroduced for a subset of
+    // tools. Exec'ing the absolute path removes the assumption entirely.
+    const shim = join(binDir, tool.name);
+    rmSync(shim, { force: true });
+    writeFileSync(shim, `#!/bin/sh\nexec ${JSON.stringify(entry)} "$@"\n`);
+    chmodSync(shim, 0o755);
+  } finally {
+    rmSync(temporary, { recursive: true, force: true });
+  }
+}
+
 /**
  * Install a pinned global npm package.
  * @param {object} tool Manifest entry.
@@ -239,6 +327,7 @@ export function installTool(tool, binDir) {
   assertPinned(tool);
   if (tool.install === "release-zip") installReleaseZip(tool, binDir);
   else if (tool.install === "release-tar") installReleaseTar(tool, binDir);
+  else if (tool.install === "release-tree") installReleaseTree(tool, binDir);
   else installNpmGlobal(tool);
 }
 

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

@@ -334,6 +334,26 @@ export function assertPinned(tool) {
     }
     return;
   }
+  // A tree carries the same checksum obligation and one more: which file inside
+  // it is the entry point. There is no sane default — the archive root is a
+  // directory, so guessing would install a directory as a binary.
+  if (tool.install === "release-tree") {
+    if (!tool.url || !tool.sha256) {
+      throw new Error(
+        `${tool.name}: a release-tree install needs both url and sha256.\n` +
+          `A version bump must move the checksum in the same reviewed commit.`
+      );
+    }
+    if (!tool.binary) {
+      throw new Error(
+        `${tool.name}: a release-tree install needs "binary" — the path to the ` +
+          `entry point INSIDE the archive, such as "maestro/bin/maestro".\n` +
+          `Unlike the single-file kinds there is nothing to fall back to: the ` +
+          `archive root is a directory.`
+      );
+    }
+    return;
+  }
   if (tool.install === "npm-global") {
     if (!tool.package)
       throw new Error(`${tool.name}: npm-global install needs a package`);
@@ -341,6 +361,6 @@ export function assertPinned(tool) {
   }
   throw new Error(
     `${tool.name}: unknown install method "${tool.install}".\n` +
-      `Supported: release-zip, release-tar, npm-global.`
+      `Supported: release-zip, release-tar, release-tree, npm-global.`
   );
 }