@codyswann/lisa 4.33.12 → 4.33.14

package/plugins/lisa-agy/skills/lisa-track/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-track
-description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate."
+description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Also accepts human_gate: <why a human must judge this first>, which files the leaf held — outside the build-ready lane, never claimed — instead of build-ready. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -17,13 +17,14 @@ This flow must return exactly one canonical `(tracker_provider, work_item_ref)`
    - an explicit reference matching the configured tracker (`KEY-123`, `org/repo#123` or issue URL, Linear team identifier);
    - an existing file path containing a specification (read the entire file, without offset/limit);
    - plain-text work description.
-3. Preserve the full resolved specification for the caller. Do not treat a ticket-like token for a different provider/project as plain text; report the mismatch.
+3. Detect the caller's readiness declaration, which is orthogonal to the classification above. Absent any declaration this is the default build-ready path. A caller deliberately holding the work for a pending human product call passes `human_gate: "<why a human must judge this first>"`; the two declarations are mutually exclusive and a `human_gate` present but empty is a blocking error, because an unexplained hold is indistinguishable from an accident.
+4. Preserve the full resolved specification for the caller. Do not treat a ticket-like token for a different provider/project as plain text; report the mismatch.
 
 ## Phase 2 — Resolve one live work item
 
 ### Explicit reference
 
-Invoke `lisa-tracker-read <ref>` and require a live result from the configured project. Reject nonexistent, inaccessible, closed/resolved/terminal, wrong-project, wrong-repository, or container items. This live read is mandatory even if caller context already includes ticket text.
+Invoke `lisa-tracker-read <ref>` and require a live result from the configured project. Reject nonexistent, inaccessible, closed/resolved/terminal, wrong-project, wrong-repository, or container items. Read the returned body for the hold marker: an item carrying `[lisa-human-gate]` is held and Phase 3 refuses to claim it, whatever role or labels it carries. This live read is mandatory even if caller context already includes ticket text.
 
 ### File or plain text
 
@@ -34,15 +35,21 @@ Search conservatively before creating:
    - GitHub: `gh issue list --repo <org>/<repo> --state open --search "<keywords> in:title,body"`.
    - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL.
    - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace.
-3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, cross-repo, and materially different outcomes.
+3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, held-by-gate, cross-repo, and materially different outcomes. A held candidate is never reused: attaching new work to an item a human is holding is how the hold gets spent.
 4. Reuse only when **exactly one** live leaf is a high-confidence semantic match for the same requested outcome and repository. A shared keyword or similar title is not enough. Record the search queries, candidates, and rejection reasons in the returned resolution evidence.
-5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true`. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
+5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true` unless the caller declared a `human_gate`, in which case pass that `human_gate: "<why>"` reason instead of `build_ready: true` and never alongside it, so the writer leaves the leaf in the tracker's default backlog role — out of the lane build-intake claims from — and stamps the hold on the body as a `[lisa-human-gate]` marker. Discarding a declared gate and filing build-ready anyway is the one outcome this step must never produce. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
 6. Live-read the writer's canonical returned reference with `lisa-tracker-read`. A create response without a verified live leaf is failure.
 
 This is intentionally conservative: ambiguity creates one explicit work item instead of silently attaching work to the wrong existing item. Across the entire invocation, at most one new work item may be created.
 
 ## Phase 3 — Claim and bind
 
+The work item is **held** when either of two independent signals is present: the caller declared a `human_gate`, or the resolved item's body contains the literal `[lisa-human-gate]` marker. Test the marker as a plain substring and never key the parse on a `reason=` value — markers are written both with and without one, and a parser that requires the key misses the keyless ones while appearing to work.
+
+A held item stops the flow here, whatever the resolution outcome and whatever roles or labels the item carries. The marker is the authority: an item can be held while sitting in the build-ready role with no blocked or human-needed label, because a human stamping a hold on live work is the most likely way a gate is ever applied, and the vendor claim contracts reject a closed item or an active blocker but not a marked one. Do not invoke `lisa-tracker-claim`, do not write the worktree binding, and do not begin durable project work. Claiming a held leaf binds a live lane to it and makes it look already-attended, which suppresses exactly the human attention it was filed to attract. Return the structured result below with `claim_outcome: held-by-gate` and `binding_outcome: skipped-human-gate`, name which signal held it in `held_by` and carry the reason verbatim in `gate_reason` alongside the canonical reference, then stop. A marker written without a `reason=` key yields `gate_reason: null` — a missing reason narrows what the result can say, never whether the item is held.
+
+Otherwise:
+
 1. Invoke `lisa-tracker-claim <canonical-ref>`. Require its post-read verified `claim_outcome: claimed|reused`; no binding may be written after a failed/unverified claim.
 2. Persist only the canonical reference in worktree-local machine state:
 
