@codyswann/lisa 2.352.0 → 2.353.0

package/expo/create-only/.github/workflows/maestro-e2e.yml

@@ -31,7 +31,16 @@ on:
   workflow_dispatch:
     inputs:
       platform:
-        description: 'Platform(s) to run'
+        # NARROWING THIS DOES NOT CLEAR THE NIGHTLY GATE. Picking `android` or
+        # `ios` skips the other platform's job, and GitHub still concludes the
+        # run `success` — a skipped job does not redden its run. The
+        # nightly-e2e-health gate reads the jobs behind a `success` run for
+        # exactly this reason (truth-table row 26 in Lisa's
+        # `docs/nightly-e2e-gate.md`), so a narrowed run reports
+        # `incomplete_run` and keeps blocking. Use these options to iterate on
+        # one platform; dispatch with `all` when the point is to clear a red
+        # nightly.
+        description: 'Platform(s) to run — use `all` when dispatching to clear the nightly gate'
         type: choice
         default: all
         options:

package/expo/create-only/.github/workflows/nightly-e2e-health.yml

@@ -102,6 +102,11 @@ jobs:
       # `{"mode":"job_pattern","pattern":"^…$"}` only for matrix job names that
       # no single string can cover.
       #
+      # `{"mode":"run"}` reads the run's conclusion AND every job behind it,
+      # because GitHub concludes a run `success` when jobs were skipped — a
+      # suite dispatched for one platform only would otherwise report green
+      # about the platform it never tested (row 26 / §2.4 of the contract).
+      #
       # ONLY `maestro-e2e.yml` by default, because that is the only nightly
       # suite this template actually ships. Naming a workflow file that does not
       # exist is truth-table row 11 — a HARD failure, not missing evidence —

package/package.json

@@ -120,7 +120,7 @@
     }
   },
   "name": "@codyswann/lisa",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "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.352.0",
+  "version": "2.353.0",
   "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.352.0",
+  "version": "2.353.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -106,6 +106,40 @@ linear_graphql() {
 Map operation names to Linear GraphQL queries/mutations in this access skill.
 Consumers pass business-shaped arguments only; they do not embed GraphQL.
 
+## `list-workflow-states` — the team's states, and which one it creates into
+
+`list-workflow-states team:<ID>` returns one node per state with `id`, `name`,
+`type`, `position`, and **`isTeamDefault`**.
+
+`isTeamDefault` is `true` for the single state named by the team's
+`defaultIssueState` — where Linear puts every brand-new Issue. Callers need it to
+enforce the rule that `linear.workflow.ready` must be a lane a human moves an
+Issue **into**: pointing `ready` at the default inverts the gate, so the
+claimable lane means "nobody has touched this" rather than "a human marked this
+ready", and build-intake dispatches unapproved work. `/lisa:setup:linear` refuses
+to resolve `ready` onto it, and `/lisa:validate-tracker-mapping` classifies a
+config that already does as `INVERTED`.
+
+It belongs on this operation rather than in a separate `get-team` call because
+every caller that needs it is already enumerating states, and a second round trip
+is a second chance for the two answers to disagree. A team with no
+`defaultIssueState` set yields `isTeamDefault: false` on every node — report that
+honestly; do not fall back to guessing by name or position.
+
+```graphql
+query($teamId:String!){
+  team(id:$teamId){
+    defaultIssueState{ id }
+    states(first:100){ nodes{ id name type position } }
+  }
+}
+```
+
+Set `isTeamDefault` per node by comparing `node.id` against
+`team.defaultIssueState.id`. On the MCP substrate, which exposes states without
+the team's default, resolve the default through the team record and join on `id`
+the same way.
+
 ## `history` — transition history (read-only)
 
 `history id:<ID>` returns an Issue's ordered past state changes — the raw

