@codyswann/lisa 4.54.13 → 4.55.1

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

@@ -299,7 +299,7 @@ If the item modifies an existing user-facing surface, a `lisa-product-walkthroug
 Before create/update, verify each field is populated where applicable:
 
 - **Workflow state**: set the resolved `ready` state (`linear.workflow.ready`, default `Ready`) on a new **leaf** work unit (Bug / Task / Sub-task / Improvement with no child work) per `leaf-only-lifecycle`, **only on explicit `build_ready: true`** (see the Build-ready control input below). A container (Epic Project / Story with sub-issues / Spike) is never put in the build-ready state.
-- **Labels**: taxonomy only — `type:<Kind>`, `repo:<name>`, `component:<name>`, and the `prd-intake-feedback` sentinel. Lifecycle is **not** a label on Linear; do not add `status:*` labels.
+- **Labels**: taxonomy only — `type:<Kind>`, `repo:<name>`, `component:<name>`. Lifecycle is **not** a label on Linear; do not add `status:*` labels.
 - **Native priority field**: 0–4 per Linear's scale; explicit, not "unset".
 - **Native estimate**: per Linear's team-configured estimate scale (often 0–8 Fibonacci); skip for Epic / Spike.
 - **ProjectMilestone**: when the team uses dated milestones, set the milestone on the Project (Epic) or on the Issue (when an Issue belongs to a milestone).
@@ -334,6 +334,17 @@ person scanning a board and to any path that has not yet been routed through the
 If the label does not exist in the tracker, create it, or record that it could not be applied and
 proceed — the marker still holds. Never file the label *instead of* the marker.
 
+**Write a `reason=` the release can name.** The hold's reason is not decoration: a hold ends when a
+`[lisa-human-gate-release]` comment repeating that same `reason=` is recorded on the item, and the
+next intake sweep then takes the marker label off and puts the item back in the build-ready role on
+its own. Matching is per-reason so that a hold declared *after* an earlier release is not born
+discharged. A keyless hold is legal and is discharged by a keyless release; a hold whose reason is a
+paragraph is legal and nobody will reproduce it. Prefer a short slug the person answering it can
+retype. Do **not** instruct anyone to delete the marker from the description to lift the hold — the
+only body write available is a whole-body replacement, so that asks them to rewrite the whole record
+to clear one line, which is why answered holds accumulated instead of being lifted
+(CodySwannGT/lisa#3852). The marker stays as history; the release is recorded beside it.
+
 If a leaf arrives with `build_ready` omitted or `false` **and** no `human_gate`, do not create it: report the incomplete handoff and name both ways to resolve it (`build_ready: true`, or a `human_gate` reason). Containers are exempt — their state rolls up from children, so they need neither.
 
 ## Phase 5.5 — Validate (Pre-write Gate)
@@ -360,7 +371,7 @@ If the validator reports `PASS`, continue to Phase 6.
 
 ### CREATE — Story / Task / Bug / Spike / Improvement (Issue with projectId)
 
-1. Resolve any required Issue labels (`type:<Kind>`, `repo:<name>`, `component:<name>`, `prd-intake-feedback` only if this is a sentinel issue) via `lisa-linear-access operation: list-issue-labels` (create via `lisa-linear-access operation: create-issue-label` if missing). Separately, place a **leaf** work unit in the `ready` lane by passing `lifecycle_role: ready` on the create call below — and only on **explicit `build_ready: true`**, per the Build-ready control input below. Omit the role for a container, and for a leaf whose `build_ready` is `false` or omitted, which then waits in the team's default backlog state for a human to promote it. Ready is an explicit claim, never an omission's default. Never resolve a state ID here and pass it as `stateId`: the access layer resolves the configured `ready` state itself and refuses anything else.
+1. Resolve any required Issue labels (`type:<Kind>`, `repo:<name>`, `component:<name>`) via `lisa-linear-access operation: list-issue-labels` (create via `lisa-linear-access operation: create-issue-label` if missing). Separately, place a **leaf** work unit in the `ready` lane by passing `lifecycle_role: ready` on the create call below — and only on **explicit `build_ready: true`**, per the Build-ready control input below. Omit the role for a container, and for a leaf whose `build_ready` is `false` or omitted, which then waits in the team's default backlog state for a human to promote it. Ready is an explicit claim, never an omission's default. Never resolve a state ID here and pass it as `stateId`: the access layer resolves the configured `ready` state itself and refuses anything else.
 2. Call `lisa-linear-access operation: save-issue` with: `team` (teamId), `title` (summary), `description` (markdown), `projectId` (the Epic Project), `priority` (0–4), `estimate`, `labelIds`, `assignee` if known.
 3. Capture the returned identifier (e.g. `ENG-123`) — Phase 4 sub-tasks need it as `parentId`.
 4. Add relationships from Phase 4b via `save_issue` (relations field) or paired relation calls.
@@ -384,7 +395,7 @@ Call the `lisa-linear-verify` skill on the resulting item. `lisa-linear-verify`
 
 ## Phase 8 — Announce
 
-Post a creation comment via `lisa-linear-access operation: save-comment` (on the Issue, or on a sentinel issue under the Project for Epic-level announcements) with:
+Post a creation comment via `lisa-linear-access operation: save-comment` — `issue_id:<ID>` for an Issue, `project_id:<ID>` for an Epic-level announcement, which goes on the Project itself. Never create an Issue to carry a Project's announcement. The comment contains:
 
 - `[<repo>]` prefix if the item is repo-scoped
 - Who the item is assigned to (if known)
@@ -393,6 +404,46 @@ Post a creation comment via `lisa-linear-access operation: save-comment` (on the
 
 Skip this step only on UPDATE when no material change was made.
 
+## Writing by a bespoke path (your own script, direct API or GraphQL)
+
+Nothing here stops a consumer from writing to Linear through the Linear GraphQL API directly, a direct API call, or your own script, and nothing should
+try to — a script that owns the credential plumbing is often the only practical transport.
+**The transport is not the gate.** A bespoke write path still owes both halves of the quality
+gate this skill runs, and owes them explicitly, because no phase of this flow will ever run
+for it.
+
+A bespoke script's own read-back does not discharge either obligation. Re-reading the work item
+and confirming Linear stored what was sent **proves transport, not quality**: it shows the
+fields round-tripped and says nothing about whether what was sent clears a single gate. An
+agent that reads `VERIFIED` out of such a script has been told the work item was checked when it
+was not. Measured once, on one work item, on 2026-09-03 (CodySwannGT/lisa#3663): a local
+script's read-back was clean on every field, and the work item then failed gates S5, S9 and S18
+when the validator was run against it by hand.
+
+What a bespoke write path still owes — the same two checks, invoked by hand:
+
+1. **Pre-write validate**, the obligation Phase 5.5 discharges here. Invoke `lisa-linear-validate-issue` via
+   the Skill tool with the proposed spec as a YAML block **before** writing. Never write on a
+   `FAIL` verdict.
+2. **Post-write verify**, the obligation Phase 7 discharges here. Invoke `lisa-linear-verify` via the
+   Skill tool with the identifier of the work item you just wrote — or `lisa-linear-validate-issue` directly in
+   identifier mode, which fetches and validates the live state. Never report success on a
+   `FAIL` verdict.
+
+Both run standalone against an existing live work item; `lisa-linear-validate-issue` documents the copy-pasteable
+invocation under its standalone entry point.
+
+**Three outcomes, never two.** `PASS`, `FAIL` and *could not validate* are distinct results.
+If the validator did not run to a verdict — the skill was unavailable, a credential was
+missing, the work item could not be fetched — that is **not** a pass. Report it as unvalidated and
+say why. Collapsing "could not validate" into "validated" is the same misreading as trusting
+a read-back.
+
+**These are skills, not scripts.** `lisa-linear-validate-issue` and `lisa-linear-verify` are plugin-resident and invoked
+through the Skill tool. They are **not** expected to appear in any repository's `scripts/`
+directory, and their absence from one is not evidence that the capability is missing —
+searching the repository you happen to be standing in is the wrong search.
+
 ## Rules
 
 - Never create a non-Epic, non-top-level item without a parent context (Project for Stories, parentId for Sub-tasks).

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

@@ -50,7 +50,7 @@ Per-ticket gates (`lisa-jira-validate-ticket`) prove each created ticket is well
    - **GitHub**: enumerate native sub-issues via `gh api graphql` (`subIssues` field), then `gh issue view <child-num> --json body,comments` per child. Recurse to depth 3.
    The audit walks the full PRD tree.
 4. If `tickets=[...]` not provided, locate the destination Epic by:
-   - Looking for a destination URL in the PRD body, comments, or the PRD's most recent "Ticketed by Claude" comment posted by `lisa-notion-prd-intake` / `lisa-confluence-prd-intake` / `lisa-linear-prd-intake` / `lisa-github-prd-intake` (for Linear, this comment lives on the project's sentinel feedback issue; for the others, it lives on the PRD page / issue itself).
+   - Looking for a destination URL in the PRD body, comments, or the PRD's most recent "Ticketed by Claude" comment posted by `lisa-notion-prd-intake` / `lisa-confluence-prd-intake` / `lisa-linear-prd-intake` / `lisa-github-prd-intake` (for every vendor, this comment lives on the PRD page / project / issue itself).
    - Searching the destination tracker via `lisa-tracker-read` (or directly via `searchJiraIssuesUsingJql` / `gh issue list --search`) for an epic whose summary or description references the PRD title or project ID.
    - If no epic found, return verdict `NO_TICKETS_FOUND` with a clear remediation — coverage cannot be assessed without the ticket set.
 5. Once the epic is known, fetch all child stories and sub-tasks:
@@ -174,7 +174,7 @@ Atomic PRD items extracted: <n>
 ### Scope-creep count: <n>
 ```
 