@@ -58,8 +65,11 @@ This is intentionally conservative: ambiguity creates one explicit work item ins
    tracker_provider: jira|github|linear
    work_item_ref: <canonical-ref>
    resolution_outcome: explicit|reused|created
-   claim_outcome: claimed|reused
-   binding_outcome: verified
+   readiness_declaration: build-ready|human-gate
+   held_by: none|caller-declaration|item-marker
+   gate_reason: <why a human must judge this first>|null
+   claim_outcome: claimed|reused|held-by-gate
+   binding_outcome: verified|skipped-human-gate
    ```
 
 ## Lifecycle
@@ -68,4 +78,5 @@ This is intentionally conservative: ambiguity creates one explicit work item ins
 - Branch setup may call `node scripts/lisa-work-item.mjs attach-branch` after the feature branch exists.
 - Keep the binding across ordinary interruptions and blocked outcomes so resumed work remains attributable.
 - Clear it only after true terminal completion — merged, deployed/verified where required, tracker evidence/backlink complete, and the work item terminal — by running `node scripts/lisa-work-item.mjs clear` and verifying no current binding remains.
+- A held filing writes no binding at all, so there is nothing to clear. The gate is released by a human, not by this skill: a human removes the `[lisa-human-gate]` marker and flips the leaf into the build-ready role, and a later invocation then resolves it on the ordinary path.
 - A tracker outage, invalid item, failed claim, or failed binding blocks durable work. Never continue untracked and never ask a Git hook to create the item.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.33.12",
+  "version": "4.33.14",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.33.12",
+  "version": "4.33.14",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.33.12",
+  "version": "4.33.14",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.33.12",
+  "version": "4.33.14",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.33.12",
+  "version": "4.33.14",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/hooks/block-direct-issue-create.sh

@@ -269,8 +269,12 @@ FILE IT THE SANCTIONED WAY — one of these two, always explicit:
    bar — reproduction, observed-versus-expected, Gherkin acceptance criteria.
 
 2. A human product call is genuinely pending. Route the same way but pass
-   \`human_gate: "<why a human must judge this first>"\`, which stamps the hold
-   so it is auditable rather than indistinguishable from an accident:
+   \`human_gate: "<why a human must judge this first>"\` in place of
+   \`build_ready: true\` — the two are mutually exclusive. The leaf is filed
+   into the default backlog role, outside the lane build-intake claims from,
+   and is deliberately NOT claimed, so it keeps attracting the human attention
+   it was filed for. The hold is stamped so it is auditable rather than
+   indistinguishable from an accident:
 
      Held for a human product call: <reason>.
      <!-- [lisa-human-gate] reason=<short-slug> -->

package/plugins/lisa-copilot/hooks/parity-safety-net.sh

@@ -1019,14 +1019,40 @@ readonly GIT_CMD='(^|[^[:alnum:]_-])git[[:space:]]+'"$GIT_GLOBAL_OPTS"
 # match. The preceding-char class still excludes `.`, `/`, and `-` to keep
 # `--rm`-style flags and `foo.rm` names out.
 readonly RM_CMD='(^|[^[:alnum:]_./-])([[:alnum:]_./-]*/)?rm'
+# Where a recursive-forced flag cluster is allowed to END.
+#
+# It used to be `([[:space:]]|$)` — whitespace or end of segment — and a closing
+# parenthesis is neither, so a SUBSHELL-wrapped pipeline fell out of every guard
+# built on these two patterns while its brace-wrapped twin was caught: `{ find
+# .git -type d | parallel rm -rf; }` matched because the `;` supplied the
+# boundary, and `(find .git -type d | parallel rm -rf)` did not (issue #3494).
+#
+# So the two STATEMENT-GROUPING terminators join whitespace here, and nothing
+# else. The general spelling — "any character that cannot be part of a flag",
+# `([^[:alnum:]-]|$)` — is the more principled statement of the intent, and is
+# deliberately NOT used: these patterns feed the rm TARGET WALK, the guard with
+# this file's longest false-positive history, and it would newly match ordinary
+# prose punctuation (`echo "rm -rf, then …"` on the comma). Paren and semicolon
+# buy the brace/paren parity the defect is about and buy nothing else.
+#
+# The cluster must still END at the boundary, so `-rfoo` is not read as `-rf`.
+readonly RM_RF_END='([[:space:];)]|$)'
 # rm invoked with BOTH a recursive and a force flag — clustered (-rf/-fr, any
 # extra letters) or split, in either order. The split gate pairs ANY recursive
 # form (short cluster containing r, or --recursive) with ANY force form (short
 # cluster containing f, or --force), so mixed spellings like `rm -r --force /`
 # and `rm --recursive -f /` cannot slip between the short/short and long/long
 # alternations (PR #1976 review).
-readonly RM_RF_CLUSTER="$RM_CMD"'([[:space:]]+-[[:alnum:]-]+)*[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'
-readonly RM_RF_SPLIT="$RM_CMD"'(([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]]|$)|([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]]|$))'
+#
+# The FLAG TAILS are named separately from the `rm`-anchored patterns because
+# the find/xargs family below needs the identical flag vocabulary against a
+# different verb anchor. Before #3494 it carried its own short-cluster-only copy
+# and therefore missed `rm --recursive --force` — a divergence that could only
+# happen because the spelling set was written twice.
+readonly RM_RF_TAIL_CLUSTER='([[:space:]]+-[[:alnum:]-]+)*[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)'"$RM_RF_END"
+readonly RM_RF_TAIL_SPLIT='(([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)'"$RM_RF_END"'|([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)'"$RM_RF_END"')'
+readonly RM_RF_CLUSTER="$RM_CMD$RM_RF_TAIL_CLUSTER"
+readonly RM_RF_SPLIT="$RM_CMD$RM_RF_TAIL_SPLIT"
 
 # 1. Recursive forced delete (`rm -rf`) of a filesystem root, home, or top-level
 #    wildcard. Two gates ANDed: the statement must invoke `rm` with BOTH a
@@ -1667,8 +1693,31 @@ fi
 if matches '(^|[^[:alnum:]_./-])find[[:space:]][^;&|]*-exec[[:space:]]+rm[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'; then
   block "find -exec rm -rf performs a recursive forced delete on unreviewed paths"
 fi
-if matches '(^|[^[:alnum:]_./-])xargs[[:space:]]([^;&|]*[[:space:]])?rm[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'; then
-  block "xargs rm -rf performs a recursive forced delete on dynamic stdin input"
+# A command that reads its operands from STDIN and runs a program on them. The
+# targets are therefore whatever the upstream stage emitted, which is exactly
+# what makes a recursive forced delete behind one unauditable.
+#
+# Three fail-opens closed here (issue #3494), all of them the same mistake —
+# this rule was written standalone instead of inheriting vocabulary the file
+# already had:
+#
+#   1. The old prefix was `(^|[^[:alnum:]_./-])xargs`, whose excluded class
+#      contains `/`, so the character before `xargs` in `/usr/bin/xargs` was
+#      itself disqualifying and a PATH-SPELLED invocation never matched.
+#      `gxargs` — the GNU findutils spelling shipped by macOS package managers —
+#      failed the same way on the alphanumeric side. RM_CMD above solved this
+#      exact problem for `rm` by putting the boundary before the WHOLE path and
+#      making the directory part optional; that shape is reused verbatim.
+#   2. `parallel` was absent. It is a drop-in `xargs` substitute reaching the
+#      same delete on the same unaudited stdin, and guard 14 below already had
+#      to name it in its own evidence — it was missing only here.
+#   3. The flag set was a short-cluster-only copy, so `rm --recursive --force`
+#      was allowed where `rm -rf` was refused. It now uses the SAME tails as the
+#      rm walk, which is what makes that class of divergence unrepeatable.
+readonly STDIN_DELETER='(^|[^[:alnum:]_./-])([[:alnum:]_./-]*/)?(g?xargs|parallel)[[:space:]]([^;&|]*[[:space:]])?rm'
+if matches "$STDIN_DELETER$RM_RF_TAIL_CLUSTER" \
+  || matches "$STDIN_DELETER$RM_RF_TAIL_SPLIT"; then
+  block "xargs/parallel rm -rf performs a recursive forced delete on dynamic stdin input"
 fi
 
 # 12. Disk destroyers, always on (exceeds upstream, which only scans these

package/plugins/lisa-copilot/skills/lisa-setup-workstation/scripts/catalogue.mjs

@@ -121,6 +121,20 @@ export const PROVIDERS = [
         sha256:
           "18253757286e119d450133a87eb463bf8c1ce418ce24c834f4f250d60cba6f9e",
       },
+      // Bitwarden publishes macOS archives for the same tag, and omitting them
+      // made the one genuinely pinned credential CLI the one a macOS operator
+      // had to install by hand — the unverified path, for the tool where an
+      // unverified download matters most.
+      "darwin-arm64": {
+        url: "https://github.com/bitwarden/sdk-sm/releases/download/bws-v2.1.0/bws-aarch64-apple-darwin-2.1.0.zip",
+        sha256:
+          "9cb1c1c6e6164d83b2e339883ba02b4cbb37188ce9a484b1ce8249443163e066",
+      },
+      "darwin-x64": {
+        url: "https://github.com/bitwarden/sdk-sm/releases/download/bws-v2.1.0/bws-x86_64-apple-darwin-2.1.0.zip",
+        sha256:
+          "6f626b3971368902af1b9847c02791a1b4666969d7561e2047681cded7997537",
+      },
     },
   },
   {
@@ -197,11 +211,26 @@ export const TOOLS = [
           "12311e320d4cfdb54d7fa2d58cd1e3a2ccb4c12e1c3abb32b0a2e48bd0f991bf",
         binary: "gh_2.83.0_linux_arm64/bin/gh",
       },
+      // `install` is per-block for gh and only for gh: the vendor ships a
+      // .tar.gz for Linux and a .zip for macOS, so the entry-level `release-tar`
+      // is wrong for exactly these two. Without the override the resolved entry
+      // keeps `release-tar` and the installer runs `tar -xzf` over a ZIP, which
+      // fails during extraction — a macOS pin that resolves and cannot install.
       "darwin-arm64": {
         url: "https://github.com/cli/cli/releases/download/v2.83.0/gh_2.83.0_macOS_arm64.zip",
         sha256:
           "fecba907bc361d5e33620dbf1145f11432c39fb2b388a839463cfbb89a84820b",
         binary: "gh_2.83.0_macOS_arm64/bin/gh",
+        install: "release-zip",
+      },
+      // Intel Macs are still in service, and an Apple Silicon-only macOS block
+      // reads as "macOS is covered" while leaving half of it uncovered.
+      "darwin-x64": {
+        url: "https://github.com/cli/cli/releases/download/v2.83.0/gh_2.83.0_macOS_amd64.zip",
+        sha256:
+          "0c0de650752bb92d7283e386cafd03d9ac5f47028c648c4ab821ef08a75c0716",
+        binary: "gh_2.83.0_macOS_amd64/bin/gh",
+        install: "release-zip",
       },
     },
   },

