@codyswann/lisa 4.37.1 → 4.37.3

package/package.json

@@ -83,6 +83,7 @@
     "verify:packed-learnings-contract": "bun run build:dist && node scripts/verify-packed-learnings-contract.mjs",
     "verify:health-agentic": "bun run build:dist && node scripts/verify-health-agentic-built.mjs",
     "verify:health-consumer": "bun run build:dist && node scripts/verify-health-consumer-built.mjs",
+    "measure:tmpdir-growth": "node scripts/measure-tmpdir-growth.mjs",
     "lint:staged": "lint-staged --config .lintstagedrc.json"
   },
   "engines": {
@@ -167,7 +168,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.37.1",
+  "version": "4.37.3",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -315,7 +316,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "814b96442184bf60e32130857d5ca2f9eb5bc000",
-  "gitHead": "814b96442184bf60e32130857d5ca2f9eb5bc000",
-  "lisaReleaseTag": "v4.37.1"
+  "lisaReleaseCommit": "3f7bdc84a24fe7f5b24973ced10b7dc57bfdd329",
+  "gitHead": "3f7bdc84a24fe7f5b24973ced10b7dc57bfdd329",
+  "lisaReleaseTag": "v4.37.3"
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.37.1",
+  "version": "4.37.3",
   "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.37.1",
+  "version": "4.37.3",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/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/.codex-plugin/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/.codex-plugin/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/.codex-plugin/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/hooks/inject-resolved-config.mjs

@@ -51,7 +51,7 @@
  * @module inject-resolved-config
  */
 import { existsSync, readFileSync, realpathSync } from "node:fs";
-import { join } from "node:path";
+import { basename, join } from "node:path";
 import { fileURLToPath } from "node:url";
 
 /** Committed, project-wide configuration. */
@@ -799,13 +799,32 @@ export function buildContext(projectDir) {
       ? `${MAIN_CONFIG} + ${LOCAL_CONFIG} (local wins where they overlap)`
       : `${MAIN_CONFIG} (no local override file)`;
 
+  // The block used to say "this project's" — a possessive with no referent
+  // anywhere in its text, so two repositories emitted blocks that were
+  // character-identical except for the values. An agent standing in one
+  // directory while doing work governed by another read something perfectly
+  // true about the directory and wrong about the work, and the next sentence
+  // told it not to open the files that would have shown the difference. Six
+  // independent agent cycles reached the same false conclusion from one such
+  // block (CodySwannGT/lisa#3765).
+  //
+  // `basename` rather than the git remote: naming the subject must not cost a
+  // subprocess on a hook that runs at every session and subagent start, and it
+  // must not fail in a directory that is not a git checkout. The absolute path
+  // beside it is the unambiguous identifier; the basename is the short name a
+  // reader actually compares against the work in front of them.
+  const subject = basename(projectDir) || projectDir;
+
   return block(
-    `These are this project's EFFECTIVE Lisa configuration values, already resolved from ${sources}.\n` +
-      `Act on them directly. Do not re-read the config files to learn them, and do not act ` +
-      `against them. A line marked [Lisa built-in default] is NOT something this project ` +
-      `declared. A key whose NAME is identity- or credential-shaped is withheld and counted, ` +
-      `and a VALUE matching a known credential shape is replaced with ${REDACTED}: a ` +
-      `best-effort filter, not proof that anything it left alone is safe to repeat.\n\n` +
+    `These are the EFFECTIVE Lisa configuration values for ${subject}, resolved from ${sources} ` +
+      `at ${projectDir}.\n` +
+      `Act on them directly and do not act against them. They describe THAT directory: if your ` +
+      `work targets a different repository, read that repository's config rather than these. For ` +
+      `work in ${subject}, do not re-read the config files to learn these values. A line marked ` +
+      `[Lisa built-in default] is NOT something ${subject} declared. A key whose NAME is identity- ` +
+      `or credential-shaped is withheld and counted, and a VALUE matching a known credential shape ` +
+      `is replaced with ${REDACTED}: a best-effort filter, not proof that anything it left alone ` +
+      `is safe to repeat.\n\n` +
       renderBody(resolved)
   );
 }

package/plugins/lisa/rules/eager/config-resolution.md

@@ -1,6 +1,8 @@
 # Config Resolution (load-bearing)
 
-**The resolved configuration is already in your context.** `inject-resolved-config.sh` runs at every session and subagent start and injects the EFFECTIVE values — `.lisa.config.local.json` already merged over `.lisa.config.json` — inside a `<lisa-resolved-config>` block, marking anything that is a Lisa built-in rather than something this project declared. Read the values there and act on them; do not re-derive them from the files, and do not act against them.
+**The resolved configuration is already in your context.** `inject-resolved-config.sh` runs at every session and subagent start and injects the EFFECTIVE values — `.lisa.config.local.json` already merged over `.lisa.config.json` — inside a `<lisa-resolved-config>` block, which **names the directory it resolved for** and marks anything that is a Lisa built-in rather than something that directory declared. Read the values there and act on them, and do not act against them.
+
+They are resolved for **that working directory only**. For work in it, do not re-derive them from the files — that is the saving this block exists for. If your work targets a **different** repository, the block does not describe it: read that repository's config instead. A block with no name on it is how six agent cycles acted on one repository's settings while doing another's work.
 
 That block replaces the paragraph that used to sit here saying where configuration lives and which file wins. Restating it is what nine eager rules were already doing while agents acted against a config they never opened; if the block is ever missing, the two files are the source and the local one wins where they overlap.
 

package/plugins/lisa/rules/reference/config-resolution.md

@@ -505,7 +505,7 @@ Resolution keys:
 - Linear: `linear.labels.build.human_needed` (default `human-needed`). Applied as a Linear **label**, for the same reason as JIRA — an Issue holds exactly one workflow state but any number of labels, so an additive marker cannot be a state. The `blocked` **state** still drives the lifecycle; `human_needed` is the marker on top of it. This is the only build-lane key left in `linear.labels`.
 - `spec_defect` resolves the same way on each vendor — `jira.labels.spec_defect` (default `Spec Defect`), `github.labels.build.spec_defect` and `linear.labels.build.spec_defect` (default `blocked:spec-defect`).
 
-**When to apply it.** Apply `human_needed` only when a human must act before the item can move — the pre-flight gate failures that bounce a ticket back to its reporter are exactly this case, but **only after** the agent has run the `pre-flight-autofill` draft-then-block procedure (drafting the authorable gaps — acceptance criteria, validation journey, repository, relationship search, etc. — into the ticket as labeled assumptions). What then remains for the human is to **confirm those assumptions** or supply a genuinely human-only input (real missing credentials, an irreducible product/scoping decision). The marker means "a human must confirm or decide," not "a human must author from scratch."
+**When to apply it.** There are two application sites. The first is **at filing**: a leaf filed with a `human_gate` reason under `ready-role-filing` carries the `[lisa-human-gate]` body marker *and* this label, so the hold is legible to a path that reads bodies and to a path that reads labels alike. Such an item sits in no lifecycle role at all rather than in `blocked`, which is the one case where this marker stands beside no role — and it is deliberate: a hold recorded on only one surface is a half-armed gate, and the label-keyed sweeps promoted exactly that population into the build queue (#3805). The second site is a **block a human must clear**: apply `human_needed` only when a human must act before the item can move — the pre-flight gate failures that bounce a ticket back to its reporter are exactly this case, but **only after** the agent has run the `pre-flight-autofill` draft-then-block procedure (drafting the authorable gaps — acceptance criteria, validation journey, repository, relationship search, etc. — into the ticket as labeled assumptions). What then remains for the human is to **confirm those assumptions** or supply a genuinely human-only input (real missing credentials, an irreducible product/scoping decision). The marker means "a human must confirm or decide," not "a human must author from scratch."
 
 **Why `spec_defect` is separate from `human_needed`.** Both name a hold a person must clear, but they are different asks and the rollup must not merge them. `human_needed` waits on an input from *outside* the item — a credential, an access grant, a product decision — and the item's own text is fine. `spec_defect` waits on the item's text being *rewritten*, and no external event will ever supply that. An item carrying `spec_defect` will sit forever until somebody edits it; that is exactly the class that accumulated silently when the rollup rendered both as plain `blocked` (issue #3045: 32 identical hold comments over six weeks on one Epic). Where both markers are present, `spec_defect` wins — it is the more specific record, and the only one carrying a judgment nothing else can supply.
 

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.1",
+  "version": "4.37.3",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"