@codyswann/lisa 2.352.0 → 2.353.0

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.352.0",
+  "version": "2.353.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/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/src/base/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/src/base/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/src/base/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/typescript/copy-overwrite/scripts/check-nightly-e2e-health.mjs

@@ -6,7 +6,7 @@
  * `CodySwannGT/lisa/.github/workflows/nightly-e2e-health.yml`; the contract both
  * halves implement is `docs/nightly-e2e-gate.md` in Lisa, whose §2 truth table
  * is proven row-by-row by `tests/unit/scripts/nightly-e2e-health*.test.ts`
- * (rows 1-16, `-api` rows 17-20, `-bypass` rows 21-25).
+ * (rows 1-16, `-api` rows 17-20, `-bypass` rows 21-25, `-completeness` row 26).
  *
  * Usage:
  *   node scripts/check-nightly-e2e-health.mjs          # human report, exit 1 when blocked
@@ -38,6 +38,12 @@
  * An unreachable or rate-limited API is a HARD failure after a bounded retry;
  * there is no configuration that renders "we could not check" as "it is fine".
  *
+ * A `success` run is not automatically a fresh `success`, and since row 26 it is
+ * not automatically a COMPLETE one either: GitHub concludes a run `success` when
+ * jobs were skipped, so a suite narrowed to one platform — or one whose
+ * prerequisites were absent — reports green having tested nothing it was asked
+ * about. A run-scoped suite therefore reads the run's jobs as well.
+ *
  * The one forgiving state is the TIME-BOXED bootstrap window (`bootstrap_until`),
  * during which MISSING evidence is reported but does not block, always with its
  * expiry timestamp on screen. Bootstrap forgives absence of evidence, never
@@ -65,7 +71,7 @@ import { pathToFileURL } from "node:url";
  * rather than running a contract neither half agrees on. See §8 of
  * `docs/nightly-e2e-gate.md` for what counts as major / minor / patch.
  */
