@codyswann/lisa 2.287.0 → 2.288.0

package/dist/core/upstream-evidence-manifest.js

@@ -353,7 +353,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/rules/reference/intent-routing.md": "8d2750f30b82ff9a84c5273954b0055e37bc305e3e83e4aef50f5ce47942df45",
     "plugins/src/base/rules/reference/leaf-only-lifecycle.md": "3d6d531fdca61a348fa1dd1bdb4c28fe66c85fb955238ef668a78cce4a36a7a1",
     "plugins/src/base/rules/reference/observability-audit.md": "98cf4c849baf0801bd2c46a90e7a072196649d506fbda577cc5c4019d2194551",
-    "plugins/src/base/rules/reference/prd-lifecycle-rollup.md": "2ab692a3f5b89dd49287bf7de5b2dd97d7a4bbd2b088d2859320d1b702b1f43a",
+    "plugins/src/base/rules/reference/prd-lifecycle-rollup.md": "f539e7b43918e173dd7491a139be078815d26098f992cd7fc86cd05878c90b9b",
     "plugins/src/base/rules/reference/pre-flight-autofill.md": "e61b745bb1ddfbe24634246588c13e4e78c25b50817e5e8ff02e1a9681ad1130",
     "plugins/src/base/rules/reference/project-learnings.md": "0326d553d6cb9b997c6cb865635f72ec8b7d5026565f788f46bff0e912748e85",
     "plugins/src/base/rules/reference/promotion-contract.md": "472416b82eda5431c8e5467d6093fe9da79efa7eb836e79c77b75ef77ee194a4",
@@ -402,9 +402,9 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-debrief-apply/SKILL.md": "90c5f01994bb0f8e71947e8a2f765ccf9a6aa3da47b8d7b8e2022150ef89c2b2",
     "plugins/src/base/skills/lisa-debrief/SKILL.md": "47e4cda36b07994ff47ab15fb04a17dd6b0c310ad804f9cae9d69637edaaa72a",
     "plugins/src/base/skills/lisa-doctor/SKILL.md": "1702485809533a2e546a590b9d2f67cbb420c8f0cb0eac8609b0287b05122ad3",
-    "plugins/src/base/skills/lisa-drive-pr-to-merge/SKILL.md": "e8680c65da64351580658e423d2e30f565e9df52079f4deec44df84d4ab82982",
+    "plugins/src/base/skills/lisa-drive-pr-to-merge/SKILL.md": "cd692a3343f2306a3d5b96a1cb9662e3abdc557df24d733138b23fde2aa8bad9",
     "plugins/src/base/skills/lisa-epic-triage/SKILL.md": "d02760411249bddbd396f283191fe3e82bb7b95bf9393a19a7025dc5a57c3ab7",
-    "plugins/src/base/skills/lisa-exploratory-qa/SKILL.md": "70d6e44becf223ecee4573c53a8153a8663c87bac212e3fb972a80689e36d1ed",
+    "plugins/src/base/skills/lisa-exploratory-qa/SKILL.md": "bc34dfc6418bff6eb5bc03f0c5cd98c7b6164ca3f4f80774d981f681321119b0",
     "plugins/src/base/skills/lisa-fix-linter-error/SKILL.md": "3a8f01f014ac7f7ac37024c67df1ba07202331542d269d27da3356a7fa0a5599",
     "plugins/src/base/skills/lisa-generate-claude-remote-build-script/SKILL.md": "f10aae4fabebbb139244fe14594d0675c3c52690ee341bf15f3bca29ff214de4",
     "plugins/src/base/skills/lisa-git-commit/SKILL.md": "56320566e9278fb43b4d51c00854f3714dc61edc960292d51962a6f49116ac0f",
@@ -456,14 +456,14 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-learnings-audit/SKILL.md": "b7281362b34f0fb56dd5102926496105d5c031a13fc9bf3158ae5d67b078b063",
     "plugins/src/base/skills/lisa-linear-access/SKILL.md": "f6034d41014561aad0caf42a76bbc82329423ba1ee90d9eb832b7800a7c6d3bc",
     "plugins/src/base/skills/lisa-linear-add-journey/SKILL.md": "0a9f2bd0e19fbaa4794537e436c22748c7621644253a91923d84bc77ca43f793",
-    "plugins/src/base/skills/lisa-linear-build-intake/SKILL.md": "37dcf503f99dafb38bc6b721c48163d3bca3c52d28e7d1130a5bb9a379895d27",
+    "plugins/src/base/skills/lisa-linear-build-intake/SKILL.md": "e1924eb8d968151127ac29d2242ba5bb220fe86c69f7f92e651867b97819581b",
     "plugins/src/base/skills/lisa-linear-claim/SKILL.md": "07e99b5bf91da096f7fcec3b0055d2671794011a6134bbb2b2f39967cc4f8aea",
     "plugins/src/base/skills/lisa-linear-create/SKILL.md": "4c769499b3db0fbf60e2f5fe1116ea3536012a9af5f78ee4858508090e340322",
     "plugins/src/base/skills/lisa-linear-evidence/SKILL.md": "ea5dc01bc0ac315fa4f0335577cb7517237cdde50d85abdb69d257588d2d5fc9",
     "plugins/src/base/skills/lisa-linear-journey/SKILL.md": "855f714cf5dcc932688dce94757d2e0e4b57f35c753135141482521ed6e01f49",
     "plugins/src/base/skills/lisa-linear-prd-intake/SKILL.md": "8a2d577e16b3762093fd2a217a544896676ef00b4fc9d72903ae03853134eb3b",
     "plugins/src/base/skills/lisa-linear-read-issue/SKILL.md": "a6b8241648ba4b7b9f1196a37e9924ffaccc5461f3ac2ee8ae283c58559e9717",
