[ffroliva]

Summary

Scoped down from #730's "sweep 24 constants" after /gflow:predict returned CAUTION 7.3/10 from three personas — unanimous: right change, wrong blast radius. Four changes ship, every one backed by a measurement.

Refs #730 (the full sweep stays open; see "Not touched" below)

The one that matters: our diagnostics were blind

ui_automation.py   _gsQuery         = 'i.google-symbols, span.google-symbols'
diagnostics.py     STRUCTURAL_DOM_JS  querySelectorAll('i.google-symbols')

On flow.google.com, where every Material Symbols ligature rides a <mat-icon>, both returned zero.

The instrument we reach for to diagnose selector drift was blind to the host the drift lives on. That is why #727 and #731 stayed invisible for weeks, and why an incident bundle from a migrated user would have reported no ligatures at all. Both queries are now class-only.

Two selectors were broken behind it

Constant	State
SUBMIT_BUTTON_SELECTORS	Working by luck. Entries 0–1 matched nothing on migrated; the submit only landed because entry 2 matches the <mat-icon>'s text. Live: prompt_submitted via="button:has-text('arrow_forward')" — after paying two misses per submit
IMAGE_MODEL_PICKER_TRIGGER	No twin, no fallback → total silent miss. Best-effort, so generation proceeded on whatever model tier the editor opened at

Both now anchor on the google-symbols class, which sits on the labs <i> and the migrated <mat-icon> alike.

The premise is now observed, not asserted

The whole proposal rested on ".google-symbols matches both carriers" — CSS semantics, never checked. tests/api/transports/test_ligature_carrier.py proves it against a real CSS engine with a two-carrier fixture: no account, no network, no credits. If it ever fails, the premise is wrong and this reverts.

It immediately caught a defect in my own fix: matched 3 of 2. SUBMIT_BUTTON_SELECTORS used :text, a substring match, which also accepts arrow_forward_ios — a real Material Symbol. The <i> qualifier had been containing that; dropping it for the class-only carrier made the over-match reachable on the load-bearing submit path. Now :text-is.

So my own "one character each" framing was wrong: dropping a tag qualifier can expose a latent substring over-match, and each site needs its exactness checked too.

Not touched, each for a measured reason

• The negation sites (button:not(:has(i.google-symbols)), and a has_not filter). Broadening inverts them — they would exclude more buttons, and on a dialog whose buttons carry mat-icons the iconless set collapses to zero → no include click → a 120s hang. They are also already broken the other way on migrated.
• The 10 mode-detection selectors. They feed a classifier that calls raise_if_migrated every tick, so they never execute on the host this fixes. Zero upside, nonzero risk on labs — which is unmeasured.
• The add_2 constants. A ligature name drift, not a carrier one, and _CHARACTER_SLOT_ADD_LIGATURE feeds a JS exact-match heuristic where a string swap is not the fix.

Validation

• pytest -q --cov — 4043 passed, 7 skipped
• pyright src — 0 errors · ruff check / format --check clean
• hygiene 1030 files · doc links · website mirror · memory round trip · PII scan
• New offline browser fixture, 6 tests, no credits

E2E: the changed selectors sit on the submit and model-picker paths, exercised by the character-create e2e. Not re-run here — the previous live run on this branch's parent predates these selector edits, so I am not claiming live coverage for them. The offline two-carrier fixture is what backs this PR; a live run belongs with whoever takes the remaining sweep.

[ffroliva]

Live verification — the E2E gap is closed

E2E: tests/e2e/test_character_create_e2e.py::test_character_create_format_prompt_clicks_format_button → 1 passed in 219.19s on denon82. That drives _click_submit with the changed SUBMIT_BUTTON_SELECTORS through a real generation.

But pytest swallows stderr on a pass, so it cannot show which cascade entry fired — and "still works" was never the claim. "Works via the fixed selector rather than the accidental text fallback" is. So the sweep spike now counts the shipped constant against the form it replaced, on both surfaces:

surface	anchor	shipped	pre-#730
composer	submit	1	0
composer	image model picker	0	0
composer	STRUCTURAL_DOM_JS	47 ligatures, 17 distinct	would be 0
character editor	submit	1	0
character editor	image model picker	1	0
character editor	STRUCTURAL_DOM_JS	14 ligatures, 13 distinct	would be 0

pre_730=0 everywhere is the point. The old anchors matched nothing on this host; the new ones resolve. And the diagnostics went from blind to 47 ligatures — that is the ui.json a migrated user's incident bundle would have carried, previously empty.

The probe caught itself

The first verification run reported zero ligatures of any kind on the composer, where an earlier run on the same URL saw 8. The page had not rendered its icons at the fixed 3s mark.

I had given the character editor a control and left the composer without one — so those zeros were unreadable, and I nearly reported them as findings. That is precisely the failure this week has been about, reproduced in my own instrument. One control on one surface certifies only that surface.

Fixed twice over: every surface now carries its own control and hard-errors after the dump, and the composer waits for .google-symbols to attach rather than sleeping a fixed interval — the thing being counted is the thing to wait for. Same URL now yields 17 hits.

That also promotes image_model_picker=0 on the composer from an unreadable zero to a meaningful one: the control passed, so that button genuinely is not on that surface — consistent with the migrated composer having no image mode.

Still not measured

labs. No unmoved account exists here. The <i class="google-symbols"> half of the class-only claim is proven by the offline two-carrier fixture against a real CSS engine, not by a live labs run. Named, not hidden.