test(#805): check the corpus's zone accounting per zone, not only in its last statement

[djhenry]

Closes #805

Revision note. This body was rewritten for review round 2. Every measurement below was taken on
the shipped head (3667927), branch merged with origin/main 41cca4e. Claims from round 1 that
the reviewer measured false are gone, not softened — see the "What round 2 changed" section at the
bottom for the list, so the correction is auditable rather than silent.

The defect

#762 gave faithful_walker_drift_corpus a completeness refusal — "a hole in the corpus is not a
water score" — and made it the last statement of the test. #763 says the corpus never terminates
on blackburrow. So on the one run where a zone is known to misbehave, the refusal is not reached: a
guard that is written and not run. Same shape as #778's scanner and the #799 source pins.

Mechanism: close the accounting per zone

Opening a zone in the corpus loop now goes through open_zone_checked(&mut roll_wr, &mut roll_423, zone) (in tests/walker_sim.rs) instead of a bare begin_zone pair. Before it opens zone K it
refuses the run if any already-closed zone sits in the unaccounted or unmeasured bucket. A
run that hangs, returns early, or dies at zone K has therefore already checked zones 1..K-1 for
both.

skipped is deliberately not checked per zone, and the reason is diagnostics, not
decidability. All three buckets are push-only Vecs, so all three are settled the instant a zone
closes and none can un-fire; a per-zone refusal on skipped could never fire where the terminal one
would not. What is true is that skipped is the common state of a partial $ZONE_DIR, i.e. the
normal state of a dev box: on the two-zone run below, akanon is skipped for "no routable pairs" at
zone 1 of 2, so gating skipped here would kill the run before crushbone's 60 journeys ever
run — and skipped is already printed per zone in the table ((no glb — skipped)), so gating it
buys little. That is a judgement call, and it is labelled as one in the code.

Alternatives rejected, and the failure mode each has

Option	Why not
Drop impl on WaterRollup that asserts	Three problems, the last decisive. (a) WaterRollup lives in crates/eqoxide-nav/src/water_grid.rs, which is held by open PR #821 — editing it manufactures a conflict. (b) A Drop that panics while a panic is already unwinding aborts the process, replacing a real corpus failure's diagnostics with a confusing abort; avoidable only with a std::thread::panicking() guard, which then makes the guard do nothing on exactly the runs that already failed. (c) A hang never drops anything. Drop runs on scope exit or unwind; a process wedged inside zone K's loop body does neither. The mechanism that looks strongest against "the last statement is skipped" does not fire in #805's scenario at all.
A reach counter asserted at the end (issue's option 3)	Terminal again, so a hang skips it — the issue says as much. It is also the PR #818 trap: a counter that consults the guard's own predicate certifies itself.
Watchdog thread / wall-clock timeout that turns the hang red	That is working around #763, which is explicitly out of scope. It is also unsound as written: a panic! on a non-test thread does not fail a libtest test, so it would need process::abort, which destroys all captured output — the opposite of the honesty goal. And the threshold would be flaky by construction: a two-zone run measured 49 s–150 s here depending on which zones, and the corpus's runtime is a function of whatever $ZONE_DIR happens to contain.
Full is_complete() per zone (i.e. also gate skipped)	Aborts the table on the first missing .glb / unroutable zone. Measured below: it would kill this box's own two-zone run at zone 1. This is the diagnostics trade, not a claim that it cannot be decided.
Fix #763	Out of scope by instruction; and the point of this PR is that the guard should survive the hang, not depend on its absence.

What an operator sees

• On a hang: nothing new. There is no timeout here and faithful_walker_drift_corpus never terminates on blackburrow — the wat-route:12 baseline is now unreplaceable #763 is untouched. An operator watching a
  wedged blackburrow run still sees nothing extra. The gain is only that zones 1..K-1 are verified
  individually as they complete, instead of all of them resting on a statement the run never
  reaches.
• When the gate does fire, it prints a partial rollup line first, then panics — because the
  corpus's own total line runs after the loop and so never executes on an aborted run. That line
  is explicitly labelled PARTIAL and "not a corpus score", since the zones after the offending one
  were never opened. Raw output in RED-A below.
• The zone still OPEN when a run stops is not covered. Nothing closes it and no later
  begin_zone observes it, so it remains the terminal assert's job — as does skipped, for every
  zone. The terminal assert is still load-bearing; it is not a backstop.

Mutation checks — both directions, all on the shipped tree

Every run below is on 3667927's tests/walker_sim.rs. Between runs the file was restored from a
byte-identical copy (md5sum verified, git status --porcelain empty). Four of the six use the
real corpus loop against real baked zone GLBs, so the mutation is at the real call site and not
only in a fixture.

M1 — kill the gate at the CALL SITE (not in its body)

In the reach-control test, open_zone_checked(&mut wr, &mut r423, zone); → wr.begin_zone(zone); r423.begin_zone(zone);. RED:

test zone_accounting_fires_before_the_corpus_loop_ends - should panic ... FAILED

---- zone_accounting_fires_before_the_corpus_loop_ends stdout ----
panicked at tests/walker_sim.rs:951:22:
UNREACHED: zone "zone_c_never_terminates" opened without the #805 gate firing on zone_b_abandoned — the gate is dead
note: panic did not contain expected string
      panic message: "UNREACHED: zone \"zone_c_never_terminates\" opened without the #805 gate firing on zone_b_abandoned — the gate is dead"
 expected substring: "unaccounted (left the loop body without reaching add or skip"

test result: FAILED. 10 passed; 1 failed; 5 ignored; 0 measured; 0 filtered out; finished in 0.07s

The should_panic substring is hand-written text; it does not consult unaccounted_zones() or
anything else the gate consults, so instrument and subject do not share a code path (#818).

M2 — the "written but not reached" evasion

if orphans.is_empty() && unmeasured.is_empty() { continue; } → if true { continue; }. The whole
refusal — println! and panic! — stays in the source and is never executed. Three of the four
gate tests RED, all with a wrong-message should_panic failure:

test zone_accounting_covers_the_423_rollup_not_just_wat_route - should panic ... FAILED
test zone_accounting_fires_before_the_corpus_loop_ends - should panic ... FAILED
test zone_accounting_refuses_an_unmeasured_zone_before_the_corpus_ends - should panic ... FAILED
test zone_accounting_stays_silent_while_every_zone_is_closed ... ok

panicked at tests/walker_sim.rs:1002:9:
UNREACHED: zone_b opened with `#423` still holding an abandoned zone_a — the gate only consults the wat-route rollup
panicked at tests/walker_sim.rs:951:22:
UNREACHED: zone "zone_c_never_terminates" opened without the #805 gate firing on zone_b_abandoned — the gate is dead
panicked at tests/walker_sim.rs:1025:9:
UNREACHED: zone_b opened after zone_a closed UNMEASURED — the run would have gone on to report a water column with a hole in it, which is #762's exhibit

test result: FAILED. 8 passed; 3 failed; 5 ignored; 0 measured; 0 filtered out; finished in 0.07s

The one test that stays green under M2 is the no-false-positive control, which is the correct
direction for it.

RED-A — real corpus, real GLBs, a .wtr removed (the unmeasured bucket, #762's exhibit)

crushbone.wtr moved aside, ZONES=crushbone,felwithea, release. The gate fires while opening
felwithea, i.e. mid-loop:

zone         walked  wedged   height  overlap  other wat-route   #423
crushbone         -       -        -        -      - unmeasured unmeasured   (unmeasured: no .wtr file for this zone)

=== FAITHFUL WALKER DRIFT [ABORTED while opening felwithea] — PARTIAL rollups; the zones after felwithea were never opened, so this is not a corpus score: wat-route: 0 over 0/1 zones — INCOMPLETE, 1 unmeasured [crushbone: no .wtr file for this zone], #423: 0 over 0/1 zones — INCOMPLETE, 1 unmeasured [crushbone: no .wtr file for this zone] ===

panicked at tests/walker_sim.rs:916:13:
#805/#762: opening zone "felwithea", but the wat-route rollup already holds a hole that the terminal
assert would only have reported at the END of a run that may never get there (#763). unaccounted
(left the loop body without reaching add or skip — a corpus WIRING bug, not an asset problem): [];
unmeasured (the water check ran and the .wtr did not load, so the zone was abandoned unwalked with
no number — #762's exhibit): ["crushbone"]. ...

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.48s

RED-B — the same assets with the gate removed from the real call site (the pre-#805 picture)

open_zone_checked(…) → the bare begin_zone pair, same command:

crushbone         -       -        -        -      - unmeasured unmeasured   (unmeasured: no .wtr file for this zone)
felwithea        60       0        0        0      0         0      0   (0 forced)

=== FAITHFUL WALKER DRIFT [DRY]: 60 full journeys walked, 0 terminal wedges (0.00%) — ... wat-route: 0 over 1/2 zones — INCOMPLETE, 1 unmeasured [crushbone: ...] ===

panicked at tests/walker_sim.rs:828:9:
#762: this run has a hole in its water coverage ... unmeasured: ["crushbone"]; skipped: []; unaccounted: []

test result: FAILED. 0 passed; 1 failed; ... finished in 49.05s

The whole loop ran — felwithea's 60 journeys included — and the hole was reported only by the last
statement. That is exactly the #805 shape and exactly the statement a non-terminating run does not
reach.

GREEN — every .wtr present, gate silent, no false positive

ZONES=akanon,crushbone, all region files present:

akanon        (no routable pairs — skipped)
crushbone        60       0        0        0      0         0      0   (0 forced)

=== FAITHFUL WALKER DRIFT [DRY]: 60 full journeys walked, 0 terminal wedges (0.00%) — ... 1 skipped [akanon (no routable pairs)] ===

panicked at tests/walker_sim.rs:828:9:
#762: ... wat-route — unmeasured: []; skipped: ["akanon"]; unaccounted: []
                                    finished in 149.52s

No [ABORTED …] line anywhere: the gate stayed silent across both zones, the whole table printed,
and the run fails at the terminal assert on the pre-existing skip — the same outcome as before this
PR. This is also the measurement the skipped exemption rests on: akanon is skipped at zone 1 of 2.

M_G — what the gate at the REAL call site is NOT pinned by

Reverting the corpus's open_zone_checked(…) to the bare begin_zone pair and running the whole
workspace suite: 55 headers = 55 results, 0 non-canonical, 14 all-zero,
1815 + 0 + 47 + 0 = 1862 — identical to the unmutated figures, and the sorted set of
test … ok|ignored lines (1819 of them) is diff -q-identical. Nothing CI runs notices the fix
being deleted. That is disclosed in open_zone_checked's rustdoc in those words; see "NOT verified"
below.

Simulating the hang without blackburrow

Blackburrow cannot be run (it hangs, per #763), so early termination is proved on WaterRollup
alone with no GLB: zone_accounting_fires_before_the_corpus_loop_ends walks a three-zone list whose
second zone is abandoned and whose third stands in for blackburrow, and both statements after the
loop are panic!("UNREACHED: …") with messages the should_panic filter rejects. The test passes
only if the gate fires at zone 3 before anything post-loop runs.

The five figures

cargo test --workspace --locked --no-fail-fast on the remote build host, stdout and stderr
captured separately.

1. Finished \test` profileappears once — that is the **build** finishing, not the run. The completion signal used here was process exit plus a complete finaltest result:` line.
2. 55 ^running [0-9]+ tests?$ headers vs 55 ^test result: lines — equal, no lost binary.
   (The regex matches test and tests; running 1 test is singular.)
3. 0 non-canonical result lines.
4. 14 all-zero targets, field-anchored on
   ^test result: ok\. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out.
5. 1815 passed + 0 failed + 47 ignored + 0 filtered out = 1862, and the header total is 1862.

origin/main 41cca4e baseline is 55 = 55, 0 non-canonical, 14 all-zero, 1857 total. Delta +5,
reconciled by name — the five tests this PR adds:

• zone_accounting_fires_before_the_corpus_loop_ends
• zone_accounting_stays_silent_while_every_zone_is_closed
• zone_accounting_covers_the_423_rollup_not_just_wat_route
• zone_accounting_refuses_an_unmeasured_zone_before_the_corpus_ends
• doc_comment_citations_in_this_file_are_rename_guarded

No target count changed. scripts/check-no-local-detail.sh → OK — no forbidden patterns in tracked files.

One test that is not about #805, and why it is here

The first workspace run in round 1 went RED on
eqoxide-nav … every_test_citation_in_the_four_citation_files_resolves_and_is_listed_in_a_guard:
open_zone_checked's rustdoc cites faithful_walker_drift_corpus by name, tests/walker_sim.rs is
in that scan's citation corpus, and the file had no guard array.
doc_comment_citations_in_this_file_are_rename_guarded supplies the let _cited: &[fn()] the scan
requires. That failure was measured, not anticipated — it is why the test exists.

Why this still says Closes #805, and what remains terminal-only

#805's exhibit is #762's motivating defect: a .wtr that did not load being scored as 0, on a run
that may never reach the reconciliation. That bucket — unmeasured — is now refused per zone, as is
unaccounted, and RED-A demonstrates the refusal firing at the real call site mid-loop. So the
issue's own scenario is covered and Closes is the honest verb.

Two things stay in the terminal assert, both named in the code rather than glossed:

1. skipped, for every zone — the diagnostics trade above. If a reviewer judges that leaving
   skipped terminal means #762's completeness guard is the corpus's LAST statement, so blackburrow's non-termination (#763) skips it entirely #805 is not closed, the one-word fix is Refs #805; I am not treating
   that as a defensible-either-way toss-up, I am stating my reason and the cost of the alternative.
2. The zone still open when a run stops — structurally uncoverable from a per-zone gate, since
   nothing closes it and no later begin_zone observes it.

NOT verified, and not claimed

• Reach limit — CI never runs the corpus, so the fix itself is unpinned.
  faithful_walker_drift_corpus is #[ignore]d and .github/workflows/test.yml runs
  cargo test --workspace --locked with no --ignored. M_G measures the consequence exactly:
  delete the open_zone_checked(…) call from the corpus loop and the entire workspace suite stays
  byte-identically green. The four gate tests pin the helper's behaviour; nothing CI runs pins
  that the corpus calls it. This is Source-scan call-site pins prove a call is written, not reached (#721 A2b, #773 E1b/E2, #791 round 1) #799 applying to this PR, it is written in the rustdoc in those
  words, and it is not fixed here — whether #[ignore]d tests should run in CI is The merge gate cannot see asset-gated pins: #[ignore]'d tests carry load-bearing evidence CI never runs #777 / Asset-gated #[ignore]d tests never run anywhere — the #648 capability tests were merged unexecuted by any reviewer #654 /
  Decision: synthetic mini-zone fixtures vs a self-hosted runner for asset-gated CI (#657 is blocked on this) #659, an owner-gated decision I did not touch (no CI config, no un-#[ignore]ing, no runner
  proposed).
• faithful_walker_drift_corpus never terminates on blackburrow — the wat-route:12 baseline is now unreplaceable #763 is untouched. No timeout, no watchdog, no attempt to make blackburrow terminate.
  Blackburrow was never run; its hang is not observed anywhere in this PR. Every "hang" claim here is
  about early termination in general, simulated on WaterRollup with a truncated zone list.
• A hang still produces no new operator-visible output. Stated in the code, stated above.
• The corpus's total line printing after the loop is a claim about statement order in
  tests/walker_sim.rs, established by reading the file — and consistent with RED-A's stdout, where
  the total line is absent and only the [ABORTED …] partial line appears. It is not an observation
  of a hung run.
• Two-/three-zone corpus, not eleven. The real-corpus runs used ZONES=akanon,crushbone and
  ZONES=crushbone,felwithea. I did not run the default eleven-zone corpus and make no claim about
  its numbers. akanon skipping for "no routable pairs" is what that asset set produced on that host;
  it is not asserted to be a property of akanon.
• open_zone_checked has seven lexical call sites on this tree — one in the corpus loop, six
  across the four gate tests. (Round 1's body said "both call sites"; there were four then, and the
  reviewer was right to count. Nothing now rests on that sentence: M1, M2 and every corpus run above
  were re-taken on the shipped tree, so there is no cross-revision byte-identity argument left in
  this PR.)
• Files held by PR fix(#803): make "no exits" and "could not read the exits" different types #821 (water_grid.rs, collision.rs, observe.rs, …) are untouched. The
  whole change is tests/walker_sim.rs, using WaterRollup's existing public API only.
• No live client run. This is a test-structure change; nothing was launched and no live
  validation is claimed.

What round 2 changed, and which claims were retracted

• Retracted (B1): "unmeasured/skipped … is a question about the whole denominator — not
  answerable at zone 3 of 11." Measured false by the reviewer: the buckets are push-only, so every
  bucket is decided the instant a zone closes and is_complete() is monotone. The gate now covers
  unmeasured, and skipped's exemption is restated as the diagnostics trade it always was.
• Retracted (B2): "the only zone whose accounting depends on reaching this line is the LAST one
  opened." Only unaccounted was per-zone at the time; unmeasured and skipped were not.
• Retracted (this round, self-caught by RED-A): "unmeasured — the zone was walked and its
  .wtr did not load." The water arm closes the zone with add(…) and continues before any
  journey is sampled — RED-A prints a row of dashes and the whole run took 0.48 s. The rustdoc, the
  panic text and the should_panic substring now say "the water check ran and the .wtr did not
  load, so the zone was abandoned unwalked".
• Added (N1): zone_accounting_covers_the_423_rollup_not_just_wat_route, a divergent-rollup RED
  test — the round-1 tests drove both rollups identically, so the #423 arm and its {label}
  interpolation were unpinned.
• Dropped (N2): zone_accounting_does_not_cover_the_zone_that_is_still_open had no unique kill
  and duplicated crates/eqoxide-nav/src/water_grid.rs's own coverage of that property. The limit it
  described is still stated in open_zone_checked's rustdoc.
• Added (N4): the [ABORTED …] partial rollup line, printed before the panic, so an aborted run
  still shows what it did establish — labelled PARTIAL so it cannot be read as a score.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HQVEpaaKeXsZcW9VT2roeV

[djhenry]

CHANGES REQUESTED

Independent adversarial review of #824 at 12019df, measured on the PR branch merged with main @ 41cca4e (merge commit built locally; git merge clean, no conflicts). I did not write this PR.

The code is sound — the per-zone unaccounted gate does what it says, it fires at the real call site, and it adds no false positive. Every blocking finding below is a claim in a tracked file that the code does not support. Two of them are the same false mechanism claim written twice, and it is the claim that carries the decision to leave two thirds of #762's refusal terminal.

---

Blocking

B1 — "not answerable at zone 3 of 11" is false, and it is the load-bearing justification for the scope split

tests/walker_sim.rs:853-855 (open_zone_checked rustdoc):

unmeasured and skipped are asset-coverage holes, and whether the corpus HAS a hole is a statement about the whole denominator — not answerable at zone 3 of 11.

Restated at tests/walker_sim.rs:821-822 (terminal-assert comment) and carried into the PR body as the reason only unaccounted moves.

Measured false. I added a probe test to the shipped tree (added, run, removed; md5sum -c clean):

test probe_unmeasured_and_skipped_are_decidable_per_zone_and_monotone ... ok
test result: ok. 11 passed; 0 failed; 5 ignored; 0 measured; 0 filtered out

It establishes three things by execution, not by reading:

1. unmeasured is decided the instant a zone closes. u.add("halas", &ZoneWater::load(<nonexistent dir>, "halas").tally()) → u.unmeasured_zones() == ["halas"] and !u.is_complete() at zone 1, with ten zones still to come.
2. is_complete() is monotone. unmeasured/skipped are Vecs that are only ever pushed to (water_grid.rs:472-476, :489-492), and is_complete ANDs "all three empty" (water_grid.rs:531-535). I drove three further measured zones after the hole and is_complete() never recovered. So a per-zone refusal on those buckets cannot fire on a run where the terminal one would not — there is no soundness argument against it at all.
3. The PR's only empirical justification — "akanon is skipped for no routable pairs at zone 1 of 2" — is a fact about skipped. In the same probe, akanon's skip leaves unmeasured_zones() empty. The measurement offered does not touch the unmeasured bucket it is used to exempt.

What is true is the sentence immediately after: checking those per zone "would abort the run on the first missing .glb instead of printing the table and reconciling at the end". That is a diagnostics trade-off, and it is a defensible one. Please make it the stated reason and delete the decidability claim from both locations. As written the doc tells a future reader that a per-zone unmeasured check is impossible, when it is merely less informative.

B2 — "the only zone whose accounting depends on reaching this line is the LAST one opened"

tests/walker_sim.rs:819-820. False as written: every zone's unmeasured and skipped accounting still depends on reaching that line. Only the unaccounted third is per-zone. The following sentence partially repairs it, but the sentence a reader will quote is this one. Suggest: "…the only zone whose unaccounted accounting depends on reaching this line is the LAST one opened."

B3 — Closes #805 overclaims relative to #805's own scenario

#805's opening exhibit is #762's motivating defect: "a build host holding 2 of 497 .wtr files once made every water-inclusive halas/blackburrow run print 0/0". That is the unmeasured bucket, on the blackburrow run — the exact zone #763 says hangs. After this PR, that refusal is still terminal and still not reached on that run. What #824 closes is the unaccounted bucket, which is a corpus wiring bug and is not the scenario #805 exhibits.

Given B1, the exemption is a diagnostics preference, not a decidability wall — so this is a real, remaining hole, not a closed one. Either:

• extend the per-zone gate to unmeasured (monotone, sound, costs the rest of the table on a partial $ZONE_DIR), or
• keep the scope and change Closes #805 to Refs #805, filing the residue, with the tracked doc saying plainly which third of A missing .wtr makes a zone silently score as 'no water' — every water metric reads 0 by construction #762's refusal a non-terminating run still skips.

I have no objection to the second option. I do object to the current combination: Closes, plus a false reason for not closing the rest.

---

Mutations I ran (all on the shipped tree; file restored from a byte-identical copy between runs, md5sum -c OK, git status --porcelain empty at the end)

#	Mutation	Result
M_A	Author's M1, reproduced. Reach-control call site (walker_sim.rs:899) open_zone_checked(&mut wr, &mut r423, zone); → wr.begin_zone(zone); r423.begin_zone(zone);	RED — zone_accounting_fires_before_the_corpus_loop_ends FAILED, 9 passed; 1 failed
M_B	Author's M2, re-run on the shipped tree (they ran it one revision back). if false { assert!(orphans.is_empty(), …) }	RED — same test, 9 passed; 1 failed
M_C	Invented. #[cfg(any())] on the gate's assert	RED — same test
M_D	Invented. Delete the gate's assert outright	RED — same test. But zone_accounting_does_not_cover_the_zone_that_is_still_open and zone_accounting_stays_silent_while_every_zone_is_closed both stayed ok
M_E	Invented. Gate checks one rollup only: for (label, roll) in [("wat-route", &*wr)]	SURVIVED — 10 passed; 0 failed. See N1
M_F	Invented. Move the check after begin_zone instead of before	RED — ..._does_not_cover_the_zone_that_is_still_open and ..._stays_silent_while_every_zone_is_closed both FAILED
M_G	Invented, the important one. Revert the real corpus call site (walker_sim.rs:604) to the pre-#805 roll_wr.begin_zone(zone); roll_423.begin_zone(zone); — full workspace	SURVIVED — 55 = 55 headers/results, 1814 passed; 0 failed; 47 ignored; 0 filtered, byte-identical totals to the unmutated run. See N3

M_B confirms the author's M2 transfers to the shipped tree, so the untested-revision caveat in the PR body is now discharged. I also verified the byte-identity claim itself against the branch reflog: the M2 revision differs from 12019df by exactly one reworded rustdoc paragraph and the added rename-guard test; open_zone_checked's body and all four call sites are byte-identical. (The PR body says "both call sites" — there are four.)

---

Non-blocking

N1 — half the gate is unpinned (M_E). Deleting the #423 arm from the gate's rollup array leaves the whole suite green. The two rollups are driven in lockstep everywhere, so no existing test can distinguish them, and the {label} interpolation is unexercised. One cheap RED-direction test fixes it: close wr but not r423 for zone 1, open zone 2, and should_panic on a message containing #423.

N2 — zone_accounting_does_not_cover_the_zone_that_is_still_open does not test the gate. Under M_D (assert deleted) it stays green: its two asserts are statements about WaterRollup, and near-identical ones already exist at crates/eqoxide-nav/src/water_grid.rs:866-875 (only_unaccounted: same begin_zone-and-abandon, same unaccounted_zones(), same !is_complete()). Its doc says "If a future change makes the gate cover the open zone too, this test goes RED" — I could not construct a coverage-extending change that makes it red (a close_zone_checked at the end of the body, or a check after the loop, both leave it green); it goes red only under a Drop-guard design. It did earn one kill (M_F, the order swap) — but so did zone_accounting_stays_silent_while_every_zone_is_closed, so it has no unique kill among the seven mutations here. Either give it a unique kill or downgrade its doc from "pinned rather than described" to what it is.

N3 — the fix itself is unreached in CI (M_G). The PR discloses this ("the gate's call site inside the real corpus is exercised only when a human runs the corpus by hand"), and the disclosure is accurate: .github/workflows/test.yml:148 runs cargo test --workspace --locked with no --ignored, and faithful_walker_drift_corpus is #[ignore]d at tests/walker_sim.rs:313. M_G measures the consequence: the entire behavioural change can be reverted and nothing goes red. The reach control covers the helper, not the fix — which is the #799 shape the PR is fixing elsewhere. I am not asking for the owner-gated #[ignore]-in-CI decision (#777/#654/#659) here. A cheap partial pin exists though: a non-ignored test that runs the corpus against an empty $ZONE_DIR with a two-zone ZONES list would drive the real loop through open_zone_checked and land on assert!(tot_walked > 0, "no journeys walked — check $ZONE_DIR") under should_panic. That pins reach of the loop, not gate behaviour — worth stating either way.

N4 — diagnostics cost, undisclosed in the tracked doc. The gate aborts mid-loop, so a wiring bug now loses the table's remaining rows and the === FAITHFUL WALKER DRIFT total line, and names only the first unaccounted zone instead of all of them. The PR body's M3 output shows exactly this and frames it as evidence; it is also a cost, and open_zone_checked's "What this does NOT buy" paragraph is the right place for it.

---

Figures — PR branch merged with 41cca4e, stdout/stderr captured separately

cargo test --workspace --locked --no-fail-fast, exit code captured explicitly (EXIT=0), judged by log content.

1. Finished \test` profile [unoptimized + debuginfo] target(s) in 3m 03s— the **compile** sentinel, present on stderr; the run was judged complete by process exit plus 55 completetest result:` lines.
2. 55 ^running [0-9]+ tests?$ headers vs 55 ^test result: lines — equal, no lost binary. (Regex admits the singular running 1 test.)
3. 0 non-canonical result lines.
4. 14 truly-empty targets, field-anchored on ^test result: ok\. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out.
5. 1814 passed + 0 failed + 47 ignored + 0 filtered = 1861, and the header sum is 1861. Equal.

Reconciliation against the 41cca4e baseline (55 = 55, 0 non-canonical, 14 truly-empty, 1810 + 0 + 47 + 0 = 1857): +4 passed, +4 total, target count unchanged, exactly the four tests this PR adds, all confirmed present and ok by name — doc_comment_citations_in_this_file_are_rename_guarded, zone_accounting_does_not_cover_the_zone_that_is_still_open, zone_accounting_fires_before_the_corpus_loop_ends - should panic, zone_accounting_stays_silent_while_every_zone_is_closed.

scripts/check-no-local-detail.sh → OK — no forbidden patterns in tracked files.

Claims I checked and found TRUE

• CI runs no --ignored (.github/workflows/test.yml:148) and the corpus is #[ignore]d (tests/walker_sim.rs:313).
• The total line prints after the zone loop (tests/walker_sim.rs:795-798, after the loop closes at :793) — the statement-order claim in open_zone_checked's doc holds.
• The gate reads unaccounted_zones() before begin_zone, so the still-open previous zone is caught via chain(self.open) (water_grid.rs:509-513) and the zone being opened is not falsely flagged. M_F shows the ordering is pinned.
• No false positive: the gate is silent whenever every zone is closed, and unaccounted is monotone, so it never fires where the terminal assert would not.
• M2's "byte-identical" caveat, verified against the reflog, and re-run here as M_B.

NOT verified

• Anything about a real hang. I did not run blackburrow and did not run the corpus at all — no baked GLBs used, no $ZONE_DIR, no live client. The author's M3/M3b/GREEN runs against real assets are unreproduced by me; I neither confirm nor dispute their numbers.
• The author's origin/main baseline (1798 + 0 + 47 + 0 = 1845) — that is against their older base; I measured against 41cca4e instead and the delta reconciles.
• Whether the diagnostics trade-off in B1 is the right call. I am asking for the reason to be corrected, not for the decision to be reversed.
• The four *_blast_radius corpora and water_grid_budget_measurement, which WaterRollup's own type doc says are not covered by any of this. Out of scope here, unexamined.
• crates/eqoxide-nav/src/water_grid.rs is untouched by this PR (confirmed: the diff is tests/walker_sim.rs only, 147 insertions), so no interaction with fix(#803): make "no exits" and "could not read the exits" different types #821 was assessed beyond that.

[djhenry]

Round 2 — commit → finding

Branch merged with origin/main 41cca4e (merge commit 15ba96c; merged rather than rebased
because force-push is blocked here). Two commits since your review, plus a full PR-body rewrite.

Finding	Commit	What changed
B1 — decidability claim measured false	1453e1c	The sentence is deleted, not softened. open_zone_checked's rustdoc now says all three buckets are decidable at close and monotone (push-only Vecs), that a per-zone refusal could never fire where the terminal one would not, and that an earlier revision claimed the opposite and was measured false. skipped's exemption is restated as a diagnostics trade with the akanon measurement attached to the bucket it actually bears on.
B2 — "the only zone … is the LAST one opened"	1453e1c	Rewritten. The terminal assert's preamble now says exactly what it still owns: skipped for every zone, plus the zone still open (nothing closes it, no later begin_zone observes it).
B3 — Closes #805 overclaims	1453e1c	Extended the gate to unmeasured rather than downgrading. Reasoning in the body under "Why this still says Closes #805". unmeasured is #762's exhibit, it is decided at close, and RED-A below shows the refusal firing at the real call site mid-loop. skipped stays terminal-only for the diagnostics reason, named explicitly — if you judge that leaves #805 open, Refs is a one-word change and I will not argue it.
N4 — nothing printed on abort	1453e1c	The gate prints a === FAITHFUL WALKER DRIFT [ABORTED while opening {zone}] — PARTIAL rollups; … this is not a corpus score … line before panicking, since the corpus's own total line runs after the loop. Labelled PARTIAL because the zones after the offending one were never opened.
M_G survived — reach control covers the helper, not the fix	1453e1c (text)	Not papered over. open_zone_checked's rustdoc has a dedicated bullet: delete the call from the corpus loop, restore the bare begin_zone pair, and the whole workspace suite stays byte-identically green, because the corpus is #[ignore]d and .github/workflows/test.yml runs cargo test --workspace --locked with no --ignored. I re-measured this myself on the shipped tree rather than taking your word: identical five figures and a diff -q-identical sorted set of 1819 test … ok|ignored lines. Same statement is in the body's "NOT verified" section as a reach limit, attributed to #799.
M_E / N1 — #423 arm unpinned	1453e1c	Added zone_accounting_covers_the_423_rollup_not_just_wat_route: closes wat-route's zone and deliberately leaves #423's open, so the two rollups diverge and only the #423 arm can fire. should_panic(expected = "the #423 rollup already holds a hole") pins the {label} interpolation.
N2 — no unique kill	1453e1c	Dropped. It duplicated crates/eqoxide-nav/src/water_grid.rs:866-875 and survived assert deletion. The limit it described is still stated in open_zone_checked's rustdoc, where it is a documented boundary rather than a test that certifies nothing.
"both call sites" → four	body rewrite	Corrected, and the sentence no longer load-bearing: there are seven lexical call sites on this tree (one in the corpus loop, six across the four gate tests), and M1/M2 plus every corpus run were re-taken on the shipped tree, so no cross-revision byte-identity argument remains in the PR.

One thing you did not find, that I found while substantiating B3

3667927 is a self-caught retraction. Round 2 shipped the unmeasured extension describing that
bucket as "the zone was walked and its .wtr did not load" — in the rustdoc, in the panic text and
in the should_panic substring. Running RED-A against real assets falsified it: the water arm calls
ZoneWater::install, and on failure closes the zone with add(zone, &zw.tally()) and continues
before a single journey is sampled. The run printed

crushbone         -       -        -        -      - unmeasured unmeasured   (unmeasured: no .wtr file for this zone)

and finished in 0.48 s — zero journeys. The wording now reads "the water check ran and the
.wtr did not load, so the zone was abandoned unwalked with no number". Same defect class you
flagged in B1/B2: a mechanism sentence that was reasoned rather than measured.

Measurements, all on the shipped head 3667927

• Workspace GREEN: 55 headers = 55 result lines, 0 non-canonical, 14 all-zero (field-anchored),
  1815 + 0 + 47 + 0 = 1862 = header total. Baseline 41cca4e = 1857, so +5, reconciled by
  name: the four gate tests plus doc_comment_citations_in_this_file_are_rename_guarded. Your 1861
  was my previous head, which had four of the five (N1's test had not been added and N2's had not
  been dropped).
• M1 (call site killed inside the reach-control test): RED, panic did not contain expected string.
• M2 (if true { continue; } — the whole refusal present in source, never reached): three of the
  four gate tests RED; the no-false-positive control stays green, which is the right direction.
• RED-A (real corpus, crushbone.wtr moved aside, ZONES=crushbone,felwithea): gate fires while
  opening felwithea, naming unmeasured … ["crushbone"], [ABORTED …] line first, 0.48 s.
• RED-B (same assets, gate removed from the real call site): the whole loop ran — felwithea's 60
  journeys included, 49 s — and the hole was reported only by the terminal assert. That is the
  pre-#762's completeness guard is the corpus's LAST statement, so blackburrow's non-termination (#763) skips it entirely #805 picture.
• GREEN (all .wtr present, ZONES=akanon,crushbone): no [ABORTED …] line, full table,
  terminal assert fires on skipped: ["akanon"] with unaccounted: [] and unmeasured: [],
  149.52 s. This is also the measurement the skipped exemption rests on.

Raw output for all six is in the PR body. scripts/check-no-local-detail.sh → OK.

[djhenry]

APPROVED — round 2, independent adversarial review of 3667927, measured on this branch merged with current origin/main (223ac9b), not on the base the author reconciled against.

Four findings below, all non-blocking; I would merge over every one of them. Round 1's blocking finding (the false decidability claim) is fixed, and I re-verified the retraction by execution rather than crediting it.

---

Baseline hazard — re-measured on the merge with 223ac9b

The author's figures reconcile against 41cca4e (1857), which is no longer main. I merged 3667927 with 223ac9b in a detached worktree (clean merge, tests/walker_sim.rs is the only file this PR touches) and re-ran the full workspace. Five figures, streams captured separately:

#	figure	value
1	compile sentinel	Finished `test` profile [unoptimized + debuginfo] target(s) in 36m 39s (cold builder), rbuild EXIT=0
2	targets	55 running [0-9]+ tests? headers = 55 test result: lines
3	non-canonical result lines	0
4	truly-empty targets (0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out)	14
5	totals	1828 passed + 0 failed + 47 ignored + 0 measured = 1875, equal to the header sum; 0 FAILED targets

223ac9b baseline is 1823 + 0 + 47 + 0 = 1870 across 55/55 ⇒ delta +5, reconciled by name against the five tests this PR adds. The dropped zone_accounting_does_not_cover_the_zone_that_is_still_open is absent (grep count 0). No cross-PR semantic conflict with #821: green on the merge, not only on the PR's own base.

---

Mutations run (all at the CALL SITE unless stated; every revert md5sum-verified)

#	mutation	result	killed by
R1	hard-code {label} → "wat-route" in the panic	RED	zone_accounting_covers_the_423_rollup_not_just_wat_route, with note: panic did not contain expected string — the right reason
R2	drop the ("#423", &*r423) arm from the loop	RED	..._covers_the_423_rollup_not_just_wat_route only
R3	gate ignores unmeasured (if orphans.is_empty() { continue; })	RED	zone_accounting_refuses_an_unmeasured_zone_before_the_corpus_ends only
R4	gate ignores unaccounted (if unmeasured.is_empty() { continue; })	RED	..._fires_before_the_corpus_loop_ends + ..._covers_the_423...; ..._refuses_an_unmeasured... stayed green — clean bucket discrimination
R5	if true { continue; } at the top of the rollup loop (repro of the author's M2)	RED	the three gate tests; ..._stays_silent_while_every_zone_is_closed green — matches the author's report
R6	delete the open_zone_checked(…) call from the reach-control test (repro of M1)	RED	..._fires_before_the_corpus_loop_ends only
R7	delete the [ABORTED …] println! entirely	SURVIVED — test result: ok. 11 passed; 0 failed; 5 ignored	(finding 2)
R8	if false { continue; } — refuse unconditionally (false-positive control)	RED	..._stays_silent_while_every_zone_is_closed fires, plus ..._covers_the_423... on the label mismatch
R9	delete the real corpus call site at tests/walker_sim.rs:608, restore the bare begin_zone pair — full workspace	SURVIVED	nothing (confirms the #799 bullet)

R9 / M_G spot-check (the self-measured control). Independently reproduced: 1828 + 0 + 47 + 0 = 1875 across 55/55 targets, 0 FAILED — figure-for-figure identical to the unmutated merge — and the sorted set of test … ok|ignored lines is diff -q-identical at 1875 lines. The author's control holds. (My line count differs from their 1819 only because my base is 223ac9b.)

M2 is a body mutation, not a call-site one — and that is fine here, but only because M1 exists. if true { continue; } sits inside open_zone_checked's loop; it cannot by itself distinguish "the gate is dead" from "the predicate is false". It is admissible in this PR because (a) the tests that kill it are should_panic tests whose kill signal is reaching a post-loop UNREACHED panic — a reach signal, not a predicate signal — and (b) a genuine call-site mutation is measured separately (author's M1; my R6, RED). M2 alone would not have been sufficient evidence; the pair is.

---

The round-2 retraction — verified independently, not credited

The corrected wording ("the water check ran and the .wtr did not load, so the zone was abandoned unwalked with no number") is true, and I checked it against the code rather than against the correction's own reasoning:

• install() returns Err exactly when the ZoneWater is Unmeasured — so the only path into the unmeasured bucket is the install-error arm at tests/walker_sim.rs:630-634, which adds zw.tally() and continues before any journey pair is sampled.
• The only other add is at :795-796, reachable only after install returned Ok, i.e. with a Measured zw — which can never land in unmeasured.

So there is no second path that could make "walked but unscored" true for some run. The surviving sentence in the correction block checks out.

---

Findings

1. NON-BLOCKING — the replacement "never" universal is false as written (tests/walker_sim.rs:871-872)

"…so a per-zone refusal on any of them could never fire where the terminal one would not"

Counterexample, by satisfying the premise (monotonicity, close-decidability — both of which I confirmed) and breaking the conclusion: assert!(tot_walked > 0, "no journeys walked — check $ZONE_DIR") at :810 runs BEFORE the completeness assert at :828. On a run where every zone lands in unmeasured (the install arm walks nothing — the very fact the retraction above establishes), tot_walked == 0, so without the gate the run dies at :810 and the terminal completeness refusal is never reached — while the per-zone gate does fire. The same holds for an all-skipped run. This is not exotic: it is exactly the "build host holding 2 of 497 .wtr files" shape the doc cites two paragraphs earlier, taken to a $ZONE_DIR where none load.

The property the sentence is reaching for is true and I verified it: the hole Vecs are push-only (no clear/retain/pop/remove in water_grid.rs), so whenever the gate fires the run was going to fail anyway — at :810 or at :828. No new false positives. Suggested wording: "could never fire on a run that would otherwise have passed". This paragraph has now carried a wrong universal in two consecutive revisions, which is why I am naming it rather than waving it through — but it is a wording defect over a sound property, and I would merge over it.

2. NON-BLOCKING — the honesty framing on the abort path is pinned by nothing (tests/walker_sim.rs:913-916)

R7 deleted the entire [ABORTED …] — PARTIAL rollups … this is not a corpus score println! and the target stayed 11 passed / 0 failed. By entailment, any weaker edit survives too — including the dangerous direction, dropping the "PARTIAL"/"not a corpus score" framing while keeping the numbers. The three should_panic expected strings pin only bucket-name fragments ("unaccounted (left the loop body…", "the #423 rollup already holds a hole", "unmeasured (the water check ran…"); nothing pins "not a corpus score" in either the println! or the panic. Given that #799's whole lesson is written ≠ reached, an unpinned honesty surface is worth a follow-up contains assertion in one of the existing should_panic tests. Not blocking: the text is correct today, and R7's direction makes the output less informative, not dishonest.

3. NON-BLOCKING (theoretical) — WaterRollup's complete form carries no INCOMPLETE marker

The gate fires when either rollup is dirty and prints both. Display's complete branch renders "{total} (over {m}/{k} zones)" with no marker, so a reader slicing just the wat-route: … fragment out of the ABORTED line could see a clean-looking number inside a partial report. This cannot arise in the corpus — every add/skip is paired across both rollups (:617, :623, :633-634, :730, :795-796), so they move in lockstep — but ..._covers_the_423_rollup_not_just_wat_route proves divergence is representable in the type. Recorded, not asked for.

4. NON-BLOCKING — undisclosed asymmetry in the skipped exemption rationale (:874)

skipped is exempted because it is "the COMMON state of a partial $ZONE_DIR". True — but by the doc's own #762 exhibit (2 of 497 .wtr files), unmeasured is equally common on a dev box, and that bucket is gated. The trade is defensible (the skipped table row is printed per zone and a skip costs a zone that was never going to be scored anyway), but the doc states the cost asymmetrically. A clause would fix it.

---

The two judgement calls you asked me to make

Closes #805 — justified. #805's success criterion is that "an abandoned run cannot leave a clean-looking rollup behind". After this PR, on an abandoned run no rollup is published at all: the only publication points are the total line at :799 and the terminal assert at :828, both after the loop, plus the new ABORTED line which is explicitly labelled not-a-score. The residue (skipped, and the zone still open when the run stops) is a coverage gap, not a publication gap — and both are named in two tracked places (:826-827 and the fn's doc). #805's headline harm — a silent zero-water score from unmeasured — is closed. A corpus that can still hold a terminal-only skipped therefore still satisfies the issue as written; #805's "Shape of a fix" explicitly leaves scope to the fixer.

The ABORTED line is honest enough about being partial. Captured live from R1's failing run:

=== FAITHFUL WALKER DRIFT [ABORTED while opening zone_b] — PARTIAL rollups; the zones after
zone_b were never opened, so this is not a corpus score: wat-route: 0 over 0/1 zones —
INCOMPLETE, 1 skipped [zone_a (no glb)], #423: 0 over 0/1 zones — INCOMPLETE, 1 unaccounted
[zone_a] (opened by begin_zone, never reached add/skip) ===

It puts ABORTED while opening {zone} in the slot where the run mode normally goes, says PARTIAL, says "this is not a corpus score", names where it died and that later zones were never opened, and each rollup's own Display independently prints INCOMPLETE with its hole named. A reader cannot mistake this for the === FAITHFUL WALKER DRIFT [mode]: N full journeys walked … score line at :799. Subject only to findings 2 and 3.

---

What I did NOT verify

• The two live corpus runs the doc cites — ZONES=crushbone,felwithea printing the all-dashes crushbone row in 0.53s, and ZONES=akanon,crushbone skipping akanon at zone 1 of 2. I have no baked zone GLBs; those figures remain the author's own measurement, uncorroborated. (Note the first implies a run that also trips :810, consistent with finding 1.)
• That the corpus actually hangs on blackburrow (faithful_walker_drift_corpus never terminates on blackburrow — the wat-route:12 baseline is now unreplaceable #763). No blackburrow run was executed by me, and the doc says none was executed by the author either.
• Real GitHub-runner behaviour. I checked the merged tree by reading: .github/workflows/test.yml:148 is cargo test --workspace --locked, and --ignored appears 0 times in .github/workflows/*.yml.
• Runtime cost of the gate (it is two Vec::is_empty() checks per zone; not measured).
• fix(#803): make "no exits" and "could not read the exits" different types #821's own content — I merged it and measured the result green; I did not review it.
• scripts/check-no-local-detail.sh passes on the merged tree (that I did run: OK).