@codyswann/lisa 4.55.1 → 4.55.3

package/plugins/lisa-agy/skills/lisa-linear-verify/SKILL.md

@@ -63,20 +63,3 @@ normalize-then-compare. Byte-exact comparison of such text is forbidden.
 - Never write to Linear. Read-only.
 - Never short-circuit the validator. Always run the full gate set.
 - If `get_issue` / `get_project` returns an access error, surface it and exit — don't pretend the item is fine.
-
-## Comparison is semantic, never byte-exact
-
-Re-run the validator against the live issue. Do NOT compare the stored body
-against what was sent byte for byte.
-
-The reason is measured rather than theoretical. Trackers normalize markdown on
-write: `-` bullets become `*`, a bare URL is wrapped as `[url](<url>)`, bold
-emphasis is re-segmented around inline code spans. All lossless, all
-rendering-identical, and all of it makes a byte comparator report failure on a
-write that was completely fine. A comparator that cannot tell vendor
-normalization from corruption fails on healthy writes and trains its reader to
-ignore it, which costs more than the check was ever worth.
-
-Compare meaning: run `lisa-linear-validate-issue` against the stored item and let the gates
-decide. Where a single field must be compared directly, normalize both sides
-first.

package/plugins/lisa-agy/skills/lisa-linear-write-issue/SKILL.md

@@ -33,40 +33,7 @@ Linear's data model maps Epic / Story / Sub-task to **different entity types**.
 
 The build lifecycle uses native **workflow states** (`Ready`, `In Progress`, `Blocked`, `On Dev`, `On Stg`, `Done`, plus an optional review state a project may bind), resolved per role from `linear.workflow` — see "Why Linear uses states, not labels" in `config-resolution`. A new **leaf** work unit is created in the configured `ready` state only on explicit `build_ready: true`; omitted or `false` leaves it in the team's default backlog state, and a container is never put in `ready` at all (see the Build-ready control input below).
 
