@codyswann/lisa 2.332.3 → 2.332.5

package/plugins/lisa-agy/skills/lisa-secrets-access/scripts/materialize-secrets.mjs

@@ -21,11 +21,15 @@
 
 import {
   chmodSync,
+  existsSync,
   mkdirSync,
+  readFileSync,
   renameSync,
   rmSync,
   writeFileSync,
 } from "node:fs";
+import { homedir } from "node:os";
+import { join } from "node:path";
 
 import { deriveAwsEnvironment } from "./aws-bootstrap.mjs";
 import { renderEnv, renderNotes } from "./envfile.mjs";
@@ -58,6 +62,70 @@ function writeAtomic(destination, contents) {
  * @param {object} [cfg] Resolved configuration.
  * @returns {{count: number, dir: string}} What was written, and where.
  */
+/** Marks the block this owns, so it is replaced rather than appended twice. */
+const PROFILE_MARKER = "# >>> lisa secrets (managed) >>>";
+
+/** Closes the managed block. */
+const PROFILE_END = "# <<< lisa secrets (managed) <<<";
+
+/**
+ * Make every shell in this container load the materialized secrets.
+ *
+ * `set -a` so the values are exported rather than merely set as shell
+ * variables, and sourced LAST so they win over anything the host injected —
+ * environment variables outrank profile files in AWS's credential chain, which
+ * is the whole reason a valid credential was being ignored.
+ *
+ * Guarded on the file existing, so a shell still starts cleanly before the
+ * first materialization or if the file is removed. Written to both `.bashrc`
+ * and `.profile` because which one a given shell reads depends on whether it is
+ * interactive or a login shell, and an agent's tool calls are not reliably
+ * either.
+ * @param {string} valuesFile Absolute path to the materialized env file.
+ * @param {object} [options] Home directory and file seams, for tests.
+ * @returns {string[]} The profile files that now source it.
+ */
+export function installProfileSourcing(valuesFile, options = {}) {
+  const {
+    home = process.env.HOME || homedir(),
+    exists = existsSync,
+    read = readFileSync,
+    write = writeFileSync,
+  } = options;
+
+  const block = [
+    PROFILE_MARKER,
+    `if [ -f "${valuesFile}" ]; then`,
+    `  set -a`,
+    `  . "${valuesFile}"`,
+    `  set +a`,
+    `fi`,
+    PROFILE_END,
+  ].join("\n");
+
+  const updated = [];
+  for (const name of [".bashrc", ".profile"]) {
+    const file = join(home, name);
+    const current = exists(file) ? String(read(file, "utf8")) : "";
+
+    // Replace an existing managed block rather than appending another: this
+    // runs on every session, and an appended-forever profile is its own bug.
+    const start = current.indexOf(PROFILE_MARKER);
+    const next =
+      start === -1
+        ? `${current}${current.endsWith("\n") || !current ? "" : "\n"}\n${block}\n`
+        : `${current.slice(0, start)}${block}${current.slice(
+            current.indexOf(PROFILE_END, start) + PROFILE_END.length
+          )}`;
+
+    if (next !== current) {
+      write(file, next, { mode: 0o600 });
+      updated.push(file);
+    }
+  }
+  return updated;
+}
+
 export function materialize(cfg = readConfig()) {
   if (!cfg.capabilities.mayWriteValues) {
     throw new Error(
@@ -88,7 +156,21 @@ export function materialize(cfg = readConfig()) {
   chmodSync(dir, 0o700);
   writeAtomic(valuesFile, renderEnv(selected));
   writeAtomic(notesFile, renderNotes(selected));
-  return { count: selected.size, derived: derived.size, dir };
+
+  // Writing the file is not the same as the values being in effect.
+  //
+  // A materialized secrets.env that nothing sources changes nothing: the agent's
+  // shell starts from the container's own environment, so a host-injected
+  // AWS_ACCESS_KEY_ID keeps winning and every call fails with
+  // InvalidClientTokenId while the correct credential sits on disk, correct and
+  // unused. Deriving the variables (above) only fixes precedence WITHIN the
+  // file — something still has to load the file.
+  //
+  // So the shell profile sources it. That is what makes "the credential is
+  // materialized" and "the credential is usable" the same statement.
+  const sourced = installProfileSourcing(valuesFile);
+
+  return { count: selected.size, derived: derived.size, dir, sourced };
 }
 
 function main() {

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.332.3",
+  "version": "2.332.5",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

package/plugins/lisa-copilot/hooks/block-no-verify.sh

@@ -20,18 +20,41 @@ set -euo pipefail
 
 input="$(cat)"
 
-tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
+# Both interpreters must be probed BEFORE they are used, and a missing one must
+# be announced rather than swallowed.
+#
+# `jq` used to be called unguarded here while `python3` two lines below was
+# guarded. Under `set -e` an absent jq aborted the script with 127, and Claude
+# Code treats any non-2 exit as a NON-BLOCKING hook error — so the hook that
+# enforces "never --no-verify" silently permitted the very thing it exists to
+# stop. It was not hypothetical: agent containers routinely ship no jq (that is
+# why jq is now a pinned toolchain entry). The Codex variant of this script has
+# always had the guard, so this was a parity gap rather than a design choice.
+#
+# Degrading to "allow" is still the right behaviour — a hook that cannot parse
+# its input cannot tell a bypass from an ordinary command, and failing closed
+# would block every Bash call on a machine missing an interpreter. What is NOT
+# right is doing it quietly, so the operator gets one line on stderr saying the
+# protection is off. A guard that is silently absent reads exactly like a guard
+# that is passing.
+for required in jq python3; do
+  if ! command -v "$required" >/dev/null 2>&1; then
+    printf 'block-no-verify: %s not found; --no-verify protection is NOT active\n' \
+      "$required" >&2
+    exit 0
+  fi
+done
+
+tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty' 2>/dev/null || true)"
 if [ "$tool_name" != "Bash" ]; then
   exit 0
 fi
 
-command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty')"
+command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty' 2>/dev/null || true)"
 if [ -z "$command_str" ]; then
   exit 0
 fi
 
-command -v python3 >/dev/null 2>&1 || exit 0
-
 if ! BLOCK_NO_VERIFY_COMMAND="$command_str" python3 - <<'PY'
 import os
 import re

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

@@ -126,13 +126,50 @@ auto-merge against a stale head you have not verified.
 `gh pr merge <pr> --auto --<merge_method>`. Enabling auto-merge is **not terminal**
 — continue the loop below until the PR is actually `MERGED` or `CLOSED`.
 
-If any later step will push commits, temporarily remove the auto-merge latch
-before the push when GitHub exposes that mutation (`disablePullRequestAutoMerge`),
-or otherwise treat the push as a merge race: immediately re-read `headRefOid`,
-reset `verify_commit` to the pushed head, wait until that head's checks have
-started, then re-enable auto-merge. Do not leave auto-merge armed while a
-required fix, CodeRabbit follow-up, generated artifact update, or CI auto-fix is
-still in flight.
+**With `auto_merge=true`, leave the latch ARMED — never disable auto-merge.**
+(Under `auto_merge=false` the deliberate disarm above still applies: that mode
+must leave the PR open for a human, so a pre-existing latch is removed on
+purpose. Everything below is the `auto_merge=true` path.)
+
+Once a fix is PUSHED the latch is safe: GitHub evaluates required checks against
+the PR's current head, so a new commit whose checks have not reported leaves the
+PR blocked. Auto-merge cannot ship a commit nothing has verified.
+
+The only window a disarm ever protected is the gap between deciding to fix
+something and that fix landing — during which the PR is genuinely green and
+genuinely mergeable, and auto-merge firing is GitHub behaving correctly. Two
+merges in this repo's history are attributed to that window (#1392, and the
+release that shipped the `./hooks/` Cursor bug). Both were fixed forward within
+minutes; one was a one-line docs inconsistency.
+
+That evidence is also weaker than it looks: **auto-merge attributes the merge to
+whoever enabled it**, so an auto-merge and a human pressing Merge are
+indistinguishable in the timeline. The record cannot tell us those PRs were not
+simply merged by hand while the latch happened to be armed.
+
+Against that, disarming costs something certain. Disabling is a durable state
+change on GitHub; re-enabling is one more step the run has to reach. When a run
+ends in between — turns exhausted, job timeout, or you concluding the work while
+checks are still pending — the latch stays off and nothing restores it. The PR is
+left WORSE OFF THAN IF THIS SKILL HAD NEVER RUN: it has lost the mechanism that
+merges it while no agent is watching, and the run reports success. Measured on
+`gunnertech/frontend#282`, the latch went off 14s before the fix commit and the
+PR sat 26 minutes after going green, against ~3 minutes for PRs this skill never
+touched.
+
+So the trade is a rare, unproven miss that costs a fix-forward PR, against a
+frequent, silent stall on every PR this skill repairs. Take the rare one.
+
+What still applies on a push: immediately re-read `headRefOid` and reset
+`verify_commit` to the pushed head, so the shipped-verification in step 3 checks
+what you actually pushed rather than the commit you replaced. That ancestry check
+is what CATCHES a raced merge — it fails loudly when the fix SHA is not an
+ancestor of the base branch — so the rare miss is detected rather than silent.
+
+**Invariant:** never terminate having left auto-merge OFF on an open PR when
+`auto_merge=true`. If some future path does disable it, restoring it is a
+terminal obligation on EVERY exit — including give-up, budget-exhausted and error
+paths — not a later step in a sequence.
 
 - **Capability fallback** (`auto_merge=true` only): if the repo disallows
   auto-merge, do not fail. Keep watching; once checks are green, the review gate
@@ -215,10 +252,9 @@ registered you will instead see real conflict markers — run
 ### c. Failing CI / deploy checks (`statusCheckRollup` has FAILURE)
 Inspect the failing check's logs (`gh pr checks <pr>`, `gh run view <run> --log-failed`).
 Fix the underlying code inline — **never lower thresholds, skip tests, or disable
-checks** to force green. Before pushing the fix, disarm auto-merge or classify the
-run as race-prone, then after the push re-read the PR head, update `verify_commit`
-to that exact SHA, wait for checks on that head to start, and only then resume
-auto-merge. When the root cause is an upstream Lisa template/postinstall bug
+checks** to force green. Leave auto-merge armed across the push (section 1);
+after it, re-read the PR head and update `verify_commit` to that exact SHA so the
+shipped-verification checks what you pushed. When the root cause is an upstream Lisa template/postinstall bug
 rather than this project's code, fix it upstream and propagate down rather than
 patching only here.
 
@@ -227,10 +263,9 @@ Delegate to the `pull-request-review` skill with the PR number. It owns the whol
 comment cycle: fetch every unresolved human + bot thread (with resolution state via
 GraphQL), implement valid feedback (commit + push), reply to invalid feedback, and
 resolve every thread via `resolveReviewThread` so the branch-protection
-thread-resolution gate clears. If that skill needs to push a commit, auto-merge
-must be disabled first when possible; when it returns, re-read `headRefOid`, reset
-`verify_commit` to the returned/pushed head, wait for that head's checks to start,
-then re-enable auto-merge and continue. Do not re-implement review handling here
+thread-resolution gate clears. If that skill needs to push a commit, leave
+auto-merge armed (section 1); when it returns, re-read `headRefOid` and reset
+`verify_commit` to the returned/pushed head, then continue. Do not re-implement review handling here
 — it is the single source of truth for review-thread handling.
 
 ### e. Review gate stall (`reviewDecision == CHANGES_REQUESTED`)
@@ -252,9 +287,9 @@ branch (the CI auto-fix workflow engaged before this session took the lease),
 adjudicate it: merge it into the head branch if the fix is correct and still
 needed, otherwise close it and delete the side branch. Never leave it dangling
 — it represents a competing writer's pending work. Merging it mutates the
-driven branch, so treat it like any other push: disarm auto-merge first,
-re-read `headRefOid`, reset `verify_commit` to the merged head, wait for that
-head's checks to start, then re-enable auto-merge (section 1). In
+driven branch, so treat it like any other push: leave auto-merge armed
+(section 1), then re-read `headRefOid` and reset `verify_commit` to the merged
+head. In
 `on_blocker=report` mode this whole step is off-limits (diagnose-only): do not
 merge, close, or delete anything — return `blocked:pending-auto-fix`.
 

package/plugins/lisa-copilot/skills/lisa-secrets-access/scripts/materialize-secrets.mjs

@@ -21,11 +21,15 @@
 
 import {
   chmodSync,
+  existsSync,
   mkdirSync,
+  readFileSync,
   renameSync,
   rmSync,
   writeFileSync,
 } from "node:fs";
+import { homedir } from "node:os";
+import { join } from "node:path";
 
 import { deriveAwsEnvironment } from "./aws-bootstrap.mjs";
 import { renderEnv, renderNotes } from "./envfile.mjs";
@@ -58,6 +62,70 @@ function writeAtomic(destination, contents) {
  * @param {object} [cfg] Resolved configuration.
  * @returns {{count: number, dir: string}} What was written, and where.
  */
+/** Marks the block this owns, so it is replaced rather than appended twice. */
+const PROFILE_MARKER = "# >>> lisa secrets (managed) >>>";
+
+/** Closes the managed block. */
+const PROFILE_END = "# <<< lisa secrets (managed) <<<";
+
+/**
+ * Make every shell in this container load the materialized secrets.
+ *
+ * `set -a` so the values are exported rather than merely set as shell
+ * variables, and sourced LAST so they win over anything the host injected —
+ * environment variables outrank profile files in AWS's credential chain, which
+ * is the whole reason a valid credential was being ignored.
+ *
+ * Guarded on the file existing, so a shell still starts cleanly before the
+ * first materialization or if the file is removed. Written to both `.bashrc`
+ * and `.profile` because which one a given shell reads depends on whether it is
+ * interactive or a login shell, and an agent's tool calls are not reliably
+ * either.
+ * @param {string} valuesFile Absolute path to the materialized env file.
+ * @param {object} [options] Home directory and file seams, for tests.
+ * @returns {string[]} The profile files that now source it.
+ */
+export function installProfileSourcing(valuesFile, options = {}) {
+  const {
+    home = process.env.HOME || homedir(),
+    exists = existsSync,
+    read = readFileSync,
+    write = writeFileSync,
+  } = options;
+
+  const block = [
+    PROFILE_MARKER,
+    `if [ -f "${valuesFile}" ]; then`,
+    `  set -a`,
+    `  . "${valuesFile}"`,
+    `  set +a`,
+    `fi`,
+    PROFILE_END,
+  ].join("\n");
+
+  const updated = [];
+  for (const name of [".bashrc", ".profile"]) {
+    const file = join(home, name);
+    const current = exists(file) ? String(read(file, "utf8")) : "";
+
+    // Replace an existing managed block rather than appending another: this
+    // runs on every session, and an appended-forever profile is its own bug.
+    const start = current.indexOf(PROFILE_MARKER);
+    const next =
+      start === -1
+        ? `${current}${current.endsWith("\n") || !current ? "" : "\n"}\n${block}\n`
+        : `${current.slice(0, start)}${block}${current.slice(
+            current.indexOf(PROFILE_END, start) + PROFILE_END.length
+          )}`;
+
+    if (next !== current) {
+      write(file, next, { mode: 0o600 });
+      updated.push(file);
+    }
+  }
+  return updated;
+}
+
 export function materialize(cfg = readConfig()) {
   if (!cfg.capabilities.mayWriteValues) {
     throw new Error(
@@ -88,7 +156,21 @@ export function materialize(cfg = readConfig()) {
   chmodSync(dir, 0o700);
   writeAtomic(valuesFile, renderEnv(selected));
   writeAtomic(notesFile, renderNotes(selected));
-  return { count: selected.size, derived: derived.size, dir };
+
+  // Writing the file is not the same as the values being in effect.
+  //
+  // A materialized secrets.env that nothing sources changes nothing: the agent's
+  // shell starts from the container's own environment, so a host-injected
+  // AWS_ACCESS_KEY_ID keeps winning and every call fails with
+  // InvalidClientTokenId while the correct credential sits on disk, correct and
+  // unused. Deriving the variables (above) only fixes precedence WITHIN the
+  // file — something still has to load the file.
+  //
+  // So the shell profile sources it. That is what makes "the credential is
+  // materialized" and "the credential is usable" the same statement.
+  const sourced = installProfileSourcing(valuesFile);
+
+  return { count: selected.size, derived: derived.size, dir, sourced };
 }
 
 function main() {

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

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

package/plugins/lisa-cursor/hooks/block-no-verify.sh

@@ -20,18 +20,41 @@ set -euo pipefail
 
 input="$(cat)"
 
-tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
+# Both interpreters must be probed BEFORE they are used, and a missing one must
+# be announced rather than swallowed.
+#
+# `jq` used to be called unguarded here while `python3` two lines below was
+# guarded. Under `set -e` an absent jq aborted the script with 127, and Claude
+# Code treats any non-2 exit as a NON-BLOCKING hook error — so the hook that
+# enforces "never --no-verify" silently permitted the very thing it exists to
+# stop. It was not hypothetical: agent containers routinely ship no jq (that is
+# why jq is now a pinned toolchain entry). The Codex variant of this script has
+# always had the guard, so this was a parity gap rather than a design choice.
+#
+# Degrading to "allow" is still the right behaviour — a hook that cannot parse
+# its input cannot tell a bypass from an ordinary command, and failing closed
+# would block every Bash call on a machine missing an interpreter. What is NOT
+# right is doing it quietly, so the operator gets one line on stderr saying the
+# protection is off. A guard that is silently absent reads exactly like a guard
+# that is passing.
+for required in jq python3; do
+  if ! command -v "$required" >/dev/null 2>&1; then
+    printf 'block-no-verify: %s not found; --no-verify protection is NOT active\n' \
+      "$required" >&2
+    exit 0
+  fi
+done
+
+tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty' 2>/dev/null || true)"
 if [ "$tool_name" != "Bash" ]; then
   exit 0
 fi
 
-command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty')"
+command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty' 2>/dev/null || true)"
 if [ -z "$command_str" ]; then
   exit 0
 fi
 
-command -v python3 >/dev/null 2>&1 || exit 0
-
 if ! BLOCK_NO_VERIFY_COMMAND="$command_str" python3 - <<'PY'
 import os
 import re

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

@@ -126,13 +126,50 @@ auto-merge against a stale head you have not verified.
 `gh pr merge <pr> --auto --<merge_method>`. Enabling auto-merge is **not terminal**
 — continue the loop below until the PR is actually `MERGED` or `CLOSED`.
 
-If any later step will push commits, temporarily remove the auto-merge latch
-before the push when GitHub exposes that mutation (`disablePullRequestAutoMerge`),
-or otherwise treat the push as a merge race: immediately re-read `headRefOid`,
-reset `verify_commit` to the pushed head, wait until that head's checks have
-started, then re-enable auto-merge. Do not leave auto-merge armed while a
-required fix, CodeRabbit follow-up, generated artifact update, or CI auto-fix is
-still in flight.
+**With `auto_merge=true`, leave the latch ARMED — never disable auto-merge.**
+(Under `auto_merge=false` the deliberate disarm above still applies: that mode
+must leave the PR open for a human, so a pre-existing latch is removed on
+purpose. Everything below is the `auto_merge=true` path.)
+
+Once a fix is PUSHED the latch is safe: GitHub evaluates required checks against
+the PR's current head, so a new commit whose checks have not reported leaves the
+PR blocked. Auto-merge cannot ship a commit nothing has verified.
+
+The only window a disarm ever protected is the gap between deciding to fix
+something and that fix landing — during which the PR is genuinely green and
+genuinely mergeable, and auto-merge firing is GitHub behaving correctly. Two
+merges in this repo's history are attributed to that window (#1392, and the
+release that shipped the `./hooks/` Cursor bug). Both were fixed forward within
+minutes; one was a one-line docs inconsistency.
+
+That evidence is also weaker than it looks: **auto-merge attributes the merge to
+whoever enabled it**, so an auto-merge and a human pressing Merge are
+indistinguishable in the timeline. The record cannot tell us those PRs were not
+simply merged by hand while the latch happened to be armed.
+
+Against that, disarming costs something certain. Disabling is a durable state
+change on GitHub; re-enabling is one more step the run has to reach. When a run
+ends in between — turns exhausted, job timeout, or you concluding the work while
+checks are still pending — the latch stays off and nothing restores it. The PR is
+left WORSE OFF THAN IF THIS SKILL HAD NEVER RUN: it has lost the mechanism that
+merges it while no agent is watching, and the run reports success. Measured on
+`gunnertech/frontend#282`, the latch went off 14s before the fix commit and the
+PR sat 26 minutes after going green, against ~3 minutes for PRs this skill never
+touched.
+
+So the trade is a rare, unproven miss that costs a fix-forward PR, against a
+frequent, silent stall on every PR this skill repairs. Take the rare one.
+
+What still applies on a push: immediately re-read `headRefOid` and reset
+`verify_commit` to the pushed head, so the shipped-verification in step 3 checks
+what you actually pushed rather than the commit you replaced. That ancestry check
+is what CATCHES a raced merge — it fails loudly when the fix SHA is not an
+ancestor of the base branch — so the rare miss is detected rather than silent.
+
+**Invariant:** never terminate having left auto-merge OFF on an open PR when
+`auto_merge=true`. If some future path does disable it, restoring it is a
+terminal obligation on EVERY exit — including give-up, budget-exhausted and error
+paths — not a later step in a sequence.
 
 - **Capability fallback** (`auto_merge=true` only): if the repo disallows
   auto-merge, do not fail. Keep watching; once checks are green, the review gate
@@ -215,10 +252,9 @@ registered you will instead see real conflict markers — run
 ### c. Failing CI / deploy checks (`statusCheckRollup` has FAILURE)
 Inspect the failing check's logs (`gh pr checks <pr>`, `gh run view <run> --log-failed`).
 Fix the underlying code inline — **never lower thresholds, skip tests, or disable
-checks** to force green. Before pushing the fix, disarm auto-merge or classify the
-run as race-prone, then after the push re-read the PR head, update `verify_commit`
-to that exact SHA, wait for checks on that head to start, and only then resume
-auto-merge. When the root cause is an upstream Lisa template/postinstall bug
+checks** to force green. Leave auto-merge armed across the push (section 1);
+after it, re-read the PR head and update `verify_commit` to that exact SHA so the
+shipped-verification checks what you pushed. When the root cause is an upstream Lisa template/postinstall bug
 rather than this project's code, fix it upstream and propagate down rather than
 patching only here.
 
@@ -227,10 +263,9 @@ Delegate to the `pull-request-review` skill with the PR number. It owns the whol
 comment cycle: fetch every unresolved human + bot thread (with resolution state via
 GraphQL), implement valid feedback (commit + push), reply to invalid feedback, and
 resolve every thread via `resolveReviewThread` so the branch-protection
-thread-resolution gate clears. If that skill needs to push a commit, auto-merge
-must be disabled first when possible; when it returns, re-read `headRefOid`, reset
-`verify_commit` to the returned/pushed head, wait for that head's checks to start,
-then re-enable auto-merge and continue. Do not re-implement review handling here
+thread-resolution gate clears. If that skill needs to push a commit, leave
+auto-merge armed (section 1); when it returns, re-read `headRefOid` and reset
+`verify_commit` to the returned/pushed head, then continue. Do not re-implement review handling here
 — it is the single source of truth for review-thread handling.
 
 ### e. Review gate stall (`reviewDecision == CHANGES_REQUESTED`)
@@ -252,9 +287,9 @@ branch (the CI auto-fix workflow engaged before this session took the lease),
 adjudicate it: merge it into the head branch if the fix is correct and still
 needed, otherwise close it and delete the side branch. Never leave it dangling
 — it represents a competing writer's pending work. Merging it mutates the
-driven branch, so treat it like any other push: disarm auto-merge first,
-re-read `headRefOid`, reset `verify_commit` to the merged head, wait for that
-head's checks to start, then re-enable auto-merge (section 1). In
+driven branch, so treat it like any other push: leave auto-merge armed
+(section 1), then re-read `headRefOid` and reset `verify_commit` to the merged
+head. In
 `on_blocker=report` mode this whole step is off-limits (diagnose-only): do not
 merge, close, or delete anything — return `blocked:pending-auto-fix`.