@codyswann/lisa 2.322.5 → 2.322.7

package/plugins/src/base/skills/lisa-setup-remote-env/assets/setup.sh

@@ -105,11 +105,21 @@ fi
 # plugin-delivered harnesses work at all. Lisa is a dependency of every project
 # it is applied to, so `node_modules` carries the same skill at the version that
 # project pins, which is the version its setup should run.
+#
+# `plugins/lisa/skills/` sits between them, and exists for exactly one project:
+# Lisa itself. There the checkout IS Lisa, at HEAD, while `node_modules` holds
+# whatever version its own lockfile pins — which was four months and a hundred
+# skills behind, so this file did not exist there at all and setup aborted
+# claiming the skill could not be found. The one place it was is the only place
+# that was not searched. It is ahead of node_modules because a checkout that
+# builds this skill is newer than any published copy of it, and harmless
+# everywhere else because no other project has that directory.
 runner=""
 for candidate in \
   ".claude/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".agents/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
+  "plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   "node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
   if [ -f "$candidate" ]; then
     runner="$candidate"
@@ -132,6 +142,18 @@ if [ -z "$runner" ]; then
   echo >&2
   echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
   echo "present, then re-run setup." >&2
+  echo >&2
+  # The version actually resolved, because "not found" and "found, but too old
+  # to contain this skill" read identically above and are fixed differently.
+  # The second is what happened on Lisa itself: node_modules held a release
+  # from before this skill existed, so every path checked was legitimately
+  # absent and the message blamed the install.
+  if [ -f node_modules/@codyswann/lisa/package.json ]; then
+    echo "For reference, node_modules has @codyswann/lisa version:" >&2
+    node -p "require('./node_modules/@codyswann/lisa/package.json').version" >&2 2>/dev/null ||
+      echo "  (unreadable)" >&2
+    echo "If that predates this skill, the pin is the problem, not the install." >&2
+  fi
   exit 1
 fi
 

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

@@ -308,28 +308,44 @@ export function installAssets(cwd = process.cwd()) {
  * at all — so a `$HOME` glob matched nothing there and bash was handed a path
  * still containing a literal asterisk.
  *
- * Both candidates are therefore tried relative to cwd, and EVERY match is
- * prepared rather than the first. A Claude Code web environment can hold more
- * than one checkout, so stopping at the first hit would prepare whichever
- * repository sorts first and silently ignore the rest — arbitrary rather than
- * merely limited. Each script anchors itself on its own repository root and
- * each project materializes under its own `secrets.namespace`, so preparing
- * several is well defined rather than a collision.
+ * Candidates are therefore tried relative to cwd first, then under `$HOME` and
+ * `/workspace` — the container roots the two surfaces actually use — because
+ * cwd is not reliably either of them. A Claude environment reported `$HOME` as
+ * `/root` with no checkout beneath it, which a cwd-only search cannot reach.
+ *
+ * EVERY match is prepared rather than the first. A Claude Code web environment
+ * can hold more than one checkout, so stopping at the first hit would prepare
+ * whichever repository sorts first and silently ignore the rest — arbitrary
+ * rather than merely limited. Each script anchors itself on its own repository
+ * root and each project materializes under its own `secrets.namespace`, so
+ * preparing several is well defined rather than a collision. Matches are
+ * deduplicated by resolved directory, since the candidate globs overlap
+ * whenever cwd happens to be one of the roots.
  *
  * The status is the first failure and every checkout is still attempted: one
  * broken repository must neither hide the others nor report success. The
  * explicit `exit 1` on no matches matters because a `for` loop over a glob that
  * matches nothing otherwise exits 0 — the quiet success this guards against.
  *
+ * Failure prints the layout it found rather than only the path it wanted. This
+ * field lives in a vendor settings box with a slow edit-and-retry loop, and a
+ * miss that reports nothing costs a whole round trip to learn one fact; the
+ * listing means the next message names the layout instead of repeating it.
+ *
  * 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.
  */
 export const SETUP_FIELD =
-  "n=0; rc=0; " +
-  "for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh; " +
-  'do [ -f "$f" ] || continue; n=$((n+1)); bash "$f" || rc=$?; done; ' +
-  '[ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1; }; ' +
+  'n=0; rc=0; seen=""; ' +
+  "for f in scripts/lisa-remote-env/setup.sh */scripts/lisa-remote-env/setup.sh " +
+  '"$HOME"/scripts/lisa-remote-env/setup.sh "$HOME"/*/scripts/lisa-remote-env/setup.sh ' +
+  "/workspace/scripts/lisa-remote-env/setup.sh /workspace/*/scripts/lisa-remote-env/setup.sh; " +
+  'do [ -f "$f" ] || continue; d=$(cd "$(dirname "$f")" && pwd -P); ' +
+  'case " $seen " in *" $d "*) continue;; esac; seen="$seen $d"; ' +
+  'n=$((n+1)); bash "$f" || rc=$?; done; ' +
+  '[ "$n" -gt 0 ] || { echo "lisa-remote-env entrypoint not found. ' +
+  'PWD=$PWD HOME=$HOME" >&2; ls -1 . "$HOME" /workspace 2>&1 | head -40 >&2; exit 1; }; ' +
   'exit "$rc"';
 
 /**

package/scripts/install-claude-plugins.sh

@@ -290,6 +290,29 @@ fi
 # Install plugins only when claude CLI is available
 if ! command -v claude &>/dev/null; then exit 0; fi
 
+# Not in a cloud session: the platform already does this, and does it at the
+# only moment it can work.
+#
+# Claude Code installs the plugins a repository declares in .claude/settings.json
+# at session start, from the marketplace that file names. This script runs from a
+# package manager's postinstall, which in a container happens during the setup
+# script — before Claude Code has launched and before any marketplace is
+# registered. Every install therefore failed:
+#
+#   Installing plugin "lisa@lisa"...× Plugin "lisa" not found in marketplace "lisa"
+#
+# Eight of eight, the official marketplace's plugins included, which is what
+# ruled out anything project-specific. The failures are harmless on their own
+# (`|| true`), but they leave an empty installed_plugins.json and several
+# screens of red in the setup log that read as the cause of whatever fails next.
+#
+# Standing down is the fix rather than racing the platform with an earlier
+# install, because there is no earlier moment at which one could succeed.
+if [ "${CLAUDE_CODE_REMOTE:-}" = "true" ]; then
+  echo "Cloud session: leaving plugin installation to Claude Code, which installs what .claude/settings.json declares at session start."
+  exit 0
+fi
+
 # Version-gated plugin sync (perf). `claude plugin marketplace update` is a
 # network git pull of the whole Lisa repo and every `claude plugin install`
 # spawns the Claude CLI (seconds each); re-running all of it on every install

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

@@ -105,11 +105,21 @@ fi
 # plugin-delivered harnesses work at all. Lisa is a dependency of every project
 # it is applied to, so `node_modules` carries the same skill at the version that
 # project pins, which is the version its setup should run.
+#
+# `plugins/lisa/skills/` sits between them, and exists for exactly one project:
+# Lisa itself. There the checkout IS Lisa, at HEAD, while `node_modules` holds
+# whatever version its own lockfile pins — which was four months and a hundred
+# skills behind, so this file did not exist there at all and setup aborted
+# claiming the skill could not be found. The one place it was is the only place
+# that was not searched. It is ahead of node_modules because a checkout that
+# builds this skill is newer than any published copy of it, and harmless
+# everywhere else because no other project has that directory.
 runner=""
 for candidate in \
   ".claude/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".agents/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   ".codex/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
+  "plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs" \
   "node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs"; do
   if [ -f "$candidate" ]; then
     runner="$candidate"
@@ -132,6 +142,18 @@ if [ -z "$runner" ]; then
   echo >&2
   echo "If dependencies are installed, run 'lisa apply' so the skills are" >&2
   echo "present, then re-run setup." >&2
+  echo >&2
+  # The version actually resolved, because "not found" and "found, but too old
+  # to contain this skill" read identically above and are fixed differently.
+  # The second is what happened on Lisa itself: node_modules held a release
+  # from before this skill existed, so every path checked was legitimately
+  # absent and the message blamed the install.
+  if [ -f node_modules/@codyswann/lisa/package.json ]; then
+    echo "For reference, node_modules has @codyswann/lisa version:" >&2
+    node -p "require('./node_modules/@codyswann/lisa/package.json').version" >&2 2>/dev/null ||
+      echo "  (unreadable)" >&2
+    echo "If that predates this skill, the pin is the problem, not the install." >&2
+  fi
   exit 1
 fi