@codyswann/lisa 4.37.2 → 4.38.0

package/package.json

@@ -66,6 +66,7 @@
     "check:orphan-processes": "node scripts/check-orphan-test-processes.mjs",
     "check:merge-drivers": "node scripts/check-merge-driver-registration.mjs",
     "check:failure-signatures": "node plugins/src/base/hooks/failure-signature-index.mjs --check",
+    "check:withdrawn-rulings": "node plugins/src/base/hooks/withdrawn-rulings.mjs --check",
     "check:template-workflow-refs": "node scripts/check-template-workflow-refs.mjs",
     "check:third-party-action-pins": "node scripts/check-third-party-action-pins.mjs",
     "check:workflow-package-paths": "node scripts/check-workflow-package-paths.mjs",
@@ -83,6 +84,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 +169,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.37.2",
+  "version": "4.38.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -315,7 +317,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "00ba362a8acf66e0a567a027b1c01dbd94ff7cbf",
-  "gitHead": "00ba362a8acf66e0a567a027b1c01dbd94ff7cbf",
-  "lisaReleaseTag": "v4.37.2"
+  "lisaReleaseCommit": "99484f8dc349184afd44f96a890524223c3ea97c",
+  "gitHead": "99484f8dc349184afd44f96a890524223c3ea97c",
+  "lisaReleaseTag": "v4.38.0"
 }

package/plugins/lisa/.claude-plugin/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"
@@ -89,6 +89,15 @@
             "command": "${CLAUDE_PLUGIN_ROOT}/hooks/enforce-team-first.sh"
           }
         ]
+      },
+      {
+        "matcher": "Bash|Edit|Write|Read|Task|Grep|Glob",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/withdrawn-rulings.sh --hook"
+          }
+        ]
       }
     ],
     "PreToolUse": [
@@ -201,6 +210,15 @@
           }
         ]
       },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/withdrawn-rulings.sh --session-start"
+          }
+        ]
+      },
       {
         "matcher": "",
         "hooks": [
@@ -248,6 +266,15 @@
           }
         ]
       },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/withdrawn-rulings.sh --session-start"
+          }
+        ]
+      },
       {
         "matcher": "",
         "hooks": [

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

@@ -38,6 +38,15 @@
             "command": "${PLUGIN_ROOT}/hooks/threshold-ratchet.sh"
           }
         ]
+      },
+      {
+        "matcher": "Bash|Edit|Write|Read|Task|Grep|Glob",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${PLUGIN_ROOT}/hooks/withdrawn-rulings.sh --hook"
+          }
+        ]
       }
     ],
     "PreToolUse": [
@@ -123,6 +132,15 @@
           }
         ]
       },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${PLUGIN_ROOT}/hooks/withdrawn-rulings.sh --session-start"
+          }
+        ]
+      },
       {
         "matcher": "",
         "hooks": [
@@ -161,6 +179,15 @@
           }
         ]
       },
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${PLUGIN_ROOT}/hooks/withdrawn-rulings.sh --session-start"
+          }
+        ]
+      },
       {
         "matcher": "",
         "hooks": [

package/plugins/lisa/.codex-plugin/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/.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)
   );
 }