@codyswann/lisa 2.322.3 → 2.322.5

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

@@ -526,8 +526,8 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-qa-queue/SKILL.md": "1d5f009f60004bf75b5d79bca370096ce40e1d41d585dc8afd4389f21bba84ae",
     "plugins/src/base/skills/lisa-quality-review/SKILL.md": "17ba45f4c4b7877c0b0c9a3c1cc1cb9e18c642ead74ff7263698d8034d3241da",
     "plugins/src/base/skills/lisa-queue-status/SKILL.md": "87c6d34d0511d4afd812d1af3fee80fa3b7aa47db8449760b12f2699fedc1d78",
-    "plugins/src/base/skills/lisa-remote-dispatch/SKILL.md": "2cc999d2c3b61b10aabb849e0833fd58edb444c5013c05108dd58e5d7d60c4ba",
-    "plugins/src/base/skills/lisa-remote-dispatch/scripts/dispatch.mjs": "6ce559964964c65154d2105a017c751bba086dcb8b4ea209ea42ce7b4fdb7d63",
+    "plugins/src/base/skills/lisa-remote-dispatch/SKILL.md": "f3c48120a206d01db45f849ca5b61690d572abc16bc36d559a4cacc8f9422c06",
+    "plugins/src/base/skills/lisa-remote-dispatch/scripts/dispatch.mjs": "475963ed64d9e72a6cbd6cbb61c8b57a419f2e1805e3ddfa76066047c590deeb",
     "plugins/src/base/skills/lisa-repair-intake/SKILL.md": "4f85ac1381631e9f250d9cf3239baba633ae0df9ba1959f8835ed662592e2d77",
     "plugins/src/base/skills/lisa-reproduce-bug/SKILL.md": "4d460993fac6021219ca23eee29b1b9afa7c37479dddc662b2fcfaca510edd68",
     "plugins/src/base/skills/lisa-research/SKILL.md": "19de7c5910b117c4b3b1bb7ae42cf9c8b6ff2a376b2e21961526bc7ebde18e85",
@@ -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": "e6530485e2564f35592a28bc5e547d185a38bf2a061feb210d533304acdc5cc2",
+    "plugins/src/base/skills/lisa-setup-remote-env/SKILL.md": "4fe124678cfc2b37188370af3b4e16895fcbad4d4b6f13b0fc7ac02bd99b0d26",
     "plugins/src/base/skills/lisa-setup-remote-env/assets/session-start.sh": "6e3871ec2f8d56b8ebb85376ebdd3956f3ed8fa4f7b278c2ed90ca9b8845897c",
     "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": "c3fedb3f9cc50e706c197129cfe69baf705a96ab93194152c6d2f952f2d6d3b7",
+    "plugins/src/base/skills/lisa-setup-remote-env/scripts/setup-remote-env.mjs": "e8f1e74dd29104dc880eb2540024549d18d2a9c958b2b6fce0610ab0afd55cbb",
     "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.322.3",
+  "version": "2.322.5",
   "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.322.3",
+  "version": "2.322.5",
   "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.322.3",
+  "version": "2.322.5",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -16,9 +16,12 @@ It changes **where** work happens and nothing about **what** happens. The remote
 | --- | --- |
 | omitted / `local` | The calling skill proceeds normally. Nothing is dispatched. |
 | `codex-cloud` | Submit to the project's Codex Cloud environment and return. |
+| `claude-web` | Fire the project's Claude routine, which starts a cloud session, and return. |
 
 Any other value is **rejected explicitly**. A silently ignored `executionEnv` would run the work locally while the operator believes it went remote, and nothing downstream would contradict that belief.
 
+For the same reason, the parameter is accepted as both `executionEnv=…` and `--executionEnv=…`, and a *dashed* parameter this skill does not recognise is an error rather than payload. The bare form is the documented one, but the dashed form is what anyone who has used a CLI will type, and a misspelling of either is indistinguishable from not asking at all — which is the one failure an operator cannot act on. A bare `key=value` still belongs to the payload, since prose may legitimately contain an equals sign.
+
 If a behaviour must differ between local and remote, it belongs in the calling skill as an explicit branch — never here. The moment this file starts encoding domain behaviour, there are two implementations to keep in sync.
 
 ## The invocation stays thin

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

