@codyswann/lisa 4.87.0 → 4.87.2

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.87.0",
+  "version": "4.87.2",
   "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.2",
   "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
 
@@ -644,17 +661,24 @@ step (e) first — which discriminates a live objection from a stranded one by
 unresolved thread count, not by `reviewDecision` — and arm afterwards.
 
 **Two ruleset settings decide whether a standing verdict ever clears itself, and
-in this repository both say no.** Verify them for the repo you are in rather
-than assuming, with `gh api repos/<owner>/<repo>/rulesets`:
-
-- `dismiss_stale_reviews_on_push: false` — the review stays attached to the
-  commit it was made on, so **pushing the fix never clears it**. The intuition
-  that a new head resets the verdict is wrong here.
+neither one clears a change request.** Verify them for the repo you are in
+rather than assuming, with `gh api repos/<owner>/<repo>/rules/branches/<base>`
+(the rules in force on the base branch, with their parameters; the
+`gh api repos/<owner>/<repo>/rulesets` list carries no rule parameters):
+
+- `dismiss_stale_reviews_on_push` dismisses stale **approvals** only. The `base`
+  ruleset Lisa generates defaults it to `true` when
+  `policy.protect.dismiss_stale_reviews` is undeclared, and keeps a declared
+  value (CodySwannGT/lisa#4574), but a
+  `CHANGES_REQUESTED` review made on an older head stays in force after a push
+  under either setting (measured on a probe repository on 2026-11-01: the push
+  changed the diff and `reviewDecision` stayed `CHANGES_REQUESTED`), so
+  **pushing the fix never clears it**.
 - `required_approving_review_count: 0` — no approval is required to merge, so a
   standing `CHANGES_REQUESTED` is not holding a slot for a review that would
   otherwise arrive. Nothing is scheduled to clear it.
 
-Together those mean the block is **indefinite, not slow**. Waiting is not a
+Where both hold, the block is **indefinite, not slow**. Waiting is not a
 strategy; something has to act.
 
 **Unresolved threads block independently of the verdict.** This repository sets
@@ -1048,10 +1072,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 +1197,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 +1508,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 +1538,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 +1656,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/.codex-plugin/skills/lisa-secrets-access/SKILL.md

@@ -275,7 +275,7 @@ No create, no update, no rotate. Writing secrets or their notes requires an auth
 
 The two writers are siblings, not modes: `rotate-secret.mjs` replaces a value **at its source**, and `sync-secret-to-ci.mjs` copies one **into a second store** without touching the source. Each needs an authority the resolver must not hold, so each is its own program with its own declaration list.
 
-A third, narrow writer lives outside this skill: the session manager's `store-token` (`lisa-session-manager/scripts/token-store.mjs`) stores the Telegram bot token as `TELEGRAM_BOT_TOKEN_<NAME>` through `providers.mjs` `createSecret` (a new record) or `writeSecret` (`--replace`), then reads it back through the ordinary provider view and compares hashes before deleting the plaintext file it replaces. It writes that one name only, and only when an operator runs it. `createSecret` is Bitwarden-only; on any other provider the operator creates the secret and `store-token` verifies it. Like `bws secret edit`, `bws secret create` (2.1.0) takes the value as a positional argument and its help offers no stdin or file option, so the value is in argv for the life of that one call: the same documented exception, confined the same way (no shell, `--output none`, and a failure message that never repeats the command line).
+A third, narrow writer lives outside this skill: the session manager's `store-token` (`lisa-session-manager/scripts/token-store.mjs`) stores the Telegram bot token as `TELEGRAM_BOT_TOKEN_<NAME>` through `providers.mjs` `createSecret` (a new record) or `writeSecret` (`--replace`), then reads it back through the ordinary provider view and compares hashes before deleting the plaintext file it replaces. It writes that one name only, and only when an operator runs it. `createSecret` is Bitwarden-only; on any other provider the operator creates the secret and `store-token` verifies it. Like `bws secret edit`, `bws secret create` (2.1.0) takes the value as a positional argument and its help offers no stdin or file option, so the value is in argv for the life of that one call: the second documented exception in Rule 4, held to the same limits (no shell, the CLI's output never shown, here through `--output none`, and a failure message that never repeats the command line).
 
 ## Rotating credentials
 
@@ -429,6 +429,6 @@ Cache **in-process only**. Never write a resolved value to disk except through t
 1. **Never read a keychain, `.env`, or provider CLI outside this skill.** One chokepoint is what makes the single-store rule enforceable.
 2. **Never log a secret value.** Print a length or a hash prefix when proving identity.
 3. **Never write a resolved value to disk** except through the materialization contract, on a surface whose capabilities permit it.
