Reach the launcher wiring, and reach a second harness: two things this repo said were somebody else's

[wenzowski]

Two things this repository said were somebody else's

Both were false, both were measured, and both are fixed here.

1. The launcher wiring — Closes CLOUD-1079

~/.claude/launcher-settings.json registered two programs into this container's hook surface. One, stop-hook-git-check.sh, exits 2 on every correctly-attributed commit here and prescribes the exact identity [attribution] identity_deny forbids.

From a true premise — Claude Code merges hooks across settings files, so a lower-precedence file can add a registration and never remove one — a session inferred "the only place it can actually be turned off is the environment configuration … outside this repository, an owner action." That sentence then propagated by quotation into four tracked files, two memories and six board rows, and sent CLOUD-1079 back to Backlog twice in one day.

The distinction it misses: the repo cannot unregister the hook through a settings file, which is not the same as cannot repair the wiring. batten wiring reclaim removes the registration and never the file — which is also why a blind rm was correctly refused, since session-start-git-identity.sh sets core.hooksPath for the whole container.

Measured on this container, before and after:

merged_siblings: 2, merged_surfaces_read: 1, ok: false
merged_siblings: 0, merged_surfaces_read: 1, ok: true

Both numbers, which is CLOUD-1079's own acceptance clause: a zero from a surface nobody read is the false green the census exists to refuse. The DECLARED rows are deleted rather than excused, which is the third clause.

Two defects found by running it rather than reading it: the handler row was missing entirely, and the task body omitted -y — wiring reclaim never prompts, so every session would have reported a provisioning error for the life of the row.

2. The advisory channel — Closes CLOUD-1362

Batten adjudicates for six harnesses and its advisory channel reached one. ADVISORY_GAPS recorded Gemini as unreachable because "the only door is the stdout this host's stdout_must_stay_clean row forbids."

That conflates two things. stdout_must_stay_clean is about stray output on exit 0 being misread as a decision. An advisory is not a decision — it wants allow-plus-a-message, which is exactly what Gemini's documented Golden Rule delivers. The door is the mechanism, not the obstacle.

The collision that would have made it an obstacle is already closed by construction: emit_channel returns early on Deny/Ask (CLOUD-1175), so an advisory and a verdict never share one invocation's stdout. Corroborating it, admit_mediated already writes bare prose to stdout on the admitted-call path.

Reach 1/6 → 2/6, asserted as a count because CLOUD-1152's acceptance is a count. The emitted body is the text verbatim, never JSON — a body that parsed would be read as a decision on the one host where that inversion is expressible, and the test pins exactly that.

Cursor and CopilotCli stay Unknown and unprobed; that is CLOUD-209's shape, not this PR's to guess.

3. Why nothing caught the stopping

RCA of this session: it took the branch green, pushed, and stopped, three times. completion.unlanded exists for exactly that and produced nothing across 2763 transcript lines and 20 stored findings.

Three suppressions, two fixed here:

• record_state — which mints the verdict — sat inside rule 4 of an early-returning ladder, behind filed_here_pointers. Ten live filed-over-own-diff rows meant rule 4 was never reached and the verdict was never minted. It is now minted before any rule can return: minting and reporting are different questions and must not share a suppression.
• The completion reading was rule 4, behind two prose-shaped rules. Precision is the right axis between rules about the same kind of thing; it is the wrong axis here. It is rule 1 now.

.claude/rules/toolchain.md carries the interim rule, because a gate that cannot fire must not be relied on silently.

Deliberately not closed

DO-NOT-CLOSE CLOUD-1372

The third and binding root cause is unfixed: the marker completion::signal needs is absent from a stream whose turns end on tool calls (last end_turn 49 records back), and Outcome::NotSignaled writes nothing — byte-identical to a landed branch. CLOUD-887 removed a marker whose own firing was its input, which was right, and replaced it with one that cannot fire, which was never measured against a real transcript. Whether a turn ending in tool_use should count as a completion is a genuine design decision, and taking it in a hurry on the gate that polices this class is how CLOUD-887 happened. The row keeps it, with the measurement.

DO-NOT-CLOSE CLOUD-1356