@@ -68,11 +68,25 @@ const LEDGER = join(".lisa", "remote-dispatch.json");
 /** This file's directory, for locating the sibling secrets skill. */
 const HERE = dirname(fileURLToPath(import.meta.url));
 
+/** Every parameter this program reads. Anything else is a typo. */
+const KNOWN_PARAMS = new Set(["executionEnv"]);
+
 /**
  * Split `key=value` parameters from the rest of an invocation.
  *
  * The remainder is passed through untouched. It is the caller's payload — a
  * ticket key, a description — and this program has no business interpreting it.
+ *
+ * A leading `--` is accepted and stripped. The bare form is the documented one,
+ * but `--executionEnv=claude-web` is what anyone who has used a CLI this decade
+ * types, and it previously fell through to the payload and left the surface at
+ * its default. That is precisely the outcome this skill says it exists to
+ * prevent: work runs locally while the operator believes it went remote, and
+ * nothing downstream contradicts them.
+ *
+ * An unrecognised parameter is rejected for the same reason. A misspelled
+ * `executionEnvv=claude-web` is indistinguishable from not asking at all, and
+ * silence is the one response that cannot be acted on.
  * @param {string} input Raw argument string.
  * @returns {{params: Record<string, string>, rest: string}} Parsed invocation.
  */
@@ -83,9 +97,19 @@ export function parseInvocation(input) {
     .trim()
     .split(/\s+/)
     .filter(Boolean)) {
-    const match = /^([A-Za-z][A-Za-z0-9_]*)=(.*)$/.exec(token);
-    if (match) params[match[1]] = match[2];
-    else rest.push(token);
+    const match = /^(--)?([A-Za-z][A-Za-z0-9_]*)=(.*)$/.exec(token);
+    // Only a dashed token is required to be a known parameter. A bare `x=y` may
+    // legitimately be part of a payload — a description, a query — and this
+    // program has no business rejecting the caller's prose.
+    if (match && (match[1] || KNOWN_PARAMS.has(match[2]))) {
+      if (!KNOWN_PARAMS.has(match[2])) {
+        throw new Error(
+          `unknown parameter "${match[2]}".\n` +
+            `Supported: ${[...KNOWN_PARAMS].join(", ")}.`
+        );
+      }
+      params[match[2]] = match[3];
+    } else rest.push(token);
   }
   return { params, rest: rest.join(" ") };
 }
@@ -416,6 +440,28 @@ function resolveBearerToken(block) {
   }
 }
 
