@codyswann/lisa 4.55.2 → 4.55.4

package/plugins/lisa-agy/skills/lisa-linear-build-intake/SKILL.md

@@ -6,6 +6,20 @@ allowed-tools: ["Skill", "Bash"]
 
 # Linear 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.
+
+
 `$ARGUMENTS` is one of:
 
 1. A Linear team key (e.g. `ENG`) — scans that team for ready Issues.
@@ -182,13 +196,21 @@ A blocker is a **claim with a timestamp, not a fact**. It is written once and go
 
 For each pre-work candidate that is **not** in `$READY`:
 
-1. **Human gate first, and it is absolute.** An Issue carrying the configured human-needed label (`linear.labels.build.human_needed`, default `human-needed`) or a `[lisa-human-gate]` marker in its description is **never** auto-selected, whatever any probe says. Skip it and move on.
+1. **Read release comments before applying the human gate.** Pass all item comments, labels,
+   body, `trustedHumanActorIds` and configured `humanNeededLabel` to `classifyReadyCandidate(...)`. For a discharged hold,
+   call `planHumanGateRelease({ labels, body, comments, trustedHumanActorIds, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   and retain its plan. Apply human-marker cleanup only as planned; defer any ready-role restoration
+   until steps 2–5 have cleared the remaining blockers (map the role to the vendor's state or label).
+   A still-active hold is never auto-selected, whatever any probe says. An absent or unreadable
+   comment history cannot discharge a hold. A release removes only the human hold: continue the
+   remaining blocker checks below before selecting the item.
+
 2. **Extract the stated discharge condition** from the description or the most recent blocking comment — the sentence naming what has to become true.
 3. **Probe it.** Machine-testable conditions are the ones that rot fastest and are cheapest to check: a version on trunk (`git show origin/<trunk>:<manifest>`), a published package, a run history (`gh run list`), an advisory's patched status. A condition that is a human decision is not machine-testable — leave it and move on.
 4. **Classify with the shared helper** so the ordering and the evidence requirement cannot drift per vendor:
 
 ```text
