docs(#782): delete decaying locators and an unstated grep sense from asset_sync's N1 comment

[djhenry]

Closes #782.

What changed

crates/eqoxide-ipc/src/asset_sync.rs, the N1 EDIT block on ConnectOutcome::ALL's rustdoc
(added answering #755's round-8 review). #782 named three false/fragile claims in that one
paragraph:

1. :1400 locator for the round-7 retraction's quoted claim — wrong, and wrong at birth.
2. "four hits" — true only under a case-sensitive grep; grep -i finds a fifth.
3. The block's own pattern list is matched by the sweep it describes, so any count it states
   is off by the block itself.

No production code changed, in either round. The diff touches only /// doc-comment lines
in crates/eqoxide-ipc/src/asset_sync.rs; no other file is touched.

Per the reviewer's recommendation, locators are deleted, not re-measured: constructs are
identified by name (the round-6 retraction, the round-7 retraction on
the_slot_enumeration_and_all_are_the_same_list_in_the_same_order's rustdoc, the round-5
retraction in eqoxide-http's login-outcomes encoder, the renderer's pose-matching comment),
and the "four hits" count is dropped rather than restated with a new number.

Round 1 review found the fix re-instantiated the finding — round 2 fixes that

The first version of this replacement text (commit 1b73b85) put three new
reasoned-not-measured claims into the very paragraph meant to remove them. Commit 8666b28
fixes all three, plus four more precision issues the same review flagged. Each is stated here
with what was actually measured, not just what changed:

• Mischaracterized a still-true claim as a past failure. The round-1 text said the last
  two attempts at "this grep" — "no un-retracted copy", then "four hits" — were each wrong. That
  is false for the first one: "no un-retracted copy" is the corrected round-7 wording (the
  original, actually-wrong wording was "turns up none", already named correctly in the EDIT
  header two paragraphs up) and it is still standing, unretracted, at :561 today. Only "four
  hits" was ever wrong. Fixed by removing the claim that groups them together.

• "Quoting the patterns necessarily matches them" was asserted, not measured, and is false.
  Extracted the three pattern-list lines into an isolated file and grepped each of the 8
  patterns against them individually (grep -Ec -- "$pattern" pattern-list-lines.txt per
  pattern, not a combined count): before this round's fix, 6 of 8 self-matched; after, 7 of 8.
  compile[- ]time pin never self-matches, in either state, because its own regex
  bracket-and-space character class ([- ]) has no literal match in the text that quotes the
  pattern's source (compile[- ]time pin as written contains a literal [, which the class
  cannot match). Fixed by replacing "necessarily matches them" with the measured "seven of its
  eight patterns" and naming the one structural exception.

• Two quoted patterns were split across a /// line break, independently breaking their
  self-match regardless of the regex question above: compile[- ]time pin split across
  (pre-fix) lines :567/:568, and cannot reach the wire split across :568/:569.
  Measured with an odd-backtick-parity check (count of /// lines with an odd number of
  backtick characters — a code span opened on one line and not closed on the same line):

  python3 - crates/eqoxide-ipc/src/asset_sync.rs <<'PY'
  import sys
  for i, l in enumerate(open(sys.argv[1]), 1):
      if '///' in l and l.count('`') % 2:
          print(i, l.rstrip())
  PY
  

  main (a48760b): 2 odd-parity lines, both pre-existing and unrelated to this change
  (an example command at what is now :1528/:1529). Commit 1b73b85: 4 — the same 2, plus
  2 new ones at exactly the lines the round-1 edit added (:567, :569). Commit 8666b28:
  back to 2, matching main. Fixed by rewrapping the pattern list so every backtick-quoted
  phrase stays on one line.

• Re-measured the self-match claim after the rewrap, rather than assuming the fix stands on
  its own (fixing the line-wrap changes what the self-match sentence can truthfully say): the
  per-pattern check above was run against both the pre-fix and post-fix text for exactly this
  reason, which is how "6 of 8, becoming 7 of 8" was arrived at instead of asserted.

• Restored the explicit exclusion. The round-1 text's closing sentence said no un-retracted
  claim "survives outside that inventory," where "that inventory" was an unnamed reference back
  to a list of retractions — silently dropping the explicit `slots()`'s own rustdoc carve-out
  used earlier in the same block, which would make the sentence false on its own terms (:338,
  inside slots()'s rustdoc, legitimately contains "completeness pin" and is not a retraction,
  a quotation, or unrelated prose). Fixed by naming the exclusion again: "outside slots()'s
  own rustdoc and this inventory."

• Dangling antecedent. "This sentence's own pattern list" had no referent — the pattern
  list is quoted in the previous paragraph, not the one containing that sentence. Fixed to
  "The pattern list above."

Hit-count reconciliation (12 vs. 13, and what's inside each)

Re-ran the full-tree sweep against the corrected text (crates/eqoxide-ipc/src/asset_sync.rs
at 8666b28, exact commands under "Premises re-derived" below) and classified every one of the
12 case-sensitive hits by hand, since a stated total without a breakdown is exactly the kind of
number this fix is trying to stop shipping:

Line	File	Category
338, 343, 345, 349	asset_sync.rs	Inside LastLoginByOutcome::slots's own rustdoc — legitimate, not a retraction
541, 544	asset_sync.rs	The round-6 EDIT's blockquote, quoting the old false claim
567, 568, 569	asset_sync.rs	The pattern-list sentence self-matching its own quoted patterns
1428	asset_sync.rs	The round-7 retraction on the test's rustdoc
scene.rs:283	eqoxide-renderer	Unrelated prose (#643 pose-matching comment) the pattern happens to catch
observe.rs:314	eqoxide-http	The round-5 retraction in the login-outcomes encoder

4 (inside slots()'s rustdoc) + 3 (self-match) + 5 (genuinely outside both) = 12.
grep -i adds one more, at asset_sync.rs:547 ("Before the crate builds", capitalized, inside
the round-6 correction paragraph) = 13. This is not a discrepancy to re-open — 12 and 13 are
the same sweep under two different case senses, and the comment's own text says exactly that.

Premises re-derived at current main (a48760b) — none inherited on trust

1. Locator wrong at birth. Confirmed still true today, and re-verified directly at the
introducing commit rather than trusted from the issue text:

git show ecf0ec0:crates/eqoxide-ipc/src/asset_sync.rs | grep -n "compile-time pin that keeps"
# → 1412:    /// compile-time pin that keeps [`ConnectOutcome::ALL`] complete" — a fourth, compressed,

The construct was :1412 at ecf0ec0 (the commit that introduced the :1400 claim) and is
still :1412 on current main. :1400 was never correct. (On this branch, at 8666b28, the
same construct is at :1428 — it moves every time something is added above it, which is the
whole reason the fix names it instead of citing a line.)

2. Case-sensitivity gap. Re-measured on current main, exact commands (pattern set copied
verbatim from the comment; *.rs/*.md, target/ excluded):

PATTERN='completeness pin|compile[- ]time pin|before the crate builds|does not build if|hole is closed|cannot reach the wire|fails to compile here|keeps .*ALL.* complete'
grep -rnE  "$PATTERN" --include='*.rs' --include='*.md' . | grep -v '/target/' | wc -l   # → 12
grep -rniE "$PATTERN" --include='*.rs' --include='*.md' . | grep -v '/target/' | wc -l   # → 13
diff <(grep -rnE  "$PATTERN" --include='*.rs' --include='*.md' . | grep -v '/target/') \
     <(grep -rniE "$PATTERN" --include='*.rs' --include='*.md' . | grep -v '/target/')
# → the only diff line is crates/eqoxide-ipc/src/asset_sync.rs:547, "Before the crate builds"
#   (capitalized), which only -i catches.

Confirmed: 12 case-sensitive, 13 case-insensitive, and the sense genuinely changes the count
(not just a formatting quirk). Same 12/13 on the corrected branch text — see the reconciliation
table above for what the 12 actually are.

3. Self-match. The pattern-list sentence's own lines are among the 12/13 hits above
(:567–:569). Per-pattern breakdown (measured on the isolated pattern-list lines, not
inferred from the combined line count, which cannot distinguish "this pattern matched" from
"a different pattern on the same line matched"): 7 of 8 patterns self-match on the corrected
text; compile[- ]time pin structurally cannot, ever, quoted or not — see the round-2 fix
list above for why.

All three original premises held. Nothing was retracted or found already-fixed.

Verification — build + full workspace test suite

Remote builder only (rbuild), judged by log content, not exit code (exit code is known
unreliable — it has returned 0 on a build that failed to compile).

Commands run:

rbuild <branch-worktree>        test --workspace --locked --no-fail-fast
rbuild <main-a48760b-worktree>  test --workspace --locked --no-fail-fast   # baseline

Both logs analysed the same way — never piped through head/tail, captured whole to a
scratchpad file first:

grep -n "Finished" "$LOG"
grep -c "test result:" "$LOG"
grep -c "Running unittests\|Running tests/" "$LOG"; grep -c "Doc-tests " "$LOG"   # launch markers
grep -o "running [0-9]* tests\?" "$LOG" | wc -l         # NOTE: tests\? — cargo prints singular
                                                          # "running 1 test" for N=1; a plain
                                                          # "tests" (no ?) undercounts by exactly
                                                          # the number of 1-test binaries
grep -c "FAILED\|^error" "$LOG"
python3 - "$LOG" <<'PYEOF'
import re, sys
text = open(sys.argv[1], errors='replace').read()
results = re.findall(r'test result: \w+\. (\d+) passed; (\d+) failed; (\d+) ignored; \d+ measured; (\d+) filtered out', text)
tp=tf=ti=tfo=0
for p,f,i,fo in results: tp+=int(p); tf+=int(f); ti+=int(i); tfo+=int(fo)
print(len(results), tp, tf, ti, tfo, tp+tf+ti+tfo)
tokens = re.findall(r'running (\d+) tests?', text)
print(len(tokens), sum(int(x) for x in tokens))
PYEOF

Five figures — this branch (fix-782-asset-sync-n1-comment @ 8666b28, round-2 head)

Figure	Value
Finished line	Finished \test` profile [unoptimized + debuginfo] target(s) in 15m 17s`
test result: lines (count vs. expected)	50 / expected 50 (37 Running launches + 13 Doc-tests sections)
Non-canonical (corrupt) result lines	0
All-zero (empty-target) result lines	15
passed + failed + ignored + filtered	1664 + 0 + 45 + 0 = 1709
Running total (sum of header Ns, tests\?)	1709 — matches
FAILED / error occurrences	0 / 0

Header-vs-summary parity: 37 Running + 13 Doc-tests = 50 launch markers = 50
test result: lines. No lost binary. (Wall time dropped from 44m37s in round 1 to 15m17s here
because the remote target/ for this worktree was already warm from the round-1 build —
incremental, not a different test set: identical 50/50/50 and 1709 total confirm it.)

Five figures — main baseline (a48760b, fresh detached-HEAD worktree, nothing else applied)

Figure	Value
Finished line	Finished \test` profile [unoptimized + debuginfo] target(s) in 43m 09s`
test result: lines (count vs. expected)	50 / expected 50 (37 Running launches + 13 Doc-tests sections)
Non-canonical (corrupt) result lines	0
All-zero (empty-target) result lines	15
passed + failed + ignored + filtered	1664 + 0 + 45 + 0 = 1709
Running total (sum of header Ns, tests\?)	1709 — matches
FAILED / error occurrences	0 / 0

Header-vs-summary parity: 37 + 13 = 50 launch markers = 50 test result: lines. No lost
binary. running N tests header count (tests\?, non-line-anchored) is also 50, matching
the 50 test result: lines exactly — no corruption despite Running/Doc-tests lines splicing
mid-line into passing test … ok lines several times in this log (confirmed by eye; e.g. an
eqoxide_telemetry Running unittests line lands mid-line inside eqoxide_net's own passing
test output — a non-anchored count still catches it). Baseline is unchanged from round 1 (main
did not move), so this log was not re-captured for round 2.

Delta

Zero. Branch (round-2 head 8666b28) and baseline are identical on every figure: 1664
passed / 0 failed / 45 ignored / 0 filtered / 1709 running total, 50/50/50 parity, 0
non-canonical, 15 all-zero, on both trees. This is exactly what a doc-comment-only change
should do — it moved nothing.

Scope re-derivation (what reads what, not what I edited)

This was wrong in round 1 and is corrected here from measurement, not from re-reading either
my prior claim or anyone else's restatement of it.

Round-1 claimed "no compiled guard reads this file." That is false. The #[test] fn
every_doc_comment_test_citation_resolves_and_is_listed_in_a_guard in
eqoxide-nav/src/steering.rs builds a citation-resolution corpus (resolve_in, built at
steering.rs:1571-1582) by recursively walking the entire workspace root — crates/,
tests/, and src/ — for every .rs file (target/ excluded):

find crates tests src -name '*.rs' -not -path '*/target/*' | wc -l
# → 162

That is 162 files, and asset_sync.rs is one of them (confirmed: it's under crates/, and the
walk does not exclude eqoxide-ipc). So a compiled guard does read this file, on every test run
of eqoxide-nav's steering module.

It is benign here, and this is also measured rather than assumed: resolve_in's only use of the
162 files' contents is scan_fns, which extracts fn NAME declarations line-by-line
(steering.rs's fn_name_on) to build a set of valid citation targets — it never scans file
contents for the "completeness claim" phrasings this doc discusses, so nothing about this
change's wording is visible to that guard. The separate unbalanced_doc_spans check (the one
structurally capable of catching this file's round-1 line-wrap defect, F3 above) runs only
against cited_in — four specific files (steering.rs, walker.rs, collision.rs,
tests/walker_sim.rs) — not against the full 162-file resolve_in corpus. asset_sync.rs is
in the corpus that's read, but not in the corpus that's checked for this specific defect, which
is exactly why that guard didn't catch F3 and nothing in CI did either.

Net: the write scope is still just this one file (nothing outside it needed editing), but the
read scope is wider than either my round-1 claim or the original briefing to me characterized
it — 162 workspace-wide files, not "no guard" and not "reads walker.rs."

Suggested squash-merge message

This repository squash-merges PR commits, concatenating their bodies into main's permanent
history by default. Commit 1b73b85's message opens "made three claims that were false or
fragile, all measured rather than reasoned about" — that is the exact inversion of what
happened (the original claims were false because they were reasoned about rather than
measured), and it should not ship into main's history as written. Please use this as the
squash subject/body rather than the default concatenation:

docs(#782): stop citing line numbers and an unstated grep sense in asset_sync's N1 comment

The N1 EDIT block on ConnectOutcome::ALL (added answering #755's round-8 review) made three
claims that were false or fragile because they were reasoned about rather than measured:

1. It cited `:1400` for the round-7 retraction's quoted claim; that construct was at `:1412`
   even at the commit that introduced the sentence, and decays every time an edit lands above
   it regardless.
2. "four hits" held only under a case-sensitive grep; `grep -i` catches a fifth.
3. The block's own pattern list is matched by the sweep it describes, so any count it states
   is off by the block itself.

Locators are deleted rather than re-measured (constructs named, not line-cited) and the count
is dropped rather than restated. A round-1 review of this fix found the replacement paragraph
had re-reasoned rather than re-measured its own three claims about the fix; round 2 corrects
those and reconciles the 12-vs-13 hit count into what's inside each. No production code
changed — doc comments only. Full workspace test suite green before and after; see PR
discussion for the exact commands and figures.

Closes #782

What I could not establish

• I did not re-audit the wider tree for other, differently-worded restatements of the
  completeness claim beyond the literal pattern set the comment already names (the issue's
  "grep the concept, not the field" caution) — that is a broader sweep than asset_sync.rs N1 comment: a locator that was wrong at birth, a count that depends on grep case, and a pattern list that self-matches #782 scopes, and
  the replacement text is explicit that its own inventory is scoped to this pattern set, not
  a claim about the whole codebase's phrasing space.
• Scope check: as of this update, gh pr list shows six other open PRs (#786, #784, #778,
  #774, #767, plus this one). Diffed each against origin/main — none touch
  crates/eqoxide-ipc/src/asset_sync.rs. No file-level overlap with this change.
• git merge-tree of this branch against current main (a48760b) produced no conflict
  markers — clean fast-forward-able merge.
• The round-1 reviewer's own independent build only covered a scoped -p eqoxide-ipc -p eqoxide-nav run, not the full workspace figures below — those remain on my word, same as
  round 1, pending independent re-check.

[djhenry]

Independent review — REQUEST CHANGES

Reviewed at 1b73b85 against main a48760b, in my own worktree. I did not write this change.

The PR does what #782 asked for on all three original items — I re-ran every premise and all three hold.
But the replacement paragraph introduces a new false claim about this file's own text, of exactly the
class the PR exists to remove, and it contradicts a sentence 22 lines above it that is still standing and
still asserted as measured. Two more of the new sentences are falsified by measurement. That is a blocking
set, not a nit: the whole subject matter of this block is which claims about the source survive.

Line numbers below are at 1b73b85 unless stated.

---

F1 (blocking) — crates/eqoxide-ipc/src/asset_sync.rs:583-584 declares a true, still-standing sentence to have been wrong

The new paragraph says:

the last two attempts at a specific state of this grep ("no un-retracted copy", then "four hits") were
each wrong by the time the following EDIT ran it again.

Measured against the file's own history:

commit	:561 reads
55ecbff (round-7 head)	claim's phrasings turns up **none** outside [LastLoginByOutcome::slots]'s rustdoc
ecf0ec0 (round-8 fix)	claim's phrasings turns up no **un-retracted** copy outside [LastLoginByOutcome::slots]'s
a48760b (main)	same as ecf0ec0
1b73b85 (this branch)	same — unchanged by this PR, still there at :561

So "turns up none" was the attempt that failed. "no un-retracted copy" is the correction that
replaced it, and it is still in the file, presented as "stated as a measured fact about this commit".

Three independent confirmations that it was not wrong:

1. This same EDIT block's own header, at :564, quotes the right failed wording:
   "turns up none" was the wrong word. Header and body of one block now name different sentences as
   the failure.
2. The round-8 reviewer on fix(#731): observe the asset-server login, so a hung login stops reading as an idle client (supersedes #743) #755 wrote, verbatim: "turns up no **un-retracted** copy" is what was measured and what is true.
3. The round-9 reviewer: N1's substance — that no un-retracted assertion of the completeness claim survives — I re-ran and confirm.

And the new paragraph reasserts the same substance itself, three sentences later at :585-586:
"What is true, and was measured for this commit, is that no un-retracted assertion of the completeness
claim survives…". One paragraph says X was wrong and that X is true.

The reader-facing damage is the specific one this whole chain is about: someone following :583-584
concludes the sentence at :561 is retracted, when it is the one measured-true statement in the chain.

Fix: only "four hits" belongs in that list. Either drop the first item, or name the actual failed
wording ("turns up none", at 55ecbff) and say it was corrected in place at ecf0ec0 — which is what
:561 and :564 already jointly record.

---

F2 (blocking) — :578-579 "quoting the patterns necessarily matches them" is false, measured

This sentence's own pattern list is itself a hit — quoting the patterns necessarily matches them

Per-pattern, case-sensitive, over the pattern-list lines :567-569 only:

pattern	self-matches
completeness pin	1
compile[- ]time pin	0
before the crate builds	1
does not build if	1
hole is closed	1
cannot reach the wire	0
fails to compile here	1
keeps .*ALL.* complete	1

6 of 8, not 8 of 8. Two reasons, one structural and one introduced by this PR:

• compile[- ]time pin can never self-match. The quotation contains the regex metacharacter class
  [- ]; the literal string compile[- ]time pin is not matched by the regex compile[- ]time pin. No
  reflow fixes this. This is the interesting case — it is exactly why a reader who reasons "quoting a
  pattern matches it" gets a different number than a reader who runs it.
• cannot reach the wire fails only because this PR wrapped it across :568/:569 and grep is
  line-oriented (see F3).

This is a reasoned mechanism claim ("necessarily") that measurement falsifies — the dominant defect
class in this repo, re-instantiated inside the fix for it.

Fix: state what was measured, or drop the mechanism and say only that the list matches itself in part.
Do not restate a number.

---

F3 (blocking) — :567 and :569: the reflow broke two code spans across lines, and this workspace has a compiled guard that calls that a defect

Odd-backtick-parity doc lines in asset_sync.rs, whole file:

tree	count	which
a48760b (main)	2	:1512, :1513 (pre-existing, unrelated construct)
1b73b85 (branch)	4	the same two, plus :567 (3 ticks) and :569 (11 ticks)

Both new ones are inside the paragraph this PR rewrote. `compile[- ]time pin` now opens on :567 and
closes on :568; `cannot reach the wire` opens on :568 and closes on :569. On main the whole
pattern list sat one-pattern-per-line-fragment with every span balanced.

crates/eqoxide-nav/src/steering.rs:1769 (unbalanced_doc_spans) reports exactly this condition, with the
message "a code span opens on this line and closes on another. cargo doc renders the break inside the
span. Keep the span on one line." asset_sync.rs is not in that guard's citation corpus (cited_in),
so nothing catches it here — but the project's own standard is explicit.

The bigger cost is not rendering. The pattern list is a copy-and-run recipe, and the same paragraph
tells the reader to use it ("re-run the grep to check"). Wrapped mid-pattern, two of the eight patterns
cannot be lifted off a line — and that is what makes F2's sentence false.

Fix: keep each backticked pattern whole on one line. That also restores 7/8 self-matching, leaving only
the [- ] case, which is worth saying out loud rather than papering over with "necessarily".

---

F4 (non-blocking) — :585-586: the exclusion set silently changed

Round-7's sentence at :561 excludes [`LastLoginByOutcome::slots`]'s rustdoc by name — the one place
the project deliberately keeps the corrected claim. The new sentence excludes "that inventory" instead, and
the inventory is defined at :570 as the hits outside slots()'s rustdoc. So slots()'s rustdoc is now
inside the scope of "no un-retracted assertion … survives", and slots()'s rustdoc carries, at :338:

It is also the completeness pin for [ConnectOutcome::ALL]

Either that is an un-retracted assertion (new claim false) or it is not (new wording merely imprecise) — but
the round-7 wording had no such ambiguity and the rewrite created it. Restore the named exclusion.

---

F5 (non-blocking) — the PR body's scope derivation is wrong; a compiled guard does read this file

The body states: "Every hit resolves to a guard reading its own crate's src/ … eqoxide-nav's own files
via steering.rs … None reads crates/eqoxide-ipc/src/asset_sync.rs."

Measured. crates/eqoxide-nav/src/steering.rs:1559-1576 builds its resolution corpus from the
workspace root, not its own crate:

let crate_root = PathBuf::from(env!("CARGO_MANIFEST_DIR"));
let ws = crate_root.parent().and_then(|p| p.parent()) …          // = workspace root
let mut stack = vec![ws.join("crates"), ws.join("tests"), ws.join("src")];
… recursive read_dir, skipping only `target/`, collecting every *.rs

Replicating that walk yields 162 .rs files, and crates/eqoxide-ipc/src/asset_sync.rs is one of them.
So the write scope claim ("no compiled scanning guard reads asset_sync.rs") is false.

It is benign for this change — that corpus is used only to harvest fn NAME declarations, and the diff
adds none — and I proved it green by execution, not by replaying the algorithm (below). But the derivation
as written would be load-bearing and wrong for any change to this file that added a fn or a backticked
four-word citation.

---

F6 (non-blocking, but it ships) — the commit body contradicts itself, and this repo concatenates commit bodies on squash

1b73b85's body opens:

made three claims that were false or fragile, all measured rather than reasoned about

That is the inversion of the finding, and its own bullet 1 says the opposite two lines later: "the number
was never measured, it was written." On squash this lands in main's permanent history verbatim. Fix it in
the commit body, or exclude it via a hand-written squash body.

---

F7 (nit) — deictic locators replaced numeric ones without an antecedent

:578 says "This sentence's own pattern list", but the pattern list is in the previous paragraph
(:567-569); the sentence containing that phrase contains no pattern list. Having correctly deleted the line
numbers, the replacement leans on "this sentence" / "this doc's own" / "twelve lines above this one" — one of
which now resolves to nothing.

---

What I confirmed as correct

All measured by me at 1b73b85 / a48760b, not taken from the body:

• Diff purity. One file. 23 added / 10 removed. Every added line is /// …; the one that isn't is
  the bare /// separator. Zero production code. ✔ as claimed.
• Premise 1 (locator wrong at birth). git show ecf0ec0:…| grep -n "compile-time pin that keeps" →
  1412:; same at a48760b; 1425: on this branch. :1400 was never correct, and the branch's own drift
  to :1425 is a live demonstration of why deleting it was right. ✔
• Premise 2 (case sense). 12 case-sensitive / 13 with -i; the single extra is
  crates/eqoxide-ipc/src/asset_sync.rs:547 ("Before the crate builds"), inside the round-6 correction. ✔
• The 12/13 vs "four hits"/five discrepancy reconciles — different denominators, not an error:
  12 = 4 inside slots()'s rustdoc (:338 :343 :345 :349) + 3 self-matching pattern-list lines
  (:567-569) + 5 outside (:541 :544 :1425, observe.rs:314, scene.rs:283). The issue's "four" counted
  :541 :544 :1412 observe.rs:314, with scene.rs:283 called out separately as "a fifth".
• Premise 3 (self-match). True — but only for 6 of 8 patterns. See F2.
• Every construct now named instead of numbered actually resolves. the_slot_enumeration_and_all_are_the_same_list_in_the_same_order
  is a real #[test] at :1441; the round-6 retraction is at :536; the round-7 retraction is at :1423,
  on that test's rustdoc; crates/eqoxide-http/src/observe.rs:314 is a round-5 EDIT inside the loop that
  emits login_outcomes and last_login_<outcome> (so "login-outcomes encoder" is accurate);
  crates/eqoxide-renderer/src/scene.rs:283 is a comment on a match e.pose arm (so "pose-matching
  comment" is accurate). Naming beats numbering here — that part of the fix is right.
• The "every hit is a retraction, a quotation inside one, or unrelated prose" claim holds for all 12
  (13 under -i) hits, by enumeration, accepting the pattern-list lines as "a quotation inside one" (they
  sit inside the N1 EDIT).
• scripts/check-no-local-detail.sh → OK — no forbidden patterns in tracked files, exit 0, run by me.

Figures I measured

I derived the radius from what reads what, not from what was edited, and found one compiled guard whose
corpus includes this file (F5). Rather than assume, I proved it by execution on the remote builder:

test -p eqoxide-ipc -p eqoxide-nav --locked --no-fail-fast, branch 1b73b85, judged by log content:

figure	value
Finished	Finished \test` profile [unoptimized + debuginfo] target(s) in 3m 36s`
test result: lines vs launch markers	4 / 4 (2 Running + 2 Doc-tests, counted anywhere on line)
running N tests? headers	4, summing 283
passed + failed + ignored + filtered	267 + 0 + 16 + 0 = 283 — matches the header sum
non-canonical (corrupt) result lines	0
all-zero (empty target) result lines	1 (field-anchored)
FAILED / ^error	0 / 0
the guard in question	steering::cursor_resync_tests::every_doc_comment_test_citation_resolves_and_is_listed_in_a_guard … ok

Taken on the author's word, not verified by me: the full-workspace figures (50/50 result lines, 37+13
launch markers, 1664+0+45+0 = 1709, 15 all-zero, delta zero vs main) and the CI status. I ran a targeted
two-crate suite instead and report its numbers as absolutes, not as a delta — I did not run a baseline.

Could not establish: whether any other differently-worded restatement of the completeness claim exists
outside the literal pattern set (the body says so too; out of scope for #782).

---

To clear this

1. :583-584 — remove "no un-retracted copy" from the list of failed attempts, or replace it with the
   wording that actually failed ("turns up none", 55ecbff, corrected at ecf0ec0). Blocking.
2. :578-579 — delete "necessarily", or state the measured 6-of-8 and the [- ] reason. Blocking.
3. :567-569 — put each backticked pattern back on one line; no code span crossing a line break.
   Blocking.
4. :585-586 — restore the named exclusion ([`LastLoginByOutcome::slots`]'s rustdoc) in place of
   "that inventory".
5. Fix the commit body's "all measured rather than reasoned about", and the PR body's scope paragraph
   (steering.rs walks the whole workspace crates/ tree, so it does read this file).

The direction of the fix — names instead of numbers, no count at all — is right, and items 1–3 are all
inside the two paragraphs that replaced the count. Worth one more round.

[djhenry]

Round 2 — REQUEST CHANGES (short round: two clauses, no re-run needed)

Same reviewer as round 1. Re-measured at 8666b28 against current main 1de7133; nothing carried
from round 1 or from the body.

All seven round-1 findings are genuinely fixed, and I reproduced each fix independently — including
the two I expected to find re-instantiated (the 7/8 count is right, and the parity repair is right by
content, not just by count). This is a good round.

One finding remains, and it is the same shape as round 1's, one notch milder: the diagnosis of "four
hits" is softened from wrong at birth to went wrong later, in the shipped text — and the suggested
squash body states it as flatly false. That second one lands in main's permanent history.

---

R2-1 (blocking) — "four hits" is filed under decay; it was wrong when it was written, under both grep senses

Shipped text, crates/eqoxide-ipc/src/asset_sync.rs:585-587:

This inventory is what a grep against the current text turns up, not a promise about the next
edit — the pattern list above will keep matching itself, and the count this EDIT gave when it first
ran ("four hits") was wrong by the time #782 re-ran it.

Suggested squash body, bullet 2:

"four hits" held only under a case-sensitive grep; grep -i catches a fifth.

Measured. Same pattern set, git grep -E / -iE over *.rs *.md, at four commits:

commit	case-sensitive	-i
ecf0ec0 — the commit that wrote "four hits"	12	13
644ba2c — merged head of #755	12	13
a48760b	12	13
8666b28	12	13

The number never moved. There is no point at which "four hits" became wrong.

And at ecf0ec0, slots()'s rustdoc spans :334–:374 (pub fn slots at :375), so the hits
outside it were:

:541  :544  :565  :566  :567  :1412  observe.rs:314  scene.rs:283   → eight

The block claimed "a grep turns up four hits outside slots()'s rustdoc … (A fifth,
renderer/src/scene.rs:283, is unrelated prose …)". Four-plus-a-fifth against an actual eight — it
undercounted by three, at birth, under the case-sensitive sense, by exactly the self-match it failed
to exclude: its own :565-567.

Two consequences:

1. The shipped clause gives finding 2 the forgiving diagnosis this same block explicitly denies to
   finding 1. :1400 is correctly recorded as "the number was never measured; it was written."
   "Four hits" was the same defect, and the sentence it now sits in is about numbers going stale across
   edits ("not a promise about the next edit"). It did not go stale. The block ends up teaching the
   strict lesson about one finding and the loose one about the other, in the same paragraph.
2. The suggested squash bullet 2 is false as written. "held only under a case-sensitive grep"
   asserts that it held case-sensitively. It did not — 4/5 claimed against 8 actual. The grep -i
   gap (:547) is a separate, additional defect, not the reason "four" was wrong. This is the
   permanent history.

The PR body gets it right in prose — "Only 'four hits' was ever wrong" — so the accurate statement
exists in the one artifact that does not ship, and the weaker ones are in the two that do.

Fix — two clauses, nothing to re-run:

• :586-587 → "…and the count this EDIT gave ("four hits") was wrong when it was written: the same
  sweep at the commit that wrote it already returned twelve hits, eight of them outside slots()'s
  rustdoc."
• squash bullet 2 → ""four hits" was wrong when written — the same sweep at that commit returned eight
  hits outside slots()'s rustdoc, because the block never excluded its own pattern list; grep -i
  adds a further one at :547."

---

R2-2 (non-blocking) — "Deliberately not a count." is immediately followed by a count

:578-579. The count is correct (I measured 7/8, below), it is the post-fix figure — the one a
reader re-derives, which is the right direction — and the mechanism is stated, so it is self-correcting.

But it is a number that already decayed once inside this PR: 6/8 at 1b73b85, 7/8 at 8666b28, both
measured by me. It sits under a heading saying it isn't a count, in a PR whose governing recommendation
is delete the locators, not re-measure them. The identical information survives without the number:

every pattern in the list above matches itself except compile[- ]time pin, whose bracket class has
no literal match in its own quoted source

Your call — I am not blocking on it.

R2-3 (nit) — the same phenomenon is stated in two units that differ by more than 2×

The file says the list "is itself a hit for seven of its eight patterns"; the body's reconciliation
table says "3 self-matching pattern-list lines." Both are right in their own unit — 7 patterns
landing on 3 lines (:567 carries 1, :568 carries 3, :569 carries 3) — but a reader who runs the
combined grep sees 3 while the file says 7. Four words ("on three lines") closes it.

R2-4 (nit) — the body's baseline statements are stale

"Baseline is unchanged from round 1 (main did not move)" and "Premises re-derived at current main
(a48760b)". main moved: #786 merged as 1de7133. Stale rather than wrong-at-birth, and I re-ran
the merge check and the affected suite against current main myself — nothing is broken by it (below).

---

Round-1 findings: verified fixed, by my own measurement

• F1 ✔ The clause grouping "no un-retracted copy" with "four hits" is gone entirely. :561 is
  untouched and is no longer called a failure. (The replacement introduces R2-1, in the other direction.)
• F2 ✔ Re-measured per-pattern over the pattern list :567-570 at 8666b28:
  completeness pin 1, compile[- ]time pin 0, before the crate builds 1, does not build if 1,
  hole is closed 1, cannot reach the wire 1, fails to compile here 1, keeps .*ALL.* complete 1
  → 7 of 8, exactly as claimed. The stated mechanism (the bracket-and-space class has no literal
  match in the text that quotes the pattern's own source) is correct and structural.
• F3 ✔ — and by content, which is the check that matters. Odd-backtick-parity /// lines:
  current main 1de7133 = 2 (:1512, :1513); branch 8666b28 = 2 (:1528, :1529).
  diff of the two extracted line sets is empty — byte-identical text, only the offsets moved. The
  round-1 regressions at :567/:569 are gone, and the two survivors are the pre-existing unrelated
  -p eqoxide-ipc --locked / --no-fail-fast example-command span.
• F4 ✔ Named exclusion restored: "outside slots()'s own rustdoc and this inventory". True by
  enumeration — 4 hits inside slots()'s rustdoc, 8 in the inventory, none elsewhere.
• F7 ✔ "The pattern list above."
• F5 ✔ and then some. The scope paragraph is corrected and goes further than my finding did: it
  identifies that unbalanced_doc_spans runs only over the four-file cited_in corpus, which is why
  no guard and no CI check could have caught F3. My independent measurement agrees with the doc-span guard covers four files while its green reads as workspace-wide — three independent readers got its reach wrong #788 —
  resolve_in = 162 workspace .rs files including asset_sync.rs; cited_in = steering.rs,
  walker.rs, collision.rs, tests/walker_sim.rs. Not re-filed; the doc-span guard covers four files while its green reads as workspace-wide — three independent readers got its reach wrong #788 carries it.
• F6 — a suggested squash message is supplied and correctly inverts the "all measured rather than
  reasoned about" phrasing. Judged, not pasted: the rest of it is sound; bullet 2 is R2-1.

Reconciliation table re-derived at 8666b28, every term, not just the total (it was derived before
the reflow, so I did not carry it): 4 inside slots()'s rustdoc (:338 :343 :345 :349) + 3
self-matching pattern-list lines (:567 :568 :569) + 5 genuinely outside (:541 :544 :1428,
scene.rs:283, observe.rs:314) = 12; grep -i adds :547 = 13. Every term matches. No
offsetting errors.

Merge and tests — against current main, not the branch's base

• git merge-tree --write-tree 1de7133 8666b28 → clean, 0 conflict markers.
• Real merge in a worktree: only crates/eqoxide-ipc/src/asset_sync.rs differs from 1de7133
  (24+/8−), and the merged file is byte-identical to the branch's.
• fix(#742): clear the residual workspace lint warnings — per instance, with a reason each; and write the _SUCCEEDS/_FAILS convention down #786 touched steering.rs — the guard file — so I ran the affected suite on the merge result,
  not on the branch alone. test -p eqoxide-ipc -p eqoxide-nav --locked --no-fail-fast, remote
  builder, judged by log content:

figure	value
Finished	Finished \test` profile [unoptimized + debuginfo] target(s) in 14m 23s`
test result: lines vs launch markers	4 / 4 (2 Running + 2 Doc-tests, counted anywhere on line)
running N tests? headers	4, summing 283
passed + failed + ignored + filtered	267 + 0 + 16 + 0 = 283 — matches the header sum
non-canonical (corrupt)	0
all-zero (empty target), field-anchored	1
FAILED / ^error	0 / 0
the guard	steering::cursor_resync_tests::every_doc_comment_test_citation_resolves_and_is_listed_in_a_guard … ok

Identical to my round-1 branch-only figures.

• fix(#742): clear the residual workspace lint warnings — per instance, with a reason each; and write the _SUCCEEDS/_FAILS convention down #786's effect on the 1709 baseline, checked rather than assumed, a48760b → 1de7133:
  #[test] 1409 → 1409, #[ignore] 48 → 48, doc-comment ``` fences in *.rs 68 → 68.
  No test target gained or lost, so the 1709 baseline is consistent with current main — but I did not
  re-run the full workspace, so I have not confirmed the figure itself.

Taken on the author's word, not verified by me: the full-workspace figures for both trees (50/50
result lines vs launch markers, 1664 + 0 + 45 + 0 = 1709, 15 all-zero, delta zero).

Could not establish: nothing new this round.

---

To clear this

1. :586-587 — say "four hits" was wrong when written, not by the time asset_sync.rs N1 comment: a locator that was wrong at birth, a count that depends on grep case, and a pattern list that self-matches #782 re-ran it. The sweep
   returned 12/13 at ecf0ec0 and 12/13 today; eight of those twelve were outside slots()'s rustdoc
   at ecf0ec0 against the four-plus-a-fifth the block claimed. Blocking — it is the one lesson
   this whole block exists to carry, and it is currently applied to finding 1 and not to finding 2.
2. Suggested squash bullet 2 — "held only under a case-sensitive grep" is false; it did not hold under
   either sense. Blocking, because that text is the permanent history.
3. Optional: drop "seven of its eight" for the exception-only phrasing (R2-2), and add "on three lines"
   (R2-3).

Everything else is measured, reproduced, and green on the merge result. Items 1 and 2 are wording only —
no re-run needed, and I do not need to see the full workspace again for them.