@codyswann/lisa 2.287.1 → 2.288.1

package/cdk/create-only/.github/workflows/deploy.yml

@@ -68,6 +68,9 @@ jobs:
     # Reference to the quality checks workflow
     uses: CodySwannGT/lisa/.github/workflows/release.yml@main
     needs: [determine_environment]
+    permissions:
+      contents: write
+      pull-requests: read
     with:
       environment: ${{ needs.determine_environment.outputs.environment }}
       release_strategy: 'standard-version'

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

@@ -23,7 +23,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "cdk/copy-overwrite/vitest.cdk.ts": "aea238d214b7eb4c532cebe5bf732dc30b9fd04d938a215bd34a5ec2eff17046",
     "cdk/copy-overwrite/vitest.config.ts": "ce14179d4ab31011bb012ee1669af7d86b5189bdf2934e0bd9dd666a30e3d01e",
     "cdk/create-only/.github/workflows/ci.yml": "04cca8fbcb7a5c6da1aeb2b2d00d7a328d15618e4252f1d9dd495052d264d0f5",
-    "cdk/create-only/.github/workflows/deploy.yml": "5b31ed443511cae5a742238509f1210bb991575deae613aea73c41513c8fe3b8",
+    "cdk/create-only/.github/workflows/deploy.yml": "2746e78fb0fbe7b23b30bbcb0f83171e16f6804fd467b3d41d3c69970572af3f",
     "cdk/create-only/cdk.json": "f89030d8fe145a1dbabd59d89ddee4e16984f222d737f7fcf6b778d911e9fe40",
     "cdk/create-only/tsconfig.local.json": "d26253827e21fd7c41d30565fe3d339675f119e00bb24c5713a01f57ccd06602",
     "cdk/create-only/vitest.config.local.ts": "476738b351114a0efbcd3ae4ce1cf016307b55ee41ed8e87c35e28e4639d98f5",
@@ -402,7 +402,7 @@ 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": "bc34dfc6418bff6eb5bc03f0c5cd98c7b6164ca3f4f80774d981f681321119b0",
     "plugins/src/base/skills/lisa-fix-linter-error/SKILL.md": "3a8f01f014ac7f7ac37024c67df1ba07202331542d269d27da3356a7fa0a5599",
@@ -463,7 +463,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "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",

package/package.json

@@ -113,7 +113,7 @@
     "brace-expansion": ">=5.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "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.1",
+  "version": "2.288.1",
   "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.1",
+  "version": "2.288.1",
   "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-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-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-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/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "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-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-cdk/.claude-plugin/plugin.json

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

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-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-cursor/.claude-plugin/plugin.json

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

package/plugins/lisa-cursor/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-cursor/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-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.287.1",
+  "version": "2.288.1",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

package/plugins/src/base/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/src/base/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.