@codyswann/lisa 4.34.3 → 4.34.5

package/package.json

@@ -127,6 +127,7 @@
   "resolutions": {
     "@isaacs/brace-expansion": "^5.0.1",
     "axios": ">=1.15.2",
+    "browserslist": ">=4.28.8",
     "deepmerge-ts": "^8.0.1",
     "esbuild": ">=0.28.1",
     "eslint-plugin-react-hooks": "^7.0.0",
@@ -165,7 +166,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.34.3",
+  "version": "4.34.5",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -313,7 +314,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "77f31b7f3b5701b52d158ae63015212acf8be6e4",
-  "gitHead": "77f31b7f3b5701b52d158ae63015212acf8be6e4",
-  "lisaReleaseTag": "v4.34.3"
+  "lisaReleaseCommit": "f53b310d12af3c0d1e81173e95d9db7c5de23a5c",
+  "gitHead": "f53b310d12af3c0d1e81173e95d9db7c5de23a5c",
+  "lisaReleaseTag": "v4.34.5"
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.34.3",
+  "version": "4.34.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.34.3",
+  "version": "4.34.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

@@ -300,6 +300,41 @@ Lifecycle membership is decided by the **`status:` prefix**, never by a pinned m
 
 ### Phase 3 — Process the first eligible ready issue
 
+#### 3.0 Human-hold gate (absolute, and it runs before every other gate)
+
+A person parks an item by putting `[lisa-human-gate]` in its description. That marker used to be
+read only for candidates **outside** `$READY` (Phase 2's blocker re-probe), so an item already in
+the ready lane was claimed with the hold never consulted — one was dispatched and fully implemented
+before a human vetoed the merge. The check was correct; it was unreachable from the path that
+matters.
+
+Run this **first**, ahead of the repo-scope gate (3a.0) and the leaf-only gate (3a), for every ready
+candidate. Ordering is load-bearing for the same reason it is inside `classifyPreWorkCandidate`: no
+other gate's verdict — however conclusive — may promote an item a person parked.
+
+1. **Classify with `classifyReadyCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`. It
+   shares the gate test with the pre-work classifier deliberately — two copies of a substring test
+   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.
+2. **On `claimable: false` with reason `human-gate`, do not claim and do not dispatch.**
+3. **Reconcile the lane; do not merely skip.** Skipping alone leaves the item in `$READY`, re-judged
+   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 })`
+   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. **Name it in the cycle summary** via `summarizeHumanGateHolds([...])`, so the record
+   distinguishes "nothing was eligible" from "something eligible was held for a person". A lane
+   mutation nobody can see afterwards is the same class of problem this gate exists to fix.
+5. **Continue to the next candidate.** A held item does not end the cycle.
+
+
 #### 3a.0 Repo-scope gate (claim only current-repo issues)
 
 GitHub Issues live in one repo by definition, so the scanned repo's issues are usually inherently current-repo. But a planning/umbrella repo's issues can target sibling repos, so this skill still claims only issues for the repo it is running in. Run this gate **before** the leaf-only gate (3a) and the claim (3b), per the `repo-scope-split` rule's "Claim-time repo scoping" section (cite it by slug; do not restate its decision table).

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

@@ -205,6 +205,41 @@ true, and nothing re-read one before this phase. For each pre-work candidate out
 
 ### Phase 3 — Process the first eligible ready ticket
 
+#### 3.0 Human-hold gate (absolute, and it runs before every other gate)
+
+A person parks an item by putting `[lisa-human-gate]` in its description. That marker used to be
+read only for candidates **outside** `$READY` (Phase 2's blocker re-probe), so an item already in
+the ready lane was claimed with the hold never consulted — one was dispatched and fully implemented
+before a human vetoed the merge. The check was correct; it was unreachable from the path that
+matters.
+
+Run this **first**, ahead of the repo-scope gate (3a.0) and the leaf-only gate (3a), for every ready
+candidate. Ordering is load-bearing for the same reason it is inside `classifyPreWorkCandidate`: no
+other gate's verdict — however conclusive — may promote an item a person parked.
+
+1. **Classify with `classifyReadyCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`. It
+   shares the gate test with the pre-work classifier deliberately — two copies of a substring test
+   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.
+2. **On `claimable: false` with reason `human-gate`, do not claim and do not dispatch.**
+3. **Reconcile the lane; do not merely skip.** Skipping alone leaves the item in `$READY`, re-judged
+   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 })`
+   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. **Name it in the cycle summary** via `summarizeHumanGateHolds([...])`, so the record
+   distinguishes "nothing was eligible" from "something eligible was held for a person". A lane
+   mutation nobody can see afterwards is the same class of problem this gate exists to fix.
+5. **Continue to the next candidate.** A held item does not end the cycle.
+
+
 #### 3a.0 Repo-scope gate (claim only current-repo tickets)
 
 A JIRA project can oversee multiple repos (`frontend` / `backend` / `infrastructure`). This skill claims only tickets for the repo it is running in. Run this gate **before** the leaf-only gate (3a) and the claim (3b), per the `repo-scope-split` rule's "Claim-time repo scoping" section (cite it by slug; do not restate its decision table).

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

