@codyswann/lisa 4.87.0 → 4.87.1

package/dist/core/nightly-e2e-guard-behavior-certificate.js

@@ -41,9 +41,9 @@ export const NIGHTLY_E2E_GUARD_BEHAVIOR_CERTIFICATES = Object.freeze({
     }),
     d1b26caeaf65950e3b60ff41964d234c032c50470072e7643310b1f6722e34e6: Object.freeze({
         contractVersion: "1.9.0",
-        packageVersions: Object.freeze(["4.87.0"]),
+        packageVersions: Object.freeze(["4.87.1"]),
         provenances: Object.freeze([
-            "workspace package @codyswann/lisa@4.87.0 (typescript/copy-overwrite/scripts/check-nightly-e2e-health.mjs)",
+            "workspace package @codyswann/lisa@4.87.1 (typescript/copy-overwrite/scripts/check-nightly-e2e-health.mjs)",
         ]),
     }),
     dfd2fef680de5ef03e63075e8a61c62ca4d95cdfdff6201939b79c748d3397f6: Object.freeze({

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

@@ -699,7 +699,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-detect-tooling/scripts/commands.mjs": "e28bd61fdde4a336b56ae3395423026943a5816015719d31d04f0d5a0ab50eec",
     "plugins/src/base/skills/lisa-detect-tooling/scripts/detect-tooling.mjs": "d9419814fc04c935bd7e320e85b1977c9bfc9275d9ea5fb557002ad438ee7925",
     "plugins/src/base/skills/lisa-doctor/SKILL.md": "ab7bb855fd3ebe321e41b0143815f202b70f6ba38f6678791d6d9e933e0c3fd8",
-    "plugins/src/base/skills/lisa-drive-pr-to-merge/SKILL.md": "4fcae84ea60fbab8f35d401daebfbd45ac46164c5b78f0c8460c96b7dc7fb10c",
+    "plugins/src/base/skills/lisa-drive-pr-to-merge/SKILL.md": "46b3b6e974caf5dad42e770c1320b0bd6ae631c9dca787a3478f21485e343429",
     "plugins/src/base/skills/lisa-epic-triage/SKILL.md": "d02760411249bddbd396f283191fe3e82bb7b95bf9393a19a7025dc5a57c3ab7",
     "plugins/src/base/skills/lisa-evaluation-suite/SKILL.md": "96b5c2091ccd22a565935a7b0b917f67998881b81055ce3e4d518319472eac8b",
     "plugins/src/base/skills/lisa-exploratory-qa/SKILL.md": "254b15d65f8da6bfc6a930814004892e4a32ba8946ff1b68c27fec2a57d9e5b4",
@@ -798,7 +798,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-project-ideation/examples/idempotency-verification-harness.md": "c6def168f32c3e6cb426d7d7d942bbe5b5776b46e315f47d2b2aeaad275c7f0f",
     "plugins/src/base/skills/lisa-project-ideation/examples/public-external-inspiration.md": "8e61344f46d46c2f6806b6bdb5bbf0086df358240661a524806d1bd659330ce9",
     "plugins/src/base/skills/lisa-project-ideation/examples/unavailable-data-rejection.md": "362835db13cb8f73179754bce427d0f7caef7738a575aa5b936a0383b7f81078",
-    "plugins/src/base/skills/lisa-pull-request-review/SKILL.md": "10bb42cba995cdd6b945efd6ef3d48578860b9d09c94aefd17c298b53aed5053",
+    "plugins/src/base/skills/lisa-pull-request-review/SKILL.md": "c95c6fd7948e1daaec760b1c7ff9504f83e3fdcf9f7e9409edeef41991254b03",
     "plugins/src/base/skills/lisa-quality-review/SKILL.md": "c51afffe153f614bcef5bbd2a7b8ffb53c241ebd246900863448e3a6f4be7d47",
     "plugins/src/base/skills/lisa-queue-status/SKILL.md": "8905a65e2c0f3d6894b4c36907723fe0b7d6048ff0fd1d0e2be529eccb5de1e3",
     "plugins/src/base/skills/lisa-remote-dispatch/SKILL.md": "f3c48120a206d01db45f849ca5b61690d572abc16bc36d559a4cacc8f9422c06",

package/package.json

@@ -189,7 +189,7 @@
     "qs": "^6.16.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.87.0",
+  "version": "4.87.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -347,7 +347,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "1a96a2fed56ab77f8f4cca54bd17a34b73324a1a",
-  "gitHead": "1a96a2fed56ab77f8f4cca54bd17a34b73324a1a",
-  "lisaReleaseTag": "v4.87.0"
+  "lisaReleaseCommit": "685c54f5fdefa2acbc9a412557124db84d898f79",
+  "gitHead": "685c54f5fdefa2acbc9a412557124db84d898f79",
+  "lisaReleaseTag": "v4.87.1"
 }

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

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

@@ -393,15 +393,16 @@ declared, arm normally (the scope rule above). Where one IS declared, absent a
 description that positively states a review ran, treat the context as vacuous.
 Fail closed: absence of evidence is not evidence of a review.
 
-#### Vacuous and transient are different properties
+#### Vacuous, transient or standing: the response is the same
 
-A vacuous context is not automatically something to wait out, and this is the
-distinction a naive wait-and-arm gets wrong — it waits forever on a repository
-where the state never clears. **Only the rate limit has both properties.**
+A vacuous context is never something to wait out. Waiting looks like progress
+but it is a stall, and on a repository where the state never clears it waits
+forever. Some vacuities clear on their own and some do not. **That changes what
+the report says, not what you do:**
 
 | description | vacuous? | clears on its own? |
 | --- | --- | --- |
-| `Review rate limited` | yes | **yes** — a throughput window |
+| `Review rate limited` (and decorated forms such as `Review rate limited (retry in 12m)`) | yes | eventually — a throughput window of unknown length |
 | `Review skipped: manual review required for this OSS repository` | yes | **no** — a standing vendor policy for public repositories |
 | `Review skipped: N files exceed the limit of M` | yes | **no** — not without splitting the pull request |
 | `Review skipped` (bare, no stated reason) | yes | **unknown — treat as standing** |
@@ -410,17 +411,33 @@ A bare skip carries no machine-readable reason, so nothing distinguishes it from
 the standing forms. Requiring a stated reason before treating a skip as vacuous
 is how the commonest form gets missed.
 
-- **Transient (the rate limit, and only the rate limit)** — do not arm yet. Wait
-  the window out and re-request the review **at most once**, then re-classify.
-  If it now proves work, arm. If it does not, stop and treat it as standing.
-  **Never loop**: a retry loop re-triggers the very limit it is escaping, and
-  measured on #3220 a single explicit re-request in this repository was
-  acknowledged, went `Review in progress`, and settled back at
-  `Review rate limited` two seconds later having reviewed nothing — minting a
-  second hollow green. One attempt, then report.
-- **Standing** — do not wait at all, and do not re-request. There is no window
-  to wait out, so waiting produces a stall that reads as progress. Go straight
-  to the watch loop and let step (d) adjudicate the merge in the open.
+**Every row, the rate limit included: do not wait, and do not re-request.** Do
+not arm. Go straight to the watch loop, run the local adversarial review over the
+PR diff at the current head **now**, post it with the substitute marker (step
+(d), "In case 3, substitute"), and keep driving. Fix what it finds, substitute
+again on each new head, and let step (d) merge when the vacuous context is the
+sole remaining gate.
+
+The rate limit used to get a wait-the-window-out-and-re-request-once exception.
+That exception is removed, for three reasons:
+
+- **The window is not short.** Agents waiting it out stalled for an hour or more
+  per pull request, across a whole portfolio of repositories, and nothing about
+  the wait made the merge safer than a substitute review would.
+- **Re-requesting does not work under a throttle.** Measured on #3220, a single
+  explicit re-request was acknowledged, went `Review in progress`, and settled
+  back at `Review rate limited` two seconds later having reviewed nothing. That
+  minted a second hollow green.
+- **Re-requesting destroys evidence.** It overwrites the existing status (see
+  "Never re-request a review to 'refresh' it" in step (d)), so the exception
+  contradicted a rule this file states with no exceptions.
+
+If the reviewer later reviews on its own, nothing special happens. Its threads
+are review threads like any other, and step (d) handles them. A `CHANGES_REQUESTED`
+it leaves is a real blocker (step (e)), and the substitute never overrides it.
+If it now proves work, arm, per the table above. That is a re-classification
+the watch loop makes on what it reads anyway. It is never a reason to wait or
+re-request.
 
 #### A latch somebody else armed
 
@@ -1048,10 +1065,11 @@ configured reviewed-when phrase says what "did work" looks like for this
 project.
 
 Prove the signal from the commit status API as above; a merely pending or queued
-check is not proof of anything and must keep polling. **A transient vacuity is not adjudicated here until the arm gate's
-single wait-and-re-request has been spent** (section 1): a rate limit has a
-window, and merging past one you never waited out is a choice you did not have
-to make. A standing vacuity has no window, so it arrives here immediately.
+check is not proof of anything and must keep polling. **A settled vacuity, the
+rate limit included, arrives here immediately.** There is no wait to spend first
+and no re-request to try: a rate limit's window is of unknown length, and
+waiting it out stalls the pull request without reading a line of the diff. The
+substitute is what makes the merge safe, not the passage of time.
 
 Once the signal is explicit, merge directly with `gh pr merge <pr>
 --<merge_method>` (pass `--admin` only if branch protection lists the vacuous
@@ -1172,6 +1190,34 @@ 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.
 
+**A stale bot verdict under a rate limit: substitute, then stop and report.**
+Under a rate limit or an exhausted review allowance, a bot's old
+`CHANGES_REQUESTED` on an outdated head can end up as the only thing blocking
+the merge. The bot cannot post a fresh review to replace it, so the verdict
+will not clear by itself while the throttle lasts. This was measured on a
+caller repo in the portfolio: every check green, zero unresolved threads, and
+the bot's verdict from an earlier head as the only blocker. In that case:
+
+1. **Do not wait for the window to reset, and do not re-request.** Waiting
+   leaves the pull request wedged for an hour or more. A re-request under the
+   throttle settles hollow and can take away the bot's standing review (see
+   above).
+2. Post the local adversarial review substitute for the **current** head, as
+   step (d) case 3 describes, if one is not already there.
+3. **Then stop** with `blocked:stale-bot-verdict` (section 4). Report exactly
+   that blocker: the bot reviewer, the review id, the outdated head it reviewed
+   and the current head, the unresolved thread count, and that the substitute
+   is posted for the current head. Name the decision that is needed: a human
+   with dismissal rights dismisses that review, or decides it must stand.
+
+Do not dismiss it on the strength of your own substitute. Here the bot's review
+is the only third-party review on the pull request. Dismissing it because of a
+review this run wrote would make the agent both author and judge of the change.
+That is the escalation the bullet above requires, reached right away instead of
+after a wait. A stranded verdict that is **not** the only substantive review, or
+one left by a reviewer that is not throttled, is still handled by the
+dismissal rule above.
+
 **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
@@ -1455,7 +1501,7 @@ Loop until one of:
   the mode forbids acting on them: `on_blocker=report`). The latch is
   deliberately not armed, so the PR sits OPEN rather than merging on a review
   nothing performed. Report the PR URL, the review context's settled
