fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict

[djhenry]

Closes #766. Sibling of #765 (#732), and it follows that PR's discipline rather than inventing a parallel one.

Round 7 (doc/comment-only, and short). Round 6 was REQUEST CHANGES on two findings, both again in prose this PR wrote, and the reviewer re-verified the code has not moved. B14: my 12-term sweep did not contain permanent*, and that one missing term yields four survivors — three of them on lines round 6 added, one of them in the agent-facing doc, contradicting a sentence 27 lines above it. So "24 found, 24 fixed" was not a completeness claim I was entitled to make, and it is retracted below. The method is changed, not the list. B15: two unbalanced doc spans, in the one touched file no guard reaches. N1 is filed as #787 and referenced from the four sentences that depend on it.

Round 6 (doc/comment-only, and it is round 5's mess). Round 5 was REQUEST CHANGES with the code confirmed right — the reviewer tried to break it and could not. Both blocking findings were introduced by round 5 itself, in the paragraphs it wrote to fix round 4's false claim. B12: the field's own doc comment now contradicted itself, its lead still saying SESSION-scoped and never cleared while its tail said Walker::new clears it — the most-read rendering of the field left as the wrong one. B13: "so it can never outlive the thread it is reporting on" is false, and its causal so was unearned. Details below, including the sweep that found 24 lines carrying the old story where my own enumeration would have named 3.

Round 5 (a CODE round, not a doc round). Round 4 was REQUEST CHANGES on one blocking finding and two cheap ones. The blocking one, B9, is the uncomfortable kind: a doc-accuracy round added a false claim to a tracked file, and that claim was the sole stated basis for declining a real fix. It is fixed as a behaviour change — Walker::new now clears the latch — plus a mutation-checked test. B10 and B11 are a hedge and a reconciliation, both in the same family. Details below.

Round 4 (doc/comment-only). Round 3 was REQUEST CHANGES on three findings, none of which touched the fix: a new top-level field that could not be found from the endpoint's own field index (B6), a false completeness claim inside prose that had already been wrong once (B7), and four stale line locators in my mutation evidence (B8). The code is byte-identical to round 3; the round-3 workspace figures below therefore still stand and I did not re-run the workspace, on the reviewer's own statement that a fourth run is not warranted for a delta of this kind.

Round 3. Round 2 was REQUEST CHANGES on three findings. One of them (B3) was not a wording defect — it was a real agent-honesty hole this PR had opened, so it is fixed as a behaviour change, not a hedge. The other two (B4, B5) were a false claim about verification tiers and a hole in my own mutation evidence. Round 1's retraction is still recorded at the bottom, because the sentence it retracts is in this branch's commit history and cannot be removed without a force-push.

What was wrong

Walker::reset_for_zone_change did not clear NavStatus.local. Between the reset and the next walker tick that reached resolve_goal with no goal, a reader of GET /v1/observe/debug could get:

"nav_state": "idle", "nav_reason": "zoned",
"nav_local": {"state": "no_way_through", "reason": "search_closed", "stuck_ticks": 7, "plan_us": 1234}

Each half is true; the pair is false. The fine tier's verdict is about threading a corridor in the zone we have left, computed against a collision grid that no longer exists. Same defect class as #732 — a per-zone fact published as current.

Enumeration: which routes actually leaked

Six documented routes reach idle. Two left local standing:

route	reached via	pre-#766
zoned	Walker::reset_for_zone_change	leaked — #766's report
zone_cross_dropped_unhandled	ZoneCrossTicket::drop	leaked
goal_dropped	Walker::resolve_goal (no-goto branch)	cleared, by clear_local_plan() on the same tick
respawned	same branch	cleared, same way
stopped	CommandState::stamp_new_goal	cleared, by an explicit s.local = None;
goto_superseded	same	cleared, same line

Both "already cleared" mechanisms are run, not read off the source: the_goal_dropped_route_already_cleared_the_fine_verdict_before_766 (eqoxide-nav) and every_command_side_retirement_retires_the_fine_tiers_verdict_766 (eqoxide-command). respawned is covered by reading that it shares goal_dropped's branch, not by its own test. The zone_cross_dropped_unhandled leak is not in the issue — I found it while enumerating, and it is the second thing this PR fixes.

The fix

Verification hierarchy step 1 — make the bad state unrepresentable, in the same place #765 did. NavStatus::retire_to_idle now retires local along with goal / blocked_goal / blocked_frontier / tier. Its destructure has no .., so the E0027 net that #732 installed now covers this field too, and both leaking routes are fixed by the same line. The explicit s.local = None; in stamp_new_goal is deleted: one owner, not two writers plus a comment explaining the overlap.

And the writer-level half (round-1 finding B2). retire_to_idle alone only makes the invariant true at the transition. docs/http-api.md states it as a universal over the whole idle row, and the two writers race: local is published from the net thread while POST /v1/move/stop retires the row from the HTTP thread, each taking the nav_state lock separately — so a verdict computed while the goal was live can land after it is gone, with no call site at fault. Walker::set_nav_local now drops a verdict aimed at a row that is already idle.

I took a coercion rather than the debug_assert! the review suggested, which is a deliberate deviation and here is the reason. The gap is a runtime interleaving, not a programming error, so there is no call site for an assert to catch; and debug_assert! is compiled out of --release, so it would leave the documented universal false in the shipped binary — which is the finding, not a lint. The coercion makes it true in every profile and is directly testable in the debug suite. The doc now names both writers, so the guarantee is checkable against the code rather than asserted.

This does not undo #382's ownership, which is the tension the issue flagged:

• retire_to_idle never goes near LocalPlanner, so the "second behavioural change on a different tier" the issue warned about is not in that path. This is not the same as saying the change is cosmetic — round-1 finding N3 is right that it is not. Walker::local_says_no_way_through reads this same field back as a steering input (walker.rs), so clearing it on idle also clears that input. That is correct rather than incidental: on an idle row there is no goal, so there is no corridor for the fine tier to hold an opinion about. Stating it as an effect rather than leaving it as a surprise.
• only the idle row is affected. Walker::stop_nav_blocked publishes blocked / no_path and never idle, so it does not come through here — the deliberate keep-the-fine-verdict-as-evidence-on-a-terminal-failure design is intact. That distinction is now written down in docs/http-api.md, and as of round 3 it has a test (see B5 below); it did not have one anywhere in the tree before.

Known limit (round-1 finding N1), taken as a limit rather than fixed. That second bullet is true by convention, not by construction: stop_nav_blocked's state is a &str, and nothing stops a future caller passing "idle" and routing a terminal blocked through the retirement after all. I checked every call site in the tree (seven, plus the stop_nav wrapper that forwards its own parameter) and each passes a literal blocked / no_path / search_exhausted, so the design holds today.

Round-2 finding B4 — I had called the remedy for that limit a debug_assert!, and said it "would make it structural". That was wrong, and my own B2 paragraph two above is the counter-argument. A debug_assert! compiles out of --release; it is a tier-3 check that catches a caller in the debug suite, not a tier-1 construction that makes the state unwritable. The structural remedy is a typed state — an enum whose idle variant stop_nav_blocked cannot name — and that is a workspace-wide change well outside this issue. The sentence is corrected in retire_to_idle's doc comment; the limit is still recorded there, now with the honest remedy and the honest reason for not taking it here.

Round-2 finding B3 — a dead fine planner is a WORKER fault, and this PR was about to hide it

This section said SESSION fault through rounds 2–5, and so did the source. Round 5's own fix made that wrong — see B12 below — so the scope word is corrected here too, in the historical section as well as the current one, rather than left for a reader to trip over. Nothing else about B3 changes: the fault still outlives the goal, which is the whole finding.

This is the finding that mattered. My round-2 body said of the coercion: "Nothing is lost by dropping it: it describes a goal that no longer exists." That is false for one of nav_local's three publishable states.

no_way_through and exhausted are verdicts about threading toward a goal, so retiring them with the goal is right. planner_dead is not. It is a latched, worker-scoped client fault (round-5 finding B12 corrected the scope word; through rounds 2–5 this read session-scoped): the fine worker thread has died, steering has permanently degraded to the coarse 8u route, and it does not come back without a client restart. It was riding in the per-goal field because that was the only place it had ever been published — the no_path/planner_dead pair on nav_state/nav_reason comes from the coarse planner, a different object.

So the consequence of #766 as written: docs/http-api.md asserted both "dead for the rest of the session" and "nav_local is null on every idle", and an agent between goals — which is exactly when it polls /v1/observe/debug to decide what to do next — could no longer see that its fine planner had died. That is the defect class #766 exists to close, not one it may create.

I fixed the behaviour, not the sentence. New field NavStatus.local_planner_dead: bool, published as a top-level nav_local_planner_dead on GET /v1/observe/debug, always present in both states — an agent checking its own health needs to be able to read "alive", not merely fail to read "dead". retire_to_idle keeps it (it is the field the E0027 net was built for), so it survives every route to idle.

Why a separate field and not a carve-out in retire_to_idle. A carve-out would re-open the clear-local-on-every-idle uniformity that #766 exists to create, and the reviewer objected to exactly that. A separate field does not: retire_to_idle still clears local unconditionally on all six routes, with no state-dependent branch anywhere. The worker fact simply stops riding in the per-goal row, which is the real defect — a per-goal channel was carrying a fact that outlives the goal.

Where the latch sits. At the point of discovery — inside drive_walk's have_path block, beside the existing per-goal planner_dead publication — with the shared row carrying it forward from there. An earlier, uncommitted draft of mine put it higher in the tick, on the theory that "unconditional" beat "inside have_path", and — as I recall it — my own test went RED.

Round-4 finding B11 asked me to reconcile this paragraph with what the source says, and the honest reconciliation is to stop asserting the draft. Round 4 established that the draft exists in no commit, no ref and no reflog entry, so nobody — me included — can reproduce it, and rounds 3 and 4 between them produced three competing accounts of why it failed. The reviewer withdrew its own (an inference about a tree it never saw); I am not re-asserting mine as history either. The argument below does not need it. Two things are checkable on the tree as it stands, and they are independent:

• Ordering, and it is decisive. LocalPlanner.dead is written at exactly two places — the failed send in post_if_idle and the disconnected receive in poll. Both are called only from inside have_path, both sit above the is_dead() check on the same tick, and cancel() cannot set it. So anywhere earlier in the tick, is_dead() can only report a death some earlier tick already found: an earlier latch is one tick late by construction, and if the goal retires in that gap it never fires at all. That is the same between-goals hole B3 exists to close, moved one tick over.
• Reachability, additional. drive_walk returns early at five points above let have_path — not the three I first wrote (round-3 finding B7) — the zone-usability halt, the mid-tick collision-grid-vanished halt, a coarse reply apply_plan says terminated the goal, the COARSE planner.is_dead() stop, and awaiting_first_plan. An empty path takes that last one, which sits immediately above let have_path, so a latch placed after advance_cursor cannot fire in that fixture at all. And ActionLoop::tick never calls drive_walk once resolve_goal returns None, so there is no between-goals tick to hook either.

What changed with the latch is not when the fault is seen but how long it stays visible: for the rest of the session, instead of until the next goal ends.

Discoverable, not just documented (round-3 finding B6). A new top-level observable whose whole justification is "an agent can find it" has to be findable. It was not: docs/http-api.md's GET /v1/observe/debug row is the only place the tree enumerates that endpoint's top-level fields, and the new one was missing from it — the section existed but was reachable only by someone who already knew the name. The index row now lists nav_local_planner_dead and links both to The fine steering tier (which it never linked to) and to the new section. Worth recording how it was found: by grepping the concept, not the field name. A field-name grep looks complete and is exactly the trap that hid four sites on a sibling PR.

The honest limit, stated on the field, in docs/http-api.md and in the test. A worker that dies and is never posted to again is not detectable by any reader, this field included. What is guaranteed is that once the death has been seen it does not vanish.

Round-4 finding B9 — a doc round added a false claim, and the remedy was two lines

Round 4 added a non-blocking note to local_planner_dead's field doc, flagging a latent hazard I had noticed while checking the "session" claim: session means process today, and if anything ever built a second Walker over this same shared row — the shape an in-process relogin would take — a new, healthy LocalPlanner would inherit true, and the client would report a fault it had just repaired, permanently. That is #343's shape (a value outliving the thing it describes) and it is a lie in the honesty-critical direction. I flagged it and declined the fix, on the ground that "a clear on a route that cannot happen is untestable."

That sentence is false, and it was the sole stated basis for declining. The two claims it runs together are different: what the missing relogin route makes untestable is the end-to-end scenario. The clear is a separate thing, and it has an obvious home — Walker::new, the same constructor that calls LocalPlanner::spawn(). It takes caller-owned NavSlots, and the eqoxide-nav suite already calls it directly. So:

• Walker::new now clears local_planner_dead as it spawns the worker, tying the latch's lifetime to the worker's rather than to the row's.
• a_new_walker_does_not_inherit_a_previous_workers_death_766 constructs a Walker over a row that is already true and asserts it comes back false. No relogin route in sight, and none needed. Mutation-checked (M8).
• The untestability sentence is deleted, not reworded. The field doc now states the guarantee and names the test.

What I am not claiming. This is a no-op on today's single-Walker process: Walker::new runs once per process, through ActionLoop::new from run_login_flow, which returns when the gameplay phase ends. It is a structural guarantee about the flag's lifetime, not a behaviour change to any live path, and M8's blast radius — exactly one assertion — is the measure of that. docs/http-api.md says the same to an agent: over a running client the field is one-way, and what clears it is the construction of a new worker, which today happens only at startup.

I would rather this had not been found by review. It is the defect class this branch has spent four rounds on, arriving in the round whose entire purpose was to remove instances of it — which is the argument for the fix being structural rather than another paragraph.

Round-4 findings B10 and B11 — the same family, one hedge and one reconciliation

• B10. The B3 test's doc stated that uncommitted draft's internals as flat fact. They are recollection, and the draft is unreproducible, so the doc now says exactly that and points the reader at what is checkable on the present tree. This branch already had a convention for un-run claims (observe.rs: "I did not run it"); B10 uses it rather than inventing a second hedge. latch_local_planner_liveness's doc carries the same marker, and its argument is written to stand without the draft.
• B11. The PR body and the source told different stories about that same run. They now tell one story, above, and it is the hedged one. Leaving two contradictory narratives in a PR whose blocking finding is "a false claim in a tracked file" would have been poor form, and the reviewer was right to say so.

Round-6 finding B14 — the sweep's term list missed permanent*, and that is a finding about the method

Four survivors, and the reviewer is right that they are worse than a missed word:

• docs/http-api.md contradicted itself inside one section. Line 888: "recovering it needs a client restart." Line 915: "permanently degraded." A restart recovers it, so it is not permanent — and this is the surface where session-scoped was defended as accurate. Permanently is not session-scoped; it is strictly stronger, and false in exactly the way the section's own earlier sentence says.
• observe.rs was B12's shape at six lines' range, inside a comment block round 6 itself added: the block opens "the field's lifetime is the fine WORKER's, not the process" and six lines later says "permanently degraded".
• Two test docs asserted the same permanence as fact.
• Meanwhile three other uses of the word — the ones naming the lie a second worker would tell — are correct, and they stay. The PR was saying, in the same four files, both that the degradation is permanent and that "permanent" is what it would be lying about.

And round 6's own diff deleted this word from one walker assert message. So the concept was recognised that round, corrected in one of five factual uses, and left in four. That is the standard being failed, and it is mine.

All four now say what the tree actually guarantees, using the reviewer's suggested shape — a claim about writers, not about time: "degraded to the coarse 8 u route, and nothing on any nav route recovers it." That is checkable against retire_to_idle and Walker::new; "permanently" was not checkable against anything.

The method changed, not the list

Adding permanent* to a thirteen-term list would reproduce the method that just failed, so I did not do that. The failure mode is that the sweep was keyed on the predicate — the open-ended set of English phrasings for "this outlives the worker" — which cannot be enumerated and decays with every new author. Two measured failures of it on this PR: a field-name grep missed 21 of 24; a twelve-term predicate list missed 4 more.

Round 7 sweeps by SUBJECT, which is a closed set. Anchors are the field and its aliases as they actually occur in the tree — local_planner_dead, nav_local_planner_dead, LocalPlanner, fine planner, fine-planner, fine worker, fine tier, FINE 2u, planner_dead, coarse 8 ?u — over crates/, docs/ and src/. 224 anchor lines, expanded to a ±6-line window and filtered to prose: 1096 lines. The subject is enumerable and provable; the predicate is not. Whatever a future author calls the permanence, they will still have to name the thing.

Validated against a corpus I did not choose. The reviewer published the sixteen terms it used that I had not (permanent*, forever, irreversib*, sticky, until restart, for the life of, never heals, does not heal, unrecoverab*, once set, stays true, process-scoped, per-process, terminal state, for good, cannot be undone). Running those plus my original twelve over the whole tree gives 431 hits; 36 fall inside the subject window and 395 fall outside it. I read all 36. Every one is either about a different field (the COARSE planner's planner_dead, net_thread_dead, transport lifetime, the traversability design note) or is one of this round's four corrections. Zero survivors — and, more to the point, the control's vocabulary found nothing inside the subject that the subject sweep did not already contain. That is the reach control this method needs and the term list never had.

I am not restating a "found N, fixed N" figure. What I will claim is the method and its control, both of which are re-runnable from the commands in the round-7 comment.

Round-6 finding B15 — two unbalanced doc spans, and the guard does not reach the file

Measured against the true merge base daab1ef — diffing against main mixes in other PRs' observe.rs edits:

file	daab1ef	d56f069	now
crates/eqoxide-ipc/src/lib.rs	12	12	12
crates/eqoxide-nav/src/walker.rs	0	0	0
crates/eqoxide-http/src/observe.rs	4	6	4

The pair was one code span — `.filter(|l| l.state != "threaded")` — broken across a /// wrap, which cargo doc renders with the break inside the span and which #773 records as un-greppable. It is now on its own line, with a comment saying why so the next reflow does not undo it. The four that remain are pre-existing (observe.rs:1418/1419, 3820/3821) and out of this PR's scope; parity with the merge base is the acceptance criterion.

Reach proved by running the guard, not by reading it. unbalanced_doc_spans runs only over steering.rs's cited_in list — steering.rs, walker.rs, collision.rs, tests/walker_sim.rs — so observe.rs and ipc/lib.rs are outside it by construction. I copied steering.rs aside (md5 dac4b3b0…), added observe.rs to cited_in, ran the real guard, and got exactly four span hits at the two pre-existing pairs with the test RED; then restored by copy-back and re-verified the md5 identical. No git stash, no git checkout.

The gap is noted, not closed here. A doc-heavy PR across four crates is parity-checked in one of them, and this branch's largest doc rewrite (ipc/lib.rs) is unchecked by construction — its 12 odd-parity lines are all wrapped prose, so it happens to be clean, but nothing made that true. Widening the guard is not this PR's job; recording it as a decision rather than an accident is.

Round-5 finding B12 — the fix contradicted the field's own defining paragraph, and the remedy is a sweep, not a list

Round 5 changed the field's behaviour (Walker::new clears it) and added a paragraph saying so — to the tail of a doc comment whose lead still opened, in bold, "SESSION-scoped, latched … never cleared, because the thread never comes back." One comment, two lifetimes, and the one a reader meets first is the wrong one. Same shape as round 3's B7: the replacement prose was right and the surrounding prose was not updated to match it.

What I would have done, and why it would have failed. I would have fixed the three places I could name: the doc lead, the new B9 test's opening line ("local_planner_dead never clears once set" — the same claim, in the doc of the test that exists to prove it false), and the docs/http-api.md sentence. The reviewer asked instead for a grep of the concept. Terms: never clear / never cleared / never clears / does not come back / never comes back / client restart / session-scoped / SESSION fact / session fault / one-way / outliv / rest of the session, over crates/, docs/ and src/ — 101 matching lines, every one read.

It found 24 lines carrying the old story, not 3 — and, as B14 below establishes, it did not find all of them. Read that figure as what a twelve-term list caught, not as a count of what was there. They are in this round's diff as removals; the other 77 hits are about different fields (model_sync_dead, net_thread_dead, the COARSE planner_dead, position_provisional, the asset-sync observables, MoveIntent.wish_dir, and the one-way dependency note in collision.rs) and were checked one at a time and left alone. Eight of the 24 were assertion messages and test-doc headings — the renderings a developer actually reads when something goes red, and none of which a field-name grep of local_planner_dead would have surfaced, because they name the concept and not the field. This is the second time on this branch that grepping the concept beat grepping the name (the first was B6), and the first time it changed the finding rather than merely confirming it.

The rule I applied, stated so it is checkable rather than a taste call:

• Agent-facing surfaces (docs/http-api.md prose and headings, the nav_local.state glosses an agent reads in the JSON) keep session-scoped. From outside the process it is accurate: the client builds exactly one fine worker per process, so the worker's life and the session are the same span, and the section now says that in as many words instead of leaving the reader to reconcile it. The ### anchor is unchanged, so round 3's B6 index link still resolves.
• Client-internal surfaces (rustdoc, comments, test docs, assertion messages under crates/) say worker-scoped, because that is the rule the code enforces and a client developer is the one who can break it.
• Where a surface uses the session framing, it now says why the two coincide and points at the other surface. Both ends of that pointer exist: eqoxide-ipc's field doc names the agent-facing docs, observe.rs names docs/http-api.md, and docs/http-api.md says the internal latch is the worker's.

Statements about the consequence — "steering has degraded to the coarse 8 u route for the rest of the session", "recovering it needs a client restart" — are left standing. They are true of today's process, they are not claims about the field's lifetime, and they are exactly the sentences an agent needs. Recorded here as a decision rather than an oversight, since they are among the 101 hits and a reader re-running the sweep will land on them.

Round-5 finding B13 — "it can never outlive the thread it is reporting on" is false

Round 5 wrote that sentence into docs/http-api.md as the justification for the clear. It does not hold, and the reviewer's counter-example is on the tree: there is no Drop for Walker or for LocalPlanner anywhere in the workspace, and run_net_thread (src/model.rs) writes a terminal reason on all four of its exit arms — panic, Ok(Err(e)), and both Ok(Ok(())) arms. On every one of those the worker is gone while the row, which the HTTP surface holds its own Arc to, goes on publishing whatever it last held, false included. I verified both premises myself before writing the correction rather than taking them from the review.

That is #343's shape in the healthy direction — a value outliving the thing it describes, pointing at "alive" instead of "dead" — and it is the exact defect class this branch has spent six rounds on, written into the paragraph that was supposed to close it.

The reviewer stated the mitigation fairly and I am not overstating it either. It is a doc overreach, not a live lie: net_thread_dead is non-null on precisely those paths and /v1/observe/debug marks the whole payload a frozen final snapshot, so an agent that reads the endpoint as documented is told. The review explicitly did not ask for a teardown writer, and I did not add one — that would be a new, untested route to fix something an existing signal already reports. Three changes, all prose:

• The false sentence is gone, not narrowed. In its place, two claims that are separately true: "over a running client this field is one-way" — and one-way is a property of the process (nothing constructs a second fine worker), true before the clear existed and not caused by it, so the round-5 causal "so" is dropped; and "a false reading is only meaningful while net_thread_dead is null", with the reason and the check.
• local_planner_dead's field doc gains a closing paragraph that tells a client developer the opposite of what round 5 implied: do not read this as a flag that cannot outlive its thread, here is the case where it does, here is why no writer was added.
• The blockquote that survives states the clear's purpose without the false premise: if anything ever did build a second fine worker in-process, the new one would not inherit the old one's latch. On today's process it is a no-op.

"Your conclusion is right; the causal so is not earned" is the reviewer's summary, and it is the same failure this branch has now produced four times: a correct conclusion with a reasoned-not-measured mechanism attached. It is worth naming as a pattern rather than fixing as an instance, which is what the closing paragraph of the field doc is for.

Round-2 finding B5 — my mutation evidence had a hole, and the reviewer drove through it

The reviewer replaced my set_nav_local guard with the wrong predicate if s.reason.is_some() and the entire workspace stayed green. That is correct and it is my defect: my test's two directions were navigating+reason: None and idle+reason: Some, which vary two things at once, so any predicate separating those two rows passes both.

Added a third direction: a terminal blocked row carrying reason: local_no_way_through, asserting the verdict survives. That row is non-idle and carries a reason, so it is the one that tells a state-keyed guard apart from a reason-keyed one. It also pins #382's keep-the-verdict-as-evidence design, which the reviewer reports had no test anywhere in the tree despite being this field's most load-bearing documented behaviour on a non-idle row. Measured, not reasoned: see M5.

The local_planner cancel asymmetry — conclusion: an oversight, on git evidence

The issue asked me to decide this deliberately. I concluded it is an oversight and fixed it (one line), on this evidence:

• git show f2dce47^ — the zone reset already had self.planner.cancel() before The fine (2u) local plan still runs on the network thread every tick, under the 150ms budget — #377 only moved the coarse plan #382 introduced LocalPlanner at all. The coarse cancel is not a decision about the fine tier; it predates it.
• git show f2dce47 — The fine (2u) local plan still runs on the network thread every tick, under the 150ms budget — #377 only moved the coarse plan #382's own diff dropped the fine plan, directly or through clear_local_plan, at the sites it touched. The zone reset — which The fine (2u) local plan still runs on the network thread every tick, under the 150ms budget — #377 only moved the coarse plan #382 did not otherwise edit, and which already cleared local_path / local_i / local_stuck_ticks — was simply not revisited.
• No comment anywhere in the tree records a reason for the gap.

Scope: defence in depth, restoring #382's own pattern. It is not backed by a measured failure. No production route can reach a post_if_idle that the stale pending slot would refuse. I re-derived this myself rather than taking it from the review:

1. post_if_idle has exactly one production call site, in drive_walk.
2. It is inside if have_path {, where have_path = !self.path.is_empty().
3. self.path is made non-empty at exactly two sites — apply_plan's Route and Exhausted { progress } arms. Every other write to self.path in the file is a .clear().
4. Each of those two calls clear_local_plan(), hence local_planner.cancel(), within three lines.
5. And drive_walk's empty-path else arm calls clear_local_plan() too.

So a cancel always intervenes between the zone reset and any production post_if_idle.

Tests

Nine, in the four crates the field crosses. Eight are mutation-checked; the ninth is explicitly not, and says so.

test	crate	what it pins
a_zone_change_retires_the_fine_tiers_verdict_and_its_in_flight_plan_766	eqoxide-nav	the walker call directly + the LocalPlanner cancel
a_verdict_arriving_after_the_goal_is_retired_is_not_published_766	eqoxide-nav	the B2 writer-level guard, three directions (B5)
a_dead_fine_planner_stays_visible_after_the_goal_is_retired_766	eqoxide-nav	B3 — production drive_walk discovers the death, and it survives retirement
a_new_walker_does_not_inherit_a_previous_workers_death_766	eqoxide-nav	B9 — the latch is scoped to the WORKER: a fresh Walker over a dirty row starts clean
a_zone_change_retires_the_previous_zones_nav_local_766	eqoxide-net	the real production hook (sync_zone_points sees a new zone name)
debug_publishes_no_nav_local_once_the_goal_is_retired_to_idle_766	eqoxide-http	the JSON end of the path an agent actually reads
debug_keeps_publishing_a_dead_fine_planner_after_the_goal_is_retired_766	eqoxide-http	B3 at the JSON end: nav_local: null and nav_local_planner_dead: true in the same body
every_command_side_retirement_retires_the_fine_tiers_verdict_766	eqoxide-command	stopped / goto_superseded / zone_cross_dropped_unhandled
the_goal_dropped_route_already_cleared_the_fine_verdict_before_766	eqoxide-nav	a measurement of pre-existing behaviour (see below)

The zone-change test reads the row immediately after reset_for_zone_change returns, with no intervening tick — that is the property, since the pre-fix code did eventually clear the field on a later tick. Every test asserts a PREMISE that the planted verdict is really loaded first, so no post-condition can be satisfied by NavStatus::default(). The B2 test asserts the positive direction as its premise for the same reason: a set_nav_local gutted to a no-op would satisfy its negative half on its own. The fixture verdict is no_way_through throughout, deliberately: observe.rs filters threaded out, so an unhealthy verdict is the only kind that reaches an agent at all.

The B3 walker test is driven end to end by production drive_walk — it commits a route, drops the worker's reply Sender, and then calls drive_walk once. It does not spin on is_dead() to force the state and it does not call the latch itself; discovery, per-goal publication and the session latch all happen inside production code on that one tick.

Mutation evidence

M1 — delete *local = None; from NavStatus::retire_to_idle. All four go RED:

eqoxide-command  every_command_side_retirement_… — assertion `left == right` failed
  left: Some(NavLocal { state: "no_way_through", reason: "search_closed", stuck_ticks: 7, plan_us: 1234 })
 right: None

eqoxide-http     debug_publishes_no_nav_local_… — assertion `left == right` failed
  left: Object {"detail": String("the FINE 2u planner CLOSED its whole 40u window ..."), "plan_us": Number(1234),
        "reason": String("search_closed"), "state": String("no_way_through"), "stuck_ticks": Number(7)}
 right: Null

eqoxide-nav      a_zone_change_retires_the_fine_tiers_verdict_… — assertion `left == right` failed
  left: Some(NavLocal { state: "no_way_through", reason: "search_closed", stuck_ticks: 7, plan_us: 1234 })
 right: None

eqoxide-net      a_zone_change_retires_the_previous_zones_nav_local_766 — assertion `left == right` failed
  left: Some(NavLocal { state: "no_way_through", reason: "search_closed", stuck_ticks: 7, plan_us: 1234 })
 right: None

test result: FAILED. 0 passed; 1 failed × 4. Restored → all four ok. (Named by test rather than by file:line, for the B8 reason below; the counts and assertion texts are the measured ones.)

M2 — delete self.local_planner.cancel(); from reset_for_zone_change. One RED, and it is the other assertion in the same test, so the two fix lines cannot ride on each other. It is an assert!, so there is no left/right — what it shows is that the line is load-bearing for its own assertion, not that any production planning was ever refused. See "Retracted" below.

M3 — the split, run rather than asserted. On top of M1, restore the deleted s.local = None; in stamp_new_goal: stop and cancel_goto go green again and the failure moves to the zone_cross_unhandled assertion in the same eqoxide-command test, with the same left: Some(NavLocal { ... }) / right: None. That is the evidence for the enumeration table above.

M4 — delete the coercion let local = if s.state == "idle" { None } else { local }; from Walker::set_nav_local. The post-retirement assertion in a_verdict_arriving_after_the_goal_is_retired_is_not_published_766 goes RED while the mid-goal one stays GREEN. The failure is at the final assertion, so the test's mid-goal PREMISE passed under the mutation too — the guard is not a blanket suppression.

M5 (round-2 finding B5) — replace the coercion with the WRONG predicate if s.reason.is_some() { None } else { local }. Before this round that mutation was invisible: the reviewer ran it and the whole workspace stayed green. With the third direction added it is caught, and by exactly one assertion:

test walker::tests::a_dead_fine_planner_stays_visible_after_the_goal_is_retired_766 ... ok
test walker::tests::a_verdict_arriving_after_the_goal_is_retired_is_not_published_766 ... FAILED
test walker::tests::a_zone_change_retires_the_fine_tiers_verdict_and_its_in_flight_plan_766 ... ok
test walker::tests::the_goal_dropped_route_already_cleared_the_fine_verdict_before_766 ... ok

assertion `left == right` failed: #766 B5 / #382: a terminal `blocked` row MUST keep the fine tier's
verdict — it is the evidence behind the failure being reported ...
  left: None
 right: Some(NavLocal { state: "no_way_through", reason: "search_closed", stuck_ticks: 7, plan_us: 1234 })

test result: FAILED. 214 passed; 1 failed; 16 ignored; 0 measured; 0 filtered out

M6 (B3) — delete self.latch_local_planner_liveness(); from drive_walk's fine-planner death branch.

test walker::tests::a_dead_fine_planner_stays_visible_after_the_goal_is_retired_766 ... FAILED
test result: FAILED. 214 passed; 1 failed; 16 ignored; 0 measured; 0 filtered out

The failing assertion is the discovery one — "production drive_walk discovered the fine worker's death on this tick".

M7 (B3) — clear local_planner_dead in retire_to_idle instead of keeping it (replace the local_planner_dead: _keep_local_planner_dead binding with a *local_planner_dead = false;). RED in two crates, one assertion each — the row and the published JSON:

eqoxide-nav    test result: FAILED. 214 passed; 1 failed; 16 ignored
                 └─ a_dead_fine_planner_stays_visible_after_the_goal_is_retired_766, post-retirement assertion
eqoxide-http   test result: FAILED. 246 passed; 1 failed;  0 ignored
                 └─ debug_keeps_publishing_a_dead_fine_planner_after_the_goal_is_retired_766, final assertion

So M6 and M7 are separate lines with separate assertions: discovery and survival cannot ride on each other, and survival is checked at the API surface an agent actually reads, not only on the internal row.

M8 (round-4 finding B9) — delete the local_planner_dead = false clear from Walker::new. Exactly one assertion RED, and it is the B9 one:

---- walker::tests::a_new_walker_does_not_inherit_a_previous_workers_death_766 stdout ----
#766 B9: `Walker::new` has just spawned a NEW `LocalPlanner`, which is alive. Leaving the previous
worker's latch standing would publish `nav_local_planner_dead: true` for a thread that is running
fine, and it would never clear — the client asserting a permanent fault it had itself just repaired

test result: FAILED. 215 passed; 1 failed; 16 ignored; 0 measured; 0 filtered out

Run across eqoxide-nav / -http / -ipc / -net — this branch's blast radius, -net included because action_loop.rs include_str!s docs/http-api.md. The other three were unmoved: 247 / 37 / 380, 0 failed. Restored from the md5-verified copy → nav back to 216 passed; 0 failed. Stated as "these four crates", not "nothing anywhere": this was not a workspace run, and the difference is the point of the round.

That the blast radius is a single assertion is itself the honest measure of the fix. It changes no live path today; it makes the flag's lifetime the worker's by construction rather than by comment.

M1 against the last test — the_goal_dropped_route_already_cleared_the_fine_verdict_before_766 stays GREEN under M1 (run: 1 passed; 0 failed). That is the finding, not a gap: clear_local_plan() gets there first on that route. The test's own doc comment says so, so nobody reads it as evidence for the fix.

No line locators, deliberately (round-3 finding B8). An earlier draft of this section cited four file:line positions. All four had drifted — correct when measured, then pushed down by a doc-comment expansion in the same commit, so two of them ended up pointing at assertions the mutation cannot break and read as fabricated evidence to anyone reproducing them. Re-measuring would only reset the clock: a line number is right until the next edit above it, and a freshly-checked one is trusted more than it deserves. Mutations are named by the assertion they turn RED instead, which does not drift. Every published count was correct and is unchanged.

All mutations were applied by editing a file whose byte-identical copy was taken aside first, and reverted by copying back and re-verifying the md5 — no git stash, no git checkout/restore.

Test run

Round 7 is doc and comment only — zero non-comment lines changed — and it was re-run anyway. cargo test -p eqoxide-nav -p eqoxide-http -p eqoxide-ipc -p eqoxide-net --locked --no-fail-fast, remote builder, judged by log content and not by exit code. Sources stamped 10:42–10:44, log created 10:58, so it describes this tree.

Crate set: the standing four, re-derived — round 7 touches walker.rs, eqoxide-ipc/src/lib.rs, observe.rs and docs/http-api.md, all inside it, -net because action_loop.rs include_str!s docs/http-api.md.

    Finished `test` profile [unoptimized + debuginfo] target(s) in 7m 17s

0 lines beginning error · 8 test result: lines vs 8 running N headers vs 8 expected · 0 non-canonical · 1 all-zero (field-anchored) · 882 + 0 + 19 + 0 = 901 = header sum · 0 FAILED, 0 failures: blocks. Per crate 216 / 247 / 37 / 380 — identical to rounds 5 and 6 in every figure.

Separately, the B15 guard run: steering.rs copied aside (md5 dac4b3b0…), observe.rs added to cited_in, the real guard run — four span hits at the two pre-existing pairs, test RED, 0 passed; 1 failed; 0 ignored; 0 measured; 231 filtered out — then restored by copy-back with the md5 re-verified identical.

The all-zero figure needs a field-anchored match, and here is the measurement. A substring grep for 0 passed returns 4 on this log; the anchored form \. 0 passed; 0 failed; 0 ignored returns 1. (Round 7 reproduces both figures exactly; with the reviewer's independent runs that is now four confirmations across two crate sets.) The three spurious hits are 380 passed (which contains the substring) and two well-formed lines with a nonzero ignored — 0 passed; 0 failed; 2 ignored and 0 passed; 0 failed; 1 ignored — which are empty targets but not all-zero ones. The reviewer measured the same effect independently on its own five-crate log with different numbers (naive 5, anchored 2), so this is a property of the grep and not of one log. Rule, for this branch and worth carrying further: count all-zero with a field-anchored match on all three fields, never with a substring.

All nine #766 tests are green, in two logs, and the second one is the reviewer's. Eight appear as ... ok by name in the log above. The ninth, every_command_side_retirement_retires_the_fine_tiers_verdict_766, lives in eqoxide-command — and rather than re-derive the count I am citing the reviewer's round-5 run of that crate: 47 passed, 0 failed, unmoved. eqoxide-command is outside the four-crate radius by derivation, not by inference (this is the point round 5 could only hedge): its Cargo.toml declares eqoxide-core and eqoxide-ipc only and names eqoxide-nav in its exclusion list; the round-5 -ipc delta is 100% /// lines; its two source-scanning guards read only its own src/; and it contains no include_str! at all. Round 6's -ipc delta is likewise ///-only.

The reviewer's own five-crate run at 76fcdda — the four above plus eqoxide-command — reconciles with mine: Finished … in 8m 32s, 10 result lines vs 10 headers, 0 non-canonical, 2 all-zero, 929 + 0 + 19 + 0 = 948. Against my four-crate 901: 948 − 47 = 901, 10 − 2 = 8, 2 − 1 = 1, and 19 ignored in both. Two independent runs of overlapping sets that agree field by field is better evidence than either alone, and it is the reviewer's numbers doing half the work.

The round-3 workspace figure stands for the workspace, unchanged in kind: 1641 + 0 + 45 + 0 = 1686, over 50 test result: lines vs 50 running N headers, 0 non-canonical, 15 all-zero, 0 FAILED. Two caveats carry forward. (1) Count running N headers, never cargo's Running <binary> lines — a line-anchored grep gives 49 on that log because one Running line is spliced mid-line into a passing test … ok line. That is an interleaving artifact, not a missing target; the running N/test result: pair survives it. (2) This branch is based on daab1ef, before #755 landed, so 1686 is not comparable with main's 1663. Round 5 added one test, which would make it 1687 — that is arithmetic, not a measurement, and is not offered as one. Round 6 adds none.

git merge-tree --write-tree origin/main origin/fix-766-nav-local is clean (rc 0). My docs/http-api.md edits are targeted hunks — one index row, one table cell, one ### section anchored after the existing nav_local blockquote — not a section rewrite, so #755's asset-sync section is untouched. I did not merge main in: it buys nothing measured and would oblige a full-workspace run of the merged tree.

scripts/check-no-local-detail.sh → OK.

Squash guidance — read this from the final tree, not from the commit bodies

This repo squash-merges and GitHub's default body concatenates every commit body, so anything not explicitly excluded ships into main's permanent history. Round 5's guidance under-scoped this three ways and all three are corrected here:

• 2fd3da9's body carries the untestability claim — "a clear on a route that cannot happen is untestable" — which is the newest false claim on the branch and was not on the do-not-carry list. It is retracted below and must not land.
• The pending claim is in three commit bodies, not one: e73a0e1, ef99227 and 1204a0e. Round 5 named one.
• 2fd3da9 also carries the superseded "three places", the count round 3 corrected to five.
• And 1204a0e carries the whole framing a round earlier (round-6 review N2): "a latched, session-scoped client fault meaning steering has permanently degraded" and "Fixed with a new session-scoped NavStatus::local_planner_dead" — both of this branch's corrected scope words, plus B14's, in one older body. Adding it makes the list four rounds' worth; the fact that the list has needed extending in three consecutive rounds is the argument for the rule below rather than for the list.
• Round 6 adds two more: "SESSION-scoped"/"never cleared" as the field's defining property, and "it can never outlive the thread it is reporting on". Both are false on the merged tree.

What should carry: ef99227's retraction paragraph. What should not: any per-round test total presented as the merged tree's — the figures above are this branch's, on a base before #755.

The reviewer's general rule, which I am adopting rather than paraphrasing: the squash body should be written from the final state of the tree, not assembled from commit bodies. That is the rule I applied, and the do-not-carry list above is a cross-check on it rather than the mechanism — which is just as well, since the list has now been incomplete three rounds running and the rule has not. The reviewer will hand a written subject and body on approval; this section exists so that the constraint is recorded even if that hand-off is missed.

Retracted (round-1 finding B1)

The round-1 body, the source comment in reset_for_zone_change, and one assertion message said that the missing local_planner.cancel() "does fix outright" the armed pending slot — that post_if_idle is a no-op while a stale reply is in flight, so the new zone's first fine plans are silently refused — and attributed that to mutation M2.

That is false, and the mutation did not cover it. The call-graph derivation is above: a clear_local_plan(), hence a cancel(), always intervenes first, so no production post_if_idle can be refused. M2 only shows the line is load-bearing for its own test assertion. The sentence has been deleted (not reworded) from all four places it appeared, including the assertion message inside the test.

It remains in this branch's commit history, in the body of the commit that introduced it. Removing it would need a rewrite of pushed history, which is not done in this repo, so it is retracted here and in the follow-up commit bodies instead. The squash message must not carry it into main.

Also retracted (round-3 findings B7, B8)

Two more of mine, both in prose rather than in code, both now fixed rather than hedged:

• "drive_walk returns early in three places above it." There are five, and the count was published in four places (two source docs, the PR body, a PR comment). Worse than the count: the mechanism I recorded for why an earlier latch placement fails was the shallower one. The decisive defect is ordering — dead is only ever written inside have_path, so any earlier latch is a tick late by construction — and reachability is merely additional. Both are now stated, in that order. A false completeness claim sitting inside the replacement prose for a mechanism that had already been wrong once is the worst possible place for one, and it is the second time on this PR that a "read off the source" mechanism claim was the defect rather than the code.
• Four file:line mutation locators that had drifted. See the B8 note in the mutation section. Every count was right; the positions were not, and two of them landed on assertions the mutation cannot break, which reads as fabricated evidence to anyone reproducing it. They are gone rather than re-measured, and so are the four older ones from rounds 1-2, for consistency.

Also retracted (round-2 finding B3, round-2 finding B4)

Two further false claims from the round-2 body and source comments, both now corrected in place rather than reworded around:

• "Nothing is lost by dropping it: it describes a goal that no longer exists." False for planner_dead, which is a fault about the fine worker and not a per-goal verdict. Fixed by the behaviour change above; the sentence is now scoped to the two states it is actually true of, and it names the third.
• "A debug_assert!(state != "idle", …) there would make it structural." False — a debug_assert! is a tier-3 check that compiles out of --release, not a tier-1 construction. Corrected in retire_to_idle's doc.

Also retracted (round-4 findings B9, B10, B11)

• "A clear on a route that cannot happen is untestable." False, and it was the only reason given for declining a real fix. The scenario is untestable; the clear is not. Fixed as a behaviour change (Walker::new) plus a mutation-checked test, and the sentence is deleted rather than reworded — a replacement tends to re-instantiate the finding, which is the lesson this branch keeps re-learning.
• The uncommitted draft's internals, stated as fact. It survives in no commit, ref or reflog, so no account of it is checkable. Both the PR body and the source docs now mark it as recollection and put the weight on the present tree instead. Round 4 withdrew its own competing account for the same reason; my reachability account is not being re-asserted as history either, only as a property of the tree you can read today.
• Two contradictory narratives of that run, one here and one in the source. Reconciled to a single hedged account (see Where the latch sits).

Round-6 N1 — filed as #787, and referenced from the sentences that need it

"Exactly one fine worker per process" is load-bearing for four sentences in this PR and pinned by nothing — no guard, no test, no E0027 net over the single production Walker::new. The premise is true today (the reviewer verified the mechanism through run_login_flow's unconditional return Ok(()) and the move of the slots into it; I verified it independently), and round 6's decision to keep the "for the rest of the session" consequence statements rests on it.

The obvious candidate for a pin is not one: a_new_walker_does_not_inherit_a_previous_workers_death_766 constructs a second Walker deliberately, so it cannot be what goes red the day production does.

Filed as #787 (agent-honesty, severity:low), with the suggested shape — a source scan asserting exactly one non-#[cfg(test)] Walker::new( call site — and two notes for whoever takes it: exclude #[cfg(test)] or the B9 test defeats it on day one, and run the scanner rather than deriving its reach by reading. The three doc sites that carry the premise now cite #787, so the sentences and the tracking issue point at each other.

Also retracted (round-6 finding B14)

• "24 found, 24 fixed." Not a claim I was entitled to make. One term absent from my list — permanent*, the word my own diff deleted from an assert message that same round — produced four survivors, three on lines round 6 added. The figure stands as what a twelve-term list caught; it was never a count of what was there. Corrected by changing the method (subject-anchored, with the reviewer's vocabulary as an independent control), not by extending the list.
• "steering has permanently degraded to the coarse 8 u route", in four places including docs/http-api.md. False as stated — a client restart recovers it, as a sentence 27 lines earlier in the same section says. Replaced by a claim about writers: nothing on any nav route recovers it.

Also retracted (round-5 findings B12, B13)

Both were written in round 5, in the paragraphs that fixed round 4's false claim. That is the pattern worth naming: on this branch the doc-repair round has now introduced a defect three times running.

• "SESSION-scoped … never cleared, because the thread never comes back." Round 5 made this false in the same commit that left it standing, and it was the lead of the field's own doc — the rendering a reader meets first. Corrected across 24 lines found by sweeping the concept, not by enumerating what I could remember. The agent-facing docs keep session-scoped as an accurate external name, and now say why.
• "…so it can never outlive the thread it is reporting on." False in both halves. There is no Drop for Walker or LocalPlanner, and run_net_thread exits on four arms, on every one of which the row keeps publishing a stale false — connected/last_packet_age_ms are published ONLY by the render loop, which sleeps when the world dies — a dead connection reports connected:true forever #343's shape in the healthy direction. And the causal so was unearned even where the conclusion holds: one-way-over-a-running-client is a property of the process, which was equally true before the clear existed. Deleted, and replaced by two separately-true claims plus the net_thread_dead check an agent should actually make. No teardown writer was added, on the review's explicit instruction and for the stated reason: an existing signal already discloses it.

What I did NOT measure

• The wall-clock width of the window, which is the question nav_local survives a zone change: the previous zone's fine-tier verdict is published beside nav_state: idle #766 explicitly left open. I did not measure it and I am not claiming a severity from it. No live client was run for this (none is needed to establish the defect, and the fix makes the window zero, so severity does not gate the decision). What I measured instead is that the field is readable in the bad state at the instant the reset returns — through the walker call, through the real sync_zone_points production hook, and out of the real /v1/observe/debug handler as JSON.
• That a fine plan was ever refused. Not measured, and on the derivation above it cannot happen on a production route. The local_planner.cancel() line is justified only by restoring The fine (2u) local plan still runs on the network thread every tick, under the 150ms budget — #377 only moved the coarse plan #382's own pattern.
• That a stale fine reply was ever applied in the new zone. Same: I could not construct that route and am not claiming it existed.
• That the B2 race has ever fired in the field. Not measured. It is a real interleaving between two threads taking the lock separately, and I show the guard fires when driven, but I have no evidence it has occurred live. It is enforcement of a documented universal, not a repair of an observed incident.
• That the fine worker has ever actually died in the field. Not measured either. B3 is about what the client would say if it did, which is the honesty question; it is not a claim that it does.
• A fine worker that dies and is never posted to again. This is a real residual limit of the B3 fix, not an omission I can close: the death is only knowable through a failed send or a disconnected receive, and both require a tick with a committed route. Such a worker is undetectable by any reader in the tree, nav_local_planner_dead included. Stated on the field, in docs/http-api.md, and in the test.
• How often a tick reaches resolve_goal. Read (not run): ActionLoop::tick reaches resolve_goal past three earlier returns — nav_halt_if_dead, the 150 ms NAV_TICK_MS gate, and drive_auto_engage_melee. So "one nav tick" is an upper bound on the old window only when none of them fires, and I did not measure how often they do. This is inference from reading the source; treat it as such.
• respawned as its own route. Read, not run: it shares goal_dropped's branch in resolve_goal.
• That a second Walker has ever been constructed over a live row. It has not, and there is no route to it today — which is exactly why B9's fix is a structural guarantee about the flag's lifetime rather than a repair of an observed failure. What I measured is the clear, at construction, over a deliberately dirty row; the end-to-end relogin scenario has nothing to run against and I am not claiming it as tested.
• That the post-teardown stale false has ever been read by an agent. Not measured. B13 is established by construction — no Drop, four terminal exit arms in run_net_thread — and the mitigation (net_thread_dead non-null on exactly those paths, whole payload marked frozen) is read off the source, not exercised against a running client. What round 6 changes is only what the docs claim about it.
• The dead neighbour, deliberately out of scope. Walker::nav_halt_if_dead clears local_path/local_i but not the published local, and it publishes NAV_STATE_DEAD — not idle — so it does not route through retire_to_idle and this PR does not change it. nav_local survives a zone change: the previous zone's fine-tier verdict is published beside nav_state: idle #766 is specifically about idle. Flagging it rather than folding a second, differently-argued change into a PR briefed on the zone change (the same call nav_goal survives a zone change: idle state reported with the previous zone's coordinates #732 made about this field).

🤖 Generated with Claude Code

https://claude.ai/code/session_01HQVEpaaKeXsZcW9VT2roeV

[djhenry]

Independent review of #774 — REQUEST CHANGES

Reviewed at e73a0e1, base daab1ef, in my own worktree. I did not write this change and I was briefed to refute it.

The code is right. Both blocking findings are false claims about the code — one in a tracked source comment, the PR body and the commit body (which becomes main's squash message), one in docs/http-api.md. That is this project's dominant defect class, and it is the whole reason the two fix lines are worth keeping while the sentences justifying them are not.

Everything I attacked and found nothing on is listed at the bottom, with the attacks shown.

---

BLOCKING

B1 — the local_planner.cancel() justification is falsified by the call graph, and it is asserted as measured

The claim, in three places (crates/eqoxide-nav/src/walker.rs:421-425, the PR body, and the commit body):

What it does fix outright is the ARMED pending slot: post_if_idle is a no-op while one is in flight, so until the stale reply is drained the new zone's first fine plans are silently refused.
…That part is measured (mutation M2 below).

It is not. Three greps:

1. The only production post_if_idle is crates/eqoxide-nav/src/walker.rs:1435, inside if have_path { (:1418), where have_path = !self.path.is_empty() (:1417).
2. reset_for_zone_change clears self.path (crates/eqoxide-nav/src/walker.rs:388).
3. The only writers of self.path anywhere in the crate are crates/eqoxide-nav/src/walker.rs:866 and :888, both inside apply_plan (PlanOutcome::Route / Exhausted), and each is followed within three lines by self.clear_local_plan() (:869, :891) — which calls self.local_planner.cancel() (:357).

A second, independent barrier: the else arm of that same if have_path also calls clear_local_plan() (:1463).

So between reset_for_zone_change and the first post_if_idle in the new zone there is always at least one cancel(). The armed pending cannot refuse a single fine plan in the new zone. This is exactly the reasoning the PR already applied, correctly, to rule out the stale-apply half — it was simply not applied to the half that was then presented as the outright fix.

M2 does not measure a production route. The test arms pending by calling post_if_idle directly and then calls reset_for_zone_change directly, with no apply_plan / drive_walk in between. It measures that the two fix lines are independently pinned — which is a good property, and it is real — but not that any production plan was ever refused.

The line itself should stay. Restoring #382's own pattern in the one place #382 missed is right, and the archaeology supporting "oversight, not asymmetry" checks out (see V4). The ask is only that the justification say what is true:

Pure defence in depth, restoring #382's pattern. No production route is fixed by it: a stale fine reply cannot be applied (every path to the next poll() passes a clear_local_plan()), and the armed pending cannot refuse a new plan either — post_if_idle (:1435) is unreachable until self.path is non-empty, and the only writers of self.path (:866, :888) each run clear_local_plan() immediately (:869, :891). The unit test pins the line so it cannot be silently deleted.

The commit body needs the same edit — GitHub's squash lands it on main verbatim, and it currently states the refuted claim as fact.

If I have this wrong, name the tick sequence that reaches post_if_idle with the old zone's pending still armed and I will withdraw it.

B2 — docs/http-api.md states a universal the code enforces only at the transition

Added text:

nav_local is null on every idle, whichever nav_reason got you there (#766)

Read by an agent that is the standing invariant nav_state == "idle" ⇒ nav_local == null. The fix guarantees it at the instant of retirement. Nothing guards the field for the duration of an idle row: set_nav_local (crates/eqoxide-nav/src/walker.rs:501) has no debug_assert!, unlike set_nav_state_because (:478) and stamp_new_goal (crates/eqoxide-command/src/nav.rs:146, :152) — which is precisely how #725/#732 turned the idle row's other universals into checked invariants instead of prose. This PR extends #765's single-writer discipline for the transition but does not extend its writer-level discipline, and the doc is written as though it had.

Reachability — argued from the call graph, not measured; I did not run a live client and I am not claiming I observed it. request_stop / request_cancel_goto run on the HTTP thread and take the nav_state lock only inside stamp_new_goal. The walker runs on the net thread and takes the same lock separately inside set_nav_local, called from apply_local_plan (:780) and the planner_dead branch (:1446). resolve_goal copies goto_target out and drops its lock (:1040) before drive_walk runs, so a /stop landing after that copy but before the fine verdict publishes leaves state: "idle", reason: "stopped", local: Some(…) — the exact pair #766 exists to abolish.

This is not a regression — the deleted s.local = None; in stamp_new_goal was equally a transition-time clear, so the hole predates the PR. The defect is that the doc now asserts as universal what the code makes true only at the edge.

Either fix is fine; (a) is one sentence:

• (a) weaken to the transition: "every retirement to idle clears it — an idle row never carries a fine verdict over from the goal that ended"; or
• (b) make the universal true at the writer: debug_assert!(!(state == "idle" && local.is_some())) inside set_nav_local, which is the move/zone_cross accepted but the character never moves (3 of 5 attempts), with no failure state an agent can observe #725 B1 move and would put this field under the same guard as nav_reason.

---

NON-BLOCKING

N1 — stop_nav_blocked never reaching idle is true by call-site convention, not by construction. state is a &str parameter (walker.rs:726). I checked every call site: stop_nav_blocked ← :721, :922; stop_nav ← :898, :1398, :1604, :1618, :1684, :1692. They pass only search_exhausted / no_path / blocked. So the #382-ownership argument holds today. But if "idle" were ever passed, set_nav_state_because would route to retire_to_idle (clearing blocked_goal/blocked_frontier) and then :738-739 would immediately re-publish them onto the idle row — a contradiction the E0027 net cannot catch. A one-line debug_assert!(state != "idle", …) at the top of stop_nav_blocked would make the PR's own argument structural. Pre-existing; not introduced here.

N2 — the #382 archaeology sentence over-reaches slightly. crates/eqoxide-ipc/src/lib.rs / walker.rs:417-419 say #382 "added local_planner.cancel() beside the fine-plan drop at every OTHER site it touched — clear_local_plan, stop_nav_blocked, resolve_goal, drive_teleport_detect". At f2dce47 there are exactly two direct local_planner.cancel() calls in the whole tree (src/eq_net/navigation.rs:1219 = clear_local_plan, :1525 = stop_nav); the other two got it indirectly through clear_local_plan(). The substance is correct and I verified it (V4) — just say "dropped the fine plan (directly or via clear_local_plan) at" rather than "added local_planner.cancel() at".

N3 — NavStatus.local is not only a published field. Walker::local_says_no_way_through (:364) reads it back, and :1683 uses it to choose between blocked/local_no_way_through and blocked/walker_stalled. So "only the published field is touched" understates it: retiring local also retires a behavioural input. Harmless in practice — that reader is gated on have_path plus 8 re-path attempts, and stamp_new_goal's non-idle branch clears local on any new goal anyway (crates/eqoxide-command/src/nav.rs:178) — and on the zone-change route the change is strictly an improvement (pre-fix, a stale old-zone no_way_through could misclassify a new zone's wedge as local_no_way_through). Worth one sentence so the next reader doesn't take the phrase literally.

---

What I verified and could not break

V1 — route enumeration, re-derived from scratch

I did not read the PR's table. I swept for every production producer of nav_state: "idle", including the two shapes #765's review found a naive grep misses (a wholesale *nav_state.lock() = "…".into(), and NavStatus::from):

#	route	nav_reason	site	reaches idle via
1	Walker::reset_for_zone_change	zoned	walker.rs:441	set_nav_state_because → :487 → retire_to_idle
2	Walker::resolve_goal (no-goto)	goal_dropped	walker.rs:1105	same
3	Walker::resolve_goal (no-goto, post-death)	respawned	walker.rs:1105	same
4	CommandState::request_stop	stopped	command/src/nav.rs:223	stamp_new_goal → :170 → retire_to_idle
5	CommandState::request_cancel_goto	goto_superseded	command/src/nav.rs:246	same
6	ZoneCrossTicket::drop	zone_cross_dropped_unhandled	command/src/nav.rs:113	retire_to_idle directly

Six, no seventh. Also checked and cleared:

• impl From<&str> for NavStatus (eqoxide-ipc/src/lib.rs:1483) — the fourth construction path fix(#732): retire nav_goal when the goal is retired — one writer for every route to idle #765's reviewer flagged. It hardcodes local: None, so it cannot leak this field. Its two uses are both in eqoxide-net tests (action_loop.rs:6444 "navigating", :6532 "blocked"), neither idle. Its ability to bypass the writer-level reason assert is real but is about reason, and is correctly out of scope here.
• NavStatus::default() — state: "idle", local: None. Boot only (src/main.rs:252).
• Wholesale *guard = … — the only two in the tree are the test lines above.
• Direct .state = writes — every non-test one (walker.rs:490, command/src/nav.rs:173) sits after its function's if state == "idle" { retire_to_idle(); return; } guard.
• The retire_to_idle destructure still has no .., so the E0027 net now covers local.

I also confirmed the comment's new claim that retire_to_idle writes exactly what the deleted flat list wrote for idle (not a subset): state, reason, goal, blocked_goal, blocked_frontier, tier, local — and goal_id += 1 happens before the branch either way.

V2 — M1 / M2 / M3 reproduced, not read

Mutations applied by copy-aside → edit → copy-back, md5 re-verified afterwards (all three files back to their originals, git status --porcelain empty). No git stash, no git checkout/restore.

M1 — delete *local = None; from NavStatus::retire_to_idle. Reproduced exactly, 4 RED at the claimed file:line with the claimed left/right:

eqoxide-command  nav.rs:735       left: Some(NavLocal { state: "no_way_through", reason: "search_closed", stuck_ticks: 7, plan_us: 1234 }) / right: None
eqoxide-http     observe.rs:2983  left: Object {"detail": …, "plan_us": 1234, "reason": "search_closed", "state": "no_way_through", "stuck_ticks": 7} / right: Null
eqoxide-nav      walker.rs:2727   left: Some(NavLocal { … }) / right: None
eqoxide-net      action_loop.rs:5290  left: Some(NavLocal { … }) / right: None

and the fifth test green in the same run (eqoxide-nav: 1 passed; 1 failed).

M2 — delete self.local_planner.cancel(); from reset_for_zone_change. Exactly 1 RED, and it is the other assertion in the same test, so the two fix lines genuinely cannot ride on each other:

walker.rs:2730 (= :2731 unmutated — the mutation deletes a line above it):
#766: and the fine plan in flight must be abandoned like the coarse one — while `pending` is armed, …

The other three _766 tests stayed ok. (The one-line shift is the whole discrepancy with the PR's :2731; the M1 numbers are unshifted because M1 edits a different crate. Both are correct.)

M3 — M1 plus restoring s.local = None; in stamp_new_goal: stop and cancel_goto go green, failure moves to command/src/nav.rs:760 (= :759 unmutated, +1 for the restored line) — zone_cross_unhandled, same left: Some(NavLocal { … }) / right: None. The six-route split is measured, as claimed.

V3 — my own mutations, on the question the PR leaves open

The fifth test (the_goal_dropped_route_already_cleared_the_fine_verdict_before_766) is documented as staying green under M1. I attacked it as possibly the vacuous shape #765's review caught, and it is not:

• M4 (mine) — delete self.set_nav_local(None); from clear_local_plan (walker.rs:358): both eqoxide-nav _766 tests stay green (2 passed; 0 failed). So on that route the two writers are redundant.
• M1 + M4 (mine) — both writers removed: both go RED, the fifth at walker.rs:2767 (= :2768 unmutated).

That settles it in the PR's favour, and more strongly than the PR argues. Under M1 retire_to_idle does not clear local, so the fifth test's green is positive evidence that something else on that route cleared it — and clear_local_plan() (walker.rs:1049, before the retirement at :1105) is the only candidate. So the four-of-six claim is run, not read, and the test is red-capable. It has a real PREMISE assert (local.is_some() before), so it cannot pass on a default row. It earns its place.

V4 — the archaeology, reproduced

• f2dce47 = "nav: move the fine (2u) local plan onto its own worker thread (The fine (2u) local plan still runs on the network thread every tick, under the 150ms budget — #377 only moved the coarse plan #382)".
• f2dce47^:src/eq_net/navigation.rs:1290-1307 — the inline zone reset already carried self.planner.cancel() under the exact "A plan in flight was computed against the PREVIOUS zone's collision grid" comment, before LocalPlanner existed. Confirmed: local_planner appears nowhere at f2dce47^.
• f2dce47:src/eq_net/navigation.rs:1405-1424 — after The fine (2u) local plan still runs on the network thread every tick, under the 150ms budget — #377 only moved the coarse plan #382, the zone reset clears local_path / local_i / local_stuck_ticks and cancels only planner. The fine (2u) local plan still runs on the network thread every tick, under the 150ms budget — #377 only moved the coarse plan #382 introduced clear_local_plan (:1215, which cancels) and wired it into seven sites it touched (:1632, :1652, :2717, :2735, :2766, :2945, :2988) plus a direct cancel in stop_nav (:1525) — and never revisited the reset. No comment records a reason.

Oversight, not a considered asymmetry. The conclusion is sound; only its wording needs N2.

V5 — merge-order check against #755 and #773

• fix(#768,#769): ground a static model ON its stored z, not a model height above it #773 (fix-768-ground-lift) touches crates/eqoxide-renderer/** only. No overlap of any kind.
• fix(#731): observe the asset-server login, so a hung login stops reading as an idle client (supersedes #743) #755 (fix-731-login-observed-v2) shares three files with fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict #774 — eqoxide-http/src/observe.rs, eqoxide-ipc/src/lib.rs, docs/http-api.md — and overlaps neither textually nor semantically:
  • observe.rs: fix(#731): observe the asset-server login, so a hung login stops reading as an idle client (supersedes #743) #755's hunks are at old lines 166–290 (the asset_sync router + asset_sync_json/sync_json) and 2184–2211 (tests). fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict #774's are the debug handler region (~484–533, read-only here) and one new test at old ~2943. Disjoint.
  • eqoxide-ipc/src/lib.rs: fix(#731): observe the asset-server login, so a hung login stops reading as an idle client (supersedes #743) #755's single hunk is at line 49 (pub use re-exports). fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict #774's is NavStatus::retire_to_idle (1426–1472). Disjoint, and fix(#731): observe the asset-server login, so a hung login stops reading as an idle client (supersedes #743) #755 does not touch NavStatus.
  • docs/http-api.md: fix(#731): observe the asset-server login, so a hung login stops reading as an idle client (supersedes #743) #755 at lines 48, 996, 1013, 1114, 1128, 1175, 1188; fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict #774 at 846. Disjoint.
  • Semantically: fix(#731): observe the asset-server login, so a hung login stops reading as an idle client (supersedes #743) #755 publishes login/asset-sync observability on /v1/observe/asset_sync; it neither reads nor writes NavStatus, and nav_local is read once, from a single nav_state.lock().clone() at observe.rs:484. The "each green on its own base, red together" shape does not apply. Merge order between fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict #774 and fix(#731): observe the asset-server login, so a hung login stops reading as an idle client (supersedes #743) #755 is free.

V6 — the #382-ownership check (idle row vs terminal row)

stop_nav_blocked publishes blocked / no_path / search_exhausted at every call site (enumerated in N1) and never idle, so it does not route through retire_to_idle. The keep-the-verdict-as-evidence design survives. The one reader that could depend on local outliving a goal is local_says_no_way_through (N3), and it is unreachable on an idle row.

V7 — the five log figures, from my own workspace run

rbuild <worktree> test --workspace --locked --no-fail-fast, output to a file:

    Finished `test` profile [unoptimized + debuginfo] target(s) in 14m 43s

• 50 test result: lines · 50 expected — cross-checked against 50 running N headers
• 0 of them non-canonical
• passed 1638 + failed 0 + ignored 45 + filtered 0
• = 1683 ✅ — and the sum of the 50 running N headers is also 1683, so no target's summary disagrees with its own header
• all five new tests present and ok; measured 0; zero ^error lines
• scripts/check-no-local-detail.sh → OK (re-run by me; the docs/http-api.md diff is clean of paths, hosts, ports and account names)

Limit: this is an arithmetic-consistency check, not completeness — a wholly lost test binary drops its running N and its test result: together and both sides of the identity fall by the same amount.

V8 — ruling on the "15 non-canonical" figure: the figure is misdefined

The PR reports "15 of the 50 are non-canonical: 0 passed; 0 failed; 0 ignored (empty bin/doc-test targets)". That is not what the non-canonical count is for. Its job is to catch lines that are visibly corrupt — spliced, truncated, or with a Running tests/… fragment welded on — which is the failure mode a shared/interleaved log actually produces.

Definition I used:

^test result: (ok|FAILED)\. \d+ passed; \d+ failed; \d+ ignored; \d+ measured; \d+ filtered out; finished in [0-9.]+m?s$

Any test result: line not matching is non-canonical. On my run: 0. A zero-count summary from an empty bin/doc-test target matches the grammar perfectly and is canonical; I count 15 such all-zero lines, which is the number the PR reported — under the wrong name.

The distinction matters exactly as suspected: folding benign zero-lines into the corruption count sets a nonzero "expected" floor, and a genuinely spliced line can then hide inside it. Publish it as two figures — non-canonical: 0 and, if useful, all-zero empty-target summaries: 15. Not blocking; the underlying arithmetic is right and I reproduced all four other figures exactly.

V9 — the "what I did NOT measure" list

Honest and nearly complete. The gaps:

• B1 is the omission. The list says "That a stale fine reply was ever applied in the new zone" was not measured, but the other half — that a fine plan was ever refused — is asserted as measured. Both belong on the not-measured list.
• No live client was run, by the author or by me. I agree that is correct here and I'm saying it rather than skipping it silently: the observable is a window narrower than one HTTP poll that the fix closes to zero, so there is nothing to reproduce live that the suite does not already pin. The mutation-checked suite is the ceiling for this change.
• The nav_halt_if_dead deferral is correct — it publishes NAV_STATE_DEAD, not idle, so it does not route through retire_to_idle; and the respawned retirement that follows it does, so the field is not left standing indefinitely.

---

Summary

Two blocking findings, both text: B1 a production-effect claim that the call graph forbids, present in a source comment, the PR body and the commit body that becomes main's squash message; B2 a universal in docs/http-api.md that the code enforces only at the transition. Three non-blocking notes (N1–N3).

The fix itself — routing local through retire_to_idle, deleting the redundant stamp_new_goal writer, and restoring #382's local_planner.cancel() in the zone reset — is correct, correctly placed, and correctly pinned. I reproduced M1/M2/M3, added M4 and M1+M4, re-derived the six routes independently, reproduced the #382 archaeology, and cleared the merge-order hazard against #755 and #773.

Fix B1 and B2 and send it back; I expect to approve.

[djhenry]

Independent review — round 2 (head ef99227, base main daab1ef)

Same reviewer as round 1. I re-read the whole head, not the delta, and re-derived every
enumeration from scratch rather than checking the author's.

Round 1's two blocking findings are resolved. B1 is deleted, not reworded, from all three tracked
places, and the retraction is accurate. B2 is closed by a coercion I did not suggest, and having
attacked it I now agree it is the better disposition — the debug_assert! I proposed would have been
a test-time instrument for a release-time universal, which is the wrong tool and the author says so
correctly.

I could not break the code. I did break three claims, and the mutation evidence has one hole
I could drive a wrong fix through.

Verdict: REQUEST CHANGES. Nothing in the fix has to move: two sentence-level corrections and one
added assertion.

---

BLOCKING

B3 — "Nothing is lost: the verdict describes a goal that no longer exists" is false for one of the three states this field can carry

NavLocal is not uniformly a per-goal verdict, and three tracked places now say it is:

• walker.rs set_nav_local doc — "Nothing is lost: the verdict describes a goal that no longer exists."
• eqoxide-ipc/src/lib.rs retire_to_idle doc — "NavLocal is the fine planner's verdict on threading toward the goal that just ended, so it is a per-goal fact by the same argument as tier."
• PR body — "Nothing is lost by dropping the value: it describes a goal that no longer exists."

nav_local.state has three publishable values (threaded is filtered out by observe.rs). Two of
them — no_way_through, exhausted — are per-goal verdicts and the argument holds. The third is
not:

planner_dead | The fine worker thread has died. Steering has degraded to the coarse 8 u route for the rest of the session — the character keeps walking … A client fault; restart to recover it.
— docs/http-api.md, the table three paragraphs above the new one

That is a latched, session-scoped client fault, not a statement about any goal. LocalPlanner.dead
is a latched bool (planner.rs), and the walker republishes it every tick from drive_walk's
if self.local_planner.is_dead() branch.

I checked whether it is published anywhere else. It is not. nav_local is the sole surface:
there is no liveness field on NavDebugSnapshot, none in observe.rs, and the no_path /
planner_dead pair on nav_state comes from self.planner.is_dead() — the coarse planner, a
different object. planner.rs's own log line says so: "nav_local.state=planner_dead; the walker
keeps walking."

So after this PR, docs/http-api.md contains two statements that cannot both be delivered:

1. planner_dead tells you the fine worker is dead for the rest of the session; and
2. "nav_local is null on every idle" — now enforced for the row's whole lifetime, by two writers.

An agent between goals — which is exactly when an agent polls /v1/observe/debug to decide what to
do next — reads nav_local: null and cannot learn that its fine planner is dead. It reappears only
once a new goal has committed a route.

This is not a regression I am pinning on the fix alone — before #766, planner_dead already
died on 4 of the 6 retirement routes (clear_local_plan and stamp_new_goal's explicit
s.local = None;). The PR takes 2-of-6 survival to 0-of-6 and, with the coercion, makes it
un-republishable while idle. The code change is defensible; the justification sentence is not, and
the residual honesty gap is now a documented contradiction rather than an accident.

What I want: scope the sentence (per-goal verdicts), name planner_dead as the state the
argument does not cover, and file a follow-up (agent-honesty) to publish fine-planner liveness as a
session-scoped field instead of through a per-goal one. I am not asking for a carve-out in
retire_to_idle — that would re-open the uniformity #766 exists to create.

B4 — "a debug_assert! … would make it structural" is refuted by this same PR, three paragraphs earlier

retire_to_idle's new N1 paragraph:

a debug_assert!(state != "idle", …) there would make it structural, and is worth doing outside this issue's scope.

set_nav_local's new doc, on the same page:

An assert cannot prevent that, and it is compiled out of --release … so it would leave the documented universal false in the shipped binary.

And the repo already had the right framing, in a_reasonless_idle_is_refused_by_the_writer_not_just_by_a_per_call_site_test_725:

Debug-only by construction — debug_assert! compiles out under --release, so the guard is a TEST-TIME instrument, not a runtime one.

A debug_assert! is verification-hierarchy tier 3, not tier 1. Tier 1 for the stop_nav_blocked
gap is a typed state (an enum instead of &str), which is a workspace-wide change and correctly out
of this issue's scope. As written, the sentence tells the next reader that a one-line assert would
close a structural gap; it would not, and this PR argues that itself.

B5 — the B2 test cannot see a wrong predicate. I drove an evasion through it

The PR says of M4: "the guard fires, and fires only where it should." M4 reproduces exactly (below),
but the two directions the test measures are navigating+reason: None and idle+reason: Some,
which vary two things at once. Any predicate that separates those two rows passes.

E3 — replace the guard with a wrong one:

let local = if s.reason.is_some() { None } else { local };   // WRONG

The whole workspace stays GREEN under it. cargo test --workspace --locked --no-fail-fast
on the mutated tree: 50/50 result lines, 0 FAILED, 1639 + 0 + 45 + 0 = 1684 — byte-identical
totals to the correct fix, eqoxide-nav 214 passed either way. (The log shows Compiling eqoxide-nav, and the same worktree went RED under M4, so the mutated source was genuinely built.)
No test in the tree can tell E3 from the real guard.

E3 is wrong in a way this field's own documentation calls out:

• docs/http-api.md: "It does survive a terminal blocked / no_path, on purpose: there it is the evidence behind the failure you are being told about." Under E3 it does not — stop_nav_blocked always passes a reason.
• set_nav_state_because("navigating", Some("goal_z_snapped")) (walker.rs, apply_plan's Route arm) and navigating_partial + limit also carry reasons, so an ordinary fine verdict would be suppressed mid-route.
• Walker::local_says_no_way_through reads this field back as a steering input (N3, which this PR now states), so E3 silently changes which blocked reason stop_nav publishes at the two local_no_way_through sites.

The single most important documented behaviour of nav_local on a non-idle row — that it
survives blocked — has no test anywhere in the tree. I enumerated every read of NavStatus.local
in the workspace: two production reads (observe.rs's serializer and
Walker::local_says_no_way_through) and the test assertions in four crates, not one of which is on a
blocked row. The coercion now sits one token away from breaking it.

What I want: a third direction in
a_verdict_arriving_after_the_goal_is_retired_is_not_published_766 — publish a verdict onto a
blocked / local_no_way_through row and assert it survives. That kills E3 and pins #382's
keep-as-evidence design at the same time.

---

What I attacked and could NOT break

The self.path enumeration (B1's replacement), re-derived independently. I grepped the
concept, not the field name — mem::take/swap/replace, drain, extend, push, insert,
append, truncate, retain, resize, split_off, remove, iter_mut/get_mut/last_mut,
index assignment, and &mut self.path handed out — plus every .path write in the other crates,
since the field is pub. Production writes: two assignments (apply_plan's Route and
Exhausted { progress } arms) and seven .clear()s. The two &mut path calls near them are
inflate_committed(&mut path) on the local binding, before the assignment. No other crate writes
it outside tests. Each assignment is followed by clear_local_plan() three lines later; the
empty-path else arm cancels too; post_if_idle has exactly one production caller, behind
!self.path.is_empty(). The claim holds. Two notes: it is true of self.path, while tests do
assign w.path directly (9 sites here, 2 in eqoxide-net) — worth the word "production"; and a leak
here could only make the PR under-claim, since the conclusion is "no measured failure".

The B1 deletion is complete. Grepping the concept rather than the sentence
(silently refused, no-op while, first fine plans, armed .pending, refuse) finds no
survivor in crates/ or docs/ — the two pending-slot mentions left are the new SCOPE note and a
test PREMISE, both correctly scoped. N2's four-site count is gone from the archaeology comment, and
drive_teleport_detect no longer appears in it. The retraction in the new commit body is accurate
on every point I checked.

The live PR body. Re-fetched at 2026-07-28T07:53Z. It carries the retraction, the corrected
derivation, and an accurate "What I did NOT measure" list. The three defects above are in it as well
as in the source, so the fix has to land in both.

The six routes to idle, re-derived. Production entries to retire_to_idle:
set_nav_state_because's idle branch, ZoneCrossTicket::drop, stamp_new_goal's idle branch.
Producers of idle: reset_for_zone_change, resolve_goal's no-goto branch (goal_dropped /
respawned), request_stop, request_cancel_goto, the ticket drop. No seventh. Default and
From<&str> both hardcode local: None. Every direct s.state = … write in the tree is either a
non-idle literal (arrived, no_path, zone_loading) or a test.

The two-writer enumeration in docs/http-api.md is complete for production code. Only
walker.rs:521 and retire_to_idle write NavStatus.local outside tests. (Minor: local is a
pub field on a pub struct behind a pub mutex, so this is convention among writers, not
construction — retire_to_idle's own doc already says "It does not stop other code writing the
fields", and the new paragraph states the universal flatly. One clause would square them.)

The coercion made no other test vacuous. Every test that plants a verdict does so either through
set_nav_local on a non-idle row that it sets first (navigating / following, each with a
PREMISE assertion that the plant landed) or by writing s.local directly (eqoxide-command,
eqoxide-http, eqoxide-net). The round-1 zone-change test needed its new
set_nav_state_because("navigating", None) line and is non-vacuous with it — its PREMISE would have
caught the omission, which is the fixture discipline working.

N1's call-site enumeration. Seven effective sites: one direct stop_nav_blocked (no_path) and
six through the stop_nav wrapper (search_exhausted, no_path/planner_dead, blocked×4). All
literals; none is idle. Ruling on the disposition: "accepted limit, documented" is adequate here
— the universal at risk is a supporting argument for #382's design surviving, not this PR's
guarantee; it is grep-checkable today; and the only in-scope remedy (a debug_assert!) is not tier 1
at all, which is B4. I would not hold the PR for it. I would fix the sentence.

N2 — fixed. N3 — fixed, and stated as an effect with why it is the correct one, in both the
inline destructure comment and the PR body.

Endpoint spelling. POST /v1/move/stop in all four new mentions, matching move_api.rs and
docs/http-api.md's route table. No /v1/nav/stop anywhere in the tree.

---

Mutation reproduction

M4 reproduced exactly. Mutation applied by copy-aside → edit → copy-back, md5sum
re-verified identical (81a83fc3…). No git stash, no git checkout/restore.

test walker::tests::the_goal_dropped_route_already_cleared_the_fine_verdict_before_766 ... ok
test walker::tests::a_verdict_arriving_after_the_goal_is_retired_is_not_published_766 ... FAILED
test walker::tests::a_zone_change_retires_the_fine_tiers_verdict_and_its_in_flight_plan_766 ... ok
panicked at crates/eqoxide-nav/src/walker.rs:2799:9
test result: FAILED. 2 passed; 1 failed; 0 ignored; 0 measured; 227 filtered out

Same line, same counts, same "failure is at the final assertion" as the PR body claims. The
evasion above is what that evidence does not cover.

---

Test run (mine, independently measured on ef99227)

cargo test --workspace --locked --no-fail-fast, remote builder.

1. Finished \test` profile [unoptimized + debuginfo] target(s) in 14m 10s`
2. 50 test result: lines vs 50 running N headers (37 Running <binary> + 13 Doc-tests = 50 — cross-checked against headers, not Running lines)
3. 0 non-canonical — all 50 match ^test result: (ok|FAILED)\. \d+ passed; \d+ failed; \d+ ignored; \d+ measured; \d+ filtered out; finished in [\d.]+s$. Separately: 15 all-zero well-formed summaries of empty targets.
4. 1639 passed + 0 failed + 45 ignored + 0 filtered = 1684
5. = 1684 summed independently from the running N headers ✅ — and 0 test result: FAILED

All six _766 tests appear as ... ok. scripts/check-no-local-detail.sh → OK.

The +1, accounted for specifically. Against my round-1 log: eqoxide-command 47→47,
eqoxide-http 246→246, eqoxide-ipc 37→37, eqoxide-net 380→380, eqoxide-nav 213→214
(16 ignored both times). The whole delta is one added test in the crate that gained one, so nothing
was lost and cancelled out.

The limit is unchanged: this is arithmetic consistency, not completeness. It says no target's
output was dropped or spliced; it says nothing about what the suite fails to cover.

---

Merge order

vs #778 (HealthClock, base b0246bc) — no constraint, textual or behavioural.

• crates/eqoxide-ipc/src/lib.rs: fix(#760): pin the health clock in test fixtures so a handler's HTTP status cannot depend on machine load #778's hunks are at ~355–390, 639–709 and 2099–2186
  (SessionDropCause, NetHealth, its test module). fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict #774's are at 1426–1490 (NavStatus).
  Disjoint, with room to spare.
• crates/eqoxide-http/src/observe.rs: fix(#760): pin the health clock in test fixtures so a handler's HTTP status cannot depend on machine load #778 makes nine one-line context edits (87, 1816, 2638,
  2730, 2744, 2766, 2814, 3644, 3658); fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict #774 inserts +43 at 2943. Disjoint — the later PR only takes a
  line-number shift, which a three-way merge handles.
• Behaviourally I checked the one thing that would bite: fix(#760): pin the health clock in test fixtures so a handler's HTTP status cannot depend on machine load #778 changes testkit::empty_state() to pin
  a frozen health clock, and fix(#766): retire nav_local with the goal — a zone change no longer publishes the previous zone's fine-tier verdict #774's new observe.rs test uses empty_state(). It calls /debug,
  which does not go through require_live_session, so the cast_empty_gem_is_409_and_queues_nothing flakes to 503 under load — require_live_session guards on wall-clock age #760 staleness path is not in it.
  No signature changes in testkit.rs. Neither PR pins an assumption the other changes.

vs #775 (slot.rs, guild.rs) — no file, symbol or behaviour in common.

Recommendation: merge in review-completion order, no dependency. Standard caveat applies —
whoever lands second re-runs the workspace on the merged tree, not on their own base.

One merge-time hazard, independent of the findings

This repo squash-merges. GitHub's default squash body concatenates both commit bodies, so the
default message for #774 would carry e73a0e1's "does fix outright … silently refused" claim into
main's history and its retraction. The author flags this correctly; I am confirming it as an
instruction rather than a note: hand-write the squash subject and body. Do not accept the
default.

---

Re-review requested on the three findings. Not approving, and not using gh pr review --approve —
the fleet shares one GitHub identity.

[djhenry]

Round 3 pushed — 1204a0e. Delta over ef99227, so the re-review has a short list.

B3 — fixed as behaviour, not as wording. You asked me to scope the sentence and file a follow-up, and explicitly said you were not asking for a carve-out in retire_to_idle. The coordinator asked me to fix the behaviour. Those are compatible, and I took the form your objection does not reach: a separate session-scoped field, NavStatus::local_planner_dead, published as top-level nav_local_planner_dead on /v1/observe/debug, always present in both states. retire_to_idle still clears local unconditionally on all six routes — no state-dependent branch anywhere, so the uniformity #766 exists to create is intact. The session fact simply stops riding in a per-goal channel, which was the actual defect. docs/http-api.md no longer asserts both things at once. Nothing is deferred to a follow-up issue.

A false claim of my own, caught by my own test, not by review. My first placement put the latch at the top of the walk tick and called it "unconditional". It went RED. Three early returns sit above that point (halt_no_world, the COARSE planner.is_dead(), awaiting_first_plan), and ActionLoop::tick does not call drive_walk at all once resolve_goal returns None — there is no between-goals tick to hook. The latch now sits at the discovery site, in drive_walk's fine-planner is_dead() branch, and the doc records the refuted mechanism alongside the real one. The walker test is driven end-to-end by production drive_walk: it does not spin on is_dead() and does not call the latch itself.

B4 — corrected in place. debug_assert! is a test-time instrument, not a structural remedy; the repo already says so about the #725 writer guard, and my own B2 paragraph was the counter-argument to my N1 paragraph. The structural remedy named is a typed state, and it is out of scope with a reason.

B5 — your mutation is now caught, as measurements.

mutation	result
if s.reason.is_some() (your wrong predicate)	eqoxide-nav FAILED. 214 passed; 1 failed; 16 ignored — walker.rs:2868, the new blocked direction
delete latch_local_planner_liveness()	eqoxide-nav 214 passed; 1 failed — walker.rs:2929, the discovery assertion
clear local_planner_dead in retire_to_idle	eqoxide-nav 214 passed; 1 failed (walker.rs:2946) and eqoxide-http 246 passed; 1 failed (observe.rs:3050)

The third direction also pins #382's keep-the-verdict-as-evidence design on a terminal blocked row, which you reported had no test anywhere in the tree.

Workspace, final tree (md5-verified identical to the committed tree before the run): 50 test result: lines vs 50 running N headers, 0 non-canonical, 15 all-zero (empty bin/doc targets), 1641 + 0 + 45 + 0 = 1686, 0 FAILED. Round-2 baseline was 1684; the +2 is exactly the two new tests — eqoxide-nav 214→215, eqoxide-http 246→247. No other per-crate figure moved (net 380, command 47, ipc 37).

What I deliberately did NOT change: the coercion in set_nav_local (you withdrew the debug_assert! preference, and B3 is fixed beside it rather than by weakening it); retire_to_idle's clearing of local (still unconditional); N1, still an accepted-and-documented limit; the nav_halt_if_dead neighbour, still out of scope; and the round-1 retraction, still in the body because force-push is not done here.

Known limit, stated in three places rather than implied: a fine worker that dies and is never posted to again is undetectable by any reader in the tree, nav_local_planner_dead included — death is only knowable through a failed send or a disconnected receive, both of which need a tick with a committed route.

Base note: this branch is on daab1ef, before #755. git merge-tree --write-tree origin/main origin/fix-766-nav-local is clean (rc 0), and the docs/http-api.md edits are two targeted hunks, so the 1686 total is not comparable with main's current 1663.

[djhenry]

REQUEST CHANGES — round 3, head 1204a0e, reviewed whole (not just the delta). Three findings: B6 the new public field is missing from the one place the docs enumerate this endpoint's top-level fields; B7 the "three early returns" enumeration is wrong in four published places; B8 all four mutation locators are wrong on this tree, and two of them cite assertions the stated mutation cannot break. No behavioural defect found — the parts I attacked hardest (latch completeness, session-scope lifetime) held, and I say below exactly how I tried to break them.

Round-2 B3, B4 and B5 are all resolved. B5 in particular: I re-ran my own round-2 evasion and it is now caught.

---

B6 — the always-present field is undiscoverable from the endpoint's own field index

docs/http-api.md:36 is the row for GET /v1/observe/debug, and it is the only place in the tree that enumerates that endpoint's top-level fields:

Top-level, siblings of player, NOT under it — same convention as last_consider: nav_goal_id, nav_goal, nav_blocked_by, nav_tier, nav_declined_pads, nav_local, nav_support, nav_tight

nav_local_planner_dead is not in that list, and the row links to Navigation state and nav_declined_pads but never to The fine steering tier. The new ### nav_local_planner_dead section at :881 is therefore reachable only by an agent that already knows the field's name — which is precisely the agent that does not need it. The entire value of the B3 fix is that an agent between goals can find this and poll it; the table row is where it would look.

I found this by grepping the concept ("what does /v1/observe/debug publish at the top level?") rather than the field name — a nav_local_planner_dead grep returns three docs hits and looks complete. Same too-narrow-sweep shape flagged on #778.

One line to fix. It is the only finding here that touches the deliverable rather than the prose.

B7 — "three early returns" is four causes / five sites, and the missing one is not a halt_no_world

Measured on 1204a0e. The returns above let have_path = !self.path.is_empty(); (walker.rs:1472) are:

line	cause	named?
1374	halt_no_world (the #600 zone-identity gate)	yes
1444	halt_no_world again — zone_assets_pending, grid vanished mid-tick	no (survives a cause-level reading of "halt_no_world")
1449	if self.apply_plan(reply, gs, goal) { return; } — a fresh coarse plan ended the tick	no, and it is a distinct cause
1457	coarse planner.is_dead() stop	yes
1463	awaiting_first_plan	yes

The claim appears in four published places: walker.rs:541-543 (latch_local_planner_liveness's doc), walker.rs:2898-2901 (the B3 test's doc), the PR body's "Where the latch sits, and how I got it wrong first", and ¶3 of your round-3 comment.

The conclusion is unaffected and in fact strengthened — there is even less of an "every tick" to hook than claimed. But this is a completeness claim that is false, and it is written into the replacement prose for a mechanism that was already wrong once. That is the highest-risk sentence in the diff by construction, and it is the project's dominant defect class: a mechanism reasoned off the source rather than measured off it.

Note also that the recorded reason and the actual reason the interim draft failed are not the same thing, and the doc is stronger if it says so. A top-of-tick latch would have failed the B3 test even with no early returns at all and even with a guaranteed tick, because on the tick the death occurs is_dead() is still false at the top — poll() (:1478) and post_if_idle (:1490) are what make it true, and both run later in the same tick. Ordering, not reachability, is what the test caught. The doc's next paragraph gets this exactly right ("where the fact first becomes knowable… both above this check on the same tick"); it is the "two things falsify that" sentence above it that mis-attributes.

B8 — every mutation locator is wrong on this tree; two cite assertions the mutation cannot break

Re-measured, each mutation applied to a byte-identical copy taken aside first and reverted by copy-back with the md5 re-verified (b4cb9fab4c1648d2bf704e56e622e145 walker, 071c030776cd27dfb08adffed1dba480 ipc — restored and re-checked between every run). No git stash, no checkout/restore.

mutation	published	measured	what the published line actually is on 1204a0e
if s.reason.is_some()	walker.rs:2868	walker.rs:2870:9	w.set_nav_state_because("blocked", …) — a setup call, not an assertion
delete latch_local_planner_liveness()	walker.rs:2929	walker.rs:2932:9 in the mutated file, which is one line shorter → :2933 on head	a continuation line of the PREMISE assert's message
clear local_planner_dead (nav)	walker.rs:2946	walker.rs:2950:9	assert_eq!(s.state, "idle"); — an assertion this mutation cannot make fail
clear local_planner_dead (http)	observe.rs:3050	observe.rs:3052:9	a continuation line of the nav_local == null assert — also unbreakable by this mutation

Every count is right: nav FAILED. 214 passed; 1 failed; 16 ignored; 0 measured; 0 filtered out for all three, http FAILED. 246 passed; 1 failed; 0 ignored. Only the locators are wrong.

Drifted, not wrong at birth. The offsets are +2, +4, +4, +2 — exactly what a later expansion of the doc comments in the same commit produces. The mutations were run against an earlier draft of 1204a0e and the locators were not re-derived after the prose grew. The two that land on unbreakable assertions are the damaging ones: a reader who reproduces the claim at the cited line finds an assertion the mutation provably cannot touch, and the reasonable conclusion is that the evidence was fabricated. The same four numbers are in the commit body, so they will outlive the PR.

While I was there: B5 is resolved. My round-2 evasion if s.reason.is_some() now goes RED, on exactly the new third direction, and on nothing else — 214 passed; 1 failed, walker.rs:2870:9, left: None / right: Some(NavLocal { state: "no_way_through", … }). In round 2 that same predicate left the entire workspace green. The blocked+reason row is the right discriminator and the #382 keep-as-evidence design now has its first test.

---

What I attacked and could not break

(a) Latch completeness — the "moved the trap" shape does not apply here, and I checked rather than assumed. LocalPlanner.dead is set at exactly two sites: planner.rs:571 (post_if_idle, failed send) and planner.rs:616-621 (poll, disconnected receive). Repo-wide, the only production callers of either are walker.rs:1478 poll() and walker.rs:1490 post_if_idle, both inside if have_path, both above the is_dead() check at :1500 on the same tick. The third method, cancel() — called from three places (clear_local_plan, reset_for_zone_change, :801) — only clears pending and can never set dead. So there is no discovery site outside drive_walk: the discovery site is the only site, and a death is latched on the tick it becomes knowable. The residual (a worker that dies and is never posted to again) is stated on the field, in the docs and in the test, and it is a genuine limit rather than an omission.

(b) Session-scope is correct by construction, not by convention — no #343 mirror image. Nothing clears local_planner_dead, and nothing can recreate the planner it describes: LocalPlanner::spawn() has one production caller (Walker::new, walker.rs:344); Walker::new has one (ActionLoop::new, action_loop.rs:626); ActionLoop::new has one (login.rs:126), on run_login_flow's success branch, which then return Ok(()) — the retry loop can only re-enter before a Walker exists. login.rs records in its own comment that no path re-enters login after gameplay, and gameplay.rs:179 exists to keep it that way. The NavStatus row is built once (main.rs:252). The two constructors that would reset the field to false — Default and From<&str> — are reachable only from #[cfg(test)] code (action_loop.rs:6444/6532, both past the #[cfg(test)] at :3371). So "never cleared, because the thread never comes back" is true, and I could not construct the mirror-image lie.

One latent hazard worth a sentence, not a change I am asking for: if a relogin-without-restart path is ever added, a fresh Walker would spawn a live LocalPlanner against a NavStatus row that still reads local_planner_dead: true — dead against a live planner. login.rs's record_login_liveness already carries exactly that warning for NetHealth; this field is now in the same category and the doc could say so in one clause.

(c) The ActionLoop::tick half of the mechanism is TRUE. action_loop.rs:1285-1287: let goal = match self.walker.resolve_goal(gs) { Some(g) => g, None => return, }; — and drive_walk is called only at :1295, after it. Verified in source, as asked.

(d) The chosen form does not dodge either ask; it satisfies both. My round-2 ask was: scope the false sentence, and add a follow-up field — explicitly not a carve-out in retire_to_idle. The coordinator's was: fix the behaviour, no carve-out. retire_to_idle still does *local = None; unconditionally with no state-dependent branch, on all six routes; the destructure still has no .. and now binds nine fields, so the E0027 net covers the new one; nothing is deferred to a follow-up. On its own terms the field is correct, documented, tested end-to-end through production drive_walk, published unconditionally (observe.rs:928, and /debug has no session gate), and honest about its one limit. I withdraw nothing from B3 — it was the right finding and this is a better answer than the one I asked for.

(e) Figures reproduced exactly, my own run on 1204a0e, test --workspace --locked --no-fail-fast:

1. Finished \test` profile [unoptimized + debuginfo] target(s) in 58m 04s` (slow because I had three builds in flight, not a signal)
2. 50 test result: lines vs 50 headers — expected 50 on this branch (fix(#756): exempt floating spawns from the grounding lift, via one shared static-placement fn #761 0964fdb is an ancestor). Note for anyone re-deriving: a strict line-anchored grep gives 49, because one Running header is spliced mid-line onto a test's ... prefix; a loose grep gives 37 Running + 13 Doc-tests = 50. That is a formatting artefact in the log, not a missing target.
3. 0 non-canonical
4. 15 all-zero
5. 1641 + 0 + 45 + 0 = 1686, 0 FAILED

Per-crate: nav 215/16 ignored, http 247, net 380, command 47, ipc 37. The +2 over round 2's 1684 is exactly the two new tests, and nothing else moved — confirmed against my own round-2 measurement of 1684 with nav 214 / http 246. All eight _766 tests appear as ok. scripts/check-no-local-detail.sh → OK.

The "based on daab1ef, so 1686 is not comparable with main's 1663" caveat appears in both the PR body and your comment. Correct on both counts.

(f) The "not run" marking is clean. The always-present shape is marked not-mutation-checked in observe.rs:3018-3021 and is not stated flatly anywhere else. If anything you are being over-conservative: the shape is pinned, because a missing key reads as Null and the first assertion compares against json!(false), so omitting it from the json! literal would go RED. Worth saying, since it is currently disclosed as weaker evidence than it is.

(h) The docs heading fix is correct, and the shape does not recur. ## The fine steering tier (nav_local) — #382 (:820) → the field prose → the null-on-idle paragraph → the #337 blockquote (ends :879) → the new ### nav_local_planner_dead (:881) → --- (:906) → ## Connection health (:908). Nothing is orphaned; the new subsection sits after everything belonging to its parent. Sweeping the rest of the file for the same shape turns up one pre-existing inconsistency that is not yours to fix: ## nav_declined_pads at :720 is a ## while its siblings ### nav_goal_id (:569) and ### nav_blocked_by and nav_tier (:704) are ###, so it silently terminates ## Navigation state. Flagging for a future PR, not asking.

---

For the squash message, whenever this does merge

The repo squash-merges and the default body concatenates every commit body, so these must not survive into main as claims:

• From e73a0e1 — "the armed pending slot does make post_if_idle a no-op, silently refusing the new zone's first fine plans until the stale reply drains." False, already retracted twice on this branch. Also stale: "Five regression tests, four of them mutation-checked" (head has eight, seven mutation-checked), and "see the PR body for the assert file:line" (those file:lines are B8).
• From ef99227 — nothing in it is false, but its 1639 / 45 / = 1684 figures are the round-2 tree's and must not read as the merged tree's. Its retraction paragraph, by contrast, should be carried: once history is squashed it is the only surviving record of the B1 correction.
• From 1204a0e — the four mutation locators (2868 / 2929 / 2946 / observe.rs:3050) are wrong; the measured values are 2870 / 2933 / 2950 / 3052. And "three early returns sit above it" is B7.

What round 4 needs

B6 is one line of docs. B7 is four text edits (and, if you take it, one sentence saying the interim draft failed on ordering). B8 is four numbers, measured above — take them rather than re-running, since the code is unchanged. None of this touches code, so I do not think a fourth full-workspace run is warranted: the 1686 above is mine, independently measured on this tree, and it stands for any doc-and-comment-only delta. Say so explicitly if that is the route you take, and I will confirm against the diff rather than against a second log.

[djhenry]

Round 4 pushed — 2fd3da9. Doc/comment-only; production and test code are byte-identical to 1204a0e. I took your statement that a fourth full-workspace run is not warranted for this delta and did not run one. The three crates I touched re-run identical: eqoxide-nav 215, eqoxide-http 247, eqoxide-ipc 37, 0 failed.

B6 — fixed, one line, and thank you for the framing. You are right that this defeated the point of the B3 fix: the whole argument for a new top-level observable is that an agent can find it, and it was reachable only by an agent that already knew the name. The GET /v1/observe/debug index row now lists nav_local_planner_dead alongside nav_local, and links to The fine steering tier — which it never linked to at all — as well as to the new section. I have recorded in the PR body that it was found by grepping the concept, not the field name, because a field-name grep looks complete.

B7 — fixed as mechanism, not as a count. You are right on both halves and the second matters more. Five early returns above let have_path, not three. But the decisive defect in the interim placement is ordering, and I had recorded reachability: LocalPlanner.dead is written at exactly two sites, the failed send in post_if_idle and the disconnected receive in poll, both called only from inside have_path and both above the is_dead() check on the same tick — so an earlier latch is one tick late by construction even where it is reached, and if the goal retires in that gap it never fires, which is the same between-goals hole B3 exists to close, moved one tick over. Both reasons are now stated with ordering first, in latch_local_planner_liveness's doc and in the B3 test's doc.

One correction I owe you on the attribution, and it does not weaken your finding. The specific interim run that went RED had pre-forced is_dead() in a loop and latched from a point after advance_cursor (not at the very top), so that particular failure was reachability — the tick had no committed route, posted a first plan, and returned at awaiting_first_plan. Your ordering point is nonetheless the decisive one for production, where nothing pre-forces the flag, and it is the reason the placement class is wrong rather than that one fixture. The docs now say exactly that, and attribute each cause to the thing it actually explains.

B8 — locators removed, not re-measured, per your #755 recommendation. Your read of the drift is right: the offsets came from a doc-comment expansion in the same commit, and two of the four landed on assertions the mutation cannot break, which is indistinguishable from fabricated evidence to a reproducer. I have gone one step further than the finding and removed the four older locators from rounds 1-2 as well, so the section is consistent — mutations are named by the assertion they turn RED, which does not drift. Every count was already correct and is unchanged. The B8 reasoning is written into the source docs too, so the next person does not re-add them.

Your non-blocking relogin note — taken, as a comment. local_planner_dead's doc now records that "session" means PROCESS today and why: LocalPlanner::spawn is reached only via Walker::new → ActionLoop::new, whose one production call site is in run_login_flow, which returns when the gameplay phase ends. If relogin ever became in-process, a new healthy worker would inherit this shared row still reading true — the honest-signal failure in the opposite direction. Flagged rather than pre-emptively cleared, because there is no such route today and a clear on an unreachable route is untestable.

Your docs/http-api.md:720 ##/### note — deliberately not taken. It is pre-existing and unrelated to #766; I would rather not widen a doc-only round into structure this PR does not own.

Two measurement notes carried into the body, both yours: the Running-line splice (a strict line-anchored grep gives 49 on this log; counting running N headers against test result: lines gives the true 50 — the Running count does not survive cargo interleaving), and the standing caveat that this branch is on daab1ef, so 1686 is not comparable with main's 1663.

Base re-checked after main moved to a48760b: git merge-tree --write-tree origin/main origin/fix-766-nav-local still clean (rc 0). Still not merging main in — it would oblige the full-workspace run you just said was not warranted.

[djhenry]

REQUEST CHANGES — round 4, head 2fd3da9. One blocking finding (B9), and it is the same class the round exists to remove: a doc-accuracy round that introduced a new false claim into a tracked file. B6, B7 and B8 are all genuinely fixed and I could not break any of them. Two non-blocking observations (B10, B11), the adjudication of both corrections, and the verification answer you asked for — including a guard that the crate-scoped run missed, which I ran myself.

---

B9 — BLOCKING. "a clear on a route that cannot happen is untestable" is false, and it is the sole stated ground for declining the fix

crates/eqoxide-ipc/src/lib.rs, the new relogin paragraph on local_planner_dead, ends:

…it is flagged here rather than pre-emptively cleared, because there is no such route today and a clear on a route that cannot happen is untestable.

You asked me to test that argument. It does not hold here, for a specific and checkable reason: the clear's natural home is not on the relogin route at all. It is Walker::new — the same constructor that calls LocalPlanner::spawn() and therefore the exact point at which a new worker starts existing. And Walker::new is a function the eqoxide-nav suite already calls directly, three times (crates/eqoxide-nav/src/walker.rs — inside walker_with, inside walker_with_shared, and once more standalone), each time with a NavSlots the caller owns and can pre-populate.

So the test is six lines and needs no relogin route to exist:

let nav: eqoxide_ipc::NavSlots = Default::default();
nav.nav_state.lock().unwrap().local_planner_dead = true;   // a previous worker's death
let _w = Walker::new(nav.clone(), Default::default(), collision, Default::default(), Default::default(), za);
assert!(!nav.nav_state.lock().unwrap().local_planner_dead,
    "a NEW fine worker must not inherit the previous worker's death");

The distinction the paragraph misses: what is untestable is the end-to-end relogin scenario. The clear is not. Placing a guarantee at the point of construction and testing it at the point of construction is ordinary, and it is what this branch has been arguing for all round — B4 was corrected precisely because a debug_assert! was called structural when it is not, and the corrected text names tier-1-by-construction as the thing that would be.

Three things make this worth blocking on rather than waving through:

1. The claim is load-bearing. It is not decoration; it is the whole justification for choosing to flag rather than fix. Strike it and the decision loses its stated basis.
2. The failure it declines to prevent is a lie in the honesty-critical direction, and the paragraph says so itself: "the client would report a dead fine planner it had just replaced." That is the mirror image of connected/last_packet_age_ms are published ONLY by the render loop, which sleeps when the world dies — a dead connection reports connected:true forever #343 — a latched fact with no clearing writer — on a field whose entire justification is that an agent can trust it to report its own health.
3. A tier-1 remedy is available in the same constructor for two lines. local_planner_dead's documented invariant is scoped to a worker ("true once LocalPlanner::is_dead() has been observed; never cleared, because the thread never comes back"). The row outlives a worker only if a second worker can exist. Clearing where the worker is created ties the flag's lifetime to the thing it describes, which makes the bad state unrepresentable instead of commented.

Minimum acceptable fix: delete the "untestable" clause, because it is false. If you want to keep the flag-don't-fix decision, state the real reason (YAGNI on an unreachable route) — that is a defensible argument and this one is not. Preferred fix: clear it in Walker::new with the six-line test above, and the paragraph becomes a note about a hazard that has been closed rather than one that is owed.

---

B6, B7, B8 — attacked, all three fixed, nothing broken

B6 — fixed, and it is the fix I asked for. docs/http-api.md's GET /v1/observe/debug index row now lists nav_local_planner_dead in the top-level group and links to The fine steering tier (which it never linked to) as well as to the new section. The added gloss also carries the two facts a reader of an index row most needs — always-present rather than null-when-healthy, and "poll this, not nav_local, because nav_local retires with the goal." I re-swept by concept and found no other enumeration of that endpoint's fields anywhere in the tree.

B7 — fixed in every place, with the labels correct. The count is now five in all four published surfaces (the latch_local_planner_liveness doc, the B3 test doc, the PR body twice). I re-measured against 2fd3da9 and the five the author names map exactly onto the five returns above let have_path, and the two halts are labelled the right way round — the first is the zone-usability/identity gate, the second is the mid-tick "collision grid vanished" zone_assets_pending halt, and the third is the previously-unnamed if self.apply_plan(reply, gs, goal) { return; }. The ordering mechanism is also correct as written and I verified it independently: LocalPlanner.dead is written at exactly two sites — the failed send in post_if_idle, the disconnected receive in poll — both called only from inside have_path, both above the is_dead() check on the same tick. cancel() cannot set it. So an earlier latch is a tick late by construction. That claim is sound.

B8 — fixed, and more thoroughly than asked. I grepped the five relevant source files for any residual file:line locator tied to a #766 mutation or review finding: zero. Both round-3 sites and the four older rounds-1–2 sites are gone, mutations are named by the assertion they turn RED, and the reasoning for not re-adding them is written into the source docs in both crates. Counts unchanged, and I had already confirmed those counts were right in round 3.

docs/http-api.md:720 ##/### — confirmed, not relitigated. Declining a pre-existing heading-level inconsistency in an unrelated section during a doc round is the right call. Leave it.

---

Verification — you asked me to establish whether a guard reads the touched files. One does, and it was not run

Your specific risk was real. I inventoried every place in the workspace that reads repo text at runtime and checked which of them can see a file this round touched (docs/http-api.md, walker.rs, observe.rs, eqoxide-ipc/src/lib.rs).

Exactly one guard escapes its own crate, and it reads the file you edited:

• crates/eqoxide-net/src/action_loop.rs — const DOC: &str = include_str!("../../../docs/http-api.md");, inside the_documented_idle_reasons_are_exactly_the_ones_the_code_can_publish_725. It is the only include_str! in the workspace that leaves its own crate directory. eqoxide-net was not in the three-crate re-run.

The rest are crate-local and were covered:

• crates/eqoxide-nav/src/steering.rs — the citation scan. Its citation corpus explicitly includes src/walker.rs, which this round edited by 81 lines of comment, and it resolves backticked names against a walk of the whole workspace. This one genuinely could have gone red on a comment-only edit. It is in eqoxide-nav, which was re-run at 215. Covered.
• crates/eqoxide-http/src/guild.rs — walks its own crate's src (so it sees observe.rs) plus eqoxide-command/src. eqoxide-http was re-run at 247. Covered.
• crates/eqoxide-command/src/slot.rs (docs(#770): delete slot.rs's false backstop claim, name the canonical spelling in guild.rs's assert #775's guard) walks only its own crate's src; nothing touched there. eqoxide-net's transport.rs and the root crate's movement.rs include_str! only their own crate's files. The renderer's shader guards are renderer-local. No guard reads eqoxide-ipc/src/lib.rs.

So the crate-scoped run as scoped was not sufficient — it needed a fourth crate. I ran it rather than asking you to.

rbuild <worktree> test -p eqoxide-net --no-fail-fast, on 2fd3da9:

1. Finished `test` profile [unoptimized + debuginfo] target(s) in 11m 52s
2. 2 test result: lines vs 2 running N headers — equal, so no target's output is missing or truncated
3. 0 non-canonical — both lines match the canonical grammar exactly
4. 0 all-zero. One target reads 0 passed; 0 failed; 1 ignored (the doc-test target) — reported separately, since that is not all-zero
5. passed 380 + failed 0 + ignored 1 + filtered 0 = 381; 0 test result: FAILED

the_documented_idle_reasons_are_exactly_the_ones_the_code_can_publish_725 appears as ... ok, and 380 matches the round-3 per-crate figure exactly, so nothing drifted.

Answer to your question: with eqoxide-net added, crate-scoped IS sufficient and a full-workspace run is NOT required for this round. Don't burn the hour. The four crates now cover every guard that can see a touched file, and the guard inventory above is the reusable artifact — the next doc round can check the touched-file list against it instead of re-deriving it.

I have to own my share of this. My round-3 recommendation — "a fourth full-workspace run isn't warranted" — was given without checking whether any guard reads doc text. It happened to land in the right place, but I reasoned from "doc-only" to "cannot change a test outcome" without doing the search that shows it, which is the same step you correctly flagged as unsafe. Your instinct to make me establish it was right and mine to assert it was not.

---

Adjudicating both corrections: the interim draft is not in the record at all

I checked before reading either account, exactly as you asked. The interim draft exists nowhere I can reach it:

• git log daab1ef..origin/fix-766-nav-local — four commits: e73a0e1, ef99227, 1204a0e, 2fd3da9.
• git for-each-ref matching 766/774 — only the local and remote fix-766-nav-local, both at 2fd3da9.
• git reflog show fix-766-nav-local — five entries, the four commits plus "branch: Created from origin/main". No amends, no dropped commit.

So none of the three accounts — the author's, yours, or mine — is verifiable as history. Here is what I could check, and my ruling.

What is verifiable, and holds: the ordering mechanism, in full, as stated above. That is a property of the tree at 2fd3da9 and it does not depend on the anecdote at all.

What is corroborated but not verified: the author's reachability account. I checked it for consistency against the present tree and it survives. A drive_walk tick with an empty path takes decision.post, the post block sets awaiting_first_plan = true because self.path.is_empty(), and the awaiting_first_plan return fires — and that return sits immediately above let have_path, so it preempts any latch placed after advance_cursor. That placement is also the one you independently recall, from a different source than the author. Two parties agreeing on the placement, plus a mechanism that follows from the current tree, is real corroboration.

My ruling. I accept the author's version over my own. My round-3 statement that the interim draft failed on ordering was an inference about a tree I never saw, and I stated it more firmly than my evidence supported — I said the recorded reason and the actual reason "are not the same thing" when what I actually had was an argument about what a top-of-tick latch would do against the current test. I withdraw it. Your self-correction is right in substance; the part worth keeping from it is the caution, not the conclusion.

And the failure mode you named is live in the current text — B10 below.

---

B10 — non-blocking. The test doc states the internals of an unpublished tree as flat fact

crates/eqoxide-nav/src/walker.rs, the B3 test's doc:

That draft pre-forced is_dead() in a loop, called drive_walk with an EMPTY path, and latched from a point above let have_path. It went RED, and it was right to: that tick took one of the FIVE early returns…

Every clause of that is about a tree that is in no commit, no ref and no reflog. It reads as a record; it is a reconstruction. And it is the sentence that resolves a three-way disagreement about what happened — which is the worst place for an unmarkable claim, because a reader who wants to check the adjudication is the reader most likely to try.

I am not asking for it to be deleted, and I am not applying a rule that only committed trees may be described — the mutation claims all over this branch are measurements of uncommitted trees too. The difference is that those come with a reproduction recipe. This one now does as well (pre-force is_dead(), empty path, latch after advance_cursor), so it is defensible. What it lacks is the marking this branch already applies elsewhere — observe.rs says "and I did not run it" about its un-run shape check, and that discipline is exactly right.

Suggested fix, one clause: "an unpublished draft — reconstructed, not recoverable from the branch; what is checkable against the tree is…". Then the two mechanism items, which stand on their own.

B11 — non-blocking. Body and source now tell different stories about the same run

The PR body still reads "the reason I recorded was the shallower of the two" and "the mechanism I recorded … was the shallower one", framing reachability as the wrong answer the author had given. walker.rs now says reachability is precisely why that run went red, with ordering as the deeper defect of the placement. Those are reconcilable but they are not the same story, and the body is what a reviewer reads first.

Non-blocking because the body does not ship to main. Worth a sentence anyway, since B7 was itself a finding about a claim fixed in some published places and not others.

---

Squash message

Held until the next round — I will hand you a written subject and body when I approve, and I will verify the carry list rather than relay it. One thing I can check now: whatever you write, do not let local_planner_dead or nav_local_planner_dead be line-wrapped or hyphen-broken in the body. Both are the identifiers someone will grep history for, and a wrapped identifier is un-greppable — that is what cost us on #773.

---

Summary

Round 4 does what it set out to do on B6, B7 and B8 — all three are fixed, the five early returns are correctly counted and correctly labelled, the ordering mechanism is sound, and every locator is gone. Blocking on B9: the round added a false claim to a tracked file, and that claim is the only stated reason for leaving an honesty-direction hazard open when a two-line tier-1 fix with a six-line test is available in the same constructor. Fix B9, take or leave B10 and B11, and no further test run is needed beyond the four crates — eqoxide-net is measured and green above.

[djhenry]

Round 5 — 76fcdda. B9 taken as a behaviour change, B10/B11 as one reconciled account.

Thanks for B9. It is the finding I'd least like to have earned and the one most worth having: a round whose entire purpose was removing false claims from tracked files added one, and the false claim was the sole basis for declining a real fix.

B9 — fixed, and your distinction is the whole thing

"A clear on a route that cannot happen is untestable" conflates two claims. The scenario is untestable; the clear is not, and the clear is what carries the guarantee. Walker::new is exactly the right home — it is the constructor that calls LocalPlanner::spawn(), it takes caller-owned NavSlots, and this suite already calls it directly.

• Walker::new now clears local_planner_dead as it spawns the worker. The latch's lifetime is the worker's, not the shared row's.
• a_new_walker_does_not_inherit_a_previous_workers_death_766 builds a Walker over a deliberately dirty row and asserts it comes back clean.
• The untestability sentence is deleted. I did not reword it — your point that a replacement re-instantiates the finding is borne out by this branch's own history.
• docs/http-api.md was updated too: the field's "never returns to false" line was true of the process but not of the field, and it now says what actually clears it and that over a running client it is one-way.

M8, run, across all four crates:

---- walker::tests::a_new_walker_does_not_inherit_a_previous_workers_death_766 stdout ----
#766 B9: `Walker::new` has just spawned a NEW `LocalPlanner`, which is alive. Leaving the previous
worker's latch standing would publish `nav_local_planner_dead: true` for a thread that is running
fine, and it would never clear — the client asserting a permanent fault it had itself just repaired

test result: FAILED. 215 passed; 1 failed; 16 ignored; 0 measured; 0 filtered out

eqoxide-http 247, eqoxide-ipc 37, eqoxide-net 380 — all unmoved under the mutation. Reverted from an md5-verified copy-aside; nav back to 216 passed; 0 failed.

I am not claiming this changes any live path. Walker::new runs once per process and M8's blast radius of one assertion is the honest measure of that. It is a structural guarantee about the flag's lifetime, which is what the hierarchy asks for and what a paragraph could not give.

B10 / B11 — reconciled rather than patched

Both source docs now mark the uncommitted draft as recollection, not history, using this branch's existing un-run convention rather than a new hedge, and the argument that replaces it rests on the present tree: an empty path returns at awaiting_first_plan immediately above let have_path (reachability), and dead is only ever written inside have_path (ordering, decisive). The PR body now tells that same single account.

On the attribution: thank you for checking the reflog and for withdrawing your own account rather than letting it stand. I am not re-asserting mine as history either — I can't reproduce the draft any more than you can. What I'll defend is the property of the tree, not the story about a run neither of us can re-run.

One thing your guard inventory caught that I hadn't

steering.rs's citation scan went RED on my first round-5 run: I cited a_dead_fine_planner_stays_visible_after_the_goal_is_retired_766 in a doc comment without adding it to walker.rs's _cited guard array. Found by the guard, not by me. Added.

Figures — four crates, blast radius re-derived rather than inherited

You were right that crate-scoped-as-originally-scoped was not enough, and I did not reuse the set on your word alone: include_str! of a doc file occurs exactly once in the tree (the -net guard), eqoxide-nav's citation scan reads walker.rs as a corpus file, and -http/-ipc are the publication path.

    Finished `test` profile [unoptimized + debuginfo] target(s) in 11m 22s

• 8 test result: lines vs 8 running N headers, 8 expected
• 0 non-canonical
• 1 all-zero — field-anchored; a substring grep for 0 passed also matches 380 passed and reports 2
• 882 + 0 + 19 + 0 = 901, and the header Ns sum to 901
• 0 test result: FAILED, 0 failures: blocks

Per-crate: nav 216 (was 215), http 247, ipc 37, net 380. +1, accounted for — the B9 test. Tree md5-verified identical before and after the run.

eqoxide-command was NOT re-run, and I'm flagging it rather than leaving it implicit: the -ipc edit is doc-comment-only and -command's two source-scanning guards read its own src/. That is inference, not measurement — the same shape as the gap that produced this finding, so it gets said out loud.

Carried forward unchanged: the Running-splice caveat (count running N, never Running <binary> — 49 vs 50 on the round-3 log), and that the round-3 workspace 1641 + 0 + 45 + 0 = 1686 sits on base daab1ef and is not comparable with main's 1663. Round 5 would make it 1687; that is arithmetic, not a measurement, and is not offered as one.

merge-tree against main (a48760b) is clean, rc 0. check-no-local-detail.sh OK, body and this comment hand-scanned.

[djhenry]

REQUEST CHANGES — round 5, head 76fcdda. The code is right. Walker::new's clear is correct, the B9 test is well-formed, B10/B11 are properly reconciled, and I reproduced every figure. Two blocking findings, both doc claims, both in the same two files, and both fixable in one edit each: B12, the fix left the field's own defining sentence asserting the opposite of what the fix does — inside a single doc comment; and B13, the new docs/http-api.md paragraph you asked me to attack contains a false "never" and an inverted causal claim. Answers to both of your specific presses are below, each settled by measurement rather than inheritance.

---

B12 — BLOCKING. The fix contradicts the field's own defining paragraph, in the same doc comment

crates/eqoxide-ipc/src/lib.rs, first paragraph of local_planner_dead's rustdoc:

SESSION-scoped, latched: the fine worker thread has died … true once LocalPlanner::is_dead() has been observed; never cleared, because the thread never comes back — recovering it needs a client restart.

Last paragraph of the same doc comment:

Latched for the life of a WORKER, and cleared where one is spawned … So Walker::new clears this flag as it spawns the worker.

Two flat contradictions in one comment: never cleared against Walker::new clears this flag, and the bold SESSION-scoped against the bold for the life of a WORKER. A reader who stops after the paragraph that defines the field — which is most readers, and which is the paragraph rustdoc renders as the summary — gets the pre-fix answer.

This is not a nitpick about staleness, it is the exact failure mode of B7 recurring: you fixed the identical sentence in docs/http-api.md ("never returns to false" → rewritten) and in the tail of this comment, and left the lead. Your own PR comment says "the field's 'never returns to false' line was true of the process but not of the field" — that reasoning applies word-for-word to the rustdoc lead, which still carries the same sentence in its original form. The concept grep is what finds it; a grep for the docs/http-api.md phrasing does not.

Second instance, same concept, same round. crates/eqoxide-nav/src/walker.rs, the opening line of the new B9 test's own doc:

local_planner_dead never clears once set, which is right for a thread that does not come back — but "never clears" and "outlives the thread it describes" are different claims…

That is the doc of the test that proves it clears. It reads as rhetorical setup, and it may be intended as the pre-fix framing, but it is an unqualified present-tense assertion opening the very test that falsifies it. One word ("used never to clear", or "does not clear on any nav route") fixes it.

Fix: rewrite the lead paragraph to state the actual lifetime, and re-run the concept grep — never clear, never returns, does not come back, client restart, session-scoped — across crates/ and docs/. I found no other live contradiction (eqoxide-http/src/lib.rs's "never cleared once set" is model_sync_dead, a different field; retire_to_idle's "latched because the thread does not come back" is about not clearing there, which is still true), but the sweep is the point, not my result.

---

B13 — BLOCKING. You asked me to attack the new contract claim. It has a false "never" and an inverted "so"

docs/http-api.md:

The one thing that clears it is the construction of a new fine worker, which today happens exactly once per process, at startup: the flag is scoped to the worker it describes, not to the process, so it can never outlive the thread it is reporting on. In practice, over a running client, that means it is one-way.

Your question, answered directly: "one-way over a running client" is true today, and it is true of the process, not of the field. The new clear does not make it true — as you say yourself, it is a no-op on a single-Walker process. The one-way property rests on there being exactly one Walker per process, which is precisely what it rested on before the fix. The conclusion is right; the "so" attributes it to the wrong thing.

And the "never" is false. The fix covers the birth end of the worker's life and nothing covers the death end:

• There is no impl Drop for Walker and no impl Drop for LocalPlanner anywhere in eqoxide-nav, -net or -ipc. Nothing invalidates the flag when a worker dies without a replacement.
• That is a routine route, not a hypothetical. src/main.rs wraps the net thread in run_net_thread, whose own comment says it writes a terminal reason "on EVERY exit path (panic, fatal Err, clean return)". On every one of those, ActionLoop → Walker → LocalPlanner is dropped and the worker thread exits — while the shared row, which the HTTP surface holds its own Arc to, keeps publishing nav_local_planner_dead: false.

So the false value does outlive the thread it reports on. That is #343's shape in the healthy direction — a value outliving the thing it describes — which is the mirror of the exact hazard this paragraph cites as its own justification, and the one you cite in Walker::new's comment.

Stating the mitigation fairly, because it matters to severity: net_thread_dead is non-null on precisely those paths, and the endpoint discloses the whole payload as a frozen final snapshot when it is. An agent is warned. This is a doc overreach, not a live lie, and I am not asking for a Drop-time writer — a stale false behind an explicit net_thread_dead is disclosed, and adding a clear on teardown would be its own untested route.

What I am asking for is that the sentence stop claiming a property the field does not have. This branch has now blocked twice on unqualified universals of exactly this shape — B7's "returns early in three places" and B9's "a clear on a route that cannot happen is untestable" — and this one is newly introduced, in the honesty surface, in the round that fixed the last one.

Suggested shape: say what is true and stop there. "Over a running client this field is one-way: nothing in the process constructs a second fine worker, so nothing clears it. The clear in Walker::new exists so that if anything ever did, the new worker would not inherit the old one's latch. Note that a false reading is only meaningful while net_thread_dead is null — once the net thread has ended, the worker is gone and this row, like the rest of the payload, is frozen." That last clause is worth its own line: it is the one thing an agent actually needs and the paragraph currently implies the opposite of it.

While you are in that paragraph: the section heading and the index-row gloss both still say session-scoped, which is now the label the field's own doc argues against. Defensible as the agent-facing word — one worker per process, so the scopes coincide — but pick one story and let both surfaces tell it.

---

Verified and could not break

• The B9 fix is correct. Walker::new clears then spawns; the lock is a statement-scoped temporary. Three writers of the field exist and they compose: the latch sets true at discovery, Walker::new sets false at construction, retire_to_idle keeps. I checked the one way the "the one thing that clears it" claim could be false in production — a whole-row replacement through NavStatus::from(&str), which sets local_planner_dead: false — and the only two such sites (eqoxide-net/src/action_loop.rs, both *nav.nav.nav_state.lock().unwrap() = "…".into();) sit past that file's #[cfg(test)] boundary. No production path replaces the row. The claim holds.
• The untestability sentence is genuinely DELETED, not reworded. Concept grep (untestab, cannot happen is, pre-emptively cleared, no such route today) across crates/, src/ and docs/ leaves exactly one hit in the branch's files, and it states the correct distinction — "what the missing route makes untestable is the end-to-end relogin scenario, not the clear." That is the finding, not a survival of it.
• The B9 test is well-formed. It asserts its PREMISE (the row starts dirty) before measuring, so it cannot pass against a field that was false all along — the failure mode that would make M8 meaningless.
• B10 — the hedge is real and in both places. latch_local_planner_liveness and the B3 test both now mark the draft as recollection, both name the reason (no commit, ref or reflog), and both put the weight on the present tree. Neither re-asserts a reachability story as history: the B3 test's replacement text says "an empty path returns at awaiting_first_plan" as a property of the tree, which is checkable and which I checked.
• B11 — body and source now tell one account. I read the PR body's placement section against both source docs; the hedge, the five early returns, and the ordering-decisive/reachability-additional split match across all three.
• The steering citation guard bit, and it bit you, not me. Adding the test to walker.rs's _cited array is the right fix and the comment credits the guard honestly. Green in my run.

---

Press 1 — eqoxide-command scope, re-derived and then measured

Derived independently, from the tree rather than from either of your accounts:

• crates/eqoxide-command/Cargo.toml declares eqoxide-core and eqoxide-ipc only, and its own layering comment names nav in the exclusion list — so Walker::new cannot reach it. Every Walker occurrence in the crate is inside a comment.
• The round-5 -ipc delta is 100% /// lines, so nothing behavioural crosses that edge.
• Its only file-reading guards are the two in slot.rs, both reading env!("CARGO_MANIFEST_DIR")/src — its own crate, untouched this round. It contains no include_str! at all, and the workspace's only cross-crate include_str! is still -net's.
• No new NavStatus field this round, so no E0027 reach.

So it is out of the radius by derivation. I ran it anyway rather than stopping at the derivation, because that is the step both of us skipped last time: eqoxide-command 47 passed, 0 failed — unmoved. Your inference was right; it is now a measurement. The bonus is that every_command_side_retirement_retires_the_fine_tiers_verdict_766 — the ninth #766 test, the one you could not report — is in my log as ... ok, so all nine appear green in a single run.

Press 2 — the all-zero count. Your method and your figure are both right

Confirmed on my own log, both ways:

• Field-anchored (0 passed; 0 failed; 0 ignored): 2 on my five-crate log.
• Naive substring 0 passed: 5 — it matches 380 passed, and it also matches two targets that report 0 passed; 0 failed; 2 ignored and 0 passed; 0 failed; 1 ignored, which are well-formed but not all-zero.

So the substring method over-counts by more than the one case you named, and the field-anchored count is the only defensible one. Your figure of 1 is right for your four-crate set, and my 2 differs from it by exactly the empty doc-test target eqoxide-command adds.

My independent figures — and they reconcile with yours exactly

rbuild <worktree> test -p eqoxide-nav -p eqoxide-http -p eqoxide-ipc -p eqoxide-net -p eqoxide-command --locked --no-fail-fast, on 76fcdda:

1. Finished `test` profile [unoptimized + debuginfo] target(s) in 8m 32s
2. 10 test result: lines vs 10 running N headers, 10 expected (5 crates × lib + doc-test)
3. 0 non-canonical — all 10 match the canonical grammar
4. 2 all-zero, field-anchored (see above)
5. passed 929 + failed 0 + ignored 19 + filtered 0 = 948; 0 test result: FAILED, 0 failures: blocks

Per-crate: nav 216 / 16 ignored, http 247, ipc 37, net 380, command 47.

Reconciliation with your four-crate run: 948 − 47 = 901; 10 − 2 targets = 8; 2 − 1 = 1 all-zero; ignored 19 in both. Every one of your figures reproduces exactly. Round 5's +1 on nav is the B9 test and nothing else moved in any of the five crates.

Not a workspace run, and I am not offering it as one — five crates, named. The round-3 1686 on base daab1ef remains the last workspace figure and remains not comparable with main's 1663. Your refusal to present 1687 as a measurement is the right call.

---

Judging the squash guidance rather than adopting it — it under-scopes in three ways

I checked the guidance against the five commit bodies. The carry/do-not-carry list is right as far as it goes, and it misses three things a default squash would ship into main:

1. 2fd3da9's body carries the untestability claim — "today and a clear on an unreachable route is untestable" — which is the newest false claim on this branch and the one B9 was about. The standing list names e73a0e1's pending claim, its stale counts, and ef99227's 1684, but not this one. It must not ship.
2. The pending claim is in three commit bodies, not one — e73a0e1, ef99227 and 1204a0e all restate it. "Drop e73a0e1's pending claim" under-scopes by two commits.
3. 2fd3da9 also carries the "three places" framing, superseded by five.

Everything else I agree with: carry ef99227's retraction paragraph (post-squash it is the only surviving record of the B1 correction), and present no total as the merged tree's figure. I will hand you a written subject and body when I approve — the general rule the above implies is that the squash body should be written from the final state and cite retractions explicitly, not assembled from commit bodies at all.

---

Summary

The code landed this round is right and I could not break it: the clear is correctly placed, correctly scoped at construction, correctly tested with a premise assertion, and the production claim that nothing else clears the row survives the one attack that could have falsified it. B10 and B11 are properly reconciled across all three surfaces. Both of your presses came back in your favour, and both are now measurements rather than inferences — including the ninth #766 test, which is green in my log.

Blocking on B12 and B13: the round fixed the claim in docs/http-api.md and in the tail of the rustdoc but left the paragraph that defines the field asserting "never cleared", and the replacement contract paragraph introduces a false "never" of its own plus a causal "so" the fix has not earned. Both are one-edit fixes in files this round already touches. Fix them, sweep the concept rather than the sentence, and I expect to approve.

[djhenry]

Round 6 pushed — d56f069

Both blocking findings were mine, both were introduced by round 5, and both are fixed. Doc, comment and assert-message only; no behaviour change.

B12 — the sweep found 24 lines where I would have enumerated 3

You were right that an enumeration is not a completeness check, and the gap is bigger than I expected. Terms swept over crates/, docs/ and src/: never clear / never cleared / never clears / does not come back / never comes back / client restart / session-scoped / SESSION fact / session fault / one-way / outliv / rest of the session. 101 matching lines, all read; 24 carried the old story and are removals in this commit's diff. The three I would have named were the doc lead, the B9 test's opening, and the docs/http-api.md sentence.

Eight of the 24 are assertion messages and test-doc headings. A grep of the field name cannot reach those — they name the concept and never the field. That is the part I would not have gotten to by re-reading, and it is the second time on this branch that grepping the concept beat grepping the name (B6 was the first); this is the first time it changed the finding rather than confirming it.

The rule I applied, written down so it is checkable rather than a taste call:

• agent-facing (docs/http-api.md, the JSON nav_local.state glosses) keeps session-scoped — accurate from outside, since exactly one fine worker is built per process — and the section now says why the two spans coincide instead of leaving the reader to reconcile it. The ### anchor is unchanged, so B6's index link still resolves;
• client-internal (rustdoc, comments, test docs, assert messages under crates/) says worker-scoped, which is the rule the code enforces;
• every surface that uses the session framing points at the other one, in both directions.

Left standing deliberately, and flagged because a re-run of the sweep lands on them: the consequence statements — "steering has degraded to the coarse 8 u route for the rest of the session", "recovering it needs a client restart". True of today's process, not claims about the field's lifetime, and exactly what an agent needs to read. Recorded as a decision, not an oversight.

B13 — the sentence is deleted, no teardown writer

I verified both premises myself before writing the correction: no impl Drop for Walker / LocalPlanner / ActionLoop anywhere in the workspace, and run_net_thread writes a terminal reason on all four exit arms. So the claim is false, in the healthy direction, which is #343's shape.

Three prose changes, no code: the false sentence is gone rather than narrowed; "one-way over a running client" is now attributed to the process and noted as equally true before the clear existed, so the causal "so" is dropped; and a false reading is documented as meaningful only while net_thread_dead is null, with the check spelled out. local_planner_dead's doc gains a closing paragraph telling a client developer the opposite of what round 5 implied, including that no teardown writer was added and why.

Your framing — a correct conclusion with an invented mechanism attached — is the fourth instance of that on this branch, so it is named as a pattern in the field doc rather than fixed as an instance.

Figures

Standing four crates, re-derived not inherited (round 6 touches walker.rs, eqoxide-ipc/src/lib.rs, observe.rs, docs/http-api.md — all inside the set):

    Finished `test` profile [unoptimized + debuginfo] target(s) in 15m 06s

8 result lines vs 8 headers (8 expected) · 0 non-canonical · 1 all-zero · 882 + 0 + 19 + 0 = 901 = header sum · 0 FAILED · 0 failures: blocks. Per crate 216 / 247 / 37 / 380 — identical to round 5 in every figure, which is what a doc round should look like. The four edited files have mtimes at 09:49–09:56 and the log was created at 10:16, so it describes this tree.

All-zero rule, adopted as you suggested: field-anchor all three fields, never substring. On this log the naive 0 passed gives 4 and the anchored form gives 1 — the extras being 380 passed plus two well-formed lines with a nonzero ignored. Your five-crate log gave 5 vs 2. Different numbers, same mechanism, which is the argument for the rule.

All nine #766 tests green, in two logs, and the second is yours. I cited your eqoxide-command run (47 passed, 0 failed, unmoved) rather than re-deriving it, and recorded that the crate is out of radius by derivation: its Cargo.toml declares core+ipc only and names nav in its exclusion list, the ipc delta is 100% /// lines, its two guards read only its own src/, and it has no include_str!. Your five-crate figures at 76fcdda reconcile with mine field by field: 948 − 47 = 901, 10 − 2 = 8, 2 − 1 = 1, 19 ignored in both.

Squash guidance — corrected for all three under-scopings

Rewritten in the commit body and the PR body, from the final state of the tree rather than assembled from commit bodies, per your rule. Do not carry: 2fd3da9's "a clear on a route that cannot happen is untestable" (the newest false claim, and it was not on the old list); the pending claim, which is in three bodies — e73a0e1, ef99227, 1204a0e — not one; 2fd3da9's superseded "three places"; and this round's two. Do carry ef99227's retraction paragraph. No per-round total is presented as the merged tree's.

merge-tree --write-tree origin/main origin/fix-766-nav-local rc 0 against main at a48760b. scripts/check-no-local-detail.sh OK.

[djhenry]

REQUEST CHANGES — round 6, head d56f069. Two new blocking findings, B14 and B15. B12 and B13 are both fixed and I could not break either replacement. The no-behaviour-change premise holds. Both new findings are, again, in prose this PR itself wrote — and B14 is the same shape as B12, one round later, in the agent-facing surface.

---

Premise first: no behaviour change — VERIFIED

git diff 76fcdda..d56f069 = 4 files, +110/−52. Filtering the .rs half to non-comment lines gives 22 changed lines, and every one of them is an assertion-message string literal. I enumerated all 22; no expression, no control flow, no signature, no field. The four rewordings that carry meaning are "The session field" → "The liveness field", "must record it on the SESSION-scoped row … has permanently degraded … and the thread does not come back" → "must record it on the shared row that outlives the goal … has degraded … and THIS thread does not come back", and "the thread does not come back, so the fault does not heal" → "a zone change does not replace the fine worker, so the dead one is still the live one and the fault has not healed". Everything else in the round is ///, // or docs/.

B12 — fixed

The field's rustdoc lead is now **The fine worker thread has died — latched, and scoped to that WORKER**, and the "cleared by nothing on any nav route … the one writer that clears it is Walker::new" sentence is in the same paragraph as the scope claim rather than four paragraphs below it. I re-read the whole comment for a second lifetime and there isn't one. The Latched for the life of a WORKER paragraph and the Known limit paragraph now agree with the lead.

B13 — fixed, and the two replacements survive attack

I checked the replacements separately, as asked.

• "Over a running client this field is one-way … a property of the process, not of the field." True, and I verified the mechanism rather than the sentence. LocalPlanner::spawn is reached only via Walker::new; the sole production Walker::new is in ActionLoop::new; the sole production ActionLoop::new is in run_login_flow, inside the Ok(…) arm of the retry loop, which unconditionally return Ok(()) after run_gameplay_phase — and the slots are moved into it, so a second pass round that loop would not compile anyway. run_login_flow itself is called once, from ServerModel::run. An independent comment in login.rs reaches the same conclusion for a different field ("no code path re-enters login after gameplay today"), which is corroboration I did not have to take from this PR.
• "A false reading is only meaningful while net_thread_dead is null." True. No Drop for Walker, LocalPlanner or ActionLoop anywhere; run_net_thread writes a terminal reason on every exit arm; the HTTP surface holds its own Arc and goes on publishing the frozen row.
• Do they jointly imply the deleted claim? No — the second one contradicts it, explicitly and by name ("do NOT read this field as 'the flag can never outlive the thread it reports on': a stale false after teardown is exactly that"). There is no path from the pair back to the deleted sentence.

I also probed the one route that would have produced a false with no worker alive and no teardown: --testzone, which skips run_login_flow entirely, so no Walker is ever built and the field publishes its Default false. That is not a hole — main.rs publishes an explicit net_thread_dead reason up front in that mode, so the "check net_thread_dead first" rule the new doc states is exactly what covers it. Worth knowing that the rule is load-bearing in a second, unrelated case.

---

B14 (blocking) — permanently degraded survived the sweep, in four places, one of them the agent-facing doc

Your instruction was not to accept "24 found, 24 fixed" as a completeness claim. It is not complete, and the missing term is one the author's own round-6 edit identifies.

permanent / permanently is absent from the 12-term sweep list. This PR adds seven lines containing it and removes none:

where	text
docs/http-api.md	"could not learn that its steering had permanently degraded to the coarse 8 u route"
crates/eqoxide-http/src/observe.rs (production comment)	"can still see that its steering has permanently degraded to the coarse 8u route"
crates/eqoxide-http/src/observe.rs (test doc)	"a latched client fault meaning steering has permanently degraded to the coarse 8 u route"
crates/eqoxide-nav/src/walker.rs (test doc)	"a latched client fault meaning steering has permanently degraded to the coarse 8 u route"
crates/eqoxide-ipc/src/lib.rs	"would report a fault it had just repaired, permanently — #343's shape"
crates/eqoxide-nav/src/walker.rs	"permanently dead: #343's shape … a lie in the honesty-critical direction"
crates/eqoxide-nav/src/walker.rs (assert message)	"permanent fault it had itself just repaired"

The bottom three are correct and are the reason this is a finding rather than a quibble: they use the word to name the lie a second worker would tell. The top four assert that same permanence as fact. The PR therefore says, in the same four files, both that the degradation is permanent and that "permanent" is what it would be lying about.

Three sharper points:

1. The author's own round-6 edit is the standard being failed. 76fcdda..d56f069 deletes exactly this word from one walker assert message — "steering has permanently degraded to the coarse 8u route" → "steering has degraded to the coarse 8u route". So "permanently" was recognised this round as carrying the old story, corrected in one of five factual uses, and left in the other four.
2. The observe.rs instance is B12's shape at six lines' range, inside one comment block this PR added: the block opens (… the field's lifetime is the fine WORKER's, not the process. docs/http-api.md keeps the agent-facing "session-scoped" name and says why) and six lines later says permanently degraded. One comment, two lifetimes — which is the literal wording of the round-5 finding.
3. In docs/http-api.md it is self-contradictory within one section. Line 888 reads "recovering it needs a client restart"; line 915 reads "permanently degraded". A restart recovers it, so it is not permanent. This is the honesty surface an agent reads, and it is the one place where "session-scoped" was defended as accurate — "permanently" is not "session-scoped", it is strictly stronger, and it is false in exactly the way the section's own earlier sentence says.

This also answers the completeness question directly: one term the sweep did not contain yields four survivors, three of them on lines this PR added. A twelve-term list that missed the word the author itself deleted this round is the same shape as the enumeration it replaced. The fix is small; the point is that "24 found, 24 fixed" should not be restated.

Suggested wording that keeps the true content: "degraded to the coarse 8 u route, and nothing on any nav route recovers it" — a statement about writers, which is what the tree actually guarantees, rather than a statement about time.

B15 (blocking) — this PR introduces two unbalanced doc spans, in the one touched file no guard reaches

You asked me to check backtick parity main-vs-branch and to derive a guard's reach by running it. I did both, and this is the #785 shape recurring on this PR.

Measured, against the true merge base daab1ef (not main — main has moved past the branch point, and diffing against a48760b mixes in other PRs' edits to observe.rs):

file	daab1ef	d56f069
crates/eqoxide-ipc/src/lib.rs	12	12
crates/eqoxide-nav/src/walker.rs	0	0
crates/eqoxide-http/src/observe.rs	4	6

The two new ones are a single code span broken across a line wrap in observe.rs:

/// same cloned `NavStatus` and passed through exactly one filter — `.filter(|l| l.state !=
/// "threaded")` — so an UNHEALTHY verdict reaches the response body verbatim, and an unhealthy

cargo doc renders the line break inside the span, and per #773 the wrapped fragment is un-greppable in exactly the way that has already cost this repo once.

Reach control, run rather than read. unbalanced_doc_spans is called from one place, inside every_doc_comment_test_citation_resolves_and_is_listed_in_a_guard, over the cited_in list only — steering.rs, walker.rs, collision.rs, tests/walker_sim.rs. observe.rs and ipc/lib.rs are outside it. So I added observe.rs to cited_in in my own worktree and ran the real guard:

observe.rs:1414: a code span opens on this line and closes on another. …
observe.rs:1415: …
observe.rs:2965: …
observe.rs:2966: …
observe.rs:3813: …
observe.rs:3814: …
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 231 filtered out

Six hits, matching my count exactly, including both new lines. Restored by copy-back, md5 re-verified (dac4b3b0…, identical), worktree clean.

Two consequences worth separating. The defect is two wrapped spans, cheap to fix. The finding is that a doc-heavy PR across four crates is parity-checked in one of them, and this round's largest doc rewrite (ipc/lib.rs, 55 lines) is unchecked by construction — its 12 pre-existing odd-parity lines are all wrapped prose, so it happens to be clean, but nothing made that true. I am not asking for the guard to be widened in this PR; I am asking for the two spans, and noting the gap so it is a decision rather than an accident.

---

Non-blocking

N1 — "exactly one fine worker per process" is load-bearing for four sentences and pinned by nothing. You asked me to test the "true of today's process" judgment. The judgment is correct today — I verified the mechanism above and could not find a second construction site. But the decay is silent in the strongest sense: there is no guard, no test and no E0027-style net over the single production Walker::new. The claim exists only as prose, in three places. And the B9 test itself constructs a second Walker, so it cannot be the thing that goes red. If this repo wants that premise loud, the natural shape is the one it already uses elsewhere — a source scan asserting exactly one non-#[cfg(test)] Walker::new in the tree, which would fail the day an in-process relogin lands and force these four sentences to be revisited. Not for this PR; worth an issue.

N2 — the do-not-carry list under-scopes a fourth time, and this is the third round in a row. Checked against the actual commit bodies. The list correctly names 2fd3da9's untestability claim, 2fd3da9's "three places", the pending claim in e73a0e1 / ef99227 / 1204a0e, and round 6's two. It does not name 1204a0e's body, which asserts "a latched, session-scoped client fault meaning steering has permanently degraded to the coarse 8u route" and "Fixed with a new session-scoped NavStatus::local_planner_dead". That is the identical framing the round-6 list excludes when round 5 wrote it — it is simply older. Under the author's own overriding rule (write the body from the final tree) this is moot, and I follow that rule, so it is a note about the list rather than about what will land.

Verification — my own figures, on my own worktree at d56f069

Four crates, --locked --no-fail-fast, remote builder, judged by log content not by exit code:

• Finished \test` profile … in 5m 56s; **0** lines beginning error`
• 8 test result: lines vs 8 running N headers vs 8 expected targets
• 0 non-canonical result lines
• 1 all-zero, field-anchored on all three fields — and naive 0 passed gives 4. This reproduces the author's figure and its two spurious classes independently: 380 passed contains the substring, and two targets are empty-but-not-all-zero (0 passed; 0 failed; 2 ignored and … 1 ignored). Third independent confirmation of the anchored rule on this branch. My own r5 five-crate log gave naive 5 / anchored 2, different numbers, same effect — it is a property of the grep.
• 882 + 0 + 19 + 0 = 901, and the running N headers sum to 901
• 0 FAILED, 0 failures: blocks
• Per crate: eqoxide-http 247, eqoxide-ipc 37, eqoxide-nav 216, eqoxide-net 380 — identical to round 5 in every figure, as claimed
• mtime check: the four touched sources are stamped 10:23, my log 10:31. The log describes this tree.

git merge-tree --write-tree origin/main origin/fix-766-nav-local → rc 0 against a48760b. check-no-local-detail.sh → rc 0. My worktree and the shared checkout are both clean (git status --porcelain empty in each).

Corpora the term list may have missed — swept, one hit

• PR title — clean. No lifetime claim in it at all; it is a statement about retirement, which is accurate.
• Issue nav_local survives a zone change: the previous zone's fine-tier verdict is published beside nav_state: idle #766 title / body / comments — one hit, "a per-zone fact outliving its zone", which is about nav_local and is correct.
• Commit bodies — the one hit is N2 above.
• Review comments — nothing carrying the old story that is not already retracted in the PR body.
• Terms I used that the author did not: permanent*, forever, irreversib*, sticky, until restart, for the life of, never heals, does not heal, unrecoverab*, once set, stays true, process-scoped, per-process, terminal state, for good, cannot be undone. All of the surviving non-permanent hits are about other fields (the COARSE planner, net_thread_dead, transport session lifetime) and are correct in context — I checked them one at a time rather than counting them.

---

Both blocking items are text. The code has now been attacked across three rounds by me and has not moved in this one; I have nothing against it. What keeps failing is the prose, and specifically the completeness claims about the prose — B14 is the third consecutive round in which a stated enumeration was the defect. That is the pattern worth naming in the squash body, and I will hand a written subject and body on the next round if these two are closed.

[djhenry]

Round 7 pushed — ad3c5a0

Both blocking findings were mine, both were in prose round 6 wrote, and both are fixed. Doc and comment only — zero non-comment lines changed.

B14 — you are right, and the fix is the method, not the term

permanent* was absent from my list, and it was the word my own round-6 diff deleted from a walker assert message. Four survivors, three on lines round 6 added, including docs/http-api.md contradicting itself 27 lines apart ("recovering it needs a client restart" / "permanently degraded") on the one surface where session-scoped was defended as accurate. All four now use your suggested shape — "degraded to the coarse 8 u route, and nothing on any nav route recovers it" — a claim about writers, checkable against retire_to_idle and Walker::new, where "permanently" was checkable against nothing. The three uses that name the lie a second worker would tell stay, since that is the whole reason the word is right there and wrong elsewhere.

I did not add permanent* to the list. The list was keyed on the predicate — the open-ended set of English phrasings for "this outlives the worker" — which cannot be enumerated and decays with every new author. Its failure is now measured twice on this PR: a field-name grep missed 21 of 24, a twelve-term predicate list missed 4 more.

Round 7 sweeps by SUBJECT, which is a closed set. Anchors are the field and its aliases as they occur in the tree — local_planner_dead, nav_local_planner_dead, LocalPlanner, fine planner, fine-planner, fine worker, fine tier, FINE 2u, planner_dead, coarse 8 ?u — over crates/, docs/, src/: 224 anchor lines, ±6-line window, 1096 prose lines. Whatever a future author calls the permanence, they still have to name the thing.

Validated against a corpus I did not choose — your sixteen terms. Running your list plus my original twelve tree-wide: 431 hits, 36 inside the subject window, 395 outside. I read all 36. Every one is either about a different field (the COARSE planner_dead, net_thread_dead, transport lifetime, the traversability design note) or is one of this round's four corrections. Your vocabulary found nothing inside the subject that the subject sweep did not already contain — which is the reach control the term list never had. I am not restating a "found N, fixed N" figure; the claim is the method and its control, both re-runnable from the commit body.

B15 — fixed, and the guard run reproduces your result

observe.rs is back to the merge base's 4 (daab1ef 4 → d56f069 6 → now 4). The span is on its own line with a comment saying why, so the next reflow does not undo it. The remaining pairs (1418/1419, 3820/3821) are pre-existing and out of scope.

Reach proved by running, per your standard: steering.rs copied aside (md5 dac4b3b0… — same file you measured), observe.rs added to cited_in, real guard run → exactly four span hits at the two pre-existing pairs, 0 passed; 1 failed; 0 ignored; 0 measured; 231 filtered out; restored by copy-back, md5 re-verified identical. No git stash, no git checkout.

Your second consequence is recorded in the PR body as a decision rather than an accident: this branch's largest doc rewrite (ipc/lib.rs) is parity-unchecked by construction and happens to be clean. Not widened here.

N1 → #787

Filed as #787 (agent-honesty, severity:low), with your suggested shape — a source scan asserting exactly one non-#[cfg(test)] Walker::new( — plus the two notes that follow from your own analysis: exclude #[cfg(test)] or the B9 test defeats it on day one, and run the scanner rather than deriving its reach by reading. The three doc sites carrying the premise now cite #787, so the sentences and the issue point at each other.

N2

1204a0e added to the do-not-carry list — it carries both corrected scope words plus B14's, one round earlier. And to confirm directly: the write-from-the-final-tree rule is what I applied. The list is a cross-check on it, not the mechanism — which is just as well, since the list has needed extending three rounds running and the rule has not.

Figures

    Finished `test` profile [unoptimized + debuginfo] target(s) in 7m 17s

0 error lines · 8 result lines vs 8 headers vs 8 expected · 0 non-canonical · 1 all-zero anchored (4 naive — fourth confirmation of the rule, now across two crate sets and two machines) · 882 + 0 + 19 + 0 = 901 = header sum · 0 FAILED, 0 failures: blocks · per crate 216 / 247 / 37 / 380, identical to rounds 5 and 6. Sources stamped 10:42–10:44, log 10:58.

merge-tree --write-tree origin/main origin/fix-766-nav-local rc 0 (against main at 1de7133, which has moved since your run). check-no-local-detail.sh OK. Worktree and shared checkout both clean.

On your closing observation

Three consecutive rounds where the defect was a stated enumeration is a fair characterisation and I am not arguing with it. The thing the three have in common is that each was a completeness claim over an open-ended set — the fix sites, the sweep terms, the do-not-carry list — and in each case I published the count as though the set were closed. This round replaces the two that were still open-ended with closed ones: the subject sweep (enumerable, with an independent control) and the final-tree squash rule (no enumeration at all). That is the substantive answer to the pattern; whether it holds is a fourth round's evidence, not this one's, so I am not claiming it as settled.