@@ -199,6 +199,41 @@ classifyPreWorkCandidate({ laneType, labels, body, humanNeededLabel, statedBlock
 
 ### Phase 3 — Process the first eligible ready Issue
 
+#### 3.0 Human-hold gate (absolute, and it runs before every other gate)
+
+A person parks an item by putting `[lisa-human-gate]` in its description. That marker used to be
+read only for candidates **outside** `$READY` (Phase 2's blocker re-probe), so an item already in
+the ready lane was claimed with the hold never consulted — one was dispatched and fully implemented
+before a human vetoed the merge. The check was correct; it was unreachable from the path that
+matters.
+
+Run this **first**, ahead of the repo-scope gate (3a.0) and the leaf-only gate (3a), for every ready
+candidate. Ordering is load-bearing for the same reason it is inside `classifyPreWorkCandidate`: no
+other gate's verdict — however conclusive — may promote an item a person parked.
+
+1. **Classify with `classifyReadyCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`. It
+   shares the gate test with the pre-work classifier deliberately — two copies of a substring test
+   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.
+2. **On `claimable: false` with reason `human-gate`, do not claim and do not dispatch.**
+3. **Reconcile the lane; do not merely skip.** Skipping alone leaves the item in `$READY`, re-judged
+   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 })`
+   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. **Name it in the cycle summary** via `summarizeHumanGateHolds([...])`, so the record
+   distinguishes "nothing was eligible" from "something eligible was held for a person". A lane
+   mutation nobody can see afterwards is the same class of problem this gate exists to fix.
+5. **Continue to the next candidate.** A held item does not end the cycle.
+
+
 #### 3a.0 Repo-scope gate (claim only current-repo Issues)
 
 A Linear team can oversee multiple repos (`frontend` / `backend` / `infrastructure`). This skill claims only Issues for the repo it is running in. Run this gate **before** the leaf-only gate (3a) and the claim (3b), per the `repo-scope-split` rule's "Claim-time repo scoping" section (cite it by slug; do not restate its decision table).

package/plugins/lisa/scripts/intake-blocker-reprobe.mjs

@@ -188,3 +188,137 @@ export function formatReprobeNote(candidate = {}, verdict) {
 
   return lines.join("\n");
 }
+
+/**
+ * Marker on the note this module leaves, so a later cycle recognises its own
+ * work instead of commenting again.
+ */
+export const HUMAN_GATE_NOTE_MARKER = "<!-- [lisa-human-gate-reconciled] -->";
+
+/**
+ * Decide whether a candidate ALREADY IN THE READY LANE may be claimed.
+ *
+ * `classifyPreWorkCandidate` was the only caller of the human-gate test, and it
+ * runs on candidates outside the ready lane. An item that reached the ready
+ * lane was therefore claimed with the gate never consulted — the check was
+ * correct and simply unreachable from the path that matters.
+ *
+ * This shares `isHumanGated` with the pre-work classifier deliberately. Two
+ * copies of a substring test drift, and a drifted gate fails silently: it stops
+ * matching, and nothing reports that it stopped.
+ *
+ * The test stays a plain literal-substring match and is NOT keyed on `reason=`.
+ * Markers in the wild carry no `reason=` at all and sit anywhere in the body, so
+ * a parser keyed on the structured field would miss those while appearing to
+ * work on every item that happens to have one — reproducing this defect one
+ * layer down.
+ * @param {{ labels?: unknown, body?: unknown, humanNeededLabel?: unknown }} input - Candidate surfaces
+ * @returns {{ claimable: boolean, reason: string, humanGated: boolean }} Claim verdict
+ */
+export function classifyReadyCandidate(input = {}) {
+  if (isHumanGated(input)) {
+    return { claimable: false, reason: "human-gate", humanGated: true };
+  }
+  return { claimable: true, reason: "ready-eligible", humanGated: false };
+}
+
+/**
+ * Plan the state repair for a ready-lane item that is held for a person.
+ *
+ * Skipping such an item is not enough. `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. Skipping alone would leave it
+ * re-evaluated and re-rejected every cycle forever, seen by nothing — trading a
+ * loud failure for a silent one.
+ *
+ * So the lane is reconciled to match the hold: the item leaves the pickup queue
+ * and gains the human-needed marker. That is the same repair the leaf-only gate
+ * already performs for a ready item that must not be dispatched.
+ *
+ * Idempotent by state rather than by memory: an item already out of the queue
+ * and already marked needs nothing, so asking twice yields no second mutation.
+ * @param {{
+ *   labels?: unknown
+ *   body?: unknown
+ *   humanNeededLabel?: unknown
+ *   readyLabel?: unknown
+ *   alreadyNotified?: unknown
+ * }} input - Candidate surfaces plus the configured lane and marker labels
+ * @returns {{ gated: boolean, reason: string, actions: { removeReadyRole: boolean, addHumanNeededLabel: boolean, comment: boolean } }} Repair plan
+ */
+export function planHumanGateReconciliation(input = {}) {
+  const idle = Object.freeze({
+    removeReadyRole: false,
+    addHumanNeededLabel: false,
+    comment: false,
+  });
+  if (!isHumanGated(input)) {
+    return { gated: false, reason: "not-gated", actions: idle };
+  }
+
+  const labels = normalizeLabels(input.labels);
+  const needed = String(input.humanNeededLabel ?? DEFAULT_HUMAN_NEEDED_LABEL)
+    .trim()
+    .toLowerCase();
+  const ready = String(input.readyLabel ?? "")
+    .trim()
+    .toLowerCase();
+  const inReadyLane = ready.length > 0 && labels.includes(ready);
+  const marked = needed.length > 0 && labels.includes(needed);
+  const actions = {
+    removeReadyRole: inReadyLane,
+    addHumanNeededLabel: needed.length > 0 && !marked,
+    comment:
+      input.alreadyNotified !== true &&
+      (inReadyLane || (needed.length > 0 && !marked)),
+  };
+  const changed =
+    actions.removeReadyRole || actions.addHumanNeededLabel || actions.comment;
+
+  return {
+    gated: true,
+    reason: changed ? "reconcile" : "already-reconciled",
+    actions,
+  };
+}
+
+/**
+ * Render the hold notice for a reader who does not know this subsystem.
+ *
+ * Written for a non-technical operator on purpose — that is who stands at this
+ * gate. It names what was found, what changed, and how to undo it, and uses no
+ * skill name, label syntax, or phase number, none of which a reader can act on.
+ * @returns {string} Comment body, carrying the marker that keeps a re-run quiet
+ */
+export function formatHumanGateNote() {
+  return [
+    "**On hold for a person**",
+    "",
+    "- What was found: this item is marked as held for a person, but it was " +
+      "also sitting in the queue that agents build from — so it would have " +
+      "been picked up and built anyway.",
+    "- What changed: it has been taken out of that queue and flagged as " +
+      "needing a person, so nothing will build it automatically.",
+    "- To resume it: remove the hold note from the description and put it " +
+      "back in the build queue.",
+    "",
+    HUMAN_GATE_NOTE_MARKER,
+  ].join("\n");
+}
+
+/**
+ * Render the cycle-summary line naming what was held.
+ *
+ * A lane mutation nobody can see afterwards is the same class of problem as the
+ * one this fixes, so the run says what it moved — and it keeps "nothing was
+ * eligible" distinguishable from "something eligible was held".
+ * @param {readonly unknown[]} held - Item references held this cycle
+ * @returns {string} One summary line
+ */
+export function summarizeHumanGateHolds(held = []) {
+  const names = (Array.isArray(held) ? held : [])
+    .map(item => trimmedString(item))
+    .filter(name => name.length > 0);
+  if (names.length === 0) return "Held for a person: none.";
+  return `Held for a person (${String(names.length)}): ${names.join(", ")}.`;
+}

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

@@ -300,6 +300,41 @@ Lifecycle membership is decided by the **`status:` prefix**, never by a pinned m
 
 ### Phase 3 — Process the first eligible ready issue
 
+#### 3.0 Human-hold gate (absolute, and it runs before every other gate)
+
+A person parks an item by putting `[lisa-human-gate]` in its description. That marker used to be
+read only for candidates **outside** `$READY` (Phase 2's blocker re-probe), so an item already in
+the ready lane was claimed with the hold never consulted — one was dispatched and fully implemented
+before a human vetoed the merge. The check was correct; it was unreachable from the path that
+matters.
+
+Run this **first**, ahead of the repo-scope gate (3a.0) and the leaf-only gate (3a), for every ready
+candidate. Ordering is load-bearing for the same reason it is inside `classifyPreWorkCandidate`: no
+other gate's verdict — however conclusive — may promote an item a person parked.
+
+1. **Classify with `classifyReadyCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`. It
+   shares the gate test with the pre-work classifier deliberately — two copies of a substring test
+   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.
+2. **On `claimable: false` with reason `human-gate`, do not claim and do not dispatch.**
+3. **Reconcile the lane; do not merely skip.** Skipping alone leaves the item in `$READY`, re-judged
+   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 })`
+   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. **Name it in the cycle summary** via `summarizeHumanGateHolds([...])`, so the record
+   distinguishes "nothing was eligible" from "something eligible was held for a person". A lane
+   mutation nobody can see afterwards is the same class of problem this gate exists to fix.
+5. **Continue to the next candidate.** A held item does not end the cycle.
+
+
 #### 3a.0 Repo-scope gate (claim only current-repo issues)
 
 GitHub Issues live in one repo by definition, so the scanned repo's issues are usually inherently current-repo. But a planning/umbrella repo's issues can target sibling repos, so this skill still claims only issues for the repo it is running in. Run this gate **before** the leaf-only gate (3a) and the claim (3b), per the `repo-scope-split` rule's "Claim-time repo scoping" section (cite it by slug; do not restate its decision table).

package/plugins/lisa/skills/lisa-jira-build-intake/SKILL.md

@@ -205,6 +205,41 @@ true, and nothing re-read one before this phase. For each pre-work candidate out
 
 ### Phase 3 — Process the first eligible ready ticket
 
+#### 3.0 Human-hold gate (absolute, and it runs before every other gate)
+
+A person parks an item by putting `[lisa-human-gate]` in its description. That marker used to be
+read only for candidates **outside** `$READY` (Phase 2's blocker re-probe), so an item already in
+the ready lane was claimed with the hold never consulted — one was dispatched and fully implemented
+before a human vetoed the merge. The check was correct; it was unreachable from the path that
+matters.
+
+Run this **first**, ahead of the repo-scope gate (3a.0) and the leaf-only gate (3a), for every ready
+candidate. Ordering is load-bearing for the same reason it is inside `classifyPreWorkCandidate`: no
+other gate's verdict — however conclusive — may promote an item a person parked.
+
+1. **Classify with `classifyReadyCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`. It
+   shares the gate test with the pre-work classifier deliberately — two copies of a substring test
+   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.
+2. **On `claimable: false` with reason `human-gate`, do not claim and do not dispatch.**
+3. **Reconcile the lane; do not merely skip.** Skipping alone leaves the item in `$READY`, re-judged
+   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 })`
+   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. **Name it in the cycle summary** via `summarizeHumanGateHolds([...])`, so the record
+   distinguishes "nothing was eligible" from "something eligible was held for a person". A lane
+   mutation nobody can see afterwards is the same class of problem this gate exists to fix.
+5. **Continue to the next candidate.** A held item does not end the cycle.
+
+
 #### 3a.0 Repo-scope gate (claim only current-repo tickets)
 
 A JIRA project can oversee multiple repos (`frontend` / `backend` / `infrastructure`). This skill claims only tickets for the repo it is running in. Run this gate **before** the leaf-only gate (3a) and the claim (3b), per the `repo-scope-split` rule's "Claim-time repo scoping" section (cite it by slug; do not restate its decision table).

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