-  description, whether it is transient or standing, and which sole-gate
+  description, whether it clears on its own (a rate limit) or is standing, and which sole-gate
   condition failed. This is an outcome that needs an operator, stated in one
   line a non-technical reader can act on — for example: *"PR #123 is ready to
   merge but nobody reviewed it: the review tool says it skips public
@@ -1485,6 +1531,16 @@ Loop until one of:
   — but a review asked for changes and that is still on record, so it will sit
   there forever. Someone needs to clear that review or resolve the open
   comments."* Never report this PR as merging.
+- **`blocked:stale-bot-verdict`** — the only thing blocking the merge is a
+  bot's `CHANGES_REQUESTED` on an outdated head, the bot is rate limited or out
+  of review allowance so it cannot replace that verdict, and the local
+  adversarial review substitute is posted for the current head (step (e)).
+  Report the reviewer, the review id, both heads, the unresolved thread count,
+  and the dismissal decision a human needs to make. For example: *"PR #123 is
+  ready except for an old review from the review bot on an earlier version. The
+  bot is rate limited and cannot re-review, and I posted my own review of the
+  current version. Someone with dismissal rights needs to dismiss review 456,
+  or decide it should stand."* Do not wait for the bot's window to reset.
 - **`CLOSED`** → report (PR was closed without merge).
 - **Hard block needing a human**: an unresolvable conflict, a failing check that
   needs design input, or genuine unresolved human objection (not a bot gate). Stop
