perf(policy): the retirement ledger is read once, not once per deleted path

[wenzowski]

Closes CLOUD-1321
Closes CLOUD-1340
DO-NOT-CLOSE CLOUD-1388

CLOUD-1388 is served, not completed. 104dd663 installs the instrument that will find it — the Windows job now reports what the engine did rather than one integer — but the defect is unfixed and needs an observation from a Windows runner this container does not have. Declining the close deliberately so the row stays open with its evidence.

Handoff note. The branch is complete and locally green; what remains is landing and that one Windows defect, which is not this branch's.

1. The term, named at a path:line

policy/shell-retirement.rego:1231. arms_for was a function, and regorus memoizes rules but not function calls, so its body — a scan of every line of the corpus batten.toml's line_sources declares (~152k lines × 5 arm markers, with a trim_space/substring/split per candidate) — ran once per call. Eleven violation bodies reach it under some path in delta.deleted, four more transitively, and two of those from inside an added × removed × deleted triple loop.

Three of the row's own claims are corrected rather than inherited. §3 concludes the term is "the some gone in delta.deleted iterations in mentions_retired, admitted_addition and their callees" — those iterate delta.deleted (≤ 8) over one file's base-lines and are cheap. §3 also says script_dir_vars (:568) and retired_path_vars (:583) are "rules keyed by their arguments now"; both are still functions, and they stay functions, because they read delta["base-lines"][path] — one file, not the corpus — so flattening them buys nothing measurable. §2 asks for a per-rule elapsed instrument; CLOUD-1217 already landed it and it is not rebuilt here.

Measured

crates/batten/tests/it/shell_retirement_cost.rs, 40 files × 1000 lines (~a quarter of production), minimum of three runs per arm, no edited governed file in any arm:

deletions	unflattened	flattened	flattened + guard
0	387.7 ms	863.7 ms	361.5 ms
2	27.50 s	870.9 ms	847.4 ms
6	81.33 s	881.6 ms	908.4 ms

The unflattened column reproduces the row's §2 table (0.43 s / 29.6 s / 96.2 s) on a smaller corpus. Six deletions cost 908 ms where they cost 81.3 s.

The middle column is why there are two commits: policy::deny queries data.batten once for the whole package, so indexing unconditionally moved work onto the shape that has none, regressing the zero-deletion floor 388 → 864 ms. count(delta.deleted) > 0 as the comprehension's first conjunct fixes it.

The bound was wrong at 3× and is 8× — corrected by measurement, not tuning

It failed on the Windows runner over a green tree: 0.68 s / 1.99 s / 2.10 s, so 3.1×. The two platforms agree on the term the case names (four more deletions cost 0.06 s here, 0.12 s there, against first-two steps of 0.49 s and 1.31 s) and disagree on the ratio of the index build to the floor — two different constants, since arm_pairs' first conjunct means the floor builds no index at all. That ratio is a property of the machine. A bound a green tree fails on a slower box is measuring the box.

2. The ceiling — perf-assert retired onto [[rule.tools]]

.claude/rules/rust.md:116 records Surface::Check as deliberately uncapped. README.md's check budget cell is ≤ 100 ms now.

The row's literal spelling (input.tree.produced, "budgets as config rows") is unbuildable; input.tree["tool-verdict"] (CLOUD-1171) is the surface that carries this shape, with mise-tasks/pkl-check.sh → validator-verdict-clean as the landed precedent. mise-tasks/perf-assert.sh and tests/perf-assert.bats are deleted with // carried: arms; policy/perf-assert.rego lands with four predicates; .github/workflows/perf.yml splits into record and assert.

Two gates land and neither is claimed to be the other. The check budget caps process-and-dispatch on a one-rule fixture, in milliseconds. The §2 harness gates the deletion-linear term over this repository's corpus, in seconds — and it is the better gate for that term because it discriminates growth shape rather than machine speed, which is exactly what the Windows reading above demonstrates.

3. Four things that were punts and are now landed

Added after review pressure on whether a full CI matrix was justified by the diff. Each was a deferral I could have closed and hadn't.

landed	why it belonged here
crates/batten/tests/it/rule_cost_rung.rs	this PR argued the -vv rung with no mechanism under it — rule 2 refuses exactly that
policy/hook-skip-local.rego (CLOUD-1340)	a High row I filed instead of fixed, on a bypass this branch itself used
policy/harness-wiring.rego guard	a wrongly-refusing gate found while landing the above
crates/batten/tests/it/perf_assert.rs repair	it read 4214/4214 green while its module was about to become unreachable

