fix(a11y): de hele interface volgt de themawissel — en de diagnose uit #780 klopte niet (#814) #818

Merged

brenno merged 1 commit from fix/apptheme-statische-vlag-814 into main

2026-07-24 20:16:24 +00:00

brenno commented

2026-07-24 20:12:37 +00:00

Owner

#780 repareerde het kwaliteitspaneel en liet de klasse open. Dit sluit hem.

De diagnose in #780 klopte niet

Daar staat dat de route-grens de herbouw tegenhield. Dat is niet zo, en het
verschil is de hele reparatie.

De scope herbouwt wél — zijn profiel verandert. Wat er stopt is de laag
eronder: Element.updateChild slaat een herbouw over zodra het nieuwe widget
identiek is aan het oude, en twee const-instanties van hetzelfde zíjn
identiek. Daar houdt het op, en alles daaronder blijft staan met de kleuren die
het bij zijn vorige build las.

Nagemeten met de opstelling van de app (modus boven de MaterialApp, blad
eronder achter een const kind): het blad herbouwt niet en houdt zijn kleur.

Omvang

776 gebruiksplekken van een mode-afhankelijk AppTheme-token, in 139
bestanden. Dat is wat optie 1 uit #814 — één regel per oppervlak — werkelijk
kost, en een reparatie die uit 139 keer één regel bestaat is er een die de 140e
vergeet.

Wat het wel is

AppearanceScope markeert bij een moduswissel élk element eronder als "moet
opnieuw bouwen", zonder er een weg te gooien. Elke build loopt opnieuw, dus
elke getter leest de nieuwe kant.

Dat het márkeert en niet weggooit is de kern. Een sleutel op de modus doet
hetzelfde in één regel en is in #780 geprobeerd en teruggedraaid: hij disposet
DeckNotifier samen met het tabblad en neemt het niet-opgeslagen deck van de
gebruiker mee. Marking laat élke State staan.

De aansluitregel in het kwaliteitspaneel, de bronwacht die hem afdwong, modeOf
en de InheritedWidget eronder zijn weer weg. Ze zijn overbodig geworden, en
een poort die een overbodige regel eist is erger dan geen poort.

De toets uit #780 mat niets

Die deed twee keer pumpWidget. Dat vervangt de wortel en herbouwt de hele
boom, waardoor het blad "vanzelf" goed kleurt — groen zonder bewijs. Het is ook
de reden dat de negatieve toets daar niet betrouwbaar rood te krijgen was en
geschrapt is.

De opstelling volgt nu de app. In die vorm reproduceert hij de bug, en beide
kernasserties (het blad herkleurt; de State blijft dezelfde) zijn één keer
rood gezien met de markering uitgezet.

Draaiend nagekeken

Beide richtingen, met wegwerpstaat als bewijs:


crash	geen, in geen van beide richtingen
kwaliteitspaneel	herkleurt — mét de aansluitregel eruit
getypte subtiteltekst	blijft staan
schuifpositie slidestrook	blijft staan
deck	tien slides, nog steeds "niet opgeslagen"

Poorten

make check groen (ongepijpt), make test-golden groen, make check-secrets
groen, make sast groen. DAST staat hier nog niet ingericht.

Bewaker overgeslagen, expliciet: dit raakt het bestandsformaat niet, de
opslag niet, geen afhankelijkheid, geen uitgaand verkeer en geen publieke
belofte. Het is één widget, één toets en twee documentatieregels.

Closes #814