-    "plugins/src/base/skills/lisa-linear-sync/SKILL.md": "178b6dd6d766ba1503d32903d40019b9788dd1051d3988e6bc7c18ed2121407f",
+    "plugins/src/base/skills/lisa-linear-sync/SKILL.md": "85fbf548b9d7972912fde717d1d6ca82c0350ad82f6d779d08c831b23b90ebd3",
     "plugins/src/base/skills/lisa-linear-to-tracker/SKILL.md": "6a096c6818c6a6b3938ed3b52f6e9be8416de3b61b0b5e23fabf0ae32a9756d8",
     "plugins/src/base/skills/lisa-linear-validate-issue/SKILL.md": "3853d6f1165ef7da055a059394d72fb1b4de6463064bec3012a2bd5b19228428",
     "plugins/src/base/skills/lisa-linear-verify/SKILL.md": "d11a58bd7c2b773a973fe8f8ad19a2621f038327ee2d8afa3039bd72885f5e97",
@@ -553,7 +553,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-use-the-product/SKILL.md": "ab3f3ab475b7c97c3409f502b80d688816b1ff4b8e3dfeec7715d93ca41e3fa0",
     "plugins/src/base/skills/lisa-validate-tracker-mapping/SKILL.md": "ab45fdc00294c4ca9698093cb294a2aaf39a73d714fe1aa6ad686c6c34e157ba",
     "plugins/src/base/skills/lisa-verification-lifecycle/SKILL.md": "6302896b70d8211e2f412deea8be3e42e68cf36d566759af3c937ccf5287b91c",
-    "plugins/src/base/skills/lisa-verify-prd/SKILL.md": "82f0a34e530d1940c38c9a2ee5f0d139cab4054616bdd34e73082753442871ab",
+    "plugins/src/base/skills/lisa-verify-prd/SKILL.md": "a9deea13d2c201e9b265ee3d36f6dd17358fc35e82ae801e72dd1a3145e6fef8",
     "plugins/src/base/skills/lisa-verify-workflow-change/SKILL.md": "d89740a4dc350a9ac0d26b1b955bf74f009775b60ee0275df3f9a50fe8be3048",
     "plugins/src/base/skills/lisa-verify/SKILL.md": "bd97bd5965c05eafff25fcfeabe0fa7e763f96d5dcab8bf959a78679696c33f1",
     "plugins/src/base/skills/lisa-wiki-install/SKILL.md": "9689e5080dfdeffcebd230a5c1cb1ae7b173172a060a603634058f91ca71c17b",

package/package.json

@@ -113,7 +113,7 @@
     "brace-expansion": ">=5.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.287.0",
+  "version": "2.288.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.287.0",
+  "version": "2.288.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.287.0",
+  "version": "2.288.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -329,6 +329,27 @@ a workflow is an action, so do **not** run `gh workflow run` / `workflow_dispatc
 it for the caller to act on, consistent with the report-mode contract (steps b–f
 of section 2 are diagnose-only).
 
+### c. Linear native-state reconciliation (non-terminal merges only)
+
+Linear's GitHub integration completes a linked Issue on merge to **any** branch
+— branch-name linkage alone triggers it, even when the PR body carries only the
+non-closing `Linear: <ID>` reference form (incident of record: TunnlAI backend
+PR #207 merged to `dev`; TUN-256 auto-completed and had to be manually
+reverted). Run this step **as soon as the PR reports `MERGED`**, before the
+deploy-run verification above can terminate the flow — a `blocked:deploy`
+outcome must never leave the merged Issue unreconciled. When the driven PR's
+work item is a Linear Issue and `<baseRefName>` **successfully resolves** via
+`.lisa.config.json` `deploy.branches` to an env below the production terminal,
+re-read the Issue's native workflow `state`. If Linear moved it to a
+`completed`-type state, revert it to the team's started/In Progress state and
+post a one-line reconciliation comment — per the `leaf-only-lifecycle` rule
+(native closure fires only at the production terminal). If the base branch
+cannot be resolved (unmapped or ambiguous), do **not** mutate the native
+`state` — post a reconciliation-suggestion comment and leave it untouched,
+matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
+Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
+merge, confirming that sync ran satisfies this step.
+
 ## 4. Terminal states
 
 Loop until one of:

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

@@ -78,7 +78,7 @@ Re-running a pass must not refile the same finding. Before creating a ticket, se
 
 - **Open** ticket carrying the marker → reference/update it instead; do not create a second.
 - **Closed as _completed_** → does **not** suppress. A recurrence after a fix is a genuine **regression**, so file the finding.
-- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
+- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear, including a Linear `duplicate` state) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
 
 Every filed finding ticket MUST end with the `rejection-detection` **operator footer** as a visible prose line so the operator knows which close-reason silences it:
 

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

@@ -151,15 +151,17 @@ Run this gate **before** the claim relabel, starting with the oldest/highest-pri
 
 **Resolve container vs. leaf — structural first, then nominal.** Per `leaf-only-lifecycle` the classification is structural: an Issue is a **container** if it has **open** child work, whatever its declared type; otherwise the **type label** decides. Resolve child work using the same hierarchy `lisa-linear-read-issue` uses — Linear's native parentage: an Issue groups **sub-issues** via `parentId`, and a **Project** (the Epic equivalent) groups Issues via `projectId`. Relations (`save_issue_relation` — `blocks` / `is blocked by`) express dependencies and are **not** parentage — do not count them as children.
 
-Fetch the Issue's sub-issues via `lisa-linear-access operation: get-issue` (which returns the children) or `lisa-linear-access operation: list-issues({parentId: <issueId>})`, then count those still open (Linear `state.type` not in the completed/canceled set):
+Fetch the Issue's sub-issues via `lisa-linear-access operation: get-issue` (which returns the children) or `lisa-linear-access operation: list-issues({parentId: <issueId>})`, then count those still open (Linear `state.type` not in the completed/canceled/duplicate set):
 
 ```text
 # Children of <issueId>: native sub-issues via parentId.
-# Count children whose Linear state.type is NOT terminal ("completed" / "canceled").
-# A parent whose children are all completed is no longer holding open work and
+# Count children whose Linear state.type is NOT terminal ("completed" / "canceled" / "duplicate").
+# "duplicate" is a first-class Linear state.type (distinct from "canceled"): an Issue marked
+# as a duplicate is closed and must NOT be counted as open, or the parent never rolls up.
+# A parent whose children are all terminal is no longer holding open work and
 # rolls up via leaf-only-lifecycle's rollup, not here.
 OPEN_CHILDREN = count(list_issues({parentId: <issueId>})
-                       where state.type not in {"completed", "canceled"})
+                       where state.type not in {"completed", "canceled", "duplicate"})
 ```
 
 For a Project-level parent (an Issue that itself anchors a `projectId` grouping rather than a `parentId` tree), resolve membership the same way `lisa-linear-read-issue` does and treat the parent as a container if any grouped Issue is still open. If sub-issue resolution is unavailable, fall back to the parentage `lisa-linear-read-issue` derives and treat the Issue as a container if any derived child is open. Note "sub-issues unavailable — parentage derived" so the operator knows how children were resolved.

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

