@codyswann/lisa 4.55.3 → 4.55.5

package/expo/copy-overwrite/scripts/bdd/validate.mjs

@@ -13,6 +13,7 @@
 import * as fs from "node:fs";
 
 import { byCodeUnit, runnersByPlatform } from "./contract.mjs";
+import { isDisclosed } from "./discover.mjs";
 import { resolveInsideRepo } from "./parse.mjs";
 
 /**
@@ -183,10 +184,19 @@ function orphanReason(reference, { keys, repos, defaultRepo }) {
     : `unknown repo ${repo}; declare it in trackers.github.repos`;
 }
 
+/**
+ * An empty discovery result, for callers that do not walk the tree.
+ *
+ * A caller that supplies no discovery gets exactly the findings it got before
+ * the rename hint existed. Absent discovery must read as "nothing to pair
+ * with", never as "pair with whatever is at hand".
+ */
+const NO_DISCOVERY = Object.freeze({ specs: [] });
+
 /**
  * Validate every scenario→test mapping, including that its evidence still
  * exists inside the mapped file.
- * @param {object} input - Root, scenarios, and the parsed contract.
+ * @param {object} input - Root, scenarios, the parsed contract, and discovery.
  * @returns {object[]} Defects found.
  */
 export function validateMappings({
@@ -194,6 +204,7 @@ export function validateMappings({
   scenarios,
   contract,
   cache = new Map(),
+  discovery = NO_DISCOVERY,
 }) {
   const byId = new Map(scenarios.map(scenario => [scenario.id, scenario]));
   const platformRunners = runnersByPlatform(contract.runnerPlatforms);
@@ -216,7 +227,9 @@ export function validateMappings({
     }
     defects.push(...mappingDuplicates(mapping, at, seen));
     defects.push(...mappingPlatforms(mapping, scenario, platformRunners, at));
-    defects.push(...mappingEvidence(root, mapping, at, cache));
+    defects.push(
+      ...mappingEvidence({ root, mapping, at, cache, contract, discovery })
+    );
   }
   return defects;
 }
@@ -327,6 +340,11 @@ export function evidenceResolves(root, mapping, cache = new Map()) {
     return {
       ok: false,
       code: "mapping-evidence",
+      // The ONE verdict a rename could explain: a live file that used to carry
+      // this string. A mapping with no evidence at all and a mapped file that
+      // is gone both return above, unmarked, so neither can be dressed up as
+      // a rename by a caller reading only the code.
+      stale: true,
       detail: `${mapping.file} no longer contains ${JSON.stringify(mapping.evidence)}`,
     };
   }
@@ -357,19 +375,77 @@ export function unresolvedEvidenceKeys({ root, contract, cache = new Map() }) {
   );
 }
 
+/**
+ * The titles in the MAPPED FILE that nothing in the contract accounts for.
+ *
+ * Scoped to `mapping.file` and to nothing else. A title in a sibling file is
+ * never a candidate: pairing across files would let one deletion here and one
+ * addition anywhere in the repository read as a single rename, which is a
+ * confident wrong answer rather than a missing one.
+ *
+ * `isDisclosed` is asked with the WHOLE contract, this stale mapping included,
+ * so a new title that the dead evidence string happens to contain reads as
+ * accounted for and yields no candidate. That is the conservative direction:
+ * the hint goes quiet rather than offering a title something already claims.
+ * @param {object} mapping - Raw mapping entry.
+ * @param {object} contract - Parsed coverage map.
+ * @param {object} discovery - The discovery result.
+ * @returns {string[]} Candidate titles, deduplicated and ordered.
+ */
+function renameCandidates(mapping, contract, discovery) {
+  const unaccounted = (discovery.specs ?? [])
+    .filter(spec => spec.file === mapping.file)
+    .filter(
+      spec => typeof spec.evidence === "string" && spec.evidence.length > 0
+    )
+    .filter(spec => !isDisclosed(spec, contract))
+    .map(spec => spec.evidence);
+  return [...new Set(unaccounted)].sort(byCodeUnit);
+}
+
+/**
+ * Say a rename is the likely story, without ever picking which one.
+ *
+ * Every candidate is offered. Naming one would be a guess, and a confident
+ * wrong guess costs more than an honest list: the author knows which of their
+ * own tests moved and only needs to be told the two findings are one edit.
+ *
+ * Each title is JSON-quoted INDIVIDUALLY, so a title containing the comma the
+ * list joins on stays recoverable rather than splitting into two titles that
+ * were never in the file.
+ * @param {readonly string[]} candidates - Unaccounted titles in the same file.
+ * @returns {string} The hint, or the empty string when there is nothing to say.
+ */
+function renameHint(candidates) {
+  if (candidates.length === 0) return "";
+  const noun = candidates.length === 1 ? "title" : "titles";
+  return (
+    ` — probably a rename: ${candidates.length} test ${noun} in that same` +
+    ` file ${candidates.length === 1 ? "is" : "are"} named by no mapping and` +
+    ` no exclusion. Candidates, each quoted whole:` +
+    ` ${candidates.map(title => JSON.stringify(title)).join(", ")}.` +
+    ` Re-point this mapping's evidence at the right one, or record an exclusion.`
+  );
+}
+
 /**
  * Prove the mapped file still contains the exact evidence string.
  *
  * This is what makes a mapping falsifiable rather than an assertion: rename
  * or delete the test and the map breaks loudly instead of leaving a scenario
  * silently unguarded.
- * @param {string} root - Repo root.
- * @param {object} mapping - Raw mapping entry.
- * @param {string} at - Location label.
- * @param {Map<string, string>} cache - File-content cache.
+ *
+ * The hint appended here is MESSAGE ONLY. It never reaches `evidenceResolves`,
+ * which is what coverage counts from, so a renamed test stays a failure and
+ * stays uncovered until someone actually updates the map.
+ * @param {object} input - Root, the mapping, its label, the cache, the contract, and discovery.
  * @returns {object[]} Defects found.
  */
-function mappingEvidence(root, mapping, at, cache) {
+function mappingEvidence({ root, mapping, at, cache, contract, discovery }) {
   const verdict = evidenceResolves(root, mapping, cache);
-  return verdict.ok ? [] : [defect(verdict.code, `${at}: ${verdict.detail}`)];
+  if (verdict.ok) return [];
+  const hint = verdict.stale
+    ? renameHint(renameCandidates(mapping, contract, discovery))
+    : "";
+  return [defect(verdict.code, `${at}: ${verdict.detail}${hint}`)];
 }

package/expo/copy-overwrite/scripts/check-bdd-coverage.mjs

@@ -248,7 +248,7 @@ function validateAll({
   const defects = [
     ...validateScenarios(scenarios, platforms),
     ...validateTrackerTags(scenarios, contract.trackers),
-    ...validateMappings({ root, scenarios, contract, cache }),
+    ...validateMappings({ root, scenarios, contract, cache, discovery }),
     ...validateWaivers({ scenarios, contract, today: options.today }),
     ...discovery.defects,
     ...disclosureDefects({ root, contract, discovery }),

package/package.json

@@ -187,7 +187,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.55.3",
+  "version": "4.55.5",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -336,7 +336,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "c6de8937e39f49d8374a0481a334cb9a0ff91808",
-  "gitHead": "c6de8937e39f49d8374a0481a334cb9a0ff91808",
-  "lisaReleaseTag": "v4.55.3"
+  "lisaReleaseCommit": "3b91f194a303d3756679b63a137eeb74b8699930",
+  "gitHead": "3b91f194a303d3756679b63a137eeb74b8699930",
+  "lisaReleaseTag": "v4.55.5"
 }

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

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

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

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

package/plugins/lisa/.codex-plugin/skills/lisa-github-build-intake/SKILL.md

@@ -6,6 +6,20 @@ allowed-tools: ["Skill", "Bash"]
 
 # GitHub 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 GitHub `org/repo` token (e.g., `acme/frontend-v2`).
@@ -216,8 +230,8 @@ A blocker is a **claim with a timestamp, not a fact** — it goes stale the mome
 true, and nothing re-read one before this phase. For each `$BLOCKED` candidate:
 
 1. **Read release comments before applying the human gate.** Pass all item comments, labels,
-   body and configured `humanNeededLabel` to `classifyReadyCandidate(...)`. For a discharged hold,
-   call `planHumanGateRelease({ labels, body, comments, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   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
@@ -227,8 +241,9 @@ true, and nothing re-read one before this phase. For each `$BLOCKED` candidate:
 2. **Extract the stated discharge condition**, then **probe it**. Machine-testable conditions — a
    version on trunk, a published package, a CI run history, an advisory's patched status — rot
    fastest and are cheapest to check. A human decision is not machine-testable; leave it.
-3. **Classify with `classifyPreWorkCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`. A
-   discharge with no recorded evidence is not a discharge, and neither is a candidate nothing
+3. **Classify with `classifyPreWorkCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`.
+   Include the structured `comments` and `trustedHumanActorIds` from step 1.
+   A discharge with no recorded evidence is not a discharge, and neither is a candidate nothing
    probed this cycle — the helper refuses both.
 4. **Record the result on the issue either way** via `formatReprobeNote(...)` as a comment, so the
    next cycle reads the answer rather than re-deriving it. Keep it idempotent.
@@ -323,7 +338,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
@@ -334,7 +349,7 @@ 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
@@ -344,7 +359,7 @@ other gate's verdict — however conclusive — may promote an item a person par
    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, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   `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

package/plugins/lisa/.codex-plugin/skills/lisa-github-write-issue/SKILL.md

@@ -6,6 +6,20 @@ allowed-tools: ["Bash", "Skill", "Read"]
 
 # Write GitHub Issue: $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 GitHub Issue with all required relationships, metadata, and quality gates. Every section below is mandatory. Thin issues are rejected.
 
 This skill is the GitHub counterpart of `lisa-jira-write-ticket`. The two skills share the same gates, description structure, acceptance-criteria format, and verification flow. The data-model translation is documented under "GitHub Issues data model" below — keep that table in sync with `lisa-github-validate-issue` so what one skill writes the other accepts.
@@ -323,7 +337,7 @@ If the label does not exist in the tracker, create it, or record that it could n
 proceed — the marker still holds. Never file the label *instead of* the marker.
 
 **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/.codex-plugin/skills/lisa-jira-build-intake/SKILL.md

@@ -6,6 +6,20 @@ allowed-tools: ["Skill", "Bash"]
 
 # JIRA 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.
+
+
 All Atlassian operations in this skill go through `lisa-atlassian-access`. Do not call MCP tools or `acli` directly.
 
 `$ARGUMENTS` is one of:
@@ -190,8 +204,8 @@ A blocker is a **claim with a timestamp, not a fact** — it goes stale the mome
 true, and nothing re-read one before this phase. For each pre-work candidate outside `$READY`:
 
 1. **Read release comments before applying the human gate.** Pass all item comments, labels,
-   body and configured `humanNeededLabel` to `classifyReadyCandidate(...)`. For a discharged hold,
-   call `planHumanGateRelease({ labels, body, comments, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   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
@@ -202,7 +216,8 @@ true, and nothing re-read one before this phase. For each pre-work candidate out
    version on trunk, a published package, a CI run history, an advisory's patched status — rot
    fastest and are cheapest to check. A human decision is not machine-testable; leave it.
 3. **Classify with `classifyPreWorkCandidate(...)`** from
-   `scripts/intake-blocker-reprobe.mjs`. A discharge with no recorded evidence is not a discharge,
+   `scripts/intake-blocker-reprobe.mjs`, including the structured `comments` and
+   `trustedHumanActorIds` from step 1. A discharge with no recorded evidence is not a discharge,
    and neither is a candidate nothing probed this cycle — the helper refuses both.
 4. **Record the result on the ticket either way** via `formatReprobeNote(...)` as a comment, so the
    next cycle reads the answer rather than re-deriving it. Keep it idempotent.
@@ -228,7 +243,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
@@ -239,7 +254,7 @@ 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
@@ -249,7 +264,7 @@ other gate's verdict — however conclusive — may promote an item a person par
    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, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   `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

package/plugins/lisa/.codex-plugin/skills/lisa-jira-write-ticket/SKILL.md

@@ -6,6 +6,20 @@ allowed-tools: ["Bash", "Skill"]
 
 # Write JIRA Ticket: $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.
+
+
 All Atlassian operations in this skill go through `lisa-atlassian-access`. Do not call MCP tools or `acli` directly.
 
 Create or update a JIRA ticket with all required relationships, metadata, and quality gates. Every section below is mandatory. Thin tickets are rejected.
@@ -308,7 +322,7 @@ If the label does not exist in the tracker, create it, or record that it could n
 proceed — the marker still holds. Never file the label *instead of* the marker.
 
 **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/.codex-plugin/skills/lisa-linear-access/SKILL.md

@@ -323,7 +323,7 @@ query($id:String!,$after:String){
   project(id:$id){
     comments(first:100,after:$after){
       pageInfo{ hasNextPage endCursor }
-      nodes{ id body createdAt url user{ name } }
+      nodes{ id body createdAt url user{ id name } botActor{ __typename } }
     }
   }
 }
@@ -334,13 +334,16 @@ arguments and node shape. For **both** anchors, use this access-layer adapter wi
 `linear_graphql` above; it accumulates every page and prints no partial history.
 A read succeeds only after `hasNextPage` is false. Errors, malformed pages, and
 missing or repeated continuation cursors fail the whole read.
+Preserve `botActor` with each comment: its non-null presence identifies automation,
+even if `user.id` is trusted. When normalizing comments, carry it forward or set
+`isBot: true`; never discard this metadata before release authorization.
 
 ```bash
 linear_list_comment_pages() {  # issue|project id -> complete JSON node array
   local anchor="$1" id="$2" after=null nodes='[]' seen='[]'
   local query variables response connection cursor
   case "$anchor" in issue|project) ;; *) echo "Error: invalid comment anchor" >&2; return 1 ;; esac
-  query='query($id:String!,$after:String){'"$anchor"'(id:$id){comments(first:100,after:$after){pageInfo{hasNextPage endCursor} nodes{id body createdAt url user{name}}}}}'
+  query='query($id:String!,$after:String){'"$anchor"'(id:$id){comments(first:100,after:$after){pageInfo{hasNextPage endCursor} nodes{id body createdAt url user{id name} botActor{__typename}}}}}'
   while :; do
     variables=$(jq -cn --arg id "$id" --argjson after "$after" '{id:$id,after:$after}') || return 1
     response=$(linear_graphql "$query" "$variables") || return 1
@@ -367,6 +370,13 @@ linear_list_comment_pages() {  # issue|project id -> complete JSON node array
 }
 ```
 
+Keep the returned comment objects intact when a caller evaluates a human-gate release. The
+`user.id` is the stable author identity; `user.name` is display text and never authorizes release.
+Pass structured comments and an independently supplied `trustedHumanActorIds` allowlist to the
+shared gate helpers (`ready-role-filing` — Human-gate release authorization). A body-only projection
+loses identity and cannot discharge a hold. Preserve any explicit bot metadata from the provider;
+if identity or trusted policy is unavailable, leave the hold active.
+
 Call `linear_list_comment_pages project "$PROJECT_ID"` for `project_id`, or
 `linear_list_comment_pages issue "$ISSUE_ID"` for `issue_id`. The caller receives
 one complete node array; it must not interpret a failed command as zero comments.

package/plugins/lisa/.codex-plugin/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.
@@ -183,8 +197,8 @@ 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. **Read release comments before applying the human gate.** Pass all item comments, labels,
-   body and configured `humanNeededLabel` to `classifyReadyCandidate(...)`. For a discharged hold,
-   call `planHumanGateRelease({ labels, body, comments, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   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
@@ -196,7 +210,7 @@ For each pre-work candidate that is **not** in `$READY`:
 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 }
 ```
 
@@ -224,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
@@ -235,7 +249,7 @@ 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
@@ -245,7 +259,7 @@ other gate's verdict — however conclusive — may promote an item a person par
    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, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   `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

package/plugins/lisa/.codex-plugin/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)`.
@@ -304,7 +318,7 @@ 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/.codex-plugin/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
@@ -1071,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, comments, 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
@@ -1088,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.
@@ -1102,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**
@@ -1119,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