@codyswann/lisa 4.37.2 → 4.38.0

package/plugins/lisa/rules/reference/withdrawn-rulings.md

@@ -0,0 +1,114 @@
+# Withdrawn Rulings — reference
+
+Long-form body for the eager rule `withdrawn-rulings`. Origin: CodySwannGT/lisa#3752.
+
+## The general property
+
+A session is a snapshot. Three independent instances of it were measured on one day:
+
+1. **Plugin version.** A session executes the plugin cache directory resolved *when the session
+   started*. A session roughly eleven hours old was running one version while the default branch and
+   the marketplace clone were two releases ahead — with the newer version already sitting in that
+   cache. Not a distribution failure: updating the cache does not help a running session, only a
+   restart re-resolves. That session reported an already-fixed defect as live, persuasively, because
+   it really had observed the behaviour. It was reporting the truth about a stale binary.
+2. **Rules injection.** The rule injector reads `rules/eager/*.md` and concatenates them into
+   context at SessionStart and SubagentStart. No metadata, no expiry, no filter — a rule withdrawn
+   upstream stays in the context of every session that started before the withdrawal, for that
+   session's whole life.
+3. **Shipped versus in effect.** A fix merged to the default branch is not in effect for any session
+   already running.
+
+**A fix has two facts behind it: that it exists, and that it is in effect.** Testing either one and
+reporting "fixed" is the error. Two agents made opposite halves of that mistake in a single evening,
+neither carelessly, each holding a real measurement.
+
+## The two instances that produced this rule
+
+**A correction that was itself wrong, published.** A claim was refuted with specific file-and-line
+evidence. The refutation was propagated to two agents and into a public work-item comment before a
+third agent, reading the source directly, established that the original claim was right and the
+refutation had been produced by grepping a stale checkout. The wrong correction stood for roughly
+forty minutes. Anyone who read that item in the interval holds the wrong version and has no signal
+it changed — the retraction is a later comment, which a reader who has already formed a conclusion
+will not necessarily see.
+
+**A workaround circulated, then retracted.** A technique was recommended to three agents, then
+disproved by measurement and withdrawn. The three had no mechanism to learn it was withdrawn.
+
+And the technique had **zero observed successes but still read as having worked**: the agent
+performed it, the very next operation was refused, it worked around the failure by other means, and
+later the condition the technique was supposed to create arrived on its own for unrelated reasons.
+Nothing about that sequence looks like a failure from outside.
+
+## Why durable memory is the worst case
+
+A superseded finding survives longest exactly where it was best recorded. A claim made in passing
+decays with the conversation; a claim written to a memory file persists and is re-read
+authoritatively by future sessions. **The more responsibly a finding was captured, the more durable
+its error becomes** — and the retraction, being conversational, decays while the claim does not.
+
+## What makes this hard
+
+- **A session cannot detect that its own context is stale.** Context completeness is not observable
+  from inside. Any fix that asks an agent to assess its own context is the trap, not the remedy.
+- **A retraction is usually not written to any canonical surface.** It is a reply, produced under
+  exactly the conditions least likely to bear a chore.
+- **The audience is not enumerable.** Whoever received the original may have relayed it onward, and
+  a session that has gone quiet is unreachable by any message.
+
+The third point is why the mechanism is a **re-check by the reader**, not a broadcast by the
+publisher. The publisher records once; every live session re-checks on its own.
+
+## The ledger's two tiers
+
+| tier | path | who it reaches |
+|---|---|---|
+| repository | `.lisa/WITHDRAWN.jsonl` (committed, union-merged) | every future reader of this project, forever |
+| machine | `${LISA_STATE_HOME:-~/.lisa}/withdrawn-rulings.jsonl` | sibling sessions in **other worktrees on this machine, now** |
+
+A withdrawal is written to both by one command; reads are the union, de-duplicated by id. The
+machine tier exists because a committed file cannot reach a sibling agent until it is merged and
+pulled, and the audience that needs the retraction soonest is the one working beside you.
+
+JSONL rather than prose: each line is independent, so concurrent appends from many agents do not
+collide and `merge=union` reconstructs the union exactly. A prose ledger would need a bespoke merge
+driver to survive the same traffic.
+
+## How a running session is reached
+
+`--session-start` stamps a per-session mark recording the ids the session was born already knowing.
+`--hook` runs after every tool result and announces exactly the entries that appeared **since**,
+once each.
+
+The common case is the cheap case: when neither ledger's `size:mtime` has moved, `--hook` returns
+after two `stat` calls without parsing anything. It fires on every tool call in every session and
+every subagent, so anything expensive multiplies.
+
+A **missing mark is deliberately silent**. A session with no mark is one whose starting knowledge is
+unknown; announcing every historical withdrawal to it would degrade the mechanism into distrusting
+everything, which is the failure the control case in #3752 exists to prevent.
+
+## Surface parity
+
+| surface | session stamp | mid-session announcement | `--list` at the escalation boundary |
+|---|---|---|---|
+| Claude Code | yes — SessionStart and SubagentStart | yes — PostToolUse | yes |
+| Codex | yes, interactive only | yes, interactive only | yes |
+| Cursor | yes — both start events | yes | yes |
+| Copilot | main sessions only — it has no subagent-start event, so a Copilot subagent is stamp-less and therefore silent | yes — `postToolUse` | yes |
+| Antigravity | no — its plugin ships blocking `PreToolUse` guards only, and headless hooks do not fire | no | yes |
+| OpenCode | no — it has no plugin hook runtime, only rules and skills | no | yes |
+
+Where a surface cannot carry the automatic half, the eager rule's `--list` instruction is the
+carried half: it is the same pointer shape #3592 shipped, which survives precisely because it does
+not travel inside the thing it points at. `codex exec` runs no plugin hooks at all, so on that
+surface the ledger is a read the agent performs, not one performed for it. Antigravity and OpenCode
+are the same shape, permanently rather than per-invocation: neither carries a session-lifecycle hook
+today, which is the identical accommodation `failure-signature-index` makes on those two surfaces.
+
+## What deliberately does not belong here
+
+A disagreement that has not been settled. The ledger is for a claim its own author has **withdrawn**
+— not for a claim someone doubts. A tombstone for a live dispute converts the ledger into an
+argument, and an argument is not something a session can act on in one line.

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