@@ -21,7 +21,7 @@ Callers (planning skills, lifecycle skills) invoke this skill at:
 | Plan created | Plan contents (sections + ordered tasks) as a comment, suggest transition `Backlog → Todo` (label: `status:ready`) |
 | Implementation in progress | Branch URL + first commit, suggest transition `Todo → In Progress` (label: `status:in-progress`) |
 | PR ready for review | PR URL + summary, the implementation handoff comment, suggest transition `In Progress → In Review` (label: `status:code-review`) |
-| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`) |
+| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`), **then run Phase 4b — mandatory when the merge target is a non-terminal env branch** |
 
 This skill **suggests** transitions but does not auto-transition the native Linear `state` field. It DOES update the `status:*` label set when the caller asks (the build queue is keyed off labels). Native state transitions remain a human / triage decision.
 
@@ -94,7 +94,7 @@ Without `--update-label`, this skill posts the comment only and does NOT touch l
 
 ## Phase 4b — Reconcile Native Auto-Close (Linear-specific)
 
-Linear's GitHub integration completes a linked Issue on merge to **any branch** — unlike GitHub's default-branch-scoped `Closes` auto-close — so a magic word (`Closes`/`Fixes`/`Resolves ENG-123`) or branch-name linkage can natively move the Issue to a Done/Completed workflow `state` at a **non-terminal** env merge, front-running the env-keyed `status:*` label ladder. `git-submit-pr` prevents the magic-word case; this phase is the required post-merge repair for the residual (branch-linkage) case we cannot suppress server-side. Run it on a `pr-merged` sync whose resolved env is **intermediate** (below the production terminal `done`):
+Linear's GitHub integration completes a linked Issue on merge to **any branch** — unlike GitHub's default-branch-scoped `Closes` auto-close — so a magic word (`Closes`/`Fixes`/`Resolves ENG-123`) or branch-name linkage can natively move the Issue to a Done/Completed workflow `state` at a **non-terminal** env merge, front-running the env-keyed `status:*` label ladder. `git-submit-pr` prevents the magic-word case; this phase is the required post-merge repair for the residual (branch-linkage) case we cannot suppress server-side — branch linkage completes the Issue even when the PR body carries only the non-closing `Linear: <ID>` form. This phase is a **mandatory** numbered step of every `pr-merged` sync, not an optional backstop; run it whenever the resolved env is **intermediate** (below the production terminal `done`):
 
 1. Resolve the merged PR's base branch to its env via `.lisa.config.json` `deploy.branches` (`config-resolution`). If it maps to the production/terminal `done`, this phase is a **no-op** — native completion is correct there.
 2. **Uniform / single-environment no-op.** When the project's env-keyed `done` map is uniform — every environment resolves to the same `status:done`, as in this repo (`production: main` only) and TunnlAI/frontend — dev-merge == terminal, so native completion is correct. Do nothing. Only a **non-uniform** env→`done` map (distinct `status:on-dev`/`status:on-stg`/`status:done` rungs) can desync.

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

