Changes touching this path

• AI skill: diagnose-bounce — resolve a bounced harbor land (#404) c5a075d8 · dbf3dbe6…
• Audit the diagnose-* runbooks: correctness, completion criteria, current engine behaviour (#514) 49ad6925 · dbf3dbe6…diff
• Skills hygiene: adopt the invocation split, give the binary preamble one home, fix describe -m guidance (#561) d6a368bf · dbf3dbe6…diff
• Say that reaping a lane needs the session that spawned it (#564) d9813a9b · dbf3dbe6…diff
• diagnose-bounce: verify with cargo test --locked so a lockfile rewrite cannot block the re-land (#692) 213f0b68 · dbf3dbe6…diff
• a ferry pass refuses to project over an open conflict, so a catch-up after a resolve can no longer land the side nobody chose (#653) a9b5fd64 · dbf3dbe6…diff
• a resolution records which side it answered, so catching up after resolving no longer re-raises the path (#744); ADR 0039 says what the one-commit promise actually guarantees (#653) b837289e · dbf3dbe6…diff
• the one flake four runbooks name as the thing to re-run CANNOT FAIL A LAND, and has not been able to for the whole life of the advice: all three describe_contention tests have carried the ignore attribute since #476, whose own subject is move contention stress tests out of the land gate - the gate is cargo test --locked and never passes --ignored, so run directly the file reads 0 passed, 0 failed, 3 ignored. the advice naming it was written by #406 and #404, both ANCESTORS of #476 as merge-base confirms, and nothing updated it when the ground moved. that is the strongest possible argument against writing a list, so what replaces it is the PROPERTY with the fixed instances as examples: the two recurring shapes, a control failure and a Windows sharing error out of a rename or a remove; a four-step triage that captures to a FILE before re-running, reads the COUNT rather than the word, and records that a green re-run is NOT evidence; and an explicit what-would-make-this-section-wrong clause. the concurrency framing this ticket was filed under does not survive anywhere, because the fifth occurrence fired with NO second session running and a process check to prove it - so running alone is not evidence against a flake, and no runbook now says otherwise. the root cause is confirmed FIXED rather than assumed: a statement-scoped census over the WHOLE workspace, not just the crate its own census test covers, reads ten temp_dir occurrences and zero shared roots, each read individually - two are pure string tests, one is a read_dir gated on a prefix that cannot reach the testkit dirs, two are children carrying their own pid, two are false positives whose pid arrives in the next statement, and one derives its stem from a fixture dir both constructors give a pid. the two originally named tests split, and the split is the point. the settled ledger one is COVERED: at the fix parent it read the bare shared root, so resolved() was the single file under TEMP that all 161 fixture sites shared, and a sibling saving an empty ledger between this test save and its load reads back exactly the reported empty map - it is also the test the fix own perturbation experiment PREDICTED and then hit. the persist codec one is NOT covered and never was: it has never used the shared root, its directory has carried a pid and a counter since #252, an ANCESTOR of the fix, so #1667 neither caused nor cures it - its race is its own eight threads renaming onto one destination, and per this ticket explicit non-goal NO RETRY was added, only the two facts recorded where the next reader meets them. and the control-failure signature is corrected before being written down, because tonight refuted its narrowing: #1864 also failed at a control and its medium was a process-global static rather than a directory, so the rule is that a control failure is the signature of SHARED STATE something outside the test wrote, with both media named. it is deliberately not written as therefore it is a flake, because a control can also fail when the change broke the setup path - it says where to look FIRST, not what to conclude (#1606) c87a13f6 · dbf3dbe6…diff
• the removal wait stops reading a FAILED SCAN as an absent file, and the hole was that ONE fallible answer served two callers needing opposite failure behaviour: the precondition, where false-on-failure makes the assert FIRE and is safe, and the exit, where it makes the wait STOP and is not. the scan now answers three ways rather than two - named, not named, or the scan did not run. NotFound stays not-named, because an absent directory naming nothing is a statement rather than a failure; every other error is an Err; and each caller decides explicitly, the precondition panicking with its own message about failing to establish its own precondition, and the exit leaving ONLY through a scan that RAN and did not name the address, waiting a transient error out on the same store budget the removal already followed one level up. flatten is GONE, and it matters at the exit for the same reason, one entry wide: the entry whose read failed may be the very address being waited on, so flatten reports not-named for a name the scan never reached. the proof is a REAL failing scan rather than a simulated one - a regular file standing where the objects directory goes is a genuine OS refusal, error 267, reachable with no second process - and the two arrangements are DISJOINT on one fixture: with the fixed exit it is 0 passed 4 failed naming that error, and with the pre-fix exit restored it is 4 passed 0 failed, which IS the quiet success, reproduced rather than argued. #1596 is otherwise untouched, same helper and same budget. the projection neither surface derived is settled by naming WHICH QUANTITY SCALES: the honest half, being the only arm a design satisfying the never-authoritative rule can reach - so 22.3 becomes about 223 at ten times the paths, on BOTH surfaces, with measured now separated from extrapolated, since the read COUNT is linear and pinned at three sizes while the TIME was measured at one. 223 is therefore the order of magnitude at which to re-open the question rather than a reading, and the other arm about 439 is named as explicitly not the number to quote. the pin the ADR claimed is now the pin the test asserts, strengthened rather than narrowed because the numbers had already been observed: the two-per-path-plus-one relation holds EXACTLY at all three sizes, run rather than trusted, 101 against 50, 401 against 200 and 1601 against 800 - with the per-path multiplier and the fixed overhead kept as SEPARATE constants, since two-N-plus-one and three-N agree only at one, and with the old greater-than line deliberately NOT kept beside it, because over the constants this file writes it is green whatever the code does. four prose corrections ride along: a step that stated the conclusion its own section refuses, a caveat a commit message claimed and no file carried, two runbook short forms stronger than the long form they point at, and a count of three defects that lists two - which STOPS COUNTING rather than inventing a third (#1899) a9018dad · dbf3dbe6…diff

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.