package/plugins/lisa-copilot/skills/lisa-track/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-track
-description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate."
+description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Also accepts human_gate: <why a human must judge this first>, which files the leaf held — outside the build-ready lane, never claimed — instead of build-ready. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -17,13 +17,14 @@ This flow must return exactly one canonical `(tracker_provider, work_item_ref)`
    - an explicit reference matching the configured tracker (`KEY-123`, `org/repo#123` or issue URL, Linear team identifier);
    - an existing file path containing a specification (read the entire file, without offset/limit);
    - plain-text work description.
-3. Preserve the full resolved specification for the caller. Do not treat a ticket-like token for a different provider/project as plain text; report the mismatch.
+3. Detect the caller's readiness declaration, which is orthogonal to the classification above. Absent any declaration this is the default build-ready path. A caller deliberately holding the work for a pending human product call passes `human_gate: "<why a human must judge this first>"`; the two declarations are mutually exclusive and a `human_gate` present but empty is a blocking error, because an unexplained hold is indistinguishable from an accident.
+4. Preserve the full resolved specification for the caller. Do not treat a ticket-like token for a different provider/project as plain text; report the mismatch.
 
 ## Phase 2 — Resolve one live work item
 
 ### Explicit reference
 
-Invoke `lisa-tracker-read <ref>` and require a live result from the configured project. Reject nonexistent, inaccessible, closed/resolved/terminal, wrong-project, wrong-repository, or container items. This live read is mandatory even if caller context already includes ticket text.
+Invoke `lisa-tracker-read <ref>` and require a live result from the configured project. Reject nonexistent, inaccessible, closed/resolved/terminal, wrong-project, wrong-repository, or container items. Read the returned body for the hold marker: an item carrying `[lisa-human-gate]` is held and Phase 3 refuses to claim it, whatever role or labels it carries. This live read is mandatory even if caller context already includes ticket text.
 
 ### File or plain text
 
