P1-22+P1-10(punt1) afgerond in gecombineerde doorloop (11 live API-calls: UTF8-decode + cache waar relevant). API-audit toegevoegd aan P2-7 (11 van 22 calls ongebruikt, met classificatie). P1-21 gecorrigeerd o.b.v. Bob: geen test-ad-toggle, testadvertentie is verwacht gedrag tot AdMob-goedkeuring na livegang; alleen de debug-fallback-UI (punt 2) blijft een echte taak.

TASKS.md

@@ -885,24 +885,28 @@ zichtbaar (geen doorontwikkeling naar een echte advertentie), en de
 ```
 BannerAd failedToLoad: LoadAdError(code: 0, domain: com.google.android.gms.ads, message: Internal error., ...)
 ```
-Twee losse punten om op te pakken:
-1. **`showsTestAd: true`** staat nog aan (regel 203, gebruikt Google's
-   demo-ad-ID i.p.v. de wél al ingevulde echte
-   `androidAdUnitID`/`iOSAdUnitID` op regel 204-205) — vermoedelijk
-   bewust tijdens ontwikkeling, maar een expliciete "zet dit om vóór
-   livegang"-controlepunt waard, anders draait de productie-app nog op
-   Google's testadvertenties (geen omzet).
-2. **De fallback-UI zelf moet sowieso weg/anders**, los van
-   test-vs-productie: een gebruiker mag nooit deze debugtekst zien, ook
-   niet als een echte advertentie een keer traag laadt of faalt (bv.
-   geen advertentie-inventory voor deze gebruiker/regio). Voorstel:
-   `flutter_flow_ad_banner.dart`'s fallback-`Container` vervangen door
-   iets neutraals (leeg vlak met dezelfde hoogte, of gewoon
-   `SizedBox.shrink()`) i.p.v. de zwarte debug-tekst-box — dit is een
-   **custom/lokaal bestand** (onderdeel van de FlutterFlow-standaard
-   widgetlibrary), dus in tegenstelling tot pagina's/componenten wél
-   rechtstreeks in de code aan te passen zonder builder-UI (net als
-   `lib/custom_code/`, zie `CLAUDE.md`).
+- **Punt 1 (`showsTestAd`) geschrapt als bug — bevestigd verwacht
+  gedrag (2026-08-13, Bob):** er is **geen** losse "test ad"-instelling
+  in de builder (bevestigd via het AdBanner-widget-eigenschappenpaneel —
+  alleen Visibility/Expansion/Padding/Alignment/Ad Properties/
+  Dimensions, geen test-toggle). De testadvertentie verschijnt omdat
+  Google AdMob de app nog niet heeft goedgekeurd — dat kan pas ná
+  livegang (Google keurt pas goed als de app in productie draait).
+  **Actie bij livegang (niet nu, geen losse builder-stap):** ná het
+  live zetten van de app bij Google/Apple de advertenties laten
+  reviewen/goedkeuren — pas daarna serveert AdMob automatisch echte
+  advertenties i.p.v. de testvariant.
+- **Punt 2 blijft een echte taak, los van goedkeuring:** de fallback-UI
+  zelf moet sowieso weg/anders — een gebruiker mag nooit deze
+  debugtekst zien, ook niet ná goedkeuring als een advertentie een keer
+  traag laadt of faalt (bv. geen advertentie-inventory voor deze
+  gebruiker/regio). Voorstel: `flutter_flow_ad_banner.dart`'s
+  fallback-`Container` vervangen door iets neutraals (leeg vlak met
+  dezelfde hoogte, of gewoon `SizedBox.shrink()`) i.p.v. de zwarte
+  debug-tekst-box — dit is een **custom/lokaal bestand** (onderdeel van
+  de FlutterFlow-standaard widgetlibrary), dus in tegenstelling tot
+  pagina's/componenten wél rechtstreeks in de code aan te passen zonder
+  builder-UI (net als `lib/custom_code/`, zie `CLAUDE.md`).
 - **Kanttekening bij P2-5** ("Ad-banners..., na livegang"): P2-5 gaat
   er nog van uit dat advertenties een niet-gebouwd P2-idee zijn — in
   werkelijkheid staat er dus al minstens 1 banner live in de code
