docs(plan-fleet): plan mode is a property of the dispatch, not a default

.claude/commands/plan-fleet.md

@@ -99,13 +99,22 @@ all of them things a child must be told:**
 
 Call the Claude Code Remote `create_session` tool with
 `source_url: https://github.com/button-inc/batten`, `model: claude-opus-5`,
-`permission_mode: "plan"`, tags `["batten-bundle", "ready-queue-<YYYY-MM-DD>"]`,
+tags `["batten-bundle", "ready-queue-<YYYY-MM-DD>"]`,
 and a title of the form `BUNDLE <domain> — CLOUD-<a> → CLOUD-<b>`.
 
-**Plan mode is correct here and is also this environment's default.** The child
-plans, a human approves in the web UI, and it then works on. Its one failure
-mode is a child nobody intends to approve — that stalls indefinitely, so only
-omit it when dispatching genuinely fire-and-forget work.
+**Whether to pass `permission_mode: "plan"` is a property of the DISPATCH, not
+of the bundle.** Pass it when a human is standing by to approve in the web UI;
+omit it when the dispatch is fire-and-forget. The same bundle takes opposite
+answers depending on which is true, so the choice is made per dispatch and not
+once per ticket.
+
+It is **not** a default, and **not** this environment's: `create_session`
+inherits the caller's mode, and dispatchers here run `auto`, so omitting it
+yields `PERMISSION_MODE_AUTO`. Unattended, plan mode is not a free extra gate —
+one child parked 91 minutes on `AskUserQuestion` for no commit, branch or PR.
+Attended it is the cheapest review point there is: the five CLOUD-607 bundles
+dispatched in plan mode with the owner approving all reached `review_ready`.
+Reasoning in `mem:workflow/agent-fanout`; measurements on CLOUD-672.
 
 Reasoning effort is **not** a `create_session` parameter; children inherit the
 dispatching session's. Dispatch from a session at the effort you want.
@@ -121,7 +130,9 @@ Each prompt is standalone — the child starts from nothing — and carries:
    `mem:workflow/board-states`, the `.claude/rules/` file matching the surface,
    and any house-style section that governs the surface it touches.
 4. **The per-ticket loop**, verbatim in shape: `claim-check` → claim → plan
-   **this ticket only** and wait for approval → build, `verify`, `linear-check`,
+   **this ticket only** — waiting for approval only if this was a plan-mode
+   dispatch, since an unattended child told to wait never proceeds (CLOUD-672)
+   → build, `verify`, `linear-check`,
    draft PR, `land` backgrounded → next ticket. For a bundle dispatched under
    the one-PR shape (step 3b), the loop is `claim-check` → claim → plan **this
    ticket only** → build → commit → next ticket, with the draft PR, `verify`,

.claude/settings.json

@@ -67,6 +67,15 @@
             "command": "$CLAUDE_PROJECT_DIR/mise-tasks/board-move-guard"
           }
         ]