@@ -1593,7 +1649,8 @@ declare none, one, or several, and each shows its own evidence.
 
 Quote the description that was actually read. A report that says "rate limited"
 on a policy skip is a wrong record, and the two call for different operator
-actions: one clears itself, the other never will.
+actions: one clears itself, the other never will. Neither changes what this
+skill does in the meantime: it substitutes and keeps driving in both cases.
 
 `NOT REVIEWED` is reporting, and on a merged PR it is never a terminal state of
 its own: it does not turn a merged PR into a blocked one. What it does gate is

package/plugins/lisa/.codex-plugin/skills/lisa-pull-request-review/SKILL.md

@@ -75,6 +75,14 @@ node scripts/check-skipped-required-checks.mjs --pr=<pr> --json
 It reports and never fails — a hollow check is often a vendor spending cap, not
 a repository defect, and it is not this skill's call to block on one.
 
+**Do not wait for a rate limit to reset, and do not re-request the review.** A
+`Review rate limited` status, including decorated forms such as
+`Review rate limited (retry in 12m)`, is handled like every other vacuous
+review. Report it here. `lisa-drive-pr-to-merge` then posts a local adversarial
+review substitute for the current head right away and keeps driving. Waiting
+out the window stalls the pull request for an hour or more and reads no code.
+Re-requesting overwrites the status and can destroy a real review.
+
 Carry the finding into your Step 4 report. **Do not write "no unresolved review
 threads" on its own** — it is true of an unreviewed PR too. Say which you
 observed:

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

