TASKS.md: P1-22 bevestigd via Bob's screenshot - fix is een simpele 'Decode Response as UTF-8'-toggle in API Call Advanced Settings (zelfde plek als P1-10's Cache-toggle), geen custom action nodig. Eigenaar Bob, mechanisch per API call over te zetten.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

TASKS.md

@@ -1008,34 +1008,55 @@ Twee losse punten om op te pakken:
   toegepast op deze ene bestaande banner, en of er bewust voor
   `PUitgaanPage` gekozen is als eerste plek.
 
-**P1-22 · Eigenaar: Onbepaald.** Emoji in Drupal-content worden `?`
--tekens i.p.v. correct weergegeven — content-encoding-bug,
-projectbreed. **Bevestigd live (2026-08-12)** op de omschrijving van
-evenement "Mythic Fest II" (zowel op de Home-kaart als op de
-EventCurrent-detailpagina, dus niet render-specifiek): tekst als
-`??? ?????????  ?????? ????` en `?????-???? ???????` vóór/tussen
-overigens prima leesbare Nederlandse tekst — precies het patroon van
-emoji die als vervangingstekens worden weergegeven. **Root cause
-(code-niveau, redelijk zeker):** elke API-call in `api_calls.dart` (in
-ieder geval `EvenementCall`, `HomeTabelCall`, `EstablishmentInfoCall`,
-`EstablishmentsCall` — lijkt projectbreed dezelfde template) heeft
-`decodeUtf8: false`. In `api_manager.dart:211-214`
-(`ApiCallResponse.fromHttpResponse`) betekent dat: de responsebody
-wordt gelezen via `response.body` (Dart's `http`-package, die zonder
-expliciete `charset` in de `Content-Type`-header van de server
-terugvalt op **Latin-1**-decodering) i.p.v. expliciet
-`Utf8Decoder().convert(response.bodyBytes)`. Gewone Nederlandse
-diakrieten (é/ë/ï) vallen toevallig ook binnen Latin-1 en blijven dus
-goed — maar emoji (buiten Latin-1) worden zo onherstelbaar naar
-vervangingstekens gemapt. **Waarschijnlijk simpele, projectbrede fix:**
-`decodeUtf8: true` zetten op de API-calls (of, als dat via losse
-builder-toggles per call moet, een enkele globale plek zoeken in de
-FlutterFlow-projectinstellingen voor API-defaults) — controleer na de
-wijziging of de Drupal-respons zelf al `charset=utf-8` in
-`Content-Type` meestuurt (zo niet, is dat een aanvullende
-server-side-check waard, maar de `decodeUtf8: true`-fix in de app zou
-hoe dan ook al moeten helpen zolang de bytes zelf al geldige UTF-8
-zijn, wat aannemelijk is voor Drupal-JSON-export).
+**P1-22 · Eigenaar: Bob (10 sec-klusje per call, zelfde patroon als
+P1-10's cache-toggle — mechanisch, maar over veel API-calls
+verspreid).** Emoji in Drupal-content worden `?`-tekens i.p.v. correct
+weergegeven — content-encoding-bug, projectbreed. **Bevestigd live
+(2026-08-12)** op de omschrijving van evenement "Mythic Fest II" (zowel
+op de Home-kaart als op de EventCurrent-detailpagina, dus niet
+render-specifiek): tekst als `??? ?????????  ?????? ????` en
+`?????-???? ???????` vóór/tussen overigens prima leesbare Nederlandse
+tekst — precies het patroon van emoji die als vervangingstekens worden
+weergegeven. **Root cause (code-niveau, bevestigd):** elke API-call in
+`api_calls.dart` (in ieder geval `EvenementCall`, `HomeTabelCall`,
+`EstablishmentInfoCall`, `EstablishmentsCall` — lijkt projectbreed
+dezelfde template) heeft `decodeUtf8: false`. In
+`api_manager.dart:211-214` (`ApiCallResponse.fromHttpResponse`)
+betekent dat: de responsebody wordt gelezen via `response.body` (Dart's
+`http`-package, die zonder expliciete `charset` in de
+`Content-Type`-header van de server terugvalt op **Latin-1**-decodering)
+i.p.v. expliciet `Utf8Decoder().convert(response.bodyBytes)`. Gewone
+Nederlandse diakrieten (é/ë/ï) vallen toevallig ook binnen Latin-1 en
+blijven dus goed — maar emoji (buiten Latin-1) worden zo onherstelbaar
+naar vervangingstekens gemapt.
+- **Fix bevestigd bereikbaar via de builder-UI, géén custom action
+  nodig (2026-08-12, screenshot van Bob):** elke API Call heeft onder
+  **Call Definition → Advanced Settings** een losse toggle
+  **"Decode Response as UTF-8"** — exact dezelfde plek/rij als de al
+  bekende "Cache API Results"-toggle uit P1-10 (op `EstablishmentInfo`
+  bevestigd: Cache staat al aan/blauw, Decode Response as UTF-8 staat
+  nog uit/wit). Simpelweg per API call aanzetten + de
+  Confirm-actiebalk bevestigen.
+- **Schaal:** de linkerlijst in het API Calls-paneel toont grofweg 15+
+  calls (`FavorietenAgendaTEST`, `getcsrf`, `ZZZhomeSlider`,
+  `homeSlidershortDate`, `homeTabel`, `ZZhome uitgaan`, `HomeSlider`,
+  `Uitgaanstabel`, `UitgaanSlider`, `EstablishmentsNew`,
+  `EstablishmentInfo`, `HorecagelegenheidEve...`,
+  `zzEstablishmentEvents...`, en vermoedelijk nog meer buiten beeld) —
+  waarschijnlijk hoeft dit niet op de `ZZ`/`zz`-geprefixte en
+  `TEST`-calls (lijken oud/scratch, zie ook P2-7's opschoonlijst) maar
+  wel op alles wat daadwerkelijk live gebruikt wordt. **Zelfde advies
+  als P1-10: niet in 1 sessie alle calls proberen, per herkenbaar
+  blokje (bv. per pagina/component-groep) oppakken.** Na elke batch
+  even een verse export/live check of de emoji in een testomschrijving
+  echt goed tonen (i.p.v. alleen op de "Synced"-badge vertrouwen, zie
+  `CLAUDE.md`'s bekende stille-niet-opgeslagen-patroon).
+- Controleer daarnaast (niet blokkerend voor deze fix) of de
+  Drupal-respons zelf al `charset=utf-8` in `Content-Type` meestuurt —
+  zo niet, is dat een aanvullende server-side-check waard, maar de
+  `Decode Response as UTF-8`-toggle in de app zou hoe dan ook al moeten
+  helpen zolang de bytes zelf al geldige UTF-8 zijn (aannemelijk voor
+  Drupal-JSON-export).
 
 **P1-9 · Eigenaar: Onbepaald.** Visuele polish (los, per pagina) —
 resterend na sessie 2026-08-06: