@codyswann/lisa 4.55.1 → 4.55.3

package/plugins/src/base/skills/lisa-linear-validate-issue/SKILL.md

@@ -91,24 +91,7 @@ prd_source: "https://notion.so/..."    # set when the Issue was generated from a
 
 If the caller passes only an identifier, fetch the item via `lisa-linear-access operation: get-issue` (Issue) or `lisa-linear-access operation: get-project` (Project), derive the same fields from the fetched data — including `runtime_behavior_change` (derived from the `## Target Backend Environment` declaration per `derived-branch-plan`, and authoritative over any caller assertion), `build_ready` (the Issue's state is the configured `ready` state) and `child_refs` (sub-issues, project-member issues, plus `blocked_by` parentage, resolved as in `lisa-linear-read-issue`) so S15 can classify the item — then run gates.
 
-## Standalone use, against an item that already exists
-
-This is a supported entry point, not only an internal step of a caller flow.
-Point it at a live issue and it fetches and validates the stored state:
-
-```text
-Skill(lisa-linear-validate-issue) with ENG-1234
-```
-
-Use it whenever the issue reached the tracker by some path other than
-`lisa-linear-write-issue` — a team's own script, a workflow step, a cron, anything holding the
-credentials but no skill runtime. Those paths get neither the pre-write nor the
-post-write gate, and their own read-back substitutes for neither: a read-back
-proves the tracker stored what was sent, never that what was sent was any good.
-
-The gate definitions live here on purpose, so every caller picks up a change
-automatically. Running this skill by hand is the same gate the write path runs,
-not an approximation of it.
+For existing items written through another path, use the [standalone entry point](#standalone-entry-point--validating-an-item-written-by-another-path). A transport read-back does not prove the stored specification passes the gates.
 
 ## Gates
 

package/plugins/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/src/base/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/scripts/build-plugins.sh

@@ -169,6 +169,9 @@ for guard in block-no-verify parity-safety-net block-shell-json-parsing \
   block-managed-file-edits block-blind-automerge worktree-binding-guard; do
   if [ -f "$SRC_DIR/base/hooks/$guard.sh" ]; then
     materialize "$SRC_DIR/base/hooks/$guard.sh" "$HOST_GUARD_DIR/$guard.sh"
+    # Both active channels must hash identical code, including the ownership
+    # banner; fan-out below derives the other plugins from this same copy.
+    materialize "$SRC_DIR/base/hooks/$guard.sh" "$PLUGINS_DIR/lisa/hooks/$guard.sh"
     chmod +x "$HOST_GUARD_DIR/$guard.sh"
   fi
 done
@@ -196,6 +199,7 @@ for companion in parity-safety-net-heredoc.py worktree-binding-guard.mjs \
   guard-dedupe.bash; do
   if [ -f "$SRC_DIR/base/hooks/$companion" ]; then
     materialize "$SRC_DIR/base/hooks/$companion" "$HOST_GUARD_DIR/$companion"
+    materialize "$SRC_DIR/base/hooks/$companion" "$PLUGINS_DIR/lisa/hooks/$companion"
   fi
 done
 # The Sonar hook wrapper, which ships alongside the guards but is not one.

package/scripts/copy-opencode-plugin-templates.mjs

@@ -12,6 +12,8 @@
 import fs from "node:fs";
 import path from "node:path";
 
+import { materialize } from "./materialize-copy-overwrite.mjs";
+
 const repoRoot = path.resolve(import.meta.dirname, "..");
 const sourceDir = path.join(repoRoot, "src", "opencode", "plugin-templates");
 const destDir = path.join(repoRoot, "dist", "opencode", "plugin-templates");
@@ -40,7 +42,9 @@ for (const entry of fs.readdirSync(sourceDir, { withFileTypes: true })) {
 }
 
 for (const filename of canonicalSupportFiles) {
-  fs.copyFileSync(
+  // build:dist precedes build:plugins. Stamp fresh authoring sources rather
+  // than copying possibly stale generated hooks, preserving channel parity.
+  materialize(
     path.join(canonicalHookDir, filename),
     path.join(destDir, filename)
   );

package/scripts/lisa-enforcement-fallback.sh

@@ -853,8 +853,16 @@ if [ -n "$notice_temp_base" ] && [ "$notice_state_trusted" -eq 1 ]; then
   if [ ! -e "$guard_memo_dir" ] && [ ! -L "$guard_memo_dir" ]; then
     (umask 077 && mkdir "$guard_memo_dir") 2>/dev/null || true
   fi
+  # Unlike shared temp ancestors, memo leaves may not be writable by another
+  # account even with the sticky bit: it could pre-create the session child.
+  guard_memo_mode=""
+  guard_memo_mode="$(stat -c '%a' "$guard_memo_dir" 2>/dev/null)" ||
+    guard_memo_mode="$(stat -f '%p' "$guard_memo_dir" 2>/dev/null)" ||
+    guard_memo_mode=""
+  case "$guard_memo_mode" in "" | *[!0-7]*) guard_memo_mode=777 ;; esac
   if [ -d "$guard_memo_dir" ] && [ ! -L "$guard_memo_dir" ] && \
-    [ -O "$guard_memo_dir" ]; then
+    [ -O "$guard_memo_dir" ] &&
+    [ $((8#$guard_memo_mode & 8#0022)) -eq 0 ]; then
     export LISA_GUARD_MEMO_DIR="$guard_memo_dir"
     export LISA_GUARD_MEMO_UID="$notice_uid"
   fi

package/scripts/two-channel-couplings.json

@@ -69,10 +69,6 @@
       "decision": "not-needed",
       "reason": "Unreachable outside this repository, and ratified above on that ground: the step tests for two paths that co-exist only here, and every consumer takes the else arm and runs the prover from the PACKAGE channel, whose vintage is their declared dependency version. There is no delivered artifact at this path for a consumer to hold a stale copy of — which is why the detection is `unchecked` rather than a measured negative."
     },
-    "quality.yml::scripts/check-skipped-required-checks.mjs": {
-      "decision": "warranted",
-      "reason": "Verdict-bearing required gate: it compares skip tokens against the ruleset's required contexts, and the step states that its absence is a failure precisely because a skipped required check reads as satisfied. A superseded copy comparing against a stale notion of the required set is the same false green arriving by the other door. The artifact exports no contract version yet; recorded as an open obligation rather than exempted."
-    },
     "quality.yml::scripts/check-state-classification.mjs": {
       "decision": "warranted",
       "reason": "Verdict-bearing required gate whose subject is classification itself — it decides which states a change is allowed to leave behind. A copy behind a classification change enforces the superseded taxonomy and names states that no longer mean what it thinks. The artifact exports no contract version yet; recorded as an open obligation rather than exempted."
@@ -99,13 +95,13 @@
   },
   "inspected": {
     "workflows": 23,
-    "steps": 777,
-    "couplings": 34,
+    "steps": 778,
+    "couplings": 33,
     "inventory": 78
   },
   "counts": {
     "package-backed": 10,
-    "apply-lagged": 22,
+    "apply-lagged": 21,
     "never-delivered": 0,
     "undelivered": 2
   },
@@ -113,13 +109,13 @@
     "version-handshake": 4,
     "capability-probe": 0,
     "existence-only": 4,
-    "no-probe": 14,
+    "no-probe": 13,
     "unchecked": 2
   },
   "decisionCounts": {
     "handshake": 4,
     "not-needed": 11,
-    "warranted": 9
+    "warranted": 8
   },
   "couplings": [
     {
@@ -484,30 +480,6 @@
       "lanes": [],
       "detail": "`quality.yml` is delivered at `@main`, so this step is live in every consumer on their next run. It reads `scripts/check-learnings-budget.ts` from the CALLER's tree, and Lisa ships no such path in any delivery lane — no apply and no bump ever produces it. Either the consumer authors it, or whatever the step does where the path is missing runs instead — and that branch is the part this scan does not read. The read sits behind an existence test, which is ALL this scan examined of the step's control flow: it did not read the test's other branch, any fallback, any explicit `exit`, or any verification of the step's output. Whether an absent path skips quietly, falls back, or fails loudly is therefore NOT MEASURED — read the step before concluding it proves nothing. The shape worth ruling out is the silent one, where a skip posts no context and an absent required context is not a red one. The step's text does carry `else-branch`, `exit-nonzero`, `error-annotation`, `failure-suppression` — located in the step, deliberately NOT related to this read, and enough to make \"it skips silently\" a claim to check rather than assume. STALENESS (a separate dimension from the delivery verdict above): `unchecked`. Lisa delivers nothing at this path, so there is no artifact to ask whether it could answer a version. The staleness half is UNKNOWN here — not current, and not probe-less. Tokens found: `workflow-requests-version`. `workflow-requests-version` is workflow-scoped — it does not say THIS step asks."
     },
-    {
-      "key": "quality.yml::scripts/check-skipped-required-checks.mjs",
-      "workflow": "quality.yml",
-      "path": "scripts/check-skipped-required-checks.mjs",
-      "channel": "apply",
-      "verdict": "apply-lagged",
-      "remedy": "run-lisa-apply",
-      "guarded": false,
-      "handling": [
-        "exit-zero",
-        "exit-nonzero",
-        "error-annotation"
-      ],
-      "detection": "no-probe",
-      "stalenessSignals": [
-        "workflow-requests-version"
-      ],
-      "decision": "warranted",
-      "reason": "Verdict-bearing required gate: it compares skip tokens against the ruleset's required contexts, and the step states that its absence is a failure precisely because a skipped required check reads as satisfied. A superseded copy comparing against a stale notion of the required set is the same false green arriving by the other door. The artifact exports no contract version yet; recorded as an open obligation rather than exempted.",
-      "lanes": [
-        "typescript/copy-overwrite"
-      ],
-      "detail": "`quality.yml` is delivered at `@main`, so this step is live in every consumer on their next run. It reads `scripts/check-skipped-required-checks.mjs` from the CALLER's tree with no package-relative candidate, and Lisa delivers that path on the `lisa apply` channel (typescript/copy-overwrite). The two halves land in the wrong order: this step is live everywhere immediately, the file it needs is live only where somebody applied. No existence test guards the read, which is ALL this scan examined of the step's control flow: it did not read anything that could absorb the failure. An absent path most likely fails the job loudly — the better of the two failures, because it is visible — but that is inferred from the missing guard, NOT MEASURED. The step's text does carry `exit-zero`, `exit-nonzero`, `error-annotation` — located in the step, deliberately NOT related to this read, and enough to make \"it skips silently\" a claim to check rather than assume. STALENESS (a separate dimension from the delivery verdict above): `no-probe`. Neither an existence test nor a version probe bears on this read, so nothing here distinguishes a current artifact from an absent or a superseded one. Tokens found: `workflow-requests-version`. `workflow-requests-version` is workflow-scoped — it does not say THIS step asks."
-    },
     {
       "key": "quality.yml::scripts/check-state-classification.mjs",
       "workflow": "quality.yml",