-`prd_anchor` and `prd_section` are built the same way as in `lisa-notion-to-tracker` / `lisa-confluence-to-tracker` / `lisa-linear-to-tracker` / `lisa-github-to-tracker`. For Notion, `prd_anchor` is the `selection_with_ellipsis` start/end snippet; for Confluence, it's the inline-comment selection text accepted by `createConfluenceInlineComment`; for Linear, it's a sub-issue identifier (e.g. `LIN-123`) when the gap maps to a specific issue, otherwise `null` (the caller posts unanchored Linear gaps on the project's sentinel feedback issue); for GitHub, it's the section heading from the PRD issue body when the gap traces to a specific section, otherwise `null` (the caller approximates inline anchoring by quoting a body excerpt at the top of the comment). The downstream caller knows which vendor it's writing to and uses the right API; this skill just emits the anchor that vendor expects.
+`prd_anchor` and `prd_section` are built the same way as in `lisa-notion-to-tracker` / `lisa-confluence-to-tracker` / `lisa-linear-to-tracker` / `lisa-github-to-tracker`. For Notion, `prd_anchor` is the `selection_with_ellipsis` start/end snippet; for Confluence, it's the inline-comment selection text accepted by `createConfluenceInlineComment`; for Linear, it's a sub-issue identifier (e.g. `LIN-123`) when the gap maps to a specific issue, otherwise `null` (the caller posts unanchored Linear gaps as a project-level comment); for GitHub, it's the section heading from the PRD issue body when the gap traces to a specific section, otherwise `null` (the caller approximates inline anchoring by quoting a body excerpt at the top of the comment). The downstream caller knows which vendor it's writing to and uses the right API; this skill just emits the anchor that vendor expects.
 
 `category` is drawn from the same fixed taxonomy used by `lisa-jira-validate-ticket` so downstream callers can apply one consistent comment-formatting policy. Most coverage gaps map to `scope` (item not represented in any ticket) or `product-clarity` (item too vague to map). Use `acceptance-criteria` for missing pass/fail conditions and `design-ux` for missing visuals.
 

package/plugins/lisa/.codex-plugin/skills/lisa-qa-clear/SKILL.md

@@ -46,9 +46,20 @@ Read `.lisa.config.json`:
       `[lisa-qa-clear] Certified without human QA: scope is <repo(s)>, not observable
       with end-user access. Verified by the automated lifecycle pre-promotion.`
    2. Then transition to the certified status.
-   3. Verify both halves landed before counting the ticket as moved. A comment without
-      the transition, or a transition without the comment, is a **partial** — report it
-      as such, never as completed.
+   3. Then clear the QA-failure **signal**, because certifying is one of its two void
+      conditions and this is the second path that reaches it:
+
+      ```bash
+      RESOLVER="${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/qa-signal-lifecycle.mjs"
+      SIGNAL=$(node "$RESOLVER" --vendor "<jira|linear|github>" --print-label)
+      ```
+
+      Remove `$SIGNAL` through the same tracker surface that applied it. Removing a label
+      the ticket does not carry is a no-op, so this runs unconditionally. The
+      `[lisa-qa-fail]` comments are never touched — the history stays, the signal goes.
+   4. Verify all three landed before counting the ticket as moved. A comment without
+      the transition, a transition without the comment, or a certified ticket still
+      wearing the signal is a **partial** — report it as such, never as completed.
 5. Report the batch:
 
 ```text
@@ -68,7 +79,8 @@ marks exactly what was auto-cleared.
 - Never bulk-move on an inferred repo list without explicit operator confirmation.
 - Every cleared ticket carries the audit comment; a transition without the comment is a
   bug in this procedure.
-- Idempotent by repair, not by skip: a ticket is complete only when it has BOTH the
-  `[lisa-qa-clear]` comment AND the certified status. Re-runs finish partials — comment
-  present but not certified → transition it; certified but no comment → post the
-  comment. Only fully-complete tickets are skipped silently.
+- Idempotent by repair, not by skip: a ticket is complete only when it has the
+  `[lisa-qa-clear]` comment, the certified status, AND no QA-failure signal. Re-runs
+  finish partials — comment present but not certified → transition it; certified but no
+  comment → post the comment; certified but still signalled → clear the signal. Only
+  fully-complete tickets are skipped silently.

package/plugins/lisa/.codex-plugin/skills/lisa-qa-fail/SKILL.md

@@ -71,10 +71,32 @@ not smoothed over.
 For `not-covered-by-ac`, do NOT transition the ticket — the spec question goes to the
 human product gate. Flag it in the response and stop after posting.
 
-## Phase 4 — Label and transition
+## Phase 4 — Signal and transition
 
-1. Apply the `qa-fail` label — this is the deterministic rework signal `lisa-rework-triage`
-   keys on at next claim, and the gap classification above becomes its primary evidence.
+1. Apply the QA-failure **signal** label. Resolve its name — never hardcode one:
+
+   ```bash
+   SIGNAL=$(node "${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/qa-signal-lifecycle.mjs" \
+     --vendor "<jira|linear|github>" --print-label)   # `qa.labels.fail`, default `qa-fail`
+   ```
+
+   This is the deterministic rework signal `lisa-rework-triage` keys on at next claim, and
+   the gap classification above becomes its primary evidence.
+
+   The signal is **transient, and it says so.** Two void conditions lift it, both with an
+   executable predicate in `scripts/qa-signal-lifecycle.mjs`: a later QA pass verdict
+   (`qa-pass-recorded`), or the item reaching the certified or a terminal role
+   (`certified-role-reached`). `lisa-qa-queue` clears it on the pass path and `lisa-qa-clear`
+   clears it when it certifies without a human, so the clear path is as reachable as this
+   one. Record that in the comment so nobody has to infer it:
+
+   ```text
+   Signal: <label> — voided by a later QA pass, or by reaching the certified/terminal role.
+   ```
+
+   What is durable is the **history**: this `[lisa-qa-fail]` comment is never rewritten or
+   removed, so "failed QA twice before shipping" stays readable after the label is gone.
+   The label is the machine-read signal; the comment is the record.
 2. Transition the ticket to the build-ready status (`jira.workflow.ready`, or the
    configured tracker's equivalent ready label/state when `tracker` is GitHub or
    Linear). The rework loop takes it from here: intake claims it, `lisa-ticket-triage` Phase 2.5 runs
@@ -92,3 +114,6 @@ human product gate. Flag it in the response and stop after posting.
 - The expectation gap must cite a specific evidence artifact or say `no-evidence-found` —
   a gap classification without a citation is a guess, and guesses are worse than
   `no-evidence-found`.
+- Never apply a signal whose clear path you cannot name. A durable mark with no inverse is
+  a defect class of its own (`state-changes-without-inverses`): it stays correct at the
+  moment it fires and becomes wrong by outliving what it described.

package/plugins/lisa/.codex-plugin/skills/lisa-qa-queue/SKILL.md

@@ -45,9 +45,32 @@ Read `.lisa.config.json`:
 
 ## Recording the verdict
 
-- **Pass** — transition the ticket to the certified status via the tracker access layer,
-  post a brief `[lisa-qa-queue] QA pass` comment naming who verified and when, and offer
-  the next item.
+- **Pass** — three writes, in this order, and the pairing must be failure-safe exactly as
+  `lisa-qa-clear`'s is:
+  1. Post a brief `[lisa-qa-queue] QA pass` comment naming who verified and when. The
+     literal marker matters: it is the `qa-pass-recorded` void condition's evidence.
+  2. Transition the ticket to the certified status via the tracker access layer.
+  3. **Clear the QA-failure signal.** A pass is the inverse of a fail, and until this runs
+     an item that failed once reads as failing forever to `lisa-rework-triage`:
+
+     ```bash
+     RESOLVER="${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/qa-signal-lifecycle.mjs"
+     SIGNAL=$(node "$RESOLVER" --vendor "<jira|linear|github>" --print-label)
+     ```
+
+     Remove `$SIGNAL` from the item through the same tracker surface that applied it —
+     `gh issue edit <n> --remove-label "$SIGNAL"` on GitHub, the label-update mutation on
+     Linear, the `update.labels[].remove` field on JIRA. Removing a label the item does not
+     carry is a no-op on every tracker, so this is safe to run unconditionally.
+
+  Verify all three landed before reporting the pass. A transition without the signal
+  cleared is a **partial** — report it as such and finish it, never count it as complete.
+
+  The failure **history** is untouched: the `[lisa-qa-fail]` comments stay exactly as
+  written. Only the machine-read signal is voided, so "this failed QA twice before
+  shipping" remains readable while "this is failing QA" stops being asserted.
+
+  Then offer the next item.
 - **Fail** — invoke `lisa-qa-fail` with the ticket key and the tester's own words
   (verbatim — do not paraphrase away detail; attach any screenshots they provided). That
   skill owns the failure report, the expectation-gap diagnosis, the `qa-fail` label, and
@@ -63,6 +86,8 @@ Read `.lisa.config.json`:
 - One ticket at a time — never dump the queue on the tester.
 - The tester's verbatim description is evidence; preserve it exactly in whatever is posted.
 - Never transition to certified without an explicit "pass" from the tester.
+- Never certify without clearing the QA-failure signal. The clear path must stay as
+  reachable as the path that applied it (`state-changes-without-inverses`).
 - All tracker writes go through the access layer / `lisa-qa-fail` — this skill never
   hand-crafts tracker mutations beyond the pass transition and its comment.
 - Session summary on request ("how did we do?"): counts of passed / failed / blocked /

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

@@ -188,6 +188,7 @@ In addition to the lifecycle roles above, the build lifecycle defines the **`hum
 
 - The blocks repair-intake **itself writes** are the auto-recoverable kind — it files a build-ready fix ticket and moves the item `blocked` *blocked by that ticket*, expecting the next cycle to self-heal. Those are **not** `human_needed`; if such an item arrives carrying a `human_needed` marker **this skill applied on an earlier cycle**, repair-intake **clears** it (the block is no longer waiting on a human).
 - **Never remove a `human_needed` marker this skill did not apply.** "Stale" is a judgment about the block's kind, not about who applied the marker or when — so without this rule an operator's deliberate hold, applied *after* correcting a wrong transition, is indistinguishable from a leftover the sweep is designed to clear, and gets swept. Establish provenance from the label event's actor (`rejection-detection` **Automation-reversal memory** reads the same surfaces); if provenance is not readable, **leave the marker in place**. Removing a human's hold is unrecoverable within the loop; leaving a stale one costs a cycle and is visible.
+- **The one exception is a hold that has recorded its own discharge.** A `[lisa-human-gate-release]` comment naming the hold's `reason=` is not a guess about provenance — it is the hold's stated void condition, recorded on the item by the person who answered it. Clearing the marker there is not overriding a human's judgment; it is *enacting* it. That is the whole of the exception: no other reading of "this looks stale" reopens the question above, and an item whose release cannot be read stays held. See "Release the holds that have been answered" below (#3852).
 - The marker is consulted **before **any** repair transition**, not only before Class C. Class C's hard stop is the strictest reading of it, but a marker that is honoured on one classification path and ignored on the other three is not a guard — and Class A, dependency clearing, is exactly the path an operator reverting a wrongly-cleared blocker is trying to protect. Match it robustly (hyphen/underscore, case-insensitive, label set and note prose) wherever it is read.
 - The blocks the **vendor agent** writes when repair-intake re-dispatches it (its pre-flight gate) carry `human_needed` already — the agent owns that marker. repair-intake leaves it in place.
 
@@ -218,7 +219,7 @@ intakes use. Never call Atlassian MCP or `acli` directly — go through `lisa-at
 | Linear (build) | Linear MCP `list_issues` / `get_issue` / `list_comments` | Linear MCP `save_issue` (labels) / `save_comment` | `lisa-linear-agent` |
 | Notion (PRD) | `lisa-notion-access` (`query`, page comments) | `lisa-notion-access` `write-page` (status) / page comment | `lisa-notion-to-tracker` (dry-run) |
 | GitHub (PRD) | `gh issue list/view` (PRD labels) / GraphQL sub-issues / generated-work section | `gh issue edit` / `gh issue comment` / `gh issue close --reason completed` | `lisa-github-to-tracker` (dry-run) |
-| Linear (PRD) | Linear MCP `list_projects` / `get_project` (+ sentinel feedback issue) | Linear MCP `save_project` (labels) / `save_comment` | `lisa-linear-to-tracker` (dry-run) |
+| Linear (PRD) | `lisa-linear-access` `list-projects` / `get-project` / `list-comments project_id` | `lisa-linear-access` `save-project` (labels) / `save-comment project_id` | `lisa-linear-to-tracker` (dry-run) |
 | Confluence (PRD) | `lisa-atlassian-access` CQL | `lisa-atlassian-access` page `parentId` update / comment | `lisa-confluence-to-tracker` (dry-run) |
 
 ## Staleness model
@@ -267,8 +268,9 @@ exposes, and compare it to `now - stale_after`:
 1. Provider-native status/label **transition** time into the in-progress role, when the provider
    exposes it cleanly (JIRA changelog transition to `claimed` / In Progress, GitHub label event,
    Linear state/label history, Notion/Confluence page move/status history).
-2. Latest human lifecycle/progress **comment** or edit on the item (and, for Linear PRDs, the
-   sentinel feedback issue). Exclude automation self-comments and Lisa audit markers such as
+2. Latest human lifecycle/progress **comment** or edit on the item (for Linear PRDs, the
+   project's own comments via `list-comments project_id`, plus any legacy sentinel feedback
+   issue for projects that predate project-level comments). Exclude automation self-comments and Lisa audit markers such as
    `[claude-build-intake]`, `[codex-build-intake]`, `[lisa-build-intake]`, and
    `[lisa-repair-intake]`.
 3. For build items, latest **PR-side forward-progress activity** on the linked PR: newest commit,
@@ -466,25 +468,49 @@ branch — operate on it the same way.
 
 **4. Classify as a blocker.** Treat any of these as a real external blocker:
 
-- **True merge conflict** — `gh pr update-branch` (step 3) reported a conflict, or
-  `git merge-tree --write-tree origin/<base> <head>` exits non-zero. A
-  merely `BEHIND` branch is **not** here — it was re-synced in step 3. Unlike the other classes below, a
-  conflict is **resolvable by re-running the build**, so step 5 gives it one in-place re-dispatch before
-  filing — see its conflict-first rule.
-
-  **`mergeable = CONFLICTING` and `mergeStateStatus = DIRTY` are hints that
-  START this check, never the verdict that ends it.** Both are cached
-  computations that go stale — measured, GitHub reported `DIRTY` for two
-  branches at the same moment while only one actually conflicted, and a single
-  response has carried `MERGEABLE` and `DIRTY` together
-  (CodySwannGT/lisa#3694). Confirm with `merge-tree` before classifying, and
-  say in the run summary which answer you acted on.
-
-  **This class matters more here than in `lisa-drive-pr-to-merge`.** There a
-  spurious `DIRTY` costs a wasted resolve, which a human sees. Here it files a
-  BLOCKER against a pull request with nothing wrong with it, unattended — so
-  the wrong answer becomes durable tracker state that a later cycle reads as
-  fact. Verify before filing, never after.
+- **True merge conflict** — confirmed by a **merge trial**, never by a cached field.
+  `mergeable = CONFLICTING` and `mergeStateStatus = DIRTY` are hints that say *go look*: both are
+  computed asynchronously, and a stale one is served often enough that GitHub reported `DIRTY` for two
+  branches at the same moment while only one of them actually conflicted (#3694). Re-derive from
+  primary evidence at the moment of asking:
+
+  ```sh
+  base=$(gh pr view <pr> --json baseRefName --jq .baseRefName)
+  head=$(gh pr view <pr> --json headRefOid --jq .headRefOid)
+  git fetch --quiet origin "$base" "pull/<pr>/head" || readable=no
+  git rev-parse --verify --quiet "origin/$base^{commit}" >/dev/null || readable=no
+  git rev-parse --verify --quiet "$head^{commit}" >/dev/null || readable=no
+  out=$(git merge-tree --write-tree "origin/$base" "$head" 2>/dev/null); code=$?
+  ```
+
+  `merge-tree --write-tree` merges into the object store only — no working tree, no index and no
+  branch is touched — so it is safe inside an unattended scanner.
+
+  **Read the exit code together with stdout; the exit code alone cannot separate the three states.**
+  Measured on git 2.53.0: a trial naming a ref that does not exist exits `1`, the same code a genuine
+  conflict returns, printing nothing on stdout and `merge-tree: <ref> - not something we can merge`
+  on stderr. A trial that ran always prints the resulting tree OID on its first line; one that could
+  not run prints nothing. Three states, and the third is not optional:
+
+  - `code == 1` **and** `$out` non-empty → **CONFLICTED**. A real external blocker. Unlike the other
+    classes below, a conflict is **resolvable by re-running the build**, so step 5 gives it one
+    in-place re-dispatch before filing — see its conflict-first rule.
+  - `code == 0` → **CLEAN**. Not a blocker, whatever the API said. Write nothing, leave the item
+    `claimed`, and let a later cycle re-ask.
+  - `readable=no`, `$out` empty, or any other exit → **NOT DETERMINED**. The trial could not run — an
+    unresolvable ref, an unreachable remote, a git older than 2.38 — which is an absence of evidence,
+    not a verdict. Write nothing, file nothing, leave the item `claimed`, and record it as
+    `not_determined` in the run summary so a later cycle re-asks.
+
+  A `gh pr update-branch` (step 3) that reported a conflict it cannot apply also counts as
+  CONFLICTED — that is a merge actually attempted, not a cached answer. A merely `BEHIND` branch is
+  **not** here — it was re-synced in step 3.
+
+  **Filing on a cached field is the expensive direction here.** In a fix-mode loop a false
+  CONFLICTED wastes a resolve, which a human sees; in this scanner it files a
+  BLOCKER against a pull request that has nothing wrong with it, unattended — so the wrong answer
+  becomes durable tracker state that a later cycle reads as fact, and intake will keep doing that
+  without anyone noticing. Verify before filing, never after.
 - **Failing required checks** — `statusCheckRollup` has a `FAILURE`/`ERROR`/`TIMED_OUT` conclusion,
   or `mergeStateStatus = UNSTABLE`/`BLOCKED` due to checks.
 - **Change requests outstanding** — `reviewDecision = CHANGES_REQUESTED`, or unresolved CodeRabbit
@@ -905,8 +931,8 @@ intake runs per item**, targeted at this single PRD and **skipping the claim** (
 ### PRD `blocked` → re-validate if new answers exist
 
 1. Determine whether **new clarifying answers** exist: any comment/update on the PRD newer than
-   the last `[lisa-repair-intake]` note or the original `blocked` note. For Linear include the
-   sentinel feedback issue and anchored sub-issue comments; for Confluence include inline/footer
+   the last `[lisa-repair-intake]` note or the original `blocked` note. For Linear include the project's own
+   comments, anchored sub-issue comments, and any legacy sentinel feedback issue; for Confluence include inline/footer
    comments where the access layer exposes them; for Notion include page comments and
    `last_edited_time`.
 2. If new answers exist → run the `lisa:<source>-to-tracker` dry-run validate→route pipeline as
@@ -1023,6 +1049,50 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    substring match whose precision is a separate open defect (#3815). Refusing and reporting is
    the safe failure direction without the latch. Count these under `held_for_person`, never under
    `normalized_ready`.
+
+   **Pass the item's `comments`.** The planner reads a recorded `[lisa-human-gate-release]` comment
+   as the discharge of the hold naming the same `reason=`, and an item read without its comments is
+   an item whose discharge cannot be seen. That fails closed — it stays held — which is the safe
+   direction and precisely why the omission is invisible.
+
+2b. **Release the holds that have been answered.** This is step 2a's inverse and it is the reason
+   this sweep is where it lives: applying a hold had a path and lifting one had none, so a person
+   could supply exactly what a held item asked for, record the decision on the item, and the item
+   stayed held forever (CodySwannGT/lisa#3852). The expensive part — getting a person's attention,
+   framing the question, obtaining a judgment — was already paid for, and the system discarded the
+   answer.
+
+   Enumerate items carrying the configured `human_needed` marker **or** a `[lisa-human-gate]` marker
+   in the body, and for each call
+   `planHumanGateRelease({ labels, body, comments, humanNeededLabel, readyLabel, lifecycleLabels, alreadyNotified })`
+   from `scripts/intake-blocker-reprobe.mjs`. Apply exactly the actions it returns: remove the
+   human-needed marker, add the configured build `ready` label back, and post
+   `formatHumanGateReleaseNote()` once. Do **not** re-implement the discharge test, and do **not**
+   decide it from labels alone — the hold and its release are body and comment surfaces.
+
+   Three refusals make this safe to run on every cycle, and each one is in the planner rather than
+   in this prose so it cannot drift:
+
+   - **Still held plans nothing.** Every outstanding reason holds the whole item; an item whose
+     second question is unanswered is not half-released.
+   - **Never held plans nothing.** Without that this would be a path that adds the build-ready role
+     to arbitrary items — a promotion mechanism wearing a release mechanism's name.
+   - **An item that has moved on is not dragged back.** The ready role is restored only when the
+     item carries no other configured lifecycle label.
+
+   This is a genuine exception to "never remove a `human_needed` marker this skill did not apply",
+   and the exception is narrow enough to state exactly: provenance is the wrong question when the
+   *hold itself* names the condition that voids it and that condition is recorded. The general rule
+   stands because "stale" is otherwise a judgment about the block's kind; here nothing is being
+   judged — a release naming the hold's own reason is on the item, or it is not.
+
+   **Never edit a description to clear a hold**, here or anywhere. The only body write this plugin
+   has is a whole-body replacement, so deleting one line means rewriting the record and hoping
+   nothing was dropped. That is why holds accumulated: each individual release was a small gamble
+   with a large downside. The hold note stays in the body as history; the release is a comment
+   beside it. Count these under `released_to_queue`, and name them in the cycle summary via
+   `summarizeHumanGateReleases([...])` — printed even when it is zero, because a release path that
+   has stopped working and a cycle with nothing to release read identically otherwise.
 3. Classify the issue:
    - **PRD** if it has PRD labels/markers (`prd`, `type:PRD`, `kind:prd`), PRD structure
      (`## Problem`, `## Goals`, `## Validation Journey`, generated-work/backlink sections), or

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

@@ -41,8 +41,34 @@ first-attempt work.
    comment posted by `lisa-tracker-evidence` (`[lisa-evidence]` / the vendor evidence
    header). Only markers proving a prior *implementation* attempt qualify —
    `[lisa-rework-triage]` comments and other unrelated `[lisa-*]` annotations never do.
-4. **Explicit rework marker.** A `rework`, `qa-fail`, or `regression` label applied by QA or
-   the verify lifecycle.
+4. **Explicit rework marker.** A `rework` or `regression` label applied by QA or the verify
+   lifecycle, or a **live** QA-failure signal.
+
+   The QA-failure signal is transient, so its bare presence is not the signal — its
+   liveness is. Ask the resolver, never the label list:
+
+   ```bash
+   RESOLVER="${CLAUDE_PLUGIN_ROOT:-${PLUGIN_ROOT:-plugins/lisa}}/scripts/qa-signal-lifecycle.mjs"
+   node "$RESOLVER" --vendor "<jira|linear|github>" --item bundle.json
+   # bundle.json: { "labels": [...], "comments": [<bodies, oldest first>], "role": "<current>" }
+   ```
+
+   Branch on `action`, never on the label being there:
+
+   | `outcome` | Meaning | What triage does |
+   |---|---|---|
+   | `live` | the failure is unresolved | signal 4 fires — this is rework |
+   | `stale` | a later QA pass, or the certified/terminal role, voided it | signal 4 does **not** fire; **remove the label** (same tracker surface that applied it) and note the repair in the triage comment. Keep evaluating signals 1–3 |
+   | `absent` | no signal | signal 4 does not fire |
+   | `unchecked` | a declared void condition has no predicate | treat as `live` and surface it — a control nothing can evaluate is a defect to report, not an exemption |
+
+   Clearing a stale signal here is the repair path for items labelled before the signal had
+   an inverse; without it that backlog never drains. The `[lisa-qa-fail]` comments are the
+   history and are never touched — a stale signal removed still leaves the failure fully
+   readable, and signal 3 still reads those comments.
+
+   `rework` and `regression` are matched on presence as before. Whether they have the same
+   shape is **unverified** and not claimed here.
 
 Record which signal fired — it is part of the evidence trail.
 
@@ -170,3 +196,7 @@ which blocks per the normal triage rules.
   bypass the quality gates this loop exists to strengthen.
 - Noise discipline: one triage comment per bounce (fingerprinted), no upstream issue without
   the dedupe search, and upstream issues describe failure *classes*, not single incidents.
+- Never key on a durable mark whose inverse you have not checked. A signal with no expiry
+  degrades toward meaning "this item has been around a while"
+  (`state-changes-without-inverses`), and a deterministic input that degrades is
+  deterministically wrong.

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

@@ -13,7 +13,7 @@ The two lifecycles run on different primitives, and conflating them is the most
 - **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`).
+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. Every PRD-lifecycle label this skill creates is a **project** label; the PRD flow needs no issue label at all, because clarifying-question comments go on the project itself (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.
 
@@ -280,7 +280,7 @@ Probe with `lisa-linear-access operation: list-project-labels`. Create missing o
 | `ticketed` | `prd-ticketed` | project label |
 | `shipped` | `prd-shipped` | project label |
 | `verified` | `prd-verified` | project label |
-| `sentinel` | `prd-intake-feedback` | **issue** label (marks the sentinel feedback issue — create via `create_issue_label`) |
+| `sentinel` | `prd-intake-feedback` | **Legacy, not created.** An issue label that marked the fabricated feedback issues earlier versions used before project-level comments were wired up. Configured only so the rollup can recognise and exclude an existing one; a fresh workspace never needs it |
 
 #### 3c. Handle name collisions / renames
 
@@ -357,7 +357,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 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.
+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`) 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
 
@@ -369,7 +369,7 @@ Confirm what was scaffolded is present: `list-workflow-states` for every build r
 
 - Never write the API key to `.lisa.config.json`. It stays in keychain or `LINEAR_API_KEY`.
 - Never accept the API key via this skill's stdin/chat — always the platform clipboard-pipe pattern, so the value never enters the LLM context.
-- Never conflate the two label kinds: build labels are **issue** labels, PRD labels are **project** labels. The sentinel is an issue label. Creating the wrong kind silently breaks the corresponding intake flow.
+- Never conflate the two label kinds: build labels are **issue** labels, PRD labels are **project** labels. Creating the wrong kind silently breaks the corresponding intake flow.
 - Never create a duplicate label for a role that already has a (differently-named) label — map and record an override instead.
 - Never set `tracker` / `source` without explicit confirmation — they're project-wide switches.
 - Never invent a workspace slug or team key. Derive from the validated identity / team list and confirm; if resolution fails, ask the user.

package/plugins/lisa/.codex-plugin/skills/lisa-track/SKILL.md

@@ -78,5 +78,5 @@ Otherwise:
 - Branch setup may call `node scripts/lisa-work-item.mjs attach-branch` after the feature branch exists.
 - Keep the binding across ordinary interruptions and blocked outcomes so resumed work remains attributable.
 - Clear it only after true terminal completion — merged, deployed/verified where required, tracker evidence/backlink complete, and the work item terminal — by running `node scripts/lisa-work-item.mjs clear` and verifying no current binding remains.