+/**
+ * How each agent spells "run this skill".
+ *
+ * Codex invokes a skill with `$name`, Claude with `/name`. The prefix is the
+ * whole invocation: get it wrong and the agent reads a sentence that merely
+ * mentions a skill rather than a command that runs one — and being a capable
+ * model it will often do *something*, which is worse than failing, because the
+ * run looks successful while executing none of the skill's contract.
+ *
+ * Nothing downstream catches it either. The routine accepts any text, so the
+ * dispatch succeeds, a session identifier is recorded, and the ledger says the
+ * work was handed off. Only reading the session shows otherwise.
+ * @param {string} surface Execution surface.
+ * @param {string} skill Skill slug, without a prefix.
+ * @param {string} rest The payload the skill is invoked with.
+ * @returns {string} The thin invocation to send.
+ */
+export function buildInvocation(surface, skill, rest) {
+  const prefix = surface === "claude-web" ? "/" : "$";
+  return `${prefix}${skill} ${rest}`.trim();
+}
+
 async function main() {
   const { skill, raw } = splitSkillFlag(process.argv.slice(2));
   const { params, rest } = parseInvocation(raw);
@@ -432,7 +478,7 @@ async function main() {
   // The invocation stays thin on purpose. Every durable instruction lives in
   // the repository-local skill, so an interactive run, a scheduled run, and a
   // recovery run all execute one contract.
-  const prompt = `$${skill} ${rest}`.trim();
+  const prompt = buildInvocation(surface, skill, rest);
 
   if (surface === "claude-web") {
     const { sessionId, url } = await dispatchClaudeWeb(block, prompt, rest);

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

@@ -13,8 +13,8 @@ Prepare a remote surface so a host project can execute there. Today that means *
 The remote environment's own configuration fields stay **one line into the repository**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       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
-maintenance: 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
+setup:       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; }; exit "$rc"
+maintenance: 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; }; exit "$rc"
 ```
 
 **That line is identical for every project AND every surface.** Nothing in it names the
@@ -34,10 +34,18 @@ and neither mentions `$HOME`. An earlier version of this field used
 the checkout is not under `$HOME` at all: the glob matches nothing and bash reports
 `No such file or directory` for a path still containing a literal `*`.
 
-`exec` on the first hit means no subshell and no `ls` output to parse, and the explicit
-`exit 1` means a missing entrypoint says so rather than the field silently succeeding. The
-script then anchors itself on the repository root, so it behaves the same however it was
-reached.
+**Every** match is prepared, not the first. A Claude Code web environment can hold more than
+one checkout, and stopping at the first glob 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's secrets land under its own
+`secrets.namespace`, so preparing several is well defined rather than a collision.
+
+The exit status is the **first failure**, and every checkout is still attempted: one broken
+repository must not hide the state of the others, and it must not report success either.
+
+The explicit `exit 1` on `n=0` means a missing entrypoint says so rather than the field
+silently succeeding — a `for` loop over a glob that matches nothing otherwise exits `0`,
+which is the quiet failure this whole section exists to avoid.
 
 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.
 
@@ -156,8 +164,8 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      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
-Maintenance:       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
+Setup script:      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; }; exit "$rc"
+Maintenance:       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; }; exit "$rc"
                    (identical for every project — the script finds the
                    checkout and installs from the committed lockfile)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud

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

@@ -308,20 +308,29 @@ 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. `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.
+ * 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.
+ *
+ * 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.
  *
  * 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" ] && exec bash "$f"; done; ' +
-  'echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1';
+  '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; }; ' +
+  'exit "$rc"';
 
 /**
  * The settings block that wires the session-start hook into a repository.

package/plugins/lisa/skills/lisa-remote-dispatch/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-remote-dispatch
-description: "Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly."
+description: "Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly."
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
 
@@ -16,9 +16,12 @@ It changes **where** work happens and nothing about **what** happens. The remote
 | --- | --- |
 | omitted / `local` | The calling skill proceeds normally. Nothing is dispatched. |
 | `codex-cloud` | Submit to the project's Codex Cloud environment and return. |
+| `claude-web` | Fire the project's Claude routine, which starts a cloud session, and return. |
 
 Any other value is **rejected explicitly**. A silently ignored `executionEnv` would run the work locally while the operator believes it went remote, and nothing downstream would contradict that belief.
 
+For the same reason, the parameter is accepted as both `executionEnv=…` and `--executionEnv=…`, and a *dashed* parameter this skill does not recognise is an error rather than payload. The bare form is the documented one, but the dashed form is what anyone who has used a CLI will type, and a misspelling of either is indistinguishable from not asking at all — which is the one failure an operator cannot act on. A bare `key=value` still belongs to the payload, since prose may legitimately contain an equals sign.
+
 If a behaviour must differ between local and remote, it belongs in the calling skill as an explicit branch — never here. The moment this file starts encoding domain behaviour, there are two implementations to keep in sync.
 
 ## The invocation stays thin

package/plugins/lisa/skills/lisa-remote-dispatch/scripts/dispatch.mjs

@@ -68,11 +68,25 @@ const LEDGER = join(".lisa", "remote-dispatch.json");
 /** This file's directory, for locating the sibling secrets skill. */
 const HERE = dirname(fileURLToPath(import.meta.url));
 
+/** Every parameter this program reads. Anything else is a typo. */
+const KNOWN_PARAMS = new Set(["executionEnv"]);
+
 /**
  * Split `key=value` parameters from the rest of an invocation.
  *
  * The remainder is passed through untouched. It is the caller's payload — a
  * ticket key, a description — and this program has no business interpreting it.
+ *
+ * A leading `--` is accepted and stripped. The bare form is the documented one,
+ * but `--executionEnv=claude-web` is what anyone who has used a CLI this decade
+ * types, and it previously fell through to the payload and left the surface at
+ * its default. That is precisely the outcome this skill says it exists to
+ * prevent: work runs locally while the operator believes it went remote, and
+ * nothing downstream contradicts them.
+ *
+ * An unrecognised parameter is rejected for the same reason. A misspelled
+ * `executionEnvv=claude-web` is indistinguishable from not asking at all, and
+ * silence is the one response that cannot be acted on.
  * @param {string} input Raw argument string.
  * @returns {{params: Record<string, string>, rest: string}} Parsed invocation.
  */
@@ -83,9 +97,19 @@ export function parseInvocation(input) {
     .trim()
     .split(/\s+/)
     .filter(Boolean)) {
-    const match = /^([A-Za-z][A-Za-z0-9_]*)=(.*)$/.exec(token);
-    if (match) params[match[1]] = match[2];
-    else rest.push(token);
+    const match = /^(--)?([A-Za-z][A-Za-z0-9_]*)=(.*)$/.exec(token);
+    // Only a dashed token is required to be a known parameter. A bare `x=y` may
+    // legitimately be part of a payload — a description, a query — and this
+    // program has no business rejecting the caller's prose.
+    if (match && (match[1] || KNOWN_PARAMS.has(match[2]))) {
+      if (!KNOWN_PARAMS.has(match[2])) {
+        throw new Error(
+          `unknown parameter "${match[2]}".\n` +
+            `Supported: ${[...KNOWN_PARAMS].join(", ")}.`
+        );
+      }
+      params[match[2]] = match[3];
+    } else rest.push(token);
   }
   return { params, rest: rest.join(" ") };
 }
