@codyswann/lisa 2.341.3 → 2.341.5

package/package.json

@@ -120,7 +120,7 @@
     }
   },
   "name": "@codyswann/lisa",
-  "version": "2.341.3",
+  "version": "2.341.5",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

package/plugins/lisa/.codex-plugin/skills/lisa-setup-linear/SKILL.md

@@ -6,9 +6,16 @@ allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mc
 
 # Setup Linear: $ARGUMENTS
 
-Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
+Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
 
-Linear's data model splits labels into two **kinds** that matter here: **issue labels** (drive the build queue, `status:*`) and **project labels** (drive the PRD lifecycle, `prd-*`). They are distinct namespaces in Linear and are NOT interchangeable — the build lifecycle lives on Issues, the PRD lifecycle lives on Projects. The sentinel feedback marker is an **issue** label even though it belongs to the PRD flow (Linear's MCP has no project-level comments — see `linear-prd-intake`).
+The two lifecycles run on different primitives, and conflating them is the most common setup error:
+
+- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
+- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
+
+Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
+
+**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
 
 ## Workflow
 
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
 
 > What should lisa use Linear for?
 >
-> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off the `status:*` issue-label namespace. Sets `tracker: "linear"`. (Requires a team key.)
+> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
 > 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
 
-The role answer drives Step 3 (which label namespaces to scaffold) and whether `teamKey` is required (tracker → yes).
+The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
 
 ### Step 1 — Establish Linear access
 
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
 - **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
 - **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
 