@@ -391,15 +391,16 @@ declared, arm normally (the scope rule above). Where one IS declared, absent a
 description that positively states a review ran, treat the context as vacuous.
 Fail closed: absence of evidence is not evidence of a review.
 
-#### Vacuous and transient are different properties
+#### Vacuous, transient or standing: the response is the same
 
-A vacuous context is not automatically something to wait out, and this is the
-distinction a naive wait-and-arm gets wrong — it waits forever on a repository
-where the state never clears. **Only the rate limit has both properties.**
+A vacuous context is never something to wait out. Waiting looks like progress
+but it is a stall, and on a repository where the state never clears it waits
+forever. Some vacuities clear on their own and some do not. **That changes what
+the report says, not what you do:**
 
 | description | vacuous? | clears on its own? |
 | --- | --- | --- |
-| `Review rate limited` | yes | **yes** — a throughput window |
+| `Review rate limited` (and decorated forms such as `Review rate limited (retry in 12m)`) | yes | eventually — a throughput window of unknown length |
 | `Review skipped: manual review required for this OSS repository` | yes | **no** — a standing vendor policy for public repositories |
 | `Review skipped: N files exceed the limit of M` | yes | **no** — not without splitting the pull request |
 | `Review skipped` (bare, no stated reason) | yes | **unknown — treat as standing** |
@@ -408,17 +409,33 @@ A bare skip carries no machine-readable reason, so nothing distinguishes it from
 the standing forms. Requiring a stated reason before treating a skip as vacuous
 is how the commonest form gets missed.
 
