@codyswann/lisa 4.33.6 → 4.33.9

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/dist/opencode/plugin-templates/parity-safety-net.sh

@@ -1687,7 +1687,50 @@ fi
 
 # 13. Dropping or truncating a database / schema / table (Lisa-only guard —
 #     upstream has no SQL protection; keep).
-if matches '\b(drop[[:space:]]+(database|schema|table)|truncate[[:space:]]+(table[[:space:]]+)?[[:alnum:]_."`]+)\b'; then
+#
+# The two arms used to be asymmetric, and only the lopsided one produced false
+# positives (issue #3530). The `drop` arm requires a following keyword —
+# `drop database|schema|table` — so `drop the ball` never matched it. The
+# `truncate` arm made that keyword OPTIONAL:
+#
+#     truncate[[:space:]]+(table[[:space:]]+)?[[:alnum:]_."`]+
+#
+# which reduces to "`truncate`, whitespace, any identifier-ish word", so
+# `truncate the board`, `truncate results` and `truncate output` all matched.
+# A session was refused for a bug-report TITLE describing a connection that
+# truncates results — and a title has no escape hatch, because the remedy this
+# hook prints at the wall (write the text to a file, pass it BY PATH) covers a
+# body, while the title flag of an issue-filing CLI is necessarily inline. The
+# only exit left was to reword, which is what trains people to route around a
+# guard.
+#
+# The fix keeps the coverage and drops the English, in three arms.
+#
+# ARM 1 — `drop`, byte-identical to before. It was already correct, and a
+# rewrite that unified the arms could only make it permissive.
+readonly SQL_DROP='\bdrop[[:space:]]+(database|schema|table)\b'
+# ARM 2 — `truncate` carrying its own evidence that it is a statement rather
+# than a verb: the TABLE keyword (what the drop arm demands), a
+# schema-qualified name, a quoted identifier, a trailing `;`, or one of the
+# tail keywords that only ever follow a TRUNCATE. English has none of these.
+readonly SQL_TRUNCATE_TAIL='(cascade|restrict|restart[[:space:]]+identity|continue[[:space:]]+identity)([^[:alnum:]_]|$)'
+readonly SQL_TRUNCATE_EVIDENCE='\btruncate[[:space:]]+(table[[:space:]]+[[:alnum:]_."`]+|(only[[:space:]]+)?([[:alnum:]_]+\.[[:alnum:]_."`]+|["`][[:alnum:]_. ]+["`]|[[:alnum:]_]+[[:space:]]*(;|'"$SQL_TRUNCATE_TAIL"')))'
+# ARM 3 — the permissive-dialect `TRUNCATE <name>` with none of that evidence.
+# Deleting this shape is what a lazy fix does: it passes every prose scenario
+# while silently removing the coverage a regression fixture already asserts
+# (`mysql -e 'TRUNCATE sessions'`). So it is recognized by CONTEXT instead —
+# the same command must also invoke a command-line database client. Prose in a
+# tracker filing or a commit message invokes none, which is exactly the
+# difference the text scan could not see on its own.
+readonly SQL_CLIENT='(^|[^[:alnum:]_./-])([[:alnum:]_./-]*/)?(psql|pgcli|mysql|mysqladmin|mysqlsh|mariadb|mycli|sqlite3|sqlcmd|cqlsh|clickhouse-client|cockroach|mongosh|duckdb|usql)([[:space:]]|$)'
+readonly SQL_TRUNCATE_BARE='\btruncate[[:space:]]+(only[[:space:]]+)?[[:alnum:]_."`]'
+# Residual, accepted and stated: a bare `TRUNCATE <name>` with no terminator,
+# no qualification and no recognized client in the same command goes unmatched
+# — the same trade the `drop` arm has always made for `drop the ball`. No DROP
+# shape is weakened, and the guard still fails in the safe direction.
+if matches "$SQL_DROP" \
+  || matches "$SQL_TRUNCATE_EVIDENCE" \
+  || { matches "$SQL_CLIENT" && matches "$SQL_TRUNCATE_BARE"; }; then
   block "destructive SQL (DROP/TRUNCATE) detected"
 fi
 

