@codyswann/lisa 4.87.1 → 4.87.3

package/package.json

@@ -189,7 +189,7 @@
     "qs": "^6.16.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.87.1",
+  "version": "4.87.3",
   "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": "685c54f5fdefa2acbc9a412557124db84d898f79",
-  "gitHead": "685c54f5fdefa2acbc9a412557124db84d898f79",
-  "lisaReleaseTag": "v4.87.1"
+  "lisaReleaseCommit": "5a1944f7ad31a802d3f47945995b2f938f187a8d",
+  "gitHead": "5a1944f7ad31a802d3f47945995b2f938f187a8d",
+  "lisaReleaseTag": "v4.87.3"
 }

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

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

@@ -661,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

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

@@ -659,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

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,
       },

package/plugins/lisa-agy/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-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.87.1",
+  "version": "4.87.3",
   "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

@@ -659,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

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

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

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

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

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

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

package/plugins/lisa-copilot/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-copilot/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -659,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

package/plugins/lisa-copilot/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-copilot/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