@@ -34,15 +35,21 @@ Search conservatively before creating:
    - GitHub: `gh issue list --repo <org>/<repo> --state open --search "<keywords> in:title,body"`.
    - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL.
    - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace.
-3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, cross-repo, and materially different outcomes.
+3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, held-by-gate, cross-repo, and materially different outcomes. A held candidate is never reused: attaching new work to an item a human is holding is how the hold gets spent.
 4. Reuse only when **exactly one** live leaf is a high-confidence semantic match for the same requested outcome and repository. A shared keyword or similar title is not enough. Record the search queries, candidates, and rejection reasons in the returned resolution evidence.
-5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true`. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
+5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true` unless the caller declared a `human_gate`, in which case pass that `human_gate: "<why>"` reason instead of `build_ready: true` and never alongside it, so the writer leaves the leaf in the tracker's default backlog role — out of the lane build-intake claims from — and stamps the hold on the body as a `[lisa-human-gate]` marker. Discarding a declared gate and filing build-ready anyway is the one outcome this step must never produce. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
 6. Live-read the writer's canonical returned reference with `lisa-tracker-read`. A create response without a verified live leaf is failure.
 
 This is intentionally conservative: ambiguity creates one explicit work item instead of silently attaching work to the wrong existing item. Across the entire invocation, at most one new work item may be created.
 
 ## Phase 3 — Claim and bind
 