-classifyPreWorkCandidate({ laneType, labels, body, humanNeededLabel, statedBlocker, probe })
+classifyPreWorkCandidate({ laneType, labels, body, comments, trustedHumanActorIds, humanNeededLabel, statedBlocker, probe })
   → { selectable, reason, humanGated, evidence }
 ```
 
@@ -216,7 +238,7 @@ other gate's verdict — however conclusive — may promote an item a person par
    drift, and a drifted gate fails *silently*, by quietly ceasing to match. Do **not** re-implement
    the test here, and do **not** key it on `reason=`: markers in the wild carry no `reason=` key at
    all and sit anywhere in the body, so a structured parse would miss them while appearing to work
-   on every item that happens to have one. **Pass the item's `comments` alongside its labels and
+   on every item that happens to have one. **Pass the item's structured `comments` and `trustedHumanActorIds` alongside its labels and
    body.** A hold is ended by a release recorded in a comment, so a reader handed no comments cannot
    see the discharge — it goes on holding an item whose question was answered weeks ago, which is
    the defect this gate carried from the day it was written (CodySwannGT/lisa#3852). Omitting them
@@ -227,16 +249,17 @@ other gate's verdict — however conclusive — may promote an item a person par
    and re-rejected every cycle forever and seen by nothing — `lisa-repair-intake` sweeps items that
    are **not** in the ready role and excludes gated ones outright, so a ready-and-gated item falls
    outside its filter twice over. Call
-   `planHumanGateReconciliation({ labels, body, humanNeededLabel, readyLabel, alreadyNotified })`
+   `planHumanGateReconciliation({ labels, body, comments, trustedHumanActorIds, humanNeededLabel, readyLabel, alreadyNotified })`
    and apply exactly the actions it returns: remove `$READY`, add the configured human-needed
    marker, and post `formatHumanGateNote()` once. The planner is idempotent by state, so an item
    already out of the lane and already marked yields no second mutation and no second comment. This
    is the same repair the leaf-only gate already performs for a ready item that must not be
    dispatched.
 4. **On `claimable: true` for an item that still carries a hold, RELEASE it — do not just proceed.**
-   The hold left durable state behind: the item is out of the queue and flagged as needing a person,
-   and answering the question does not undo either. Call
-   `planHumanGateRelease({ labels, body, comments, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   This ready-lane candidate can retain a historical body marker and a human-needed label.
+   This step reconciles only candidates still in the ready lane; released holds outside it are
+   recovered by `lisa-repair-intake` step 2b (or Phase 2.5 when included in this cycle). Call
+   `planHumanGateRelease({ labels, body, comments, trustedHumanActorIds, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
    and apply exactly the actions it returns: remove the configured human-needed marker, add the
    configured ready role back, and post `formatHumanGateReleaseNote()` once. It is the exact inverse
    of step 3's planner and it refuses in both directions — an item still held plans nothing, and an
@@ -268,10 +291,12 @@ A Linear team can oversee multiple repos (`frontend` / `backend` / `infrastructu
 1. **Resolve the current repo** per `config-resolution` "Repo scoping" (`.repo` → `.github.repo` → `git remote get-url origin` basename). If unresolvable, stop and report.
 2. **Cheap path first.** Prefer candidates already carrying the `repo:<current>` label. Keep the Phase 2 scan broad so unlabeled Issues are still seen, determined, and stamped.
 3. **Per candidate, apply the repo-scope decision (`repo-scope-split`):**
-   - Carries `repo:<other>` → **skip** (leave it `ready` for that repo's own intake); next candidate.
-   - **Unlabeled** → determine the target repo(s) from the Issue + code surfaces, then **stamp** `repo:<name>` via `lisa-linear-access operation: save-issue` (resolve/create the label via `list_issue_labels`/`create_issue_label`) so later cycles filter cheaply; re-apply with the now-known repo.
-   - **Multi-repo leaf → split, never claim.** Run the `repo-scope-split` work-time procedure into single-repo siblings, each created **build-ready** (`build_ready: true`) and stamped with its own `repo:<name>`; the current repo's sibling becomes a normal candidate.
-   - **Single-repo leaf for the current repo** → fall through to 3a (leaf-only gate) and 3b (claim).
+   - **Count distinct repository markers first**: collect all `repo:<name>` labels and, on JIRA, recognized repository components; deduplicate by repository. A container may carry multiple `repo:<name>` labels. Do not split or claim it here; send it to the leaf-only gate.
+   - **Multi-repo leaf → split, never claim.** More than one repository takes the work-time split before any wrong-repository skip. Each sibling is **build-ready** (`build_ready: true`) and stamped with its own `repo:<name>`; the current repo's sibling becomes a normal candidate.
+   - **Exactly one other repository** (`repo:<other>`) → **skip**, leaving the item ready for that repo's intake.
+   - **No repository marker** → determine target repo(s) from the ticket and code, stamp `repo:<name>` through the vendor access layer, and re-apply from the count.
+   - **Single-repo leaf for the current repo** → fall through to 3a and 3b.
+
 4. Continue until a claimable current-repo leaf is found (claim it; one per cycle) or the candidate set is exhausted — exit cleanly on the denominator-stated summary, naming the current repo alongside the swept lanes.
 
 #### 3a. Leaf-only claim gate (skip / safe-block containers)

package/plugins/lisa-agy/skills/lisa-linear-prd-intake/SKILL.md

@@ -130,6 +130,16 @@ Select the first ready project returned by Phase 2 and process only that project
 
 #### 3a. Claim
 
+**Preflight project comments before any claim or destination-ticket creation.** Through
+`lisa-linear-access`, resolve an identity-matched tier-1 GraphQL credential and the
+`save-comment project_id` adapter, then read the candidate's complete project comment
+history with `list-comments project_id:<id>`. The issue-only MCP is insufficient for
+this flow. If the required credential, adapter or read is unavailable, return the
+layer's `Error:` naming the project-comment operation and leave the project ready;
+create no tickets and no substitute comment-holder Issue. This is a read-only
+capability preflight, not a test comment. It establishes the available transport;
+later permission changes or write failures still follow the normal error handler.
+
 Transition labels via `lisa-linear-access operation: save-project({id, labels})`: pass the full new label set with `$READY` removed and `$IN_REVIEW` added. This is the idempotency lock — a re-entrant cycle running concurrently won't see this project because its query filters on `label: "$READY"`.
 
 If the update fails (permission error, race condition), log it and skip this project. Do not proceed to validation on a project you didn't successfully claim.
@@ -152,7 +162,7 @@ This call also indirectly invokes `lisa-tracker-source-artifacts` (artifact extr
 
 1. Re-invoke `lisa-linear-to-tracker` with `dry_run: false` to actually write the tickets. This re-runs Phases 1-5 and runs the preservation gate (Phase 5.5).
 2. Capture the created ticket keys from the skill's output.
-3. Post a comment on the project via `lisa-linear-access operation: save-comment project_id:<id>` listing the created tickets (epic, stories, sub-tasks) with their JIRA URLs. Lead with: `"Ticketed by Claude. Created N JIRA issues — see below. Add the $SHIPPED label to the Linear project after the work is delivered."`
+3. Post a comment on the project via `lisa-linear-access operation: save-comment project_id:<id>` listing the created tickets (epic, stories, sub-tasks) with the URLs returned by the configured destination tracker. Lead with: `"Ticketed by Claude. Created N tickets — see below. Add the $SHIPPED label to the Linear project after the work is delivered."`
 4. Transition labels: remove `$IN_REVIEW`, add `$TICKETED` via `save_project`.
 5. **Run Phase 3e (coverage audit)** before considering this PRD done.
 
@@ -396,6 +406,6 @@ Before this skill can run against a Linear workspace or team, the team must adop
 1. Apply the `ready` label (default: `prd-ready`) to projects that are ready for ticketing (replaces the Notion `Status = Ready` flip and the Confluence `prd-ready` page label).
 2. Reserve `in_review`, `blocked`, `ticketed` (defaults: `prd-in-review`, `prd-blocked`, `prd-ticketed`) for this skill — humans should not set them manually except to recover from an error.
 3. (Optional but recommended) Add the `draft` and `shipped` labels (defaults: `prd-draft`, `prd-shipped`) for in-progress PRDs and delivered work respectively, so the full lifecycle is visible at a glance.
-4. The labels must exist as **project labels** in Linear (`list_project_labels` should return them). Issue-level labels with the same names won't work; Linear keeps the two label kinds separate.
+4. The labels must exist as **project labels** in Linear (`list-project-labels` should return them). Issue-level labels with the same names won't work; Linear keeps the two label kinds separate.
 
 If the workspace hasn't adopted these labels, the first run exits with a label-convention error (not the idle empty-set message) — this distinguishes a setup issue from a genuinely empty queue so operators know to apply the convention rather than assuming there is no work. See Phase 2 for how the skill detects this case.

package/plugins/lisa-agy/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/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

@@ -6,6 +6,20 @@ allowed-tools: ["Bash", "Skill"]
 
 # Write Linear Work Item: $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.
+
+
 Create or update a Linear work item — Project (for Epics), Issue (for Stories), or sub-Issue (for Sub-tasks) — with all required relationships, metadata, and quality gates. Every section below is mandatory. Thin items are rejected.
 
 Repository name for scoped comments: `basename $(git rev-parse --show-toplevel)`.
@@ -33,40 +47,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,8 +315,10 @@ 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
+`[lisa-human-gate-release]` comment repeating that same `reason=` is recorded on the item by an authorized human, and the
 next intake sweep then takes the marker label off and puts the item back in the build-ready role on
 its own. Matching is per-reason so that a hold declared *after* an earlier release is not born
 discharged. A keyless hold is legal and is discharged by a keyless release; a hold whose reason is a

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

@@ -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-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,