-4. **Never pass a secret as a command-line argument.** The one documented exception is the Bitwarden rotation write, whose CLI exposes no stdin path; it is confined to that single operation and noted in the code.
+4. **Never pass a secret as a command-line argument.** There are two documented exceptions, both Bitwarden writes whose CLI (2.1.0) takes the value only on the command line: `bws secret edit --value` (the rotation write, `writeSecret`) and `bws secret create` (`store-token`'s `createSecret`). Each is confined to that single operation and noted in the code, and both are held to the same limits: no shell, the CLI's output (which echoes the record) is never shown (`create` passes `--output none`; `edit`'s output is captured and discarded), and a failure message never repeats the command line.
 5. **Verify a credential when it is stored, not when it is first used.** An unverified credential is indistinguishable from a broken one, and the gap between the two is measured in weeks.
 6. **Treat a mismatch as stop-and-ask.** If a value differs between two places, they are two live credentials — not a stale copy to be discarded. Deleting the one you cannot verify leaves a working credential that no record accounts for.

package/plugins/lisa/.codex-plugin/skills/lisa-session-manager/scripts/cli-usage.mjs

@@ -170,8 +170,8 @@ Per cycle
                            [--sender <name>]               STDIN: question
       --kind: worker-question (default) | repo-route | exhausted | decision.
       No message id with no channel. A re-ask keeps the item's marker
-      fields (markerType, marker, markedAt); a queued answer survives only a
-      re-ping of the same text.
+      fields (markerType, marker); markedAt and a queued answer survive only
+      a re-ping of the same text, so a changed question must be marked again.
   ledger marked <ref> --marker-type label|role --marker <value>
                      --comment-id <id>
       Records that the human-needed marker was applied on the tracker and

package/plugins/lisa/.codex-plugin/skills/lisa-session-manager/scripts/ledger-questions.mjs

@@ -177,9 +177,14 @@ export function listPendingQuestions(ledger, answerCommand) {
  * gets a placeholder item with zero attempts.
  *
  * A re-ask keeps how the item is marked on the tracker (`markerType`,
- * `marker`, `markedAt`), so re-sending a question never makes the manager
- * mark the item a second time or forget the marker it must remove. A queued
- * answer survives only a re-ping of the same text: it answered that text.
+ * `marker`), so re-sending a question never makes the manager forget the
+ * marker it must remove. `markedAt` survives only a re-ping of the same text:
+ * a changed question has not been posted or read back yet, so it reads as
+ * unmarked until `ledger marked` records the new question comment. Keeping it
+ * would let the next cycle run `item-answer` against the old question comment
+ * and queue a reply to the old question as the answer to the new one
+ * (CodySwannGT/lisa#4570). A queued answer survives only a re-ping of the same
+ * text for the same reason: it answered that text.
  * `kind` defaults to the previous kind, then `worker-question`.
  * @param {string} projectRoot - Absolute project root
  * @param {{ref: string, text: string, telegramMessageId: number|null,
@@ -213,7 +218,7 @@ export function setPendingQuestion(
         telegramMessageId: telegramMessageId ?? null,
         markerType: existing?.markerType ?? null,
         marker: existing?.marker ?? null,
-        markedAt: existing?.markedAt ?? null,
+        markedAt: sameText ? (existing?.markedAt ?? null) : null,
         managerCommentIds: existing?.managerCommentIds ?? [],
         answer: sameText ? (existing.answer ?? null) : null,
       },

package/plugins/lisa/hooks/block-blind-automerge.sh

@@ -16,11 +16,13 @@
 # for hours before someone queried the field by hand.
 #
 # The stale case is the one actually observed, and it is the one prose cannot
-# help with: the `base` ruleset sets `dismiss_stale_reviews_on_push: false`, so
-# a CHANGES_REQUESTED review stays attached to the commit it was made on and
-# pushing the fix never clears it, while `required_approving_review_count: 0`
-# means no scheduled re-review will ever clear it either. The PR is blocked
-# indefinitely and every check-based signal reads ready.
+# help with: a CHANGES_REQUESTED review stays attached to the commit it was made
+# on and pushing the fix never clears it, while
+# `required_approving_review_count: 0` means no scheduled re-review will ever
+# clear it either. The PR is blocked indefinitely and every check-based signal
+# reads ready. `dismiss_stale_reviews_on_push` does not help: GitHub dismisses
+# stale APPROVALS only, so a change request survives a push under either
+# setting (measured 2026-11-01, CodySwannGT/lisa#4574).
 #
 # WHAT IT CHECKS, AND WHY THAT AND NOT THE CHECK ROLLUP
 #
@@ -1048,9 +1050,9 @@ REFUSAL = """Blocked: arming auto-merge on %s would report a merge that can neve
 
 GitHub reports reviewDecision = CHANGES_REQUESTED. That is a merge blocker with
 NO check-run representation: the failing-check count reads 0 and the checks tab
-is entirely green while the PR is permanently unmergeable. Where the ruleset
-sets dismiss_stale_reviews_on_push: false, pushing the fix does not clear it and
-no re-review is scheduled to.
+is entirely green while the PR is permanently unmergeable. Pushing the fix does
+not clear it (dismiss_stale_reviews_on_push dismisses stale approvals only, not
+change requests), and no re-review is scheduled to.
 
 Clear the blocker, then arm:
   - resolve every review thread and address or reply to the feedback

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
 
@@ -642,17 +659,24 @@ step (e) first — which discriminates a live objection from a stranded one by
 unresolved thread count, not by `reviewDecision` — and arm afterwards.
 
 **Two ruleset settings decide whether a standing verdict ever clears itself, and
-in this repository both say no.** Verify them for the repo you are in rather
-than assuming, with `gh api repos/<owner>/<repo>/rulesets`:
-
-- `dismiss_stale_reviews_on_push: false` — the review stays attached to the
-  commit it was made on, so **pushing the fix never clears it**. The intuition
-  that a new head resets the verdict is wrong here.
+neither one clears a change request.** Verify them for the repo you are in
+rather than assuming, with `gh api repos/<owner>/<repo>/rules/branches/<base>`
+(the rules in force on the base branch, with their parameters; the
+`gh api repos/<owner>/<repo>/rulesets` list carries no rule parameters):
+
+- `dismiss_stale_reviews_on_push` dismisses stale **approvals** only. The `base`
+  ruleset Lisa generates defaults it to `true` when
+  `policy.protect.dismiss_stale_reviews` is undeclared, and keeps a declared
+  value (CodySwannGT/lisa#4574), but a
+  `CHANGES_REQUESTED` review made on an older head stays in force after a push
+  under either setting (measured on a probe repository on 2026-11-01: the push
+  changed the diff and `reviewDecision` stayed `CHANGES_REQUESTED`), so
+  **pushing the fix never clears it**.
 - `required_approving_review_count: 0` — no approval is required to merge, so a
   standing `CHANGES_REQUESTED` is not holding a slot for a review that would
   otherwise arrive. Nothing is scheduled to clear it.
 
-Together those mean the block is **indefinite, not slow**. Waiting is not a
+Where both hold, the block is **indefinite, not slow**. Waiting is not a
 strategy; something has to act.
 
 **Unresolved threads block independently of the verdict.** This repository sets
@@ -1046,10 +1070,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 +1195,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 +1506,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 +1536,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 +1654,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/skills/lisa-secrets-access/SKILL.md

@@ -273,7 +273,7 @@ No create, no update, no rotate. Writing secrets or their notes requires an auth
 
 The two writers are siblings, not modes: `rotate-secret.mjs` replaces a value **at its source**, and `sync-secret-to-ci.mjs` copies one **into a second store** without touching the source. Each needs an authority the resolver must not hold, so each is its own program with its own declaration list.
 
-A third, narrow writer lives outside this skill: the session manager's `store-token` (`lisa-session-manager/scripts/token-store.mjs`) stores the Telegram bot token as `TELEGRAM_BOT_TOKEN_<NAME>` through `providers.mjs` `createSecret` (a new record) or `writeSecret` (`--replace`), then reads it back through the ordinary provider view and compares hashes before deleting the plaintext file it replaces. It writes that one name only, and only when an operator runs it. `createSecret` is Bitwarden-only; on any other provider the operator creates the secret and `store-token` verifies it. Like `bws secret edit`, `bws secret create` (2.1.0) takes the value as a positional argument and its help offers no stdin or file option, so the value is in argv for the life of that one call: the same documented exception, confined the same way (no shell, `--output none`, and a failure message that never repeats the command line).
+A third, narrow writer lives outside this skill: the session manager's `store-token` (`lisa-session-manager/scripts/token-store.mjs`) stores the Telegram bot token as `TELEGRAM_BOT_TOKEN_<NAME>` through `providers.mjs` `createSecret` (a new record) or `writeSecret` (`--replace`), then reads it back through the ordinary provider view and compares hashes before deleting the plaintext file it replaces. It writes that one name only, and only when an operator runs it. `createSecret` is Bitwarden-only; on any other provider the operator creates the secret and `store-token` verifies it. Like `bws secret edit`, `bws secret create` (2.1.0) takes the value as a positional argument and its help offers no stdin or file option, so the value is in argv for the life of that one call: the second documented exception in Rule 4, held to the same limits (no shell, the CLI's output never shown, here through `--output none`, and a failure message that never repeats the command line).
 
 ## Rotating credentials
 
@@ -427,6 +427,6 @@ Cache **in-process only**. Never write a resolved value to disk except through t
 1. **Never read a keychain, `.env`, or provider CLI outside this skill.** One chokepoint is what makes the single-store rule enforceable.
 2. **Never log a secret value.** Print a length or a hash prefix when proving identity.
 3. **Never write a resolved value to disk** except through the materialization contract, on a surface whose capabilities permit it.
-4. **Never pass a secret as a command-line argument.** The one documented exception is the Bitwarden rotation write, whose CLI exposes no stdin path; it is confined to that single operation and noted in the code.
+4. **Never pass a secret as a command-line argument.** There are two documented exceptions, both Bitwarden writes whose CLI (2.1.0) takes the value only on the command line: `bws secret edit --value` (the rotation write, `writeSecret`) and `bws secret create` (`store-token`'s `createSecret`). Each is confined to that single operation and noted in the code, and both are held to the same limits: no shell, the CLI's output (which echoes the record) is never shown (`create` passes `--output none`; `edit`'s output is captured and discarded), and a failure message never repeats the command line.
 5. **Verify a credential when it is stored, not when it is first used.** An unverified credential is indistinguishable from a broken one, and the gap between the two is measured in weeks.
 6. **Treat a mismatch as stop-and-ask.** If a value differs between two places, they are two live credentials — not a stale copy to be discarded. Deleting the one you cannot verify leaves a working credential that no record accounts for.

package/plugins/lisa/skills/lisa-session-manager/scripts/cli-usage.mjs

@@ -170,8 +170,8 @@ Per cycle
                            [--sender <name>]               STDIN: question
       --kind: worker-question (default) | repo-route | exhausted | decision.
       No message id with no channel. A re-ask keeps the item's marker
-      fields (markerType, marker, markedAt); a queued answer survives only a
-      re-ping of the same text.
+      fields (markerType, marker); markedAt and a queued answer survive only
+      a re-ping of the same text, so a changed question must be marked again.
   ledger marked <ref> --marker-type label|role --marker <value>
                      --comment-id <id>
       Records that the human-needed marker was applied on the tracker and

package/plugins/lisa/skills/lisa-session-manager/scripts/ledger-questions.mjs

@@ -177,9 +177,14 @@ export function listPendingQuestions(ledger, answerCommand) {
  * gets a placeholder item with zero attempts.
  *
  * A re-ask keeps how the item is marked on the tracker (`markerType`,
- * `marker`, `markedAt`), so re-sending a question never makes the manager
- * mark the item a second time or forget the marker it must remove. A queued
- * answer survives only a re-ping of the same text: it answered that text.
+ * `marker`), so re-sending a question never makes the manager forget the
+ * marker it must remove. `markedAt` survives only a re-ping of the same text:
+ * a changed question has not been posted or read back yet, so it reads as
+ * unmarked until `ledger marked` records the new question comment. Keeping it
+ * would let the next cycle run `item-answer` against the old question comment
+ * and queue a reply to the old question as the answer to the new one
+ * (CodySwannGT/lisa#4570). A queued answer survives only a re-ping of the same
+ * text for the same reason: it answered that text.
  * `kind` defaults to the previous kind, then `worker-question`.
  * @param {string} projectRoot - Absolute project root
  * @param {{ref: string, text: string, telegramMessageId: number|null,
@@ -213,7 +218,7 @@ export function setPendingQuestion(
         telegramMessageId: telegramMessageId ?? null,
         markerType: existing?.markerType ?? null,
         marker: existing?.marker ?? null,
-        markedAt: existing?.markedAt ?? null,
+        markedAt: sameText ? (existing?.markedAt ?? null) : null,
         managerCommentIds: existing?.managerCommentIds ?? [],
         answer: sameText ? (existing.answer ?? null) : null,
       },