Two WCAG 2.2 SC 1.4.10 failures on main, both from my branches, both fixed here. Gate green, browser drive 24/24, CI green at f05c041.
The live-sync session found the first one and reported it properly — element named, numbers measured, no guess at the fix. That is why it took minutes.
What was wrong
The document page overflowed by 6px. The toolbar wraps, so a group that does not fit moves to its own line — but a group wider than a line then runs off the viewport, and three selects side by side are exactly that at 320px. Fixed by letting the group wrap inside itself, and letting a select shrink below its own content width: a flex item's automatic minimum is its content, and a <select>'s content is its widest option, so "Extra large" set a floor no amount of wrapping could get under.
The list page overflowed by 36px — which nobody had looked at, including me.
That second one is worse than a miss. The search form carried flex-wrap: nowrap to stop its button dropping onto its own line in the desktop header, under a comment I wrote asserting that "a 320px viewport puts each form on its own line intact rather than breaking one of them in half". That was never measured and was wrong: the group wrapped, but the form itself was 340px against 288px of available width. A desktop layout nicety traded for an accessibility failure, by a comment that sounded like it had been checked.
The field now takes what is left after the button rather than claiming a fixed width; the button keeps its whole label, since that label is also the field's accessible name.
Why it reached main
There was no check at 320px. The branch had a review and a browser drive, and neither looked at the one width AGENTS.md commits to without exemption — so the drive now sets a real 320px viewport, walks every element on the list and on a document, and names the innermost one whose box crosses the edge. "Something overflows" sends the next person hunting through a stylesheet; "select[docs-tool-select] ends at 326" does not.
Confirmed red against the unfixed CSS on both pages first, naming exactly the elements above. 24/24 with the fix.
One question before this lands
The live-sync session relayed that you asked for squash merges rather than amadan branch merge, and did theirs by hand: squash onto current main on a temp branch, push it, wait for its own CI, then fast-forward main.
I have not done that, for two reasons. It reached me second-hand, and I put a rule in AGENTS.md a few hours ago about not acting on another session's report as though I had checked it — this is exactly that shape, and getting it wrong means rewriting main's history. And the last step pushes to main, which this session is instructed never to do.
So: say which you want and I will do it — amadan branch merge as before, or the squash-and-fast-forward, or you land it yourself. The branch is ready either way.
— claude~paul@keymail.dev, session "checklist formatting and export"
amadan