-export const NIGHTLY_E2E_CONTRACT_VERSION = "1.0.0";
+export const NIGHTLY_E2E_CONTRACT_VERSION = "1.1.0";
 
 /**
  * The conclusions that constitute a verdict about the code.
@@ -565,20 +571,75 @@ export function assessSuite(suite, observation, context) {
     };
   }
 
+  const jobs = observation.jobs ?? [];
+
   if (suite.match.mode === "run") {
     const state = stateForConclusion(run.conclusion);
+    if (state !== SUITE_STATES.pass) {
+      return {
+        ...base,
+        ...seen,
+        state,
+        reason:
+          state === SUITE_STATES.unknown
+            ? "indecisive_conclusion"
+            : "run_conclusion",
+      };
+    }
+
+    // Row 26 — COMPLETENESS. `mode: "run"` means the whole workflow IS the
+    // suite, so the run's own `success` is evidence only when every job behind
+    // it also succeeded.
+    //
+    // GitHub concludes a run `success` when jobs were SKIPPED. That is how a
+    // suite reports green having tested half of itself: the shipped
+    // `maestro-e2e.yml` caller exposes a `platform` dispatch picker, and
+    // `platform: android` leaves the iOS job skipped while the run still
+    // concludes `success`. Read as a run conclusion alone, that filtered
+    // dispatch cleared a required merge gate for an arm that never executed —
+    // propswap's trap, a suite declaring itself green on evidence it never
+    // gathered. The same shape reaches the CRON path: with
+    // `require_prerequisites: false` and no EXPO_TOKEN, every job skips and the
+    // run is still `success`.
+    //
+    // The discriminator is "was this run PARTIAL?", never "was this a
+    // dispatch?" — twice deliberately. The runs API exposes no `inputs` field,
+    // so the filter itself is unreadable; and a full unfiltered dispatch is the
+    // documented unblock path (§7), which must keep counting or the gate stops
+    // being escapable by FIXING.
+    //
+    // An EMPTY job list lands here too: a completed run always has at least one
+    // job, so an empty list is an unread job list, and "we could not check"
+    // never renders as "it is fine".
+    const shortfall = jobs.find(job => job.conclusion !== GREEN_CONCLUSION);
+    if (jobs.length === 0 || shortfall) {
+      const conclusion = shortfall?.conclusion ?? null;
+      return {
+        ...base,
+        ...seen,
+        // The RUN's `success` must not be printed beside a blocked state — the
+        // same self-contradiction the job-scoped modes refuse below.
+        conclusion,
+        url: shortfall?.html_url ?? seen.url,
+        // A skipped arm is ABSENCE of evidence, which bootstrap may forgive; a
+        // job that failed under `continue-on-error` inside a green run is
+        // EVIDENCE OF FAILURE, which it never may.
+        state:
+          stateForConclusion(conclusion) === SUITE_STATES.fail
+            ? SUITE_STATES.fail
+            : SUITE_STATES.unknown,
+        reason: "incomplete_run",
+      };
+    }
+
     return {
       ...base,
       ...seen,
-      state,
-      reason:
-        state === SUITE_STATES.unknown
-          ? "indecisive_conclusion"
-          : "run_conclusion",
+      state: SUITE_STATES.pass,
+      reason: "run_conclusion",
     };
   }
 
-  const jobs = observation.jobs ?? [];
   const matches =
     suite.match.mode === "job"
       ? jobs.filter(job => job.name === suite.match.name)
@@ -903,6 +964,8 @@ const REASON_TEXT = Object.freeze({
     "the run completed without ever producing the job this gate reads. The job was renamed, which silently disarms the gate.",
   pattern_matched_nothing:
     "the job pattern matched zero jobs in the newest run. Zero matches is the signature of a renamed job.",
+  incomplete_run:
+    "the run reported `success`, but it did not run everything: at least one job was skipped, failed under `continue-on-error`, or could not be read. A run that skipped part of itself did not gather the evidence its green claims — a suite re-run for one platform only is not a verdict about the other one. Re-run the suite WITHOUT narrowing it.",
   run_conclusion: "",
   job_conclusion: "",
 });
@@ -979,7 +1042,7 @@ export function formatReport(verdict, context) {
     lines.push(
       `Merges into \`${context.branch}\` are blocked until the nightly e2e suites are green again. To unblock:`,
       "  1. Fix the failure (open the run above — it names the failing spec or flow).",
-      `  2. Re-run the suite from the Actions tab against \`${context.branch}\`. A \`workflow_dispatch\` run counts exactly like a scheduled one, so a green dispatch clears this gate immediately — no waiting for tomorrow.`,
+      `  2. Re-run the suite from the Actions tab against \`${context.branch}\`, running the WHOLE suite. A \`workflow_dispatch\` run counts exactly like a scheduled one, so a green dispatch clears this gate immediately — no waiting for tomorrow. What does not count is a NARROWED re-run: leave any platform / tag / shard picker on its "all" default, because a run that skipped an arm says nothing about that arm.`,
       "  3. Re-run this check on your PR.",
       "",
       `If the failure is in the harness rather than the app — or this IS the PR that fixes the red nightly — a maintainer (not you) can apply the \`${context.bypassLabel}\` label after you add a \`Nightly-E2E-Bypass: <TICKET> <reason>\` line to the PR body. There is no admin-merge-past-red: the audited bypass is the only sanctioned path.`
@@ -1182,7 +1245,10 @@ export async function observe(api, suites, branch, wait) {
               : newest,
           null
         );
-      if (!run || suite.match.mode === "run") {
+      // Jobs are read for EVERY match mode, `run` included. A run-scoped suite
+      // needs them to prove the run was complete (row 26) — a `success` run
+      // that skipped half its jobs is not evidence about the half it skipped.
+      if (!run) {
         return { workflowMissing: false, run, jobs: [] };
       }
       return {