@@ -416,6 +440,28 @@ function resolveBearerToken(block) {
   }
 }
 
+/**
+ * How each agent spells "run this skill".
+ *
+ * Codex invokes a skill with `$name`, Claude with `/name`. The prefix is the
+ * whole invocation: get it wrong and the agent reads a sentence that merely
+ * mentions a skill rather than a command that runs one — and being a capable
+ * model it will often do *something*, which is worse than failing, because the
+ * run looks successful while executing none of the skill's contract.
+ *
+ * Nothing downstream catches it either. The routine accepts any text, so the
+ * dispatch succeeds, a session identifier is recorded, and the ledger says the
+ * work was handed off. Only reading the session shows otherwise.
+ * @param {string} surface Execution surface.
+ * @param {string} skill Skill slug, without a prefix.
+ * @param {string} rest The payload the skill is invoked with.
+ * @returns {string} The thin invocation to send.
+ */
+export function buildInvocation(surface, skill, rest) {
+  const prefix = surface === "claude-web" ? "/" : "$";
+  return `${prefix}${skill} ${rest}`.trim();
+}
+
 async function main() {
   const { skill, raw } = splitSkillFlag(process.argv.slice(2));
   const { params, rest } = parseInvocation(raw);
@@ -432,7 +478,7 @@ async function main() {
   // The invocation stays thin on purpose. Every durable instruction lives in
   // the repository-local skill, so an interactive run, a scheduled run, and a
   // recovery run all execute one contract.
-  const prompt = `$${skill} ${rest}`.trim();
+  const prompt = buildInvocation(surface, skill, rest);
 
   if (surface === "claude-web") {
     const { sessionId, url } = await dispatchClaudeWeb(block, prompt, rest);

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

@@ -13,8 +13,8 @@ Prepare a remote surface so a host project can execute there. Today that means *
 The remote environment's own configuration fields stay **one line into the repository**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       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
-maintenance: 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
+setup:       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; }; exit "$rc"
+maintenance: 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; }; exit "$rc"
 ```
 
 **That line is identical for every project AND every surface.** Nothing in it names the
@@ -34,10 +34,18 @@ and neither mentions `$HOME`. An earlier version of this field used
 the checkout is not under `$HOME` at all: the glob matches nothing and bash reports
 `No such file or directory` for a path still containing a literal `*`.
 
-`exec` on the first hit means no subshell and no `ls` output to parse, and the explicit
-`exit 1` means a missing entrypoint says so rather than the field silently succeeding. The
-script then anchors itself on the repository root, so it behaves the same however it was
-reached.
+**Every** match is prepared, not the first. A Claude Code web environment can hold more than
+one checkout, and stopping at the first glob 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's secrets land under its own
+`secrets.namespace`, so preparing several is well defined rather than a collision.
+
+The exit status is the **first failure**, and every checkout is still attempted: one broken
+repository must not hide the state of the others, and it must not report success either.
+
+The explicit `exit 1` on `n=0` means a missing entrypoint says so rather than the field
+silently succeeding — a `for` loop over a glob that matches nothing otherwise exits `0`,
+which is the quiet failure this whole section exists to avoid.
 
 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.
 
@@ -156,8 +164,8 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      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
-Maintenance:       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
+Setup script:      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; }; exit "$rc"
+Maintenance:       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; }; exit "$rc"
                    (identical for every project — the script finds the
                    checkout and installs from the committed lockfile)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud

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

@@ -308,20 +308,29 @@ 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. `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.
+ * 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.
+ *
+ * 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.
  *
  * 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" ] && exec bash "$f"; done; ' +
-  'echo "lisa-remote-env entrypoint not found under $PWD" >&2; exit 1';
+  '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; }; ' +
+  'exit "$rc"';
 
 /**
  * The settings block that wires the session-start hook into a repository.

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-remote-dispatch/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-remote-dispatch
-description: "Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly."
+description: "Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly."
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
 
@@ -16,9 +16,12 @@ It changes **where** work happens and nothing about **what** happens. The remote
 | --- | --- |
 | omitted / `local` | The calling skill proceeds normally. Nothing is dispatched. |
 | `codex-cloud` | Submit to the project's Codex Cloud environment and return. |
+| `claude-web` | Fire the project's Claude routine, which starts a cloud session, and return. |
 
 Any other value is **rejected explicitly**. A silently ignored `executionEnv` would run the work locally while the operator believes it went remote, and nothing downstream would contradict that belief.
 
+For the same reason, the parameter is accepted as both `executionEnv=…` and `--executionEnv=…`, and a *dashed* parameter this skill does not recognise is an error rather than payload. The bare form is the documented one, but the dashed form is what anyone who has used a CLI will type, and a misspelling of either is indistinguishable from not asking at all — which is the one failure an operator cannot act on. A bare `key=value` still belongs to the payload, since prose may legitimately contain an equals sign.
+
 If a behaviour must differ between local and remote, it belongs in the calling skill as an explicit branch — never here. The moment this file starts encoding domain behaviour, there are two implementations to keep in sync.
 
 ## The invocation stays thin

package/plugins/lisa-agy/skills/lisa-remote-dispatch/scripts/dispatch.mjs

@@ -68,11 +68,25 @@ const LEDGER = join(".lisa", "remote-dispatch.json");
 /** This file's directory, for locating the sibling secrets skill. */
 const HERE = dirname(fileURLToPath(import.meta.url));
 
+/** Every parameter this program reads. Anything else is a typo. */
+const KNOWN_PARAMS = new Set(["executionEnv"]);
+
 /**
  * Split `key=value` parameters from the rest of an invocation.
  *
  * The remainder is passed through untouched. It is the caller's payload — a
  * ticket key, a description — and this program has no business interpreting it.
+ *
+ * A leading `--` is accepted and stripped. The bare form is the documented one,
+ * but `--executionEnv=claude-web` is what anyone who has used a CLI this decade
+ * types, and it previously fell through to the payload and left the surface at
+ * its default. That is precisely the outcome this skill says it exists to
+ * prevent: work runs locally while the operator believes it went remote, and
+ * nothing downstream contradicts them.
+ *
+ * An unrecognised parameter is rejected for the same reason. A misspelled
+ * `executionEnvv=claude-web` is indistinguishable from not asking at all, and
+ * silence is the one response that cannot be acted on.
  * @param {string} input Raw argument string.
  * @returns {{params: Record<string, string>, rest: string}} Parsed invocation.
  */
@@ -83,9 +97,19 @@ export function parseInvocation(input) {
     .trim()
     .split(/\s+/)
     .filter(Boolean)) {
-    const match = /^([A-Za-z][A-Za-z0-9_]*)=(.*)$/.exec(token);
-    if (match) params[match[1]] = match[2];
-    else rest.push(token);
+    const match = /^(--)?([A-Za-z][A-Za-z0-9_]*)=(.*)$/.exec(token);
+    // Only a dashed token is required to be a known parameter. A bare `x=y` may
+    // legitimately be part of a payload — a description, a query — and this
+    // program has no business rejecting the caller's prose.
+    if (match && (match[1] || KNOWN_PARAMS.has(match[2]))) {
+      if (!KNOWN_PARAMS.has(match[2])) {
+        throw new Error(
+          `unknown parameter "${match[2]}".\n` +
+            `Supported: ${[...KNOWN_PARAMS].join(", ")}.`
+        );
+      }
+      params[match[2]] = match[3];
+    } else rest.push(token);
   }
   return { params, rest: rest.join(" ") };
 }