@@ -199,6 +199,41 @@ classifyPreWorkCandidate({ laneType, labels, body, humanNeededLabel, statedBlock
 
 ### Phase 3 — Process the first eligible ready Issue
 
+#### 3.0 Human-hold gate (absolute, and it runs before every other gate)
+
+A person parks an item by putting `[lisa-human-gate]` in its description. That marker used to be
+read only for candidates **outside** `$READY` (Phase 2's blocker re-probe), so an item already in
+the ready lane was claimed with the hold never consulted — one was dispatched and fully implemented
+before a human vetoed the merge. The check was correct; it was unreachable from the path that
+matters.
+
+Run this **first**, ahead of the repo-scope gate (3a.0) and the leaf-only gate (3a), for every ready
+candidate. Ordering is load-bearing for the same reason it is inside `classifyPreWorkCandidate`: no
+other gate's verdict — however conclusive — may promote an item a person parked.
+
+1. **Classify with `classifyReadyCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`. It
+   shares the gate test with the pre-work classifier deliberately — two copies of a substring test
+   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.
+2. **On `claimable: false` with reason `human-gate`, do not claim and do not dispatch.**
+3. **Reconcile the lane; do not merely skip.** Skipping alone leaves the item in `$READY`, re-judged
+   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 })`
+   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. **Name it in the cycle summary** via `summarizeHumanGateHolds([...])`, so the record
+   distinguishes "nothing was eligible" from "something eligible was held for a person". A lane
+   mutation nobody can see afterwards is the same class of problem this gate exists to fix.
+5. **Continue to the next candidate.** A held item does not end the cycle.
+
+
 #### 3a.0 Repo-scope gate (claim only current-repo Issues)
 
 A Linear team can oversee multiple repos (`frontend` / `backend` / `infrastructure`). This skill claims only Issues for the repo it is running in. Run this gate **before** the leaf-only gate (3a) and the claim (3b), per the `repo-scope-split` rule's "Claim-time repo scoping" section (cite it by slug; do not restate its decision table).

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/scripts/intake-blocker-reprobe.mjs

@@ -188,3 +188,137 @@ export function formatReprobeNote(candidate = {}, verdict) {
 
   return lines.join("\n");
 }
+
+/**
+ * Marker on the note this module leaves, so a later cycle recognises its own
+ * work instead of commenting again.
+ */
+export const HUMAN_GATE_NOTE_MARKER = "<!-- [lisa-human-gate-reconciled] -->";
+
+/**
+ * Decide whether a candidate ALREADY IN THE READY LANE may be claimed.
+ *
+ * `classifyPreWorkCandidate` was the only caller of the human-gate test, and it
+ * runs on candidates outside the ready lane. An item that reached the ready
+ * lane was therefore claimed with the gate never consulted — the check was
+ * correct and simply unreachable from the path that matters.
+ *
+ * This shares `isHumanGated` with the pre-work classifier deliberately. Two
+ * copies of a substring test drift, and a drifted gate fails silently: it stops
+ * matching, and nothing reports that it stopped.
+ *
+ * The test stays a plain literal-substring match and is NOT keyed on `reason=`.
+ * Markers in the wild carry no `reason=` at all and sit anywhere in the body, so
+ * a parser keyed on the structured field would miss those while appearing to
+ * work on every item that happens to have one — reproducing this defect one
+ * layer down.
+ * @param {{ labels?: unknown, body?: unknown, humanNeededLabel?: unknown }} input - Candidate surfaces
+ * @returns {{ claimable: boolean, reason: string, humanGated: boolean }} Claim verdict
+ */
+export function classifyReadyCandidate(input = {}) {
+  if (isHumanGated(input)) {
+    return { claimable: false, reason: "human-gate", humanGated: true };
+  }
+  return { claimable: true, reason: "ready-eligible", humanGated: false };
+}
+
+/**
+ * Plan the state repair for a ready-lane item that is held for a person.
+ *
+ * Skipping such an item is not enough. `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. Skipping alone would leave it
+ * re-evaluated and re-rejected every cycle forever, seen by nothing — trading a
+ * loud failure for a silent one.
+ *
+ * So the lane is reconciled to match the hold: the item leaves the pickup queue
+ * and gains the human-needed marker. That is the same repair the leaf-only gate
+ * already performs for a ready item that must not be dispatched.
+ *
+ * Idempotent by state rather than by memory: an item already out of the queue
+ * and already marked needs nothing, so asking twice yields no second mutation.
+ * @param {{
+ *   labels?: unknown
+ *   body?: unknown
+ *   humanNeededLabel?: unknown
+ *   readyLabel?: unknown
+ *   alreadyNotified?: unknown
+ * }} input - Candidate surfaces plus the configured lane and marker labels
+ * @returns {{ gated: boolean, reason: string, actions: { removeReadyRole: boolean, addHumanNeededLabel: boolean, comment: boolean } }} Repair plan
+ */
+export function planHumanGateReconciliation(input = {}) {
+  const idle = Object.freeze({
+    removeReadyRole: false,
+    addHumanNeededLabel: false,
+    comment: false,
+  });
+  if (!isHumanGated(input)) {
+    return { gated: false, reason: "not-gated", actions: idle };
+  }
+
+  const labels = normalizeLabels(input.labels);
+  const needed = String(input.humanNeededLabel ?? DEFAULT_HUMAN_NEEDED_LABEL)
+    .trim()
+    .toLowerCase();
+  const ready = String(input.readyLabel ?? "")
+    .trim()
+    .toLowerCase();
+  const inReadyLane = ready.length > 0 && labels.includes(ready);
+  const marked = needed.length > 0 && labels.includes(needed);
+  const actions = {
+    removeReadyRole: inReadyLane,
+    addHumanNeededLabel: needed.length > 0 && !marked,
+    comment:
+      input.alreadyNotified !== true &&
+      (inReadyLane || (needed.length > 0 && !marked)),
+  };
+  const changed =
+    actions.removeReadyRole || actions.addHumanNeededLabel || actions.comment;
+
+  return {
+    gated: true,
+    reason: changed ? "reconcile" : "already-reconciled",
+    actions,
+  };
+}
+
+/**
+ * Render the hold notice for a reader who does not know this subsystem.
+ *
+ * Written for a non-technical operator on purpose — that is who stands at this
+ * gate. It names what was found, what changed, and how to undo it, and uses no
+ * skill name, label syntax, or phase number, none of which a reader can act on.
+ * @returns {string} Comment body, carrying the marker that keeps a re-run quiet
+ */
+export function formatHumanGateNote() {
+  return [
+    "**On hold for a person**",
+    "",
+    "- What was found: this item is marked as held for a person, but it was " +
+      "also sitting in the queue that agents build from — so it would have " +
+      "been picked up and built anyway.",
+    "- What changed: it has been taken out of that queue and flagged as " +
+      "needing a person, so nothing will build it automatically.",
+    "- To resume it: remove the hold note from the description and put it " +
+      "back in the build queue.",
+    "",
+    HUMAN_GATE_NOTE_MARKER,
+  ].join("\n");
+}
+
+/**
+ * Render the cycle-summary line naming what was held.
+ *
+ * A lane mutation nobody can see afterwards is the same class of problem as the
+ * one this fixes, so the run says what it moved — and it keeps "nothing was
+ * eligible" distinguishable from "something eligible was held".
+ * @param {readonly unknown[]} held - Item references held this cycle
+ * @returns {string} One summary line
+ */
+export function summarizeHumanGateHolds(held = []) {
+  const names = (Array.isArray(held) ? held : [])
+    .map(item => trimmedString(item))
+    .filter(name => name.length > 0);
+  if (names.length === 0) return "Held for a person: none.";
+  return `Held for a person (${String(names.length)}): ${names.join(", ")}.`;
+}

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

@@ -300,6 +300,41 @@ Lifecycle membership is decided by the **`status:` prefix**, never by a pinned m
 
 ### Phase 3 — Process the first eligible ready issue
 
+#### 3.0 Human-hold gate (absolute, and it runs before every other gate)
+
+A person parks an item by putting `[lisa-human-gate]` in its description. That marker used to be
+read only for candidates **outside** `$READY` (Phase 2's blocker re-probe), so an item already in
+the ready lane was claimed with the hold never consulted — one was dispatched and fully implemented
+before a human vetoed the merge. The check was correct; it was unreachable from the path that
+matters.
+
+Run this **first**, ahead of the repo-scope gate (3a.0) and the leaf-only gate (3a), for every ready
+candidate. Ordering is load-bearing for the same reason it is inside `classifyPreWorkCandidate`: no
+other gate's verdict — however conclusive — may promote an item a person parked.
+
+1. **Classify with `classifyReadyCandidate(...)`** from `scripts/intake-blocker-reprobe.mjs`. It
+   shares the gate test with the pre-work classifier deliberately — two copies of a substring test
+   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.
+2. **On `claimable: false` with reason `human-gate`, do not claim and do not dispatch.**
+3. **Reconcile the lane; do not merely skip.** Skipping alone leaves the item in `$READY`, re-judged
+   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 })`
+   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. **Name it in the cycle summary** via `summarizeHumanGateHolds([...])`, so the record
+   distinguishes "nothing was eligible" from "something eligible was held for a person". A lane
+   mutation nobody can see afterwards is the same class of problem this gate exists to fix.
+5. **Continue to the next candidate.** A held item does not end the cycle.
+
+
 #### 3a.0 Repo-scope gate (claim only current-repo issues)
 
 GitHub Issues live in one repo by definition, so the scanned repo's issues are usually inherently current-repo. But a planning/umbrella repo's issues can target sibling repos, so this skill still claims only issues for the repo it is running in. Run this gate **before** the leaf-only gate (3a) and the claim (3b), per the `repo-scope-split` rule's "Claim-time repo scoping" section (cite it by slug; do not restate its decision table).