The perf_assert repair is the one to read first

findings() returned stdout and never looked at the exit code. check exits 0 clean and 2 on a verdict; a config that will not load exits 1 and says why on stderr — which the helper discarded while handing back an empty string. Every case asserting a finding failed with a blank message, and the case asserting silence passed on that same emptiness. The suite reported a dead module as a partly working one, which is worse than reporting it broken.

The trigger was verdict_rows() selecting fixture classes by prefix (starts_with("prose state")). main landed prose state other for an unrelated row; the prefix swept it into a bundle that enables one module, nothing raised it, and the registry's both-directions check failed the load. It names the four exact ids now, each asserted present as it is rendered.

hook-skip-local, and an override route added then withdrawn

HK_SKIP_STEPS names steps for hk to skip; batten never read it, so a switched-off gate and a satisfied one were byte-identical. ci-suite-lane already governs the variable in the workflow files, so the declared use was gated and the ad-hoc one was free — a hole shaped exactly like the repository's own legitimate use. Measured on this branch: the variable went onto three commits, a false justification into two commit messages, and a four-option menu to a human; batten wiring reclaim -y cleared it in one command.

The class declares no override, and that reverses a decision made earlier in this branch. The route drafted first named a real case — a step reading a generated file a later commit in the same rebase sequence writes, met three times here over bench/suites/RESULTS.md. That case is already served by --no-verify plus the articulation block commit check requires, which is gated and leaves a record in the commit; shell edit refused is precedent for a class that refuses outright. So --no-verify is the route, this class has none, and the branch carries no declared weakening — config lint against origin/main is clean rather than admitted.

The harness-wiring guard

enforced guarded a merged row on merged_read > 0, which counts surfaces that resolved rather than surfaces that carried anything. Measured after a container restart: ~/.claude/launcher-settings.json present and hookless, the other three merged ids absent, so merged_read was 1 while merged_commands was empty — and both rows of policy/harness-declared.json fired at once, while the stop-hook-git-check.sh they license was demonstrably still running. That is could-not-look rendered as a spent licence, the exact collapse the comment above that predicate says the guard exists to prevent. Guarded on count(merged_commands) > 0 now.

One comment in that module was false and is corrected rather than left: "NO MERGED ROW IS DECLARED ANY MORE." Both live rows are basenames, so both are merged rows, and the arm that comment called unreachable was the one every live row went through — which is why the coarse guard sat unexamined.

4. CLOUD-1388 — served, declined, not this branch's

mediated_verbs::the_absolute_spelling_is_refused_for_every_write_tool fails on windows only — an under-deny: a Write at an absolute batten.toml is allowed where protected must refuse it.