package/plugins/lisa/.codex-plugin/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -71,7 +71,8 @@ Resolve the **effective** role → name mapping using the same defaults `/lisa:i
 - **Missing / empty tracker**: report `UNRESOLVABLE` with setup guidance (`/lisa:setup:jira`, `/lisa:setup:github`, or `/lisa:setup:linear`). Do not default to JIRA.
 - **JIRA build workflow** (`jira.workflow`): `ready`, `claimed`, optional `review`, `blocked`, and each `done.<env>` (`dev` / `staging` / `production`). Defaults: `Ready`, `In Progress`, `Code Review`, `Blocked`, `{dev: "On Dev", staging: "On Stg", production: "Done"}`.
 - **GitHub build/prd labels** (`github.labels.build`, `github.labels.prd`): each configured label string.
-- **Linear build/prd labels** (`linear.labels.build`, `linear.labels.prd`): each configured label/state string.
+- **Linear build workflow** (`linear.workflow`): `ready`, `claimed`, `review`, `blocked`, and each `done.<env>` — native workflow **states**, the Linear analogue of `jira.workflow`, not of `github.labels`. Defaults: `Ready`, `In Progress`, `In Review`, `Blocked`, `{dev: "On Dev", staging: "On Stg", production: "Done"}`.
+- **Linear labels** (`linear.labels`): the `prd.*` map plus the one surviving build-lane key, the `human_needed` marker (`linear.labels.build.human_needed`). A config that predates the state model may still carry `ready` / `claimed` / `blocked` / `done` under `linear.labels.build`; those are **inert** — nothing reads them. Do not audit them against the live label set, and do not report them as drift. Report them once as a migration note pointing at `/lisa:setup:linear`, which removes them.
 - **Notion PRD values** (`notion.values`): each configured select-option value, validated against the `notion.statusProperty` property's options.
 - **Confluence PRD parents** (`confluence.parents`): each configured parent page id, validated by existence.
 
@@ -103,7 +104,9 @@ gh label list --repo "$REPO" --limit 200 --json name -q '.[].name'
 
 ### Linear / Notion / Confluence
 
-Enumerate via the corresponding access surface (Linear MCP workflow states + labels; Notion data-source select options for `notion.statusProperty`; Confluence page-exists check per parent id). Same compare-exact-case contract as JIRA.
+Enumerate via the corresponding access surface (`lisa-linear-access` workflow states + labels; Notion data-source select options for `notion.statusProperty`; Confluence page-exists check per parent id). Same compare-exact-case contract as JIRA.
+
+For Linear, `lisa-linear-access operation: list-workflow-states` returns each state's `name`, `type`, `position` and `isTeamDefault` (the access layer sets it from the team's `defaultIssueState`). **Keep `isTeamDefault`** — Step 4 needs it, and it is the only authoritative answer to "which state does this team create Issues into". Do not approximate it with a name guess: `Todo` is merely the stock name, and a team that renamed its `defaultIssueState` is exactly the case a name guess misses.
 
 ## Step 4 — Compare (exact case)
 
@@ -113,10 +116,14 @@ For each `(role, configured-name)` pair, classify against the live name set:
 - **CASE_DRIFT** — a case-insensitive match exists but no exact-case match (e.g. config `"On Stg"` vs live `"ON STG"`). Canonical = the live exact name.
 - **MISSING** — no case-insensitive match exists. The name was renamed beyond recognition or deleted.
 
+One role carries a further check that name-existence cannot express:
+
+- **INVERTED** — Linear only, `ready` only: the configured state exists, but it is the team's **default created state** (`isTeamDefault`). This is worse than a name that does not resolve. The name resolves perfectly, so every existence check passes while the gate runs backwards: `ready` is supposed to mean "a human moved this Issue here", and the team's default means "nobody has touched this". Build-intake claims from that lane, so an INVERTED mapping dispatches work no human ever approved. Measured on the first team it hit: 20 Issues in the claimable lane, 12 never marked ready — including decision tickets shaped like leaves, which the leaf-only gate cannot catch either. Report it even when every other role is VALID.
+
 A project's verdict:
 
 - **VALID** — every role is VALID.
-- **DRIFTED** — at least one CASE_DRIFT or MISSING role, none of which is UNRESOLVABLE.
+- **DRIFTED** — at least one CASE_DRIFT, MISSING, or INVERTED role, none of which is UNRESOLVABLE. An INVERTED `ready` is never VALID, no matter how cleanly it resolves.
 - **UNRESOLVABLE** — the live set couldn't be enumerated (auth mismatch, missing tracker config, access failure). Distinguish this loudly from VALID — an unresolved audit is not a passing audit.
 
 ## Step 5 — Report
@@ -134,7 +141,17 @@ Per project, print a terminal-first section:
   done.production Done              Done                VALID
 ```
 
-End with a roll-up: counts of VALID / DRIFTED / UNRESOLVABLE projects and the exact next command (`… repair=true` when drift is auto-repairable; an admin note when a status is genuinely MISSING).
+An INVERTED `ready` gets a full line rather than a one-word status, because the operator reading it is not necessarily an engineer and the word alone does not convey the stakes:
+
+```
+  ready           Todo              Todo                INVERTED
+      "Todo" is the state this Linear team puts every NEW issue into, so the
+      build queue is currently claiming issues nobody marked ready. Pick or
+      create a state a person moves an issue into (Lisa's default is "Ready")
+      via /lisa:setup:linear, then set linear.workflow.ready to it.
+```
+
+End with a roll-up: counts of VALID / DRIFTED / UNRESOLVABLE projects and the exact next command (`… repair=true` when drift is auto-repairable; an admin note when a status is genuinely MISSING; `/lisa:setup:linear` when a `ready` is INVERTED).
 
 ## Step 6 — Repair (only when `repair=true`)
 