@@ -911,55 +915,17 @@ 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: 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-22 volledig afgerond 2026-08-13 — live pair-sessie, Bob builder +
+Claude verse-export-verificatie, gecombineerd met P1-10's cache-toggle
+in één doorloop per call (Bob's voorstel, scheelde een dubbele
+builder-bezoekronde). Alle 11 live API-calls hebben nu `decodeUtf8:
+true` bevestigd (`homeTabel`, `HomeSlider`, `Uitgaanstabel`,
+`UitgaanSlider`, `EstablishmentInfo`, `HorecagelegenheidEvents`,
+`gemeenten`, `provincies`, `Evenement`, `Establishments`,
+`requestNewPassword`) — `EstablishmentsCall`'s toggle werd in de eerste
+ronde gemist (niet te verwarren met het dode `EstablishmentsNewCall`,
+zelfde-klinkende naam), in een 2e verse export alsnog bevestigd
+correct. Uit deze lijst verwijderd.)*
 
 **P1-9 · Eigenaar: Onbepaald.** Visuele polish (los, per pagina) —
 resterend na sessie 2026-08-06:
@@ -1007,42 +973,22 @@ resterend na sessie 2026-08-06:
   gebruiken (werkt als browser-find) i.p.v. handmatig scrollen (scroll-
   wheel-events op die pagina reageren nauwelijks).
 
-**P1-10 · Eigenaar: Bob (10 sec-klusje, geblokkeerd voor Claude —
-clipping).** Performance — resterend werk (audit
+*(P1-10 punt 1 — cache-toggle op `homeTabel`/`gemeenten`/`provincies` —
+afgerond 2026-08-13, gecombineerd met P1-22 in één doorloop per API
+call, bevestigd via verse export. Punt 2 hieronder blijft open als
+losse taak.)*
+
+**P1-10 · Eigenaar: Onbepaald.** Performance — resterend werk (audit
 afgerond 2026-08-05, Claude, code-niveau):
-1. **Low-risk quick win, builder-only (geen codewijziging):** zet
-   `cache: true` op `HomeTabelCall` (`api_calls.dart:465`) en op
-   `GemeentenCall`/`ProvinciesCall` (`api_calls.dart:1274/1306`,
-   gebruikt in `select_state_drop_down_component_widget.dart`) — nu
-   `cache: false`, terwijl de onderliggende data (categorielijst per
-   Home-tab resp. provincie/gemeente-referentielijst) binnen een sessie
-   feitelijk statisch is. `EstablishmentsCall` heeft dit al goed staan
-   (`cache: true`, werkt functioneel correct — `ApiCallOptions extends
-   Equatable` met `params`/`headers` in de `props`, dus geen
-   reference-equality-bug) en is het te volgen voorbeeld. **2026-08-05,
-   geprobeerd door Claude op `homeTabel` (API Calls →
-   Advanced Settings → "Cache API Results"-toggle aanzetten): toggle
-   zet zelf prima aan, maar de **"Confirm"-knop van de daaropvolgende
-   opslag-bar (Cancel/Confirm) rendert buiten het browservenster** —
-   nieuw bevestigd geval van het bekende rechterpaneel/actiebalk-
-   clippingprobleem uit `CLAUDE.md` (nu ook horizontaal op de
-   API-Calls-pagina, niet alleen op Widget Tree-panelen). Geprobeerd:
-   directe klik, scroll, DOM/shadow-DOM-doorzoeking op tekst "Confirm"/
-   "Cancel" (niets gevonden — Flutter Web HTML-renderer, geen
-   standaard-knoppen), Flutter-accessibility-semantics geforceerd
-   geactiveerd (`flt-semantics-placeholder`, hielp niet), Tab-
-   toetsnavigatie. Geen succes — wijziging veilig teruggedraaid
-   (toggle weer uit, geen halve state). **Bob: 3x deze toggle aanzetten
-   (homeTabel, gemeenten, provincies) en de Confirm-knop rechtsonder
-   klikken** (in eigen browser wél gewoon zichtbaar/klikbaar).
-2. **Groter/structureel, nog te beoordelen:** 4 pagina's (`Home`,
+1. **Groter/structureel, nog te beoordelen:** 4 pagina's (`Home`,
    `horecagelegenheden_overzicht(_sort_page/_page_data_type)_widget.dart`)
    hebben een `TabBarView` met 6-7 tabs die **allemaal gelijktijdig**
    hun eigen API-call vuren bij page-load (Flutter bouwt alle tabs
    eager, geen lazy-tabs) — ook de tabs die de gebruiker nog niet ziet.