+      },
+      {
+        "matcher": ".*(subscribe_pr_activity|send_later|create_trigger)",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$CLAUDE_PROJECT_DIR/mise-tasks/connector-verb-guard"
+          }
+        ]
       }
     ],
     "PostToolUse": [

.serena/memories/workflow/agent-fanout.md

@@ -242,6 +242,30 @@ invisible until they bite:
   ExitPlanMode". That park is the feature — the child plans, a human approves,
   and it works on from there. It is only a defect for work nobody intends to
   approve, which then stalls forever. Pass it explicitly so the intent is legible.
+
+  **Both halves are false. Superseded 2026-08-18 (CLOUD-672).** `create_session`
+  inherits the **caller's** mode — the tool contract says "omit to inherit it" —
+  and dispatchers on this account run `auto`: two children dispatched with no
+  `permission_mode` came up `PERMISSION_MODE_AUTO`, not plan. The 2026-08-11
+  reading was taken from a dispatcher already in plan mode, so it measured
+  inheritance and recorded it as an environment property. The "only a defect for
+  work nobody intends to approve" bound is the normal case, not the edge: one
+  child parked **91 minutes** on `AskUserQuestion` — not `ExitPlanMode` — for
+  zero commits, branches or PRs, and the same ticket re-dispatched without the
+  parameter reached a draft PR. Plan mode does not add one gate at the end; it
+  raises the child's propensity to hand control back at all.
+
+  **The criterion is a property of the DISPATCH, not the ticket:** pass it when a
+  human is standing by to approve, omit it when the dispatch is fire-and-forget.
+  The same bundle takes opposite answers — plan mode was _correct_ for the five
+  CLOUD-607 BUNDLE children on 2026-08-14, all of which reached `review_ready`
+  with the owner approving in the web UI. That is the criterion working, not an
+  exception to it.
+
+  **Unmeasured, so do not lean on "works on from there":** one child declined a
+  write at end-of-session citing plan mode, hours after its plan was approved.
+  Whether the mode persists past approval or was re-entered is not established.
+
 - **Reasoning effort is not a `create_session` parameter.** Children inherit the
   dispatcher's, so dispatch from a session at the effort you want them to run at.
 - **In-process subagents are the wrong tool here, for a reason unrelated to

mise-tasks/connector-verb-guard

@@ -0,0 +1,151 @@
+#!/usr/bin/env bash
+#MISE description="PreToolUse hook body: decide the harness-connector verbs AGENTS.md already rules on, by tool-name SUFFIX, so the verdict survives the exposed server name changing (CLOUD-178)"
+#
+# CLOUD-178. A `.claude/settings.json` permission rule must name its server as a
+# LITERAL — `mcp-allow-check` refuses a glob in that segment, correctly, because
+# the CLI skips such a rule with a warning and it grants nothing. But a claude.ai
+# connector's exposed name is chosen per registration episode by the HOST:
+# readable at session start (`mcp__Linear__save_issue`), a UUID after a reconnect
+# (`mcp__4db58e41-…__save_issue`). The literal that would match the second is an
+# account-specific identifier, which non-negotiable rule 1 keeps out of committed
+# config.
+#
+# So a permission rule cannot express these verdicts portably. CLOUD-178 concluded
+# from that "no gate is possible for this one". That conclusion was wrong, and the
+# counter-example was already shipping beside it: `issue-read-guard` and
+# `board-move-guard` match `*save_issue` on the SUFFIX and never read the server
+# segment at all. This file is that idiom applied to the verbs AGENTS.md rules on.
+#
+# MEASURED 2026-08-19, and it is why this exists rather than a fifth permission
+# rule. `.claude/settings.json` on `main` allows `mcp__Claude_Code_Remote__*` and
+# `mcp__Linear__*`; in the session that landed it the host exposed those same two
+# connectors as `mcp__bf7c680d-…__*` and `mcp__cc451d34-…__*`, so
+# `…__get_session` and `…__list_comments` both answered "requires approval" from
+# inside an allow list that reads as covering them. A second literal spelling is
+# still a literal.
+#
+# WHAT IT DECIDES, and every one is an existing AGENTS.md rule rather than a new
+# one this file invents:
+#
+#   unsubscribe_pr_activity   ALLOW  — dropping a subscription only ever narrows
+#                                      what reaches the session, and `land`'s
+#                                      `pr-unsubscribed` gate REQUIRES the drop
+#                                      before a runner is spent. An enforced path
+#                                      that prompts on every PR is a path that
+#                                      gets worked around instead of satisfied.
+#   subscribe_pr_activity     DENY   — "No heartbeats … to babysit a PR."
+#   send_later                DENY   — "No heartbeats (`send_later`/Routines/
+#   create_trigger            DENY     timers) to babysit a PR … the ban is on
+#                                      timers."
+#
+# The last two already sit in `permissions.deny` under a literal server name, and
+# that is precisely the shape measured inert above: a deny that under-matches
+# reads as a prohibition and enforces NOTHING. An allow that under-matches fails
+# the other way — into a prompt a human sees — which is why `mcp-allow-check`'s
+# new predicate binds denies and not allows.
+#
+# THE SUBSTRING HAZARD, AND WHICH DEFENCE ACTUALLY CARRIES IT.
+# `unsubscribe_pr_activity` ENDS WITH `subscribe_pr_activity`, so an unbounded
+# `*subscribe_pr_activity` test matches BOTH and denies the very call this file
+# exists to free — identical to the hazard `closing-key-check` records against
+# its own `DO-NOT-CLOSE` marker, where "the opt-out was unusable exactly when it
+# was written correctly, and it failed as the inverse of the author's intent
+# rather than as a refusal, which is the silent direction."
+#
+# Two independent defences, and the first is the structural one: the deny arm is
+# LEFT-BOUNDED on `__`, so `…__unsubscribe_pr_activity` cannot match
+# `*__subscribe_pr_activity` at all — the boundary character is `u`, not `s`.
+# Testing the allow arm FIRST is the second, and it is redundancy rather than the
+# mechanism. Said plainly because an earlier draft of this header claimed the
+# ordering was what carried it, and the mutation run disproved that: with the
+# allow arm deleted the unsubscribe rows fail by going UNDECIDED, never by being
+# denied. Neither defence alone is observable through the other, which is why the
+# suite carries a row for the bound (`…_v2`, `resubscribe_…`) as well as the
+# ordering.
+#
+# ALLOW IS A DECISION HERE, not an omission, and it is why this is a by-path guard
+# rather than a `batten.toml` row. The engine models `Decision::Allow` as "emit
+# nothing, exit 0", which leaves the ordinary permission flow to prompt. Actually
+# pre-approving needs `hookSpecificOutput.permissionDecision: "allow"` on stdout,
+# a variant the engine has no representation for. That is a capability gap on
+# CLOUD-312's ledger — a missing decision variant, not a missing rule kind.
+#
+# Pointer-only (non-negotiable 4): the decision names the verb and the rule, never
+# the payload.
+#
+# `--covers` prints the tool suffixes this file decides, one per line, so
+# `mcp-allow-check` can bind a deny rule to its coverage without grepping this
+# file's `case` statements. One authority per fact.
+#
+# Exit 0 always — a guard renders its verdict in the JSON, never in the status.
+# FAILS OPEN on everything it cannot establish, and on BATTEN_CONNECTOR_VERB_BYPASS=1.
+#
+# The mutation drops the allow arm, so an unsubscribe falls through UNDECIDED and
+# the approval prompt this file exists to remove comes back. Every deny row still
+# passes under it — only the unsubscribe rows can catch it, which is what makes
+# them the suite's spine and why they are written under both spellings.
+#MUTANT unsubscribe-not-preapproved|s@^ALLOW_SUFFIXES=.*@ALLOW_SUFFIXES=""@|an unsubscribe must be pre-approved, not merely left to the permission flow
+set -uo pipefail
+
+ALLOW_SUFFIXES="unsubscribe_pr_activity"
+DENY_SUFFIXES="subscribe_pr_activity send_later create_trigger"
+
+if [ "${1:-}" = "--covers" ]; then
+	for suffix in $ALLOW_SUFFIXES $DENY_SUFFIXES; do
+		printf '%s\n' "$suffix"
+	done
+	exit 0
+fi
+
+# CLOUD-479's pairing, declared rather than discovered: registered BY PATH, so
+# mise's `"aqua:jqlang/jq"` pin does not reach it and `jq` is whatever the ambient
+# PATH holds. Every read below fails open, so an absent parser would ALLOW
+# silently — the one outcome a guard must never reach by accident. Say so on
+# stderr and get out of the way; exit 2 is a DENY on this event and a broken
+# toolchain must not take that channel.
+#PIN-OK: jq
+if ! command -v jq >/dev/null 2>&1; then
+	echo "::error:: connector-verb-guard: no jq on PATH — this guard is registered by path, so it does not get mise's pinned jq. It is checking NOTHING and allowing every call. Run: mise install" >&2
+	exit 0
+fi
+
+[ -n "${BATTEN_CONNECTOR_VERB_BYPASS:-}" ] && exit 0
+
+raw=$(cat) || exit 0
+
+tool=$(printf '%s' "$raw" | jq -r '.tool_name // empty' 2>/dev/null) || exit 0
+[ -n "$tool" ] || exit 0
+
+decide() {
+	jq -n --arg d "$1" --arg r "$2" '{
+  hookSpecificOutput: {
+    hookEventName: "PreToolUse",
+    permissionDecision: $d,
+    permissionDecisionReason: $r
+  }
+}'
+	exit 0
+}
+
+# ALLOW FIRST. See the order note above: the deny suffix is a substring of this
+# one, so testing the other way round denies what this exists to permit.
+for suffix in $ALLOW_SUFFIXES; do
+	case "$tool" in
+	*__"$suffix" | "$suffix")
+		decide allow "connector-verb-guard: $suffix is pre-approved. Dropping a PR subscription only narrows what reaches this session, and \`mise run land\` refuses to land a PR whose subscription is still armed — so this must never wait on an approval. Record the drop afterwards: mise run pr-unsubscribed record <pr>."
+		;;
+	esac
+done
+
+# Left-bounded on `__` so it cannot reach back across the word boundary into
+# `unsubscribe_pr_activity`. The bare-name arm is for a host that exposes a verb
+# with no server prefix at all.
+for suffix in $DENY_SUFFIXES; do
+	case "$tool" in
+	*__"$suffix" | "$suffix")
+		decide deny "connector-verb-guard: $suffix is denied by AGENTS.md — no heartbeats (send_later/Routines/timers) and no babysitting a PR. Landing is driven by \`mise run land\`, which laps fetch -> rebase -> verify -> push -> ci-wait -> fast-forward by itself; a webhook's silence is not success. Bypass with BATTEN_CONNECTOR_VERB_BYPASS=1 when a human has asked for this specific call."
+		;;
+	esac
+done
+
+exit 0