-- **Transient (the rate limit, and only the rate limit)** — do not arm yet. Wait
-  the window out and re-request the review **at most once**, then re-classify.
-  If it now proves work, arm. If it does not, stop and treat it as standing.
-  **Never loop**: a retry loop re-triggers the very limit it is escaping, and
-  measured on #3220 a single explicit re-request in this repository was
-  acknowledged, went `Review in progress`, and settled back at
-  `Review rate limited` two seconds later having reviewed nothing — minting a
-  second hollow green. One attempt, then report.
-- **Standing** — do not wait at all, and do not re-request. There is no window
-  to wait out, so waiting produces a stall that reads as progress. Go straight
-  to the watch loop and let step (d) adjudicate the merge in the open.
+**Every row, the rate limit included: do not wait, and do not re-request.** Do
+not arm. Go straight to the watch loop, run the local adversarial review over the
+PR diff at the current head **now**, post it with the substitute marker (step
+(d), "In case 3, substitute"), and keep driving. Fix what it finds, substitute
+again on each new head, and let step (d) merge when the vacuous context is the
+sole remaining gate.
+
+The rate limit used to get a wait-the-window-out-and-re-request-once exception.
+That exception is removed, for three reasons:
+
+- **The window is not short.** Agents waiting it out stalled for an hour or more
+  per pull request, across a whole portfolio of repositories, and nothing about
+  the wait made the merge safer than a substitute review would.
+- **Re-requesting does not work under a throttle.** Measured on #3220, a single
+  explicit re-request was acknowledged, went `Review in progress`, and settled
+  back at `Review rate limited` two seconds later having reviewed nothing. That
+  minted a second hollow green.
+- **Re-requesting destroys evidence.** It overwrites the existing status (see
+  "Never re-request a review to 'refresh' it" in step (d)), so the exception
+  contradicted a rule this file states with no exceptions.
+
+If the reviewer later reviews on its own, nothing special happens. Its threads
+are review threads like any other, and step (d) handles them. A `CHANGES_REQUESTED`
+it leaves is a real blocker (step (e)), and the substitute never overrides it.
+If it now proves work, arm, per the table above. That is a re-classification
+the watch loop makes on what it reads anyway. It is never a reason to wait or
+re-request.
 
 #### A latch somebody else armed
 
@@ -1046,10 +1063,11 @@ configured reviewed-when phrase says what "did work" looks like for this
 project.
 
 Prove the signal from the commit status API as above; a merely pending or queued
-check is not proof of anything and must keep polling. **A transient vacuity is not adjudicated here until the arm gate's
-single wait-and-re-request has been spent** (section 1): a rate limit has a
-window, and merging past one you never waited out is a choice you did not have
-to make. A standing vacuity has no window, so it arrives here immediately.
+check is not proof of anything and must keep polling. **A settled vacuity, the
+rate limit included, arrives here immediately.** There is no wait to spend first
+and no re-request to try: a rate limit's window is of unknown length, and
+waiting it out stalls the pull request without reading a line of the diff. The
+substitute is what makes the merge safe, not the passage of time.
 
 Once the signal is explicit, merge directly with `gh pr merge <pr>
 --<merge_method>` (pass `--admin` only if branch protection lists the vacuous
@@ -1170,6 +1188,34 @@ 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.
 
+**A stale bot verdict under a rate limit: substitute, then stop and report.**
+Under a rate limit or an exhausted review allowance, a bot's old
+`CHANGES_REQUESTED` on an outdated head can end up as the only thing blocking
+the merge. The bot cannot post a fresh review to replace it, so the verdict
+will not clear by itself while the throttle lasts. This was measured on a
+caller repo in the portfolio: every check green, zero unresolved threads, and
+the bot's verdict from an earlier head as the only blocker. In that case:
+
+1. **Do not wait for the window to reset, and do not re-request.** Waiting
+   leaves the pull request wedged for an hour or more. A re-request under the
+   throttle settles hollow and can take away the bot's standing review (see
+   above).
+2. Post the local adversarial review substitute for the **current** head, as
+   step (d) case 3 describes, if one is not already there.
+3. **Then stop** with `blocked:stale-bot-verdict` (section 4). Report exactly
+   that blocker: the bot reviewer, the review id, the outdated head it reviewed
+   and the current head, the unresolved thread count, and that the substitute
+   is posted for the current head. Name the decision that is needed: a human
+   with dismissal rights dismisses that review, or decides it must stand.
+
+Do not dismiss it on the strength of your own substitute. Here the bot's review
+is the only third-party review on the pull request. Dismissing it because of a
+review this run wrote would make the agent both author and judge of the change.
+That is the escalation the bullet above requires, reached right away instead of
+after a wait. A stranded verdict that is **not** the only substantive review, or
+one left by a reviewer that is not throttled, is still handled by the
+dismissal rule above.
+
 **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
@@ -1453,7 +1499,7 @@ Loop until one of:
   the mode forbids acting on them: `on_blocker=report`). The latch is
   deliberately not armed, so the PR sits OPEN rather than merging on a review
   nothing performed. Report the PR URL, the review context's settled