-   `cache: true` (punt 1) verhelpt dit niet — dat voorkomt alleen
-   herhaling bij een latere rebuild, niet de eerste gelijktijdige
-   burst. Echte fix vraagt een structurele herbouw (bv. `IndexedStack`
+   De inmiddels aangezette `cache: true` (zie archiveringsnotitie
+   hierboven) verhelpt dit niet — dat voorkomt alleen herhaling bij een
+   latere rebuild, niet de eerste gelijktijdige burst. Echte fix vraagt
+   een structurele herbouw (bv. `IndexedStack`
    met on-demand `FutureBuilder` per tab-activatie i.p.v.
    `TabBarView`) — vermoedelijk custom code. Geen bekend
    rate-limit-probleem op de Drupal-API, dus mogelijk lage prioriteit
@@ -1194,9 +1140,47 @@ code).
   gebruikte event-detailpagina. Alleen bereikbaar via een handmatige
   directe URL. Beslissing (verwijderen uit `nav.dart`+`index.dart`, of
   alsnog ergens aan koppelen) ligt bij Bob.
-- `EstablishmentsNewCall` (`lib/backend/api_requests/api_calls.dart:845`)
-  wordt nergens meer aangeroepen — dode API-call-definitie (gevonden
-  bij de P1-10-performance-audit 2026-08-05).
+- **Volledige API-call-audit (2026-08-13, Claude, `grep` op alle
+  klassenamen buiten `api_calls.dart` zelf, gecombineerd met de
+  live-bereikbaarheid-bevindingen uit P1-19/P2-7): van de 22
+  gegenereerde API-calls in de builder zijn er 11 ongebruikt.**
+  `EstablishmentsNewCall` (regel hierboven) was hier al 1 van, nu
+  volledig lijstje:
+  - **Vervangen door custom code, veilig te verwijderen:** `login`
+    (`LoginCall`) en `getcsrf` (`GetcsrfCall`) — de echte login-flow
+    loopt via de custom action `drupalLogin`
+    (`lib/custom_code/actions/drupal_login.dart`), die zelf rechtstreeks
+    `http.post` naar het Drupal-login-endpoint doet én het CSRF-`token`
+    al uit diezelfde loginrespons haalt (`data['token']`) — de aparte
+    `GetcsrfCall`/`services/session/token`-aanroep is dus overbodig
+    geworden. Bevestigd: geen van beide klassen wordt nog ergens
+    aangeroepen.
+  - **Test/scratch-duplicaten, veilig te verwijderen (geen enkele
+    live referentie):** `ZZ userEstablishments TEST`
+    (`ZZUserEstablishmentsTESTCall`), `FavorietenAgendaTESTKANWEG`
+    (`FavorietenAgendaTESTKANWEGCall`), `ZZZhomeSlider`
+    (`ZZZhomeSliderCall` — enige referentie zit in
+    `slider_uitgaan_component_small_current_widget.dart`, zelf alleen
+    bereikbaar via `lib/kanweg/`, dus niet live), `homeSlidershortDate`
+    (`HomeSlidershortDateCall`), `ZZhome uitgaan`
+    (`ZZhomeUitgaanCall`), `zzEstablishmentEvents Copy`
+    (`ZzEstablishmentEventsCopyCall`), `EstablishmentsNew`
+    (`EstablishmentsNewCall`, al bekend), `QueryCityId`
+    (`QueryCityIdCall`).
+  - **Nog niét dood, wel ongebruikt — laten staan:** `FavorietenAgenda`
+    (`FavorietenAgendaCall`) — geen enkele huidige live-referentie,
+    maar dit is de call die P1-7's geplande "Persoonlijke
+    agenda"/Favorieten-tabs straks nodig hebben. Niet verwijderen,
+    gewoon nog niet aangesloten.
+  - **Live/actief (11, ter controle, niet aanraken):** `homeTabel`,
+    `HomeSlider`, `Uitgaanstabel`, `UitgaanSlider`, `EstablishmentInfo`,
+    `HorecagelegenheidEvents`, `gemeenten`, `provincies`, `Evenement`,
+    `Establishments` (let op: niet hetzelfde als het dode
+    `EstablishmentsNew` hierboven — bevestigd verwarrend gelijkende
+    naam, zelfde valkuil als bij P1-22's toggle-ronde), `requestNewPassword`.
+  - Verwijderen kan gewoon via de builder (API Calls-paneel → call
+    selecteren → verwijderen) — geen custom code/lokale bestanden bij
+    betrokken, dus geen export-sync-risico zoals bij widget-edits.
 - Laag risico, uit P0-3 gehaald (2026-08-10): de component-load
   default-toewijzing (eerste app-start, provincie/gemeente-id
   `28666`/`28694`) krijgt nog geen bijbehorende naam mee — valt terug