+The work item is **held** when either of two independent signals is present: the caller declared a `human_gate`, or the resolved item's body contains the literal `[lisa-human-gate]` marker. Test the marker as a plain substring and never key the parse on a `reason=` value — markers are written both with and without one, and a parser that requires the key misses the keyless ones while appearing to work.
+
+A held item stops the flow here, whatever the resolution outcome and whatever roles or labels the item carries. The marker is the authority: an item can be held while sitting in the build-ready role with no blocked or human-needed label, because a human stamping a hold on live work is the most likely way a gate is ever applied, and the vendor claim contracts reject a closed item or an active blocker but not a marked one. Do not invoke `lisa-tracker-claim`, do not write the worktree binding, and do not begin durable project work. Claiming a held leaf binds a live lane to it and makes it look already-attended, which suppresses exactly the human attention it was filed to attract. Return the structured result below with `claim_outcome: held-by-gate` and `binding_outcome: skipped-human-gate`, name which signal held it in `held_by` and carry the reason verbatim in `gate_reason` alongside the canonical reference, then stop. A marker written without a `reason=` key yields `gate_reason: null` — a missing reason narrows what the result can say, never whether the item is held.
+
+Otherwise:
+
 1. Invoke `lisa-tracker-claim <canonical-ref>`. Require its post-read verified `claim_outcome: claimed|reused`; no binding may be written after a failed/unverified claim.
 2. Persist only the canonical reference in worktree-local machine state:
 
@@ -58,8 +65,11 @@ This is intentionally conservative: ambiguity creates one explicit work item ins
    tracker_provider: jira|github|linear
    work_item_ref: <canonical-ref>
    resolution_outcome: explicit|reused|created
