@codyswann/lisa 4.55.2 → 4.55.4

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

@@ -6,6 +6,20 @@ allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit"]
 
 # Repair Intake: $ARGUMENTS
 
+## Human-gate release authorization
+
+A release requires a trusted human author, not just matching comment text. Follow
+`ready-role-filing` — **Human-gate release authorization**: preserve tracker-supplied comment
+author IDs and bot metadata, resolve `trustedHumanActorIds` only from an explicit user instruction
+or existing human-authored trusted project policy, and pass it with structured `comments` to every
+hold classifier, reconciliation, normalization and release planner. Never derive trust from the
+comment body, a display name, the actor's own assertion, or an automation posting on its own behalf.
+Missing policy, missing/unreadable author identity, raw body strings, untrusted actors and known bots
+cannot discharge a hold. Keep the item held and report the missing authorization; do not silently
+replace these inputs with an empty history or an inferred allowlist. Authorized matching releases
+continue through the existing path and never override an independently declared caller hold.
+
+
 Run one batch-**repair** cycle against the queue identified by `$ARGUMENTS`, or by merged GitHub
 config when the queue is omitted and a GitHub source/tracker default is resolvable. Where `lisa-intake`
 scans the `ready` role and moves work *forward*, repair-intake scans the **stuck and
@@ -189,7 +203,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 +635,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 +678,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 +1085,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, trustedHumanActorIds, 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
@@ -1050,7 +1102,7 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    the safe failure direction without the latch. Count these under `held_for_person`, never under
    `normalized_ready`.
 
-   **Pass the item's `comments`.** The planner reads a recorded `[lisa-human-gate-release]` comment
+   **Pass the item's `comments` with author identity and `trustedHumanActorIds`.** The planner reads a recorded `[lisa-human-gate-release]` comment
    as the discharge of the hold naming the same `reason=`, and an item read without its comments is
    an item whose discharge cannot be seen. That fails closed — it stays held — which is the safe
    direction and precisely why the omission is invisible.
@@ -1064,7 +1116,7 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
 
    Enumerate items carrying the configured `human_needed` marker **or** a `[lisa-human-gate]` marker
    in the body, and for each call
-   `planHumanGateRelease({ labels, body, comments, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   `planHumanGateRelease({ labels, body, comments, trustedHumanActorIds, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
    from `scripts/intake-blocker-reprobe.mjs`. Apply exactly the actions it returns: remove the
    human-needed marker, add the configured build `ready` label back, and post
    `formatHumanGateReleaseNote()` once. Do **not** re-implement the discharge test, and do **not**
@@ -1081,10 +1133,10 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
      item carries no other configured lifecycle label.
 
    This is a genuine exception to "never remove a `human_needed` marker this skill did not apply",
-   and the exception is narrow enough to state exactly: provenance is the wrong question when the
-   *hold itself* names the condition that voids it and that condition is recorded. The general rule
-   stands because "stale" is otherwise a judgment about the block's kind; here nothing is being
-   judged — a release naming the hold's own reason is on the item, or it is not.
+   and the exception is narrow enough to state exactly: the release author must first be verified against `trustedHumanActorIds`; only then does the
+   matching release satisfy the hold's stated void condition. The actor who originally applied the
+   marker does not need to match that authorized release author. The general rule
+   stands because "stale" is otherwise a judgment about the block's kind; here an authorized matching release is required; arbitrary matching text is not enough.
 
    **Never edit a description to clear a hold**, here or anywhere. The only body write this plugin
    has is a whole-body replacement, so deleting one line means rewriting the record and hoping
@@ -1187,9 +1239,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-cursor/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-cursor/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-cursor/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-cursor/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-cursor/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-cursor/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-cursor/skills/lisa-track/SKILL.md

@@ -6,6 +6,20 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 # Track Work: $ARGUMENTS
 
+## Human-gate release authorization
+
+A release requires a trusted human author, not just matching comment text. Follow
+`ready-role-filing` — **Human-gate release authorization**: preserve tracker-supplied comment
+author IDs and bot metadata, resolve `trustedHumanActorIds` only from an explicit user instruction
+or existing human-authored trusted project policy, and pass it with structured `comments` to every
+hold classifier, reconciliation, normalization and release planner. Never derive trust from the
+comment body, a display name, the actor's own assertion, or an automation posting on its own behalf.
+Missing policy, missing/unreadable author identity, raw body strings, untrusted actors and known bots
+cannot discharge a hold. Keep the item held and report the missing authorization; do not silently
+replace these inputs with an empty history or an inferred allowlist. Authorized matching releases
+continue through the existing path and never override an independently declared caller hold.
+
+
 Establish the tracked-work invariant before any durable project mutation. Discussion and read-only orientation may proceed without this skill; code, configuration, documentation, research artifacts, plans, investigation findings, tests, commits, and pull requests may not.
 
 This flow must return exactly one canonical `(tracker_provider, work_item_ref)` pair or fail closed. It never returns an unvalidated textual guess.
@@ -24,7 +38,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 +58,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, trustedHumanActorIds, 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 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.
 
-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.
+For a discharged item, call
+`planHumanGateRelease({ labels, body, comments, trustedHumanActorIds, 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 +106,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-cursor/skills/lisa-tracker-build-intake/SKILL.md

@@ -6,6 +6,20 @@ allowed-tools: ["Skill", "Bash", "Read"]
 
 # Tracker Build Intake: $ARGUMENTS
 
+## Human-gate release authorization
+
+A release requires a trusted human author, not just matching comment text. Follow
+`ready-role-filing` — **Human-gate release authorization**: preserve tracker-supplied comment
+author IDs and bot metadata, resolve `trustedHumanActorIds` only from an explicit user instruction
+or existing human-authored trusted project policy, and pass it with structured `comments` to every
+hold classifier, reconciliation, normalization and release planner. Never derive trust from the
+comment body, a display name, the actor's own assertion, or an automation posting on its own behalf.
+Missing policy, missing/unreadable author identity, raw body strings, untrusted actors and known bots
+cannot discharge a hold. Keep the item held and report the missing authorization; do not silently
+replace these inputs with an empty history or an inferred allowlist. Authorized matching releases
+continue through the existing path and never override an independently declared caller hold.
+
+
 Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor build-queue scanner.
 
 See the `config-resolution` rule for configuration and dispatch table.
@@ -63,7 +77,7 @@ blocker re-probe carries an absolute human gate: an item carrying the configured
 or a `[lisa-human-gate]` marker is never auto-selected, whatever a probe returns.
 
 That gate has an inverse, and it is forwarded identically: a hold ends when a
-`[lisa-human-gate-release]` comment naming the same `reason=` is recorded on the item. Every vendor
+`[lisa-human-gate-release]` comment naming the same `reason=` is recorded on the item by an authorized human. Every vendor
 scanner passes the item's `comments` into the gate helpers so the discharge is visible, and calls
 `planHumanGateRelease(...)` to take the marker off and put the item back in the queue. **No vendor
 scanner clears a hold by editing the description** — the only body write any of them has is a

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "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.55.2",
+  "version": "4.55.4",
   "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.55.2",
+  "version": "4.55.4",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.55.2",
+  "version": "4.55.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"