-  description, whether it is transient or standing, and which sole-gate
+  description, whether it clears on its own (a rate limit) or is standing, and which sole-gate
   condition failed. This is an outcome that needs an operator, stated in one
   line a non-technical reader can act on — for example: *"PR #123 is ready to
   merge but nobody reviewed it: the review tool says it skips public
@@ -1483,6 +1529,16 @@ Loop until one of:
   — but a review asked for changes and that is still on record, so it will sit
   there forever. Someone needs to clear that review or resolve the open
   comments."* Never report this PR as merging.
+- **`blocked:stale-bot-verdict`** — the only thing blocking the merge is a
+  bot's `CHANGES_REQUESTED` on an outdated head, the bot is rate limited or out
+  of review allowance so it cannot replace that verdict, and the local
+  adversarial review substitute is posted for the current head (step (e)).
+  Report the reviewer, the review id, both heads, the unresolved thread count,
+  and the dismissal decision a human needs to make. For example: *"PR #123 is
+  ready except for an old review from the review bot on an earlier version. The
+  bot is rate limited and cannot re-review, and I posted my own review of the
+  current version. Someone with dismissal rights needs to dismiss review 456,
+  or decide it should stand."* Do not wait for the bot's window to reset.
 - **`CLOSED`** → report (PR was closed without merge).
 - **Hard block needing a human**: an unresolvable conflict, a failing check that
   needs design input, or genuine unresolved human objection (not a bot gate). Stop
@@ -1591,7 +1647,8 @@ declare none, one, or several, and each shows its own evidence.
 
 Quote the description that was actually read. A report that says "rate limited"
 on a policy skip is a wrong record, and the two call for different operator
-actions: one clears itself, the other never will.
+actions: one clears itself, the other never will. Neither changes what this
+skill does in the meantime: it substitutes and keeps driving in both cases.
 
 `NOT REVIEWED` is reporting, and on a merged PR it is never a terminal state of
 its own: it does not turn a merged PR into a blocked one. What it does gate is

package/plugins/lisa/skills/lisa-pull-request-review/SKILL.md

@@ -73,6 +73,14 @@ node scripts/check-skipped-required-checks.mjs --pr=<pr> --json
 It reports and never fails — a hollow check is often a vendor spending cap, not
 a repository defect, and it is not this skill's call to block on one.
 
+**Do not wait for a rate limit to reset, and do not re-request the review.** A
+`Review rate limited` status, including decorated forms such as
+`Review rate limited (retry in 12m)`, is handled like every other vacuous
+review. Report it here. `lisa-drive-pr-to-merge` then posts a local adversarial
+review substitute for the current head right away and keeps driving. Waiting
+out the window stalls the pull request for an hour or more and reads no code.
+Re-requesting overwrites the status and can destroy a real review.
+
 Carry the finding into your Step 4 report. **Do not write "no unresolved review
 threads" on its own** — it is true of an unreviewed PR too. Say which you
 observed:

package/plugins/lisa-agy/plugin.json

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

@@ -391,15 +391,16 @@ declared, arm normally (the scope rule above). Where one IS declared, absent a
 description that positively states a review ran, treat the context as vacuous.
 Fail closed: absence of evidence is not evidence of a review.
 
-#### Vacuous and transient are different properties
+#### Vacuous, transient or standing: the response is the same
 
-A vacuous context is not automatically something to wait out, and this is the
-distinction a naive wait-and-arm gets wrong — it waits forever on a repository
-where the state never clears. **Only the rate limit has both properties.**
+A vacuous context is never something to wait out. Waiting looks like progress
+but it is a stall, and on a repository where the state never clears it waits
+forever. Some vacuities clear on their own and some do not. **That changes what
+the report says, not what you do:**
 
 | description | vacuous? | clears on its own? |
 | --- | --- | --- |
-| `Review rate limited` | yes | **yes** — a throughput window |
+| `Review rate limited` (and decorated forms such as `Review rate limited (retry in 12m)`) | yes | eventually — a throughput window of unknown length |
 | `Review skipped: manual review required for this OSS repository` | yes | **no** — a standing vendor policy for public repositories |
 | `Review skipped: N files exceed the limit of M` | yes | **no** — not without splitting the pull request |
 | `Review skipped` (bare, no stated reason) | yes | **unknown — treat as standing** |