Attribution is evidence, not inference. git log -S puts the case at 4d5bd0cc; 604815b1 (main's, "isolate the state root…") is what repointed write_verdict onto run_with_stdin_at_real_root. And every other open PR is a draft, so CI has run Windows on none of them — #828 is the first head to ready since that commit landed, which is why it surfaced here and why the next PR to ready inherits it.

Three hypotheses were argued and all three are wrong; CLOUD-1388 records them so nobody re-walks them (LOCALAPPDATA; a separator miss; different relative_to branches — that last one checked on Linux, a check that does not transfer). The sharpest surviving observation: .serena/memories/** is a glob and batten.toml a literal, so the passing sibling is false comfort — a glob matches where an exact literal misses.

104dd663 adds the instrument rather than a guess: write_decision runs the hook at -vv and hands the assertion both streams, so the next Windows run reports what the engine did instead of one integer. That commit does not fix the defect and does not claim to — hence DO-NOT-CLOSE above.

5. Corrections owed on already-pushed history

bde7661 and eca096a1 carry a justification for HK_SKIP_STEPS that is false — they claim hooks-wiring-check refused for an environmental reason outside this container's control. It did not; batten wiring reclaim -y cleared it. The supporting diagnosis was also wrong: it asserted siblings in ~/.claude/settings.json, a file that does not exist here. Corrected here rather than rewritten, because those commits are pushed and this branch does not rewrite published history. That bypass being ungated on the local path is CLOUD-1340, closed by this PR.

A MUTANT_GATES conflict was resolved with the wrong operation. Union cannot express a deletion, and main had retired perf-compare.sh and perf-gate.sh — so two gate names with no subject came back, and mutate census caught them (names-no-subject). The tell was printed at the time: main-only: []. Main's list being a strict subset is what a deletion looks like from the union's side. Main is the authority for removals; this branch adds one name.

6. Rows

• CLOUD-1340 — closed here.
• CLOUD-1388 (Urgent) — the Windows under-deny. Served by the instrument, declined for close, needs one value off a Windows runner.
• CLOUD-1339 — hook wire duplicate named no remedy. main landed the same fix independently; this branch's version withdrawn rather than duplicated.
• CLOUD-1349 (Urgent) — a stale installed mediator answers for the tree's own gates. Hit five times on this branch: every rebase that adds a config key leaves the installed binary unable to parse batten.toml, and it always surfaces as an unrelated refusal.

7. Local state at head

mise run test 4280/4280 · batten policy test 49 bundles / 634 assertions · mutate census clean · config lint vs origin/main clean · clippy clean · filed-here clean.

---

Generated with Claude Code

https://claude.ai/code/session_01WJh9RZQeUxnYA7z7QHFnUe

[linear-code]

CLOUD-1321 shell-retirement costs ~15s per deleted governed path, and Surface::Check has no ceiling

§1 Subject

policy/shell-retirement.rego, and the absent budget for Surface::Check that mise-tasks/perf-assert.sh's BUDGETS table does not carry.

§2 The measurement

batten check --rule shell-retirement, this container, timed per commit on the PR #793 branch. Only the deleted-path count varies; no edited governed file is present in any arm:

deleted governed paths	wall clock
0 (origin/main 4d5bd0c)	0.43 s
0 (8c58d930)	0.50 s
2 (7e6d3812)	29.6 s
4 (84a2619a)	56.7 s
6 (f701914e, both large edited files reverted)	96.2 s

Linear, ~15 s per deleted governed path, off a 0.43 s floor. With the branch's eight deletions plus two large edited governed files it reaches 273 s.

§3 What is already ruled out

Not the line_sources gap (CLOUD-1320). Adding tests/**/*.bats flips the verdict from 2 to 0 and moves the runtime from 274 s to 273 s. Measured immediately after; the two defects met on one branch and the tidier story was one cause, which the numbers refute.

Not the nested per-file scan. script_dir_vars and retired_path_vars were Rego functions, the second reaching the first per line; they are rules keyed by their arguments now (landed on #793). That removed one nested scan and did not move the deletion-linear term.

Not delta acquisition. batten check --rule rules-drift over the identical delta returns in well under a second, so the engine is building the tree input cheaply and the cost is inside this module's evaluation.

So the remaining term is whatever is linear in delta.deleted — the some gone in delta.deleted iterations in mentions_retired, admitted_addition and their callees — at a very large constant.

§4 Why it matters now

batten-check runs in verify AND as a CI job, so this is paid on every lap of every landing. CLOUD-843 has ~130 more programs to retire; at ~15 s each the term grows with the campaign's own success, and a bundle retiring ten paths pays 150 s before any other rule runs.

.claude/rules/rust.md records that perf-assert deliberately budgets no ceiling for Surface::Check, and cites batten check over 654 tracked files at p50 8.67 ms as the reading that made a ceiling unnecessary. That reading predates any policy rule doing per-deleted-path work. The absence of a ceiling is a stated decision, which is exactly why it needs re-deciding with a number rather than being left to somebody noticing.

The CI reading, added 2026-09-02 — this is the last link of the ci job's serial chain

Measured from ci.yml run 33586699312 (head ee1c9f52, no deleted governed path): the hk gate's cargo chain is a serial ~190s cold debug build → cargo-clippy 75s → test 267s → batten-check 215s, ~12.5 of the job's 14.5 minutes, on 2 cores. CLOUD-1225 recorded batten-check at 99s and 60s on two earlier runs of the same shape. So the zero-deletion cost of enforce under CI varies 60–215s across three runs and nothing records which rule is paying it — the module timing above was taken by hand with --rule, one rule at a time. That is why the first half below is an instrument rather than a guess: a per-rule wall clock is what turns this row's bisection into a number the next reader can take in one run, and what makes the Surface::Check ceiling assertable at all.

Refinement — Ready (name the term with an instrument, then cap the surface)

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

• **Authority boundary (§1). **policy/shell-retirement.rego (the linear term, once named); crates/batten/src/policy.rs or its evaluation seam (a per-rule elapsed-time reading, emitted only under -v as rule-id ms, pointer-only); and the ceiling's home, DECIDED 2026-09-02 so the implementer does not choose: mise-tasks/perf-assert.sh is governed and its BUDGETS table cannot be edited, so this PR retires perf-assert whole — perf-assert.sh and tests/perf-assert.bats (0.9s) deleted with // carried: arms, the predicate landing as policy/perf-assert.rego over input.tree.produced (the hyperfine record perf writes) and README's budget column in input.tree.lines, with the budgets as config rows the module reads. CLOUD-1164 already records this member as "a board-gate-shaped predicate over a produced record plus README's budget column — plausibly unblocked today"; this is that retirement, and the check ceiling is one more row in the table it carries. Its #MUTANT row (perf-assert.sh:54) re-homes onto the module under a #MUTANT-SUITE line. No other governed file is edited.
• **Computable predicate (§2). **batten check --rule shell-retirement -v over the §2 harness prints one elapsed reading per rule, and the deletion-linear term is named at a path:line in the module with the clause that produces it rewritten so the table above reads flat (≤ 2× the 0.43s floor at six deletions). perf-assert then holds Surface::Check over this repository's own tree to a ceiling taken from that flattened reading, and a rule that reintroduces per-path work is refused at its commit.
• Deliberately not in scope (§2). The cold debug build, clippy and nextest terms of the same chain (CLOUD-1225, CLOUD-840, CLOUD-1210, PR fix(ci): put the dev profile in the rust-cache key, and stop asserting one rule with all 103 #819). The line_sources gap (CLOUD-1320, ruled out above). Any change to what shell-retirement decides — a conserved verdict over every arm in §2, checked by the module's own test_ rules staying green.
• **Effect (§3). **read. The timing is a reading the engine already has the clock for; it spawns nothing and writes nothing.
• Output and exit (§5). The per-rule line is -v-only and pointer-shaped (rule-id ms), never a finding's content. Exit codes unchanged; perf-assert's new row answers 1 over budget like its siblings.
• **Commit / bump (§6). **perf(policy) for the flattened term and the -v reading, refactor(ci) for the perf-assert retirement — two commits, one PR, no bump: neither type releases anything at any version.
• **Test obligation (§7). **crates/batten/tests/it/ as a mod: the §2 harness as a case — a synthetic base delta with 0, 2 and 6 deleted governed paths, asserting the flattened ratio; shown able to fail per CLOUD-418 by reverting the module clause and watching the ratio case go red; a case that the -v line is absent without -v (the anti-vacuity mirror). the module's check ceiling shown red against a deliberately over-budget produced record, and its missing clause asserted over the compiled binary; two // carried: arms, and mutant-census green after the PR.
• Blockers (§8). None. relatedTo CLOUD-843 (the campaign that grows the term), CLOUD-1217 (the last enforce speed-up, 84→37s), CLOUD-1320 (ruled out), CLOUD-1225 (the rest of the chain), CLOUD-1151 (the dispatch it rides in), CLOUD-770 (README's published budget column).

Acceptance

• The §2 table re-taken on the branch reads within 2× of the floor at six deletions, and the named clause is cited at a path:line.
• batten check -v prints one elapsed reading per rule and nothing more; without -v the output is byte-identical to today.
• perf-assert.sh and its suite are gone, policy/perf-assert.rego carries every budget it carried plus a check ceiling, README publishes it, and the ceiling is shown able to fail.
• batten-check's step wall on a zero-deletion CI run is recorded against the 215s above.

§6 Cost of not doing it

Measured: three hours of one session spent on a check that never returned, plus a wrong bisection published and then retracted because "fast" meant "inside whatever timeout I happened to set". Every arm I called fast was 30–96 s.

§8 Blocks

Blocks nothing today — #793 lands at 273 s. It gets worse monotonically with CLOUD-843.

---

Found while landing PR #793 (Bundle A of CLOUD-843).

CLOUD-1340 `HK_SKIP_STEPS` switches a gate off on the local path and nothing records it, while batten's own nine hatches are declared and censused

§1 Subject

HK_SKIP_STEPS as spent on the LOCAL path — HK_SKIP_STEPS=<step> git commit, and the same variable inherited by mise run verify and mise run land. Not its use inside .github/workflows/*.yml, which policy/ci-suite-lane.rego already reads and decides.

§2 The measurement

Measured 2026-09-02 while landing CLOUD-1321.

HK_SKIP_STEPS=hooks-wiring-check was spent on three commits and on two land invocations. Nothing asked why, nothing recorded it, and no gate saw it. The only reason it is visible at all is that the session chose to write it into the commit messages — which is a courtesy, not a mechanism, and two of those messages state a justification that is now known false (CLOUD-1339).

The asymmetry is the finding. batten.toml declares nine BATTEN_*_BYPASS hatches. Each is a declared string, scrubbed on the mediated path, and censused. HK_SKIP_STEPS reaches the identical outcome — a declared gate does not run — and on the local path has none of that.

policy/ci-suite-lane.rego proves the variable is already known to the engine, and proves the bound: it reads step.env.HK_SKIP_STEPS and job.env.HK_SKIP_STEPS out of input.tree.documents for workflow files (:80, :88). A workflow carving out test:bats is decided. An agent typing the same variable at a shell is not.

§3 Why this is the shape CLOUD-1051 already removed once

BATTEN_FILED_HERE_BYPASS and BATTEN_FILED_HERE_OVERLAP were deleted rather than ported, on the recorded ground that they were "knowable strings anyone could spend without articulating anything", replaced by batten override request/spend with a declared precondition.

HK_SKIP_STEPS is that same shape one layer out, and it is cheaper to spend than the hatches that were deleted: it needs no batten.toml row, no bypass_env declaration, and it is documented by hk rather than by this repository, so a reader looking for the repo's own escape hatches will not find it.

It is also strictly more powerful than a bypass_env. A BATTEN_X_BYPASS silences one declared row. HK_SKIP_STEPS takes a comma-separated list and can silence test, batten-check, cargo-clippy — whole steps, each covering many rows — in one assignment.

§4 What the honest use looks like, because it is not "ban it"

The three spends on CLOUD-1321 were, at the time, over a real environmental refusal on a step whose remedy the session could not find (CLOUD-1339). A ban would have stopped the branch; what was missing was a record, not a prohibition.

Refinement — Ready (a spend leaves a record)

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

{
  "source_of_truth": "policy/ci-suite-lane.rego reads `HK_SKIP_STEPS` only from `input.tree.documents` for workflow files (:80, :88), so a spend typed at a shell reaches no gate; batten.toml declares nine `BATTEN_*_BYPASS` hatches that are scrubbed and censused, and this one is neither",
  "gate": { "task": "batten-check", "exits": [0, 2] },
  "commit_type": "feat",
  "blockers": [],
  "tests": [
    { "file": "policy/run-shape.rego", "mutation": "background-not-consulted" },
    { "file": "policy/ci-suite-lane.rego", "mutation": "lane-carveout-unread" }
  ]
}

• Authority boundary (§1). A mediated_call predicate over an environment assignment on the call, plus whatever batten.toml row declares it. hook::segments already carries environment assignments — the boundary that resolves programs[_].program "through wrappers, environment assignments and every spelling of the mediator's own invocation" already sees this, which is what makes the question expressible without a second parser.

• Computable predicate (§2). A mediated call carrying HK_SKIP_STEPS in its environment is refused unless an admission for it has been issued and spent, on the path write refused model — the spend articulates which step, and why, and the articulation travels in the commit like CLOUD-1278's block. Silence stays the default for a workflow spend, which ci-suite-lane already owns.

• Deliberately not in scope (§2). The workflow half. Banning the variable outright: §4 records why that would have stopped a legitimate branch.

• **Effect (§3). **read on the mediated call.

• Test obligation (§7). A compiled-binary tier driving a real call carrying the assignment, plus the negative — a call without it is untouched, and a workflow document carrying it still reaches only ci-suite-lane. Shown able to fail by spending the variable with no admission.

  The claims above name EXISTING mutations in the two modules this work touches, so they bind today; verify lane-carveout-unread against policy/ci-suite-lane.rego's own rows when picking this up and substitute a real slug from that file if it has been renamed. The first draft named skip-steps-unrecorded and policy/guardrail-bypass.rego:foreign-hatch-uncounted — the first slug does not exist and the second FILE does not exist at all. obligations-bound refuses a declared slug that is not a #MUTANT row in a tracked declared file, and it caught this on the filing branch.

• Blockers (§8). None. relatedTo CLOUD-1339 (the refusal that made the spend look necessary), CLOUD-1051 (the hatches deleted for this shape), CLOUD-1278 (the articulation-in-the-commit mechanism this would reuse).

Acceptance

• A local HK_SKIP_STEPS spend is refused without an admission, and the admission's articulation names the step.
• A workflow HK_SKIP_STEPS is unaffected and still decided by ci-suite-lane.
• Shown able to fail.

§6 Cost of not doing it

Measured on CLOUD-1321: three commits carrying a switched-off gate, with the only record being prose the author volunteered — and that prose was wrong. A gate that can be switched off by a string nobody declared is a gate whose green means less than it reads.

---

Found while landing CLOUD-1321 (PR #828).

CLOUD-1388 windows: an absolute Write at batten.toml is allowed where protected must refuse it

The defect, measured

mediated_verbs::the_absolute_spelling_is_refused_for_every_write_tool fails on the windows job. It is an under-deny: a Write at an absolute batten.toml is ALLOWED where the protected set must refuse it.

assertion `left == right` failed: Write at an absolute protected path is refused
  left: Some(0)
 right: Some(2)
crates\batten\tests\it\mediated_verbs.rs:528

First seen on run 33704247426 (PR #828, head 52fd3f7c). Every other required check on that head is green.

Why this is Urgent rather than a test nit

The subject is batten.toml — the policy authority. Its own protected comment says deleting it "is the maximal weakening — it disarms every gate at once, including this one." A Windows host writing it through an absolute path is unrefused today, and the case that would have caught that is the one failing. The test is doing its job; the engine is not.

What is established

• The case predates the change: git log -S "the_absolute_spelling_is_refused_for_every_write_tool" puts its introduction at 4d5bd0cc.
• 604815b1 ("test(harness): isolate the state root for the suites whose subject is the real repository") is the most recent change to the file, and it repointed write_verdict and its neighbours from run_with_stdin to run_with_stdin_at_real_root. The only behavioural delta for these cases is state_dir(scratch_state_root()).
• No other pull request has run the windows job since. Every other open PR (829, 833, 837, 839, 840, 793, 801, 791, 676, 659) is a draft, and CI does not run on drafts. perf(policy): the retirement ledger is read once, not once per deleted path #828 is the first head to ready after 604815b1 landed, which is why it surfaced there and nowhere else. The next PR to ready inherits it.

What is ruled out

Recorded so the next reader does not re-walk them — both looked plausible and both are wrong:

• Not LOCALAPPDATA being an uncreated directory. state::state_root resolves through etcetera::choose_base_strategy().data_dir(), and etcetera-0.11.0/src/base_strategy/windows.rs reads APPDATA for data_dir() and LOCALAPPDATA only for cache_dir(). common::state_dir points APPDATA at the directory scratch_state_root() calls create_dir_all on. The state root is on a created path.
• Not a path-separator rendering miss. hook::relative_to ends with .replace('\\', "/") for CLOUD-1141's reason. A root-level batten.toml relativises to a name with no separator in it, so separator handling cannot lose it — and if it could, the nested .serena/memories/core.md case would be the failing one, which is the opposite of what is observed.
• Not the two cases taking different branches of relative_to. Both subjects exist on disk, so both take the candidate.canonicalize() branch rather than the parent-peel fallback.

The observation that most narrows it

a_protected_write_is_refused_in_both_spellings_the_host_can_send passes in the same run, over the same helper, the same canonicalize(), and the same Write tool. The two differ only in subject, and both subjects are in the same list:

protected = [
  ".serena/memories/**",   # passes
  "batten.toml",           # fails
  ".github/workflows/**",
]

One is a ** glob, the other an exact literal. A glob matches strings an exact literal misses, so the sibling's green is false comfort: it does not establish that relativisation returns a correct value on Windows, only that whatever it returns still satisfies a permissive matcher. Look at what relative_to actually returns on Windows for a root-level file, and at how PathSet::contains compares a literal entry against it — not at the passing case.

Why no fix is attached

Windows-only, reproducing on no other platform available here. Attaching an unvalidated patch would be a guess pushed into CI, and the two hypotheses above were both confident and both wrong. This needs one observation from a Windows runner — the value of rendered in hook::relative_to for an absolute batten.toml — after which the fix is likely one line.

Acceptance

• mediated_verbs::the_absolute_spelling_is_refused_for_every_write_tool passes on the windows job.
• The fix names what relative_to returned on Windows and why it missed the literal.
• It does NOT widen the batten.toml entry to a glob: that would hide the defect behind exactly the false comfort the sibling case already provides.
• A case that discriminates the literal entry specifically, so a regression cannot pass on the glob entry alone.

Refinement - Ready (the engine refuses an absolute protected write on every platform)

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

{
  "source_of_truth": "the windows job on run 33704247426 reports left Some(0) right Some(2) at crates/batten/tests/it/mediated_verbs.rs:528, while the same helper and the same Write tool pass for .serena/memories/core.md in the same run",
  "gate": { "task": "test", "exits": [0, 1] },
  "commit_type": "fix",
  "blockers": [],
  "tests": [
    { "file": "policy/shell-retirement.rego", "mutation": "arms-for-unread" }
  ]
}

• **Authority boundary (§1). **hook::relative_to and whatever reads its output. No config row moves, and in particular protected is not edited.
• **Computable predicate (§2). **mediated_verbs::the_absolute_spelling_is_refused_for_every_write_tool exits 2 on the windows job. It exits 0 today.
• Deliberately not in scope (§2). Widening the batten.toml entry in protected into a glob. That would make the case pass by giving the literal the permissive matcher the sibling already has, which is the false comfort this row is about, and would leave every other literal entry unprotected on Windows.
• **Effect (§3). **read.
• Test obligation (§7). The case exists and already fails on one platform, so the fix is shown able to fail by construction. A #MUTANT row is owed only if the fix adds a new predicate rather than repairing relative_to.
• Blockers (§8). None. 104dd663 on PR perf(policy): the retirement ledger is read once, not once per deleted path #828 already installs the instrument: write_decision runs the hook at -vv and the assertion prints both streams, so the next Windows run reports the value the fix needs.

The mechanism, as a computable predicate. mediated_verbs::the_absolute_spelling_is_refused_for_every_write_tool exits 2 on the windows job. It exits 0 today. Nothing else in the suite changes.

The one observation the fix needs. hook::relative_to ends with:

let relative = resolved.strip_prefix(&root).ok()?;
let rendered = relative.to_str()?.replace('\\', "/");
(!rendered.is_empty()).then_some(rendered)

What is rendered on Windows when path is an absolute batten.toml and root is the repository root? Every remaining hypothesis is a guess until that string is read. 104dd663 on PR #828 already installs the instrument: write_decision runs the hook at -vv and the assertion prints both streams, so the next Windows run on that branch reports it without further work.

Obligation. crates/batten/tests/it/mediated_verbs.rs:the_absolute_spelling_is_refused_for_every_write_tool — the case exists and currently fails on one platform, so the fix is shown able to fail by construction. A #MUTANT row is owed only if the fix adds a new predicate rather than repairing relative_to.

Scope bound. Do not widen batten.toml's protected entry for batten.toml into a glob. That would make the case pass by giving the literal the same permissive matcher the sibling already has — the false comfort this row is about — and would leave every other literal entry, present and future, unprotected on Windows.

Priority is Urgent on the subject, not the symptom. The unrefused path is the policy authority itself, and batten.toml's own comment calls writing it "the maximal weakening — it disarms every gate at once, including this one."

Not blocked on PR #828. The instrument commit is independent of the perf work; whoever takes this can read the value off that branch's next Windows run, off a one-line diagnostic PR of their own, or off any Windows checkout.

Review in Linear

[coderabbitai]

Warning

Review limit reached

Next included review available in 33 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: f6063a77-114b-47b7-836f-ade2d27b3ae5

📥 Commits

Reviewing files that changed from the base of the PR and between 498642c and eaf18d0.

📒 Files selected for processing (20)

• .github/workflows/perf.yml
• README.md
• batten.toml
• bench/suites/RESULTS.md
• crates/batten/tests/it/cli.rs
• crates/batten/tests/it/hook_skip_local.rs
• crates/batten/tests/it/main.rs
• crates/batten/tests/it/mediated_verbs.rs
• crates/batten/tests/it/perf_assert.rs
• crates/batten/tests/it/perf_pair.rs
• crates/batten/tests/it/rule_cost_rung.rs
• crates/batten/tests/it/shell_retirement.rs
• crates/batten/tests/it/shell_retirement_cost.rs
• mise-tasks/perf-assert.sh
• mise.toml
• policy/harness-wiring.rego
• policy/hook-skip-local.rego
• policy/perf-assert.rego
• policy/shell-retirement.rego
• tests/perf-assert.bats

---

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

[wenzowski]

windows is red on 52fd3f7, and it is not this PR's

mediated_verbs::the_absolute_spelling_is_refused_for_every_write_tool fails on the windows job only — run 33704247426. Every other required check is green.

assertion `left == right` failed: Write at an absolute protected path is refused
  left: Some(0)
 right: Some(2)
crates\batten\tests\it\mediated_verbs.rs:528

An under-deny: a Write at an absolute batten.toml was allowed where the protected set must refuse it.

Why it is not this branch's

git log -S "the_absolute_spelling_is_refused_for_every_write_tool" puts the case's introduction at 4d5bd0cc, long before this branch. The most recent change to the file is 604815b1 — "test(harness): isolate the state root for the suites whose subject is the real repository", landed on main while this branch was open, and this branch rebased onto it. That commit is what repointed write_verdict and its neighbours from run_with_stdin to run_with_stdin_at_real_root:

+use common::{run, run_with_stdin_at_real_root, stderr};
+    run_with_stdin_at_real_root(

So the case predates the branch, the helper under it changed on main, and this branch touches neither. The diff here adds a mediated_call module, three config rows, a guard in policy/harness-wiring.rego and three test files — no path resolution, no state-root handling, nothing mediated_verbs reads.

The sibling case a_protected_write_is_refused_in_both_spellings_the_host_can_send passes in the same run over the same helper, so the config loads and denies work; the difference between them is the subject (batten.toml vs .serena/memories/core.md), not the machinery.

Why there is no push here instead of a comment

The failure is Windows-only and this container is Linux, so I cannot reproduce it, and I will not push an unvalidated fix for somebody else's defect into this PR — one validated push beats three speculative ones, and a guess is how a red job becomes two.

Where I would look first

common::scratch_state_root() creates its directory, and common::state_dir then points LOCALAPPDATA at dir.join("cache"), which nothing creates:

command
    .env("XDG_DATA_HOME", dir)
    .env("APPDATA", dir)
    .env("LOCALAPPDATA", dir.join("cache"))

On Windows the state root resolves through LOCALAPPDATA, so an absent directory there is a plausible cause of a Windows-only state read failing in a way POSIX never sees — scratch_state_root's own comment notes CLOUD-619's defect was a name that "was POSIX-only and redirected nothing on Windows". Creating the cache directory alongside the root is safe on every platform and costs nothing if it is not the cause. Stated as a direction, not a diagnosis — I have not measured it.

Local state on this branch's head: mise run test 4220/4220, batten policy test 49 bundles / 634 assertions, mutate census 115 gates, config lint against origin/main clean, clippy clean.

---

Generated by Claude Code

[wenzowski]

Correction: the direction I proposed above is wrong

The LOCALAPPDATA lead in my previous comment does not hold, and I would rather retract it than leave a plausible-looking pointer for the next reader to spend an hour on.

state::state_root resolves through etcetera::choose_base_strategy().data_dir(). In etcetera-0.11.0/src/base_strategy/windows.rs:

fn data_dir(&self) -> PathBuf {
    Self::dir_inner("APPDATA").unwrap_or_else(|| self.home_dir.join("AppData").join("Roaming"))
}

fn cache_dir(&self) -> PathBuf {
    Self::dir_inner("LOCALAPPDATA")

So the state root reads APPDATA, which common::state_dir points at dir — and scratch_state_root() calls create_dir_all on exactly that directory. LOCALAPPDATA feeds cache_dir(), which nothing in the state path calls. The directory I said was missing is not on the resolution path at all.

What still stands from the previous comment is only the attribution, which is evidence rather than inference: git log -S puts the case at 4d5bd0cc, and 604815b1 is what repointed write_verdict onto run_with_stdin_at_real_root. The cause inside that change is not identified, and I am not going to name a second guess.

Two observations for whoever picks it up, offered as facts rather than as a diagnosis:

• The sibling a_protected_write_is_refused_in_both_spellings_the_host_can_send passes in the same run, over the same helper and the same canonicalize(). The two differ only in subject — .serena/memories/core.md passes, batten.toml fails.
• That direction is the opposite of a path-separator explanation. A root-level batten.toml relativizes to a name with no separator in it; the memory path has two. If backslashes were the cause, the passing and failing cases would be the other way round.

---

Generated by Claude Code

[sonarqubecloud]

❌ The last analysis has failed.

See analysis details on SonarQube Cloud

[wenzowski]

/fast-forward