-   claim_outcome: claimed|reused
-   binding_outcome: verified
+   readiness_declaration: build-ready|human-gate
+   held_by: none|caller-declaration|item-marker
+   gate_reason: <why a human must judge this first>|null
+   claim_outcome: claimed|reused|held-by-gate
+   binding_outcome: verified|skipped-human-gate
    ```
 
 ## Lifecycle
@@ -68,4 +78,5 @@ This is intentionally conservative: ambiguity creates one explicit work item ins
 - Branch setup may call `node scripts/lisa-work-item.mjs attach-branch` after the feature branch exists.
 - Keep the binding across ordinary interruptions and blocked outcomes so resumed work remains attributable.
 - Clear it only after true terminal completion — merged, deployed/verified where required, tracker evidence/backlink complete, and the work item terminal — by running `node scripts/lisa-work-item.mjs clear` and verifying no current binding remains.
+- A held filing writes no binding at all, so there is nothing to clear. The gate is released by a human, not by this skill: a human removes the `[lisa-human-gate]` marker and flips the leaf into the build-ready role, and a later invocation then resolves it on the ordinary path.
 - A tracker outage, invalid item, failed claim, or failed binding blocks durable work. Never continue untracked and never ask a Git hook to create the item.

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

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

package/plugins/lisa-cursor/hooks/block-direct-issue-create.sh

@@ -269,8 +269,12 @@ FILE IT THE SANCTIONED WAY — one of these two, always explicit:
    bar — reproduction, observed-versus-expected, Gherkin acceptance criteria.
 
 2. A human product call is genuinely pending. Route the same way but pass
-   \`human_gate: "<why a human must judge this first>"\`, which stamps the hold
-   so it is auditable rather than indistinguishable from an accident:
+   \`human_gate: "<why a human must judge this first>"\` in place of
+   \`build_ready: true\` — the two are mutually exclusive. The leaf is filed
+   into the default backlog role, outside the lane build-intake claims from,
+   and is deliberately NOT claimed, so it keeps attracting the human attention
+   it was filed for. The hold is stamped so it is auditable rather than
+   indistinguishable from an accident:
 
      Held for a human product call: <reason>.
      <!-- [lisa-human-gate] reason=<short-slug> -->

package/plugins/lisa-cursor/hooks/parity-safety-net.sh

@@ -1019,14 +1019,40 @@ readonly GIT_CMD='(^|[^[:alnum:]_-])git[[:space:]]+'"$GIT_GLOBAL_OPTS"
 # match. The preceding-char class still excludes `.`, `/`, and `-` to keep
 # `--rm`-style flags and `foo.rm` names out.
 readonly RM_CMD='(^|[^[:alnum:]_./-])([[:alnum:]_./-]*/)?rm'
+# Where a recursive-forced flag cluster is allowed to END.
+#
+# It used to be `([[:space:]]|$)` — whitespace or end of segment — and a closing
+# parenthesis is neither, so a SUBSHELL-wrapped pipeline fell out of every guard
+# built on these two patterns while its brace-wrapped twin was caught: `{ find
+# .git -type d | parallel rm -rf; }` matched because the `;` supplied the
+# boundary, and `(find .git -type d | parallel rm -rf)` did not (issue #3494).
+#
+# So the two STATEMENT-GROUPING terminators join whitespace here, and nothing
+# else. The general spelling — "any character that cannot be part of a flag",
+# `([^[:alnum:]-]|$)` — is the more principled statement of the intent, and is
+# deliberately NOT used: these patterns feed the rm TARGET WALK, the guard with
+# this file's longest false-positive history, and it would newly match ordinary
+# prose punctuation (`echo "rm -rf, then …"` on the comma). Paren and semicolon
+# buy the brace/paren parity the defect is about and buy nothing else.
+#
+# The cluster must still END at the boundary, so `-rfoo` is not read as `-rf`.
+readonly RM_RF_END='([[:space:];)]|$)'
 # rm invoked with BOTH a recursive and a force flag — clustered (-rf/-fr, any
 # extra letters) or split, in either order. The split gate pairs ANY recursive
 # form (short cluster containing r, or --recursive) with ANY force form (short
 # cluster containing f, or --force), so mixed spellings like `rm -r --force /`
 # and `rm --recursive -f /` cannot slip between the short/short and long/long
 # alternations (PR #1976 review).
-readonly RM_RF_CLUSTER="$RM_CMD"'([[:space:]]+-[[:alnum:]-]+)*[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'
-readonly RM_RF_SPLIT="$RM_CMD"'(([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]]|$)|([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]]|$))'
+#
+# The FLAG TAILS are named separately from the `rm`-anchored patterns because
+# the find/xargs family below needs the identical flag vocabulary against a
+# different verb anchor. Before #3494 it carried its own short-cluster-only copy
+# and therefore missed `rm --recursive --force` — a divergence that could only
+# happen because the spelling set was written twice.
+readonly RM_RF_TAIL_CLUSTER='([[:space:]]+-[[:alnum:]-]+)*[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)'"$RM_RF_END"
+readonly RM_RF_TAIL_SPLIT='(([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)'"$RM_RF_END"'|([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)'"$RM_RF_END"')'
+readonly RM_RF_CLUSTER="$RM_CMD$RM_RF_TAIL_CLUSTER"
+readonly RM_RF_SPLIT="$RM_CMD$RM_RF_TAIL_SPLIT"
 
 # 1. Recursive forced delete (`rm -rf`) of a filesystem root, home, or top-level
 #    wildcard. Two gates ANDed: the statement must invoke `rm` with BOTH a
@@ -1667,8 +1693,31 @@ fi
 if matches '(^|[^[:alnum:]_./-])find[[:space:]][^;&|]*-exec[[:space:]]+rm[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'; then
   block "find -exec rm -rf performs a recursive forced delete on unreviewed paths"
 fi
-if matches '(^|[^[:alnum:]_./-])xargs[[:space:]]([^;&|]*[[:space:]])?rm[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'; then
-  block "xargs rm -rf performs a recursive forced delete on dynamic stdin input"
+# A command that reads its operands from STDIN and runs a program on them. The
+# targets are therefore whatever the upstream stage emitted, which is exactly
+# what makes a recursive forced delete behind one unauditable.
+#
+# Three fail-opens closed here (issue #3494), all of them the same mistake —
+# this rule was written standalone instead of inheriting vocabulary the file
+# already had:
+#
+#   1. The old prefix was `(^|[^[:alnum:]_./-])xargs`, whose excluded class
+#      contains `/`, so the character before `xargs` in `/usr/bin/xargs` was
+#      itself disqualifying and a PATH-SPELLED invocation never matched.
+#      `gxargs` — the GNU findutils spelling shipped by macOS package managers —
+#      failed the same way on the alphanumeric side. RM_CMD above solved this
+#      exact problem for `rm` by putting the boundary before the WHOLE path and
+#      making the directory part optional; that shape is reused verbatim.
+#   2. `parallel` was absent. It is a drop-in `xargs` substitute reaching the
+#      same delete on the same unaudited stdin, and guard 14 below already had
+#      to name it in its own evidence — it was missing only here.
+#   3. The flag set was a short-cluster-only copy, so `rm --recursive --force`
+#      was allowed where `rm -rf` was refused. It now uses the SAME tails as the
+#      rm walk, which is what makes that class of divergence unrepeatable.
+readonly STDIN_DELETER='(^|[^[:alnum:]_./-])([[:alnum:]_./-]*/)?(g?xargs|parallel)[[:space:]]([^;&|]*[[:space:]])?rm'
+if matches "$STDIN_DELETER$RM_RF_TAIL_CLUSTER" \
+  || matches "$STDIN_DELETER$RM_RF_TAIL_SPLIT"; then
+  block "xargs/parallel rm -rf performs a recursive forced delete on dynamic stdin input"
 fi
 
 # 12. Disk destroyers, always on (exceeds upstream, which only scans these

package/plugins/lisa-cursor/skills/lisa-setup-workstation/scripts/catalogue.mjs

@@ -121,6 +121,20 @@ export const PROVIDERS = [
         sha256:
           "18253757286e119d450133a87eb463bf8c1ce418ce24c834f4f250d60cba6f9e",
       },
+      // Bitwarden publishes macOS archives for the same tag, and omitting them
+      // made the one genuinely pinned credential CLI the one a macOS operator
+      // had to install by hand — the unverified path, for the tool where an
+      // unverified download matters most.
+      "darwin-arm64": {
+        url: "https://github.com/bitwarden/sdk-sm/releases/download/bws-v2.1.0/bws-aarch64-apple-darwin-2.1.0.zip",
+        sha256:
+          "9cb1c1c6e6164d83b2e339883ba02b4cbb37188ce9a484b1ce8249443163e066",
+      },
+      "darwin-x64": {
+        url: "https://github.com/bitwarden/sdk-sm/releases/download/bws-v2.1.0/bws-x86_64-apple-darwin-2.1.0.zip",
+        sha256:
+          "6f626b3971368902af1b9847c02791a1b4666969d7561e2047681cded7997537",
+      },
     },
   },
   {
@@ -197,11 +211,26 @@ export const TOOLS = [
           "12311e320d4cfdb54d7fa2d58cd1e3a2ccb4c12e1c3abb32b0a2e48bd0f991bf",
         binary: "gh_2.83.0_linux_arm64/bin/gh",
       },
+      // `install` is per-block for gh and only for gh: the vendor ships a
+      // .tar.gz for Linux and a .zip for macOS, so the entry-level `release-tar`
+      // is wrong for exactly these two. Without the override the resolved entry
+      // keeps `release-tar` and the installer runs `tar -xzf` over a ZIP, which
+      // fails during extraction — a macOS pin that resolves and cannot install.
       "darwin-arm64": {
         url: "https://github.com/cli/cli/releases/download/v2.83.0/gh_2.83.0_macOS_arm64.zip",
         sha256:
           "fecba907bc361d5e33620dbf1145f11432c39fb2b388a839463cfbb89a84820b",
         binary: "gh_2.83.0_macOS_arm64/bin/gh",
+        install: "release-zip",
+      },
+      // Intel Macs are still in service, and an Apple Silicon-only macOS block
+      // reads as "macOS is covered" while leaving half of it uncovered.
+      "darwin-x64": {
+        url: "https://github.com/cli/cli/releases/download/v2.83.0/gh_2.83.0_macOS_amd64.zip",
+        sha256:
+          "0c0de650752bb92d7283e386cafd03d9ac5f47028c648c4ab821ef08a75c0716",
+        binary: "gh_2.83.0_macOS_amd64/bin/gh",
+        install: "release-zip",
       },
     },
   },

