@codyswann/lisa 4.33.5 → 4.33.8

package/dist/core/workflow-deletion-ownership.d.ts

@@ -0,0 +1,69 @@
+/**
+ * The sentence a `copy-overwrite` template carries, minus its comment prefix.
+ *
+ * Matched as a substring rather than a whole line because the prefix differs by
+ * file type (`#`, `//`, ` *`) and the wording has been revised once already —
+ * the retired header said "changes will be overwritten on the next `lisa` run".
+ * Both spellings contain this phrase, so a consumer still holding a
+ * years-old Lisa workflow is still correctly attributed.
+ */
+export declare const LISA_MANAGED_MARKER = "managed by Lisa";
+/**
+ * The word a `create-only` seed header shouts, minus its comment prefix.
+ *
+ * "YOURS" is the load-bearing token of that contract and the one the header
+ * test asserts. A file carrying it came out of Lisa's template tree AND was
+ * handed to the consumer, which is exactly the pair of facts that makes it
+ * undeletable.
+ */
+export declare const LISA_SEEDED_MARKER = "YOURS";
+/** What Lisa can prove about a workflow file it has been asked to delete. */
+export type WorkflowDeletionVerdict = 
+/** Header asserts Lisa replaces this file wholesale. Lisa may retire it. */
+{
+    readonly kind: "lisa-managed";
+}
+/** Header seeded it as the consumer's. Lisa promised not to touch it. */
+ | {
+    readonly kind: "host-owned-seed";
+}
+/** No Lisa header at all. Lisa has no record of installing this. */
+ | {
+    readonly kind: "unattributable";
+};
+/**
+ * Whether a deletion target lives under `.github/workflows/`.
+ *
+ * Only this tree is gated. The manifests name 200-odd other paths whose
+ * deletion is unchanged by #3656, and narrowing the guard is deliberate: a
+ * workflow's absence is undetectable by construction, which is not true of a
+ * missing config file or skill directory.
+ * @param relativePath - Repo-relative path a deletions manifest wants removed
+ * @returns Whether the ownership gate applies to it
+ */
+export declare function isWorkflowDeletionPath(relativePath: string): boolean;
+/**
+ * Read the ownership contract a workflow file states about itself.
+ *
+ * Precedence is seed-before-managed. A `create-only` header mentions
+ * `copy-overwrite` in its own second line, so a naive managed-first check would
+ * read every seeded workflow as Lisa-managed and delete the very files #3656
+ * lost. Ordering it this way means the strongest claim a file can make is the
+ * one that keeps it.
+ * @param contents - Raw text of the workflow file on disk
+ * @returns The verdict its header supports
+ */
+export declare function classifyWorkflowForDeletion(contents: string): WorkflowDeletionVerdict;
+/**
+ * The operator-readable reason a workflow deletion was refused.
+ *
+ * Written for whoever is staring at an install log wondering why a file they
+ * expected to disappear is still there — so it names the contract, not the
+ * implementation, and says what to do about it.
+ * @param verdict - The verdict that refused the deletion
+ * @returns A sentence fragment naming why the file was kept
+ */
+export declare function describeRefusal(verdict: Exclude<WorkflowDeletionVerdict, {
+    kind: "lisa-managed";
+}>): string;
+//# sourceMappingURL=workflow-deletion-ownership.d.ts.map

package/dist/core/workflow-deletion-ownership.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"workflow-deletion-ownership.d.ts","sourceRoot":"","sources":["../../src/core/workflow-deletion-ownership.ts"],"names":[],"mappings":"AAuEA;;;;;;;;GAQG;AACH,eAAO,MAAM,mBAAmB,oBAAoB,CAAC;AAErD;;;;;;;GAOG;AACH,eAAO,MAAM,kBAAkB,UAAU,CAAC;AAc1C,6EAA6E;AAC7E,MAAM,MAAM,uBAAuB;AACjC,4EAA4E;AAC1E;IAAE,QAAQ,CAAC,IAAI,EAAE,cAAc,CAAA;CAAE;AACnC,yEAAyE;GACvE;IAAE,QAAQ,CAAC,IAAI,EAAE,iBAAiB,CAAA;CAAE;AACtC,oEAAoE;GAClE;IAAE,QAAQ,CAAC,IAAI,EAAE,gBAAgB,CAAA;CAAE,CAAC;AAYxC;;;;;;;;;GASG;AACH,wBAAgB,sBAAsB,CAAC,YAAY,EAAE,MAAM,GAAG,OAAO,CAEpE;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,2BAA2B,CACzC,QAAQ,EAAE,MAAM,GACf,uBAAuB,CAQzB;AAED;;;;;;;;GAQG;AACH,wBAAgB,eAAe,CAC7B,OAAO,EAAE,OAAO,CAAC,uBAAuB,EAAE;IAAE,IAAI,EAAE,cAAc,CAAA;CAAE,CAAC,GAClE,MAAM,CAIR"}

package/dist/core/workflow-deletion-ownership.js

@@ -0,0 +1,156 @@
+/**
+ * Whether Lisa may delete a workflow file it finds in a consumer repository.
+ *
+ * A deletions manifest names DESTINATION PATHS. It cannot name bytes, and until
+ * CodySwannGT/lisa#3656 nothing between the manifest and `fse.remove` looked at
+ * any. So a manifest entry retiring one of Lisa's own workflows also removed a
+ * completely unrelated file a consumer happened to author at the same path —
+ * three of them at once, on a routine version bump, with nothing in the install
+ * output anyone could read afterwards.
+ *
+ * The damage shape is what makes path-only deletion unacceptable here rather
+ * than merely untidy. **A workflow that no longer exists cannot fail.** Removing
+ * one does not redden a check; it removes the check. Two capabilities stopped in
+ * that repo — PR branches were no longer auto-updated and required-checks drift
+ * was no longer policed — and both losses presented as a quiet, healthy repo.
+ * The only reason anyone found out was an unrelated test that happened to read
+ * one of the files off disk and got `ENOENT`.
+ *
+ * ## Ownership is read from the file's own header, and the header already exists
+ *
+ * Every template Lisa ships carries an ownership header, and which header it
+ * carries is enforced repo-wide by `tests/unit/templates/template-ownership-header.test.ts`.
+ * The two headers are not decoration — they are opposite contracts, and this
+ * module simply honours the one the file on disk is carrying:
+ *
+ * - **`copy-overwrite`**: "This file is managed by Lisa and IS replaced on each
+ *   `lisa` run." Lisa asserts ownership of the bytes and has always replaced
+ *   them wholesale. Retiring such a file is Lisa deleting its own artifact,
+ *   which is squarely inside the mandate.
+ * - **`create-only`**: "Seeded by Lisa on first setup — this file is YOURS.
+ *   Lisa will not overwrite it." Lisa explicitly DISCLAIMED ownership at seed
+ *   time. Whatever is in that file now may be entirely the consumer's work, and
+ *   deleting it is the one operation the header promised would never happen.
+ *   Overwriting it was already refused; removing it must be too.
+ *
+ * All three files lost in #3656 were `create-only` seeds. So was every workflow
+ * template Lisa currently ships.
+ *
+ * ## Why a header and not the hash ledger
+ *
+ * `core/lisa-owned-provenance` answers a neighbouring question — are these bytes
+ * some past Lisa release? — from a generated hash ledger, and it would be the
+ * stronger signal if it applied. It does not: the generator
+ * (`scripts/generate-lisa-owned-hash-ledger.mjs`) enrols only `copy-overwrite`
+ * sources under `scripts/`, so `LISA_OWNED_HASH_LEDGER` holds no
+ * `.github/workflows/` key at all and every workflow would classify as
+ * `unenrolled` — the verdict whose documented meaning is "behave exactly as
+ * before", which is the bug. Enrolling workflows would mean walking the history
+ * of retired template paths, and it still could not vouch for a `create-only`
+ * seed a consumer has since edited. The header answers the question that is
+ * actually being asked, for every workflow Lisa has ever shipped, with no
+ * generated artifact to keep in step.
+ *
+ * ## The residual risk, stated
+ *
+ * A consumer who deletes the `copy-overwrite` header out of a Lisa-managed
+ * workflow makes it unattributable, and Lisa will then decline to retire it.
+ * That is the safe direction: a stale reusable workflow nobody calls costs
+ * nothing, and `lisa doctor` is not made worse by its presence. The unsafe
+ * direction — deleting a file Lisa cannot account for — is the one this module
+ * closes.
+ * @module core/workflow-deletion-ownership
+ */
+import * as path from "node:path";
+/**
+ * Repo-relative directory GitHub Actions reads workflow definitions from.
+ * Deletion of anything inside it is what this module governs.
+ */
+const WORKFLOWS_DIR = ".github/workflows";
+/**
+ * The sentence a `copy-overwrite` template carries, minus its comment prefix.
+ *
+ * Matched as a substring rather than a whole line because the prefix differs by
+ * file type (`#`, `//`, ` *`) and the wording has been revised once already —
+ * the retired header said "changes will be overwritten on the next `lisa` run".
+ * Both spellings contain this phrase, so a consumer still holding a
+ * years-old Lisa workflow is still correctly attributed.
+ */
+export const LISA_MANAGED_MARKER = "managed by Lisa";
+/**
+ * The word a `create-only` seed header shouts, minus its comment prefix.
+ *
+ * "YOURS" is the load-bearing token of that contract and the one the header
+ * test asserts. A file carrying it came out of Lisa's template tree AND was
+ * handed to the consumer, which is exactly the pair of facts that makes it
+ * undeletable.
+ */
+export const LISA_SEEDED_MARKER = "YOURS";
+/**
+ * How many leading lines of a file count as its ownership header.
+ *
+ * Bounded on purpose. A whole-file search would let any mention of Lisa
+ * anywhere in a consumer's workflow — a step name, a comment about a Lisa
+ * command — authorise that file's deletion, which is the false-negative
+ * direction that reintroduces #3656. Every shipped template puts its header on
+ * the first two lines; four covers a leading `---` document marker or a blank
+ * line above it and still stops short of any workflow body.
+ */
+const HEADER_LINES = 4;
+/**
+ * Normalize a path for comparison: POSIX separators, no leading `./`.
+ * @param value - Raw path from a deletions manifest
+ * @returns Comparable POSIX-style repo-relative path
+ */
+function normalizeRepoPath(value) {
+    const posix = value.split(path.sep).join("/");
+    return posix.startsWith("./") ? posix.slice(2) : posix;
+}
+/**
+ * Whether a deletion target lives under `.github/workflows/`.
+ *
+ * Only this tree is gated. The manifests name 200-odd other paths whose
+ * deletion is unchanged by #3656, and narrowing the guard is deliberate: a
+ * workflow's absence is undetectable by construction, which is not true of a
+ * missing config file or skill directory.
+ * @param relativePath - Repo-relative path a deletions manifest wants removed
+ * @returns Whether the ownership gate applies to it
+ */
+export function isWorkflowDeletionPath(relativePath) {
+    return normalizeRepoPath(relativePath).startsWith(`${WORKFLOWS_DIR}/`);
+}
+/**
+ * Read the ownership contract a workflow file states about itself.
+ *
+ * Precedence is seed-before-managed. A `create-only` header mentions
+ * `copy-overwrite` in its own second line, so a naive managed-first check would
+ * read every seeded workflow as Lisa-managed and delete the very files #3656
+ * lost. Ordering it this way means the strongest claim a file can make is the
+ * one that keeps it.
+ * @param contents - Raw text of the workflow file on disk
+ * @returns The verdict its header supports
+ */
+export function classifyWorkflowForDeletion(contents) {
+    const header = contents.split("\n").slice(0, HEADER_LINES).join("\n");
+    if (header.includes(LISA_SEEDED_MARKER)) {
+        return { kind: "host-owned-seed" };
+    }
+    return header.includes(LISA_MANAGED_MARKER)
+        ? { kind: "lisa-managed" }
+        : { kind: "unattributable" };
+}
+/**
+ * The operator-readable reason a workflow deletion was refused.
+ *
+ * Written for whoever is staring at an install log wondering why a file they
+ * expected to disappear is still there — so it names the contract, not the
+ * implementation, and says what to do about it.
+ * @param verdict - The verdict that refused the deletion
+ * @returns A sentence fragment naming why the file was kept
+ */
+export function describeRefusal(verdict) {
+    return verdict.kind === "host-owned-seed"
+        ? "Lisa seeded this workflow as yours and will not remove it"
+        : "Lisa cannot prove it installed this workflow";
+}
+//# sourceMappingURL=workflow-deletion-ownership.js.map