Four of seven prose sites corrected. batten.toml and two policy/*.rego headers are protected paths whose remaining edits land behind their own admission, so the row stays open with its inventory corrected — including two errors in that inventory this branch found: the .rego headers are protected rather than freely editable, and core.md never carried the sentence at all.

Also filed, not fixed here

CLOUD-1359 and CLOUD-1361 — both were deferrals sitting in memories reading "unfiled because the tracker was unreachable", which stopped being true in this session. CLOUD-1378 — an issued admission is keyed to HEAD, so land's own rebase voids it every lap; the same eight were spent twice here for an unchanged diff.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WTqsjPE2ckz9DSJmq9nfXR

[linear-code]

CLOUD-1079 Stop provisioning the two user-level git hooks into `~/.claude/launcher-settings.json` — the owner action CLOUD-605 named and nothing owns

Why

~/.claude/launcher-settings.json registers two programs this repository does not own and cannot unregister:

SessionStart: ~/.claude/session-start-git-identity.sh
Stop:         ~/.claude/stop-hook-git-check.sh

CLOUD-605 established that a delete does not survive, and named the remedy without owning it: *"the only place it can actually be turned off is the environment configuration that generates *launcher-settings.json — outside this repository, an owner action. That is the real remedy." This row is that action. It exists so the remedy has a home rather than being a sentence inside a Done issue.

Re-provisioning, measured 2026-08-27. A previous session ran batten wiring reclaim -y, which removed both registrations from the merged surface. This session's files carry identical mtimes of 22:36:38 — launcher-settings.json and both scripts, rewritten together at session start.

*~~"So the repair and its erasure are one event, and no in-session action can outlast it." ~~*THAT INFERENCE IS FALSE AND IT IS THE WHOLE DEFECT IN THIS ROW. One manual invocation was erased by one re-provision, and the conclusion drawn was permanent impossibility. What was never tried is what this repository already does twice: register the repair as a session-start **handler so it runs on every session, after the launcher provisions. **session:signing exists for precisely this reason — "the launcher writes commit.gpgsign true --global every session, and local beats global only if something writes local" — and it wins. A repair that runs once loses to a rewrite that runs every session; a repair that also runs every session does not.

Re-measured 2026-09-02, and it sharpens the point rather than rescuing the old claim. Both scripts carry mtime 16:59 — rewritten MID-SESSION, not only at session start. So a one-off manual delete is even more hopeless than recorded, and a handler on the provisioning path is even more clearly the answer.

Why each should stop being provisioned, for this environment

stop-hook-git-check.sh is unsatisfiable here by construction. Its predicate (line 83) is an OR:

if [[ "$ce" != "noreply@anthropic.com" ]] ||
   ! git cat-file commit "$sha" | grep -qE '^gpgsig(-sha256)? '

Commits here are SSH-signed, so the second term is already satisfied and the email term alone carries the refusal. The only value it accepts is the one [attribution] identity_deny forbids, so the hook exits 2 on every correctly-attributed commit and the remedy it prints produces a commit commit-attribution refuses. Two policies, one of which has to not run.

session-start-git-identity.sh sets user.email, user.name **and **core.hooksPath globally (lines 21, 22, 104). The identity half is redundant here — attribution-identity writes repo-locally and local beats global, which is CLOUD-605's own recorded reason attribution in this repo has never failed.

**The **core.hooksPath line is new information and changes the shape of the ask. CLOUD-605 describes this script as an identity setter; it is also a global git-hooks redirect. So removing it wholesale has a blast radius beyond commit identity, and this row asks the owner to decide per line rather than per file. Turning off the identity pinning is what this repository needs; the hooks-path line may be load-bearing for the container and is not ours to judge.

What this blocks

The hook-registration campaign's remaining half. With these two present, hooks-wiring-check under a [hook] exclusive declaration can only be satisfied by deleting another tool's user-level configuration — which is the delete-and-lose race above. Once they stop being provisioned, the campaign's strong reading and the gate agree with no exemption and no delete, which is the only state where zero siblings is true rather than asserted.

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• **Source of truth (§1). CORRECTED 2026-09-02. **"The environment configuration that generates ~~~/.claude/launcher-settings.json~~ *~~— a console/provisioning surface outside every repository." ~~*False. The authority is batten.toml's [[hook.handler]] sequence plus mise.toml's session:* tasks — the same surface session:identity and session:signing already use to repair launcher-provisioned state. batten doctor hooks -J's merged_siblings remains the observation; batten wiring reclaim is the repair, and it existed before this row was filed.
• **Computable predicate (§2). **batten doctor hooks -J reports merged_siblings: 0 for claude-code on a fresh container, with merged_surfaces_read non-zero so the census is known to have looked rather than failed to. Both numbers, because a zero from a surface nobody read is the false green this whole census exists to refuse.
• Effect (§3). No change in this repository beyond the follow-up in §7. The action is a configuration change in the environment that provisions containers.
• Generated artifacts (§4). None.
• Output & exit (§5). Unchanged.
• **Commit / bump (§6). **fix → patch until 0.1.0, for the follow-up that removes the two now-obsolete DECLARED rows. Not chore: release-plz gives chore no bump at all, and this is not housekeeping — deleting an exemption changes the gate's verdict on an input it previously excused.
• Test obligation (§7). After the environment change: a fresh container reports merged_siblings: 0, and the two stop-hook-git-check.sh / session-start-git-identity.sh rows come out of hooks-wiring-check.sh's DECLARED table in one commit, with the gate green because the siblings are genuinely gone. Shown able to fail by re-adding a merged registration to a fixture $HOME, which tests/hooks-wiring-check.bats already drives through HOOKS_WIRING_MERGED.
• Blockers (§8). None. *~~"The action itself needs an owner with access to the provisioning configuration." ~~*RETRACTED 2026-09-02 — a punt, not a constraint, inherited by quotation from CLOUD-605, which is itself now retracted. The action is this repository's and is landing under this row.

Done

A fresh container carries no non-batten hook registration on any merged surface, batten doctor hooks reports merged_siblings: 0 having read the surfaces, and the two DECLARED rows are deleted rather than excused.

What is deliberately not proposed — REWRITTEN 2026-09-02

Half of the original refusal survives and half was the punt.

Still refused, and now for the right reason: deleting either FILE. session-start-git-identity.sh sets core.hooksPath for the whole container and that line may be load-bearing. batten wiring reclaim removes registrations, never files — which is exactly why it is the correct instrument and a blind rm is not.

No longer refused: running the repair from this repository. That was the punt, and the core.hooksPath caution is what it hid behind — a real precision requirement on the repair, dressed up as a reason to have no repair.

Honest residue, recorded rather than handed to an owner: a session-start handler closes the session-start window and does not hold against the 16:59 mid-session rewrite. What would close that is the provisioning seam mise.toml's deps-install comment already describes — the container's setup script runs mise run deps-install before any session begins, upstream of both the rewrite and the harness snapshot.

Superseded original, kept so the reasoning is auditable:

Deleting the files from $HOME at session start, from this repository or from batten wiring reclaim. That is the race CLOUD-605 measured and it loses: the launcher rewrites them at the next session, and one of the two also sets core.hooksPath for the whole container. A repository fighting its own harness's provisioning is a worse failure than the registrations it is trying to remove.

---

Why this row went backwards, traced 2026-09-02

It was In Progress 06:18–15:33 today and moved back to Backlog. The loop, and no step needs anyone outside this repository:

1. Nothing keeps the installed batten current — measured 0.0.121, built Aug 28, against a source tree at 0.0.137.
2. So batten wiring reclaim — the repair — was absent from the installed CLI (error: unrecognized subcommand 'wiring'), and an agent checking reachability concluded it did not exist.
3. And CLOUD-1314's test_the_retired_launcher_hooks_are_refused_if_they_return (policy/harness-wiring.rego:576) was not in that binary either, so batten doctor hooks -J answered siblings: 0, ok: true while merged: 2 showed it looking straight at both registrations.
4. A green census makes this row read as satisfied or unactionable → back to Backlog.

On 0.0.137 the same host answers merged_siblings: 2, ok: false, with a finding per event. policy/harness-declared.json is {} — there is no exemption; the rule that refuses these simply was not running.

CLOUD-1326 names this class. The engine's own contract-drift advisory fired during this session and said it plainly: "this session's SessionStart registration did not run … every mediated call until it appeared failed open and said nothing. This is a provisioning failure rather than a policy one."

CLOUD-1356 One retracted sentence is quoted by four files, three memories and six rows, and an open PR is landing it back into the tree

Why

CLOUD-605 (Done) concluded: "the only place it can actually be turned off is the environment configuration that generates launcher-settings.json — outside this repository, an owner action."

It is false, and it did not stay in one row. It propagated by quotation into a citation chain that now spans the tree, the memories and the board — and because CLOUD-605 is Done, nothing re-derives it. Each inheritor cites an authority rather than a measurement, so the chain is self-reinforcing: connector-not-granted.rego cites commits.md, commits.md states it as normative, batten.toml states it as a count table, and six rows cite CLOUD-605.

This row owns retracting it everywhere. CLOUD-1079 owns the mechanism that makes the retraction true.

Why it is false, in one paragraph

The rewrite happens every session, so a one-off repair loses — which is all CLOUD-605 measured. A repair that also runs every session does not, and this repository already does exactly that twice. session:signing exists in its own words because "the launcher writes commit.gpgsign true --global every session, and local beats global only if something writes local"; session:identity is the same shape. The launcher-hook case is the third member of that family and nobody had registered it. batten wiring reclaim (crates/batten/src/wiring.rs:293, declared surface.rs:3466, asserted crates/batten/tests/it/wiring_reclaim.rs:173) is the repair, and it predates CLOUD-1079.

Why nobody noticed — the reason this is Urgent

Measured 2026-09-02. The installed binary was 0.0.121, built Aug 28, against a source tree at 0.0.137:

binary	siblings	merged_siblings	ok
0.0.121 (installed)	0	absent	true
0.0.137 (source)	0	2	false

So batten wiring reclaim answered error: unrecognized subcommand 'wiring' — an agent checking reachability concluded the repair did not exist — and CLOUD-1314's test_the_retired_launcher_hooks_are_refused_if_they_return (policy/harness-wiring.rego:576) was not in that binary either, so doctor hooks reported green while merged: 2 showed it looking straight at both registrations. policy/harness-declared.json is {}**; there is no exemption — the rule that refuses these simply was not running. **CLOUD-1326 names this class and is the root cause; it is Backlog with no milestone.

The engine said so itself this session: "this session's SessionStart registration did not run … every mediated call until it appeared failed open and said nothing. This is a provisioning failure rather than a policy one."

AND IT IS LANDING BACK IN RIGHT NOW

PR #826 is open and draft, and its revert(hook) commit restores CLOUD-1314's two deleted declared rows and withdraws [hook] exclusive = true, quoting batten.toml's note — "so no commit here can clear them" — and concluding a per-surface exclusive is "strictly better than waiting for a zero no commit can produce." That zero is producible; --dry-run on this container reports would remove 2 sibling registration(s). Commented on the PR (#826 comment). The three retirements and the red-gate unblock in that PR are sound; only the exemption restoration should not land.

The inventory — four files

One citation chain, so they are corrected together; fixing commits.md alone orphans the rego citation.

site	verbatim	note
batten.toml:6283-6288	"no commit here can clear them; CLOUD-1079's remedy is the environment configuration that generates them"	also factually stale — harness-declared.json is {}
.claude/rules/commits.md:114-118	"an owner action on the environment configuration that generates those settings, outside this repository"	strongest instance, in a normative file
policy/connector-not-granted.rego:21-25	"outside this repository and outside every gate here"	cites commits.md as precedent; narrow half (a gate may not assert registration) is genuine, "outside every gate" is not — [[rule.external]] already reads the file
policy/harness-wiring.rego:88-91	"cannot remove a program living outside this repository"	contradicted by its own file 20 lines later

**The model for the rewrite is already in the tree: **mise.toml:1717-1727 is the same sentence with the opposite, correct conclusion — "Nothing outside this repository changes … that configuration already makes the call." Cite it.

Three memories

• .serena/memories/toolchain-and-hooks.md:396-410 — "still the fix that would close the window", "wants a row", "Unfiled". The named fix is a SessionStart write, which is now a [[hook.handler]] row.
• .serena/memories/core.md:1337-1348 — asserts the DECLARED table is empty, contradicting batten.toml:6283. Correcting the latter resolves it.
• .serena/memories/connector-allowlist-recovery.md:232-234 — "whether a SessionStart *hook's settings write affects the session that is starting … unmeasured. Measure it, do not assume it." *CLOUD-1079's handler measures it. Record the reading.

Six rows

row	state	verbatim
CLOUD-605	Done	the root; retraction header added 2026-09-02
CLOUD-1079	Todo	§1/§8 corrected 2026-09-02; owns the mechanism
CLOUD-1086	Todo	"No commit in this repository is expected" — near-duplicate of 1079; names wiring reclaim and still concludes no route
CLOUD-1314	In Progress	"turning them off is an owner action" — in the body whose Done condition is the removal
CLOUD-1085	In Review	§1 "the change is in the environment configuration that provisions a container" — about to close having handed the fix to nobody
CLOUD-893	Done	"the launcher's hook is outside this repository's control"
CLOUD-312 rows 12–13	In Review	"out of repo — not ours to port" — true of porting, false of removing; blocks its own end-state predicate 2

Deliberately NOT in this row

Two sites were swept and judged genuine, recorded so they are not "corrected" by a later reader pattern-matching on the words:

• mise-tasks/container-preflight.sh:6-27 — an ambient NO_PROXY consumed by mise's own resolver before [env] applies really is pre-process.
• mise-tasks/release-tracking-check.sh:67 — a CI secret's existence is genuinely unreadable from the tree, and it ships the gate it can.

CLOUD-1333 is the counter-example worth copying: it refuses to let "reported upstream" stand as a posture and files in-repo options anyway.

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• **Authority boundary (§1). **batten.toml, .claude/rules/commits.md, two .rego headers (comments, not predicates — so this is not a shell-retirement event), and three .serena/memories/ files. No mise-tasks/*.sh is touched, where the only two shapes are retire-whole or leave-alone.
• Computable predicate (§2). No tracked file asserts that the launcher's hook registrations are unreachable from this repository. Mechanically: the four sites above carry the corrected claim, and each names session:wiring or mise.toml:1717-1727 rather than an owner.
• Deliberately not in scope (§2). The mechanism itself (CLOUD-1079). The two genuine sites above. CLOUD-716's unsent-client-text claim, which is narrowly true.
• **Effect (§3). **read — prose only; no predicate changes.
• Output & exit (§5). Unchanged.
• **Commit / bump (§6). **docs → no bump. The .rego edits are header comments; no rule's verdict moves.
• Test obligation (§7). Prose has no compiled tier, and saying otherwise would be the defect this row is about. What IS checkable: policy-test and the harness_wiring tier stay green (proving the .rego edits touched no predicate), and batten doctor hooks -J reports merged_siblings: 0 with merged_surfaces_read non-zero once CLOUD-1079 lands — a zero from a surface nobody read is the false green this census exists to refuse.
• **Blockers (§8). **relatedTo CLOUD-1079 (the mechanism that makes the retraction true — correcting the prose before the handler exists would trade one false claim for another), CLOUD-1326 (root cause of the invisibility; should be milestoned), and the six rows above.

Acceptance

• No tracked file, memory or open row asserts the claim.
• Every correction cites the measurement or mise.toml:1717-1727, never another prose site — the chain is broken, not re-pointed.
• The two genuine sites are untouched and their genuineness is recorded.
• PR feat(facts): a vendored prompt's dispatch becomes a fact the tree can read #826 does not land the exemption restoration.

---

Filed 2026-09-02 after a session spent tracing why CLOUD-1079 went In Progress → Backlog again that morning. The row was not wrong about the race; it was wrong that the race was the only surface.

CLOUD-605 A user-level stop hook instructs the exact commit identity `batten.toml` denies, so its remedy is unlandable here and nothing records which authority wins

Why

Measured 2026-08-14, three times in one session (PR #450), once per new tip SHA. A user-level stop hook — ~/.claude/stop-hook-git-check.sh, outside the repo and outside any gate — reports:

There are commit(s) on branch … that GitHub will show as Unverified (missing signature, or committer email is not noreply@anthropic.com). Please run git config user.email noreply@anthropic.com && git config user.name Claude, then git commit --amend --no-edit --reset-author …

batten.toml:941 commits this repository's identity_deny:

identity_deny = [
  '^Claude <',
  '@noreply\.anthropic\.com>$',
  '\bclaude-(opus|sonnet|haiku|fable)\b',
]

Claude <noreply@anthropic.com> matches the first pattern. The remedy the hook prescribes produces a commit this repository's own commit-attribution gate refuses, so a session that complies cannot commit again without either bypassing the gate or reverting the identity. The same session had already watched that gate correctly reject a Claude-Session: trailer minutes earlier.

This is not a hypothetical clash. CLOUD-274 built the gate from a measurement on this repo — 39 of the first 50 main commits carried an environment-injected vendor identity — and its recorded position is that accountability attaches to the human or service identity that directs, reviews and adopts a change, never to a model identity. The hook asks for precisely the state that measurement was taken to end.

The conflation is the second half of the defect. The hook's message ORs two unrelated conditions — "missing signature" and "committer email is not noreply@anthropic.com" — and offers one remedy that addresses only the second. The first is real and already tracked as CLOUD-591 (main takes unsigned commits; the repo gates identity and never signature). Resetting the author does not sign anything, so following the instruction trades a tracked gap for a policy violation and leaves the tracked gap open.

What is actually missing here is the record. Three refusals in one session were each argued from first principles against batten.toml, and nothing durable says which authority wins. The next session re-derives it, or complies.

Mechanism — DECIDED. The three below are kept for the reasons two were not taken, not as an open choice.

Read the hook, 2026-08-18. It is UNSATISFIABLE by construction, and three assumptions in this issue were wrong.

The predicate, from ~/.claude/stop-hook-git-check.sh:

if [[ "$ce" != "noreply@anthropic.com" ]] ||
   ! git cat-file commit "$sha" | grep -qE '^gpgsig'

An OR, over every commit not yet on a remote. So:

• Fixing the signature half does not silence it. This repo's commits ARE signed — commit.gpgsign true, gpg.format ssh, key at /home/claude/.ssh/commit_signing_key.pub — so the gpgsig term is already satisfied and the email term alone carries the refusal. CLOUD-591 landing changes nothing here. The earlier reading that the two halves were separable was right about the message and wrong about the code.
• No configuration satisfies it. The only value it accepts is the one identity_deny forbids. This is not a tuning problem; the hook and the repo encode contradictory policies, and one of them has to not run.
• It exits 2, the blocking status for a Stop hook, which is why it re-prompts rather than informing once.

Where it comes from, and why deleting it does not work. It is registered in ~/.claude/launcher-settings.json, alongside a SessionStart companion ~/.claude/session-start-git-identity.sh that runs git config --global user.email noreply@anthropic.com and --global user.name Claude. The repo's own attribution-identity writes the accountable identity repo-locally, and local beats global, which is why every commit here is correctly attributed and the gate has never failed.

All three launcher files were rewritten at 14:27:09 this session — one second before the injected MCP config at 14:27:10 — so they are re-provisioned by the launcher mid-session, and a delete does not survive. Nor can the repo unregister it: Claude Code merges hooks across settings files (hooks-wiring-check's own header records this), so a lower-precedence file can add a hook and never remove one.

So the only place it can actually be turned off is the environment configuration that generates launcher-settings.json — outside this repository, an owner action. That is the real remedy, and this issue's mechanism below is the mitigation for as long as it is not taken.

The original framing follows. The hook is a user-level file this repository cannot edit or gate, so the options are about what the repo states and what it can detect:

1. State the precedence in .claude/rules/commits.md — a repo-committed instruction that a harness identity request is refused, naming batten.toml's identity_deny as the authority and CLOUD-591 as the home for the signature half. Cheapest, feedforward only, and enough to stop the re-derivation.
2. Ship a repo-level stop hook that answers the same question correctly — reporting the unsigned state without prescribing a denied identity — so the two hooks do not disagree in front of an agent. .claude/settings.json already carries batten's registrations, and CLOUD-62's derivation is the shape.
3. Nothing in the engine. Worth saying out loud: identity_deny already refuses the bad state at the earliest computable moment, and it fired correctly every time. There is no enforcement gap — only a guidance gap.

Correction 2026-08-18 — option 1's PLACEMENT is wrong, and that is why this keeps recurring.

.claude/rules/commits.md is path-scoped. Its frontmatter loads it only for CHANGELOG.md, release-plz.toml and Cargo.toml. The stop hook fires on every commit in every session, most of which touch none of those three — measured today on claude/revert-connector-name-misdiagnosis, which edits .claude/settings.json, mise-tasks/, hk.pkl and mise.toml, so the file was not in context when the hook spoke. A precedence record filed there is absent at exactly the moment it is needed, which is indistinguishable from not having written it.

That is not a small correction to option 1; it falsifies it. The record has to live on a surface that is present at Stop time, and there is exactly one always-loaded instruction surface: AGENTS.md.

Decision: one line in AGENTS.md, plus the gate. The line names [attribution] identity_deny as the authority over any harness identity request and points the signature half at CLOUD-591. .claude/rules/commits.md keeps the detail, where a session touching release config will find it.

The cost is named rather than absorbed: AGENTS.md sits at its [budget.instructions] ceiling, so this line has to be paid for by trimming one. That is the correct trade and not a reason to hide the rule somewhere unread — a rule that is only loaded when the reader happens to be editing Cargo.toml is feedforward that fires after the fact. If policy-budget refuses the addition, the refusal is a real signal about what else in AGENTS.md has stopped earning its lines, not a reason to relocate this.

Option 2 (a repo-level Stop hook) is rejected on noise, and the reason is worth keeping. It would speak in the right channel at the right instant, which is its whole appeal. But the condition it would key on is true of every correctly-attributed commit this repo produces — by policy the committer is never noreply@anthropic.com — so it would fire on every stop, forever, to restate a rule that was already followed. That is the compliance-reassurance shape AGENTS.md's output posture forbids.

Acceptance

• A committed instruction states which authority governs commit identity, so a session refuses without re-deriving the argument from batten.toml.
• The signature half stays pointed at CLOUD-591 rather than absorbed here — one issue per condition, since the remedies differ.
• No change to identity_deny: the deny-set is correct, and this issue is about the guidance around it.

Bounds

Not a fail-open bug. Every commit on #450 carried an accountable identity and the gate passed; the cost is a session spending three rounds on a settled question, and the risk that one complies and produces an unlandable commit.

Refinement — Ready (record the precedence, and gate that no tracked file prescribes the denied identity)

Refinement gate: Definition of Ready & Done. This body carries only specializations.

Mechanism decided: Option 1 plus a gate. Option 1 alone is feedforward only, and §2 refuses a rule with no runnable gate — so the record ships with two exit codes rather than as prose a later edit can quietly drop.

• Source of truth (§1). AGENTS.md carries the precedence record — the only always-loaded surface, and the correction above is why .claude/rules/commits.md cannot: it is path-scoped to three release files and absent from the session where the hook actually fires. .claude/rules/commits.md keeps the detail. One new [[rule]] row in batten.toml carries the gate over tracked files. [attribution] identity_deny stays the authority on commit identity: it is named and never restated. The row is not a second copy of it — identity_deny judges what a commit carries, the row judges what a tracked file prescribes. Different object, different pattern, one authority each.
• Computable predicate (§2). Two exit codes, both under the hk gate and CI. (a) A presence check refuses a tree whose AGENTS.md does not carry the precedence statement — placed there rather than in commits.md per the §1 correction, so the gate protects the copy that is actually loaded. (b) A forbid row makes batten check exit 2 on any tracked line prescribing the denied identity — the git config user.email … remedy shape the hook asks for. Engine-side, not a bash gate: the row is ordinary batten.toml data evaluated by batten check.
• Effect (§3). No new command; the effect table and the derived allowlist are untouched. The row evaluates under check, which stays read.
• Output & exit (§5). Pointer-only — path:line plus the rule id, never the matched line. The finding lands on the 0/1/2/3 table like any other, so 2 is the verdict and nothing needs a private path.
• Commit / bump (§6). feat → patch until 0.1.0.
• Budget (§4). One line added to AGENTS.md against a file at its [budget.instructions] ceiling, so one line comes out. mise run policy-budget is the arbiter and its refusal is a finding about AGENTS.md's other lines, never a reason to move this one.
• Test obligation (§7). One bats case per gate, each shown able to fail: a tree whose AGENTS.md is missing the record refuses and a tree carrying it passes; a fixture prescribing the denied identity refuses and the same fixture without it passes.
• Blockers (§8). None. The signature half sits with CLOUD-591 as a relatedTo, not a blocker — one issue per condition, since the remedies differ, which is this issue's own stated bound.

Re-measured 2026-08-14, and one premise above is now false. This paragraph is the correction; the falsified sentence is left in place above so the two can be read together. The hook fired six more times in a later session on PR #460, across two container restarts, which is the re-derivation cost this issue predicts. That session also measured the signature half directly, and it does not say what the hook says: the commits are signed (SSH), and GitHub answers verified: false, reason: unknown_key — not unsigned. So the line above reading "main takes unsigned commits" describes a state that is not the current one; the gap is that the signing key is unpublished. That correction belongs to CLOUD-591 and changes nothing here, because this issue's subject is the identity half, which was refused correctly every time — commit-attribution locally and commit-lint in CI both passed on the merged commits.

CLOUD-1314 The two CLOUD-605 identity hooks are still wired, and the issue that recorded their precedence closed without removing them

Context

policy/harness-wiring.rego carries a declared table whose contract is "what is wired today that should not be, naming the issue that owns its retirement". Two of its three rows name CLOUD-605, which is Done (2026-08-23):

• ~/.claude/stop-hook-git-check.sh
• ~/.claude/session-start-git-identity.sh

A licence keyed to a closed issue is the permanent-exemption shape the table exists to refuse. Measured on this branch while landing CLOUD-1310.

What CLOUD-605 actually closed

It closed by recording a precedence — [attribution] identity_deny outranks a harness identity request, now non-negotiable rule 8 in AGENTS.md, gated by no-denied-identity-prescribed. That mechanism stops the hook's remedy from being followed. It does not remove the hooks, and it could not have: both live in ~/.claude/, outside this repository, so turning them off is an owner action on the environment config.

So the row was right to exist and wrong to point at CLOUD-605: the issue that owns the precedence is not the issue that owns the removal, and nothing owned the removal.

Ready

Mechanism as a computable predicate. The two rows in harness-wiring.rego's declared table point at this issue instead of CLOUD-605, and harness-wiring regains the direction that refuses a row whose owner has closed — the direction hooks-wiring-check used to hold from piped-in payloads and which CLOUD-1160 retired with no successor. CLOUD-1310's Fact::Minted is what gives that predicate a tree-surface home.

Done when: both hooks are gone from the harness config, the rows are deleted from declared, and harness-wiring refuses their return.

Out of scope

Re-litigating rule 8. The precedence stands; this is only about the two programs still being wired underneath it.

CLOUD-1326 An installed `batten` older than a config key disarms every mediated gate silently: the hook fails open on a config it cannot parse, and nothing says so

Why

**Measured 2026-09-02, in this repository, by accident. **batten config show exited 1 against the committed batten.toml:

invalid config ./batten.toml: TOML parse error at line 5878
unknown field `bot_lane`, expected one of `version`, `min_batten_version`, ...

The installed binary was built at 23:21; [bot_lane] landed on the branch at 00:0x, added by CLOUD-1295's bot-issue retirement. .claude/settings.json invokes that binary — batten hook --harness claude-code — on **every **PreToolUse. The engine's stated posture is fail open: "Unreadable stdin, unparseable JSON, an envelope with no command — all resolve to Decision::Allow."

So for roughly ninety minutes every mediated gate in the session was inert, and the only evidence was that nothing ever refused anything. Confirmed by the reverse: within a minute of mise run install:local, the engine refused a git commit piped into grep (verdict-not-discarded) — a shape it had been silently allowing all along.

Why the existing sensors do not cover it

**A MISSING binary is reported; a STALE one is not. **CLOUD-824 moved that report forward deliberately: session-start builds and installs, so an absent binary is an ::error:: at provisioning time. The stale case is different in kind — the binary is present, executable, and answers every call with "allow".

doctor asserts the installs are intact, which they are: the symlink resolves and the program runs. It does not ask whether the program can read the authority it is about to enforce.

min_batten_version runs the wrong way. It refuses a config that needs a NEWER binary. This is the opposite: a config the older binary cannot parse at all, refused at the TOML layer before any version check is reached.

contract-drift is blind to it by construction. It hashes the [contract] tracked surface to say the instruction files moved. It says nothing about whether the binary can still load the config.

The general shape, which is why this is Urgent rather than a chore

A gate that cannot read its own authority answers "allow" to everything, and that is byte-identical to a clean tree on the decision surface. It is the same class as .claude/rules/policy-modules.md's opening measurement — a module reading a key the engine never builds, green over a knowingly-broken registry — and the same as CLOUD-1049's dead channel. The failure is always: something could not look, and the reading was "fine".

Every branch that adds a config key creates this window for any session whose binary predates it, which in a fleet is every sibling session that has not reinstalled.

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• Authority boundary (§1). The hook entry's own startup path, plus whatever channel a host offers for an out-of-band notice. It is NOT a new config key — a key the stale binary cannot parse is precisely what is unreadable here, so any remedy expressed in batten.toml is unreachable in the case it exists for. That constraint is the whole design problem and is why this row is not obvious.
• Computable predicate (§2). When the engine cannot LOAD the committed authority, that must be distinguishable from a clean adjudication. Fail-open on the call is correct and stays — a guard must never be the reason a session cannot proceed — but silence is not. The distinction is Look::CouldNotLook versus Look::IsNot, which this engine already draws everywhere else and does not draw here.
• Deliberately not in scope (§2). Making the hook fail CLOSED. That would let a config typo wedge every tool call in every session, which is strictly worse and is what the fail-open posture exists to prevent. The ask is a READING, not a refusal.
• Where the notice can go (§2), stated because it is the hard half. A PreToolUse deny is exit 2 and is ruled out by the posture above. Claude Code delivers additionalContext on PreToolUse with the call still allowed (measured 2026-08-29, CLOUD-1131), which is a candidate. SessionStart is the other, and it is where doctor already runs — an assertion that the installed binary can parse the committed authority is one config show and an exit code, which makes it the cheapest honest half even if the per-call notice proves unreachable on some harness.
• **Effect (§3). **read. One config load the boundary already performs.
• Output & exit (§5). Pointer-only: that the authority did not load, and the coordinate the parse failed at. Never the config's contents. Exit 3 for could-not-look, never 2 — a verdict about the environment is not a verdict about the call.
• **Commit / bump (§6). **fix(hook) — patch until 0.1.0.
• Test obligation (§7). Over the compiled binary, shown able to fail per CLOUD-418. Red today: a fixture whose committed config carries a key the binary does not know, adjudicating a call that a loadable config would refuse — the call is allowed AND nothing distinguishes it from a clean pass. Green: the same fixture reports could-not-look through some channel while still allowing the call. The anti-vacuity mirror, without which the arm is satisfied by a notice on every run: a config that loads cleanly says nothing.
• Blockers (§8). None. relatedTo CLOUD-824 (which moved the MISSING-binary report to provisioning time and is the sibling case), CLOUD-1131 (the measurement that PreToolUse can carry additionalContext), CLOUD-1049 (a channel that could not look and read as clean), CLOUD-418.

Acceptance

• A session whose installed binary cannot parse the committed authority learns that it cannot, rather than inferring safety from silence.
• The call is still allowed — fail-open is unchanged.
• A loadable config produces no notice at all.
• The remedy does not depend on a batten.toml key, since that file is the thing that cannot be read.

Found by it happening: [bot_lane] landed on a branch, the session's installed binary predated it, and roughly ninety minutes of mediated calls went unjudged with nothing to show for it. Reinstalling restored refusals within a minute.

CLOUD-1085 Deleting `.claude/container-setup.sh` left no bootstrap at all: `batten` is absent at SessionStart, so the engine mediates nothing for the whole session

Why

.claude/container-setup.sh was added by #709 — "Put the released batten on PATH before the session starts" — and deleted by #713 (65757c8, 2026-08-28T03:32:44Z) on #711's premise that the hardened one-liner makes a repo-side wrapper unnecessary. That premise is about what install.sh can do, and it is correct. What it does not establish is that anything invokes it.

Measured on the first session after that deletion, 2026-08-28, this container:

time	event
04:37:21	.git/batten-receipts/session-start written — session-start.sh ran, so SessionStart fired
04:39:58	/root/.local/bin/batten created by mise run install:local (141 s build, per /tmp/session-start-batten-build.log)
04:40:48	first .git/batten-contract/<session> snapshot written

contract.rs seeds that snapshot on SessionStart (CLOUD-461), deliberately, so an autonomous session's first fetch+rebase cannot be recorded as the baseline. It was written at the first PostToolBatch instead, 3½ minutes late. The SessionStart registration of batten hook --harness claude-code therefore did not run: there was no binary on PATH for the host to execute.

So for the first ~2.5 minutes of every session on a container of this class, and for the whole of any session where install:local fails or is not reached, batten mediates nothing — every PreToolUse resolves to a command the host cannot run and fails open, silently. .claude/settings.json registers batten hook on all eight events by bare name; only .claude/hooks/session-start.sh is registered by path, and it is the sole reason a binary exists at all.

The failure is not loud. No host error surfaced in that session; the only hook message was container-preflight's own success line. An absent reference monitor and a passing one are indistinguishable from the outside, which is exactly the silent-absence case #711 refused inside install.sh ("Off PATH is a refusal, not a warning over exit 0") — the same defect, one layer out.

Why it is more than one container's setup

The repo now carries no bootstrap. install:local inside the SessionStart hook is the only thing installing batten, and it is a dev-clone convenience that supersedes a release build — not a provisioning path. That inverts CLOUD-824's posture, which moved the missing-binary report forward to provisioning time, where it can still be fixed.

It also blocks CLOUD-312 row 10 on its merits. #714 retires .claude/hooks/session-start.sh behind a [[hook.handler]], which is right under the intended design — one environment-agnostic install script, everything else driven by batten. But a handler is dispatched by the binary, so while nothing puts a released batten on PATH first, that move removes the last thing that installs it. Row 10's premise is this row's acceptance.

Not in scope: restoring the wrapper. The design is one install script and no harness-specific bootstrap; re-adding .claude/container-setup.sh would re-take a decision #711 and #713 made deliberately.

---

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• **Source of truth (§1). **install.sh stays the one install interface and gains nothing; the change is in the environment configuration that provisions a container, which must invoke it before any hook fires. No second installer, in the repo or beside it.
• Computable predicate (§2). Two, both decidable. (a) On a fresh container, command -v batten answers before the first SessionStart hook runs — observable after the fact as: the batten-contract snapshot for a session is written at that session's SessionStart, not at a later event. (b) A session whose SessionStart engine registration did not run is reported rather than silent: the first batten hook invocation of a session that finds no snapshot for it says so on its own advisory channel, which is free because the snapshot is already keyed per session.
• **Effect (§3). **read. (b) reads and writes only the existing per-session snapshot store under $GIT_DIR; no new fact class, no new verb.
• Generated artifacts (§4). None.
• Output & exit (§5). Pointer-only and advisory. (b) rides SessionStart/PostToolBatch's existing advisory channel, never exit 2 — an absent reference monitor is news, not a verdict about the call in hand, and Event::carries_a_verdict is the authority.
• **Commit / bump (§6). **fix — patch until 0.1.0.
• Test obligation (§7). Shown able to fail per CLOUD-418: a fixture session whose snapshot store carries no entry for the current session id produces the advisory, and one that does produces silence. The measurement above is (a)'s reproduction and needs no fixture — it is a property of a real container and is checked by provisioning one.
• Blockers (§8). None. relatedTo CLOUD-312 (row 10's premise is this row's acceptance), CLOUD-824 (which moved the missing-binary report to provisioning time), CLOUD-476 (which closed the absence this reopens).

Acceptance

• A fresh container has batten on PATH before its first hook fires, and the SessionStart contract snapshot proves it by being written at SessionStart.
• A session where that did not happen says so, once, rather than mediating nothing in silence.
• No harness-specific bootstrap returns to the repository.

Found while landing #714, by asking whether row 10's stated premise — "a container puts batten on PATH before any hook fires" — holds on the container running it. It does not, and the reason is 65 minutes older than the session that measured it.

CLOUD-1362 The advisory emitter reaches 1 of 6 harnesses, so Batten's neutral instruction channel cannot carry doctrine off `.claude/` — CLOUD-44 landed the decision half and nothing has owned the advisory half since

Why

CLOUD-1152's §2 says, in its own words: *"If that work is larger than this row, split it out and make this row *blockedBy it; do not relocate prose ahead of the channel meant to carry it." That split was never made. CLOUD-1152 has been In Progress since 2026-08-30 with no update since 2026-08-31, and its only attachment (#751) is a different subject. This row is the split.

The diagnosis it inherits, which is correct and is worth restating once. Batten adjudicates for six harnesses and keeps its own binding doctrine in .claude/rules/, which five of them cannot read. The instinct is to hunt for a neutral folder; the right answer is that Batten already ships a neutral channel — a [[rule]] row's glob is the trigger, severity = "warn" is advice that does not refuse, the [[verdict]] registry is the prose once where a gate can read it, and delivery is at the act rather than at session start. The folder did not win on merit. It tied with the channel on reach — one harness either way — and beat it on effort.

So the relocation is not the blocking question; this is. Moving doctrine now takes it from a folder one harness reads to a channel one harness receives, and buys nothing.

Measured against the tree, 2026-09-02

AdvisoryReach (crates/batten/src/hook.rs:887) and ADVISORY_GAPS (:8040):

host	delivered_on	declared
ClaudeCode	PreToolUse, PostToolBatch, SessionStart, Stop	Yes
GeminiCli	empty	Yes
Cursor, CopilotCli	empty	Unknown — unprobed
CodexCli	empty	No — advertised, parsed but unsupported
ExitCode	empty	exit status and nothing else

CLOUD-1152's characterisation of the Gemini half is FALSIFIED, and that is this row's first correction

CLOUD-1152 calls GeminiCli "a pure Batten gap with no host uncertainty in the way" and "1/6 → 2/6 with a single shim". The tree says otherwise, and said so before that sentence was written. ADVISORY_GAPS' own Gemini row:

the documented "Golden Rule" treats unparseable stdout as a systemMessage, which is an advisory channel whose only door is the stdout this host's stdout_must_stay_clean row forbids.

So it is not a shim over an open door. Batten would have to emit into a channel one of its own rules forbids writing to, and that conflict is the actual work: either stdout_must_stay_clean gains a declared exception for the advisory frame, or Gemini's advisory reach stays honestly empty and the neutrality claim is bounded rather than fixed. Deciding that is this row's deliverable, and it is a decision, not a port.

AND THE CONFLICT IS NOT REAL — decided 2026-09-02, which is what this row was for

The paragraph above is my own, written hours earlier, and it is wrong in the same shape as the sentence it was correcting. It read the stdout_must_stay_clean row as a prohibition on writing to stdout. It is not. Its own doc comment (hook.rs:465):

Whether stray non-JSON stdout on exit 0 is read as an allow. Gemini's documented "Golden Rule": any unparseable stdout defaults to Allow and is treated as a systemMessage.

The hazard it guards is a decision document corrupted into an accidental allow. An advisory is not a decision: it wants allow-plus-a-message, which is exactly what the Golden Rule delivers. The door is the mechanism, not the obstacle.

**The collision that would have made it an obstacle is already closed by construction. **emit_channel (lib.rs:7442):

let speaks_a_verdict = matches!(decision, Decision::Deny(_) | Decision::Ask(_));
if advice.is_empty() || speaks_a_verdict { return Ok(()); }

CLOUD-1175 landed that. An advisory and a verdict never share one invocation's stdout — so on every path where advice is emitted at all, the decision is already Allow, and the bytes Gemini reads as "allow, and tell the model" say precisely what the engine decided. There is no direction in which this inverts a verdict.

**Corroborated rather than argued: **admit_mediated (lib.rs:6903) already writes a bare prose line to stdout on the admitted-call path. That door has therefore been open on a live allow path on this host, with no defect reported, for the same reason.

**On the per-event probe discipline, which is the one thing that looked like it forbade this. **ADVISORY_GAPS' Claude row refuses listing an unprobed surface. That scope does not transfer, and reading a rejection without its scope is the error .claude/rules/scanning.md records: there the question is whether a documented FIELD (additionalContext) is honoured at a given event — genuinely per-event. Here it is how the host's reader parses hook stdout, a property of the reader and not of the moment. If it is ever measured otherwise the cost is silence, which is the sanctioned degradation.

What landed

• GeminiCli's advisory row: delivered_on = ["BeforeTool", "AfterTool", "AfterAgent", "BeforeAgent"], declared: Yes unchanged, with the argument above at the row.
• encode_advice gains a GeminiCli arm returning the text verbatim — deliberately NOT JSON, because a body that parsed would be read as a decision on the one host where that inversion is expressible.
• The Gemini row is deleted from ADVISORY_GAPS, which is what closing a gap looks like there; the census fails until it goes.
• the_advisory_channel_reaches_a_second_host_and_never_as_a_document asserts the reach as a count (CLOUD-1152's acceptance is a count) and asserts the emitted body does not parse as JSON. That second arm is the load-bearing one.

**Reach is now 2 of 6, stated. **Cursor and CopilotCli stay Unknown and unprobed — CLOUD-209's shape, and not this row's to guess. CodexCli stays No on its own evidence.

Why the silence is the dangerous part

ADVISORY_GAPS' own header states the failure mode better than a summary can: "an advisory that goes nowhere is silent by design, so the failure mode of a wrong row here is a notice nobody ever sees and nobody can tell from a notice nobody wrote. A deny that fails to reach a host is loud; this is not."

That is why the census over Harness::ALL already exists and why it fails in both directions. The mechanism here is honest and well-built — the gap is stated rather than smoothed over, and a probe that succeeds forces its row out of the table. Nothing about this row is a criticism of that structure; what is missing is that nobody has done the probing or taken the Gemini decision.

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• Source of truth (§1). crates/batten/src/hook.rs — AdvisoryReach, ADVISORY_GAPS, encode_advice and its per-host match. The match is stated rather than wildcarded precisely so a row gaining a delivered_on entry must come back and answer for its wire shape; that property is preserved, not routed around.
• Computable predicate (§2). AdvisoryReach.delivered_on is non-empty for more than one host, and every host whose declared is Yes with an empty delivered_on carries an ADVISORY_GAPS row stating why — which the existing census already enforces in both directions. For Gemini specifically the deliverable is a decision with its citation: either an emitted frame plus a declared, tested exception to stdout_must_stay_clean, or a recorded finding that the host's only advisory door is unusable, with declared corrected if the primary docs no longer support Yes.
• Effect (§3). read. An emitter writes to the host's own reply channel; no new fact, no new verb, no config surface.
• Generated artifacts (§4). None.
• Output & exit (§5). The degradation direction is the invariant and it must not invert. AdvisoryReach's doc comment is the authority: an unreachable escalation degrades to a refusal, an unreachable advisory degrades to silence. A shim that got this backwards would turn a missing channel into a deny on four hosts, which is a far worse outcome than the silence it replaced.
• Commit / bump (§6). feat → patch until 0.1.0.
• Test obligation (§7). Shown able to fail per CLOUD-418. The census (hook.rs:12546) already fails when a host declares the channel, reaches none of it, and no row says so — and when a row no longer describes a gap, so closing one is red until the row is deleted. Any new emitter owes a case asserting the host's wire shape, and one asserting that an unreachable advisory produces silence rather than a verdict.
• Blockers (§8). None. Cursor and CopilotCli need a primary-doc probe before their Unknown can move, which is CLOUD-209's shape and is relatedTo rather than blocking — this row can be done for Gemini alone.

Acceptance

• AdvisoryReach.delivered_on is non-empty for more than one host, and the count is stated.
• No host's declared value moves without a primary-doc citation in its own row's comment.
• The Gemini stdout conflict is decided rather than deferred, with the decision written where the next reader meets it.
• CLOUD-1152 is unblocked, or records precisely which hosts it still cannot reach and why.

Bounds

Not the relocation of any prose — that is CLOUD-1152's, and it should not start before this lands. Not a change to the decision emitter, which CLOUD-44 shipped and which works. Not .serena/memories/**, a second vendor surface with its own loading contract.

relatedTo CLOUD-1152 (which this unblocks), CLOUD-44 (which landed the decision emitter and not this one), CLOUD-601 (AskReach, the same problem solved one channel over and the template rather than something to re-derive), CLOUD-209 (the harness capability matrix behind the neutrality claim).

CLOUD-1372 `completion.unlanded` has never fired on Claude Code: the marker it needs is absent from the stream, and `NotSignaled` records nothing — so the gate against stopping-before-landing is byte-identical to a clean tree

Why

Measured 2026-09-02 on a session that did exactly what this rule exists to catch: it took a branch to green, pushed it, reported "committed and pushed", and stopped without landing — repeatedly, across several turns, with the owner having to say "why the fuck stopped" twice. completion.unlanded produced nothing at any point.

That is not a tuning miss. The detector is structurally dead on this host, and it fails in the one direction this repository refuses everywhere else: could-not-look reading as clean.

The measurement

This session's transcript, 2763 lines:

reading	value
"stop_reason":"end_turn" records	42
"stop_reason":"tool_use" records	736
records after the LAST end_turn	49
completion.unlanded rows in the finding store	0
other findings in the store	20 (filed-over-own-diff, plan-unrecorded, filed-unrefined, harness-wiring, spawn-adapters)

batten state record run by hand exits 0 and still mints nothing, so this is the detector declining rather than the recorder failing.

Root cause 1 — the marker is absent exactly when it matters

completion::signal takes "the last marker with no tool call after it", and is_completion admits only EndTurn / StopSequence. Every recent turn in this transcript ends tool_use: the agent's turns close on a tool call, the harness re-invokes on hook advice and task notifications, and the last genuine end_turn is 49 records back. So signal() returns None → Outcome::NotSignaled → no finding.

CLOUD-887 predicted this in the code and mis-graded it. Its own comment:

The cost is stated rather than buried: a host that records no stop reason now yields NO claim rather than a claim per hook run. That is the correct three-valued answer — "could not look", not "declared done" — and it is strictly better than a constant.

The first half is right and the last clause is wrong. It is not recorded as could-not-look: NotSignaled writes no row, emits nothing, and is indistinguishable from "looked, and the work had landed". CLOUD-887 correctly killed a detector whose own firing was its input, and replaced it with one that cannot fire at all. Neither state was ever measured against a real transcript on the host the repository runs on.

Root cause 2 — the minting is starved by the ladder in front of it

stop_nudges is an ordered ladder of early returns, and record_state() — which mints the verdict — is called inside rule 4. Rules 1–3 return first; rule 3 is filed_here_pointers(PerRow), and this session had ten live filed-over-own-diff rows. So on any branch with an open filing obligation, rule 4 is never reached and the verdict is never even minted, independent of root cause 1.

Above that, two more suppressions, both confirmed:

• fill_turn_advice guards the whole block with if advice.is_empty() — any advisory suppresses the end-of-turn surface.
• hook::stop_advice(…).or_else(|| stop_nudges(…)) — or_else short-circuits, so a firing stop-posture means the ladder is not evaluated. Measured: stop-posture: prose report duplicate 1 fired on this session, on a turn that had also stopped without landing.

So the highest-consequence reading in the set sits behind three suppressions and a marker that is absent. Its position is the inverse of its importance: a style nit about prose outranks the work is not landed.

Why this is Urgent rather than tidy-up

The rule is the last line against the failure AGENTS.md names first — "an agent that finishes the edits and then stops." It has been silently absent for the whole period it was believed to be covering that, which is why the human is the detector. A gate that cannot look must say so; this one says nothing, and silence here reads as "the branch landed".

Refinement — Ready

Refinement gate: Definition of Ready & Done. This body carries only specializations.

• **Source of truth (§1). **crates/batten/src/completion.rs (signal, is_completion, assess, Outcome) and crates/batten/src/lib.rs (fill_turn_advice, stop_nudges, record_state). No [[rule]] row — the predicate needs the transcript and the findings store, neither of which a batten.toml row can name, which RULE_ID's own comment already states.
• Computable predicate (§2), and it is two independent obligations. (a) A session whose stream carries no usable completion marker records completion.unlanded as could-not-look, distinguishably from a session that looked and found the work landed — Outcome::NotSignaled must reach the store as a reading rather than as absence. (b) The verdict is minted unconditionally at Stop, before any nudge-selection ladder decides what to say. Minting and reporting are different questions and must not share a suppression.
• Deliberately not in scope (§2). Restoring Marker::StopHook. CLOUD-887's deletion was correct — a hook run is machinery, not a claim — and re-adding it would restore a detector whose own firing is its input. The fix is not a broader marker set; it is that an absent marker is a READING. Whether a turn ending in tool_use while the harness re-invokes should ever count as a completion is a real question and belongs to its own row, not smuggled in here.
• **Effect (§3). **read plus the store write record_state already performs.
• Output & exit (§5). Pointer-only and advisory; never a deny. Event::carries_a_verdict stays the authority and the Stop channel stays incapable of refusing — an end-of-turn gate that blocked would be the deny CLOUD-97 and CLOUD-219 each ruled out independently.
• Test obligation (§7). Shown able to fail per CLOUD-418, over the compiled binary and against a real captured stream, never a hand-built one — a fabricated transcript is what let this survive, since every existing case constructs a stream containing the marker it is testing for. Three cases: a stream with a completion marker and unlanded work raises; the same stream with the work landed is silent; a stream whose recent turns all end tool_use reports could-not-look and is distinguishable from both. The third is the one that is red today. Plus one over the ladder: a branch carrying a filed-over-own-diff row still mints the completion verdict.
• Blockers (§8). None. relatedTo CLOUD-887 (which removed the over-firing marker and shipped this), CLOUD-97 and CLOUD-219 (which each ruled the deny out), CLOUD-1051 (which moved the end-of-turn surface into the engine), CLOUD-1326 (the same class — a gate that cannot read its authority answering "allow" to everything).

Acceptance

• A session that stops with unlanded work is told so, on this host, with a real transcript.
• A session whose stream carries no usable marker says it could not look, rather than nothing.
• The verdict is minted whether or not any other end-of-turn rule fired first.
• The regression case runs against a captured stream, so a marker vocabulary that stops matching the host is red rather than quiet.

Bounds

Does not make the Stop channel able to refuse, and does not change what "landed" means — Landing decides by patch identity and that is correct and untouched.

Found by the owner asking why the agent had stopped, twice, on a session where this rule was the mechanism that should have answered instead.

Review in Linear

[coderabbitai]

Warning

Review limit reached

Next included review available in 42 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Free

Run ID: 17a2d8aa-b905-49eb-ab68-f4e01308b99c

📥 Commits

Reviewing files that changed from the base of the PR and between 393e327 and dda531f.

📒 Files selected for processing (7)

• .claude/rules/toolchain.md
• batten.toml
• crates/batten/src/hook.rs
• crates/batten/src/lib.rs
• crates/batten/tests/it/identity_precedence.rs
• crates/batten/tests/it/session_provisioning.rs
• mise.toml

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Free

Run ID: 4fe0ddf5-159f-423f-89f5-5df22ba83587

📥 Commits

Reviewing files that changed from the base of the PR and between 8c95e02 and 393e327.

📒 Files selected for processing (5)

• .claude/rules/commits.md
• .serena/memories/connector-allowlist-recovery.md
• .serena/memories/toolchain-and-hooks.md
• batten.toml
• mise.toml

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The change adds a session:wiring task that runs batten wiring reclaim -y and reports failures. A session-wiring startup handler invokes this task after session-batten, with a timeout, owner, and expiry. The change also updates repository guidance and memory records about hook reclamation, launcher rewrites, connector sensor gaps, and transcript hook handling.

Merge Risk: ⚪ Minimal · up to 393e3

The change adds a session-start repair task and its startup registration; no actionable merge-blocking risk remains beyond normal checks and review.

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing.

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

❌ The last analysis has failed.

See analysis details on SonarQube Cloud

[wenzowski]

/fast-forward