-### Step 3 — Scaffold the lifecycle label namespaces
+### Step 3 — Scaffold the lifecycle namespaces
 
 Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
 
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
 [ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
 ```
 
-Confirm the scaffolded labels are present (`list_issue_labels` for `status:*` + the sentinel; `list_project_labels` for `prd-*`, including the terminal `prd-verified`). Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
+Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
 
 ## Idempotency
 

package/plugins/lisa/commands/setup/linear.md

@@ -1,5 +1,5 @@
 ---
-description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the `status:*` issue-label (build) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
+description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the build-queue workflow states (`linear.workflow`) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
 allowed-tools: ["Skill"]
 argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
 ---

package/plugins/lisa/hooks/block-instruction-file-edits.sh

@@ -42,12 +42,48 @@ fi
 tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
 [ -n "$tool_name" ] || exit 0
 
-# Lisa's own bounded bridges write marked regions. A payload carrying a marker
-# is replacing a delimited block, not appending prose, so it cannot be the
-# unbounded growth this guard exists to stop.
-if printf '%s' "$input" | grep -q '<!-- LISA_'; then
-  exit 0
-fi
+# Lisa's own bounded bridges write marked regions — the agy project-learnings
+# bridge and cross-pollinate's rule section. The premise of their exemption, as
+# originally stated, is that they "replace in place and cannot grow the file".
+# This enforces that premise rather than trusting it.
+#
+# Both sides have to be a marked region and nothing else:
+#
+#   - old_string bounded proves the region really is on disk. Scanning the whole
+#     payload was trivially forgeable — any caller could put `<!-- LISA_` in the
+#     content it was WRITING and walk past the guard.
+#   - new_string bounded is what makes it a replacement rather than an append.
+#     old_string alone does not authorize anything: a caller can read a genuine
+#     marked region, echo it back verbatim, and still smuggle unbounded prose in
+#     after the closing marker. Requiring the written text to be exactly one
+#     marked region — whitespace aside — leaves nowhere to put it.
+#
+# Every edit in a MultiEdit must qualify; one unbounded edit taints the batch.
+# Write is absent by construction: it has no old_string and clobbers the whole
+# file, which is precisely the unbounded case.
+case "$tool_name" in
+  Edit | MultiEdit)
+    if printf '%s' "$input" |
+      jq -e '
+        # Exactly ONE marked region and nothing else. The inner
+        # `(?!<!-- LISA_)` is what makes it one: a plain `[\s\S]*` anchors only
+        # the FIRST opening marker and the LAST closing marker, so
+        # `region + prose + region` satisfies it and the prose between the two
+        # regions rides along outside any marked block.
+        def bounded:
+          type == "string"
+          and test("^\\s*<!-- LISA_[A-Z_]+ -->(?:(?!<!-- LISA_)[\\s\\S])*<!-- LISA_[A-Z_]+ -->\\s*$");
+        def replacement_pairs:
+          if .tool_input.edits? then [.tool_input.edits[]?]
+          else [.tool_input] end;
+        replacement_pairs
+        | length > 0
+        and all(.[]; (.old_string | bounded) and (.new_string | bounded))
+      ' >/dev/null 2>&1; then
+      exit 0
+    fi
+    ;;
+esac
 
 # Basename match, case-insensitively: `agents.md` and `AGENTS.md` are the same
 # file on the macOS checkouts this fleet runs on.
@@ -130,9 +166,13 @@ EOF
     # Write signatures only. A bare mention (`cat AGENTS.md`, `rg x AGENTS.md`)
     # is a read and must stay allowed — the filename has to appear as the target
     # of a redirection, a tee, or an in-place sed.
+    # `>>?\|?` covers `>`, `>>`, and the noclobber override `>|`. The bare-`>`
+    # branch already catches explicit fd forms such as `1>` / `2>>` because the
+    # pattern is unanchored and matches the `>` inside them; `>|` was the real
+    # gap, since `|` is excluded by the target class and so terminated the match.
     write_target='[^ |;&]*(agents|claude|copilot-instructions)\.md'
     if printf '%s' "$command_str" |
-      grep -Eqi ">>?[[:space:]]*['\"]?$write_target|tee([[:space:]]+-[a-z]+)*[[:space:]]+['\"]?$write_target|sed[[:space:]]+[^|;&]*-i[^|;&]*$write_target"; then
+      grep -Eqi ">>?\|?[[:space:]]*['\"]?$write_target|tee([[:space:]]+-[a-z]+)*[[:space:]]+['\"]?$write_target|sed[[:space:]]+[^|;&]*-i[^|;&]*$write_target"; then
       refuse "$(printf '%s' "$command_str" |
         grep -Eoi "$write_target" | head -1)"
     fi

package/plugins/lisa/hooks/block-no-verify.sh

@@ -97,17 +97,61 @@ except ValueError:
 
 normalized_tokens = [token.strip("();|&") for token in tokens]
 
+# The only relocations that keep a repo's own hooks in play. `.husky` is the
+# husky convention this fleet runs; `.githooks` is the common hand-rolled one.
+# Anything else — including "" and /dev/null, which are simply the two most
+# obvious members of the blocked set rather than special cases — is refused.
+PERMITTED_HOOKS_PATHS = {".husky", ".githooks"}
+
+
+def is_permitted_hooks_path(value):
+    """Whether a core.hooksPath value relocates hooks rather than disabling them.
+
+    Args:
+        value: The raw core.hooksPath value as it appeared on the command line.
+
+    Returns:
+        True if the path is an established in-repo hooks directory.
+    """
+    cleaned = value.strip().strip("'\"")
+    if cleaned.startswith("./"):
+        cleaned = cleaned[2:]
+    return cleaned.rstrip("/") in PERMITTED_HOOKS_PATHS
+
 for i, token in enumerate(normalized_tokens):
     if token == "--no-verify":
         sys.exit(1)
     if token == "HUSKY=0" or token.startswith("HUSKY_SKIP_HOOKS="):
         sys.exit(1)
-    if token.startswith("core.hooksPath="):
-        value = token.split("=", 1)[1]
-        if value in ("", "/dev/null"):
+    # Allowlist the destinations, do not denylist the disabling ones.
+    #
+    # This used to block only "" and /dev/null. But hooks are disabled just as
+    # completely by pointing hooksPath at any directory that happens to contain
+    # none — `-c core.hooksPath=/tmp/empty` bypassed every hook while reading as
+    # an ordinary path — so a denylist of "obviously disabling" values can
+    # always be stepped around by naming a third thing. The set of paths that
+    # DISABLE hooks is unbounded; the set that legitimately relocates them is
+    # tiny and known, so the allowlist is the only side that can be enumerated.
+    #
+    # Matched case-insensitively because git config variable names are:
+    # `CORE.HOOKSPATH=/x` and `core.hookspath=/x` are the same setting to git,
+    # so a case-sensitive check is bypassed by holding down shift.
+    lowered = token.lower()
+    if lowered.startswith("core.hookspath="):
+        if not is_permitted_hooks_path(token.split("=", 1)[1]):
+            sys.exit(1)
+    if lowered == "core.hookspath" and i + 1 < len(normalized_tokens):
+        if not is_permitted_hooks_path(normalized_tokens[i + 1]):
+            sys.exit(1)
+    # `git --config-env=core.hooksPath=SOMEVAR` sets the same config, reading
+    # the value out of the named environment variable. The path therefore is
+    # not in the command at all, so there is nothing to allowlist against —
+    # SOMEVAR can hold anything by the time git reads it. Any core.hooksPath
+    # routed through --config-env is refused outright.
+    if lowered.startswith("--config-env="):
+        spec = token.split("=", 1)[1]
+        if spec.split("=", 1)[0].strip().lower() == "core.hookspath":
             sys.exit(1)
-    if token == "core.hooksPath" and i + 1 < len(normalized_tokens) and normalized_tokens[i + 1] in ("", "/dev/null"):
-        sys.exit(1)
 
 sys.exit(0)
 PY

package/plugins/lisa/hooks/block-shell-json-parsing.sh

@@ -24,6 +24,25 @@ set -euo pipefail
 
 input="$(cat)"
 
+# Probe the interpreters before the first use. Under `set -euo pipefail` an
+# absent jq does not merely skip the parse — the assignment below dies with
+# 127, and 127 is not a refusal, so the guard vanishes and the command runs.
+# Worse, that 127 used to outrank a sibling guard's 2 in
+# lisa-enforcement-fallback.sh, taking a real refusal down with it.
+#
+# Degrading to "allow" stays right: a hook that cannot parse its input cannot
+# tell a bypass from an ordinary command, and failing closed would block every
+# Bash call on a machine missing an interpreter. Doing it QUIETLY is what is
+# wrong — a guard that is silently absent reads exactly like a guard that is
+# passing. Mirrors block-no-verify.sh, which already had this.
+for required in jq python3; do
+  if ! command -v "$required" >/dev/null 2>&1; then
+    printf 'block-shell-json-parsing: %s not found; JSON-parsing protection is NOT active\n' \
+      "$required" >&2
+    exit 0
+  fi
+done
+
 tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
 if [ "$tool_name" != "Bash" ]; then
   exit 0
@@ -40,7 +59,7 @@ case "$command_str" in
   *) exit 0 ;;
 esac
 
-command -v python3 >/dev/null 2>&1 || exit 0
+# python3 is probed with jq at the top now, announced rather than silent.
 
 if ! BLOCK_SHELL_JSON_COMMAND="$command_str" python3 - <<'PY'
 import os

package/plugins/lisa/skills/lisa-setup-linear/SKILL.md

@@ -1,14 +1,21 @@
 ---
 name: lisa-setup-linear
-description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue issue-label namespace (`status:*`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
+description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue **workflow states** (`linear.workflow`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
 ---
 
 # Setup Linear: $ARGUMENTS
 
-Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
+Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
 
-Linear's data model splits labels into two **kinds** that matter here: **issue labels** (drive the build queue, `status:*`) and **project labels** (drive the PRD lifecycle, `prd-*`). They are distinct namespaces in Linear and are NOT interchangeable — the build lifecycle lives on Issues, the PRD lifecycle lives on Projects. The sentinel feedback marker is an **issue** label even though it belongs to the PRD flow (Linear's MCP has no project-level comments — see `linear-prd-intake`).
+The two lifecycles run on different primitives, and conflating them is the most common setup error:
+
+- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
+- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
+
+Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
+
+**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
 
 ## Workflow
 
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
 
 > What should lisa use Linear for?
 >
-> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off the `status:*` issue-label namespace. Sets `tracker: "linear"`. (Requires a team key.)
+> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
 > 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
 
-The role answer drives Step 3 (which label namespaces to scaffold) and whether `teamKey` is required (tracker → yes).
+The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
 
 ### Step 1 — Establish Linear access
 
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
 - **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
 - **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
 
-### Step 3 — Scaffold the lifecycle label namespaces
+### Step 3 — Scaffold the lifecycle namespaces
 
 Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
 
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
 [ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
 ```
 
-Confirm the scaffolded labels are present (`list_issue_labels` for `status:*` + the sentinel; `list_project_labels` for `prd-*`, including the terminal `prd-verified`). Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
+Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
 
 ## Idempotency
 

package/plugins/lisa-agy/commands/lisa/setup/linear.md

@@ -1,5 +1,5 @@
 ---
-description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the `status:*` issue-label (build) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
+description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the build-queue workflow states (`linear.workflow`) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
 allowed-tools: ["Skill"]
 argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
 ---

package/plugins/lisa-agy/hooks/block-instruction-file-edits.sh

@@ -42,12 +42,48 @@ fi
 tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
 [ -n "$tool_name" ] || exit 0
 
-# Lisa's own bounded bridges write marked regions. A payload carrying a marker
-# is replacing a delimited block, not appending prose, so it cannot be the
-# unbounded growth this guard exists to stop.
-if printf '%s' "$input" | grep -q '<!-- LISA_'; then
-  exit 0
-fi
+# Lisa's own bounded bridges write marked regions — the agy project-learnings
+# bridge and cross-pollinate's rule section. The premise of their exemption, as
+# originally stated, is that they "replace in place and cannot grow the file".
+# This enforces that premise rather than trusting it.
+#
+# Both sides have to be a marked region and nothing else:
+#
+#   - old_string bounded proves the region really is on disk. Scanning the whole
+#     payload was trivially forgeable — any caller could put `<!-- LISA_` in the
+#     content it was WRITING and walk past the guard.
+#   - new_string bounded is what makes it a replacement rather than an append.
+#     old_string alone does not authorize anything: a caller can read a genuine
+#     marked region, echo it back verbatim, and still smuggle unbounded prose in
+#     after the closing marker. Requiring the written text to be exactly one
+#     marked region — whitespace aside — leaves nowhere to put it.
+#
+# Every edit in a MultiEdit must qualify; one unbounded edit taints the batch.
+# Write is absent by construction: it has no old_string and clobbers the whole
+# file, which is precisely the unbounded case.
+case "$tool_name" in
+  Edit | MultiEdit)
+    if printf '%s' "$input" |
+      jq -e '
+        # Exactly ONE marked region and nothing else. The inner
+        # `(?!<!-- LISA_)` is what makes it one: a plain `[\s\S]*` anchors only
+        # the FIRST opening marker and the LAST closing marker, so
+        # `region + prose + region` satisfies it and the prose between the two
+        # regions rides along outside any marked block.
+        def bounded:
+          type == "string"
+          and test("^\\s*<!-- LISA_[A-Z_]+ -->(?:(?!<!-- LISA_)[\\s\\S])*<!-- LISA_[A-Z_]+ -->\\s*$");
+        def replacement_pairs:
+          if .tool_input.edits? then [.tool_input.edits[]?]
+          else [.tool_input] end;
+        replacement_pairs
+        | length > 0
+        and all(.[]; (.old_string | bounded) and (.new_string | bounded))
+      ' >/dev/null 2>&1; then
+      exit 0
+    fi
+    ;;
+esac
 
 # Basename match, case-insensitively: `agents.md` and `AGENTS.md` are the same
 # file on the macOS checkouts this fleet runs on.