package/dist/core/workflow-deletion-ownership.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"workflow-deletion-ownership.js","sourceRoot":"","sources":["../../src/core/workflow-deletion-ownership.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8DG;AACH,OAAO,KAAK,IAAI,MAAM,WAAW,CAAC;AAElC;;;GAGG;AACH,MAAM,aAAa,GAAG,mBAAmB,CAAC;AAE1C;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAG,iBAAiB,CAAC;AAErD;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,kBAAkB,GAAG,OAAO,CAAC;AAE1C;;;;;;;;;GASG;AACH,MAAM,YAAY,GAAG,CAAC,CAAC;AAWvB;;;;GAIG;AACH,SAAS,iBAAiB,CAAC,KAAa;IACtC,MAAM,KAAK,GAAG,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IAC9C,OAAO,KAAK,CAAC,UAAU,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC;AACzD,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,UAAU,sBAAsB,CAAC,YAAoB;IACzD,OAAO,iBAAiB,CAAC,YAAY,CAAC,CAAC,UAAU,CAAC,GAAG,aAAa,GAAG,CAAC,CAAC;AACzE,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,2BAA2B,CACzC,QAAgB;IAEhB,MAAM,MAAM,GAAG,QAAQ,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,KAAK,CAAC,CAAC,EAAE,YAAY,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IACtE,IAAI,MAAM,CAAC,QAAQ,CAAC,kBAAkB,CAAC,EAAE,CAAC;QACxC,OAAO,EAAE,IAAI,EAAE,iBAAiB,EAAE,CAAC;IACrC,CAAC;IACD,OAAO,MAAM,CAAC,QAAQ,CAAC,mBAAmB,CAAC;QACzC,CAAC,CAAC,EAAE,IAAI,EAAE,cAAc,EAAE;QAC1B,CAAC,CAAC,EAAE,IAAI,EAAE,gBAAgB,EAAE,CAAC;AACjC,CAAC;AAED;;;;;;;;GAQG;AACH,MAAM,UAAU,eAAe,CAC7B,OAAmE;IAEnE,OAAO,OAAO,CAAC,IAAI,KAAK,iBAAiB;QACvC,CAAC,CAAC,2DAA2D;QAC7D,CAAC,CAAC,8CAA8C,CAAC;AACrD,CAAC"}

package/package.json

@@ -165,7 +165,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.33.5",
+  "version": "4.33.8",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -313,7 +313,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "093c20ef2f67eadda94e473ffe5ff52cd14e1107",
-  "gitHead": "093c20ef2f67eadda94e473ffe5ff52cd14e1107",
-  "lisaReleaseTag": "v4.33.5"
+  "lisaReleaseCommit": "463ea1625bf43084967f87bee3daa9ab4225be85",
+  "gitHead": "463ea1625bf43084967f87bee3daa9ab4225be85",
+  "lisaReleaseTag": "v4.33.8"
 }

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

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

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

@@ -190,7 +190,7 @@ Apply gate verdicts in the same order as build intake:
 
 1. **Repo-scope gate.** A build item carrying `repo:<other>` and not `repo:<current>` is outside this repo's pickup lane. Return `MISCONFIGURED` when repo scope is absent or contradictory enough that the current repo cannot be determined confidently; otherwise explain the repo-scope mismatch and recommend running intake in the target repo or fixing the `repo:<name>` label. For an unlabeled item whose target repo is obvious from the item body, report the inferred repo signal but stay read-only: execution intake would stamp `repo:<name>`, while intake-explain only says it would do so. A multi-repo leaf is not directly buildable; explain that execution intake would split it per `repo-scope-split`, but this read-only diagnosis does not split.
 2. **Leaf-only gate.** If the item has open child work from native GitHub sub-issues or body parentage, return `NON_LEAF_CONTAINER` and explain that direct build pickup is leaf-only per `leaf-only-lifecycle`. If it has no open children but carries `type:Epic`, also return `NON_LEAF_CONTAINER` because a childless Epic is a pure rollup container that still needs decomposition or reclassification. (A childless `type:Story` or `type:Spike` is a valid leaf per `leaf-only-lifecycle` and is NOT a `NON_LEAF_CONTAINER` — it is directly buildable.) The next action for a childless Epic is decomposition, moving `status:ready` to leaf children, or correcting the issue type. Execution build intake would move such a stale ready container out of the pickup queue; this read-only diagnosis must not perform that repair.