package/package.json

@@ -165,7 +165,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.33.6",
+  "version": "4.33.9",
   "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": "384b68c7af30a0c6a27ea50978b723b470f6aaaa",
-  "gitHead": "384b68c7af30a0c6a27ea50978b723b470f6aaaa",
-  "lisaReleaseTag": "v4.33.6"
+  "lisaReleaseCommit": "e27b5463d29df52d8d5ffc9bae219cd970ca0323",
+  "gitHead": "e27b5463d29df52d8d5ffc9bae219cd970ca0323",
+  "lisaReleaseTag": "v4.33.9"
 }

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

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

package/plugins/lisa/.codex-plugin/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -652,7 +652,7 @@ result: **27 of 27** open items carrying the claimed role in this repository had
 a merged pull request — the claimed lane reported 27 things in flight when the
 real number was one.
 
-Three properties make the command safe to run unconditionally:
+Four properties make the command safe to run unconditionally:
 
 1. **The terminal role is RESOLVED, never assumed.** `lifecycleContract` reads
    `github.labels.build.done` (or the Jira/Linear equivalent), which is
@@ -666,7 +666,22 @@ Three properties make the command safe to run unconditionally:
    a real one afterwards. Cross-repository references do not count: a downstream
    consumer's PR mentioning an upstream issue is not evidence the upstream issue
    shipped.
-3. **It is idempotent**, so re-running after a retry converges rather than
+3. **It weighs the merged pull request's BASE BRANCH**, the same way step (c)
+   above does, and for the same reason. A merged pull request is not evidence
+   on its own: the writer resolves `<baseRefName>` through `.lisa.config.json`
+   `deploy.branches` and applies only the role that base earned. A merge into
+   the production deploy branch is terminal and closes the item; a merge into a
+   branch mapping to a lower env records that env's role and leaves the item
+   open; a merge into a branch the project does not deploy at all — an
+   integration/stack branch — records nothing, closes nothing, and reports the
+   base it observed. **Measured**: on a stacked-PR queue the previous writer
+   stamped the production terminal role and closed every ticket in the batch at
+   the moment its PR landed on the stacking branch, and one of those false
+   completions then made push gate 1 refuse a follow-up commit on the same
+   ticket, because there was no longer an open work item to bind. When the
+   command reports `work-item NOT completed`, that is the correct answer for a
+   stacked merge — re-run it after the stack reaches the deploy branch.
+4. **It is idempotent**, so re-running after a retry converges rather than
    accumulating.
 
 It also removes the claimed role rather than only adding the terminal one.

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

@@ -539,7 +539,7 @@ gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Buil
 
 The ordering is the point. Announcing before verifying leaves a public "Build complete" on an item whose lifecycle state was never confirmed, and a reader has no way to tell that claim apart from a verified one — the same indistinguishability the readback exists to prevent. On a failed readback, comment the Error instead.
 
-`node scripts/lisa-work-item.mjs complete --ref <org>/<repo>#<number>` performs this whole terminal sequence — merged-PR evidence check, full role reconciliation, close, independent readback — in one step, and is the preferred path whenever `$DONE` is the terminal value. Use the manual commands above for intermediate env transitions, which must not close the issue.
+`node scripts/lisa-work-item.mjs complete --ref <org>/<repo>#<number>` performs this whole terminal sequence — merged-PR evidence check, full role reconciliation, close, independent readback — in one step, and is the preferred path whenever `$DONE` is the terminal value. It also decides for itself whether `$DONE` is terminal here: it resolves each merged PR's base branch through `.lisa.config.json` `deploy.branches`, so a merge into an intermediate env branch records that env's role WITHOUT closing the issue, and a merge into a branch the project does not deploy records nothing and says which base it saw. The manual commands above remain available for an intermediate env transition performed without merge evidence.
 
 For any non-Success outcome, do NOT transition. The issue sits in `$CLAIMED` (or wherever the lifecycle left it) — humans take it from there.
 

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/hooks/parity-safety-net.sh

