Twinned from https://github.com/cfsh/ninefold/issues/387 by tools/beads/import_github.py's reconcile pass.
main is currently failing 8 probes. Five are the known probe_all UTF-8 decode bug (#371, fixed in #335, still unmerged). The other three are new regressions from #359 — "Row labels: wrap long sound names, widen the name column".
Not this session's area (#359 is tonapse-main's, already merged), so filing rather than fixing.
Fresh dotnet build on both sides, then each probe run individually:
| commit | focus-cujs | focus-ring | grid-scroll |
|---|---|---|---|
| de81316 — the commit before #359 | pass | pass | pass |
| 765603e — current main | fail | fail | fail |
focus-cujs — CUJ 5, "up from a keys chip lands on the left-column cell":
``` [probe] focus -> @Button@652 (a keys chip) [probe] expect_focus 'SongCellButton' FAILED — focus is on Button '@Button@35' ```
@Button@35 is the song grid's ▶ play song button (SongGrid.cs:77). So navigating up out of a sound chip now lands on the SONG header's play button instead of the nearest cell. That contradicts CONTROLS.md's focus model — *"entering a section by moving up/down: land on the focusable control nearest your column… entering upward on its bottom row"* — and it's a real controller-feel regression, not just a red assertion.
grid-scroll — same shape, three times (@Button@35, @Button@25).
focus-ring — expect_pixel misses, reading background (20,24,38) where the ring's green/amber should be:
``` expect_pixel (150,130) FAILED — got (20,24,38), want (95,211,154) ±60 expect_pixel (134,130) FAILED — got (20,24,38), want (244,232,135) ±30 ```
Consistent with the widened name column shifting the grid's geometry: the ring is presumably still drawn, just not at those coordinates. Whether the fix is repointing the probe's coordinates or restoring the layout is a call for whoever owns #353/#359.
This is the cost of a gate with standing reds, which is the point I filed as #381. probe_all was already failing 5 on the decode bug, so "8 failed" didn't read as *new*. I only caught it because I measured a clean baseline before quoting numbers on an unrelated PR.
Two things would each have caught it independently: merging #335 (clears the 5 decode failures, so any new red stands out), and #380's build-freshness guard (I nearly misdiagnosed this twice today from a stale DLL).
My first hypothesis was a deferred re-grab stealing focus — #385's layer 3, since @Button@35 is exactly the FirstFocusable(_songGrid) target several CallDeferred(GrabFocus) sites use. That is not it. A minimal probe that grabs SongCellButton and waits 30 frames holds focus fine; the failure only appears after the d-pad traversal. So this is the neighbour graph / geometry, not the re-grab race.
None.
No comments.