@codyswann/lisa 4.53.7 → 4.54.1

package/package.json

@@ -181,7 +181,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.53.7",
+  "version": "4.54.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -329,7 +329,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "f55a6d64cf60dc1317b8b45f27b82f8cfb0a6c2f",
-  "gitHead": "f55a6d64cf60dc1317b8b45f27b82f8cfb0a6c2f",
-  "lisaReleaseTag": "v4.53.7"
+  "lisaReleaseCommit": "c212a00cb49d283e91e50f22a11353a35e3d5c39",
+  "gitHead": "c212a00cb49d283e91e50f22a11353a35e3d5c39",
+  "lisaReleaseTag": "v4.54.1"
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.53.7",
+  "version": "4.54.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": "4.53.7",
+  "version": "4.54.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

@@ -931,11 +931,49 @@ proxy for the other, so read them separately:
   wedged looking abandoned.
 
 Never dismiss on `reviewDecision` alone. Dismiss the stale (often bot) review
-where repo policy permits, else re-request review:
+where repo policy permits:
 ```bash
 gh api -X PUT repos/<owner>/<repo>/pulls/<pr>/reviews/<review_id>/dismissals \
   -f message="Addressed; threads resolved." -f event=DISMISS
 ```
+
+**When you cannot dismiss, re-requesting is NOT the automatic fallback.** This
+file already forbids re-requesting to refresh a review, in as many words, and
+that prohibition applies here too — the fallback used to contradict it, and an
+agent reaching it was told to do the thing the same file calls one-way
+destruction (CodySwannGT/lisa#3587).
+
+Read the reviews before deciding, because the read is cheap and settles it:
+
+```bash
+gh api "repos/<owner>/<repo>/pulls/<pr>/reviews" \
+  --jq '[.[] | {author: .user.login, state: .state, hasBody: (((.body // "") | length) > 0)}]'
+```
+
+- **A human reviewer** — re-request freely. Re-requesting a person's review is
+  unremarkable and loses nothing.
+- **A bot reviewer whose review is NOT the only substantive one** — re-request.
+  Something else still evidences that this head was read.
+- **A bot reviewer whose review IS the only substantive one on the PR** — do
+  NOT re-request. **Escalate for a dismissal decision instead.** Under a
+  throttle or a spending cap the bot answers a new request with a status
+  carrying no review body, that hollow answer becomes its latest review, and
+  every effective-review computation — including the "latest non-dismissed
+  review per reviewer" rule immediately below — then reads the hollow one. The
+  substantive review is still retrievable from the reviews API; what is lost is
+  its standing as the reviewer's current review, which is the thing the merge
+  standard reads.
+
+Deleting the fallback outright would over-correct: it is the only remedy a lane
+without dismissal permission has, and that permission is not universal. This
+narrows it to the case that costs nothing.
+
+**Unverified, and stated as such rather than asserted:** that a bot's re-review
+REPLACES its predecessor in the effective set is inferred from the observed
+consequence, not measured against the vendor. It has not been tested here, and
+testing it means re-requesting on a live pull request. The guidance is worth
+following either way — the escalation costs one human decision, and the failure
+it avoids is one-way.
 Some org rulesets allow 0 approvals yet a bot `CHANGES_REQUESTED` still blocks
 auto-merge — dismissing the stale review after resolving all threads is what
 unblocks it.

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

@@ -229,6 +229,14 @@ For each candidate, classify the relationship:
 
 Linear native relations are set on the Issue via `save_issue`'s `relations` field (or via a paired `save_issue_relation` call if available in the MCP). For Project-level (Epic) relationships, capture them in the description under `## Related Projects` since Linear doesn't model relations between Projects natively.
 
+**Adding a relation to an already-linked pair may be a REPLACE, not an add.** Reported measured twice against the raw `issueRelationCreate` mutation: creating a `blocks` edge between two issues already carrying a `related` edge converted that edge in place — the source issue's outgoing relation count did not grow (CodySwannGT/lisa#3605). Relationship discovery is mandatory on the UPDATE path as well as creation, so this skill's own contract routinely points it at pairs that already have edges.
+
+So on an update, read the pair's existing relations before writing one. Where an edge already exists and differs in type, surface it and let a human decide rather than writing over it — **an inherited relation is not a verified one**, and rewriting it silently removes the only moment anyone would check what it meant.
+
+**The true undo is delete plus re-create with the original type.** A single delete removes the link entirely and does not restore what was there before, so any runbook recording "undo = delete relation X" has written down a plan that loses the prior relationship.
+
+**Marked UNVERIFIED.** The observations were against the raw mutation; whether the MCP's `relations` field diffs before writing has not been tested, and testing it means writing a relation to a live workspace. Note that this does not make Lisa safe by default: `lisa-linear-access` resolves `LINEAR_API_KEY` + raw GraphQL as **tier 1, ahead of the MCP**, so the normal autonomous path is the one the observations were made against.
+
 ### 4c. Remote Links
 
 Identify and attach (Linear stores attachments / links on the Issue or in description body):

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

@@ -352,6 +352,28 @@ a PR that cannot merge or a deploy that failed — it just churns.
      ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
      a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
+     **On Linear, READ the pair's existing relations before writing that link.** Reported measured
+     twice: `issueRelationCreate` on a pair that already carries a `related` edge appears to CONVERT
+     that edge rather than add a second one — the outgoing count did not grow — and the undo is not
+     what it looks like, because deleting the new relation removes the link entirely instead of
+     restoring the original. Full reversal is delete **plus re-create with the original type**
+     (CodySwannGT/lisa#3605).
+
+     So: fetch the pair's relations first. If any edge already exists between the two items, do
+     **not** write — record the item under the run's escalations naming the existing edge and its
+     type, and leave both alone. A fix ticket freshly filed by this same pass has no prior edge by
+     construction, which is the ordinary case and stays a single write.
+
+     This matters here more than anywhere else Lisa writes a relation: this pass runs unattended on a
+     schedule, and `max_candidates` defaults to 100, so a converting write is not one lost edge but
+     up to a hundred — none of them logged, because nothing read the prior state.
+
+     **Marked UNVERIFIED, deliberately.** The conversion was observed against the raw GraphQL
+     mutation, and confirming it on Lisa's own path means writing a relation to a live Linear
+     workspace. That has not been done and must not be done to close this. The read costs one call
+     and is correct whether or not the semantics are what they appear to be — which is the whole
+     reason it is safe to adopt without settling the question.
+
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
 

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

@@ -931,11 +931,49 @@ proxy for the other, so read them separately:
   wedged looking abandoned.
 
 Never dismiss on `reviewDecision` alone. Dismiss the stale (often bot) review
-where repo policy permits, else re-request review:
+where repo policy permits:
 ```bash
 gh api -X PUT repos/<owner>/<repo>/pulls/<pr>/reviews/<review_id>/dismissals \
   -f message="Addressed; threads resolved." -f event=DISMISS
 ```
+
+**When you cannot dismiss, re-requesting is NOT the automatic fallback.** This
+file already forbids re-requesting to refresh a review, in as many words, and
+that prohibition applies here too — the fallback used to contradict it, and an
+agent reaching it was told to do the thing the same file calls one-way
+destruction (CodySwannGT/lisa#3587).
+
+Read the reviews before deciding, because the read is cheap and settles it:
+
+```bash
+gh api "repos/<owner>/<repo>/pulls/<pr>/reviews" \
+  --jq '[.[] | {author: .user.login, state: .state, hasBody: (((.body // "") | length) > 0)}]'
+```
+
+- **A human reviewer** — re-request freely. Re-requesting a person's review is
+  unremarkable and loses nothing.
+- **A bot reviewer whose review is NOT the only substantive one** — re-request.
+  Something else still evidences that this head was read.
+- **A bot reviewer whose review IS the only substantive one on the PR** — do
+  NOT re-request. **Escalate for a dismissal decision instead.** Under a
+  throttle or a spending cap the bot answers a new request with a status
+  carrying no review body, that hollow answer becomes its latest review, and
+  every effective-review computation — including the "latest non-dismissed
+  review per reviewer" rule immediately below — then reads the hollow one. The
+  substantive review is still retrievable from the reviews API; what is lost is
+  its standing as the reviewer's current review, which is the thing the merge
+  standard reads.
+
+Deleting the fallback outright would over-correct: it is the only remedy a lane
+without dismissal permission has, and that permission is not universal. This
+narrows it to the case that costs nothing.
+
+**Unverified, and stated as such rather than asserted:** that a bot's re-review
+REPLACES its predecessor in the effective set is inferred from the observed
+consequence, not measured against the vendor. It has not been tested here, and
+testing it means re-requesting on a live pull request. The guidance is worth
+following either way — the escalation costs one human decision, and the failure
+it avoids is one-way.
 Some org rulesets allow 0 approvals yet a bot `CHANGES_REQUESTED` still blocks
 auto-merge — dismissing the stale review after resolving all threads is what
 unblocks it.

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

@@ -229,6 +229,14 @@ For each candidate, classify the relationship:
 
 Linear native relations are set on the Issue via `save_issue`'s `relations` field (or via a paired `save_issue_relation` call if available in the MCP). For Project-level (Epic) relationships, capture them in the description under `## Related Projects` since Linear doesn't model relations between Projects natively.
 
+**Adding a relation to an already-linked pair may be a REPLACE, not an add.** Reported measured twice against the raw `issueRelationCreate` mutation: creating a `blocks` edge between two issues already carrying a `related` edge converted that edge in place — the source issue's outgoing relation count did not grow (CodySwannGT/lisa#3605). Relationship discovery is mandatory on the UPDATE path as well as creation, so this skill's own contract routinely points it at pairs that already have edges.
+
+So on an update, read the pair's existing relations before writing one. Where an edge already exists and differs in type, surface it and let a human decide rather than writing over it — **an inherited relation is not a verified one**, and rewriting it silently removes the only moment anyone would check what it meant.
+
+**The true undo is delete plus re-create with the original type.** A single delete removes the link entirely and does not restore what was there before, so any runbook recording "undo = delete relation X" has written down a plan that loses the prior relationship.
+
+**Marked UNVERIFIED.** The observations were against the raw mutation; whether the MCP's `relations` field diffs before writing has not been tested, and testing it means writing a relation to a live workspace. Note that this does not make Lisa safe by default: `lisa-linear-access` resolves `LINEAR_API_KEY` + raw GraphQL as **tier 1, ahead of the MCP**, so the normal autonomous path is the one the observations were made against.
+
 ### 4c. Remote Links
 
 Identify and attach (Linear stores attachments / links on the Issue or in description body):

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

@@ -352,6 +352,28 @@ a PR that cannot merge or a deploy that failed — it just churns.
      ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
      a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
+     **On Linear, READ the pair's existing relations before writing that link.** Reported measured
+     twice: `issueRelationCreate` on a pair that already carries a `related` edge appears to CONVERT
+     that edge rather than add a second one — the outgoing count did not grow — and the undo is not
+     what it looks like, because deleting the new relation removes the link entirely instead of
+     restoring the original. Full reversal is delete **plus re-create with the original type**
+     (CodySwannGT/lisa#3605).
+
+     So: fetch the pair's relations first. If any edge already exists between the two items, do
+     **not** write — record the item under the run's escalations naming the existing edge and its
+     type, and leave both alone. A fix ticket freshly filed by this same pass has no prior edge by
+     construction, which is the ordinary case and stays a single write.
+
+     This matters here more than anywhere else Lisa writes a relation: this pass runs unattended on a
+     schedule, and `max_candidates` defaults to 100, so a converting write is not one lost edge but
+     up to a hundred — none of them logged, because nothing read the prior state.
+
+     **Marked UNVERIFIED, deliberately.** The conversion was observed against the raw GraphQL
+     mutation, and confirming it on Lisa's own path means writing a relation to a live Linear
+     workspace. That has not been done and must not be done to close this. The read costs one call
+     and is correct whether or not the semantics are what they appear to be — which is the whole
+     reason it is safe to adopt without settling the question.
+
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
 

package/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.53.7",
+  "version": "4.54.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

@@ -931,11 +931,49 @@ proxy for the other, so read them separately:
   wedged looking abandoned.
 
 Never dismiss on `reviewDecision` alone. Dismiss the stale (often bot) review
-where repo policy permits, else re-request review:
+where repo policy permits:
 ```bash
 gh api -X PUT repos/<owner>/<repo>/pulls/<pr>/reviews/<review_id>/dismissals \
   -f message="Addressed; threads resolved." -f event=DISMISS
 ```
+
+**When you cannot dismiss, re-requesting is NOT the automatic fallback.** This
+file already forbids re-requesting to refresh a review, in as many words, and
+that prohibition applies here too — the fallback used to contradict it, and an
+agent reaching it was told to do the thing the same file calls one-way
+destruction (CodySwannGT/lisa#3587).
+
+Read the reviews before deciding, because the read is cheap and settles it:
+
+```bash
+gh api "repos/<owner>/<repo>/pulls/<pr>/reviews" \
+  --jq '[.[] | {author: .user.login, state: .state, hasBody: (((.body // "") | length) > 0)}]'
+```
+
+- **A human reviewer** — re-request freely. Re-requesting a person's review is
+  unremarkable and loses nothing.
+- **A bot reviewer whose review is NOT the only substantive one** — re-request.
+  Something else still evidences that this head was read.
+- **A bot reviewer whose review IS the only substantive one on the PR** — do
+  NOT re-request. **Escalate for a dismissal decision instead.** Under a
+  throttle or a spending cap the bot answers a new request with a status
+  carrying no review body, that hollow answer becomes its latest review, and
+  every effective-review computation — including the "latest non-dismissed
+  review per reviewer" rule immediately below — then reads the hollow one. The
+  substantive review is still retrievable from the reviews API; what is lost is
+  its standing as the reviewer's current review, which is the thing the merge
+  standard reads.
+
+Deleting the fallback outright would over-correct: it is the only remedy a lane
+without dismissal permission has, and that permission is not universal. This
+narrows it to the case that costs nothing.
+
+**Unverified, and stated as such rather than asserted:** that a bot's re-review
+REPLACES its predecessor in the effective set is inferred from the observed
+consequence, not measured against the vendor. It has not been tested here, and
+testing it means re-requesting on a live pull request. The guidance is worth
+following either way — the escalation costs one human decision, and the failure
+it avoids is one-way.
 Some org rulesets allow 0 approvals yet a bot `CHANGES_REQUESTED` still blocks
 auto-merge — dismissing the stale review after resolving all threads is what
 unblocks it.

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

@@ -229,6 +229,14 @@ For each candidate, classify the relationship:
 
 Linear native relations are set on the Issue via `save_issue`'s `relations` field (or via a paired `save_issue_relation` call if available in the MCP). For Project-level (Epic) relationships, capture them in the description under `## Related Projects` since Linear doesn't model relations between Projects natively.
 
+**Adding a relation to an already-linked pair may be a REPLACE, not an add.** Reported measured twice against the raw `issueRelationCreate` mutation: creating a `blocks` edge between two issues already carrying a `related` edge converted that edge in place — the source issue's outgoing relation count did not grow (CodySwannGT/lisa#3605). Relationship discovery is mandatory on the UPDATE path as well as creation, so this skill's own contract routinely points it at pairs that already have edges.
+
+So on an update, read the pair's existing relations before writing one. Where an edge already exists and differs in type, surface it and let a human decide rather than writing over it — **an inherited relation is not a verified one**, and rewriting it silently removes the only moment anyone would check what it meant.
+
+**The true undo is delete plus re-create with the original type.** A single delete removes the link entirely and does not restore what was there before, so any runbook recording "undo = delete relation X" has written down a plan that loses the prior relationship.
+
+**Marked UNVERIFIED.** The observations were against the raw mutation; whether the MCP's `relations` field diffs before writing has not been tested, and testing it means writing a relation to a live workspace. Note that this does not make Lisa safe by default: `lisa-linear-access` resolves `LINEAR_API_KEY` + raw GraphQL as **tier 1, ahead of the MCP**, so the normal autonomous path is the one the observations were made against.
+
 ### 4c. Remote Links
 
 Identify and attach (Linear stores attachments / links on the Issue or in description body):

package/plugins/lisa-agy/skills/lisa-repair-intake/SKILL.md

@@ -352,6 +352,28 @@ a PR that cannot merge or a deploy that failed — it just churns.
      ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
      a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
+     **On Linear, READ the pair's existing relations before writing that link.** Reported measured
+     twice: `issueRelationCreate` on a pair that already carries a `related` edge appears to CONVERT
+     that edge rather than add a second one — the outgoing count did not grow — and the undo is not
+     what it looks like, because deleting the new relation removes the link entirely instead of
+     restoring the original. Full reversal is delete **plus re-create with the original type**
+     (CodySwannGT/lisa#3605).
+
+     So: fetch the pair's relations first. If any edge already exists between the two items, do
+     **not** write — record the item under the run's escalations naming the existing edge and its
+     type, and leave both alone. A fix ticket freshly filed by this same pass has no prior edge by
+     construction, which is the ordinary case and stays a single write.
+
+     This matters here more than anywhere else Lisa writes a relation: this pass runs unattended on a
+     schedule, and `max_candidates` defaults to 100, so a converting write is not one lost edge but
+     up to a hundred — none of them logged, because nothing read the prior state.
+
+     **Marked UNVERIFIED, deliberately.** The conversion was observed against the raw GraphQL
+     mutation, and confirming it on Lisa's own path means writing a relation to a live Linear
+     workspace. That has not been done and must not be done to close this. The read costs one call
+     and is correct whether or not the semantics are what they appear to be — which is the whole
+     reason it is safe to adopt without settling the question.
+
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.53.7",
+  "version": "4.54.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": "4.53.7",
+  "version": "4.54.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": "4.53.7",
+  "version": "4.54.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": "4.53.7",
+  "version": "4.54.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": "4.53.7",
+  "version": "4.54.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": "4.53.7",
+  "version": "4.54.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

@@ -931,11 +931,49 @@ proxy for the other, so read them separately:
   wedged looking abandoned.
 
 Never dismiss on `reviewDecision` alone. Dismiss the stale (often bot) review
-where repo policy permits, else re-request review:
+where repo policy permits:
 ```bash
 gh api -X PUT repos/<owner>/<repo>/pulls/<pr>/reviews/<review_id>/dismissals \
   -f message="Addressed; threads resolved." -f event=DISMISS
 ```
+
+**When you cannot dismiss, re-requesting is NOT the automatic fallback.** This
+file already forbids re-requesting to refresh a review, in as many words, and
+that prohibition applies here too — the fallback used to contradict it, and an
+agent reaching it was told to do the thing the same file calls one-way
+destruction (CodySwannGT/lisa#3587).
+
+Read the reviews before deciding, because the read is cheap and settles it:
+
+```bash
+gh api "repos/<owner>/<repo>/pulls/<pr>/reviews" \
+  --jq '[.[] | {author: .user.login, state: .state, hasBody: (((.body // "") | length) > 0)}]'
+```
+
+- **A human reviewer** — re-request freely. Re-requesting a person's review is
+  unremarkable and loses nothing.
+- **A bot reviewer whose review is NOT the only substantive one** — re-request.
+  Something else still evidences that this head was read.
+- **A bot reviewer whose review IS the only substantive one on the PR** — do
+  NOT re-request. **Escalate for a dismissal decision instead.** Under a
+  throttle or a spending cap the bot answers a new request with a status
+  carrying no review body, that hollow answer becomes its latest review, and
+  every effective-review computation — including the "latest non-dismissed
+  review per reviewer" rule immediately below — then reads the hollow one. The
+  substantive review is still retrievable from the reviews API; what is lost is
+  its standing as the reviewer's current review, which is the thing the merge
+  standard reads.
+
+Deleting the fallback outright would over-correct: it is the only remedy a lane
+without dismissal permission has, and that permission is not universal. This
+narrows it to the case that costs nothing.
+
+**Unverified, and stated as such rather than asserted:** that a bot's re-review
+REPLACES its predecessor in the effective set is inferred from the observed
+consequence, not measured against the vendor. It has not been tested here, and
+testing it means re-requesting on a live pull request. The guidance is worth
+following either way — the escalation costs one human decision, and the failure
+it avoids is one-way.
 Some org rulesets allow 0 approvals yet a bot `CHANGES_REQUESTED` still blocks
 auto-merge — dismissing the stale review after resolving all threads is what
 unblocks it.

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

@@ -229,6 +229,14 @@ For each candidate, classify the relationship:
 
 Linear native relations are set on the Issue via `save_issue`'s `relations` field (or via a paired `save_issue_relation` call if available in the MCP). For Project-level (Epic) relationships, capture them in the description under `## Related Projects` since Linear doesn't model relations between Projects natively.
 
+**Adding a relation to an already-linked pair may be a REPLACE, not an add.** Reported measured twice against the raw `issueRelationCreate` mutation: creating a `blocks` edge between two issues already carrying a `related` edge converted that edge in place — the source issue's outgoing relation count did not grow (CodySwannGT/lisa#3605). Relationship discovery is mandatory on the UPDATE path as well as creation, so this skill's own contract routinely points it at pairs that already have edges.
+
+So on an update, read the pair's existing relations before writing one. Where an edge already exists and differs in type, surface it and let a human decide rather than writing over it — **an inherited relation is not a verified one**, and rewriting it silently removes the only moment anyone would check what it meant.
+
+**The true undo is delete plus re-create with the original type.** A single delete removes the link entirely and does not restore what was there before, so any runbook recording "undo = delete relation X" has written down a plan that loses the prior relationship.
+
+**Marked UNVERIFIED.** The observations were against the raw mutation; whether the MCP's `relations` field diffs before writing has not been tested, and testing it means writing a relation to a live workspace. Note that this does not make Lisa safe by default: `lisa-linear-access` resolves `LINEAR_API_KEY` + raw GraphQL as **tier 1, ahead of the MCP**, so the normal autonomous path is the one the observations were made against.
+
 ### 4c. Remote Links
 
 Identify and attach (Linear stores attachments / links on the Issue or in description body):

package/plugins/lisa-copilot/skills/lisa-repair-intake/SKILL.md

@@ -352,6 +352,28 @@ a PR that cannot merge or a deploy that failed — it just churns.
      ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
      a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
+     **On Linear, READ the pair's existing relations before writing that link.** Reported measured
+     twice: `issueRelationCreate` on a pair that already carries a `related` edge appears to CONVERT
+     that edge rather than add a second one — the outgoing count did not grow — and the undo is not
+     what it looks like, because deleting the new relation removes the link entirely instead of
+     restoring the original. Full reversal is delete **plus re-create with the original type**
+     (CodySwannGT/lisa#3605).
+
+     So: fetch the pair's relations first. If any edge already exists between the two items, do
+     **not** write — record the item under the run's escalations naming the existing edge and its
+     type, and leave both alone. A fix ticket freshly filed by this same pass has no prior edge by
+     construction, which is the ordinary case and stays a single write.
+
+     This matters here more than anywhere else Lisa writes a relation: this pass runs unattended on a
+     schedule, and `max_candidates` defaults to 100, so a converting write is not one lost edge but
+     up to a hundred — none of them logged, because nothing read the prior state.
+
+     **Marked UNVERIFIED, deliberately.** The conversion was observed against the raw GraphQL
+     mutation, and confirming it on Lisa's own path means writing a relation to a live Linear
+     workspace. That has not been done and must not be done to close this. The read costs one call
+     and is correct whether or not the semantics are what they appear to be — which is the whole
+     reason it is safe to adopt without settling the question.
+
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.53.7",
+  "version": "4.54.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

@@ -931,11 +931,49 @@ proxy for the other, so read them separately:
   wedged looking abandoned.
 
 Never dismiss on `reviewDecision` alone. Dismiss the stale (often bot) review
-where repo policy permits, else re-request review:
+where repo policy permits:
 ```bash
 gh api -X PUT repos/<owner>/<repo>/pulls/<pr>/reviews/<review_id>/dismissals \
   -f message="Addressed; threads resolved." -f event=DISMISS
 ```
+
+**When you cannot dismiss, re-requesting is NOT the automatic fallback.** This
+file already forbids re-requesting to refresh a review, in as many words, and
+that prohibition applies here too — the fallback used to contradict it, and an
+agent reaching it was told to do the thing the same file calls one-way
+destruction (CodySwannGT/lisa#3587).
+
+Read the reviews before deciding, because the read is cheap and settles it:
+
+```bash
+gh api "repos/<owner>/<repo>/pulls/<pr>/reviews" \
+  --jq '[.[] | {author: .user.login, state: .state, hasBody: (((.body // "") | length) > 0)}]'
+```
+
+- **A human reviewer** — re-request freely. Re-requesting a person's review is
+  unremarkable and loses nothing.
+- **A bot reviewer whose review is NOT the only substantive one** — re-request.
+  Something else still evidences that this head was read.
+- **A bot reviewer whose review IS the only substantive one on the PR** — do
+  NOT re-request. **Escalate for a dismissal decision instead.** Under a
+  throttle or a spending cap the bot answers a new request with a status
+  carrying no review body, that hollow answer becomes its latest review, and
+  every effective-review computation — including the "latest non-dismissed
+  review per reviewer" rule immediately below — then reads the hollow one. The
+  substantive review is still retrievable from the reviews API; what is lost is
+  its standing as the reviewer's current review, which is the thing the merge
+  standard reads.
+
+Deleting the fallback outright would over-correct: it is the only remedy a lane
+without dismissal permission has, and that permission is not universal. This
+narrows it to the case that costs nothing.
+
+**Unverified, and stated as such rather than asserted:** that a bot's re-review
+REPLACES its predecessor in the effective set is inferred from the observed
+consequence, not measured against the vendor. It has not been tested here, and
+testing it means re-requesting on a live pull request. The guidance is worth
+following either way — the escalation costs one human decision, and the failure
+it avoids is one-way.
 Some org rulesets allow 0 approvals yet a bot `CHANGES_REQUESTED` still blocks
 auto-merge — dismissing the stale review after resolving all threads is what
 unblocks it.

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

@@ -229,6 +229,14 @@ For each candidate, classify the relationship:
 
 Linear native relations are set on the Issue via `save_issue`'s `relations` field (or via a paired `save_issue_relation` call if available in the MCP). For Project-level (Epic) relationships, capture them in the description under `## Related Projects` since Linear doesn't model relations between Projects natively.
 
+**Adding a relation to an already-linked pair may be a REPLACE, not an add.** Reported measured twice against the raw `issueRelationCreate` mutation: creating a `blocks` edge between two issues already carrying a `related` edge converted that edge in place — the source issue's outgoing relation count did not grow (CodySwannGT/lisa#3605). Relationship discovery is mandatory on the UPDATE path as well as creation, so this skill's own contract routinely points it at pairs that already have edges.
+
+So on an update, read the pair's existing relations before writing one. Where an edge already exists and differs in type, surface it and let a human decide rather than writing over it — **an inherited relation is not a verified one**, and rewriting it silently removes the only moment anyone would check what it meant.
+
+**The true undo is delete plus re-create with the original type.** A single delete removes the link entirely and does not restore what was there before, so any runbook recording "undo = delete relation X" has written down a plan that loses the prior relationship.
+
+**Marked UNVERIFIED.** The observations were against the raw mutation; whether the MCP's `relations` field diffs before writing has not been tested, and testing it means writing a relation to a live workspace. Note that this does not make Lisa safe by default: `lisa-linear-access` resolves `LINEAR_API_KEY` + raw GraphQL as **tier 1, ahead of the MCP**, so the normal autonomous path is the one the observations were made against.
+
 ### 4c. Remote Links
 
 Identify and attach (Linear stores attachments / links on the Issue or in description body):

package/plugins/lisa-cursor/skills/lisa-repair-intake/SKILL.md

@@ -352,6 +352,28 @@ a PR that cannot merge or a deploy that failed — it just churns.
      ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
      a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
 
+     **On Linear, READ the pair's existing relations before writing that link.** Reported measured
+     twice: `issueRelationCreate` on a pair that already carries a `related` edge appears to CONVERT
+     that edge rather than add a second one — the outgoing count did not grow — and the undo is not
+     what it looks like, because deleting the new relation removes the link entirely instead of
+     restoring the original. Full reversal is delete **plus re-create with the original type**
+     (CodySwannGT/lisa#3605).
+
+     So: fetch the pair's relations first. If any edge already exists between the two items, do
+     **not** write — record the item under the run's escalations naming the existing edge and its
+     type, and leave both alone. A fix ticket freshly filed by this same pass has no prior edge by
+     construction, which is the ordinary case and stays a single write.
+
+     This matters here more than anywhere else Lisa writes a relation: this pass runs unattended on a
+     schedule, and `max_candidates` defaults to 100, so a converting write is not one lost edge but
+     up to a hundred — none of them logged, because nothing read the prior state.
+
+     **Marked UNVERIFIED, deliberately.** The conversion was observed against the raw GraphQL
+     mutation, and confirming it on Lisa's own path means writing a relation to a live Linear
+     workspace. That has not been done and must not be done to close this. The read costs one call
+     and is correct whether or not the semantics are what they appear to be — which is the whole
+     reason it is safe to adopt without settling the question.
+
 If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
 the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.53.7",
+  "version": "4.54.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": "4.53.7",
+  "version": "4.54.1",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"