-3. **Dependency hold gate.** If a single-repo leaf for the current repo has explicit blockers, read each blocker. Closed blockers are clear. Open blockers are clear only when they carry a cleared build status such as `status:code-review`, `status:on-dev`, `status:on-stg`, `status:done`, or the configured done-equivalent labels. Open blockers with `status:ready`, `status:in-progress`, no cleared status label, or inaccessible state are active. Return `HELD_BY_BLOCKERS`, list the active blocker refs, and make the next action blocker resolution rather than `/lisa:intake`.
+3. **Dependency hold gate.** If a single-repo leaf for the current repo has explicit blockers, read each blocker and clear-check it **by containment, per the `blocker-containment` rule** — cite that slug for the full contract rather than restating it. A blocker is clear only when its merged PRs are ancestors of the branch this leaf will be built from (resolved from the leaf's `## Target Backend Environment` through `.lisa.config.json` `deploy.branches`, never from a rendered `Branch Plan`), or when the rule's narrow no-code carve-out or human override applies. **A build status label is never the test** — `status:code-review`, `status:on-dev`, `status:on-stg` and `status:done` are name matches that hold in a single-trunk workflow and come apart in a promotion workflow, where `main` is the trailing branch. Every other state, and every case where containment is not computable, is active: fail closed. Return `HELD_BY_BLOCKERS`, list the active blocker refs with the rule's reason key for each, and make the next action blocker resolution rather than `/lisa:intake`.
 4. **Ready leaf.** A build item in the configured ready role, scoped to the current repo, with no open child work and no active blockers returns `ELIGIBLE_FOR_INTAKE`. The `Why:` line should say it is a single-repo leaf for the current repo and that leaf-only, repo-scope, and dependency gates all pass.
 
 Relevant `Signals:` should include the decisive context, not every field: for example `repo:lisa; type:Sub-task; no open children`, `open children #12/#13`, `repo:api but current repo is web`, or `active blockers CodySwannGT/lisa#123`.

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

@@ -1005,28 +1005,40 @@ is no normalized `is blocked by` field. Read the bundle, then extract blockers p
 - **Linear**: inspect the native issue **relations** from Linear MCP `get_issue` and select
   blocker relations.
 
-Then classify each blocker:
-
-- **Closed, or shipped to any environment** → **cleared**. A blocker is cleared at **any**
-  env-staged `done` role — not only the production terminal. The `done` role is configured
-  per-env as a `{dev, staging, production}` map (`config-resolution`), so `On Dev`, `On Stg`,
-  **and** production `Done` all mean the blocker's code is merged and deployed to ≥1 environment.
-  A post-build `review` role (e.g. `Code Review`) is likewise cleared — the change exists and is
-  in flight. An `is blocked by` link is a **development** dependency: it is satisfied once the
-  blocker's code is in trunk; it must NOT wait for the blocker to reach production. (This matches
-  the intake-path dependency-hold gate in `lisa-intake-explain`, which already treats
-  `code-review` / `on-dev` / `on-stg` / `done` as cleared — repair-intake must not be stricter.
-  In an env-staged workflow where `Done` means "in production", a strict production-terminal
-  check strands every dependent forever behind a blocker that is already merged and sitting at
-  `On Stg` / `On Dev`.)
-- **Open** in a pre-merge role (`ready` / `claimed` / unknown — code not yet in trunk) → **still
-  blocking**.
-- **Inaccessible** (deleted, cross-org, permission denied) → **still blocking**, unless the item
-  body or a newer human comment explicitly states the dependency is resolved.
+Then classify each blocker **by containment, per the `blocker-containment` rule** — cite that
+slug for the full contract; do not restate its resolution steps or its fail-closed table here.
+
+The one question is whether the blocker's code is on the branch **this item** will be built from:
+resolve this item's base branch from its `## Target Backend Environment` through
+`.lisa.config.json` `deploy.branches` (`derived-branch-plan`, `config-resolution` — never by
+reading a rendered `Branch Plan`), resolve the blocker's merge commit through the vendor access
+layer, and test ancestry against the remote.
+
+- **Contained** — every merged PR on the blocker is an ancestor of this item's base branch →
+  **cleared**.
+- **Not contained**, or containment **not computable** for any reason the rule enumerates (no
+  linked PR, PR not merged, blocker inaccessible, base branch underivable or absent from the
+  remote, ancestry query errored) → **still blocking**, with the rule's reason key in the run
+  record.
+- **Ships no code** — the blocker is closed as completed, positively declares
+  `Target Backend Environment: None — no runtime behavior change`, and has no merged PR →
+  **cleared** under the rule's carve-out. This is a positive determination, never an absence:
+  "no PR found" is `no-pr` and stays blocking.
+- **Human override** — an explicit human statement on this item that the dependency is satisfied
+  clears it and outranks a failed containment check. Name it in the run record.
+
+**A lifecycle status name is never the test.** `done`, `on-stg`, `on-dev` and `code-review` are
+labels that correlate with containment in a single-trunk workflow and come apart from it in a
+promotion workflow, where `main` is the trailing branch — a blocker at `On Stg` is on `staging`
+and absent from `main`, and a blocker in `Code Review` is merged to nothing. Containment gets
+both the loose and the strict failure right at once: a blocker merged into the branch this item
+builds from clears **immediately**, with no wait for production, so a dependent is never stranded
+behind work already merged where it needs it.
 
 Only re-dispatch when **every** parsed blocker is cleared. When in doubt, stay blocked — a
-false-negative (left blocked) is cheap; a false-positive (re-dispatched into a real blocker)
-wastes a build cycle.
+false-negative (left blocked) costs one cycle and is visible; a false-positive is **invisible**,
+because the item moves to `ready`, which looks exactly like a repair that worked, and the failure
+surfaces days later as work begun before its dependency existed.
 
 ### Class B — validation / quality-gate self-block
 

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

@@ -46,7 +46,7 @@ If relevant code IS found, proceed to Phase 2.
 
 From the context bundle, evaluate relationships before analyzing this ticket in isolation:
 