#780 repareerde het kwaliteitspaneel en liet de klasse open. Dit sluit hem. ## De diagnose in #780 klopte niet Daar staat dat de route-grens de herbouw tegenhield. Dat is niet zo, en het verschil is de hele reparatie. De scope herbouwt wél — zijn profiel verandert. Wat er stopt is de laag eronder: `Element.updateChild` slaat een herbouw over zodra het nieuwe widget **identiek** is aan het oude, en twee `const`-instanties van hetzelfde zíjn identiek. Daar houdt het op, en alles daaronder blijft staan met de kleuren die het bij zijn vorige build las. Nagemeten met de opstelling van de app (modus boven de `MaterialApp`, blad eronder achter een `const` kind): het blad herbouwt niet en houdt zijn kleur. ## Omvang **776 gebruiksplekken van een mode-afhankelijk `AppTheme`-token, in 139 bestanden.** Dat is wat optie 1 uit #814 — één regel per oppervlak — werkelijk kost, en een reparatie die uit 139 keer één regel bestaat is er een die de 140e vergeet. ## Wat het wel is `AppearanceScope` markeert bij een moduswissel élk element eronder als "moet opnieuw bouwen", zonder er een weg te gooien. Elke `build` loopt opnieuw, dus elke getter leest de nieuwe kant. Dat het márkeert en niet weggooit is de kern. Een sleutel op de modus doet hetzelfde in één regel en is in #780 geprobeerd en teruggedraaid: hij disposet `DeckNotifier` samen met het tabblad en neemt het niet-opgeslagen deck van de gebruiker mee. Marking laat élke `State` staan. De aansluitregel in het kwaliteitspaneel, de bronwacht die hem afdwong, `modeOf` en de `InheritedWidget` eronder zijn weer weg. Ze zijn overbodig geworden, en een poort die een overbodige regel eist is erger dan geen poort. ## De toets uit #780 mat niets Die deed twee keer `pumpWidget`. Dat vervangt de wortel en herbouwt de hele boom, waardoor het blad "vanzelf" goed kleurt — groen zonder bewijs. Het is ook de reden dat de negatieve toets daar niet betrouwbaar rood te krijgen was en geschrapt is. De opstelling volgt nu de app. In die vorm reproduceert hij de bug, en beide kernasserties (het blad herkleurt; de `State` blijft dezelfde) zijn één keer rood gezien met de markering uitgezet. ## Draaiend nagekeken Beide richtingen, met wegwerpstaat als bewijs: | | | |---|---| | crash | geen, in geen van beide richtingen | | kwaliteitspaneel | herkleurt — mét de aansluitregel eruit | | getypte subtiteltekst | blijft staan | | schuifpositie slidestrook | blijft staan | | deck | tien slides, nog steeds "niet opgeslagen" | ## Poorten `make check` groen (ongepijpt), `make test-golden` groen, `make check-secrets` groen, `make sast` groen. DAST staat hier nog niet ingericht. **Bewaker overgeslagen, expliciet:** dit raakt het bestandsformaat niet, de opslag niet, geen afhankelijkheid, geen uitgaand verkeer en geen publieke belofte. Het is één widget, één toets en twee documentatieregels. Closes #814

brenno added 1 commit

2026-07-24 20:12:37 +00:00

fix(a11y): de hele interface volgt de themawissel, niet alleen het paneel (#814 )

scans / scans (pull_request) Successful in 3m22s

Details

e54c86fb8a

#780 repareerde het kwaliteitspaneel door het op de modus te laten aansluiten
en liet de klasse open. De omvang daarvan: **776 gebruiksplekken van een
mode-afhankelijk `AppTheme`-token in 139 bestanden.** Een reparatie die uit
139 keer één regel bestaat, is er een die de 140e vergeet.

De oorzaak lag een laag dieper dan #780 beschreef. De scope herbouwde wél —
zijn profiel verandert — maar zijn kind is een `const` widget, en
`Element.updateChild` slaat een herbouw over zodra het nieuwe widget identiek
is aan het oude. Twee `const`-instanties van hetzelfde zíjn identiek. Daar
stopte de herbouw, en alles eronder hield de kleuren van de vorige build.

`AppearanceScope` markeert nu bij een moduswissel élk element eronder als
"moet opnieuw bouwen", zonder er een weg te gooien. Elke `build` loopt
opnieuw, dus elke getter leest de nieuwe kant; geen enkele `State` sneuvelt.
Dat laatste is de hele reden dat het márkeren is en geen sleutel op de modus:
die versie is in #780 geprobeerd en teruggedraaid omdat ze `DeckNotifier`
disposet en het niet-opgeslagen deck meeneemt.

Draaiend nagekeken in beide richtingen, met een getypte tekst en een gescrolde
slidestrook als bewijs dat vluchtige staat blijft staan — en het deck bleef
tien slides en "niet opgeslagen".

De aansluitregel in het paneel en de bronwacht die hem afdwong zijn weer weg,
net als `modeOf` en de `InheritedWidget` eronder. Ze zijn overbodig geworden,
en een poort die een overbodige regel eist is erger dan geen poort.

**De toets is opnieuw opgebouwd, want de vorige mat niets.** Twee keer
`pumpWidget` vervangt de wortel en herbouwt de hele boom — dan kleurt het blad
"vanzelf" goed en is groen geen bewijs. Dat is ook waarom de negatieve toets
in #780 niet betrouwbaar rood te krijgen was. De opstelling volgt nu de app:
modus van bóven de `MaterialApp`, blad eronder achter een `const` kind. In die
vorm reproduceert hij de bug, en beide kernasserties zijn één keer rood gezien
met de markering uitgezet.

Closes #814

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>