@@ -130,9 +166,13 @@ EOF
     # Write signatures only. A bare mention (`cat AGENTS.md`, `rg x AGENTS.md`)
     # is a read and must stay allowed — the filename has to appear as the target
     # of a redirection, a tee, or an in-place sed.
+    # `>>?\|?` covers `>`, `>>`, and the noclobber override `>|`. The bare-`>`
+    # branch already catches explicit fd forms such as `1>` / `2>>` because the
+    # pattern is unanchored and matches the `>` inside them; `>|` was the real
+    # gap, since `|` is excluded by the target class and so terminated the match.
     write_target='[^ |;&]*(agents|claude|copilot-instructions)\.md'
     if printf '%s' "$command_str" |
-      grep -Eqi ">>?[[:space:]]*['\"]?$write_target|tee([[:space:]]+-[a-z]+)*[[:space:]]+['\"]?$write_target|sed[[:space:]]+[^|;&]*-i[^|;&]*$write_target"; then
+      grep -Eqi ">>?\|?[[:space:]]*['\"]?$write_target|tee([[:space:]]+-[a-z]+)*[[:space:]]+['\"]?$write_target|sed[[:space:]]+[^|;&]*-i[^|;&]*$write_target"; then
       refuse "$(printf '%s' "$command_str" |
         grep -Eoi "$write_target" | head -1)"
     fi