@@ -38,10 +38,20 @@ function normalizeLabels(labels) {
 }
 
 /**
- * @param {{ labels?: unknown, body?: unknown, humanNeededLabel?: unknown }} input
- * @returns {boolean}
+ * Whether an item is held for a person, on either surface.
+ *
+ * Exported deliberately, and it is the ONLY answer to that question anywhere in
+ * the intake machinery. Every selection and promotion path calls this rather
+ * than inspecting labels itself, because the label surface alone is a partial
+ * answer: the vendor writers stamp the body marker on a deliberate hold, so an
+ * item held exactly as the filing contract instructs carries no label at all.
+ * A path that read labels alone judged such an item unheld and promoted it —
+ * which is #3805, and is why this is a shared function rather than a shared
+ * convention.
+ * @param {{ labels?: unknown, body?: unknown, humanNeededLabel?: unknown }} input - Candidate surfaces
+ * @returns {boolean} True when a person is holding this item
  */
-function isHumanGated(input) {
+export function isHumanGated(input) {
   const configured = String(
     input.humanNeededLabel ?? DEFAULT_HUMAN_NEEDED_LABEL
   )
@@ -282,6 +292,113 @@ export function planHumanGateReconciliation(input = {}) {
   };
 }
 
+/**
+ * Marker on the note the normalization sweep leaves, so a later cycle
+ * recognises its own work instead of commenting again.
+ *
+ * Deliberately NOT the hold marker and deliberately not a superstring of it:
+ * `HUMAN_GATE_MARKER` closes with `]`, so neither this nor
+ * `HUMAN_GATE_NOTE_MARKER` matches it. A note that read as a hold declaration
+ * would make every reported item look held to the next body-reading sweep,
+ * including items the report merely names.
+ */
+export const NORMALIZATION_HOLD_NOTE_MARKER =
+  "<!-- [lisa-human-gate-normalization-held] -->";
+
+/**
+ * Decide whether an item carrying NO configured lifecycle label may be
+ * normalized into a ready lane.
+ *
+ * This is the promotion path, and it was keyed on labels alone. The configured
+ * `human_needed` label is one of the lifecycle labels whose *absence* the sweep
+ * enumerates on, so an item held only by the body marker was a member of the
+ * swept population by definition and got the build-ready label applied to it.
+ * The `[lisa-human-gate]` exclusion existed, in a different and read-only sweep
+ * further down the same contract: the one sweep that writes was the one that
+ * could not see the marker.
+ *
+ * Order is load-bearing for the same reason it is in `classifyPreWorkCandidate`:
+ * the hold is checked before lane membership and before any classification, so
+ * nothing downstream — however confident — can promote an item a person parked.
+ *
+ * On a match this plans NO write of its own. `planHumanGateReconciliation`
+ * turns a match into durable state, so a false positive there latches and every
+ * later cycle agrees with the first. The gate test is a plain substring match
+ * whose imprecision is tracked separately, so this path refuses and reports
+ * read-only instead — the same treatment the ungated-filing sweep already gives
+ * a hold it finds.
+ * @param {{
+ *   labels?: unknown
+ *   body?: unknown
+ *   humanNeededLabel?: unknown
+ *   lifecycleLabels?: unknown
+ *   readyLabel?: unknown
+ * }} input - Candidate surfaces plus the configured lifecycle vocabulary
+ * @returns {{ normalize: boolean, reason: string, humanGated: boolean, actions: { addReadyLabel: string | null, reportHold: boolean } }} Normalization plan
+ */
+export function planLabelNormalization(input = {}) {
+  const idle = Object.freeze({ addReadyLabel: null, reportHold: false });
+  if (isHumanGated(input)) {
+    return {
+      normalize: false,
+      reason: "human-gate",
+      humanGated: true,
+      actions: Object.freeze({ addReadyLabel: null, reportHold: true }),
+    };
+  }
+
+  const labels = normalizeLabels(input.labels);
+  if (normalizeLabels(input.lifecycleLabels).some(l => labels.includes(l))) {
+    return {
+      normalize: false,
+      reason: "already-in-lifecycle",
+      humanGated: false,
+      actions: idle,
+    };
+  }
+
+  const ready = trimmedString(input.readyLabel);
+  if (ready.length === 0) {
+    return {
+      normalize: false,
+      reason: "no-ready-label",
+      humanGated: false,
+      actions: idle,
+    };
+  }
+
+  return {
+    normalize: true,
+    reason: "normalize",
+    humanGated: false,
+    actions: Object.freeze({ addReadyLabel: ready, reportHold: false }),
+  };
+}
+
+/**
+ * Render the notice for an item the normalization sweep left alone.
+ *
+ * Distinct from `formatHumanGateNote` because the two say opposite things
+ * about what happened: that one reports a lane that WAS changed, this one
+ * reports a promotion that was declined and nothing else. Reusing it would tell
+ * an operator their item had been moved when it had not.
+ * @returns {string} Comment body, carrying the marker that keeps a re-run quiet
+ */
+export function formatNormalizationHoldNote() {
+  return [
+    "**Left alone: a person is holding this**",
+    "",
+    "- What was found: the description says a person is holding this one, so " +
+      "it was not put into the queue that agents work from.",
+    "- What changed: nothing at all. It was left exactly as it is, and " +
+      "nothing will pick it up on its own.",
+    "- To resume it: remove the hold note from the description, then put it " +
+      "into the build queue.",
+    "",
+    NORMALIZATION_HOLD_NOTE_MARKER,
+  ].join("\n");
+}
+
 /**
  * Render the hold notice for a reader who does not know this subsystem.
  *

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

@@ -276,6 +276,17 @@ Held for a human product call: <reason>.
 <!-- [lisa-human-gate] reason=<short-slug> -->
 ```
 
+**Stamp both surfaces, not just the marker.** Also apply the configured `human_needed` marker
+label (`github.labels.build.human_needed`, default `human-needed`) to the issue, via `gh issue edit`/`gh issue create --label`. The marker in the body and the label say the same thing,
+and a filing that carries only one of them is a **half-armed gate**: sweeps that read the body
+honour it, and sweeps that read labels do not. That is not hypothetical — the repair sweep that
+normalizes items carrying no lifecycle label keys on the *absence* of `human_needed`, so a
+marker-only hold was its population by construction and got promoted into the build queue (#3805).
+The marker remains the authoritative declaration; the label is what makes the hold visible to a
+person scanning a board and to any path that has not yet been routed through the shared reader.
+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.
+
 If a leaf arrives with `build_ready` omitted or `false` **and** no `human_gate`, do not create it: report the incomplete handoff and name both ways to resolve it (`build_ready: true`, or a `human_gate` reason). Containers are exempt — their state rolls up from children, so they need neither.
 
 ## Phase 5.5 — Validate (Pre-write Gate)

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

@@ -261,6 +261,17 @@ Held for a human product call: <reason>.
 <!-- [lisa-human-gate] reason=<short-slug> -->
 ```
 
+**Stamp both surfaces, not just the marker.** Also apply the configured `human_needed` marker
+label (`jira.labels.human_needed`, default `Human Needed`) to the ticket, via the ticket's `labels` field. The marker in the body and the label say the same thing,
+and a filing that carries only one of them is a **half-armed gate**: sweeps that read the body
+honour it, and sweeps that read labels do not. That is not hypothetical — the repair sweep that
+normalizes items carrying no lifecycle label keys on the *absence* of `human_needed`, so a
+marker-only hold was its population by construction and got promoted into the build queue (#3805).
+The marker remains the authoritative declaration; the label is what makes the hold visible to a
+person scanning a board and to any path that has not yet been routed through the shared reader.
+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.
+
 If a leaf arrives with `build_ready` omitted or `false` **and** no `human_gate`, do not create it: report the incomplete handoff and name both ways to resolve it (`build_ready: true`, or a `human_gate` reason). Containers are exempt — their status rolls up from children, so they need neither.
 
 ## Phase 5.5 — Validate (Pre-write Gate)

package/plugins/lisa/skills/lisa-linear-write-issue/SKILL.md

@@ -280,6 +280,17 @@ Held for a human product call: <reason>.
 <!-- [lisa-human-gate] reason=<short-slug> -->
 ```
 
+**Stamp both surfaces, not just the marker.** Also apply the configured `human_needed` marker
+label (`linear.labels.build.human_needed`, default `human-needed`) to the Issue, via the Issue's labels (create it via `create_issue_label` if absent). The marker in the body and the label say the same thing,
+and a filing that carries only one of them is a **half-armed gate**: sweeps that read the body
+honour it, and sweeps that read labels do not. That is not hypothetical — the repair sweep that
+normalizes items carrying no lifecycle label keys on the *absence* of `human_needed`, so a
+marker-only hold was its population by construction and got promoted into the build queue (#3805).
+The marker remains the authoritative declaration; the label is what makes the hold visible to a
+person scanning a board and to any path that has not yet been routed through the shared reader.
+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.
+
 If a leaf arrives with `build_ready` omitted or `false` **and** no `human_gate`, do not create it: report the incomplete handoff and name both ways to resolve it (`build_ready: true`, or a `human_gate` reason). Containers are exempt — their state rolls up from children, so they need neither.
 
 ## Phase 5.5 — Validate (Pre-write Gate)

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

@@ -951,6 +951,23 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    selected by `intake_mode`. If `intake_mode=prd`, only PRD-classified issues are normalized. If
    `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
+   `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
+   hold, and `human_needed` is one of the lifecycle labels this sweep keys on the **absence** of —
+   so an item held exactly as the filing contract instructs is a member of this swept population by
+   construction, and a label-only read promoted it into the build queue (#3805). The
+   `[lisa-human-gate]` exclusion already existed in the read-only "Ungated non-ready filing" sweep
+   below; the one sweep that writes was the one that could not see it.
+
+   On `normalize: false` with reason `human-gate`, **stop for that item**: apply no label, do not
+   classify it, and report it read-only per step 5. Writing a label here — even the human-needed
+   marker — would turn a match into durable state on a second path, and the gate test is a plain
+   substring match whose precision is a separate open defect (#3815). Refusing and reporting is
+   the safe failure direction without the latch. Count these under `held_for_person`, never under
+   `normalized_ready`.
 3. Classify the issue:
    - **PRD** if it has PRD labels/markers (`prd`, `type:PRD`, `kind:prd`), PRD structure
      (`## Problem`, `## Goals`, `## Validation Journey`, generated-work/backlink sections), or
@@ -964,7 +981,8 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    - **Ambiguous PRD/build** if strong PRD and build classifications both match. In `intake_mode=prd`
      normalize as PRD; in `intake_mode=build` normalize as build; in `intake_mode=both`, prefer PRD
      only when the body has PRD structure, otherwise build.
-4. Apply exactly one configured ready label for the classified lifecycle:
+4. Apply exactly one configured ready label for the classified lifecycle — and only when step
+   2a returned `normalize: true`; its `actions.addReadyLabel` is the label to apply, verbatim:
    - PRD → add the configured PRD `ready` label (default `prd-ready`).
    - Build ticket → add the configured build `ready` label (default `status:ready`).
    Keep any unofficial labels for auditability unless the project has explicitly configured one as a
@@ -972,7 +990,11 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    normalization makes the next normal `lisa-intake` run pick it up.
 5. Post one idempotent `[lisa-repair-intake]` note naming the classification and the configured label
    applied. Include the normalization result in the loop-prevention fingerprint so repeated repair
-   cycles do not spam comments.
+   cycles do not spam comments. For an item step 2a held, post `formatNormalizationHoldNote()`
+   instead — it says that nothing was changed and how a person resumes the item, which is the
+   opposite of what the reconciliation note says and must not be substituted for it. A promotion
+   declined silently is invisible, which is the quieter version of the failure this step exists to
+   prevent, so name every held item in the cycle summary via `summarizeHumanGateHolds([...])`.
 
 ### Ungated non-ready filing → surface as an incomplete handoff (read-only)
 
@@ -1223,6 +1245,8 @@ It MAY:
   Epic/Story container** from its hierarchy/body-parentage children — so rollup and the GitHub UI can
   rely on the native graph. This repairs structure only; it does not ship, transition, or verify the
   parent.
+- Leave a normalization candidate untouched and report it when it is held for a person — the
+  human gate is consulted before classification and its refusal is absolute.
 - Normalize a GitHub issue with no configured lifecycle label by adding the configured PRD or build
   `ready` label after classifying the issue. This is a visibility repair, not a claim; the item
   remains open and unclaimed for normal intake.
@@ -1305,6 +1329,10 @@ Report outcomes in these buckets:
   from hierarchy/body-parentage) whose missing native sub-issue links were attached.
 - `normalized_ready` — GitHub issues missing official lifecycle labels that were classified and
   given the configured PRD/build `ready` label so normal intake can claim them.
+- `held_for_person` — normalization candidates left exactly as they were because a person is
+  holding them, per the human gate in step 2a of that repair. Nothing was written to them. This
+  bucket is never merged into `normalized_ready` or `errors`: "a person parked this and I honoured
+  it" is a repair outcome, not a failure and not a promotion.
 - `still_blocked` — examined and intentionally left `blocked`, with the active reason.
 - `reversal_suppressed` — a repair this skill previously made was reversed by a human, so the
   classification was **not** re-applied. Name the **reversed transition** (role, direction, and

package/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.37.2",
+  "version": "4.38.0",
   "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

@@ -38,10 +38,20 @@ function normalizeLabels(labels) {
 }
 
 /**
- * @param {{ labels?: unknown, body?: unknown, humanNeededLabel?: unknown }} input
- * @returns {boolean}
+ * Whether an item is held for a person, on either surface.
+ *
+ * Exported deliberately, and it is the ONLY answer to that question anywhere in
+ * the intake machinery. Every selection and promotion path calls this rather
+ * than inspecting labels itself, because the label surface alone is a partial
+ * answer: the vendor writers stamp the body marker on a deliberate hold, so an
+ * item held exactly as the filing contract instructs carries no label at all.
+ * A path that read labels alone judged such an item unheld and promoted it —
+ * which is #3805, and is why this is a shared function rather than a shared
+ * convention.
+ * @param {{ labels?: unknown, body?: unknown, humanNeededLabel?: unknown }} input - Candidate surfaces
+ * @returns {boolean} True when a person is holding this item
  */
-function isHumanGated(input) {
+export function isHumanGated(input) {
   const configured = String(
     input.humanNeededLabel ?? DEFAULT_HUMAN_NEEDED_LABEL
   )
@@ -282,6 +292,113 @@ export function planHumanGateReconciliation(input = {}) {
   };
 }
 
+/**
+ * Marker on the note the normalization sweep leaves, so a later cycle
+ * recognises its own work instead of commenting again.
+ *
+ * Deliberately NOT the hold marker and deliberately not a superstring of it:
+ * `HUMAN_GATE_MARKER` closes with `]`, so neither this nor
+ * `HUMAN_GATE_NOTE_MARKER` matches it. A note that read as a hold declaration
+ * would make every reported item look held to the next body-reading sweep,
+ * including items the report merely names.
+ */
+export const NORMALIZATION_HOLD_NOTE_MARKER =
+  "<!-- [lisa-human-gate-normalization-held] -->";
+
+/**
+ * Decide whether an item carrying NO configured lifecycle label may be
+ * normalized into a ready lane.
+ *
+ * This is the promotion path, and it was keyed on labels alone. The configured
+ * `human_needed` label is one of the lifecycle labels whose *absence* the sweep
+ * enumerates on, so an item held only by the body marker was a member of the
+ * swept population by definition and got the build-ready label applied to it.
+ * The `[lisa-human-gate]` exclusion existed, in a different and read-only sweep
+ * further down the same contract: the one sweep that writes was the one that
+ * could not see the marker.
+ *
+ * Order is load-bearing for the same reason it is in `classifyPreWorkCandidate`:
+ * the hold is checked before lane membership and before any classification, so
+ * nothing downstream — however confident — can promote an item a person parked.
+ *
+ * On a match this plans NO write of its own. `planHumanGateReconciliation`
+ * turns a match into durable state, so a false positive there latches and every
+ * later cycle agrees with the first. The gate test is a plain substring match
+ * whose imprecision is tracked separately, so this path refuses and reports
+ * read-only instead — the same treatment the ungated-filing sweep already gives
+ * a hold it finds.
+ * @param {{
+ *   labels?: unknown
+ *   body?: unknown
+ *   humanNeededLabel?: unknown
+ *   lifecycleLabels?: unknown
+ *   readyLabel?: unknown
+ * }} input - Candidate surfaces plus the configured lifecycle vocabulary
+ * @returns {{ normalize: boolean, reason: string, humanGated: boolean, actions: { addReadyLabel: string | null, reportHold: boolean } }} Normalization plan
+ */
+export function planLabelNormalization(input = {}) {
+  const idle = Object.freeze({ addReadyLabel: null, reportHold: false });
+  if (isHumanGated(input)) {
+    return {
+      normalize: false,
+      reason: "human-gate",
+      humanGated: true,
+      actions: Object.freeze({ addReadyLabel: null, reportHold: true }),
+    };
+  }
+
+  const labels = normalizeLabels(input.labels);
+  if (normalizeLabels(input.lifecycleLabels).some(l => labels.includes(l))) {
+    return {
+      normalize: false,
+      reason: "already-in-lifecycle",
+      humanGated: false,
+      actions: idle,
+    };
+  }
+
+  const ready = trimmedString(input.readyLabel);
+  if (ready.length === 0) {
+    return {
+      normalize: false,
+      reason: "no-ready-label",
+      humanGated: false,
+      actions: idle,
+    };
+  }
+
+  return {
+    normalize: true,
+    reason: "normalize",
+    humanGated: false,
+    actions: Object.freeze({ addReadyLabel: ready, reportHold: false }),
+  };
+}
+
+/**
+ * Render the notice for an item the normalization sweep left alone.
+ *
+ * Distinct from `formatHumanGateNote` because the two say opposite things
+ * about what happened: that one reports a lane that WAS changed, this one
+ * reports a promotion that was declined and nothing else. Reusing it would tell
+ * an operator their item had been moved when it had not.
+ * @returns {string} Comment body, carrying the marker that keeps a re-run quiet
+ */
+export function formatNormalizationHoldNote() {
+  return [
+    "**Left alone: a person is holding this**",
+    "",
+    "- What was found: the description says a person is holding this one, so " +
+      "it was not put into the queue that agents work from.",
+    "- What changed: nothing at all. It was left exactly as it is, and " +
+      "nothing will pick it up on its own.",
+    "- To resume it: remove the hold note from the description, then put it " +
+      "into the build queue.",
+    "",
+    NORMALIZATION_HOLD_NOTE_MARKER,
+  ].join("\n");
+}
+
 /**
  * Render the hold notice for a reader who does not know this subsystem.
  *

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

@@ -276,6 +276,17 @@ Held for a human product call: <reason>.
 <!-- [lisa-human-gate] reason=<short-slug> -->
 ```
 
+**Stamp both surfaces, not just the marker.** Also apply the configured `human_needed` marker
+label (`github.labels.build.human_needed`, default `human-needed`) to the issue, via `gh issue edit`/`gh issue create --label`. The marker in the body and the label say the same thing,
+and a filing that carries only one of them is a **half-armed gate**: sweeps that read the body
+honour it, and sweeps that read labels do not. That is not hypothetical — the repair sweep that
+normalizes items carrying no lifecycle label keys on the *absence* of `human_needed`, so a
+marker-only hold was its population by construction and got promoted into the build queue (#3805).
+The marker remains the authoritative declaration; the label is what makes the hold visible to a
+person scanning a board and to any path that has not yet been routed through the shared reader.
+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.
+
 If a leaf arrives with `build_ready` omitted or `false` **and** no `human_gate`, do not create it: report the incomplete handoff and name both ways to resolve it (`build_ready: true`, or a `human_gate` reason). Containers are exempt — their state rolls up from children, so they need neither.
 
 ## Phase 5.5 — Validate (Pre-write Gate)

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

@@ -261,6 +261,17 @@ Held for a human product call: <reason>.
 <!-- [lisa-human-gate] reason=<short-slug> -->
 ```
 
+**Stamp both surfaces, not just the marker.** Also apply the configured `human_needed` marker
+label (`jira.labels.human_needed`, default `Human Needed`) to the ticket, via the ticket's `labels` field. The marker in the body and the label say the same thing,
+and a filing that carries only one of them is a **half-armed gate**: sweeps that read the body
+honour it, and sweeps that read labels do not. That is not hypothetical — the repair sweep that
+normalizes items carrying no lifecycle label keys on the *absence* of `human_needed`, so a
+marker-only hold was its population by construction and got promoted into the build queue (#3805).
+The marker remains the authoritative declaration; the label is what makes the hold visible to a
+person scanning a board and to any path that has not yet been routed through the shared reader.
+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.
+
 If a leaf arrives with `build_ready` omitted or `false` **and** no `human_gate`, do not create it: report the incomplete handoff and name both ways to resolve it (`build_ready: true`, or a `human_gate` reason). Containers are exempt — their status rolls up from children, so they need neither.
 
 ## Phase 5.5 — Validate (Pre-write Gate)

package/plugins/lisa-agy/skills/lisa-linear-write-issue/SKILL.md

@@ -280,6 +280,17 @@ Held for a human product call: <reason>.
 <!-- [lisa-human-gate] reason=<short-slug> -->
 ```
 
+**Stamp both surfaces, not just the marker.** Also apply the configured `human_needed` marker
+label (`linear.labels.build.human_needed`, default `human-needed`) to the Issue, via the Issue's labels (create it via `create_issue_label` if absent). The marker in the body and the label say the same thing,
+and a filing that carries only one of them is a **half-armed gate**: sweeps that read the body
+honour it, and sweeps that read labels do not. That is not hypothetical — the repair sweep that
+normalizes items carrying no lifecycle label keys on the *absence* of `human_needed`, so a
+marker-only hold was its population by construction and got promoted into the build queue (#3805).
+The marker remains the authoritative declaration; the label is what makes the hold visible to a
+person scanning a board and to any path that has not yet been routed through the shared reader.
+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.
+
 If a leaf arrives with `build_ready` omitted or `false` **and** no `human_gate`, do not create it: report the incomplete handoff and name both ways to resolve it (`build_ready: true`, or a `human_gate` reason). Containers are exempt — their state rolls up from children, so they need neither.
 
 ## Phase 5.5 — Validate (Pre-write Gate)

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

@@ -951,6 +951,23 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    selected by `intake_mode`. If `intake_mode=prd`, only PRD-classified issues are normalized. If
    `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
+   `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
+   hold, and `human_needed` is one of the lifecycle labels this sweep keys on the **absence** of —
+   so an item held exactly as the filing contract instructs is a member of this swept population by
+   construction, and a label-only read promoted it into the build queue (#3805). The
+   `[lisa-human-gate]` exclusion already existed in the read-only "Ungated non-ready filing" sweep
+   below; the one sweep that writes was the one that could not see it.
+
+   On `normalize: false` with reason `human-gate`, **stop for that item**: apply no label, do not
+   classify it, and report it read-only per step 5. Writing a label here — even the human-needed
+   marker — would turn a match into durable state on a second path, and the gate test is a plain
+   substring match whose precision is a separate open defect (#3815). Refusing and reporting is
+   the safe failure direction without the latch. Count these under `held_for_person`, never under
+   `normalized_ready`.
 3. Classify the issue:
    - **PRD** if it has PRD labels/markers (`prd`, `type:PRD`, `kind:prd`), PRD structure
      (`## Problem`, `## Goals`, `## Validation Journey`, generated-work/backlink sections), or
@@ -964,7 +981,8 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    - **Ambiguous PRD/build** if strong PRD and build classifications both match. In `intake_mode=prd`
      normalize as PRD; in `intake_mode=build` normalize as build; in `intake_mode=both`, prefer PRD
      only when the body has PRD structure, otherwise build.
-4. Apply exactly one configured ready label for the classified lifecycle:
+4. Apply exactly one configured ready label for the classified lifecycle — and only when step
+   2a returned `normalize: true`; its `actions.addReadyLabel` is the label to apply, verbatim:
    - PRD → add the configured PRD `ready` label (default `prd-ready`).
    - Build ticket → add the configured build `ready` label (default `status:ready`).
    Keep any unofficial labels for auditability unless the project has explicitly configured one as a
@@ -972,7 +990,11 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    normalization makes the next normal `lisa-intake` run pick it up.
 5. Post one idempotent `[lisa-repair-intake]` note naming the classification and the configured label
    applied. Include the normalization result in the loop-prevention fingerprint so repeated repair
-   cycles do not spam comments.
+   cycles do not spam comments. For an item step 2a held, post `formatNormalizationHoldNote()`
+   instead — it says that nothing was changed and how a person resumes the item, which is the
+   opposite of what the reconciliation note says and must not be substituted for it. A promotion
+   declined silently is invisible, which is the quieter version of the failure this step exists to
+   prevent, so name every held item in the cycle summary via `summarizeHumanGateHolds([...])`.
 
 ### Ungated non-ready filing → surface as an incomplete handoff (read-only)
 
@@ -1223,6 +1245,8 @@ It MAY:
   Epic/Story container** from its hierarchy/body-parentage children — so rollup and the GitHub UI can
   rely on the native graph. This repairs structure only; it does not ship, transition, or verify the
   parent.
+- Leave a normalization candidate untouched and report it when it is held for a person — the
+  human gate is consulted before classification and its refusal is absolute.
 - Normalize a GitHub issue with no configured lifecycle label by adding the configured PRD or build
   `ready` label after classifying the issue. This is a visibility repair, not a claim; the item
   remains open and unclaimed for normal intake.
@@ -1305,6 +1329,10 @@ Report outcomes in these buckets:
   from hierarchy/body-parentage) whose missing native sub-issue links were attached.
 - `normalized_ready` — GitHub issues missing official lifecycle labels that were classified and
   given the configured PRD/build `ready` label so normal intake can claim them.
+- `held_for_person` — normalization candidates left exactly as they were because a person is
+  holding them, per the human gate in step 2a of that repair. Nothing was written to them. This
+  bucket is never merged into `normalized_ready` or `errors`: "a person parked this and I honoured
+  it" is a repair outcome, not a failure and not a promotion.
 - `still_blocked` — examined and intentionally left `blocked`, with the active reason.
 - `reversal_suppressed` — a repair this skill previously made was reversed by a human, so the
   classification was **not** re-applied. Name the **reversed transition** (role, direction, and