Changes touching this path
- the fix-up a cross-ticket review sweep asked for, and both halves were the same defect wearing different clothes: a claim stated where nothing can check it. surface_with_report_reusing's doc said Workspace::surface_plan is the only caller and meets the precondition by construction, which was wrong twice - surface_plan calls it nowhere, being the PRODUCER of the set, and it lives in loot-cli while the door lives in loot-core, so the sentence named a function one crate away as a caller it is not. The door is also pub, which makes the only caller half unenforceable in principle rather than merely untrue today: a caller in any crate compiles without meeting anything. The replacement names the real set, verified by grep - surface_with_report passing an empty set, Workspace::surface_with_report_reusing as the one non-empty caller, and three in-module #1703 tests that hand-build the set, two of them naming a path the reader may not open, which are the standing demonstration that this walk will accept anything at all. A second sentence understated its own mechanism and is corrected in the same pass: surface_plan does not merely record which change it measured, SurfacePlan::already_on_disk_at COMPARES and returns an empty set on mismatch, so the same-change precondition does have an enforcing mechanism and it too is one crate away. That asymmetry is worth naming because it sizes #1710: the set-vouching half has no mechanism anywhere, the same-change half has one in the wrong place, and only one of them needs a type moved. No API changes here - making the door private is #1710 and is deliberately not smuggled in. The other half is three authored figures sitting inside the doc of prove_the_walk_repeats, the non-vacuity control this whole file rests on, saying 192 occurrences against 31 addresses and a 6.2x gap while the assertion below pinned none of them, so editing PATHS or CHANGES or EDITS left all three silently stale in the very place that exists to stop un-grounded claims. OCCURRENCES is now derived as CHANGES times PATHS, the bare literal 4 already in the assertion is named MIN_GAP, and the floor is a const assert that fails at COMPILE time before any fixture is built. Four arms proved it rather than argued it: the baseline reproduces 192 and 31 and 6.2x exactly, so the fixture being reasoned about is the one the old prose described; widening to twelve paths moves the figures to 372 and 42 and 8.9x with everything green, which is precisely the silent staleness that used to be possible; collapsing the gap to one path fails to compile with the floor's own message; and re-authoring OCCURRENCES back to 192 against twelve paths goes red at 288 versus 192. The module header's other readings are marked a dated reading that nothing asserts, following lane_new_sweep.rs, because they come from fixtures this file cannot see and deriving them here would be a second invented claim rather than a fix (#1709)
1b45fed0 · dbf3dbe6…
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.