package/plugins/lisa-agy/hooks/block-shell-json-parsing.sh

@@ -24,6 +24,25 @@ set -euo pipefail
 
 input="$(cat)"
 
+# Probe the interpreters before the first use. Under `set -euo pipefail` an
+# absent jq does not merely skip the parse — the assignment below dies with
+# 127, and 127 is not a refusal, so the guard vanishes and the command runs.
+# Worse, that 127 used to outrank a sibling guard's 2 in
+# lisa-enforcement-fallback.sh, taking a real refusal down with it.
+#
+# Degrading to "allow" stays right: a hook that cannot parse its input cannot
+# tell a bypass from an ordinary command, and failing closed would block every
+# Bash call on a machine missing an interpreter. Doing it QUIETLY is what is
+# wrong — a guard that is silently absent reads exactly like a guard that is
+# passing. Mirrors block-no-verify.sh, which already had this.
+for required in jq python3; do
+  if ! command -v "$required" >/dev/null 2>&1; then
+    printf 'block-shell-json-parsing: %s not found; JSON-parsing protection is NOT active\n' \
+      "$required" >&2
+    exit 0
+  fi
+done
+
 tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
 if [ "$tool_name" != "Bash" ]; then
   exit 0
@@ -40,7 +59,7 @@ case "$command_str" in
   *) exit 0 ;;
 esac
 