-- **Open blockers (`is blocked by`)**: if any blocker is not `Done` or its linked PR is not merged, raise an ambiguity: "Blocker {KEY} is not shipped — work cannot meaningfully start." This is an automatic `BLOCKED` verdict unless the human confirms the blocker state is acceptable.
+- **Open blockers (`is blocked by`)**: clear-check each blocker **by containment, per the `blocker-containment` rule** — cite that slug for the full contract rather than restating it. A blocker is satisfied when its merged PRs are ancestors of the branch this ticket will be built from (resolved from this ticket's `## Target Backend Environment` through `.lisa.config.json` `deploy.branches`, never from a rendered `Branch Plan`), or when the rule's narrow no-code carve-out or human override applies. **`Done` is not the test** — a state name holds in a single-trunk workflow and comes apart in a promotion workflow, and requiring the production terminal strands every dependent behind work already merged where this ticket needs it. This is the same predicate the `DUPLICATE_ALREADY_FIXED` bullet below already requires ("present on the relevant base branch… never from a name/label match alone"), applied here too. For a blocker that is not contained, or where containment is not computable, raise an ambiguity naming the rule's reason key: "Blocker {KEY} is not on {BRANCH} ({REASON}) — work cannot meaningfully start." That is an automatic `BLOCKED` verdict unless the human confirms the blocker state is acceptable.
 - **Epic siblings in progress**: if a sibling under the same epic is `In Progress` / `In Review` with a different assignee and overlapping scope, raise it as an edge case in Phase 4 ("Duplicate-work risk with {KEY}").
 - **`duplicates` / `is duplicated by` links**:
   - If this ticket is a duplicate of an open canonical ticket whose fix is not yet merged into the base branch, verdict is `BLOCKED` with the recommendation to close as duplicate manually rather than implement.

package/plugins/lisa/rules/eager/blocker-containment.md

@@ -0,0 +1,44 @@
+# Blocker Containment (load-bearing)
+
+**An `is blocked by` dependency is cleared by one fact only: the blocker's code is present on the branch the dependent will be built from.** A lifecycle status name — `done`, `on-stg`, `on-dev`, `code-review`, or any configured equivalent — is never that fact. It is a label that correlates with the fact in a single-trunk workflow and comes apart from it in a promotion workflow.
+
+**One vendor-neutral contract, cited by** `lisa-repair-intake` (Class A dependency clearing), `lisa-intake-explain` (dependency hold gate), and `lisa-ticket-triage` (Phase 1.5 open-blocker gate) — the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never divergent per-consumer prose.
+
+## Why a status name is the wrong test
+
+Where promotion runs `dev → staging → main`, `main` is the **trailing** branch. A blocker at `On Stg` is merged to `staging` and absent from `main`, so a dependent that builds from `main` does not have it. A blocker in `Code Review` is merged to nothing at all. The two failures are symmetric and both are live in the tree:
+
+- Test too **loosely** (any env-staged `done` clears) and a dependent is dispatched into work whose prerequisite is not on its branch. Nothing goes red; the item moves to `ready`, which is indistinguishable from a repair that worked.
+- Test too **strictly** (only the production terminal clears) and every dependent strands behind a blocker that is already merged where it matters.
+
+Containment is the one predicate that gets both right, because it asks the question the status name was standing in for.
+
+## The predicate
+
+1. **Resolve the dependent's base branch.** Take the dependent's `## Target Backend Environment` and map that exact key forward through `.lisa.config.json` `deploy.branches`, per `derived-branch-plan` and `config-resolution`. **Never read the rendered `Branch Plan` section as input** — `derived-branch-plan` forbids it; a surface needing the base branch derives it again.
+2. **Resolve the blocker's merge commit** — the commit that landed the blocker's PR.
+3. **Test ancestry on the remote:** is that commit an ancestor of the resolved base branch (`git merge-base --is-ancestor <sha> origin/<base>`)?
+4. **Cleared** iff the answer is yes. Otherwise **still blocking**.
+
+## Fail closed
+
+**Never fail open on an unresolvable ancestry check.** Any step that cannot be positively resolved leaves the dependency **blocking**, and the run record says which step failed:
+
+- no linked PR, or a PR that is not merged;
+- the blocker is inaccessible (deleted, cross-org, permission denied) — containment across repositories is not defined;
+- the dependent's environment is not derivable, maps non-uniquely, or maps to a branch absent from the remote;
+- the ancestry query itself fails.
+
+A false negative (left blocked) costs a cycle and is visible. A false positive (dispatched into a missing prerequisite) is invisible and surfaces days later as work begun before its dependency existed. Prefer the visible failure.
+
+## The one carve-out: a blocker with no code
+
+A dependency need not deliver code. A blocker **closed as completed** that positively declares no code deliverable — `Target Backend Environment: None — no runtime behavior change` (doc-only / config-only / type-only), no linked PR, no merge commit — is **cleared**, because there is no artifact whose location could matter.
+
+This requires a **positive determination**, never an absence. "I could not find a PR" is fail-closed under the rule above; "the item declares it ships no code" is this carve-out. Collapsing the two turns the carve-out into a universal bypass.
+
+## Human override
+
+A human statement on the item that the dependency is satisfied clears it, and outranks a failed containment check. Record it as the reason in the run record. This is the escape hatch for cross-repo and untracked dependencies, and it is the only one. An automation may never synthesize one on its own behalf.
+
+Full contract (resolution steps, per-vendor merge-commit bindings, the fail-closed reason-key table, the no-code carve-out's three conditions, and what this rule deliberately does not do): [reference/blocker-containment.md](../reference/blocker-containment.md).

package/plugins/lisa/rules/reference/blocker-containment.md

@@ -0,0 +1,92 @@
+# Blocker Containment
+
+An `is blocked by` link is a **development** dependency. It asks one question: *does the dependent have the blocker's code on the branch it will be built from?* This rule makes that the test, replacing the lifecycle-status-name checks that three Lisa surfaces had each grown independently.
+
+It is a **single vendor-neutral contract** consumed by `lisa-repair-intake` (Class A dependency clearing), `lisa-intake-explain` (dependency hold gate), and `lisa-ticket-triage` (Phase 1.5 open-blocker gate). Each cites this slug rather than re-implementing the test, exactly as they cite `leaf-only-lifecycle` and `repo-scope-split`. That is what keeps the three from drifting apart again.
+
+## The failure this replaces
+
+Before this rule, all three surfaces tested a **status name** and each picked a different threshold, so the same dependency could be simultaneously cleared by one surface and held by another.
+
+`lisa-repair-intake` tested too loosely — any env-staged `done` role cleared the dependency, on the stated reasoning that `On Dev`, `On Stg` and production `Done` all mean *"the blocker's code is merged and deployed to ≥1 environment"*, and that an `is blocked by` link *"is satisfied once the blocker's code is in trunk."* The first clause names the right idea. The second substitutes a weaker one for it: in a `dev → staging → main` promotion workflow, "deployed to ≥1 environment" and "in trunk" are different facts. `main` is the trailing branch, so a blocker at `On Stg` is on `staging` and absent from `main`. A dependent building from `main` was dispatched without it. That surface also cleared on a post-build `review` role, where the code is merged to no branch at all.
+
+`lisa-ticket-triage` tested too strictly — a blocker not at the production terminal raised an automatic `BLOCKED` verdict, stranding dependents behind work already merged where they needed it.
+
+Both are the same defect. **A lifecycle status name is never the test** — not `status:done`, not `status:on-stg`, not `status:on-dev`, and least of all `status:code-review`, where the code is merged to no branch at all. The status name is a **proxy** for branch containment that holds in a single-trunk workflow and breaks in a promotion workflow, and the two surfaces broke in opposite directions because they picked opposite ends of the same bad proxy. Correcting either one alone by moving its threshold re-opens the other's bug — which is why this is one predicate rather than three tuned lists.
+
+Notably, the correct predicate was already in the tree. `lisa-ticket-triage`'s own `DUPLICATE_ALREADY_FIXED` bullet, four lines below its defective gate, already required *"empirical evidence that the canonical fix is present on the relevant base branch. Never emit this verdict from a name/label match alone."* This rule generalizes that sentence to the gate above it.
+
+## The predicate
+
+### 1. Resolve the dependent's base branch
+
+Take the **dependent's** `## Target Backend Environment`, resolve it under the existing grammar (`config-resolution`, `pre-flight-autofill` — human-confirmed wins, then validated `Inferred:`, then `Assumption:`), and map that exact key forward through `.lisa.config.json` `deploy.branches`.
+
+**Never read the rendered `Branch Plan` section as input.** `derived-branch-plan` is explicit that the rendered branches exist for humans and are recomputed for machines: *"The rendered branches are never read as input by any flow, at any phase — a surface that needs the base branch derives it again from the environment."* Reading the rendered section would make a hand-edited ticket able to redirect the containment test.
+
+The key must map uniquely, and the mapped branch must exist on the remote. Neither condition is assumed.
+
+### 2. Resolve the blocker's merge commit
+
+The commit that landed the blocker's PR, obtained through the vendor access layer (`integration-access-layer`), never a direct vendor API call:
+
+- **GitHub** — the merge commit of the PR linked from the blocker issue.
+- **JIRA** — the merge commit of the PR on the blocker's development panel / linked PR records.
+- **Linear** — the merge commit of the PR attached to the blocker Issue.
+
+An unmerged PR has no merge commit and is not a candidate. A blocker with several merged PRs requires **all** of them contained.
+
+### 3. Test ancestry against the remote
+
+```bash
+git fetch origin <base> --quiet
+git merge-base --is-ancestor <blocker-merge-sha> origin/<base>
+```
+
+Exit `0` → contained. Exit `1` → not contained. Any other exit → not computable, which is **not** the same as not contained; both block, but the run record distinguishes them so an operator can tell a genuine dependency from a broken lookup.
+
+### 4. Verdict
+
+**Cleared** iff every resolved merge commit is an ancestor of the resolved base branch. Otherwise **still blocking**.
+
+## Fail closed
+
+**Never fail open on an unresolvable ancestry check.** Each of these leaves the dependency blocking, and each is named distinctly in the run record:
+
+| Condition | Verdict | Run-record reason |
+|---|---|---|
+| Blocker has no linked PR | still blocking | `no-pr` |
+| Linked PR is open or closed unmerged | still blocking | `pr-not-merged` |
+| Blocker inaccessible (deleted, cross-org, permission denied) | still blocking | `blocker-inaccessible` |
+| Dependent's environment not derivable or non-unique | still blocking | `base-branch-underivable` |
+| Mapped branch absent from the remote | still blocking | `base-branch-missing` |
+| Ancestry query errored | still blocking | `containment-not-computable` |
+| Merge commit resolved, not an ancestor | still blocking | `not-contained` |
+
+The asymmetry is deliberate and is the same one the consuming surfaces already state: a false negative (left blocked) costs one cycle and an operator can see it sitting there. A false positive (re-dispatched into a prerequisite that is not on the branch) is **invisible** — the item moves to `ready`, which looks exactly like a repair that worked, and the failure surfaces days later as work that began before its dependency existed. Prefer the visible failure. When in doubt, stay blocked.
+
+## The one carve-out: a blocker that ships no code
+
+Not every dependency delivers code. A decision, a doc change, or a config-only item can legitimately block work and will never have a merge commit on any branch. Requiring containment of a non-existent artifact would strand those dependents permanently — the same bug, in a new place.
+
+A blocker is cleared under this carve-out when **all** of the following hold:
+
+1. it is **closed as completed** (not `not planned` — see `rejection-detection`, where *not planned* is a durable decline);
+2. it **positively declares no code deliverable** — `## Target Backend Environment` reading `None — no runtime behavior change: doc-only` (or `config-only` / `type-only`), per the grammar `derived-branch-plan` already defines;
+3. it has **no linked merged PR**. If it has one, the normal containment test applies regardless of what the section declares — the code is the authority over the prose.
+
+This is a **positive determination, never an absence.** "I could not find a PR" is `no-pr` in the fail-closed table above. "The item declares that it ships no code" is this carve-out. Collapsing the two converts a narrow carve-out into a universal bypass, and it is the single most likely way for this rule to be implemented wrongly.
+
+An Epic or container blocker declaring `None — container: state rolls up from children` is **not** covered: resolve containment against its children, or treat it as `blocker-inaccessible` if the children cannot be enumerated.
+
+## Human override
+
+An explicit human statement on the dependent — in the body or in a comment — that the dependency is satisfied clears it, and outranks a failed containment check. The run record names the override and the comment it came from.
+
+This is the sanctioned escape hatch for the cases the predicate genuinely cannot reach: a cross-repository blocker (two repositories have no shared ancestry, so containment is undefined), a dependency on work tracked outside any connected system, or a vendor whose PR linkage is unreadable. It is the **only** escape hatch. An automation may never synthesize one on its own behalf.
+
+## What this rule does not do
+
+It does not decide **when** a dependency edge should exist, dissolve an edge once satisfied, or govern what a surface does after clearing — re-dispatch, re-validation, and lifecycle transitions remain the consuming skill's business. It governs exactly one question: given an edge, is it satisfied.
+
+It also carries no memory of its own prior verdicts. A surface that re-runs this predicate after a human reversed a transition it produced will reach the same answer from the same facts; making that reversal durable is a separate concern belonging to the consuming skill's loop-prevention contract, not to this predicate.

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

@@ -190,7 +190,7 @@ Apply gate verdicts in the same order as build intake:
 
 1. **Repo-scope gate.** A build item carrying `repo:<other>` and not `repo:<current>` is outside this repo's pickup lane. Return `MISCONFIGURED` when repo scope is absent or contradictory enough that the current repo cannot be determined confidently; otherwise explain the repo-scope mismatch and recommend running intake in the target repo or fixing the `repo:<name>` label. For an unlabeled item whose target repo is obvious from the item body, report the inferred repo signal but stay read-only: execution intake would stamp `repo:<name>`, while intake-explain only says it would do so. A multi-repo leaf is not directly buildable; explain that execution intake would split it per `repo-scope-split`, but this read-only diagnosis does not split.
 2. **Leaf-only gate.** If the item has open child work from native GitHub sub-issues or body parentage, return `NON_LEAF_CONTAINER` and explain that direct build pickup is leaf-only per `leaf-only-lifecycle`. If it has no open children but carries `type:Epic`, also return `NON_LEAF_CONTAINER` because a childless Epic is a pure rollup container that still needs decomposition or reclassification. (A childless `type:Story` or `type:Spike` is a valid leaf per `leaf-only-lifecycle` and is NOT a `NON_LEAF_CONTAINER` — it is directly buildable.) The next action for a childless Epic is decomposition, moving `status:ready` to leaf children, or correcting the issue type. Execution build intake would move such a stale ready container out of the pickup queue; this read-only diagnosis must not perform that repair.
-3. **Dependency hold gate.** If a single-repo leaf for the current repo has explicit blockers, read each blocker. Closed blockers are clear. Open blockers are clear only when they carry a cleared build status such as `status:code-review`, `status:on-dev`, `status:on-stg`, `status:done`, or the configured done-equivalent labels. Open blockers with `status:ready`, `status:in-progress`, no cleared status label, or inaccessible state are active. Return `HELD_BY_BLOCKERS`, list the active blocker refs, and make the next action blocker resolution rather than `/lisa:intake`.
+3. **Dependency hold gate.** If a single-repo leaf for the current repo has explicit blockers, read each blocker and clear-check it **by containment, per the `blocker-containment` rule** — cite that slug for the full contract rather than restating it. A blocker is clear only when its merged PRs are ancestors of the branch this leaf will be built from (resolved from the leaf's `## Target Backend Environment` through `.lisa.config.json` `deploy.branches`, never from a rendered `Branch Plan`), or when the rule's narrow no-code carve-out or human override applies. **A build status label is never the test** — `status:code-review`, `status:on-dev`, `status:on-stg` and `status:done` are name matches that hold in a single-trunk workflow and come apart in a promotion workflow, where `main` is the trailing branch. Every other state, and every case where containment is not computable, is active: fail closed. Return `HELD_BY_BLOCKERS`, list the active blocker refs with the rule's reason key for each, and make the next action blocker resolution rather than `/lisa:intake`.
 4. **Ready leaf.** A build item in the configured ready role, scoped to the current repo, with no open child work and no active blockers returns `ELIGIBLE_FOR_INTAKE`. The `Why:` line should say it is a single-repo leaf for the current repo and that leaf-only, repo-scope, and dependency gates all pass.
 
 Relevant `Signals:` should include the decisive context, not every field: for example `repo:lisa; type:Sub-task; no open children`, `open children #12/#13`, `repo:api but current repo is web`, or `active blockers CodySwannGT/lisa#123`.

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

@@ -1005,28 +1005,40 @@ is no normalized `is blocked by` field. Read the bundle, then extract blockers p
 - **Linear**: inspect the native issue **relations** from Linear MCP `get_issue` and select
   blocker relations.
 
-Then classify each blocker:
-
-- **Closed, or shipped to any environment** → **cleared**. A blocker is cleared at **any**
-  env-staged `done` role — not only the production terminal. The `done` role is configured
-  per-env as a `{dev, staging, production}` map (`config-resolution`), so `On Dev`, `On Stg`,
-  **and** production `Done` all mean the blocker's code is merged and deployed to ≥1 environment.
-  A post-build `review` role (e.g. `Code Review`) is likewise cleared — the change exists and is
-  in flight. An `is blocked by` link is a **development** dependency: it is satisfied once the
-  blocker's code is in trunk; it must NOT wait for the blocker to reach production. (This matches
-  the intake-path dependency-hold gate in `lisa-intake-explain`, which already treats
-  `code-review` / `on-dev` / `on-stg` / `done` as cleared — repair-intake must not be stricter.
-  In an env-staged workflow where `Done` means "in production", a strict production-terminal
-  check strands every dependent forever behind a blocker that is already merged and sitting at
-  `On Stg` / `On Dev`.)
-- **Open** in a pre-merge role (`ready` / `claimed` / unknown — code not yet in trunk) → **still
-  blocking**.
-- **Inaccessible** (deleted, cross-org, permission denied) → **still blocking**, unless the item
-  body or a newer human comment explicitly states the dependency is resolved.
+Then classify each blocker **by containment, per the `blocker-containment` rule** — cite that
+slug for the full contract; do not restate its resolution steps or its fail-closed table here.
+
+The one question is whether the blocker's code is on the branch **this item** will be built from:
+resolve this item's base branch from its `## Target Backend Environment` through
+`.lisa.config.json` `deploy.branches` (`derived-branch-plan`, `config-resolution` — never by
+reading a rendered `Branch Plan`), resolve the blocker's merge commit through the vendor access
+layer, and test ancestry against the remote.
+
+- **Contained** — every merged PR on the blocker is an ancestor of this item's base branch →
+  **cleared**.
+- **Not contained**, or containment **not computable** for any reason the rule enumerates (no
+  linked PR, PR not merged, blocker inaccessible, base branch underivable or absent from the
+  remote, ancestry query errored) → **still blocking**, with the rule's reason key in the run
+  record.
+- **Ships no code** — the blocker is closed as completed, positively declares
+  `Target Backend Environment: None — no runtime behavior change`, and has no merged PR →
+  **cleared** under the rule's carve-out. This is a positive determination, never an absence:
+  "no PR found" is `no-pr` and stays blocking.
+- **Human override** — an explicit human statement on this item that the dependency is satisfied
+  clears it and outranks a failed containment check. Name it in the run record.
+
+**A lifecycle status name is never the test.** `done`, `on-stg`, `on-dev` and `code-review` are
+labels that correlate with containment in a single-trunk workflow and come apart from it in a
+promotion workflow, where `main` is the trailing branch — a blocker at `On Stg` is on `staging`
+and absent from `main`, and a blocker in `Code Review` is merged to nothing. Containment gets
+both the loose and the strict failure right at once: a blocker merged into the branch this item
+builds from clears **immediately**, with no wait for production, so a dependent is never stranded
+behind work already merged where it needs it.
 
 Only re-dispatch when **every** parsed blocker is cleared. When in doubt, stay blocked — a
-false-negative (left blocked) is cheap; a false-positive (re-dispatched into a real blocker)
-wastes a build cycle.
+false-negative (left blocked) costs one cycle and is visible; a false-positive is **invisible**,
+because the item moves to `ready`, which looks exactly like a repair that worked, and the failure
+surfaces days later as work begun before its dependency existed.
 
 ### Class B — validation / quality-gate self-block
 

package/plugins/lisa/skills/lisa-ticket-triage/SKILL.md

@@ -46,7 +46,7 @@ If relevant code IS found, proceed to Phase 2.
 
 From the context bundle, evaluate relationships before analyzing this ticket in isolation:
 
-- **Open blockers (`is blocked by`)**: if any blocker is not `Done` or its linked PR is not merged, raise an ambiguity: "Blocker {KEY} is not shipped — work cannot meaningfully start." This is an automatic `BLOCKED` verdict unless the human confirms the blocker state is acceptable.
+- **Open blockers (`is blocked by`)**: clear-check each blocker **by containment, per the `blocker-containment` rule** — cite that slug for the full contract rather than restating it. A blocker is satisfied when its merged PRs are ancestors of the branch this ticket will be built from (resolved from this ticket's `## Target Backend Environment` through `.lisa.config.json` `deploy.branches`, never from a rendered `Branch Plan`), or when the rule's narrow no-code carve-out or human override applies. **`Done` is not the test** — a state name holds in a single-trunk workflow and comes apart in a promotion workflow, and requiring the production terminal strands every dependent behind work already merged where this ticket needs it. This is the same predicate the `DUPLICATE_ALREADY_FIXED` bullet below already requires ("present on the relevant base branch… never from a name/label match alone"), applied here too. For a blocker that is not contained, or where containment is not computable, raise an ambiguity naming the rule's reason key: "Blocker {KEY} is not on {BRANCH} ({REASON}) — work cannot meaningfully start." That is an automatic `BLOCKED` verdict unless the human confirms the blocker state is acceptable.
 - **Epic siblings in progress**: if a sibling under the same epic is `In Progress` / `In Review` with a different assignee and overlapping scope, raise it as an edge case in Phase 4 ("Duplicate-work risk with {KEY}").
 - **`duplicates` / `is duplicated by` links**:
   - If this ticket is a duplicate of an open canonical ticket whose fix is not yet merged into the base branch, verdict is `BLOCKED` with the recommendation to close as duplicate manually rather than implement.

package/plugins/lisa-agy/plugin.json

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