package/plugins/lisa-cursor/skills/lisa-track/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-track
-description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate."
+description: "Resolves exactly one live configured-tracker leaf for durable project work, claims it idempotently, and persists its canonical reference in worktree-local state. Accepts an existing Jira/GitHub/Linear ref, a spec file, or plain text. Also accepts human_gate: <why a human must judge this first>, which files the leaf held — outside the build-ready lane, never claimed — instead of build-ready. Use directly to mention/create the related ticket, and as lisa-implement's mandatory input gate."
 allowed-tools: ["Skill", "Bash", "Read"]
 ---
 
@@ -17,13 +17,14 @@ This flow must return exactly one canonical `(tracker_provider, work_item_ref)`
    - an explicit reference matching the configured tracker (`KEY-123`, `org/repo#123` or issue URL, Linear team identifier);
    - an existing file path containing a specification (read the entire file, without offset/limit);
    - plain-text work description.
-3. Preserve the full resolved specification for the caller. Do not treat a ticket-like token for a different provider/project as plain text; report the mismatch.
+3. Detect the caller's readiness declaration, which is orthogonal to the classification above. Absent any declaration this is the default build-ready path. A caller deliberately holding the work for a pending human product call passes `human_gate: "<why a human must judge this first>"`; the two declarations are mutually exclusive and a `human_gate` present but empty is a blocking error, because an unexplained hold is indistinguishable from an accident.
+4. Preserve the full resolved specification for the caller. Do not treat a ticket-like token for a different provider/project as plain text; report the mismatch.
 
 ## Phase 2 — Resolve one live work item
 
 ### Explicit reference
 