mise-tasks/mcp-allow-check

@@ -5,7 +5,7 @@
 # symptom is an approval prompt on every call, which reads as harness behaviour
 # rather than as a settings bug. That silence is what earns a gate.
 #
-# Two predicates, both pure functions of the settings file:
+# Three predicates, all pure functions of the settings file:
 #
 #   unanchored-allow-glob     an allow rule whose glob reaches the server
 #                             segment. The CLI accepts a tool-name glob only
@@ -24,8 +24,16 @@
 #                             mandates stalled behind an approval prompt this
 #                             repo had already decided to give.
 #
-# Deny rules are deliberately not checked: a deny may glob freely, and a deny
-# that over-matches fails closed rather than silently.
+#   uncovered-connector-deny  a deny naming ONE host-supplied server and ONE
+#                             tool, both literally, that no suffix-matching
+#                             guard covers. Detail and the measurement are
+#                             beside the predicate at the foot of this file.
+#
+# A deny may still glob freely — `mcp__*` is a broad prohibition rather than a
+# misspelled narrow one, and a deny that OVER-matches fails closed. What the
+# third predicate added is the opposite direction: a deny that UNDER-matches,
+# because it spells a connector name the host has since changed, fails open and
+# silently. That distinction is the whole of its scope.
 #
 # Reads no network and no live MCP state — the settings file is the whole input,
 # so the same command answers the same way in a hook, on CI, and in a test.