@@ -70,7 +70,7 @@ If neither source yields any generated top-level child (the PRD generated nothin
 Apply the **per-vendor terminal-state predicate from the `prd-lifecycle-rollup` rule** to every generated **top-level** work item (cite the rule by slug — do not restate its predicate table here). In summary, a top-level child is:
 
 - **Terminal** — it has reached its source/tracker's done/shipped state (GitHub: closed + the resolved build `done` role label where used; Linear: a `done`-category completed state; JIRA: `statusCategory.key == "done"`; Notion/Confluence: the documented generated-work entry marked done). A generated Epic is terminal only when *it* has rolled up to its own terminal state per `leaf-only-lifecycle` — read the child's own resolved state; do not re-derive it from its leaves.
-- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled (Linear) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
+- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled or duplicate (Linear — both are terminal `state.type`s; `duplicate` is distinct from `canceled`) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
 - **Incomplete / blocked** — anything else (still open, or closed without the `done` role). It holds the PRD open.
 
 The **required** set is the top-level children minus the terminal-but-dropped ones. Branch:

package/plugins/lisa/rules/reference/prd-lifecycle-rollup.md

@@ -66,13 +66,13 @@ A generated top-level child is **terminal** (counts as done for rollup) when it
 | Vendor | A generated top-level child is terminal when… |
 |---|---|
 | **GitHub Issues** | the issue is **closed** *and* (where the build-status label is used) carries the resolved `done` role label (`status:done` by default — env-keyed; see below). A closed-as-not-planned issue is terminal-but-dropped: it does not hold the PRD open but is excluded from "shipped" (treated like a won't-do leaf). |
-| **Linear** | the Issue/Project is in a **completed** workflow state (`done`-category), **or** a **canceled** state (terminal-but-dropped, like not-planned — does not hold the PRD open, excluded from shipped). |
+| **Linear** | the Issue/Project is in a **completed** workflow state (`done`-category), **or** a **canceled** or **duplicate** state (both terminal-but-dropped, like not-planned — do not hold the PRD open, excluded from shipped). Linear exposes `duplicate` as its own first-class `state.type`, distinct from `canceled`; an Issue marked as a duplicate (via Linear's native action or a team's Duplicate workflow state) is terminal and must be treated like canceled, never as still-open. |
 | **JIRA** | the issue's status is in the **Done status category** (`statusCategory.key == "done"`). |
 | **Confluence / Notion** | the documented generated-work entry is marked **done** in the PRD's machine-readable section (the durable equivalent of a closed ticket, since these sources have no native ticket state). |
 
 Notes:
 
-- **Required vs. optional children.** Only the generated top-level children that must ship for the PRD to be complete are counted toward the all-terminal check. Won't-do / canceled / not-planned children are terminal-but-dropped: they do not hold the PRD open and are excluded from the shipped set. This mirrors `leaf-only-lifecycle`'s "required leaves" qualifier.
+- **Required vs. optional children.** Only the generated top-level children that must ship for the PRD to be complete are counted toward the all-terminal check. Won't-do / canceled / duplicate / not-planned children are terminal-but-dropped: they do not hold the PRD open and are excluded from the shipped set. This mirrors `leaf-only-lifecycle`'s "required leaves" qualifier.
 - **Recursion is delegated, not duplicated.** A generated Epic is terminal only when *it* has rolled up to its own terminal state per `leaf-only-lifecycle`'s parent-status-rollup (all its required Stories/Sub-tasks terminal). This rule does not re-derive an Epic's state from its leaves — it reads the top-level child's own resolved state and trusts `leaf-only-lifecycle` to have rolled that up bottom-up.
 - **Blocked dominates at the report level.** If any required generated top-level child is blocked or incomplete, rollup leaves the PRD open and reports the incomplete child set (PRD #525: "rollup leaving a PRD open when at least one generated top-level child is incomplete"). The PRD is only advanced when **all** required top-level children are terminal.
 

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

@@ -329,6 +329,27 @@ a workflow is an action, so do **not** run `gh workflow run` / `workflow_dispatc
 it for the caller to act on, consistent with the report-mode contract (steps b–f
 of section 2 are diagnose-only).
 
+### c. Linear native-state reconciliation (non-terminal merges only)
+
+Linear's GitHub integration completes a linked Issue on merge to **any** branch
+— branch-name linkage alone triggers it, even when the PR body carries only the
+non-closing `Linear: <ID>` reference form (incident of record: TunnlAI backend
+PR #207 merged to `dev`; TUN-256 auto-completed and had to be manually
+reverted). Run this step **as soon as the PR reports `MERGED`**, before the
+deploy-run verification above can terminate the flow — a `blocked:deploy`
+outcome must never leave the merged Issue unreconciled. When the driven PR's
+work item is a Linear Issue and `<baseRefName>` **successfully resolves** via
+`.lisa.config.json` `deploy.branches` to an env below the production terminal,
+re-read the Issue's native workflow `state`. If Linear moved it to a
+`completed`-type state, revert it to the team's started/In Progress state and
+post a one-line reconciliation comment — per the `leaf-only-lifecycle` rule
+(native closure fires only at the production terminal). If the base branch
+cannot be resolved (unmapped or ambiguous), do **not** mutate the native
+`state` — post a reconciliation-suggestion comment and leave it untouched,
+matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
+Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
+merge, confirming that sync ran satisfies this step.
+
 ## 4. Terminal states
 
 Loop until one of:

package/plugins/lisa/skills/lisa-exploratory-qa/SKILL.md

@@ -78,7 +78,7 @@ Re-running a pass must not refile the same finding. Before creating a ticket, se
 
 - **Open** ticket carrying the marker → reference/update it instead; do not create a second.
 - **Closed as _completed_** → does **not** suppress. A recurrence after a fix is a genuine **regression**, so file the finding.
-- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
+- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear, including a Linear `duplicate` state) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
 
 Every filed finding ticket MUST end with the `rejection-detection` **operator footer** as a visible prose line so the operator knows which close-reason silences it:
 

package/plugins/lisa/skills/lisa-linear-build-intake/SKILL.md

@@ -151,15 +151,17 @@ Run this gate **before** the claim relabel, starting with the oldest/highest-pri
 
 **Resolve container vs. leaf — structural first, then nominal.** Per `leaf-only-lifecycle` the classification is structural: an Issue is a **container** if it has **open** child work, whatever its declared type; otherwise the **type label** decides. Resolve child work using the same hierarchy `lisa-linear-read-issue` uses — Linear's native parentage: an Issue groups **sub-issues** via `parentId`, and a **Project** (the Epic equivalent) groups Issues via `projectId`. Relations (`save_issue_relation` — `blocks` / `is blocked by`) express dependencies and are **not** parentage — do not count them as children.
 
-Fetch the Issue's sub-issues via `lisa-linear-access operation: get-issue` (which returns the children) or `lisa-linear-access operation: list-issues({parentId: <issueId>})`, then count those still open (Linear `state.type` not in the completed/canceled set):
+Fetch the Issue's sub-issues via `lisa-linear-access operation: get-issue` (which returns the children) or `lisa-linear-access operation: list-issues({parentId: <issueId>})`, then count those still open (Linear `state.type` not in the completed/canceled/duplicate set):
 
 ```text
 # Children of <issueId>: native sub-issues via parentId.
-# Count children whose Linear state.type is NOT terminal ("completed" / "canceled").
-# A parent whose children are all completed is no longer holding open work and
+# Count children whose Linear state.type is NOT terminal ("completed" / "canceled" / "duplicate").
+# "duplicate" is a first-class Linear state.type (distinct from "canceled"): an Issue marked
+# as a duplicate is closed and must NOT be counted as open, or the parent never rolls up.
+# A parent whose children are all terminal is no longer holding open work and
 # rolls up via leaf-only-lifecycle's rollup, not here.
 OPEN_CHILDREN = count(list_issues({parentId: <issueId>})
-                       where state.type not in {"completed", "canceled"})
+                       where state.type not in {"completed", "canceled", "duplicate"})
 ```
 
 For a Project-level parent (an Issue that itself anchors a `projectId` grouping rather than a `parentId` tree), resolve membership the same way `lisa-linear-read-issue` does and treat the parent as a container if any grouped Issue is still open. If sub-issue resolution is unavailable, fall back to the parentage `lisa-linear-read-issue` derives and treat the Issue as a container if any derived child is open. Note "sub-issues unavailable — parentage derived" so the operator knows how children were resolved.

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

@@ -21,7 +21,7 @@ Callers (planning skills, lifecycle skills) invoke this skill at:
 | Plan created | Plan contents (sections + ordered tasks) as a comment, suggest transition `Backlog → Todo` (label: `status:ready`) |
 | Implementation in progress | Branch URL + first commit, suggest transition `Todo → In Progress` (label: `status:in-progress`) |
 | PR ready for review | PR URL + summary, the implementation handoff comment, suggest transition `In Progress → In Review` (label: `status:code-review`) |
-| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`) |
+| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`), **then run Phase 4b — mandatory when the merge target is a non-terminal env branch** |
 
 This skill **suggests** transitions but does not auto-transition the native Linear `state` field. It DOES update the `status:*` label set when the caller asks (the build queue is keyed off labels). Native state transitions remain a human / triage decision.
 
@@ -94,7 +94,7 @@ Without `--update-label`, this skill posts the comment only and does NOT touch l
 
 ## Phase 4b — Reconcile Native Auto-Close (Linear-specific)
 
-Linear's GitHub integration completes a linked Issue on merge to **any branch** — unlike GitHub's default-branch-scoped `Closes` auto-close — so a magic word (`Closes`/`Fixes`/`Resolves ENG-123`) or branch-name linkage can natively move the Issue to a Done/Completed workflow `state` at a **non-terminal** env merge, front-running the env-keyed `status:*` label ladder. `git-submit-pr` prevents the magic-word case; this phase is the required post-merge repair for the residual (branch-linkage) case we cannot suppress server-side. Run it on a `pr-merged` sync whose resolved env is **intermediate** (below the production terminal `done`):
+Linear's GitHub integration completes a linked Issue on merge to **any branch** — unlike GitHub's default-branch-scoped `Closes` auto-close — so a magic word (`Closes`/`Fixes`/`Resolves ENG-123`) or branch-name linkage can natively move the Issue to a Done/Completed workflow `state` at a **non-terminal** env merge, front-running the env-keyed `status:*` label ladder. `git-submit-pr` prevents the magic-word case; this phase is the required post-merge repair for the residual (branch-linkage) case we cannot suppress server-side — branch linkage completes the Issue even when the PR body carries only the non-closing `Linear: <ID>` form. This phase is a **mandatory** numbered step of every `pr-merged` sync, not an optional backstop; run it whenever the resolved env is **intermediate** (below the production terminal `done`):
 
 1. Resolve the merged PR's base branch to its env via `.lisa.config.json` `deploy.branches` (`config-resolution`). If it maps to the production/terminal `done`, this phase is a **no-op** — native completion is correct there.
 2. **Uniform / single-environment no-op.** When the project's env-keyed `done` map is uniform — every environment resolves to the same `status:done`, as in this repo (`production: main` only) and TunnlAI/frontend — dev-merge == terminal, so native completion is correct. Do nothing. Only a **non-uniform** env→`done` map (distinct `status:on-dev`/`status:on-stg`/`status:done` rungs) can desync.

package/plugins/lisa/skills/lisa-verify-prd/SKILL.md

@@ -70,7 +70,7 @@ If neither source yields any generated top-level child (the PRD generated nothin
 Apply the **per-vendor terminal-state predicate from the `prd-lifecycle-rollup` rule** to every generated **top-level** work item (cite the rule by slug — do not restate its predicate table here). In summary, a top-level child is:
 
 - **Terminal** — it has reached its source/tracker's done/shipped state (GitHub: closed + the resolved build `done` role label where used; Linear: a `done`-category completed state; JIRA: `statusCategory.key == "done"`; Notion/Confluence: the documented generated-work entry marked done). A generated Epic is terminal only when *it* has rolled up to its own terminal state per `leaf-only-lifecycle` — read the child's own resolved state; do not re-derive it from its leaves.
-- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled (Linear) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
+- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled or duplicate (Linear — both are terminal `state.type`s; `duplicate` is distinct from `canceled`) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
 - **Incomplete / blocked** — anything else (still open, or closed without the `done` role). It holds the PRD open.
 
 The **required** set is the top-level children minus the terminal-but-dropped ones. Branch:

package/plugins/lisa-agy/plugin.json

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

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

@@ -329,6 +329,27 @@ a workflow is an action, so do **not** run `gh workflow run` / `workflow_dispatc
 it for the caller to act on, consistent with the report-mode contract (steps b–f
 of section 2 are diagnose-only).
 
+### c. Linear native-state reconciliation (non-terminal merges only)
+
+Linear's GitHub integration completes a linked Issue on merge to **any** branch
+— branch-name linkage alone triggers it, even when the PR body carries only the
+non-closing `Linear: <ID>` reference form (incident of record: TunnlAI backend
+PR #207 merged to `dev`; TUN-256 auto-completed and had to be manually
+reverted). Run this step **as soon as the PR reports `MERGED`**, before the
+deploy-run verification above can terminate the flow — a `blocked:deploy`
+outcome must never leave the merged Issue unreconciled. When the driven PR's
+work item is a Linear Issue and `<baseRefName>` **successfully resolves** via
+`.lisa.config.json` `deploy.branches` to an env below the production terminal,
+re-read the Issue's native workflow `state`. If Linear moved it to a
+`completed`-type state, revert it to the team's started/In Progress state and
+post a one-line reconciliation comment — per the `leaf-only-lifecycle` rule
+(native closure fires only at the production terminal). If the base branch
+cannot be resolved (unmapped or ambiguous), do **not** mutate the native
+`state` — post a reconciliation-suggestion comment and leave it untouched,
+matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
+Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
+merge, confirming that sync ran satisfies this step.
+
 ## 4. Terminal states
 
 Loop until one of:

package/plugins/lisa-agy/skills/lisa-exploratory-qa/SKILL.md

@@ -78,7 +78,7 @@ Re-running a pass must not refile the same finding. Before creating a ticket, se
 
 - **Open** ticket carrying the marker → reference/update it instead; do not create a second.
 - **Closed as _completed_** → does **not** suppress. A recurrence after a fix is a genuine **regression**, so file the finding.
-- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
+- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear, including a Linear `duplicate` state) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
 
 Every filed finding ticket MUST end with the `rejection-detection` **operator footer** as a visible prose line so the operator knows which close-reason silences it:
 