@@ -1687,7 +1687,50 @@ fi
 
 # 13. Dropping or truncating a database / schema / table (Lisa-only guard —
 #     upstream has no SQL protection; keep).
-if matches '\b(drop[[:space:]]+(database|schema|table)|truncate[[:space:]]+(table[[:space:]]+)?[[:alnum:]_."`]+)\b'; then
+#
+# The two arms used to be asymmetric, and only the lopsided one produced false
+# positives (issue #3530). The `drop` arm requires a following keyword —
+# `drop database|schema|table` — so `drop the ball` never matched it. The
+# `truncate` arm made that keyword OPTIONAL:
+#
+#     truncate[[:space:]]+(table[[:space:]]+)?[[:alnum:]_."`]+
+#
+# which reduces to "`truncate`, whitespace, any identifier-ish word", so
+# `truncate the board`, `truncate results` and `truncate output` all matched.
+# A session was refused for a bug-report TITLE describing a connection that
+# truncates results — and a title has no escape hatch, because the remedy this
+# hook prints at the wall (write the text to a file, pass it BY PATH) covers a
+# body, while the title flag of an issue-filing CLI is necessarily inline. The
+# only exit left was to reword, which is what trains people to route around a
+# guard.
+#
+# The fix keeps the coverage and drops the English, in three arms.
+#
+# ARM 1 — `drop`, byte-identical to before. It was already correct, and a
+# rewrite that unified the arms could only make it permissive.
+readonly SQL_DROP='\bdrop[[:space:]]+(database|schema|table)\b'
+# ARM 2 — `truncate` carrying its own evidence that it is a statement rather
+# than a verb: the TABLE keyword (what the drop arm demands), a
+# schema-qualified name, a quoted identifier, a trailing `;`, or one of the
+# tail keywords that only ever follow a TRUNCATE. English has none of these.
+readonly SQL_TRUNCATE_TAIL='(cascade|restrict|restart[[:space:]]+identity|continue[[:space:]]+identity)([^[:alnum:]_]|$)'
+readonly SQL_TRUNCATE_EVIDENCE='\btruncate[[:space:]]+(table[[:space:]]+[[:alnum:]_."`]+|(only[[:space:]]+)?([[:alnum:]_]+\.[[:alnum:]_."`]+|["`][[:alnum:]_. ]+["`]|[[:alnum:]_]+[[:space:]]*(;|'"$SQL_TRUNCATE_TAIL"')))'
+# ARM 3 — the permissive-dialect `TRUNCATE <name>` with none of that evidence.
+# Deleting this shape is what a lazy fix does: it passes every prose scenario
+# while silently removing the coverage a regression fixture already asserts
+# (`mysql -e 'TRUNCATE sessions'`). So it is recognized by CONTEXT instead —
+# the same command must also invoke a command-line database client. Prose in a
+# tracker filing or a commit message invokes none, which is exactly the
+# difference the text scan could not see on its own.
+readonly SQL_CLIENT='(^|[^[:alnum:]_./-])([[:alnum:]_./-]*/)?(psql|pgcli|mysql|mysqladmin|mysqlsh|mariadb|mycli|sqlite3|sqlcmd|cqlsh|clickhouse-client|cockroach|mongosh|duckdb|usql)([[:space:]]|$)'
+readonly SQL_TRUNCATE_BARE='\btruncate[[:space:]]+(only[[:space:]]+)?[[:alnum:]_."`]'
+# Residual, accepted and stated: a bare `TRUNCATE <name>` with no terminator,
+# no qualification and no recognized client in the same command goes unmatched
+# — the same trade the `drop` arm has always made for `drop the ball`. No DROP
+# shape is weakened, and the guard still fails in the safe direction.
+if matches "$SQL_DROP" \
+  || matches "$SQL_TRUNCATE_EVIDENCE" \
+  || { matches "$SQL_CLIENT" && matches "$SQL_TRUNCATE_BARE"; }; then
   block "destructive SQL (DROP/TRUNCATE) detected"
 fi
 

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).