-## Writing by another path? The gates still apply
-
-A team that talks to its tracker through its own script is doing a normal
-thing — the script usually owns the credential plumbing, and Lisa neither
-controls nor wants to control it. What that script does NOT get is either half
-of this skill's quality gate, and nothing about the write says so.
-
-**A read-back is not the missing check.** A bespoke path almost always re-reads
-the issue after writing and confirms the tracker stored what was sent. That is
-worth doing and it is not this. It proves TRANSPORT: the API accepted the
-payload and the field values round-tripped. It cannot fail for the reason these
-gates exist, because it never looks at whether what was sent was any good — a
-issue with no acceptance criteria, no parent, and a human decision left sitting
-in the middle of it round-trips perfectly. That is the dangerous half of the
-shape: a failing control gets investigated, a misread one gets trusted.
-
-So a write by any other path still owes both phases, and both run standalone
-against an item that already exists:
-
-| Phase | Skill | What it costs you |
-|---|---|---|
-| Pre-write validate | `lisa-linear-validate-issue` | Run it on the draft before you send it |
-| Post-write verify | `lisa-linear-verify` | Run it on the live issue after you send it |
-
-```text
-Skill(lisa-linear-validate-issue) with the draft issue, or with a reference to a live one
-Skill(lisa-linear-verify) with ENG-1234
-```
-
-**These are plugin-resident skills invoked through the Skill tool.** They are
-not shell scripts and will not appear in any repository's `scripts/` directory,
-including yours. An agent that searches the repo it is standing in, finds
-nothing, and concludes the capability is absent has made the one mistake that
-turns a local script from the convenient option into the only one.
+For direct API or bespoke script writes, the [bespoke-path contract](#writing-by-a-bespoke-path-your-own-script-direct-api-or-graphql) still requires pre-write validation and post-write verification.
 
 ## Phase 1 — Resolve Intent
 
@@ -334,6 +301,8 @@ person scanning a board and to any path that has not yet been routed through the
 If the label does not exist in the tracker, create it, or record that it could not be applied and
 proceed — the marker still holds. Never file the label *instead of* the marker.
 
+**Every marker reader must consult comments.** Use `classifyReadyCandidate` with labels, body, comments and the configured human-needed label, then `planHumanGateRelease` for any release actions. A historical body marker alone is not an active hold after its matching release; unreadable comments leave a hold in place.
+
 **Write a `reason=` the release can name.** The hold's reason is not decoration: a hold ends when a
 `[lisa-human-gate-release]` comment repeating that same `reason=` is recorded on the item, and the
 next intake sweep then takes the marker label off and puts the item back in the build-ready role on

package/plugins/lisa-agy/skills/lisa-prd-ticket-coverage/SKILL.md

@@ -15,7 +15,7 @@ The PRD URL can be a **Notion page URL**, a **Confluence page URL**, a **Linear
 
 - `notion.so` / `notion.site` → Notion. Fetch with `mcp__claude_ai_Notion__notion-fetch` (`include_discussions: true`) and `mcp__claude_ai_Notion__notion-get-comments`.
 - Atlassian Confluence host (e.g. `*.atlassian.net/wiki/...`) → Confluence. Through `lisa-atlassian-access`, fetch the page, its descendants (for child epic pages), and its footer + inline comments including nested replies. State the operation, not a vendor tool name — the access skill owns substrate selection (`integration-access-layer`).
-- `linear.app` host → Linear. Fetch with `lisa-linear-access operation: get-project` (capture description, labels, state, attached resources), `lisa-linear-access operation: list-documents({projectId})` + `lisa-linear-access operation: get-document` per attached document, `lisa-linear-access operation: list-issues({project})` for sub-issues that act as child epics / user stories, and `lisa-linear-access operation: list-comments({issueId})` per sub-issue for decisions and engineering notes. Comments do not exist on the project itself in the MCP surface — sub-issue comments are the substitute.
+- `linear.app` host → Linear. Fetch with `lisa-linear-access operation: get-project` (capture description, labels, state, attached resources), `lisa-linear-access operation: list-documents({projectId})` + `lisa-linear-access operation: get-document` per attached document, `lisa-linear-access operation: list-issues({project})` for sub-issues that act as child epics / user stories, and `lisa-linear-access operation: list-comments({issueId})` per sub-issue for decisions and engineering notes. Also fetch all project comments with `lisa-linear-access operation: list-comments project_id:<ID>`; the access layer pages through GraphQL even when the MCP lacks project comments. An incomplete comment read is an access failure, not an empty history.
 - `github.com` host → GitHub Issues. Fetch with the `gh` CLI (no GitHub MCP — Lisa uses the CLI exclusively for GitHub):
   - `gh issue view <number> --repo <org>/<repo> --json number,title,body,labels,milestone,assignees,author,createdAt,comments,url` for the PRD body and comments.
   - `gh api graphql` with the `subIssues` field for native sub-issue children (these stand in for child epic pages — see `lisa-github-read-issue` Phase 3 for the exact query).
@@ -41,7 +41,7 @@ Per-ticket gates (`lisa-jira-validate-ticket`) prove each created ticket is well
 2. Fetch the PRD using the vendor-appropriate tool surface:
    - **Notion**: `notion-fetch` with `include_discussions: true`. Capture: title, body, child Epic pages, all comment threads.
    - **Confluence**: `getConfluencePage` (capture title, body, labels), `getConfluencePageFooterComments` + `getConfluencePageInlineComments` (capture all comments; walk replies via `getConfluenceCommentChildren` for any thread with children).
-   - **Linear**: `get_project` (capture name, description, labels, state, attached resources). Capture sub-issues via `list_issues({project})` and per-issue comments via `list_comments({issueId})`.
+   - **Linear**: `get_project` (capture name, description, labels, state, attached resources). Capture all project comments via `lisa-linear-access operation: list-comments project_id:<ID>`, plus sub-issues via `list_issues({project})` and per-issue comments via `list_comments({issueId})`. Include both comment sources in destination URL discovery; refuse to report `NO_TICKETS_FOUND` from an incomplete read.
    - **GitHub**: `gh issue view --json` for the source PRD issue (title, body, labels, comments). Capture sub-issues via the GraphQL `subIssues` traversal.
 3. If the PRD has child Epic sub-pages / sub-issues (a multi-epic PRD), fetch each in parallel:
    - **Notion**: `notion-fetch` per child page with `include_discussions: true`.

package/plugins/lisa-agy/skills/lisa-repair-intake/SKILL.md

@@ -189,7 +189,7 @@ In addition to the lifecycle roles above, the build lifecycle defines the **`hum
 - The blocks repair-intake **itself writes** are the auto-recoverable kind — it files a build-ready fix ticket and moves the item `blocked` *blocked by that ticket*, expecting the next cycle to self-heal. Those are **not** `human_needed`; if such an item arrives carrying a `human_needed` marker **this skill applied on an earlier cycle**, repair-intake **clears** it (the block is no longer waiting on a human).
 - **Never remove a `human_needed` marker this skill did not apply.** "Stale" is a judgment about the block's kind, not about who applied the marker or when — so without this rule an operator's deliberate hold, applied *after* correcting a wrong transition, is indistinguishable from a leftover the sweep is designed to clear, and gets swept. Establish provenance from the label event's actor (`rejection-detection` **Automation-reversal memory** reads the same surfaces); if provenance is not readable, **leave the marker in place**. Removing a human's hold is unrecoverable within the loop; leaving a stale one costs a cycle and is visible.
 - **The one exception is a hold that has recorded its own discharge.** A `[lisa-human-gate-release]` comment naming the hold's `reason=` is not a guess about provenance — it is the hold's stated void condition, recorded on the item by the person who answered it. Clearing the marker there is not overriding a human's judgment; it is *enacting* it. That is the whole of the exception: no other reading of "this looks stale" reopens the question above, and an item whose release cannot be read stays held. See "Release the holds that have been answered" below (#3852).
-- The marker is consulted **before **any** repair transition**, not only before Class C. Class C's hard stop is the strictest reading of it, but a marker that is honoured on one classification path and ignored on the other three is not a guard — and Class A, dependency clearing, is exactly the path an operator reverting a wrongly-cleared blocker is trying to protect. Match it robustly (hyphen/underscore, case-insensitive, label set and note prose) wherever it is read.
+- The marker is consulted **before **any** repair transition**, not only before Class C. Class C's hard stop is the strictest reading of it, but a marker that is honoured on one classification path and ignored on the other three is not a guard — and Class A, dependency clearing, is exactly the path an operator reverting a wrongly-cleared blocker is trying to protect. Read all comments and consult `classifyReadyCandidate` / `planHumanGateRelease` before treating the marker as active; a matching release discharges the historical body marker. Use the shared helpers for robust label and declaration matching, and leave unreadable releases held.
 - The blocks the **vendor agent** writes when repair-intake re-dispatches it (its pre-flight gate) carry `human_needed` already — the agent owns that marker. repair-intake leaves it in place.
 
 Resolve with the standard role-read pattern (local overrides global, default fallback):
@@ -621,6 +621,41 @@ the item open. Recording "the fix reached dev and production but skipped staging
 branch back-fill, not outstanding delivery" and then closing anyway is this defect exactly — the
 condition observed, filed under the wrong heading, and overridden.
 
+### Resolve the shipped blocker-edge module
+
+The helper ships in the plugin and npm package. Only the runtime-supplied plugin roots
+and installed package are trusted here; do not search arbitrary checkout-local plugin folders.
+Write the evaluated edge inputs to a JSON array file, then call `blocker_edge_decisions`.
+An absent module, unreadable input or import failure stops this repair without tracker writes.
+
+```bash
+resolve_blocker_guard() {
+  local candidate
+  for candidate in \
+    "${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/scripts/blocker-edge-resolution.mjs}" \
+    "${PLUGIN_ROOT:+$PLUGIN_ROOT/scripts/blocker-edge-resolution.mjs}" \
+    node_modules/@codyswann/lisa/plugins/lisa/scripts/blocker-edge-resolution.mjs; do
+    [ -n "$candidate" ] && [ -f "$candidate" ] && { printf '%s\n' "$candidate"; return; }
+  done
+  echo "Error: could not locate blocker-edge-resolution.mjs; refusing repair." >&2
+  return 1
+}
+
+blocker_edge_decisions() {  # JSON array file -> decision object
+  local guard
+  guard=$(resolve_blocker_guard) || return 1
+  node --input-type=module - "$guard" "$1" <<'LISA_BLOCKER_NODE'
+import { readFileSync } from "node:fs";
+import { resolve } from "node:path";
+import { pathToFileURL } from "node:url";
+const { resolveBlockerEdges } = await import(pathToFileURL(resolve(process.argv[2])).href);
+const edges = JSON.parse(readFileSync(process.argv[3], "utf8"));
+if (!Array.isArray(edges)) throw new Error("Expected an array of blocker edges");
+console.log(JSON.stringify(resolveBlockerEdges(edges)));
+LISA_BLOCKER_NODE
+}
+```
+
 ### Build `blocked` → re-evaluate, unblock if cleared
 
 1. Read the block reason and classify the blocker (see Blocker classification & clearing). An item
@@ -629,8 +664,11 @@ condition observed, filed under the wrong heading, and overridden.
    Re-check **every** class present — do not stop at "no `is blocked by` links, therefore nothing
    to do." A self-block has zero dependencies by definition, yet is fully re-checkable.
 2. **Dependency cleared** — decide each parsed `is blocked by` edge with
-   `scripts/blocker-edge-resolution.mjs`, feeding it the `blocker-containment` verdict plus the
-   blocker's state and closure reason. It returns `dissolve` / `keep` / `escalate` per edge.
+   the shipped plugin helper `scripts/blocker-edge-resolution.mjs`, feeding it the
+   `blocker-containment` verdict plus the blocker's state and closure reason. This is a module,
+   not a CLI and not a required host `scripts/` file. Resolve a trusted plugin/package path and
+   invoke `resolveBlockerEdges` as shown above; never create a second resolver in the host.
+   It returns `dissolve` / `keep` / `escalate` per edge.
    **Dissolve the edge in the SAME write that records the ruling, then read the relation back and
    confirm it is gone.** Only when every edge dissolves → move `blocked → claimed`, then run the
    same agent-dispatch + post-agent `claimed → done` sequence as the stalled-`claimed` path above
@@ -1033,7 +1071,7 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    `intake_mode=build`, every non-PRD issue is normalized as a build ticket. If `intake_mode=both`,
    classify PRDs first and normalize all remaining issues as build tickets.
 2a. **Ask whether a person is holding it, before anything else.** Call
-   `planLabelNormalization({ labels, body, humanNeededLabel, lifecycleLabels, readyLabel })` from
+   `planLabelNormalization({ labels, body, comments, humanNeededLabel, lifecycleLabels, readyLabel })` from
    `scripts/intake-blocker-reprobe.mjs` for every candidate and apply exactly the verdict it
    returns. Do **not** re-implement the test here and do **not** decide held-ness from labels
    alone: the vendor writers stamp the `[lisa-human-gate]` marker into the body of a deliberate
@@ -1187,9 +1225,11 @@ layer, and test ancestry against the remote.
   remote, ancestry query errored) → **still blocking**, with the rule's reason key in the run
   record.
 - **Ships no code** — the blocker is closed as completed, positively declares
-  `Target Backend Environment: None — no runtime behavior change`, and has no merged PR →
+  `## Target Backend Environment` reading `None — no runtime behavior change: <kind>`
+  with kind `doc-only`, `config-only`, or `type-only`, and has no linked PR and no merge commit →
   **cleared** under the rule's carve-out. This is a positive determination, never an absence:
-  "no PR found" is `no-pr` and stays blocking.
+  "no PR found" is `no-pr` and stays blocking. A missing kind does not qualify; any linked
+  open or unmerged PR stays blocking under the normal containment test.
 - **Human override** — an explicit human statement on this item that the dependency is satisfied
   clears it and outranks a failed containment check. Name it in the run record.
 - **Human hold** — the override runs in both directions. `human_needed` is checked here as well as

package/plugins/lisa-agy/skills/lisa-rework-triage/SKILL.md

@@ -53,7 +53,8 @@ first-attempt work.
    # bundle.json: { "labels": [...], "comments": [<bodies, oldest first>], "role": "<current>" }
    ```
 
-   Branch on `action`, never on the label being there:
+   Branch on `outcome`, never on the label being there. The resolver's separate
+   `action` field is `keep` / `clear` / `none`; it is not the liveness verdict:
 
    | `outcome` | Meaning | What triage does |
    |---|---|---|

package/plugins/lisa-agy/skills/lisa-secrets-access/scripts/providers.mjs

@@ -743,7 +743,8 @@ export function createCoordinationRecord(cfg, key, projectId, note) {
         "--output",
         "json",
       ],
-      env
+      env,
+      "creating a coordination record in Bitwarden"
     );
     const created = JSON.parse(raw);
     return {

package/plugins/lisa-agy/skills/lisa-setup-linear/SKILL.md

@@ -357,7 +357,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
 [ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
 ```
 
-Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
+Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list-project-labels` for `prd-*` (including the terminal `prd-verified`) when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
 
 ## Idempotency
 

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

@@ -70,7 +70,7 @@ const BLOCKING = new Set(["missing", "invalid"]);
 /**
  * Whether an unpinnable entry is nonetheless usable on this machine.
  *
- * Presence-only, and deliberately not a skip. Dropping the entry entirely would
+ * Executability is required, even when no version floor is declared. Dropping the entry entirely would
  * report clean for a tool that is neither pinned nor installed, which is the
  * vacuous green this module refuses everywhere else. So the probe still decides
  * — it just gets asked, which on this branch it previously never was.
@@ -83,7 +83,12 @@ const BLOCKING = new Set(["missing", "invalid"]);
  * @returns {boolean} Whether the tool is present and good enough to use.
  */
 function usableWithoutPin(step, minVersions) {
-  if (!step.unpinnedForPlatform || !step.found?.present) return false;
+  if (
+    !step.unpinnedForPlatform ||
+    !step.found?.present ||
+    step.found.executable !== true
+  )
+    return false;
   const floor = minVersions[step.name];
   return !floor || compareVersions(step.found.version ?? "0", floor) >= 0;
 }

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

@@ -120,7 +120,7 @@ export function readRemoteEnvConfig(cwd = process.cwd()) {
  * on which quirky binaries happen to exist on the machine running the tests.
  * @param {string} name Executable name.
  * @param {Function} [exec] Command runner, for tests.
- * @returns {{version: string|null, present: boolean}} Probe result.
+ * @returns {{version: string|null, present: boolean, executable: boolean}} Probe result.
  */
 export function probe(name, exec = boundedChildOutput) {
   try {
@@ -128,12 +128,19 @@ export function probe(name, exec = boundedChildOutput) {
       encoding: "utf8",
       stdio: ["ignore", "pipe", "pipe"],
     });
-    return { present: true, version: extractVersion(out) };
+    return { present: true, executable: true, version: extractVersion(out) };
   } catch (err) {
-    if (err.code === "ENOENT") return { present: false, version: null };
     if (err.code === "ETIMEDOUT") throw err;
+    // A numeric exit status proves the child started, even when --version is
+    // unsupported. EACCES and other spawn failures carry no exit status: a
+    // file being discoverable does not mean the agent can execute it.
+    const executable = typeof err.status === "number";
     const output = `${err.stdout ?? ""}${err.stderr ?? ""}`;
-    return { present: true, version: extractVersion(output) };
+    return {
+      present: err.code !== "ENOENT",
+      executable,
+      version: executable ? extractVersion(output) : null,
+    };
   }
 }
 

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

@@ -56,7 +56,7 @@ export function extractVersion(output) {
 /**
  * Classify one required tool against what the environment actually provides.
  * @param {object} tool Manifest entry.
- * @param {{version: string|null, present: boolean}} found Probe result.
+ * @param {{version: string|null, present: boolean, executable: boolean}} found Probe result.
  * @returns {{name: string, action: string, reason: string}} The decision.
  */
 function planRequired(tool, found) {
@@ -70,6 +70,13 @@ function planRequired(tool, found) {
         `Either add an install entry or pin a different image.`,
     };
   }
+  if (found.executable !== true) {
+    return {
+      name: tool.name,
+      action: "missing",
+      reason: `${tool.name} was found but cannot be executed. Repair its permissions or replace the binary before using it.`,
+    };
+  }
   if (
     tool.minVersion &&
     compareVersions(found.version ?? "0", tool.minVersion) < 0
@@ -97,7 +104,7 @@ function planRequired(tool, found) {
  * and maintenance the same script, and it is the cheap path when a container
  * resumes from cache rather than being built fresh.
  * @param {object} tool Manifest entry.
- * @param {{version: string|null, present: boolean}} found Probe result.
+ * @param {{version: string|null, present: boolean, executable: boolean}} found Probe result.
  * @returns {{name: string, action: string, reason: string}} The decision.
  */
 function planInstallable(tool, found, pinIsFloor = false) {
@@ -108,7 +115,11 @@ function planInstallable(tool, found, pinIsFloor = false) {
       reason: `${tool.name} has no pinned version. An unpinned install is not reproducible.`,
     };
   }
-  if (found.present && found.version === tool.version) {
+  if (
+    found.present &&
+    found.executable === true &&
+    found.version === tool.version
+  ) {
     return {
       name: tool.name,
       action: "skip",
@@ -125,6 +136,7 @@ function planInstallable(tool, found, pinIsFloor = false) {
   if (
     pinIsFloor &&
     found.present &&
+    found.executable === true &&
     found.version &&
     compareVersions(found.version, tool.version) > 0
   ) {
@@ -286,10 +298,10 @@ export function appliesToSurface(tool, surface) {
  * asking about availability rather than provisioning has the answer instead of
  * having to infer one from the other.
  * @param {{require?: object[], install?: object[]}} tools Manifest.
- * @param {(name: string) => {version: string|null, present: boolean}} probe Version probe.
+ * @param {(name: string) => {version: string|null, present: boolean, executable: boolean}} probe Version probe.
  * @param {string} [surface] Surface being provisioned.
  * @param {string} [platform] Platform key to resolve install entries against.
- * @returns {Array<{name: string, action: string, reason: string, tool?: object, found?: {version: string|null, present: boolean}, unpinnedForPlatform?: boolean}>} Ordered decisions.
+ * @returns {Array<{name: string, action: string, reason: string, tool?: object, found?: {version: string|null, present: boolean, executable: boolean}, unpinnedForPlatform?: boolean}>} Ordered decisions.
  */
 export function planToolchain(
   tools,

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

@@ -24,7 +24,7 @@ This flow must return exactly one canonical `(tracker_provider, work_item_ref)`
 
 ### 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. 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.
+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, labels and all comments; Phase 3 uses the shared hold classifier so a historical `[lisa-human-gate]` marker with a matching release is not mistaken for an active hold. This live read is mandatory even if caller context already includes ticket text.
 
 ### File or plain text
 
@@ -44,9 +44,23 @@ This is intentionally conservative: ambiguity creates one explicit work item ins
 
 ## 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.
+The work item is **held** when the caller declared a `human_gate`, independently of any item history,
+or `classifyReadyCandidate({ labels, body, comments, humanNeededLabel })` from the shipped
+`scripts/intake-blocker-reprobe.mjs` returns `claimable: false`. Pass the complete live comment
+history so a matching `[lisa-human-gate-release]` discharges the historical body marker. Never
+reimplement heldness as a substring test or as the negation of `planHumanGateRelease().released`:
+that planner also returns `released: false` for an item that was never held. Missing comments fail
+closed for a hold; never infer release from a missing label.
 
-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.
+A held item stops the flow here, whatever roles or labels it carries. Do not invoke
+`lisa-tracker-claim`, write the worktree binding, or begin durable project work. Return
+`claim_outcome: held-by-gate` and `binding_outcome: skipped-human-gate`, name the signal in `held_by`
+and carry its reason verbatim in `gate_reason` (null for a keyless hold), then stop.
+
+For a discharged item, call
+`planHumanGateRelease({ labels, body, comments, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+and apply only the returned actions before claiming. Keep the body marker as history; a release
+never overrides a new caller-declared hold or another eligibility check.
 
 Otherwise:
 
@@ -78,5 +92,5 @@ Otherwise:
 - 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 decision, but not by a human edit: the person records the decision as a comment on the leaf beginning `[lisa-human-gate-release]` and repeating the hold's `reason=` verbatim, and the next intake sweep takes the human-needed marker off and puts the leaf back in the build-ready role on its own (`planHumanGateRelease` in `scripts/intake-blocker-reprobe.mjs`). A later invocation then resolves it on the ordinary path. **Do not tell anyone to delete the marker from the description, and do not delete it here.** The only description write available is a whole-body replacement, so clearing one line means rewriting the entire record — which is why, before this, the rational move was always to leave a hold in place and answered holds only accumulated (CodySwannGT/lisa#3852). The hold stays in the body as history; the release is recorded beside it.
+- A held filing writes no binding at all, so there is nothing to clear. The gate is released by a human decision, but not by a human edit: the person records the decision as a comment on the leaf beginning `[lisa-human-gate-release]` and, for a keyed hold, repeating its `reason=` verbatim. For a keyless hold, the comment begins `[lisa-human-gate-release]` without a `reason=` field. The next intake sweep takes the human-needed marker off and puts the leaf back in the build-ready role on its own (`planHumanGateRelease` in `scripts/intake-blocker-reprobe.mjs`). A later invocation then resolves it on the ordinary path. **Do not tell anyone to delete the marker from the description, and do not delete it here.** The only description write available is a whole-body replacement, so clearing one line means rewriting the entire record — which is why, before this, the rational move was always to leave a hold in place and answered holds only accumulated (CodySwannGT/lisa#3852). The hold stays in the body as history; the release is recorded beside it.
 - 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.55.1",
+  "version": "4.55.3",
   "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.55.1",
+  "version": "4.55.3",
   "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.55.1",
+  "version": "4.55.3",
   "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.55.1",
+  "version": "4.55.3",
   "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.55.1",
+  "version": "4.55.3",
   "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.55.1",
+  "version": "4.55.3",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/hooks/block-blind-automerge.sh

@@ -1,4 +1,7 @@
 #!/usr/bin/env bash
+# This file is managed by Lisa and IS replaced on each `lisa` run.
+# Do not edit directly — durable changes belong upstream in Lisa.
+
 # PreToolUse hook for Bash: refuse to ARM auto-merge on a pull request that
 # GitHub already says is blocked on review.
 #
@@ -280,7 +283,8 @@ NODE_ID_PATTERN = re.compile(r"^[A-Za-z0-9_=-]+$")
 NODE_QUERY = (
     "query($id:ID!){node(id:$id){... on PullRequest"
     "{number url reviewDecision state baseRefName "
-    "commits(last:1){nodes{commit{statusCheckRollup{contexts(first:100){nodes{"
+    "commits(last:1){nodes{commit{statusCheckRollup{contexts(first:100){"
+    "pageInfo{hasNextPage} nodes{"
     "__typename ... on CheckRun{name conclusion} "
     "... on StatusContext{context state}"
     "}}}}}}}}}"
@@ -294,9 +298,13 @@ NODE_QUERY = (
 # checks, which is genuinely not failing and gets an empty list. A node without
 # the scaffolding is a probe that never asked, and it must leave the key absent
 # so the re-target path can tell the two apart instead of reading both as green.
+# A truncated page is equally unreadable: a failing check may be on the next
+# page, so a green first page cannot authorize an uncovered-base re-target.
 NODE_JQ = (
     "if .data.node == null then null else .data.node as $n "
-    "| if ($n | has(\"commits\")) then ($n | del(.commits)) "
+    "| if ($n.commits.nodes[0].commit.statusCheckRollup.contexts.pageInfo.hasNextPage == true) "
+    "then ($n | del(.commits)) "
+    "elif ($n | has(\"commits\")) then ($n | del(.commits)) "
     "+ {statusCheckRollup: "
     "((($n.commits.nodes[0].commit.statusCheckRollup.contexts.nodes)) // [])} "
     "else $n end end"
@@ -1024,9 +1032,9 @@ not read the pull request's checks.
 
 That ref has ZERO required status checks, so the one thing standing between the
 move and a permission-free gate bypass is whether the PR is currently failing —
-and the probe returned no `statusCheckRollup` at all. An absent rollup is not an
-empty one. Reporting the move as the sanctioned green-PR batching case here
-would be a verdict about a question that was never asked.
+and the probe returned no complete `statusCheckRollup`. An absent or truncated
+rollup is not an empty one. Reporting the move as the sanctioned green-PR
+batching case here would claim a result the probe did not establish.
 
 Re-target through `gh pr edit --base` instead, which reads the checks, or fix
 the probe. Do not report the PR as batched until something has actually looked.

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

@@ -1,4 +1,7 @@
 #!/usr/bin/env bash
+# This file is managed by Lisa and IS replaced on each `lisa` run.
+# Do not edit directly — durable changes belong upstream in Lisa.
+
 # PreToolUse hook for Bash: refuse a direct tracker-creation command that
 # declares no readiness.
 #
@@ -2106,6 +2109,10 @@ def unparseable_reads_only(text):
     Returns:
         True when every segment's command word is a known reader.
     """
+    # Unlexable operands cannot be certified as data when shell substitutions
+    # may execute inside them. Preserve the plain apostrophe reader exemption.
+    if any(operator in text for operator in ("$(", "`", "<(", ">(")):
+        return False
     words = raw_command_words(text)
     return bool(words) and all(word in READ_ONLY_PROGRAMS for word in words)
 

package/plugins/lisa-copilot/hooks/block-instruction-file-edits.sh

@@ -1,4 +1,7 @@
 #!/usr/bin/env bash
+# This file is managed by Lisa and IS replaced on each `lisa` run.
+# Do not edit directly — durable changes belong upstream in Lisa.
+
 # PreToolUse hook: refuse agent writes to the session-instruction files.
 #
 # `AGENTS.md`, `CLAUDE.md`, and `.github/copilot-instructions.md` are the files