@codyswann/lisa 2.322.1 → 2.322.2

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.322.1",
+  "version": "2.322.2",
   "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.322.1",
+  "version": "2.322.2",
   "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.322.1",
+  "version": "2.322.2",
   "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.322.1",
+  "version": "2.322.2",
   "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.322.1",
+  "version": "2.322.2",
   "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.322.1",
+  "version": "2.322.2",
   "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.322.1",
+  "version": "2.322.2",
   "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-setup-remote-env/scripts/setup-remote-env.mjs

@@ -299,18 +299,29 @@ export function installAssets(cwd = process.cwd()) {
 }
 
 /**
- * The setup field, identical for every project.
+ * The setup field, identical for every project and every surface.
  *
- * Names neither the repository nor its package manager. Claude Code web runs
- * this field from `$HOME` while the checkout sits one level down, so the glob
- * locates the script; the script then anchors itself on the repository root and
- * installs dependencies from whichever lockfile the project commits.
+ * Names neither the repository nor its package manager, and deliberately not
+ * `$HOME` either: the surfaces disagree about where the field runs. Codex Cloud
+ * runs it inside the checkout, Claude Code web runs it from `$HOME` with the
+ * checkout one level down, and on Codex Cloud the checkout is not under `$HOME`
+ * at all — so a `$HOME` glob matched nothing there and bash was handed a path
+ * still containing a literal asterisk.
  *
- * A field that named both was a string a human had to get right, in a settings
- * box with no review, no version history and no test — and the logic it encoded
- * belongs in a file that has all three.
+ * Both candidates are therefore tried relative to cwd. `exec` on the first hit
+ * avoids a subshell and avoids parsing `ls`; the explicit `exit 1` means a
+ * missing entrypoint says so rather than the field quietly succeeding. The
+ * script then anchors itself on the repository root and installs dependencies
+ * from whichever lockfile the project commits.
+ *
+ * A field that named the repository and package manager was a string a human
+ * had to get right, in a settings box with no review, no version history and no
+ * test — and the logic it encoded belongs in a file that has all three.
  */
-const SETUP_FIELD = `bash "$HOME"/*/scripts/lisa-remote-env/setup.sh`;
+export const SETUP_FIELD =
+  "for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; " +
+  'do [ -f "$f" ] && exec bash "$f"; done; ' +
+  'echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1';
 
 /**
  * The settings block that wires the session-start hook into a repository.

package/scripts/lisa-remote-env/setup.sh

@@ -13,9 +13,21 @@
 # and emphatically not in a vendor settings field.
 set -euo pipefail
 
+# Claude Code web runs the environment setup field from $HOME, while the
+# checkout lives at $HOME/<repo>. If this installed copy is invoked by absolute
+# path, move back to the repository root before resolving project-local files.
+script_dir="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd -P)"
+case "$script_dir" in
+  */scripts/lisa-remote-env)
+    cd "$script_dir/../.."
+    ;;
+esac
+
 # Node is the one thing that cannot be installed by the installer, since the
-# installer is written in it. Fail with an actionable message rather than a
-# "command not found" forty lines deep.
+# installer is written in it. Checked before the dependency install rather than
+# after: every package manager below is itself a node program, so a missing node
+# would otherwise surface as that manager failing under `set -e`, and the script
+# would exit on a confusing error instead of this actionable one.
 if ! command -v node >/dev/null 2>&1; then
   echo "node is required to prepare this environment but is not present." >&2
   echo "It cannot be installed by the toolchain step, because that step runs" >&2
@@ -23,6 +35,62 @@ if ! command -v node >/dev/null 2>&1; then
   exit 1
 fi
 
+# Install the project's dependencies, unless the caller already did.
+#
+# This lives here rather than in the vendor's settings field so that field can
+# be one identical line for every project. Naming the package manager there
+# meant a Claude environment for an npm project and one for a bun project
+# differed by a string a human had to get right, in a box with no review, no
+# version history, and no test.
+#
+# Which manager is decided by the lockfile that is actually committed, never
+# guessed: a guessed one fails on the container's first command with an error
+# blaming the project rather than the guess.
+#
+# Skipped when node_modules already exists, which is what makes this cheap on a
+# resumed container and correct to run twice.
+if [ "${LISA_SKIP_INSTALL:-}" != "1" ] && [ ! -d node_modules ]; then
+  if [ -f bun.lock ] || [ -f bun.lockb ]; then install_cmd="bun install"
+  elif [ -f pnpm-lock.yaml ]; then install_cmd="pnpm install --frozen-lockfile"
+  elif [ -f yarn.lock ]; then
+    # Yarn Classic and Berry spell the same intent differently, and each
+    # rejects the other's flag. The lockfile itself says which is in use:
+    # Yarn 1 writes a "# yarn lockfile v1" header, Berry does not.
+    if head -5 yarn.lock | grep -q "yarn lockfile v1"; then
+      install_cmd="yarn install --frozen-lockfile"
+    else
+      install_cmd="yarn install --immutable"
+    fi
+  elif [ -f package-lock.json ]; then install_cmd="npm ci"
+  else install_cmd=""
+  fi
+
+  if [ -n "$install_cmd" ]; then
+    echo "Installing dependencies with: $install_cmd"
+    # CI=1 so lifecycle scripts take their automation path and leave the
+    # checkout alone. A remote-env setup is automation by definition, and a
+    # postinstall that rewrites tracked files here breaks any skill with a
+    # clean-checkout precondition — which the publishing skills have, because
+    # their diff is contractually bounded and merged without human review.
+    #
+    # Lisa's own postinstall already guards on exactly this variable, so this
+    # is an existing convention rather than a new one.
+    #
+    # NOT --ignore-scripts: that would also stop patch-package, so a project
+    # relying on patched dependencies would silently get unpatched ones — a
+    # quieter failure than the one being fixed.
+    #
+    # Without it the bug is cache-dependent, not deterministic: a fresh
+    # container installs and dirties the tree, a resumed one skips the install
+    # and succeeds. That reads as flakiness rather than a cause.
+    CI=1 $install_cmd
+  else
+    # Not fatal on its own. A project may carry no lockfile and still have the
+    # skill in a checkout directory, so let the resolver below decide.
+    echo "No lockfile found; skipping dependency install." >&2
+  fi
+fi
+
 # Where the skill lives depends on how this project's harness receives it, and
 # the two delivery models differ in a way that matters here.
 #
@@ -57,9 +125,10 @@ if [ -z "$runner" ]; then
   echo "yet: Claude and Codex receive Lisa skills as an installed plugin, which" >&2
   echo "is not part of a clone, so node_modules is the only copy present." >&2
   echo >&2
-  echo "Install dependencies before this script runs. The environment's setup" >&2
-  echo "command should be the install and this script together, for example:" >&2
-  echo "  bun install && bash scripts/lisa-remote-env/setup.sh" >&2
+  echo "This script installs dependencies itself, so reaching here means the" >&2
+  echo "install did not produce the package, or the project has no lockfile" >&2
+  echo "identifying its package manager. Check that @codyswann/lisa is a" >&2
+  echo "dependency and that a lockfile is committed." >&2
   echo >&2
   echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
   echo "present, then re-run setup." >&2