package/plugins/lisa-agy/skills/lisa-linear-build-intake/SKILL.md

@@ -151,15 +151,17 @@ Run this gate **before** the claim relabel, starting with the oldest/highest-pri
 
 **Resolve container vs. leaf — structural first, then nominal.** Per `leaf-only-lifecycle` the classification is structural: an Issue is a **container** if it has **open** child work, whatever its declared type; otherwise the **type label** decides. Resolve child work using the same hierarchy `lisa-linear-read-issue` uses — Linear's native parentage: an Issue groups **sub-issues** via `parentId`, and a **Project** (the Epic equivalent) groups Issues via `projectId`. Relations (`save_issue_relation` — `blocks` / `is blocked by`) express dependencies and are **not** parentage — do not count them as children.
 
-Fetch the Issue's sub-issues via `lisa-linear-access operation: get-issue` (which returns the children) or `lisa-linear-access operation: list-issues({parentId: <issueId>})`, then count those still open (Linear `state.type` not in the completed/canceled set):
+Fetch the Issue's sub-issues via `lisa-linear-access operation: get-issue` (which returns the children) or `lisa-linear-access operation: list-issues({parentId: <issueId>})`, then count those still open (Linear `state.type` not in the completed/canceled/duplicate set):
 
 ```text
 # Children of <issueId>: native sub-issues via parentId.
-# Count children whose Linear state.type is NOT terminal ("completed" / "canceled").
-# A parent whose children are all completed is no longer holding open work and
+# Count children whose Linear state.type is NOT terminal ("completed" / "canceled" / "duplicate").
+# "duplicate" is a first-class Linear state.type (distinct from "canceled"): an Issue marked
+# as a duplicate is closed and must NOT be counted as open, or the parent never rolls up.
+# A parent whose children are all terminal is no longer holding open work and
 # rolls up via leaf-only-lifecycle's rollup, not here.
 OPEN_CHILDREN = count(list_issues({parentId: <issueId>})
-                       where state.type not in {"completed", "canceled"})
+                       where state.type not in {"completed", "canceled", "duplicate"})
 ```
 
 For a Project-level parent (an Issue that itself anchors a `projectId` grouping rather than a `parentId` tree), resolve membership the same way `lisa-linear-read-issue` does and treat the parent as a container if any grouped Issue is still open. If sub-issue resolution is unavailable, fall back to the parentage `lisa-linear-read-issue` derives and treat the Issue as a container if any derived child is open. Note "sub-issues unavailable — parentage derived" so the operator knows how children were resolved.

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