@@ -408,17 +409,33 @@ A bare skip carries no machine-readable reason, so nothing distinguishes it from
 the standing forms. Requiring a stated reason before treating a skip as vacuous
 is how the commonest form gets missed.
 
-- **Transient (the rate limit, and only the rate limit)** — do not arm yet. Wait
-  the window out and re-request the review **at most once**, then re-classify.
-  If it now proves work, arm. If it does not, stop and treat it as standing.
-  **Never loop**: a retry loop re-triggers the very limit it is escaping, and
-  measured on #3220 a single explicit re-request in this repository was
-  acknowledged, went `Review in progress`, and settled back at
-  `Review rate limited` two seconds later having reviewed nothing — minting a
-  second hollow green. One attempt, then report.
-- **Standing** — do not wait at all, and do not re-request. There is no window
-  to wait out, so waiting produces a stall that reads as progress. Go straight
-  to the watch loop and let step (d) adjudicate the merge in the open.
+**Every row, the rate limit included: do not wait, and do not re-request.** Do
+not arm. Go straight to the watch loop, run the local adversarial review over the
+PR diff at the current head **now**, post it with the substitute marker (step
+(d), "In case 3, substitute"), and keep driving. Fix what it finds, substitute
+again on each new head, and let step (d) merge when the vacuous context is the
+sole remaining gate.
+
+The rate limit used to get a wait-the-window-out-and-re-request-once exception.
+That exception is removed, for three reasons:
+
+- **The window is not short.** Agents waiting it out stalled for an hour or more
+  per pull request, across a whole portfolio of repositories, and nothing about
+  the wait made the merge safer than a substitute review would.
+- **Re-requesting does not work under a throttle.** Measured on #3220, a single
+  explicit re-request was acknowledged, went `Review in progress`, and settled
+  back at `Review rate limited` two seconds later having reviewed nothing. That
+  minted a second hollow green.
+- **Re-requesting destroys evidence.** It overwrites the existing status (see
+  "Never re-request a review to 'refresh' it" in step (d)), so the exception
+  contradicted a rule this file states with no exceptions.
+
+If the reviewer later reviews on its own, nothing special happens. Its threads
+are review threads like any other, and step (d) handles them. A `CHANGES_REQUESTED`
+it leaves is a real blocker (step (e)), and the substitute never overrides it.
+If it now proves work, arm, per the table above. That is a re-classification
+the watch loop makes on what it reads anyway. It is never a reason to wait or
+re-request.
 
 #### A latch somebody else armed
 
@@ -1046,10 +1063,11 @@ configured reviewed-when phrase says what "did work" looks like for this
 project.
 
 Prove the signal from the commit status API as above; a merely pending or queued
-check is not proof of anything and must keep polling. **A transient vacuity is not adjudicated here until the arm gate's
-single wait-and-re-request has been spent** (section 1): a rate limit has a
-window, and merging past one you never waited out is a choice you did not have
-to make. A standing vacuity has no window, so it arrives here immediately.
+check is not proof of anything and must keep polling. **A settled vacuity, the
+rate limit included, arrives here immediately.** There is no wait to spend first
+and no re-request to try: a rate limit's window is of unknown length, and
+waiting it out stalls the pull request without reading a line of the diff. The
+substitute is what makes the merge safe, not the passage of time.
 
 Once the signal is explicit, merge directly with `gh pr merge <pr>
 --<merge_method>` (pass `--admin` only if branch protection lists the vacuous
@@ -1170,6 +1188,34 @@ 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.
 
+**A stale bot verdict under a rate limit: substitute, then stop and report.**
+Under a rate limit or an exhausted review allowance, a bot's old
+`CHANGES_REQUESTED` on an outdated head can end up as the only thing blocking
+the merge. The bot cannot post a fresh review to replace it, so the verdict
+will not clear by itself while the throttle lasts. This was measured on a
+caller repo in the portfolio: every check green, zero unresolved threads, and
+the bot's verdict from an earlier head as the only blocker. In that case:
+
+1. **Do not wait for the window to reset, and do not re-request.** Waiting
+   leaves the pull request wedged for an hour or more. A re-request under the
+   throttle settles hollow and can take away the bot's standing review (see
+   above).
+2. Post the local adversarial review substitute for the **current** head, as
+   step (d) case 3 describes, if one is not already there.
+3. **Then stop** with `blocked:stale-bot-verdict` (section 4). Report exactly
+   that blocker: the bot reviewer, the review id, the outdated head it reviewed
+   and the current head, the unresolved thread count, and that the substitute
+   is posted for the current head. Name the decision that is needed: a human
+   with dismissal rights dismisses that review, or decides it must stand.
+
+Do not dismiss it on the strength of your own substitute. Here the bot's review
+is the only third-party review on the pull request. Dismissing it because of a
+review this run wrote would make the agent both author and judge of the change.
+That is the escalation the bullet above requires, reached right away instead of
+after a wait. A stranded verdict that is **not** the only substantive review, or
+one left by a reviewer that is not throttled, is still handled by the
+dismissal rule above.
+
 **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