-Invoke `lisa-tracker-read <ref>` and require a live result from the configured project. Reject nonexistent, inaccessible, closed/resolved/terminal, wrong-project, wrong-repository, or container items. This live read is mandatory even if caller context already includes ticket text.
+Invoke `lisa-tracker-read <ref>` and require a live result from the configured project. Reject nonexistent, inaccessible, closed/resolved/terminal, wrong-project, wrong-repository, or container items. Read the returned body for the hold marker: an item carrying `[lisa-human-gate]` is held and Phase 3 refuses to claim it, whatever role or labels it carries. This live read is mandatory even if caller context already includes ticket text.
 
 ### File or plain text
 
@@ -34,15 +35,21 @@ Search conservatively before creating:
    - GitHub: `gh issue list --repo <org>/<repo> --state open --search "<keywords> in:title,body"`.
    - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL.
    - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace.
-3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, cross-repo, and materially different outcomes.
+3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, held-by-gate, cross-repo, and materially different outcomes. A held candidate is never reused: attaching new work to an item a human is holding is how the hold gets spent.
 4. Reuse only when **exactly one** live leaf is a high-confidence semantic match for the same requested outcome and repository. A shared keyword or similar title is not enough. Record the search queries, candidates, and rejection reasons in the returned resolution evidence.
-5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true`. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
+5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true` unless the caller declared a `human_gate`, in which case pass that `human_gate: "<why>"` reason instead of `build_ready: true` and never alongside it, so the writer leaves the leaf in the tracker's default backlog role — out of the lane build-intake claims from — and stamps the hold on the body as a `[lisa-human-gate]` marker. Discarding a declared gate and filing build-ready anyway is the one outcome this step must never produce. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
 6. Live-read the writer's canonical returned reference with `lisa-tracker-read`. A create response without a verified live leaf is failure.
 
 This is intentionally conservative: ambiguity creates one explicit work item instead of silently attaching work to the wrong existing item. Across the entire invocation, at most one new work item may be created.
 
 ## Phase 3 — Claim and bind
 
+The work item is **held** when either of two independent signals is present: the caller declared a `human_gate`, or the resolved item's body contains the literal `[lisa-human-gate]` marker. Test the marker as a plain substring and never key the parse on a `reason=` value — markers are written both with and without one, and a parser that requires the key misses the keyless ones while appearing to work.
+
+A held item stops the flow here, whatever the resolution outcome and whatever roles or labels the item carries. The marker is the authority: an item can be held while sitting in the build-ready role with no blocked or human-needed label, because a human stamping a hold on live work is the most likely way a gate is ever applied, and the vendor claim contracts reject a closed item or an active blocker but not a marked one. Do not invoke `lisa-tracker-claim`, do not write the worktree binding, and do not begin durable project work. Claiming a held leaf binds a live lane to it and makes it look already-attended, which suppresses exactly the human attention it was filed to attract. Return the structured result below with `claim_outcome: held-by-gate` and `binding_outcome: skipped-human-gate`, name which signal held it in `held_by` and carry the reason verbatim in `gate_reason` alongside the canonical reference, then stop. A marker written without a `reason=` key yields `gate_reason: null` — a missing reason narrows what the result can say, never whether the item is held.
+
+Otherwise:
+
 1. Invoke `lisa-tracker-claim <canonical-ref>`. Require its post-read verified `claim_outcome: claimed|reused`; no binding may be written after a failed/unverified claim.
 2. Persist only the canonical reference in worktree-local machine state:
 
@@ -58,8 +65,11 @@ This is intentionally conservative: ambiguity creates one explicit work item ins
    tracker_provider: jira|github|linear
    work_item_ref: <canonical-ref>
    resolution_outcome: explicit|reused|created
-   claim_outcome: claimed|reused
-   binding_outcome: verified
+   readiness_declaration: build-ready|human-gate
+   held_by: none|caller-declaration|item-marker
+   gate_reason: <why a human must judge this first>|null
+   claim_outcome: claimed|reused|held-by-gate
+   binding_outcome: verified|skipped-human-gate
    ```
 
 ## Lifecycle
@@ -68,4 +78,5 @@ This is intentionally conservative: ambiguity creates one explicit work item ins
 - Branch setup may call `node scripts/lisa-work-item.mjs attach-branch` after the feature branch exists.
 - Keep the binding across ordinary interruptions and blocked outcomes so resumed work remains attributable.
 - Clear it only after true terminal completion — merged, deployed/verified where required, tracker evidence/backlink complete, and the work item terminal — by running `node scripts/lisa-work-item.mjs clear` and verifying no current binding remains.
+- A held filing writes no binding at all, so there is nothing to clear. The gate is released by a human, not by this skill: a human removes the `[lisa-human-gate]` marker and flips the leaf into the build-ready role, and a later invocation then resolves it on the ordinary path.
 - A tracker outage, invalid item, failed claim, or failed binding blocks durable work. Never continue untracked and never ask a Git hook to create the item.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.33.12",
+  "version": "4.33.14",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.33.12",
+  "version": "4.33.14",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.33.12",
+  "version": "4.33.14",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"