@@ -21,7 +21,7 @@ Callers (planning skills, lifecycle skills) invoke this skill at:
 | Plan created | Plan contents (sections + ordered tasks) as a comment, suggest transition `Backlog → Todo` (label: `status:ready`) |
 | Implementation in progress | Branch URL + first commit, suggest transition `Todo → In Progress` (label: `status:in-progress`) |
 | PR ready for review | PR URL + summary, the implementation handoff comment, suggest transition `In Progress → In Review` (label: `status:code-review`) |
-| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`) |
+| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`), **then run Phase 4b — mandatory when the merge target is a non-terminal env branch** |
 
 This skill **suggests** transitions but does not auto-transition the native Linear `state` field. It DOES update the `status:*` label set when the caller asks (the build queue is keyed off labels). Native state transitions remain a human / triage decision.
 
@@ -94,7 +94,7 @@ Without `--update-label`, this skill posts the comment only and does NOT touch l
 
 ## Phase 4b — Reconcile Native Auto-Close (Linear-specific)
 
-Linear's GitHub integration completes a linked Issue on merge to **any branch** — unlike GitHub's default-branch-scoped `Closes` auto-close — so a magic word (`Closes`/`Fixes`/`Resolves ENG-123`) or branch-name linkage can natively move the Issue to a Done/Completed workflow `state` at a **non-terminal** env merge, front-running the env-keyed `status:*` label ladder. `git-submit-pr` prevents the magic-word case; this phase is the required post-merge repair for the residual (branch-linkage) case we cannot suppress server-side. Run it on a `pr-merged` sync whose resolved env is **intermediate** (below the production terminal `done`):
+Linear's GitHub integration completes a linked Issue on merge to **any branch** — unlike GitHub's default-branch-scoped `Closes` auto-close — so a magic word (`Closes`/`Fixes`/`Resolves ENG-123`) or branch-name linkage can natively move the Issue to a Done/Completed workflow `state` at a **non-terminal** env merge, front-running the env-keyed `status:*` label ladder. `git-submit-pr` prevents the magic-word case; this phase is the required post-merge repair for the residual (branch-linkage) case we cannot suppress server-side — branch linkage completes the Issue even when the PR body carries only the non-closing `Linear: <ID>` form. This phase is a **mandatory** numbered step of every `pr-merged` sync, not an optional backstop; run it whenever the resolved env is **intermediate** (below the production terminal `done`):
 
 1. Resolve the merged PR's base branch to its env via `.lisa.config.json` `deploy.branches` (`config-resolution`). If it maps to the production/terminal `done`, this phase is a **no-op** — native completion is correct there.
 2. **Uniform / single-environment no-op.** When the project's env-keyed `done` map is uniform — every environment resolves to the same `status:done`, as in this repo (`production: main` only) and TunnlAI/frontend — dev-merge == terminal, so native completion is correct. Do nothing. Only a **non-uniform** env→`done` map (distinct `status:on-dev`/`status:on-stg`/`status:done` rungs) can desync.

package/plugins/lisa-agy/skills/lisa-verify-prd/SKILL.md