@@ -110,5 +118,75 @@ done < <(jq -r '(.enabledMcpjsonServers // empty) | if type == "array" then .[]
 # A gate may only assert what it can verify from the repo. The connector-name
 # question cannot be, and belongs in user-level settings — see CLOUD-178.
 
-[ "$fail" = 0 ] && echo "mcp-allow-check: every allow rule in $settings names a tool it can match, and every enabled server has a grant"
+# --- an under-matching DENY, which is the direction that fails open -----------
+#
+# The paragraph above still holds: this gate cannot know which name a connector
+# is live under. What it CAN decide from the repo alone is whether a rule is
+# being RELIED ON for a server the repo never declares.
+#
+# MEASURED 2026-08-19, on this gate's own settings file at `d671184`. Four deny
+# rules named `mcp__Claude_Code_Remote__*` and `mcp__github__*`; the session that
+# wrote them had those connectors exposed as `mcp__bf7c680d-…__*` and
+# `mcp__cc451d34-…__*`, so three of the four matched nothing. The gate passed,
+# because every rule was well-SHAPED. A deny that names no live tool reads as a
+# prohibition and enforces nothing.
+#
+# WHY DENIES AND NOT ALLOWS, which is the whole of the new predicate's scope. The
+# two fail in opposite directions. An under-matching ALLOW fails closed — the call
+# stops at an approval prompt, a human sees it, and the compensating control
+# CLOUD-178 already records ("the failure is loud to the human even though it is
+# silent to the agent") applies. An under-matching DENY fails OPEN, silently, and
+# no one is prompted about a prohibition that quietly stopped applying. Only the
+# second needs a gate, and scoping to it is what lets this land without a waiver
+# for every pre-existing allow rule.
+#
+# COVERAGE IS DECLARED, NEVER PARSED. A guard that decides a verb by tool-name
+# SUFFIX works under any exposed server name, which is the portable form of this
+# rule — `issue-read-guard` and `board-move-guard` have matched `*save_issue` that
+# way all along. Each such guard prints the suffixes it owns via `--covers`, and
+# this gate takes the union. Grepping a neighbour's `case` statements instead
+# would be a second authority for a fact the guard already states.
+#
+# A server the repo DOES declare (`.mcp.json` / `enabledMcpjsonServers`) keeps a
+# stable name by construction, so its deny rules need no guard.
+declared=$( (
+	jq -r '(.enabledMcpjsonServers // empty) | if type == "array" then .[] else empty end' "$settings" 2>/dev/null
+	jq -r '(.mcpServers // {}) | keys[]' .mcp.json 2>/dev/null
+) | sort -u)
+
+# STDIN IS CLOSED FOR THE PROBE, and that is not a tidiness detail. A guard that
+# does not know `--covers` falls through to its `raw=$(cat)` and blocks forever
+# waiting for a payload that will never come — this gate hung the whole suite
+# exactly once, at the two-minute harness kill, before the redirect was added.
+# The output is filtered to bare tool-name shapes so a guard that answers with a
+# usage line or an `::error::` cannot inject a spurious "coverage".
+covered=$(for guard in "$(dirname "$0")"/*-guard; do
+	[ -x "$guard" ] || continue
+	"$guard" --covers </dev/null 2>/dev/null || true
+done | grep -E '^[a-z][a-z0-9_]*$' | sort -u)
+
+while IFS= read -r rule; do
+	[ -n "$rule" ] || continue
+	case "$rule" in
+	mcp__*) ;;
+	*) continue ;;
+	esac
+	rule_server=${rule#mcp__}
+	rule_server=${rule_server%%__*}
+	suffix=${rule##*__}
+	# A GLOB IN EITHER SEGMENT IS THE OTHER QUESTION, and the header above already
+	# answers it: "a deny may glob freely". `mcp__*` is a broad prohibition, not a
+	# misspelled narrow one, and there is no suffix for a guard to cover. The
+	# predicate here is only about a deny that names ONE server and ONE tool, both
+	# literally — the shape that looks precise and silently addresses nothing.
+	case "$rule_server$suffix" in
+	*'*'*) continue ;;
+	esac
+	# Declared server: the name is the repo's own and cannot drift under it.
+	grep -qxF "$rule_server" <<<"$declared" && continue
+	grep -qxF "$suffix" <<<"$covered" && continue
+	report "$rule — a deny on a host-supplied connector, whose exposed name the host chooses per registration episode (CLOUD-178). No suffix-matching guard covers \`$suffix\`, so this rule reads as a prohibition and enforces nothing the moment the connector comes back under a different name."
+done < <(jq -r '[.permissions.deny // [] | .[] | select(type == "string")] | .[]' "$settings")
+
+[ "$fail" = 0 ] && echo "mcp-allow-check: every allow rule in $settings names a tool it can match, every enabled server has a grant, and every deny on a host-supplied connector is backed by a suffix-matching guard"
 exit "$fail"