-- A held filing writes no binding at all, so there is nothing to clear. The gate is released by a human, not by this skill: a human removes the `[lisa-human-gate]` marker and flips the leaf into the build-ready role, and a later invocation then resolves it on the ordinary path.
+- A held filing writes no binding at all, so there is nothing to clear. The gate is released by a human decision, but not by a human edit: the person records the decision as a comment on the leaf beginning `[lisa-human-gate-release]` and repeating the hold's `reason=` verbatim, and the next intake sweep takes the human-needed marker off and puts the leaf back in the build-ready role on its own (`planHumanGateRelease` in `scripts/intake-blocker-reprobe.mjs`). A later invocation then resolves it on the ordinary path. **Do not tell anyone to delete the marker from the description, and do not delete it here.** The only description write available is a whole-body replacement, so clearing one line means rewriting the entire record — which is why, before this, the rational move was always to leave a hold in place and answered holds only accumulated (CodySwannGT/lisa#3852). The hold stays in the body as history; the release is recorded beside it.
 - A tracker outage, invalid item, failed claim, or failed binding blocks durable work. Never continue untracked and never ask a Git hook to create the item.

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

@@ -62,6 +62,15 @@ Shared helpers own both, so the vocabulary cannot drift per vendor:
 blocker re-probe carries an absolute human gate: an item carrying the configured human-needed label
 or a `[lisa-human-gate]` marker is never auto-selected, whatever a probe returns.
 