@@ -70,7 +70,7 @@ If neither source yields any generated top-level child (the PRD generated nothin
 Apply the **per-vendor terminal-state predicate from the `prd-lifecycle-rollup` rule** to every generated **top-level** work item (cite the rule by slug — do not restate its predicate table here). In summary, a top-level child is:
 
 - **Terminal** — it has reached its source/tracker's done/shipped state (GitHub: closed + the resolved build `done` role label where used; Linear: a `done`-category completed state; JIRA: `statusCategory.key == "done"`; Notion/Confluence: the documented generated-work entry marked done). A generated Epic is terminal only when *it* has rolled up to its own terminal state per `leaf-only-lifecycle` — read the child's own resolved state; do not re-derive it from its leaves.
-- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled (Linear) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
+- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled or duplicate (Linear — both are terminal `state.type`s; `duplicate` is distinct from `canceled`) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
 - **Incomplete / blocked** — anything else (still open, or closed without the `done` role). It holds the PRD open.
 
 The **required** set is the top-level children minus the terminal-but-dropped ones. Branch:

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

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

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

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

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

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

package/plugins/lisa-copilot/rules/reference/prd-lifecycle-rollup.md

@@ -66,13 +66,13 @@ A generated top-level child is **terminal** (counts as done for rollup) when it
 | Vendor | A generated top-level child is terminal when… |
 |---|---|
 | **GitHub Issues** | the issue is **closed** *and* (where the build-status label is used) carries the resolved `done` role label (`status:done` by default — env-keyed; see below). A closed-as-not-planned issue is terminal-but-dropped: it does not hold the PRD open but is excluded from "shipped" (treated like a won't-do leaf). |
-| **Linear** | the Issue/Project is in a **completed** workflow state (`done`-category), **or** a **canceled** state (terminal-but-dropped, like not-planned — does not hold the PRD open, excluded from shipped). |
+| **Linear** | the Issue/Project is in a **completed** workflow state (`done`-category), **or** a **canceled** or **duplicate** state (both terminal-but-dropped, like not-planned — do not hold the PRD open, excluded from shipped). Linear exposes `duplicate` as its own first-class `state.type`, distinct from `canceled`; an Issue marked as a duplicate (via Linear's native action or a team's Duplicate workflow state) is terminal and must be treated like canceled, never as still-open. |
 | **JIRA** | the issue's status is in the **Done status category** (`statusCategory.key == "done"`). |
 | **Confluence / Notion** | the documented generated-work entry is marked **done** in the PRD's machine-readable section (the durable equivalent of a closed ticket, since these sources have no native ticket state). |
 
 Notes:
 
-- **Required vs. optional children.** Only the generated top-level children that must ship for the PRD to be complete are counted toward the all-terminal check. Won't-do / canceled / not-planned children are terminal-but-dropped: they do not hold the PRD open and are excluded from the shipped set. This mirrors `leaf-only-lifecycle`'s "required leaves" qualifier.
+- **Required vs. optional children.** Only the generated top-level children that must ship for the PRD to be complete are counted toward the all-terminal check. Won't-do / canceled / duplicate / not-planned children are terminal-but-dropped: they do not hold the PRD open and are excluded from the shipped set. This mirrors `leaf-only-lifecycle`'s "required leaves" qualifier.
 - **Recursion is delegated, not duplicated.** A generated Epic is terminal only when *it* has rolled up to its own terminal state per `leaf-only-lifecycle`'s parent-status-rollup (all its required Stories/Sub-tasks terminal). This rule does not re-derive an Epic's state from its leaves — it reads the top-level child's own resolved state and trusts `leaf-only-lifecycle` to have rolled that up bottom-up.
 - **Blocked dominates at the report level.** If any required generated top-level child is blocked or incomplete, rollup leaves the PRD open and reports the incomplete child set (PRD #525: "rollup leaving a PRD open when at least one generated top-level child is incomplete"). The PRD is only advanced when **all** required top-level children are terminal.
 

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

@@ -329,6 +329,27 @@ a workflow is an action, so do **not** run `gh workflow run` / `workflow_dispatc
 it for the caller to act on, consistent with the report-mode contract (steps b–f
 of section 2 are diagnose-only).
 
+### c. Linear native-state reconciliation (non-terminal merges only)
+
+Linear's GitHub integration completes a linked Issue on merge to **any** branch
+— branch-name linkage alone triggers it, even when the PR body carries only the
+non-closing `Linear: <ID>` reference form (incident of record: TunnlAI backend
+PR #207 merged to `dev`; TUN-256 auto-completed and had to be manually
+reverted). Run this step **as soon as the PR reports `MERGED`**, before the
+deploy-run verification above can terminate the flow — a `blocked:deploy`
+outcome must never leave the merged Issue unreconciled. When the driven PR's
+work item is a Linear Issue and `<baseRefName>` **successfully resolves** via
+`.lisa.config.json` `deploy.branches` to an env below the production terminal,
+re-read the Issue's native workflow `state`. If Linear moved it to a
+`completed`-type state, revert it to the team's started/In Progress state and
+post a one-line reconciliation comment — per the `leaf-only-lifecycle` rule
+(native closure fires only at the production terminal). If the base branch
+cannot be resolved (unmapped or ambiguous), do **not** mutate the native
+`state` — post a reconciliation-suggestion comment and leave it untouched,
+matching Phase 4b's safe default. The full procedure is `lisa-linear-sync`
+Phase 4b; when the caller's flow already runs a `pr-merged` sync for this
+merge, confirming that sync ran satisfies this step.
+
 ## 4. Terminal states
 
 Loop until one of:

package/plugins/lisa-copilot/skills/lisa-exploratory-qa/SKILL.md

@@ -78,7 +78,7 @@ Re-running a pass must not refile the same finding. Before creating a ticket, se
 
 - **Open** ticket carrying the marker → reference/update it instead; do not create a second.
 - **Closed as _completed_** → does **not** suppress. A recurrence after a fix is a genuine **regression**, so file the finding.
-- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
+- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear, including a Linear `duplicate` state) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
 
 Every filed finding ticket MUST end with the `rejection-detection` **operator footer** as a visible prose line so the operator knows which close-reason silences it:
 

package/plugins/lisa-copilot/skills/lisa-linear-build-intake/SKILL.md

@@ -151,15 +151,17 @@ Run this gate **before** the claim relabel, starting with the oldest/highest-pri
 
 **Resolve container vs. leaf — structural first, then nominal.** Per `leaf-only-lifecycle` the classification is structural: an Issue is a **container** if it has **open** child work, whatever its declared type; otherwise the **type label** decides. Resolve child work using the same hierarchy `lisa-linear-read-issue` uses — Linear's native parentage: an Issue groups **sub-issues** via `parentId`, and a **Project** (the Epic equivalent) groups Issues via `projectId`. Relations (`save_issue_relation` — `blocks` / `is blocked by`) express dependencies and are **not** parentage — do not count them as children.
 
-Fetch the Issue's sub-issues via `lisa-linear-access operation: get-issue` (which returns the children) or `lisa-linear-access operation: list-issues({parentId: <issueId>})`, then count those still open (Linear `state.type` not in the completed/canceled set):
+Fetch the Issue's sub-issues via `lisa-linear-access operation: get-issue` (which returns the children) or `lisa-linear-access operation: list-issues({parentId: <issueId>})`, then count those still open (Linear `state.type` not in the completed/canceled/duplicate set):
 
 ```text
 # Children of <issueId>: native sub-issues via parentId.
-# Count children whose Linear state.type is NOT terminal ("completed" / "canceled").
-# A parent whose children are all completed is no longer holding open work and
+# Count children whose Linear state.type is NOT terminal ("completed" / "canceled" / "duplicate").
+# "duplicate" is a first-class Linear state.type (distinct from "canceled"): an Issue marked
+# as a duplicate is closed and must NOT be counted as open, or the parent never rolls up.
+# A parent whose children are all terminal is no longer holding open work and
 # rolls up via leaf-only-lifecycle's rollup, not here.
 OPEN_CHILDREN = count(list_issues({parentId: <issueId>})
-                       where state.type not in {"completed", "canceled"})
+                       where state.type not in {"completed", "canceled", "duplicate"})
 ```
 
 For a Project-level parent (an Issue that itself anchors a `projectId` grouping rather than a `parentId` tree), resolve membership the same way `lisa-linear-read-issue` does and treat the parent as a container if any grouped Issue is still open. If sub-issue resolution is unavailable, fall back to the parentage `lisa-linear-read-issue` derives and treat the Issue as a container if any derived child is open. Note "sub-issues unavailable — parentage derived" so the operator knows how children were resolved.

package/plugins/lisa-copilot/skills/lisa-linear-sync/SKILL.md

@@ -21,7 +21,7 @@ Callers (planning skills, lifecycle skills) invoke this skill at:
 | Plan created | Plan contents (sections + ordered tasks) as a comment, suggest transition `Backlog → Todo` (label: `status:ready`) |
 | Implementation in progress | Branch URL + first commit, suggest transition `Todo → In Progress` (label: `status:in-progress`) |
 | PR ready for review | PR URL + summary, the implementation handoff comment, suggest transition `In Progress → In Review` (label: `status:code-review`) |
-| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`) |
+| PR merged | Merge SHA + deploy environment (if known), suggest transition `In Review → Done` (label: `status:done`), **then run Phase 4b — mandatory when the merge target is a non-terminal env branch** |
 
 This skill **suggests** transitions but does not auto-transition the native Linear `state` field. It DOES update the `status:*` label set when the caller asks (the build queue is keyed off labels). Native state transitions remain a human / triage decision.
 
@@ -94,7 +94,7 @@ Without `--update-label`, this skill posts the comment only and does NOT touch l
 
 ## Phase 4b — Reconcile Native Auto-Close (Linear-specific)
 
-Linear's GitHub integration completes a linked Issue on merge to **any branch** — unlike GitHub's default-branch-scoped `Closes` auto-close — so a magic word (`Closes`/`Fixes`/`Resolves ENG-123`) or branch-name linkage can natively move the Issue to a Done/Completed workflow `state` at a **non-terminal** env merge, front-running the env-keyed `status:*` label ladder. `git-submit-pr` prevents the magic-word case; this phase is the required post-merge repair for the residual (branch-linkage) case we cannot suppress server-side. Run it on a `pr-merged` sync whose resolved env is **intermediate** (below the production terminal `done`):
+Linear's GitHub integration completes a linked Issue on merge to **any branch** — unlike GitHub's default-branch-scoped `Closes` auto-close — so a magic word (`Closes`/`Fixes`/`Resolves ENG-123`) or branch-name linkage can natively move the Issue to a Done/Completed workflow `state` at a **non-terminal** env merge, front-running the env-keyed `status:*` label ladder. `git-submit-pr` prevents the magic-word case; this phase is the required post-merge repair for the residual (branch-linkage) case we cannot suppress server-side — branch linkage completes the Issue even when the PR body carries only the non-closing `Linear: <ID>` form. This phase is a **mandatory** numbered step of every `pr-merged` sync, not an optional backstop; run it whenever the resolved env is **intermediate** (below the production terminal `done`):
 
 1. Resolve the merged PR's base branch to its env via `.lisa.config.json` `deploy.branches` (`config-resolution`). If it maps to the production/terminal `done`, this phase is a **no-op** — native completion is correct there.
 2. **Uniform / single-environment no-op.** When the project's env-keyed `done` map is uniform — every environment resolves to the same `status:done`, as in this repo (`production: main` only) and TunnlAI/frontend — dev-merge == terminal, so native completion is correct. Do nothing. Only a **non-uniform** env→`done` map (distinct `status:on-dev`/`status:on-stg`/`status:done` rungs) can desync.

package/plugins/lisa-copilot/skills/lisa-verify-prd/SKILL.md

@@ -70,7 +70,7 @@ If neither source yields any generated top-level child (the PRD generated nothin
 Apply the **per-vendor terminal-state predicate from the `prd-lifecycle-rollup` rule** to every generated **top-level** work item (cite the rule by slug — do not restate its predicate table here). In summary, a top-level child is:
 
 - **Terminal** — it has reached its source/tracker's done/shipped state (GitHub: closed + the resolved build `done` role label where used; Linear: a `done`-category completed state; JIRA: `statusCategory.key == "done"`; Notion/Confluence: the documented generated-work entry marked done). A generated Epic is terminal only when *it* has rolled up to its own terminal state per `leaf-only-lifecycle` — read the child's own resolved state; do not re-derive it from its leaves.
-- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled (Linear) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
+- **Terminal-but-dropped** — closed-as-not-planned (GitHub `stateReason == "not_planned"`) / canceled or duplicate (Linear — both are terminal `state.type`s; `duplicate` is distinct from `canceled`) / won't-do. It does **not** hold the PRD open and is excluded from the required set.
 - **Incomplete / blocked** — anything else (still open, or closed without the `done` role). It holds the PRD open.
 
 The **required** set is the top-level children minus the terminal-but-dropped ones. Branch: