KeelrLeek
9c3273e6af
The adaptive waits went in unmeasured — the comparison was still running when work stopped. Measured against round 42's 255 step verdicts they are not green: six steps that were `ok` at baseline fail — `artist-lanes-page`, `net-playing`, `net-sheet`, `np-more`, `np-copied`, `np-saved`. They were not six faults. `net-playing` threw `Cannot read properties of null (reading 'click')` because the network row it wanted had not arrived, and every step after it then worked the wrong track: `np-copied` and `np-saved` were hunting for `Copy to a folder` on a LOCAL track's sheet, which does not have it. The reading asked for three things and got one. `resolver.active` is real. **`net.busy` and `lib.loading` are not fields on those stores** — `net` publishes `searching`, `responses`, `files` and `groups`, `lib` publishes `loaded` — so both read `undefined` on every poll, joined a constant into the fingerprint, and left a search in flight indistinguishable from a settled page. The catalog was not read at all, which is `artist-lanes-page`: an artist lookup sits in `catalog.artists[name].status` until it turns `ready`, and the mock holds that page for four seconds on purpose. The names are corrected, the catalog's loading entries are counted, and the counters that move as results land are in the reading, so partial progress registers as progress. The second half matters more than the names. **A stable fingerprint is not a settled page.** A search that has sent nothing back yet holds every counter still, so "two identical readings 90 ms apart" was satisfied in the middle of the work it existed to wait for. Work in flight is its own leading field now, and while the resolver is active, a search is running or any catalog entry is loading, a still page does not count as a settled one. An unreadable page reads as busy for the same reason. The declared wait was always the ceiling and still is. That fixed four of the six. What it did not fix is the reason this is now **off by default**: across three full walks the catalog and network cluster fails a *different subset* each time — one run lost `net-arrived`, `np-copied` and `np-saved`; the next got all three back and lost `net-playing`, `cat-album-row` and the three that hang off `net-playing`. A gate that is green at random is worse than a slow one, and every expectation in this file was written against the declared waits. So `settle()` sleeps the wait it was given unless **`SS_ADAPTIVE=1`** asks otherwise, and the walk prints which mode it ran in so no log is ambiguous about it. Turning that variable on and off is also the A/B the comparison needed and never had. With it on the saving is real — 162 of 414 declared seconds on the mock walk, 95 of 224 on a device, where the walk went 131 of 131 with no exceptions and no console errors. It can have the default when it is green twice running. Three steps carry `hold: true` either way, because they wait on the mock's own clock rather than on the app: a streamed file handed over on a seven-second timer, and the two writes whose only evidence is the notice that follows them.