-command -v python3 >/dev/null 2>&1 || exit 0
+# python3 is probed with jq at the top now, announced rather than silent.
 
 if ! BLOCK_SHELL_JSON_COMMAND="$command_str" python3 - <<'PY'
 import os

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-setup-linear/SKILL.md

@@ -1,14 +1,21 @@
 ---
 name: lisa-setup-linear
-description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue issue-label namespace (`status:*`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
+description: "Configure Linear as the destination tracker and/or the PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in OS keychain), resolves the workspace slug and team key, scaffolds the build-queue **workflow states** (`linear.workflow`) when Linear is the tracker and/or the PRD-lifecycle project-label namespace (`prd-*` + issue-level sentinel) when Linear is the PRD source, writes the `linear` section into `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` and/or `source: \"linear\"`. Idempotent — re-running updates the existing section and reuses existing labels. No /lisa:setup:atlassian prerequisite."
 allowed-tools: ["Bash", "Read", "Write", "Edit", "Skill", "AskUserQuestion", "mcp__linear-server__authenticate", "mcp__linear-server__complete_authentication"]
 ---
 
 # Setup Linear: $ARGUMENTS
 
-Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
+Make Linear a tracker, a PRD source, or both for this project. After this skill, `.lisa.config.json` contains `linear.workspace` (+ `linear.teamKey` when Linear is the tracker), the team carries the lifecycle states and label namespaces lisa needs, and (optionally) `tracker` / `source` point at Linear.
 
-Linear's data model splits labels into two **kinds** that matter here: **issue labels** (drive the build queue, `status:*`) and **project labels** (drive the PRD lifecycle, `prd-*`). They are distinct namespaces in Linear and are NOT interchangeable — the build lifecycle lives on Issues, the PRD lifecycle lives on Projects. The sentinel feedback marker is an **issue** label even though it belongs to the PRD flow (Linear's MCP has no project-level comments — see `linear-prd-intake`).
+The two lifecycles run on different primitives, and conflating them is the most common setup error:
+
+- **Build queue → native workflow STATES**, read from `linear.workflow.*`. Not labels. See "Why Linear uses states, not labels" in `config-resolution`, and Step 3a below. `lisa-linear-build-intake` reads only these.
+- **PRD lifecycle → PROJECT labels** (`prd-*`), because a PRD is a Linear Project.
+
+Project labels and issue labels are distinct namespaces in Linear and are NOT interchangeable — creating an issue label named `prd-ready` will not work for the PRD flow. The one issue label this skill creates is the sentinel feedback marker, which belongs to the PRD flow despite being an issue label (Linear's MCP has no project-level comments — see `linear-prd-intake`).
+
+**A `status:*` issue-label namespace is no longer scaffolded or read.** It was the pre-state-model build lane; see "Migrating a project that predates the state model" below for what to do with a config that still carries it.
 
 ## Workflow
 
@@ -28,10 +35,10 @@ Ask two things via `AskUserQuestion`.
 
 > What should lisa use Linear for?
 >
-> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off the `status:*` issue-label namespace. Sets `tracker: "linear"`. (Requires a team key.)
+> 1. **Destination tracker** — lisa writes Epics→Projects, Stories→Issues, Sub-tasks→Sub-issues; the build queue runs off native workflow **states** (`linear.workflow`), not labels. Sets `tracker: "linear"`. (Requires a team key.)
 > 2. **PRD source** — humans flag Linear **projects** with `prd-ready`; `/lisa:intake` scans and ticketes them off the `prd-*` project-label namespace. Sets `source: "linear"`.
 
-The role answer drives Step 3 (which label namespaces to scaffold) and whether `teamKey` is required (tracker → yes).
+The role answer drives Step 3 (states for the tracker lane, `prd-*` project labels for the PRD lane) and whether `teamKey` is required (tracker → yes).
 
 ### Step 1 — Establish Linear access
 
@@ -139,7 +146,7 @@ echo "Linear key validated. Org: $(echo "$VIEWER" | jq -r '.data.organization.ur
 - **Workspace slug**: honor `--workspace=<slug>`. Otherwise derive from the validated identity — the GraphQL `organization.urlKey` (API path) or the team list's workspace (MCP path). Confirm with the user; this slug is the keychain `account` key and the multi-workspace disambiguator.
 - **Team key** (required when Linear is the **tracker**): honor `--team=<KEY>`. Otherwise enumerate teams via `lisa-linear-access operation: list-teams({})` (or the GraphQL `teams` query) and present them via `AskUserQuestion` (label = team key, description = team name) for the user to pick the team that owns lisa's destination Issues. If Linear is source-only, `teamKey` is optional — skip unless the user wants to pin a team scope.
 
-### Step 3 — Scaffold the lifecycle label namespaces
+### Step 3 — Scaffold the lifecycle namespaces
 
 Read role → label with the default-fallback ladder the intake skills use, so scaffolded labels match exactly what they query.
 
@@ -280,7 +287,7 @@ jq -e '.linear.workspace' .lisa.config.json >/dev/null
 [ "$(jq -r '.tracker // empty' .lisa.config.json)" = "linear" ] && jq -e '.linear.teamKey' .lisa.config.json >/dev/null
 ```
 
-Confirm the scaffolded labels are present (`list_issue_labels` for `status:*` + the sentinel; `list_project_labels` for `prd-*`, including the terminal `prd-verified`). Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
+Confirm what was scaffolded is present: `list-workflow-states` for every build role when Linear is the tracker, `list_project_labels` for `prd-*` (including the terminal `prd-verified`) and `list_issue_labels` for the sentinel when Linear is the PRD source. Do NOT expect a `status:*` namespace — it is not part of this model. Report success with the resolved workspace, team key (if any), which namespaces were scaffolded (created vs. already existed), any non-default overrides, and whether `tracker` / `source` were set. Direct the user to `/lisa:intake` to test.
 
 ## Idempotency
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.341.3",
+  "version": "2.341.5",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.341.3",
+  "version": "2.341.5",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.341.3",
+  "version": "2.341.5",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.341.3",
+  "version": "2.341.5",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.341.3",
+  "version": "2.341.5",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/commands/lisa/setup/linear.md

@@ -1,5 +1,5 @@
 ---
-description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the `status:*` issue-label (build) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
+description: "Set up Linear as the tracker and/or PRD source for this project. Verifies Linear access (MCP OAuth or a personal API key in keychain), resolves the workspace slug and team key, scaffolds the build-queue workflow states (`linear.workflow`) and/or `prd-*` project-label (PRD) namespaces, writes the `linear` section of `.lisa.config.json`, and offers to set top-level `tracker: \"linear\"` / `source: \"linear\"`. No /lisa:setup:atlassian prerequisite."
 allowed-tools: ["Skill"]
 argument-hint: "[--workspace=<slug>] [--team=<KEY>]"
 ---