+That gate has an inverse, and it is forwarded identically: a hold ends when a
+`[lisa-human-gate-release]` comment naming the same `reason=` is recorded on the item. Every vendor
+scanner passes the item's `comments` into the gate helpers so the discharge is visible, and calls
+`planHumanGateRelease(...)` to take the marker off and put the item back in the queue. **No vendor
+scanner clears a hold by editing the description** — the only body write any of them has is a
+whole-body replacement, so a release that went through the description would risk destroying the
+record it was releasing, which is why holds accumulated with no way out (CodySwannGT/lisa#3852).
+The hold note stays in the description as history and the release sits beside it as a comment.
+
 Measured: sweeping one team by lane name saw 39 of 343 open rows; by category it sees 100. The
 61-row gap produced 31 consecutive false "dry lane" cycles, every record honest and every
 conclusion wrong (#2657).

package/plugins/lisa/agents/linear-prd-intake.md

@@ -1,6 +1,6 @@
 ---
 name: linear-prd-intake
-description: PRD intake agent for Linear-hosted PRDs. Runs one intake cycle against a Linear workspace or team — claims projects carrying the configured `ready` PRD label (relabels to the configured `in_review` label), validates each through the dry-run pipeline, and routes to the configured `blocked` label (with clarifying comments on a sentinel feedback issue) or `ticketed` label (with destination tickets created). Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. Designed to be invoked manually via /linear-prd-intake or autonomously via a scheduled cron.
+description: PRD intake agent for Linear-hosted PRDs. Runs one intake cycle against a Linear workspace or team — claims projects carrying the configured `ready` PRD label (relabels to the configured `in_review` label), validates each through the dry-run pipeline, and routes to the configured `blocked` label (with clarifying comments on the project) or `ticketed` label (with destination tickets created). Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. Designed to be invoked manually via /linear-prd-intake or autonomously via a scheduled cron.
 skills:
   - linear-prd-intake
   - linear-to-tracker
@@ -15,9 +15,9 @@ skills:
 
 You are a PRD intake agent. Your single job is to run one intake cycle against the Linear scope (a workspace or a team) given to you, then report what happened.
 
-This agent is the Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. The behavior is identical apart from the source-of-truth tool surface and one structural difference (clarifying comments land on a sentinel feedback issue under each project, not on the project page itself, because Linear's MCP doesn't expose project-level comments). If you have a Notion database, use the Notion agent; if you have a Confluence space, use the Confluence agent.
+This agent is the Linear counterpart of `notion-prd-intake` and `confluence-prd-intake`. The behavior is identical apart from the source-of-truth tool surface: clarifying comments land on the project itself, exactly as they do on a Notion or Confluence page. (They used to land on a fabricated per-project "sentinel" issue, justified by the Linear MCP not exposing project-level comments. That premise was wrong about the substrate — `commentCreate(input: { projectId, body })` and `Project.comments` have always existed, and the access layer's precedence contract puts GraphQL ahead of the MCP. The gap was in the wrapper, and it is closed; see "Legacy sentinel feedback issues" in the skill for what happens to the ones already created.) If you have a Notion database, use the Notion agent; if you have a Confluence space, use the Confluence agent.
 
-PRD label role names (`ready`, `in_review`, `blocked`, `ticketed`, `shipped`, `verified`, `sentinel`) are resolved from `.lisa.config.json` `linear.labels.prd.*` by the `linear-prd-intake` skill. The defaults match the legacy hardcoded names (`prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed`, `prd-shipped`, `prd-verified`, `prd-intake-feedback`). The full PRD lifecycle is `draft → ready → in_review → blocked | ticketed → shipped → verified`; this agent only ever drives `ready → in_review → blocked | ticketed`. The `shipped` rollup is owned by the intake skill's rollup phase, and `verified` is set by `/lisa:verify-prd` after empirical PRD-level acceptance — never by this agent.
+PRD label role names (`ready`, `in_review`, `blocked`, `ticketed`, `shipped`, `verified`, and the legacy read-only `sentinel`) are resolved from `.lisa.config.json` `linear.labels.prd.*` by the `linear-prd-intake` skill. The defaults match the legacy hardcoded names (`prd-ready`, `prd-in-review`, `prd-blocked`, `prd-ticketed`, `prd-shipped`, `prd-verified`, `prd-intake-feedback`). The full PRD lifecycle is `draft → ready → in_review → blocked | ticketed → shipped → verified`; this agent only ever drives `ready → in_review → blocked | ticketed`. The `shipped` rollup is owned by the intake skill's rollup phase, and `verified` is set by `/lisa:verify-prd` after empirical PRD-level acceptance — never by this agent.
 
 ## Confirmation policy
 
@@ -29,11 +29,11 @@ Once you have a workspace or team scope, RUN. Do not ask the caller whether to p
 
 The invoking caller (a slash command, a scheduled cron, or a parent agent) hands you a Linear workspace URL, a team URL, a bare team key, or the literal token `linear` (which falls back to `linear.workspace` in `.lisa.config.json`). You do not pick the scope yourself.
 
-If no scope is provided, stop and ask. Never run intake against a default or guessed scope — the side effects (label changes, sentinel-issue creation, JIRA tickets created) are too high to act without an explicit target.
+If no scope is provided, stop and ask. Never run intake against a default or guessed scope — the side effects (label changes, project comments, JIRA tickets created) are too high to act without an explicit target.
 
 ### 2. Run the intake skill
 
-Invoke the `linear-prd-intake` skill with the scope as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, sentinel feedback issue management, summary. Do not duplicate that logic here.
+Invoke the `linear-prd-intake` skill with the scope as `$ARGUMENTS`. The skill owns the cycle logic — claim, dry-run, branch, write or comment, label transitions, summary. Do not duplicate that logic here.
 
 Treat the skill's output as the source of truth (e.g. `ticketed: 3 / blocked: 1 / errors: 0`).
 
@@ -49,7 +49,7 @@ If the cycle errored before processing any PRDs (e.g. workspace unreachable, mis
 
 ### 4. Suggest next actions when warranted
 
-After a successful cycle, if any PRDs ended in the `blocked` label, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the sentinel feedback issue (and on specific sub-issues for anchored failures) are the channel; the caller decides whether to ping anyone.
+After a successful cycle, if any PRDs ended in the `blocked` label, mention to the caller that those PRDs need product attention before they can be re-ticketed. Do not auto-notify product — comments on the project (and on specific sub-issues for anchored failures) are the channel; the caller decides whether to ping anyone.
 
 When reporting `blocked` outcomes, distinguish the cause: **pre-write gate failure** (per-ticket validator caught a problem before any tickets were created) vs **post-write coverage gap** (tickets were created and remain in the destination tracker, but the PRD has uncovered requirements that the next intake cycle will address). Both result in the `blocked` label, but the implication for product is different — coverage gaps mean some tickets are already real and product should not re-author the PRD from scratch.
 
@@ -60,7 +60,7 @@ If all PRDs ended in the `ticketed` label with coverage `COMPLETE`, mention that
 - **Never run a cycle without an explicit scope.** Side effects are too high to default.
 - **Never modify the lifecycle**: only `ready → in_review → blocked|ticketed`. Never touch the `draft`, `shipped`, or `verified` labels (`shipped` is owned by the intake rollup phase; `verified` is owned by `/lisa:verify-prd`). Never invent new labels.
 - **Never write destination tickets directly.** All writes go through the skill chain (intake → linear-to-tracker → tracker-write).
-- **Never edit a project's description or any attached Linear document.** Communication with product happens only via comments — on specific sub-issues for anchored failures, on the sentinel feedback issue otherwise.
-- **Never close, archive, or repurpose the sentinel feedback issue.** It is reused across cycles; its longevity is the audit trail.
+- **Never edit a project's description or any attached Linear document.** Communication with product happens only via comments — on specific sub-issues for anchored failures, on the project itself otherwise.
+- **Never fabricate an issue to hold a comment.** The project takes comments directly. Legacy sentinel issues from earlier cycles are left exactly as they are — not closed, not archived, not repurposed, not posted to — and the rollup excludes them so they stop holding their projects open.
 - **Never start a second cycle while one is in flight against the same scope.** Serial execution; the scheduling layer is responsible for not double-firing.
 - **Stop and surface failures rather than retry-loop.** If `linear-to-tracker` returns an error, the skill records it under `Errors` in the summary; pass that through.