@@ -1453,7 +1499,7 @@ Loop until one of:
   the mode forbids acting on them: `on_blocker=report`). The latch is
   deliberately not armed, so the PR sits OPEN rather than merging on a review
   nothing performed. Report the PR URL, the review context's settled
-  description, whether it is transient or standing, and which sole-gate
+  description, whether it clears on its own (a rate limit) or is standing, and which sole-gate
   condition failed. This is an outcome that needs an operator, stated in one
   line a non-technical reader can act on — for example: *"PR #123 is ready to
   merge but nobody reviewed it: the review tool says it skips public
@@ -1483,6 +1529,16 @@ Loop until one of:
   — but a review asked for changes and that is still on record, so it will sit
   there forever. Someone needs to clear that review or resolve the open
   comments."* Never report this PR as merging.
+- **`blocked:stale-bot-verdict`** — the only thing blocking the merge is a
+  bot's `CHANGES_REQUESTED` on an outdated head, the bot is rate limited or out
+  of review allowance so it cannot replace that verdict, and the local
+  adversarial review substitute is posted for the current head (step (e)).
+  Report the reviewer, the review id, both heads, the unresolved thread count,
+  and the dismissal decision a human needs to make. For example: *"PR #123 is
+  ready except for an old review from the review bot on an earlier version. The
+  bot is rate limited and cannot re-review, and I posted my own review of the
+  current version. Someone with dismissal rights needs to dismiss review 456,
+  or decide it should stand."* Do not wait for the bot's window to reset.
 - **`CLOSED`** → report (PR was closed without merge).
 - **Hard block needing a human**: an unresolvable conflict, a failing check that
   needs design input, or genuine unresolved human objection (not a bot gate). Stop
@@ -1591,7 +1647,8 @@ declare none, one, or several, and each shows its own evidence.
 
 Quote the description that was actually read. A report that says "rate limited"
 on a policy skip is a wrong record, and the two call for different operator
-actions: one clears itself, the other never will.
+actions: one clears itself, the other never will. Neither changes what this
+skill does in the meantime: it substitutes and keeps driving in both cases.
 
 `NOT REVIEWED` is reporting, and on a merged PR it is never a terminal state of
 its own: it does not turn a merged PR into a blocked one. What it does gate is

package/plugins/lisa-agy/skills/lisa-pull-request-review/SKILL.md

@@ -73,6 +73,14 @@ node scripts/check-skipped-required-checks.mjs --pr=<pr> --json
 It reports and never fails — a hollow check is often a vendor spending cap, not
 a repository defect, and it is not this skill's call to block on one.
 
+**Do not wait for a rate limit to reset, and do not re-request the review.** A
+`Review rate limited` status, including decorated forms such as
+`Review rate limited (retry in 12m)`, is handled like every other vacuous
+review. Report it here. `lisa-drive-pr-to-merge` then posts a local adversarial
+review substitute for the current head right away and keeps driving. Waiting
+out the window stalls the pull request for an hour or more and reads no code.
+Re-requesting overwrites the status and can destroy a real review.
+
 Carry the finding into your Step 4 report. **Do not write "no unresolved review
 threads" on its own** — it is true of an unreviewed PR too. Say which you
 observed:

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.87.0",
+  "version": "4.87.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.87.0",
+  "version": "4.87.1",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"