@codyswann/lisa 2.321.4 → 2.322.0

package/dist/core/upstream-evidence-manifest.js

@@ -550,7 +550,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-sentry-access/SKILL.md": "ecaf49b42bbf399781a3ebd0b1595e5a8ac44422537832e0442b2f184da0c83c",
     "plugins/src/base/skills/lisa-setup-atlassian/SKILL.md": "3820aecb57d184fde1cfa988e7e1402d8f2a766a0b3ffbb576de5a6a72b3d5c5",
     "plugins/src/base/skills/lisa-setup-automations/SKILL.md": "3ad004148a54571a50df90f23abec71e8510ef3ea3562ac812f8e2e11beb157a",
-    "plugins/src/base/skills/lisa-setup-automations/scripts/generate-workflow.mjs": "dd1a0999156bbbaf864fc0f1d85206db5ea2ada172ccac2ee11091303e06ff4d",
+    "plugins/src/base/skills/lisa-setup-automations/scripts/generate-workflow.mjs": "bfb3867cc62dd37d84367859e4d796edb7a0c046595b3e0194ddb0b6d3b63d61",
     "plugins/src/base/skills/lisa-setup-confluence/SKILL.md": "e92d762dbdaeae671c3e52dfe8e10d40a10b606b5e050589181a3898649faedc",
     "plugins/src/base/skills/lisa-setup-github-repo/SKILL.md": "b9b223a5ffad2f88e3fde5831b60fea9bdc2c981750c49d03bb046d43772a0d3",
     "plugins/src/base/skills/lisa-setup-github/SKILL.md": "75435e81130abd21c678d302b7a220da95a19868d122ca93168278628b200666",
@@ -559,10 +559,10 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-setup-linear/SKILL.md": "ec76f832a6df6f58b163f7f5ba6826ed2fcbddc91e44a8372e874858e4d0c518",
     "plugins/src/base/skills/lisa-setup-notion/SKILL.md": "f5a1e9290789fd1c33675168d30461fb24a11c98a433ef777c1f536bc2f905ef",
     "plugins/src/base/skills/lisa-setup-remote-aws/SKILL.md": "80fbf157f9c562c033886c25a99b37356602edd9e61cd2d492f339769ddcf97e",
-    "plugins/src/base/skills/lisa-setup-remote-env/SKILL.md": "313d1b96500950b566a3e22bc1620662a76635c89c6c90c2648d48e0497574b7",
+    "plugins/src/base/skills/lisa-setup-remote-env/SKILL.md": "0673567b71f5d3ef52b244bbd7acfe628d0cfcb7459bda5375ce81c80a1cc501",
     "plugins/src/base/skills/lisa-setup-remote-env/assets/session-start.sh": "6e3871ec2f8d56b8ebb85376ebdd3956f3ed8fa4f7b278c2ed90ca9b8845897c",
-    "plugins/src/base/skills/lisa-setup-remote-env/assets/setup.sh": "f1b492196f41adcceb1c2a2ada048355e7f36735de3be0dfe028e472b452f28c",
-    "plugins/src/base/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs": "ceba67f85f1db0f390b0cbe66c63401cc03eaa8a27b254ba3d4b0c271103a53d",
+    "plugins/src/base/skills/lisa-setup-remote-env/assets/setup.sh": "7f7cf8a2248dbaa31f2f039fdaf147d083427a21633f7cf06ad612f38344d6c1",
+    "plugins/src/base/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs": "1794aec433f1f469857123ed08156c4a74cc746cca12ca541d38edfbadc5c746",
     "plugins/src/base/skills/lisa-setup-remote-env/scripts/toolchain.mjs": "ff66d33ba41a068d09be18f81ac68988238c2afa1d4e3733ae906b73eea74324",
     "plugins/src/base/skills/lisa-setup-remote-env/scripts/verify-remote-env.mjs": "82bc2a27a0a5afb2ff413a88365c619fd7f0eaada5de3ccabf2000938f0607a4",
     "plugins/src/base/skills/lisa-setup-sonar/SKILL.md": "53fbd8acce4b5e47e88195a7b90d5be424fa6ef7ad872f52c50467c690664c3b",

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.9"
   },
   "name": "@codyswann/lisa",
-  "version": "2.321.4",
+  "version": "2.322.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/scripts/generate-workflow.mjs

@@ -41,9 +41,20 @@ export function readAutomation(name, cwd = process.cwd()) {
         `Declare the loop before generating its workflow.`
     );
   }
+  const surface = cfg.remoteEnv?.surfaces?.[loop.executionEnv];
+  const github = cfg.github ?? {};
   return {
     ...loop,
-    repository: cfg.remoteEnv?.surfaces?.[loop.executionEnv]?.repository,
+    // Only used for the fork guard, so it is a question about *this* repository
+    // rather than about the surface. Read from the surface where one records it
+    // — Codex Cloud binds an environment to a repository — and otherwise from
+    // the project's own GitHub config. A Claude cloud environment binds no
+    // repository at all, and demanding one there asked for a field that cannot
+    // exist, which refused to generate a workflow for a correctly configured
+    // loop.
+    repository:
+      surface?.repository ??
+      (github.org && github.repo ? `${github.org}/${github.repo}` : undefined),
     // Where this project keeps its bootstrap. A workstation serving several
     // tenants gives each its own name, so the generated workflow must template
     // it rather than assume the default.
@@ -81,12 +92,28 @@ export function renderWorkflow(name, loop) {
   const bootstrap = loop.bootstrapKey ?? "BWS_ACCESS_TOKEN";
   if (!loop.repository) {
     throw new Error(
-      `automations["${name}"] targets executionEnv "${loop.executionEnv}", ` +
-        `but no remoteEnv.surfaces["${loop.executionEnv}"].repository is set.\n` +
-        `Run /lisa:setup:remote-env ${loop.executionEnv} first.`
+      `cannot determine which repository this loop belongs to.\n` +
+        `The generated workflow guards on it so a fork never dispatches. Set ` +
+        `github.org and github.repo in .lisa.config.json.`
     );
   }
 
+  // Always emitted, even for a surface whose dispatcher token is not consumed
+  // by use. Making it conditional on secrets.rotating would mean a project that
+  // later declares one, without regenerating its workflow, silently loses the
+  // persist step and strands the replacement. One inert step is the cheaper
+  // failure.
+  const rotation = `
+      # The dispatcher authenticates with a credential that rotates on use, so
+      # the replacement must be persisted even when the dispatch itself failed.
+      - name: Persist any credential rotation
+        if: \${{ always() }}
+        env:
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
+        run: |
+          set -euo pipefail
+          node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases`;
+
   const trigger = loop.enabled
     ? `  schedule:\n    - cron: '${loop.schedule}'\n  workflow_dispatch:`
     : `  # schedule: disabled until the production path is proven once for one\n` +
@@ -149,15 +176,7 @@ jobs:
             'executionEnv=${loop.executionEnv} ${loop.payload ?? ""}' \\
             --skill ${loop.skill ?? `lisa-${name}`}
 
-      # The dispatcher authenticates with a credential that rotates on use, so
-      # the replacement must be persisted even when the dispatch itself failed.
-      - name: Persist any credential rotation
-        if: \${{ always() }}
-        env:
-          ${bootstrap}: \${{ secrets.${bootstrap} }}
-        run: |
-          set -euo pipefail
-          node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases
+${rotation}
 `;
 }
 

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/SKILL.md

@@ -10,26 +10,28 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       <install> && bash scripts/lisa-remote-env/setup.sh
-maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
+setup:       bash "$HOME"/*/scripts/lisa-remote-env/setup.sh
+maintenance: bash "$HOME"/*/scripts/lisa-remote-env/setup.sh
 ```
 
-`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+**That line is identical for every project.** Nothing in it names the repository or the package manager, so it can be pasted unchanged into any project's environment. The glob is what locates the checkout — Claude Code web runs this field from `$HOME` while the clone lands one level down — and the script then anchors itself on the repository root.
 
 They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
-The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
+The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things — and neither is a repository name and a package manager, which is what this field used to carry.
 
-### Why the install has to come first
+### The script installs the dependencies itself
 
 **A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
 
 `node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
 
-Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+So the install has to happen before the runner is resolved — and the entrypoint does it, rather than the settings field. Which package manager is read from the lockfile the project actually commits (`bun.lock`, `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`), never guessed: a guessed one fails on the container's first command with an error that blames the project rather than the guess. The step is skipped when `node_modules` already exists, which is what keeps a resumed container cheap, and `LISA_SKIP_INSTALL=1` opts out entirely for a caller that has already installed.
+
+A project with no lockfile is not fatal on its own — a checkout may carry the skill directly — so the script says so and lets the resolver decide.
 
 ## The three phases
 
@@ -134,11 +136,10 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
-Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
-                   (<install> is the project's own: bun install, npm ci, ...
-                   It must precede the script — on a fresh container
-                   node_modules is the only copy of the skills present.)
+Setup script:      bash "$HOME"/*/scripts/lisa-remote-env/setup.sh
+Maintenance:       bash "$HOME"/*/scripts/lisa-remote-env/setup.sh
+                   (identical for every project — the script finds the
+                   checkout and installs from the committed lockfile)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -157,11 +158,11 @@ Generate the exact text to paste:
 node scripts/setup-remote-env.mjs --emit=claude-web
 ```
 
-It reads the project's own install command from its lockfile and the bootstrap name from `secrets.bootstrap.key`, then emits the environment fields, the `.claude/settings.json` hook block, and the two base-image surprises worth knowing before they cost an afternoon:
+It reads the bootstrap name from `secrets.bootstrap.key` and emits the environment fields, the `.claude/settings.json` hook block, and the base-image surprises worth knowing before they cost an afternoon:
 
 - **`gh` is not pre-installed.** If the project's flows shell out to it, add it to `remoteEnv.tools.install`, pinned and checksummed like anything else.
 - **A proxied credential reads as the literal string `proxy-injected`.** Tools that authenticate through the GitHub proxy work; a script that reads the variable directly gets the placeholder. The read-back asserts this rather than leaving it to be discovered against a live service.
-- **The setup field runs from `$HOME`, not from the checkout.** The emitted setup command starts with `cd <repo-name>` on purpose; without it the package install runs one directory above the clone and cannot find `package.json`.
+- **The setup field runs from `$HOME`, not from the checkout.** That is why the field is a `$HOME` glob rather than a plain relative path: it locates the clone one level down, and the script anchors itself from there. Nothing in the emitted line names this project, so it is the same line everywhere.
 - **Trusted network access is not enough for provider CLIs.** Use Custom and include package registries, GitHub, cloud SDK hosts, and the bootstrap credential manager API.
 
 ### One environment per project, pinned locally

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/assets/setup.sh

@@ -24,8 +24,10 @@ case "$script_dir" in
 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
@@ -33,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.
 #
@@ -67,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

package/plugins/lisa/.codex-plugin/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs

@@ -298,6 +298,20 @@ export function installAssets(cwd = process.cwd()) {
   });
 }
 
+/**
+ * The setup field, identical for every project.
+ *
+ * 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.
+ *
+ * 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.
+ */
+const SETUP_FIELD = `bash "$HOME"/*/scripts/lisa-remote-env/setup.sh`;
+
 /**
  * The settings block that wires the session-start hook into a repository.
  *
@@ -366,12 +380,11 @@ export function pinEnvironment(environmentId, cwd = process.cwd()) {
  * settings page, no direct URL, and no endpoint. Emit is not a degraded option
  * here, it is the only one — so the read-back in `verify-remote-env.mjs` is
  * what makes the result trustworthy, exactly as it would be at any other tier.
- * @param {{bootstrapKey: string|null, install: string, repoDir?: string}} options Project details.
+ * @param {{bootstrapKey: string|null}} options Project details.
  * @returns {string} Text to show the operator.
  */
-export function emitClaudeWeb({ bootstrapKey, install, repoDir = "lisa" }) {
+export function emitClaudeWeb({ bootstrapKey }) {
   const key = bootstrapKey ?? "<secrets.bootstrap.key is not configured>";
-  const setup = `cd ${shellQuote(repoDir)} && ${install} && bash scripts/lisa-remote-env/setup.sh`;
   return [
     "Provisioning tier: EMIT — and for this surface that is the only tier.",
     "  A Claude cloud environment is account-scoped configuration edited in the",
@@ -393,13 +406,17 @@ export function emitClaudeWeb({ bootstrapKey, install, repoDir = "lisa" }) {
     "    is why exactly one value needs to live here.",
     "",
     "  Setup script:",
-    `    ${setup}`,
+    `    ${SETUP_FIELD}`,
+    "",
+    "    This line is identical for every project — nothing in it names this",
+    "    repository or its package manager. Claude runs the field from $HOME",
+    "    while the checkout lives one level down, so the glob is what locates",
+    "    it; the script then anchors itself and installs dependencies using",
+    "    whichever lockfile the project actually commits.",
     "",
-    `    Claude runs this field from $HOME, while the checkout is $HOME/${repoDir}.`,
-    "    The `cd` must come first, and the install must run before the setup",
-    "    script. On a fresh container node_modules is the only copy of the Lisa",
-    "    skills present, because Claude receives them as an installed plugin",
-    "    rather than as part of the clone.",
+    "    Keeping it generic is the point. A field that named the repository and",
+    "    the package manager was a string a human had to get right, in a box",
+    "    with no review, no version history and no test.",
     "",
     "Commit to the repository",
     "------------------------",
@@ -478,57 +495,6 @@ async function detectSurface() {
   return { surface, materializeAt: mod.SURFACES[surface].materializeAt };
 }
 
-/**
- * Name the project's own install command rather than inventing one.
- *
- * The emitted setup line must begin with whatever this project already uses; a
- * guessed package manager produces a container that fails on its first command.
- * @param {string} [cwd] Repository root.
- * @returns {string} The install command to place before the setup script.
- */
-export function detectInstallCommand(cwd = process.cwd()) {
-  const lockfiles = [
-    ["bun.lockb", "bun install"],
-    ["bun.lock", "bun install"],
-    ["pnpm-lock.yaml", "pnpm install --frozen-lockfile"],
-    ["yarn.lock", "yarn install --immutable"],
-    ["package-lock.json", "npm ci"],
-  ];
-  for (const [file, command] of lockfiles) {
-    if (existsSync(join(cwd, file))) return command;
-  }
-  return "<your install command>";
-}
-
-/**
- * Name the directory Claude creates under $HOME when it clones this repository.
- *
- * Claude cloud runs the environment setup field from $HOME, not from the
- * checkout. The setup line therefore has to `cd` into the clone before running
- * the project install. Prefer the configured GitHub repo name because it is the
- * thing Claude clones; fall back to the current directory for non-GitHub tests
- * and local dry runs.
- * @param {string} [cwd] Repository root.
- * @returns {string} Directory name to place after `cd`.
- */
-export function detectRepositoryDirectory(cwd = process.cwd()) {
-  const path = join(cwd, ".lisa.config.json");
-  if (existsSync(path)) {
-    const repo = JSON.parse(readFileSync(path, "utf8")).github?.repo;
-    if (repo && !repo.includes("/") && !repo.includes("\0")) return repo;
-  }
-  return basename(cwd);
-}
-
-/**
- * Quote a value for POSIX shell usage.
- * @param {string} value Raw value.
- * @returns {string} Single-quoted shell literal.
- */
-function shellQuote(value) {
-  return "'" + String(value).replaceAll("'", "'\\''") + "'";
-}
-
 /**
  * Read the bootstrap key name, which is the one value the operator must paste.
  * @param {string} [cwd] Repository root.
@@ -577,13 +543,7 @@ async function main() {
           `Emitting is implemented for claude-web, which has no other tier.`
       );
     }
-    console.log(
-      emitClaudeWeb({
-        bootstrapKey: readBootstrapKey(),
-        install: detectInstallCommand(),
-        repoDir: detectRepositoryDirectory(),
-      })
-    );
+    console.log(emitClaudeWeb({ bootstrapKey: readBootstrapKey() }));
     return;
   }
 

package/plugins/lisa/skills/lisa-setup-automations/scripts/generate-workflow.mjs

@@ -41,9 +41,20 @@ export function readAutomation(name, cwd = process.cwd()) {
         `Declare the loop before generating its workflow.`
     );
   }
+  const surface = cfg.remoteEnv?.surfaces?.[loop.executionEnv];
+  const github = cfg.github ?? {};
   return {
     ...loop,
-    repository: cfg.remoteEnv?.surfaces?.[loop.executionEnv]?.repository,
+    // Only used for the fork guard, so it is a question about *this* repository
+    // rather than about the surface. Read from the surface where one records it
+    // — Codex Cloud binds an environment to a repository — and otherwise from
+    // the project's own GitHub config. A Claude cloud environment binds no
+    // repository at all, and demanding one there asked for a field that cannot
+    // exist, which refused to generate a workflow for a correctly configured
+    // loop.
+    repository:
+      surface?.repository ??
+      (github.org && github.repo ? `${github.org}/${github.repo}` : undefined),
     // Where this project keeps its bootstrap. A workstation serving several
     // tenants gives each its own name, so the generated workflow must template
     // it rather than assume the default.
@@ -81,12 +92,28 @@ export function renderWorkflow(name, loop) {
   const bootstrap = loop.bootstrapKey ?? "BWS_ACCESS_TOKEN";
   if (!loop.repository) {
     throw new Error(
-      `automations["${name}"] targets executionEnv "${loop.executionEnv}", ` +
-        `but no remoteEnv.surfaces["${loop.executionEnv}"].repository is set.\n` +
-        `Run /lisa:setup:remote-env ${loop.executionEnv} first.`
+      `cannot determine which repository this loop belongs to.\n` +
+        `The generated workflow guards on it so a fork never dispatches. Set ` +
+        `github.org and github.repo in .lisa.config.json.`
     );
   }
 
+  // Always emitted, even for a surface whose dispatcher token is not consumed
+  // by use. Making it conditional on secrets.rotating would mean a project that
+  // later declares one, without regenerating its workflow, silently loses the
+  // persist step and strands the replacement. One inert step is the cheaper
+  // failure.
+  const rotation = `
+      # The dispatcher authenticates with a credential that rotates on use, so
+      # the replacement must be persisted even when the dispatch itself failed.
+      - name: Persist any credential rotation
+        if: \${{ always() }}
+        env:
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
+        run: |
+          set -euo pipefail
+          node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases`;
+
   const trigger = loop.enabled
     ? `  schedule:\n    - cron: '${loop.schedule}'\n  workflow_dispatch:`
     : `  # schedule: disabled until the production path is proven once for one\n` +
@@ -149,15 +176,7 @@ jobs:
             'executionEnv=${loop.executionEnv} ${loop.payload ?? ""}' \\
             --skill ${loop.skill ?? `lisa-${name}`}
 
-      # The dispatcher authenticates with a credential that rotates on use, so
-      # the replacement must be persisted even when the dispatch itself failed.
-      - name: Persist any credential rotation
-        if: \${{ always() }}
-        env:
-          ${bootstrap}: \${{ secrets.${bootstrap} }}
-        run: |
-          set -euo pipefail
-          node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases
+${rotation}
 `;
 }
 

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

@@ -10,26 +10,28 @@ Prepare a remote surface so a host project can execute there. Today that means *
 
 ## What lives where
 
-The remote environment's own configuration fields stay **one line into the repository, preceded by the project's dependency install**. Nothing else is pasted into a vendor UI.
+The remote environment's own configuration fields stay **one line into the repository**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       <install> && bash scripts/lisa-remote-env/setup.sh
-maintenance: <install> && bash scripts/lisa-remote-env/setup.sh
+setup:       bash "$HOME"/*/scripts/lisa-remote-env/setup.sh
+maintenance: bash "$HOME"/*/scripts/lisa-remote-env/setup.sh
 ```
 
-`<install>` is whatever the project already uses — `bun install`, `npm ci`, `pnpm install`. Substitute it; do not invent one.
+**That line is identical for every project.** Nothing in it names the repository or the package manager, so it can be pasted unchanged into any project's environment. The glob is what locates the checkout — Claude Code web runs this field from `$HOME` while the clone lands one level down — and the script then anchors itself on the repository root.
 
 They are the same command. A container may be built fresh or resumed from cache; every step is idempotent and version-aware, so running it twice is correct, and running it on resume is what picks up a rotated value, an edited note, or a changed version pin.
 
-The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things.
+The complete logic is repository-owned so it is reviewed, versioned, tested, and reusable. A large inline installer in a settings field is none of those things — and neither is a repository name and a package manager, which is what this field used to carry.
 
-### Why the install has to come first
+### The script installs the dependencies itself
 
 **A clone does not contain the skills on the harnesses that matter here.** OpenCode and Antigravity have them written into the checkout by `lisa apply`. Claude and Codex receive them as an *installed plugin*, which lives in the user's home directory — so a container that has just cloned the repository has never seen it.
 
 `node_modules/@codyswann/lisa` is therefore the only copy present on a fresh container, and it is a good one: it is the version that project pins, which is the version its setup should run. The entrypoint searches the agent directories first and falls back to it.
 
-Omitting the install does not degrade gracefully. The entrypoint exits before the toolchain, secrets, and hook phases have done anything, so the environment looks provisioned and fails on first dispatch.
+So the install has to happen before the runner is resolved — and the entrypoint does it, rather than the settings field. Which package manager is read from the lockfile the project actually commits (`bun.lock`, `pnpm-lock.yaml`, `yarn.lock`, `package-lock.json`), never guessed: a guessed one fails on the container's first command with an error that blames the project rather than the guess. The step is skipped when `node_modules` already exists, which is what keeps a resumed container cheap, and `LISA_SKIP_INSTALL=1` opts out entirely for a caller that has already installed.
+
+A project with no lockfile is not fatal on its own — a checkout may carry the skill directly — so the script says so and lets the resolver decide.
 
 ## The three phases
 
@@ -134,11 +136,10 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      <install> && bash scripts/lisa-remote-env/setup.sh
-Maintenance:       <install> && bash scripts/lisa-remote-env/setup.sh
-                   (<install> is the project's own: bun install, npm ci, ...
-                   It must precede the script — on a fresh container
-                   node_modules is the only copy of the skills present.)
+Setup script:      bash "$HOME"/*/scripts/lisa-remote-env/setup.sh
+Maintenance:       bash "$HOME"/*/scripts/lisa-remote-env/setup.sh
+                   (identical for every project — the script finds the
+                   checkout and installs from the committed lockfile)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud
                    BWS_ACCESS_TOKEN=<from the provider; an environment
                    variable, not a task secret — setup and cache-resume
@@ -157,11 +158,11 @@ Generate the exact text to paste:
 node scripts/setup-remote-env.mjs --emit=claude-web
 ```
 
-It reads the project's own install command from its lockfile and the bootstrap name from `secrets.bootstrap.key`, then emits the environment fields, the `.claude/settings.json` hook block, and the two base-image surprises worth knowing before they cost an afternoon:
+It reads the bootstrap name from `secrets.bootstrap.key` and emits the environment fields, the `.claude/settings.json` hook block, and the base-image surprises worth knowing before they cost an afternoon:
 
 - **`gh` is not pre-installed.** If the project's flows shell out to it, add it to `remoteEnv.tools.install`, pinned and checksummed like anything else.
 - **A proxied credential reads as the literal string `proxy-injected`.** Tools that authenticate through the GitHub proxy work; a script that reads the variable directly gets the placeholder. The read-back asserts this rather than leaving it to be discovered against a live service.
-- **The setup field runs from `$HOME`, not from the checkout.** The emitted setup command starts with `cd <repo-name>` on purpose; without it the package install runs one directory above the clone and cannot find `package.json`.
+- **The setup field runs from `$HOME`, not from the checkout.** That is why the field is a `$HOME` glob rather than a plain relative path: it locates the clone one level down, and the script anchors itself from there. Nothing in the emitted line names this project, so it is the same line everywhere.
 - **Trusted network access is not enough for provider CLIs.** Use Custom and include package registries, GitHub, cloud SDK hosts, and the bootstrap credential manager API.
 
 ### One environment per project, pinned locally