@@ -416,6 +440,28 @@ function resolveBearerToken(block) {
   }
 }
 
+/**
+ * How each agent spells "run this skill".
+ *
+ * Codex invokes a skill with `$name`, Claude with `/name`. The prefix is the
+ * whole invocation: get it wrong and the agent reads a sentence that merely
+ * mentions a skill rather than a command that runs one — and being a capable
+ * model it will often do *something*, which is worse than failing, because the
+ * run looks successful while executing none of the skill's contract.
+ *
+ * Nothing downstream catches it either. The routine accepts any text, so the
+ * dispatch succeeds, a session identifier is recorded, and the ledger says the
+ * work was handed off. Only reading the session shows otherwise.
+ * @param {string} surface Execution surface.
+ * @param {string} skill Skill slug, without a prefix.
+ * @param {string} rest The payload the skill is invoked with.
+ * @returns {string} The thin invocation to send.
+ */
+export function buildInvocation(surface, skill, rest) {
+  const prefix = surface === "claude-web" ? "/" : "$";
+  return `${prefix}${skill} ${rest}`.trim();
+}
+
 async function main() {
   const { skill, raw } = splitSkillFlag(process.argv.slice(2));
   const { params, rest } = parseInvocation(raw);
@@ -432,7 +478,7 @@ async function main() {
   // The invocation stays thin on purpose. Every durable instruction lives in
   // the repository-local skill, so an interactive run, a scheduled run, and a
   // recovery run all execute one contract.
-  const prompt = `$${skill} ${rest}`.trim();
+  const prompt = buildInvocation(surface, skill, rest);
 
   if (surface === "claude-web") {
     const { sessionId, url } = await dispatchClaudeWeb(block, prompt, rest);

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

@@ -13,8 +13,8 @@ Prepare a remote surface so a host project can execute there. Today that means *
 The remote environment's own configuration fields stay **one line into the repository**. Nothing else is pasted into a vendor UI.
 
 ```text
-setup:       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
-maintenance: 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
+setup:       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; }; exit "$rc"
+maintenance: 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; }; exit "$rc"
 ```
 
 **That line is identical for every project AND every surface.** Nothing in it names the
@@ -34,10 +34,18 @@ and neither mentions `$HOME`. An earlier version of this field used
 the checkout is not under `$HOME` at all: the glob matches nothing and bash reports
 `No such file or directory` for a path still containing a literal `*`.
 
-`exec` on the first hit means no subshell and no `ls` output to parse, and the explicit
-`exit 1` means a missing entrypoint says so rather than the field silently succeeding. The
-script then anchors itself on the repository root, so it behaves the same however it was
-reached.
+**Every** match is prepared, not the first. A Claude Code web environment can hold more than
+one checkout, and stopping at the first glob 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's secrets land under its own
+`secrets.namespace`, so preparing several is well defined rather than a collision.
+
+The exit status is the **first failure**, and every checkout is still attempted: one broken
+repository must not hide the state of the others, and it must not report success either.
+
+The explicit `exit 1` on `n=0` means a missing entrypoint says so rather than the field
+silently succeeding — a `for` loop over a glob that matches nothing otherwise exits `0`,
+which is the quiet failure this whole section exists to avoid.
 
 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.
 
@@ -156,8 +164,8 @@ When emitting, produce exactly:
 ```text
 Environment name:  <project> remote executor
 Repository:        <org>/<repo>        (must be the default checkout)
-Setup script:      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
-Maintenance:       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
+Setup script:      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; }; exit "$rc"
+Maintenance:       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; }; exit "$rc"
                    (identical for every project — the script finds the
                    checkout and installs from the committed lockfile)
 Environment vars:  LISA_SECRETS_SURFACE=codex-cloud