@@ -166,6 +183,18 @@ Compute the closest live candidates (case-insensitive token/substring overlap, t
 
 Only write on an explicit pick. Never auto-select. If the user leaves it unchanged, keep the project `DRIFTED` and surface the admin remediation (add the status back, or fix it in the tracker).
 
+### INVERTED — never auto-repair
+
+**Never auto-repair an INVERTED `ready`, even with `repair=true`.** Every other classification has one correct answer that the live tracker already knows: CASE_DRIFT has the canonical casing, MISSING has a shortlist of near-matches. INVERTED has neither. The configured name is live and correctly cased; what is wrong is which lane the project chose to mean "build-ready", and nothing in the config or the tracker records what the human intended instead. Guessing would silently repoint the queue at a lane that may hold nothing, or worse, at another lane the team fills automatically — swapping one wrong answer for a quieter one.
+
+The team may also genuinely not have a dedicated ready lane yet, in which case the repair is to **create a state**, not to rewrite a string — `/lisa:validate-tracker-mapping` audits config, it does not mutate the tracker.
+
+So: present the team's non-default states via `AskUserQuestion`, and write `linear.workflow.ready` only on an explicit pick. If none fits, or the user declines, leave the config untouched, keep the project `DRIFTED`, and hand off:
+
+> Linear has no dedicated build-ready state on this team. Run `/lisa:setup:linear` — it offers to create `Ready` and records the mapping.
+
+Until then, say plainly that the build queue is claiming unapproved work and that pausing build intake is the safe interim.
+
 ### Invalidate the verification cache
 
 After any JIRA repair, clear the `setup-jira` reachability cache so it re-verifies the new mapping:

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

@@ -449,6 +449,13 @@ Every lifecycle skill operates on a fixed set of **roles** (`ready`, `claimed`,
 
 **`ready` must never resolve to the team's DEFAULT state.** `Todo` is where Linear puts a brand-new issue, so using it for `ready` inverts the gate: the lane stops meaning "a human flipped this to build-ready" and starts meaning "nobody has touched this". Measured on the first team migrated: 20 issues in the lane, only 8 ever explicitly marked ready. JIRA avoids this because `jira.workflow.ready` is a dedicated `Ready` status while a fresh ticket lands in the project default.
 
+**That rule is enforced, not merely stated — a correct default is only half the fix.** The default is `Ready`, but any project can override `linear.workflow.ready`, and an override reproduces the inversion exactly. Two arms catch it, deliberately split by what each can see:
+
+- **Static, always-on.** The queue-contract resolver refuses a `ready` naming a stock default created state (`Todo`, `To Do`, `Backlog`, `Triage`) and throws rather than resolving. It needs no network, so it runs everywhere, including offline and in CI. It cannot see a team that renamed its default.
+- **Live, authoritative.** `/lisa:validate-tracker-mapping` compares the configured `ready` against the team's real `defaultIssueState` (surfaced as `isTeamDefault` on `lisa-linear-access operation: list-workflow-states`) and classifies a match as `INVERTED` — never `VALID`, and never auto-repaired, because nothing records what lane the human meant instead.
+
+`INVERTED` is not a name-resolution failure; it is the opposite. The name resolves perfectly, which is precisely why every existence check passes while the gate runs backwards.
+
 **Linear state resolution is `type`-aware.** When a configured name is missing, a lifecycle skill may fall back to the team's states by `type` — `claimed`/`review` → the lowest-position `started`, `blocked` → `started` or `unstarted`, terminal `done` → `completed` — but only to *read*. **`ready` has no fallback on purpose:** every candidate would be the team's default unstarted state, which is exactly the inversion described above. A missing `ready` state is reported, never guessed; it must never invent a state to write into. Missing states are a setup defect, repaired by `/lisa:setup:linear`, not papered over at runtime.
 
 `blocked` is what every vendor agent flips to when triage finds unresolved ambiguities or the build path is blocked by something the agent can't resolve. Different from `claimed` because it explicitly signals "human attention required."

package/plugins/lisa/scripts/queue-contract-resolution.mjs

@@ -32,6 +32,24 @@ const DEFAULT_LINEAR_BUILD_DONE = {
   production: "Done",
 };
 
+// The state names a stock Linear team creates brand-new Issues into. `ready`
+// must name a lane a human moves an Issue INTO, so it may never be one of
+// these: the claimable lane would stop meaning "a human flipped this to
+// build-ready" and start meaning "nobody has touched this", and build-intake
+// would dispatch work nobody approved.
+//
+// This list is a STATIC backstop for the stock names, which is the case that
+// actually bit us. It cannot see a team that renamed its default — only the
+// live `Team.defaultIssueState` can, which is why `/lisa:validate-tracker-mapping`
+// carries the authoritative arm (`INVERTED`) and this one carries the arm that
+// needs no network and therefore always runs.
+const LINEAR_STOCK_DEFAULT_CREATED_STATES = [
+  "todo",
+  "to do",
+  "backlog",
+  "triage",
+];
+
 const DEFAULT_GITHUB_LINEAR_PRD_ROLES = {
   draft: "prd-draft",
   ready: "prd-ready",
@@ -272,6 +290,35 @@ export function resolvePrdLifecycleRoles(
   }
 }
 
+/**
+ * Reject a Linear `ready` override that names a state a stock team creates
+ * brand-new Issues into.
+ *
+ * Failing loudly is the safe direction. An operator staring at a hard error has
+ * a broken queue; an operator with a silently inverted gate has agents shipping
+ * work no human approved, which is the failure mode that produced this guard.
+ *
+ * @param {string} configured The resolved `linear.workflow.ready` name.
+ * @returns {string} The same name, once it is proven not to be a default lane.
+ * @throws {Error} When the name is a stock default created state.
+ */
+function assertLinearReadyIsNotDefaultState(configured) {
+  const normalized = configured.trim().toLowerCase();
+
+  if (!LINEAR_STOCK_DEFAULT_CREATED_STATES.includes(normalized)) {
+    return configured;
+  }
+
+  throw new Error(
+    `linear.workflow.ready is set to "${configured.trim()}", which is where Linear puts a ` +
+      "brand-new Issue. That inverts the build-ready gate: the claimable lane would mean " +
+      '"nobody has touched this" instead of "a human marked this ready", so intake would ' +
+      "claim untouched backlog items. Point linear.workflow.ready at a dedicated state a " +
+      "human moves Issues into (the default is `Ready`), then re-run /lisa:setup:linear to " +
+      "create it if the team does not have one."
+  );
+}
+
 /**
  * Resolve the build lifecycle roles for the configured tracker vendor.
  *
@@ -307,7 +354,9 @@ export function resolveBuildLifecycleRoles(
         vendor: "linear",
         kind: "workflow",
         roles: {
-          ready: config.linear?.workflow?.ready || "Ready",
+          ready: assertLinearReadyIsNotDefaultState(
+            config.linear?.workflow?.ready || "Ready"
+          ),
           claimed: config.linear?.workflow?.claimed || "In Progress",
           review: config.linear?.workflow?.review || "In Review",
           blocked: config.linear?.workflow?.blocked || "Blocked",

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

@@ -106,6 +106,40 @@ linear_graphql() {
 Map operation names to Linear GraphQL queries/mutations in this access skill.
 Consumers pass business-shaped arguments only; they do not embed GraphQL.
 
+## `list-workflow-states` — the team's states, and which one it creates into
+
+`list-workflow-states team:<ID>` returns one node per state with `id`, `name`,
+`type`, `position`, and **`isTeamDefault`**.
+
+`isTeamDefault` is `true` for the single state named by the team's
+`defaultIssueState` — where Linear puts every brand-new Issue. Callers need it to
+enforce the rule that `linear.workflow.ready` must be a lane a human moves an
+Issue **into**: pointing `ready` at the default inverts the gate, so the
+claimable lane means "nobody has touched this" rather than "a human marked this
+ready", and build-intake dispatches unapproved work. `/lisa:setup:linear` refuses
+to resolve `ready` onto it, and `/lisa:validate-tracker-mapping` classifies a
+config that already does as `INVERTED`.
+
+It belongs on this operation rather than in a separate `get-team` call because
+every caller that needs it is already enumerating states, and a second round trip
+is a second chance for the two answers to disagree. A team with no
+`defaultIssueState` set yields `isTeamDefault: false` on every node — report that
+honestly; do not fall back to guessing by name or position.
+
+```graphql
+query($teamId:String!){
+  team(id:$teamId){
+    defaultIssueState{ id }
+    states(first:100){ nodes{ id name type position } }
+  }
+}
+```
+
+Set `isTeamDefault` per node by comparing `node.id` against
+`team.defaultIssueState.id`. On the MCP substrate, which exposes states without
+the team's default, resolve the default through the team record and join on `id`
+the same way.
+
 ## `history` — transition history (read-only)
 
 `history id:<ID>` returns an Issue's ordered past state changes — the raw

package/plugins/lisa/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -71,7 +71,8 @@ Resolve the **effective** role → name mapping using the same defaults `/lisa:i
 - **Missing / empty tracker**: report `UNRESOLVABLE` with setup guidance (`/lisa:setup:jira`, `/lisa:setup:github`, or `/lisa:setup:linear`). Do not default to JIRA.
 - **JIRA build workflow** (`jira.workflow`): `ready`, `claimed`, optional `review`, `blocked`, and each `done.<env>` (`dev` / `staging` / `production`). Defaults: `Ready`, `In Progress`, `Code Review`, `Blocked`, `{dev: "On Dev", staging: "On Stg", production: "Done"}`.
 - **GitHub build/prd labels** (`github.labels.build`, `github.labels.prd`): each configured label string.
-- **Linear build/prd labels** (`linear.labels.build`, `linear.labels.prd`): each configured label/state string.
+- **Linear build workflow** (`linear.workflow`): `ready`, `claimed`, `review`, `blocked`, and each `done.<env>` — native workflow **states**, the Linear analogue of `jira.workflow`, not of `github.labels`. Defaults: `Ready`, `In Progress`, `In Review`, `Blocked`, `{dev: "On Dev", staging: "On Stg", production: "Done"}`.
+- **Linear labels** (`linear.labels`): the `prd.*` map plus the one surviving build-lane key, the `human_needed` marker (`linear.labels.build.human_needed`). A config that predates the state model may still carry `ready` / `claimed` / `blocked` / `done` under `linear.labels.build`; those are **inert** — nothing reads them. Do not audit them against the live label set, and do not report them as drift. Report them once as a migration note pointing at `/lisa:setup:linear`, which removes them.
 - **Notion PRD values** (`notion.values`): each configured select-option value, validated against the `notion.statusProperty` property's options.
 - **Confluence PRD parents** (`confluence.parents`): each configured parent page id, validated by existence.
 
@@ -103,7 +104,9 @@ gh label list --repo "$REPO" --limit 200 --json name -q '.[].name'
 
 ### Linear / Notion / Confluence
 
-Enumerate via the corresponding access surface (Linear MCP workflow states + labels; Notion data-source select options for `notion.statusProperty`; Confluence page-exists check per parent id). Same compare-exact-case contract as JIRA.
+Enumerate via the corresponding access surface (`lisa-linear-access` workflow states + labels; Notion data-source select options for `notion.statusProperty`; Confluence page-exists check per parent id). Same compare-exact-case contract as JIRA.
+
+For Linear, `lisa-linear-access operation: list-workflow-states` returns each state's `name`, `type`, `position` and `isTeamDefault` (the access layer sets it from the team's `defaultIssueState`). **Keep `isTeamDefault`** — Step 4 needs it, and it is the only authoritative answer to "which state does this team create Issues into". Do not approximate it with a name guess: `Todo` is merely the stock name, and a team that renamed its `defaultIssueState` is exactly the case a name guess misses.
 
 ## Step 4 — Compare (exact case)
 
@@ -113,10 +116,14 @@ For each `(role, configured-name)` pair, classify against the live name set:
 - **CASE_DRIFT** — a case-insensitive match exists but no exact-case match (e.g. config `"On Stg"` vs live `"ON STG"`). Canonical = the live exact name.
 - **MISSING** — no case-insensitive match exists. The name was renamed beyond recognition or deleted.
 
+One role carries a further check that name-existence cannot express:
+
+- **INVERTED** — Linear only, `ready` only: the configured state exists, but it is the team's **default created state** (`isTeamDefault`). This is worse than a name that does not resolve. The name resolves perfectly, so every existence check passes while the gate runs backwards: `ready` is supposed to mean "a human moved this Issue here", and the team's default means "nobody has touched this". Build-intake claims from that lane, so an INVERTED mapping dispatches work no human ever approved. Measured on the first team it hit: 20 Issues in the claimable lane, 12 never marked ready — including decision tickets shaped like leaves, which the leaf-only gate cannot catch either. Report it even when every other role is VALID.
+
 A project's verdict:
 
 - **VALID** — every role is VALID.
-- **DRIFTED** — at least one CASE_DRIFT or MISSING role, none of which is UNRESOLVABLE.
+- **DRIFTED** — at least one CASE_DRIFT, MISSING, or INVERTED role, none of which is UNRESOLVABLE. An INVERTED `ready` is never VALID, no matter how cleanly it resolves.
 - **UNRESOLVABLE** — the live set couldn't be enumerated (auth mismatch, missing tracker config, access failure). Distinguish this loudly from VALID — an unresolved audit is not a passing audit.
 
 ## Step 5 — Report
@@ -134,7 +141,17 @@ Per project, print a terminal-first section:
   done.production Done              Done                VALID
 ```
 
-End with a roll-up: counts of VALID / DRIFTED / UNRESOLVABLE projects and the exact next command (`… repair=true` when drift is auto-repairable; an admin note when a status is genuinely MISSING).
+An INVERTED `ready` gets a full line rather than a one-word status, because the operator reading it is not necessarily an engineer and the word alone does not convey the stakes:
+
+```
+  ready           Todo              Todo                INVERTED
+      "Todo" is the state this Linear team puts every NEW issue into, so the
+      build queue is currently claiming issues nobody marked ready. Pick or
+      create a state a person moves an issue into (Lisa's default is "Ready")
+      via /lisa:setup:linear, then set linear.workflow.ready to it.
+```
+
+End with a roll-up: counts of VALID / DRIFTED / UNRESOLVABLE projects and the exact next command (`… repair=true` when drift is auto-repairable; an admin note when a status is genuinely MISSING; `/lisa:setup:linear` when a `ready` is INVERTED).
 
 ## Step 6 — Repair (only when `repair=true`)
 
@@ -166,6 +183,18 @@ Compute the closest live candidates (case-insensitive token/substring overlap, t
 
 Only write on an explicit pick. Never auto-select. If the user leaves it unchanged, keep the project `DRIFTED` and surface the admin remediation (add the status back, or fix it in the tracker).
 
+### INVERTED — never auto-repair
+
+**Never auto-repair an INVERTED `ready`, even with `repair=true`.** Every other classification has one correct answer that the live tracker already knows: CASE_DRIFT has the canonical casing, MISSING has a shortlist of near-matches. INVERTED has neither. The configured name is live and correctly cased; what is wrong is which lane the project chose to mean "build-ready", and nothing in the config or the tracker records what the human intended instead. Guessing would silently repoint the queue at a lane that may hold nothing, or worse, at another lane the team fills automatically — swapping one wrong answer for a quieter one.
+
+The team may also genuinely not have a dedicated ready lane yet, in which case the repair is to **create a state**, not to rewrite a string — `/lisa:validate-tracker-mapping` audits config, it does not mutate the tracker.
+
+So: present the team's non-default states via `AskUserQuestion`, and write `linear.workflow.ready` only on an explicit pick. If none fits, or the user declines, leave the config untouched, keep the project `DRIFTED`, and hand off:
+
+> Linear has no dedicated build-ready state on this team. Run `/lisa:setup:linear` — it offers to create `Ready` and records the mapping.
+
+Until then, say plainly that the build queue is claiming unapproved work and that pausing build intake is the safe interim.
+
 ### Invalidate the verification cache
 
 After any JIRA repair, clear the `setup-jira` reachability cache so it re-verifies the new mapping:

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/scripts/queue-contract-resolution.mjs

@@ -32,6 +32,24 @@ const DEFAULT_LINEAR_BUILD_DONE = {
   production: "Done",
 };
 
+// The state names a stock Linear team creates brand-new Issues into. `ready`
+// must name a lane a human moves an Issue INTO, so it may never be one of
+// these: the claimable lane would stop meaning "a human flipped this to
+// build-ready" and start meaning "nobody has touched this", and build-intake
+// would dispatch work nobody approved.
+//
+// This list is a STATIC backstop for the stock names, which is the case that
+// actually bit us. It cannot see a team that renamed its default — only the
+// live `Team.defaultIssueState` can, which is why `/lisa:validate-tracker-mapping`
+// carries the authoritative arm (`INVERTED`) and this one carries the arm that
+// needs no network and therefore always runs.
+const LINEAR_STOCK_DEFAULT_CREATED_STATES = [
+  "todo",
+  "to do",
+  "backlog",
+  "triage",
+];
+
 const DEFAULT_GITHUB_LINEAR_PRD_ROLES = {
   draft: "prd-draft",
   ready: "prd-ready",
@@ -272,6 +290,35 @@ export function resolvePrdLifecycleRoles(
   }
 }
 
+/**
+ * Reject a Linear `ready` override that names a state a stock team creates
+ * brand-new Issues into.
+ *
+ * Failing loudly is the safe direction. An operator staring at a hard error has
+ * a broken queue; an operator with a silently inverted gate has agents shipping
+ * work no human approved, which is the failure mode that produced this guard.
+ *
+ * @param {string} configured The resolved `linear.workflow.ready` name.
+ * @returns {string} The same name, once it is proven not to be a default lane.
+ * @throws {Error} When the name is a stock default created state.
+ */
+function assertLinearReadyIsNotDefaultState(configured) {
+  const normalized = configured.trim().toLowerCase();
+
+  if (!LINEAR_STOCK_DEFAULT_CREATED_STATES.includes(normalized)) {
+    return configured;
+  }
+
+  throw new Error(
+    `linear.workflow.ready is set to "${configured.trim()}", which is where Linear puts a ` +
+      "brand-new Issue. That inverts the build-ready gate: the claimable lane would mean " +
+      '"nobody has touched this" instead of "a human marked this ready", so intake would ' +
+      "claim untouched backlog items. Point linear.workflow.ready at a dedicated state a " +
+      "human moves Issues into (the default is `Ready`), then re-run /lisa:setup:linear to " +
+      "create it if the team does not have one."
+  );
+}
+
 /**
  * Resolve the build lifecycle roles for the configured tracker vendor.
  *
@@ -307,7 +354,9 @@ export function resolveBuildLifecycleRoles(
         vendor: "linear",
         kind: "workflow",
         roles: {
-          ready: config.linear?.workflow?.ready || "Ready",
+          ready: assertLinearReadyIsNotDefaultState(
+            config.linear?.workflow?.ready || "Ready"
+          ),
           claimed: config.linear?.workflow?.claimed || "In Progress",
           review: config.linear?.workflow?.review || "In Review",
           blocked: config.linear?.workflow?.blocked || "Blocked",

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

@@ -106,6 +106,40 @@ linear_graphql() {
 Map operation names to Linear GraphQL queries/mutations in this access skill.
 Consumers pass business-shaped arguments only; they do not embed GraphQL.
 
+## `list-workflow-states` — the team's states, and which one it creates into
+
+`list-workflow-states team:<ID>` returns one node per state with `id`, `name`,
+`type`, `position`, and **`isTeamDefault`**.
+
+`isTeamDefault` is `true` for the single state named by the team's
+`defaultIssueState` — where Linear puts every brand-new Issue. Callers need it to
+enforce the rule that `linear.workflow.ready` must be a lane a human moves an
+Issue **into**: pointing `ready` at the default inverts the gate, so the
+claimable lane means "nobody has touched this" rather than "a human marked this
+ready", and build-intake dispatches unapproved work. `/lisa:setup:linear` refuses
+to resolve `ready` onto it, and `/lisa:validate-tracker-mapping` classifies a
+config that already does as `INVERTED`.
+
+It belongs on this operation rather than in a separate `get-team` call because
+every caller that needs it is already enumerating states, and a second round trip
+is a second chance for the two answers to disagree. A team with no
+`defaultIssueState` set yields `isTeamDefault: false` on every node — report that
+honestly; do not fall back to guessing by name or position.
+
+```graphql
+query($teamId:String!){
+  team(id:$teamId){
+    defaultIssueState{ id }
+    states(first:100){ nodes{ id name type position } }
+  }
+}
+```
+
+Set `isTeamDefault` per node by comparing `node.id` against
+`team.defaultIssueState.id`. On the MCP substrate, which exposes states without
+the team's default, resolve the default through the team record and join on `id`
+the same way.
+
 ## `history` — transition history (read-only)
 
 `history id:<ID>` returns an Issue's ordered past state changes — the raw

package/plugins/lisa-agy/skills/lisa-validate-tracker-mapping/SKILL.md

@@ -71,7 +71,8 @@ Resolve the **effective** role → name mapping using the same defaults `/lisa:i
 - **Missing / empty tracker**: report `UNRESOLVABLE` with setup guidance (`/lisa:setup:jira`, `/lisa:setup:github`, or `/lisa:setup:linear`). Do not default to JIRA.
 - **JIRA build workflow** (`jira.workflow`): `ready`, `claimed`, optional `review`, `blocked`, and each `done.<env>` (`dev` / `staging` / `production`). Defaults: `Ready`, `In Progress`, `Code Review`, `Blocked`, `{dev: "On Dev", staging: "On Stg", production: "Done"}`.
 - **GitHub build/prd labels** (`github.labels.build`, `github.labels.prd`): each configured label string.
-- **Linear build/prd labels** (`linear.labels.build`, `linear.labels.prd`): each configured label/state string.
+- **Linear build workflow** (`linear.workflow`): `ready`, `claimed`, `review`, `blocked`, and each `done.<env>` — native workflow **states**, the Linear analogue of `jira.workflow`, not of `github.labels`. Defaults: `Ready`, `In Progress`, `In Review`, `Blocked`, `{dev: "On Dev", staging: "On Stg", production: "Done"}`.
+- **Linear labels** (`linear.labels`): the `prd.*` map plus the one surviving build-lane key, the `human_needed` marker (`linear.labels.build.human_needed`). A config that predates the state model may still carry `ready` / `claimed` / `blocked` / `done` under `linear.labels.build`; those are **inert** — nothing reads them. Do not audit them against the live label set, and do not report them as drift. Report them once as a migration note pointing at `/lisa:setup:linear`, which removes them.
 - **Notion PRD values** (`notion.values`): each configured select-option value, validated against the `notion.statusProperty` property's options.
 - **Confluence PRD parents** (`confluence.parents`): each configured parent page id, validated by existence.
 
@@ -103,7 +104,9 @@ gh label list --repo "$REPO" --limit 200 --json name -q '.[].name'
 
 ### Linear / Notion / Confluence
 
-Enumerate via the corresponding access surface (Linear MCP workflow states + labels; Notion data-source select options for `notion.statusProperty`; Confluence page-exists check per parent id). Same compare-exact-case contract as JIRA.
+Enumerate via the corresponding access surface (`lisa-linear-access` workflow states + labels; Notion data-source select options for `notion.statusProperty`; Confluence page-exists check per parent id). Same compare-exact-case contract as JIRA.
+
+For Linear, `lisa-linear-access operation: list-workflow-states` returns each state's `name`, `type`, `position` and `isTeamDefault` (the access layer sets it from the team's `defaultIssueState`). **Keep `isTeamDefault`** — Step 4 needs it, and it is the only authoritative answer to "which state does this team create Issues into". Do not approximate it with a name guess: `Todo` is merely the stock name, and a team that renamed its `defaultIssueState` is exactly the case a name guess misses.
 
 ## Step 4 — Compare (exact case)
 
@@ -113,10 +116,14 @@ For each `(role, configured-name)` pair, classify against the live name set:
 - **CASE_DRIFT** — a case-insensitive match exists but no exact-case match (e.g. config `"On Stg"` vs live `"ON STG"`). Canonical = the live exact name.
 - **MISSING** — no case-insensitive match exists. The name was renamed beyond recognition or deleted.
 
+One role carries a further check that name-existence cannot express:
+
+- **INVERTED** — Linear only, `ready` only: the configured state exists, but it is the team's **default created state** (`isTeamDefault`). This is worse than a name that does not resolve. The name resolves perfectly, so every existence check passes while the gate runs backwards: `ready` is supposed to mean "a human moved this Issue here", and the team's default means "nobody has touched this". Build-intake claims from that lane, so an INVERTED mapping dispatches work no human ever approved. Measured on the first team it hit: 20 Issues in the claimable lane, 12 never marked ready — including decision tickets shaped like leaves, which the leaf-only gate cannot catch either. Report it even when every other role is VALID.
+
 A project's verdict:
 
 - **VALID** — every role is VALID.
-- **DRIFTED** — at least one CASE_DRIFT or MISSING role, none of which is UNRESOLVABLE.
+- **DRIFTED** — at least one CASE_DRIFT, MISSING, or INVERTED role, none of which is UNRESOLVABLE. An INVERTED `ready` is never VALID, no matter how cleanly it resolves.
 - **UNRESOLVABLE** — the live set couldn't be enumerated (auth mismatch, missing tracker config, access failure). Distinguish this loudly from VALID — an unresolved audit is not a passing audit.
 
 ## Step 5 — Report
@@ -134,7 +141,17 @@ Per project, print a terminal-first section:
   done.production Done              Done                VALID
 ```
 
-End with a roll-up: counts of VALID / DRIFTED / UNRESOLVABLE projects and the exact next command (`… repair=true` when drift is auto-repairable; an admin note when a status is genuinely MISSING).
+An INVERTED `ready` gets a full line rather than a one-word status, because the operator reading it is not necessarily an engineer and the word alone does not convey the stakes:
+
+```
+  ready           Todo              Todo                INVERTED
+      "Todo" is the state this Linear team puts every NEW issue into, so the
+      build queue is currently claiming issues nobody marked ready. Pick or
+      create a state a person moves an issue into (Lisa's default is "Ready")
+      via /lisa:setup:linear, then set linear.workflow.ready to it.
+```
+
+End with a roll-up: counts of VALID / DRIFTED / UNRESOLVABLE projects and the exact next command (`… repair=true` when drift is auto-repairable; an admin note when a status is genuinely MISSING; `/lisa:setup:linear` when a `ready` is INVERTED).
 
 ## Step 6 — Repair (only when `repair=true`)
 
@@ -166,6 +183,18 @@ Compute the closest live candidates (case-insensitive token/substring overlap, t
 
 Only write on an explicit pick. Never auto-select. If the user leaves it unchanged, keep the project `DRIFTED` and surface the admin remediation (add the status back, or fix it in the tracker).
 
+### INVERTED — never auto-repair
+
+**Never auto-repair an INVERTED `ready`, even with `repair=true`.** Every other classification has one correct answer that the live tracker already knows: CASE_DRIFT has the canonical casing, MISSING has a shortlist of near-matches. INVERTED has neither. The configured name is live and correctly cased; what is wrong is which lane the project chose to mean "build-ready", and nothing in the config or the tracker records what the human intended instead. Guessing would silently repoint the queue at a lane that may hold nothing, or worse, at another lane the team fills automatically — swapping one wrong answer for a quieter one.
+
+The team may also genuinely not have a dedicated ready lane yet, in which case the repair is to **create a state**, not to rewrite a string — `/lisa:validate-tracker-mapping` audits config, it does not mutate the tracker.
+
+So: present the team's non-default states via `AskUserQuestion`, and write `linear.workflow.ready` only on an explicit pick. If none fits, or the user declines, leave the config untouched, keep the project `DRIFTED`, and hand off:
+
+> Linear has no dedicated build-ready state on this team. Run `/lisa:setup:linear` — it offers to create `Ready` and records the mapping.
+
+Until then, say plainly that the build queue is claiming unapproved work and that pausing build intake is the safe interim.
+
 ### Invalidate the verification cache
 
 After any JIRA repair, clear the `setup-jira` reachability cache so it re-verifies the new mapping:

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "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.352.0",
+  "version": "2.353.0",
   "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.352.0",
+  "version": "2.353.0",
   "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.352.0",
+  "version": "2.353.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"