# Uitgaanskrant — takenlijst **Vervolg dezelfde sessie (2026-08-25):** na afronding van P1-7 is de volledige lijst herscand op zoek naar nieuw zelfstandig oppakbaar werk — bleek verder vrijwel alles óf al Bob's eigen taak, óf een productbeslissing die eerst bij hem moet liggen. Eén mechanisch item gevonden en met Bob's expliciete akkoord gebouwd: **P2-5** (AdMob- banner op `HorecagelegenheidCurrent` + `EventCurrent`, zelfde patroon als de al werkende banner op `PUitgaanPage`) — horeca-overzicht bewust overgeslagen wegens Bob's actieve Sort/Datatype-experiment daar. Ook **P2-9** kreeg 2 kant-en-klare, direct bouwbare onboarding-opties uitgewerkt (nog geen keuze gemaakt). Bevestigd via verse export + `flutter analyze` (0 errors) + live `ff-run-fvm.sh`-build/launch op emulator-5554 (geen exceptions). --- **Deze sessie (2026-08-24/25, sessie 46, builder via Bob's gedeelde Chrome na expliciet akkoord in de chat, Bob gelijktijdig zelf actief op P2-7):** P1-7 volledig afgerond — **Restpunt A** (horeca-hartjes op `HorecagelegenheidoverzichtKaart` + `HorecagelegenheidCurrent` syncen nu ook naar Drupal via het bestaande `favorieten`-endpoint, zelfde patroon als het gemeente-hartje) en **Restpunt B** ("Wachtwoord wijzigen"-link op de Gebruiker-tab). Nieuw herbruikbaar recept ontdekt en vastgelegd in `CLAUDE.md`: een JSON-body-string met 1 ingesloten variabele bouw je via een kleine Custom Function (`favorietenBodyNode`), niet via het Custom-Action-argumentenpaneel zelf (geen concatenatie-optie op een kaal String-argument). Bevestigd via verse export (`flutter analyze`: 0 errors) + een live `ff-run-fvm.sh`-build/launch op emulator-5554 (geen exceptions). Onderweg 2x geblokkeerd op de bekende geneste-Set-Variable- freeze, beide keren opgelost met een page-reload zonder dataverlies. P1-7 blijft als taak staan (Tab 1's categorie-SQL-patch wacht nog op Bob's bevestiging, zie hieronder) maar heeft geen eigen openstaande Claude-actie meer. --- **Vorige sessie (2026-08-23, sessie 45, code-only + Bob aanwezig achter zijn scherm, geen builder-automation zelf uitgevoerd — Bob pakt de resterende builder-stappen zelf op in een andere chat):** takenlijst doorgelopen op zoek naar zelfstandig oppakbaar werk — bleek vrijwel leeg (bijna alles resterend is Bob-owned of wacht op een korte beslissing van hem). Twee concrete dingen gedaan/afgesproken: 1. **Export-drift gecommit (`27d65ec`)**: `.gitignore` was de `.claude/`-exclude-regel weer kwijt (bekende valkuil, herstel) + de al openstaande `ios/project.pbxproj`-drift. **Push naar `origin` faalde met een SSH-timeout** (`ssh -p 2222 gogs.digitalforce.tv` → "Connection timed out") — geen code-probleem, lijkt netwerk/VPN-gerelateerd. Commit staat lokaal klaar, **nog niet gepusht** — volgende sessie eerst `git push` proberen vóór er weer op verder gebouwd wordt. 2. **P2-7-cluster (opschonen):** de 5 al eerder bevestigde dode orphan-mappen opnieuw vers geverifieerd (`grep` op de exacte klassenamen, geen externe referenties) — `git rm -r` blijft geblokkeerd door de permissie-classifier (3e poging), commando staat klaar voor Bob (zie P2-7 hieronder). **`EventWidget`-orphan- route: Bob's besluit — niet verwijderen, hernoemen met een `kanweg_`-prefix** (consistent met de bestaande `lib/kanweg/`-scratch-conventie) — nog niet uitgevoerd, staat klaar als eerstvolgende builder-stap voor Bob (pagina "Event" in FlutterFlow hernoemen), nog te verifiëren via een verse export zodra gedaan. **Minor-2 bevestigd: blijft op Bob's eigen lijstje**, geen wijziging. --- **Vorige sessie (2026-08-21, sessie 44, terminal/git-verificatie + enkele kleine builder-taken via Bob, geen eigen browser-automation):** vier punten afgerond of afgesloten, telkens bevestigd via verse export (en waar mogelijk een live emulator-run): 1. **P1-7 Tab 1 afgerond** — `TabPersAgenda`'s eigen "On Tap"- `drupalRequest` stond nog op `'POST'`, nu `'GET'` (zelfde fix als eerder al op de On-Page-Load-trigger). Gecommit `0306c26`. 2. **P0-9 afgerond — bleek geen Drupal-bug.** Home's "Uitgaan"-tab (eerste tab) riep de niet-bestaande `display_3` aan i.p.v. de daadwerkelijk al bestaande `services_3` (zelfde naamgeving als de andere 4 secties `services_4/5/6/7`) — een verkeerde letterlijke waarde op de `displayid`-component-parameter, geen Drupal-Views- misconfiguratie zoals aanvankelijk gedacht. Builder-fix + curl- bevestigd (`services_3` geeft nu gewoon de eventlijst terug). 3. **P1-25-bijdrage** — 3 van de 4 tekstvelden (horecagelegenheid/ adres/datum) op `HomeUitgaantabelKaartComponent` kregen `maxLines: 1`/`overflow: ellipsis`; een parallelle sessie (43) vond en fixte het laatst ontbrekende veld (`plaats`) en rondde de taak af — zie de afgeronde P1-25-notitie verderop. 4. **P1-24, Bob's besluit: geaccepteerd, geen verdere actie.** De resterende Json-Path-guard-beperking op `HomeUitgaantabelKaartComponent` (zie hieronder) is niet de moeite waard om verder te fixen — `logo` is in Drupal een verplicht veld (kan in de praktijk niet leeg zijn), en de huidige impact is toch al laag (onschadelijk fallback-icoon, geen app-crash — zie de bijgewerkte P1-24-notitie). **Belangrijke concurrency-les deze sessie (zie ook de aangescherpte regel in `CLAUDE.md`):** halverwege bleek een parallelle sessie tegelijk aan P1-24/P1-25/P1-26 te werken, zonder dat ooit een "— bezig"-marker in `TASKS.md` verscheen — pas ontdekt via een onverwachte `git status`-diff (een halfklare `print()`-placeholder in `header_buttons_component_widget.dart`), niet via de bedoelde marker. Geen schade, beide sessies' werk sloot uiteindelijk netjes op elkaar aan, maar wel reden om de regel expliciet aan te scherpen. **Nog open, niet door Bob beantwoord deze sessie:** **P1-7 Tab 2** — is het hartje op de header (via P1-26) de hele bedoelde scope, of wil Bob ook een echte lijst van gefavoriete gemeenten op de tab zelf (patroon al klaar: `gemeenteNaamById` + `List.generate` over `favorieteGemeenteIds`, geen nieuwe Drupal-afhankelijkheid)? Zie de volledige vraag bij P1-7 hieronder. --- **Vorige sessie (2026-08-21, sessie 43, ~2.5u builder-werk via gedeelde Chrome-browserautomatisering, na expliciete toestemming in de chat, in 2 blokken):** drie taken opgepakt, alle bevestigd via verse export + gerichte `flutter analyze` (0 errors, alleen bestaande info/warning-lints). 1. **P1-25 afgerond** — RenderFlex-overflow op `home_uitgaantabel_kaart_component_widget.dart:359` bleek de `plaats`-Text te zijn die als enige van 4 buurvelden geen `maxLines: 1` had; nu gefixt. 2. **P1-24 grotendeels afgerond** — `PUitgaanSliderKaartComponent`'s ongeguarde `Image.network` kreeg een ConditionalBuilder-guard (`logo != ''`). **Nieuwe bouwtechniek gevonden** (nu in `CLAUDE.md`): een letterlijke lege-string-Second-Value op een Single Condition is wél bereikbaar voor een String/Image-Path-component-parameter (eerder ten onrechte als "onmogelijk" gedocumenteerd voor het losstaande Json-Path-geval van `HomeUitgaantabelKaartComponent`, dat blijft open, zie P1-24 hieronder). **Bijvangst:** de "Component Name kan per ongeluk overschreven worden"-valkuil uit `CLAUDE.md` deed zich opnieuw voor (typen in de zoekbalk landde in het Component Name-veld) — meteen hersteld, geen blijvende schade. 3. **P2-12 volledig afgerond** (2e blok, op Bob's "ga nog maar even door") — laad-placeholder via FlutterFlow's "Use Blur Hash"-toggle + een vaste neutrale hash-string (nieuw recept, zie `CLAUDE.md`), toegepast op alle 9 live `CachedNetworkImage`-plekken in het project (2 bevestigd dode orphans bewust overgeslagen, zie P2-7). **Live geverifieerd na blok 1:** `ff-run-fvm.sh`-build op emulator-5554 draaide succesvol, geen nieuwe excepties — de enige optredende exceptie was exact het al gedocumenteerde open P1-24-restpunt (`HomeUitgaantabelKaartComponent`'s JSON-Path-guard). Blok 2 alleen geverifieerd via verse export + `flutter analyze` (geen tweede live emulator-launch meer gedaan, `emulator-5554` was tussentijds gestopt/verdwenen uit `adb devices` — puur additieve wijziging (laad-placeholder), laag risico). Beide blokken gecommit + gepusht (`f505a71`, `14f97e3`, en het commit van blok 2 hieronder). --- **Vorige sessie (2026-08-21, sessie 42, ~1-2u builder-werk + live-emulatoronderzoek via gedeelde Chrome-browserautomatisering + `mcp__android__*`, na expliciete toestemming in de chat):** twee builder-taken afgerond, plus stale-documentatie gecorrigeerd, plus nieuw onderzoek naar P1-24/P1-25. 1. **P1-27** — Home-pagina TabBar "Tab Bar Scrollable" aan. 2. **P2-11** — categorie-tag-kleur van bordeauxrood naar het groen van uitgaanskrant.com (`#09B34A`) op de 2 bevestigde plekken (`TagCategorieComponent` + `HorecagelegenheidoverzichtKaart`). Beide eerst geverifieerd via losse `/tmp`-exports, **later alsnog een echte `flutterflow export-code` in de projectrepo zelf gedaan** (was aanvankelijk vergeten) + gecommit/gepusht (`7dd0707`) — pas toen bleek via een live app-launch dat de fixes ook echt zichtbaar waren (tags groen, tab-labels voluit). 3. **Concurrency-vondst bij sessiestart:** een andere/concurrente sessie (commit `d8bbba4`, waarschijnlijk Bob) had ondertussen zowel **P1-26** (gemeente-hartje op `HeaderButtonsComponent`) als **P0-9** (Home's kapotte Drupal-`display_3` → app-side workaround naar `services_3`) al afgerond — beide bevestigd in code/via curl en `TASKS.md` bijgewerkt (was nog stale). 4. **P1-24/P1-25-herverificatie na Bob's hulp** (hij startte `emulator-5554` en wees op zijn fysieke `K7V8DYTSMVTW6XBI`, zie ook zijn losse vraag over `emulator-5556`'s incidentele crashes): **P1-24's root cause definitief gevonden** (leeg `logo`-veld op Drupal-content nid 214339, 2 widgets met een guard die niet ver genoeg gaat — zie P1-24 hieronder, **niet** gelinkt aan P0-9 zoals eerder gedacht). **P1-25 bleef onderzoek-technisch steken**: Home's "Uitgaan"-tab reageerde niet meer op scroll-swipes (drie verschillende methodes geprobeerd, geen effect), en vlak daarna **crashte `emulator-5554` zelf** (systemd: `signal=SEGV`, geheugenpiek 20GB) — mogelijk gerelateerd aan P1-24's image-decode-burst, niet bevestigd. **Nieuw diagnoserecept toegevoegd aan `CLAUDE.md`** (AVD-crash-diagnose via `journalctl --user -u android-emulator*.service`, en een `adb logcat`-buffer- valkuil die een misleidend "er gebeurt hier van alles"-beeld gaf). Geen tijd meer gehad om `emulator-5554` na de crash opnieuw te proberen of `emulator-5556`/het fysieke toestel in te zetten voor P1-25 — blijft open voor een volgende sessie. 5. **Performance-vraag van Bob** (fysieke testtoestellen "enorm traag" ná een schone herinstallatie): geen kapot toestel/instelling gevonden (Developer Options normaal, geen achtergrondbelasting) — bleek gewoon een **debug-build** (`dumpsys package` toonde `DEBUGGABLE` op beide telefoons, universeel en met opzet trager dan een release/profile-build). **Nieuwe staande regel, vastgelegd in `CLAUDE.md`:** voortaan standaard `fvm flutter run --profile -d ` voor gewone testrondes, volledige debug-mode (`ff-run-fvm.sh`) alleen nog bij het actief jagen op een specifieke bug. Gedemonstreerd op `K7V8DYTSMVTW6XBI` (profile-build: 56s Gradle + 3.2s install, draait probleemloos). 6. **P1-24-bouwpoging (~45 min) mislukt, overgedragen aan Bob** — de guard-fix op `HomeUitgaantabelKaartComponent` bleek geblokkeerd op een echte FlutterFlow-UI-beperking (operator "Is Set and Not Empty" niet beschikbaar voor een JSON-Path-gebonden First Value op een ongetypeerd loop-item, geen letterlijke-tekst-invoer voor een 2e AND-conditie) — zie de uitgebreide poging-documentatie bij P1-24 hieronder + nieuwe `CLAUDE.md`-notitie. Widget zelf staat nog ongewijzigd/veilig (elke poging netjes teruggedraaid via Cancel/ page-reload, geverifieerd). **Bijvangst:** de 2e P1-24-locatie (`PUitgaanSliderKaartComponent`'s `Image.network`) is juist waarschijnlijk wél eenvoudig, want die `logo` is daar een directe String-component-parameter, niet een JSON-Path-binding — apart genoteerd voor Bob. **Vorige sessie (2026-08-20, laat, look&feel-review mobiel+tablet, code-only + live emulators `emulator-5554`/`emulator-5556`, geen builder-UI aangeraakt):** op Bob's verzoek een look&feel-review gedaan als een van de laatste checks vóór livegang — Home-pagina live vergeleken op telefoon- en tabletformaat, plus een kleurenpalet-check. 3 nieuwe punten toegevoegd (**P1-27** t/m **P1-29**) en 2 nieuwe polish-ideeën in P2 (**P2-11** kleurcodering, **P2-12** laad-placeholder bij afbeeldingen). **Geen nieuwe P0's** — de app is in de basis bruikbaar op beide formaten, dit zijn allemaal afwerkingspunten. Onderweg 2 al bekende issues live herbevestigd i.p.v. opnieuw als nieuw gemeld: **P1-13** (5382px-overflow op Horeca-overzicht → Activiteiten-tab) staat nog exact zo kapot als eerder gedocumenteerd, inclusief het bekende "Confirm even geen scroll meer mogelijk"-effect; **P1-21**'s AdBanner-debugtekst staat er ook nog, maar dat is Bob's eigen bewuste keuze (blijft zo tot na AdMob-goedkeuring) — geen actie. Sessie werd 2x onderbroken door een computer-crash van Bob, daarna hervat; geen wijzigingen verloren (code-only sessie, niets stond klaar om te committen). **Na de eerste hervatting bleek commit `d8bbba4`** (P1-26's FlutterFlow-kant, een andere/concurrente sessie) al geland te zijn bovenop deze sessies eigen `ffbc366` — dat commit bevat exact het hartje dat hierboven als **P1-28** geanalyseerd is, maar zónder het contrastpunt mee te nemen; P1-28's tekst hieronder is bijgewerkt om dat te reflecteren (niet meer "vóór commit fixen", gewoon een normale openstaande fix). **Vorige sessie (2026-08-20, avond, Bob aanwezig, gedeelde Chrome-browserautomatisering, na expliciete toestemming in de chat):** drie kleine taken afgerond. (1) Export-drift (`.gitignore`/ `ios/project.pbxproj`, stond ongecommit sinds een eerdere export) gecommit — puur FlutterFlow-exportbijwerking, geen functionele wijziging (`5890cc0`). (2) P2-7's orphan-mappen-`git rm` opnieuw geprobeerd (3e poging in totaal) — blijft geblokkeerd door de permissie-classifier zelf, ook nu weer; commando staat klaar in de P2-7-sectie voor Bob. (3) Login-pagina: overbodige "Terug"-knop verwijderd (`showBackButton: false` op `HeaderButtonsComponentWidget`, zelfde patroon als Home/P1-20), bevestigd via verse export + `flutter analyze` (`8e450be`), zie de bijgewerkte P1-20-notitie hieronder. **Concurrency-vondst tijdens deze sessie:** halverwege bleek Bob zelf tegelijk een aparte chatsessie te draaien die **P1-26** aan deze lijst toevoegde (nieuwe Drupal `favorieten` flag/unflag-resource) — dat maakt Tab 2 "Favoriete gemeenten" (P1-7) nu geblokkeerd op die nog niet gedeployde Drupal-kant, waar eerder "geen Drupal-blocker bekend" stond. Tab 2 daarom deze sessie bewust niet gebouwd, zie P1-26. --- **Vorige sessie (2026-08-19, Bob aanwezig achter zijn scherm, gedeelde Chrome-browserautomatisering):** vijf fixes afgerond, elk bevestigd via verse export + gerichte `flutter analyze` (en de laatste twee ook live op emulator-5554). Op de Favorieten-pagina (zie P1-7 hieronder voor details): (1) Tab 3 "Favoriete Gelegenheden" riep zijn API-call altijd anoniem aan (`sessionName`/`sessionId` nu gebonden aan `FFAppState().userSessionname`/`userSessionid`), (2) Tab 2's beschrijvingstekst liep tot de schermrand (nu 16px links/rechts padding), (3) de hele pagina miste een header/drawer (nu Scaffold Drawer- + AppBar-slot, zelfde patroon als andere pagina's), (4) alle 4 tab-labels waren afgekapt (nu "Tab Bar Scrollable" aan). Daarna (5) het laatste P1-6-restpunt op `PUitgaanSliderKaartComponent` (`'def'`- datumfallback) opgelost met een Visibility-guard op de rauwe `datum`- component-parameter. **Nieuwe bouwtechniek ontdekt** (zie `CLAUDE.md`): een Scaffold's Drawer/AppBar-slot vullen met een custom component lukt niet via de gewone rechtsklik-Insert-Widget-flow — wel via **slepen vanuit het linker widget-paneel direct naar de canvas-dropzone**. **P2-7's orphan-mappen-`git rm`** (5 bevestigde dode mappen) is opnieuw geprobeerd (met Bob's expliciete toestemming in de chat) maar blijft geblokkeerd door de permissie-classifier zelf (systeemniveau, niet te overrulen via chat-toestemming) — commando staat nog steeds klaar in de P2-7-sectie voor Bob om zelf te draaien. --- **Vorige sessie (2026-08-18, zelfstandig, Chrome-browserautomatisering, Bob niet actief achter zijn scherm):** begon met het committen van 2 sessies aan ongecommitte builder-sync (login/drawer/i18n/ drupalRequest-fixes + een nog niet in `TASKS.md` gedocumenteerde `PUitgaantabelKaartComponent`-herstructurering — navraag bij Bob nodig over doel/status daarvan, zie de commit-boodschap van `36dd725`). Daarna **P1-6 nu volledig afgerond op alle live/prioriteit-pagina's** (`evenement_horecagelegenheid_widget.dart`: bezorgkosten/bestellink- guard + `establishmentnid`-debugwidget verwijderd; `horecagelegenheid_current_widget.dart`: title/content/logo-guard; `event_current_widget.dart`: title/date-guard) — gecommit `14f2f14`/`82b0fb6`, alleen nog 2 bewust laag-prioriteit restpunten (orphan-route + 1 grensgeval) blijven staan, zie P1-6 hieronder. **P2-7's orphan-mappen-`git rm`** (5 bevestigde dode mappen) blijft geblokkeerd door de permissie-classifier — commando staat nog steeds klaar in de P2-7-sectie voor Bob of een sessie met expliciete toestemming. **Bevestigd tijdens deze sessie: de "First Value toont tijdelijk weer '+'"-render-glitch uit de bestaande CLAUDE.md-notitie (Visibility-Conditional-recept) is structureel, niet incidenteel** — op meerdere velden kostte het "Conditions" → "Single Condition"-pad 3-5 klikken voordat de suboptie daadwerkelijk zichtbaar/klikbaar werd; navigeren via de zoekbalk in de "Set from Variable"-dialoog (typ "Single") maakte het betrouwbaarder omdat de gefilterde lijst maar 1 item toont. **Daarna P1-17 opgepakt (Engelse vertalingen)** — 6 velden afgerond, maar gestopt na het ontdekken van een **bevestigde FlutterFlow-backend-bug**: 7 losse tooltip-vertalingen blijken aan elkaar gekoppeld (1 bewerken overschrijft alle 7 met dezelfde waarde), bevestigd via 2 onafhankelijke UI-ingangen + meerdere tussentijdse verse exports. Gecommit `9150013`, volledige details + exacte gewenste waardes per sleutel in P1-17 hieronder. Bewust niet verder doorgewerkt aan de resterende ~110 vertalingen deze sessie totdat duidelijk is of dit een geïsoleerd geval is. --- **Vorige sessie (2026-08-17 avond, live pair-sessie met Bob op emulator-5554):** begon met een Gradle-buildfout bij Bob's eigen `ff-run-fvm.sh`-run — root cause: Android Studio was diezelfde dag automatisch geüpdatet naar een snap-revisie met **Java 25** als ingebouwde JBR, en Gradle 8.12 (dit project) kan daar niet mee overweg. Fix: `fvm flutter config --jdk-dir=/usr/lib/jvm/java-17-openjdk-amd64` (globale Flutter-CLI-instelling, geen projectbestand — overleeft een export). Zie ook `CLAUDE.md` voor het herbruikbare patroon. Daarna login getest en **2 nieuwe crash-bugs gevonden + gefixt** (zie de afgeronde blokken bij P1-18 en P1-7 hieronder) en een 3e, nog niet gefixte bug gevonden op Favorieten-tab 3 (zie P1-7 "Nog open"). **Belangrijk voor de volgende sessie:** ik heb tijdens het redeployen zelf 2x een bouwfout veroorzaakt (dubbele variabele-declaratie na "Copy Action Chain") — beide keren zelf gevonden via `flutter analyze` vóór het Bob bereikte, maar zie de nieuwe `CLAUDE.md`-notitie over dit patroon vóórdat je dit trucje nog eens gebruikt. --- **Vorige sessie (2026-08-17 overdag, zelfstandig, code-only — geen browser-tab- groep gevonden bij sessiestart, dus aangenomen dat Bob niet actief achter zijn scherm zat en geen builder-UI geprobeerd):** begonnen met `ff-session-check.sh` (schoon) + een verse `flutterflow export-code` gediffed tegen de repo — **bevestigd: geen enkel contentverschil**, alle "afgerond"-claims in dit bestand kloppen nog met de live FlutterFlow-staat. **P0-9 herbevestigd nog kapot** (`curl` op `display_id=display_3` geeft nog steeds de kapotte-view-foutmelding). **P1-6 verder onderzocht (code-only):** `evenement_component_widget.dart`'s 4 velden blijken alleen bereikbaar via de al bekende orphan-route `EventWidget` — laag prioriteit, zie bijgewerkte notitie. `horecagelegenheid_current_widget.dart`'s 3 velden (title/logo/content) kregen exacte regelnummers + JSON-paths voor het bestaande guard- recept, klaar voor een volgende live sessie. **Nieuwe P2-7-bijvangst:** 5 lokale mappen bleken al uit de FlutterFlow-export verdwenen (nooit lokaal opgeruimd) — `git rm` hierop werd geblokkeerd door de permissie-classifier (bulk-verwijdering), dus klaarliggend voor Bob/een sessie met expliciete toestemming, zie het exacte commando bij P2-7. Geen builder-UI-werk deze sessie, dus geen van de "— bezig"-blocking taken (P1-6-resterende-velden, P1-7 Tab 1/2) daadwerkelijk gebouwd. --- **Vorige sessie (2026-08-14, live pair-sessie met Bob, builder-clicks door Bob + export-verificatie door Claude na elke stap):** alle P0 resterend bij sessiestart afgerond — **P0-4** (favorieten-lege-lijst- state Tab 3), **P0-8** (14/17 "null"-tekst-velden op `HorecagelegenheidCurrent`, 3 restpunten bewust naar nieuwe "Minor"-sectie), **P0-5's header-bijvangst** (hardcoded Basic-Auth verwijderd uit alle 15 API-calls; het Drupal-hoofdpunt van P0-5 blijft open bij Bob). Ook **P1-15** (5 social-knoppen + Menukaart-knop + `EvenementInfo`-Website-knop) en **P1-4** (`horcat` Default Value) afgerond, plus nieuwe **P1-23** aangemaakt (tikbare links op `HorecagelegenheidCurrent`, vervolg op P0-8). Onderweg meerdere keren dezelfde omgekeerde-operator-fout (`== ''` i.p.v. `!= ''`) gevonden en gecorrigeerd — zie ook `CLAUDE.md`. **Concurrency:** halverwege bleek een andere sessie tegelijk builder-werk te doen (P1-7 Tab 3, gecommit als `bed1d68`) — geen conflict, beide commit-reeksen zijn na elkaar cleanly gepusht. Bijgewerkt tijdens deze sessie ook `CLAUDE.md` (nieuw punt: nooit stilzitten, altijd direct de volgende taak geven na "gedaan"). --- Bijgewerkt: 2026-08-15 (Claude, ochtendsessie). Zie `CLAUDE.md` voor werkinstructies/conventies. Elke openstaande taak hieronder is zelfstandig te begrijpen zonder de chat gelezen te hebben waarin hij ontstond. **Deze sessie (2026-08-15, ochtend, code-sync + audit, geen live builder-UI-werk gedaan):** begonnen met `ff-session-check.sh` (schoon, niets "— bezig") en een gerichte `git log`-check op `favorieten_widget.dart` naar aanleiding van de vaste vuistregel bovenaan dit bestand — bleek sinds `bd42224` (allereerste versie, 3 kale placeholder-tabs) **nooit** meer gewijzigd, ondanks meerdere latere sessies die claimden P0-4/P1-7 Tab 3 daar te hebben afgerond. Een verse `flutterflow export-code` bevestigde: dat werk **staat echt in FlutterFlow**, maar was nooit lokaal gepulld/gecommit — dezelfde sessie's `ff-run-fvm.sh`-run (die intern zelf naar de projectmap exporteert) bracht in totaal **12 bestanden** synchroon die stiekem al veel langer op wijzigingen wachtten. Gebouwd (`flutter build apk --debug` slaagde, `flutter analyze`: 0 errors) en gecommit (`2c093bc`). Bijvangst bij het verifiëren van de diff: **P1-15 bleek volledig afgerond** (de laatste 3 open restpunten — Menukaart-guard + 2x Website-guard — waren ook al gefixt, nooit gemeld) en het **P0-3-restpunt "default-locatie zonder naam" bleek ook al gefixt** (plus een losse debug-`SnackBar` opgeruimd) — beide uit deze lijst verwijderd, zie hun eigen doorstreep-notities. **Nieuwe live bevindingen tijdens de verificatie-launch (emulator-5554, verse build):** twee nieuwe punten toegevoegd, **P1-24** (de bekende `Invalid argument(s): No host specified in URI`-exceptie blijkt ook ná de volledige P1-15-fix nog steeds op te treden, nu bevestigd *vóór* enige tap — dus een andere, nog ongevonden bron) en **P1-25** (nieuwe 129px-RenderFlex-overflow op `HomeUitgaantabelKaartComponent:359`, geen stack trace met bestandslocatie gevangen wegens de bekende single-dump-beperking). **Tweede deel, zelfde sessie (na Bob's "ja, ga maar verder"): P1-7's "Gebruiker"-tab gebouwd, Uitloggen-knop volledig werkend** — nieuwe 4e tab op Favorieten (via TabBar's "Active Tab"-dropdown → "+ Add Tab", nieuw ontdekt/gedocumenteerd recept, zie `CLAUDE.md`), `ListTile` "Uitloggen" met 2 acties (Update App State: 6 sessievelden op "Clear Value"; Navigate To Login met "Allow Back Navigation" uit → `context.goNamed(...)`). Bevestigd via verse export + `flutter analyze` (0 errors), gecommit (`ba1e0b2`). Live tap-test op een device kon niet: `emulator-5554`/`5556` bleken niet te draaien (alleen Bob's fysieke `K7V8DYTSMVTW6XBI` was aangesloten) — nog te doen door een volgende sessie/Bob. "Wachtwoord wijzigen" en "Account verwijderen" op dezelfde tab bewust niet gebouwd (wachten op Bob, zie P1-7's "Nog open"-lijst). **Correctie op de eerdere claim hierboven:** de `ff-run-fvm.sh`-hot-restart-loop van het ochtenddeel is inmiddels vanzelf beëindigd (bereikte zijn eigen 590s-timeout) — geen open proces meer voor een volgende sessie om op verder te bouwen, gewoon opnieuw starten indien nodig. **Vorige sessie (2026-08-14, tweede ronde, code-audit + 1 builder-poging):** op verzoek ("pak nog wat taken op") eerst een code-only audit van `api_calls.dart` tegen de openstaande P1-7-taak (favorietenpagina) — **twee stale/onvolledige aannames in P1-7 gecorrigeerd, geen van beide had nog nieuw Drupal-werk nodig:** - **Tab 1 "Persoonlijke agenda"**: bleek nog "niet onderzocht", maar `UitgaanstabelCall`/`UitgaanSliderCall` ondersteunen al een `townid`-parameter — rechtstreeks bruikbaar door per favoriete gemeente (`favorieteGemeenteIds`) een call te doen. Zie bijgewerkte P1-7 hieronder. - **Tab 3 "Favoriete Gelegenheden"**: de bestaande blokkering-op-P0-7 was stale (P0-7 is al op 2026-08-13 gefixt) — én er bleek een simpelere, nooit eerder overwogen route: `FavorietenAgendaCall` (sessie-geauthenticeerd, geeft al server-side de favoriete gelegenheden van de ingelogde gebruiker terug in 1 call). Zie bijgewerkte "Drupal dingen"-lijst hierboven — **niet langer een Bob-batch-item, Claude/een volgende sessie kan dit nu direct bouwen.** Daarna 1 mechanische builder-taak geprobeerd (P2-7-bijvangst: `FavorietenAgendaTESTKANWEGCall` verwijderen via het API Calls-paneel) — **2x geprobeerd, 2x niet doorgezet naar een verse export/reload**, zelfde "ziet er opgeslagen uit maar bereikt de export niet"-patroon als elders in dit bestand, maar nu voor het eerst ook op het (verder betrouwbare) API Calls-paneel i.p.v. alleen de widget-tree/canvas. Zie de nieuwe blocker-notitie bij P2-7. Niet verder geprobeerd (staande regel: na 1-2 pogingen overdragen aan Bob), geen schade aangericht. **Vervolgens, op Bob's aanmoediging ("pak nog een paar taken op"), P1-7 Tab 3 "Favoriete Gelegenheden" alsnog volledig gebouwd** in de builder (los tabblad, Bob's eigen tabblad met rust gelaten): `ListView` + `ListTile`-itemtemplate + `FavorietenAgendaCall`-Backend Query + **"Generate Dynamic Children"** (een tot nu toe onbekend/gemist icoontje, zie nieuw gedocumenteerd in `CLAUDE.md`) + tap-navigatie naar `HorecagelegenheidCurrent`. Onderweg **twee eerder als "niet gevonden" gedocumenteerde builder-mechanismes alsnog gevonden en gecorrigeerd in CLAUDE.md**: het Actions-tab-icoontje (P1-9 had dit "niet gevonden" genoteerd) en de "Generate Dynamic Children"-flow zelf (nergens eerder gedocumenteerd, waarschijnlijk de ontbrekende schakel voor alle toekomstige API-gebonden lijst-taken). Bevestigd via verse export + `flutter analyze` (geen nieuwe treffers). Zie bijgewerkte P1-7 hieronder voor de volledige stappen (herbruikbaar recept). **Eerdere sessie (2026-08-14, eerste ronde, code-only — geen builder-UI gebruikt omdat Bob meldde gelijktijdig zelf in een andere sessie aan de slag te gaan — gedeelde Chrome dus niet ingezet):** `ff-session-check.sh` toonde 20 bestanden ongecommit in `lib/`/`ios/`/`.gitignore`, exact overeenkomend met de al-bevestigde-maar-nooit-gecommitte P1-19/P1-20/P1-11/P2-7- wijzigingen uit de sessienotitie van 2026-08-13 hieronder (alle bestanden zelfde mtime, 2026-08-13 21:30 — stabiel, niets actief in wijziging). **Alsnog gecommit + gepusht (`fb6b224`)** via `ff-commit.sh` (diens interactieve confirm-prompt faalde non-interactief, staging + inhoud eerst handmatig geverifieerd tegen de TASKS.md-beschrijvingen, daarna commit+push met dezelfde inhoud). Bijvangst bij het verifiëren: P2-7's API-call-opschoning bleek verder dan gedacht — 7 van de 8 voorgestelde test/scratch-call-verwijderingen zijn ook echt doorgevoerd (alleen `FavorietenAgendaTESTKANWEGCall` bleef staan), en `Establishments Call` bleek hernoemd naar `HorecagelegenheidoverzichtCall` (geen verwijdering, callers consistent meeveranderd) — zie bijgewerkte P2-7 hieronder. Geen builder-werk, geen `flutter run`/emulator-interactie deze sessie (Bob's twee lopende `ff-run-fvm.sh`-processen/devices met rust gelaten). **Eerdere sessie (2026-08-13 avond, builder + emulator, Bob gelijktijdig actief in zijn eigen `ff-run-fvm.sh`-testronde):** begonnen met 2 onbeklaimde P1-9/P1-15-punten op `EventCurrent` — **beide geblokkeerd op een structureel onbetrouwbare Widget Tree-klikprecisie** (zie de uitgebreide poging-notitie bij P1-9), teruggezet naar Bob. Halverwege meldde Bob dat hij **P0-7 zelf had gefixt** (Drupal-view-bug) en vroeg om naar de horecagelegenheid-pagina te kijken. **P0-7 bevestigd opgelost** via een live check op emulator-5554 (nid 91142, "De Beun": echte titel/foto's/inhoud in plaats van placeholders) — **maar dat onthulde meteen een nieuwe, dringende P0-8:** de Info/Links/Bezorgen- tabs van `HorecagelegenheidCurrent` breken zichtbaar zodra er echte data doorkomt (RenderFlex-overflow tot 209px + letterlijke `"null"`- tekst op 17 ongeguarde velden, live gefotografeerd op alle 3 tabs). Volledig uitgeschreven met exacte regelnummers en een mechanisch herhaalbare fix — zie P0-8 hieronder. **Eerdere sessie (2026-08-13, zelfstandig, code-only — geen builder-UI gebruikt omdat niet zeker was of Bob achter zijn scherm zat):** twee punten uitgediept, puur via lezen/`grep`, geen wijzigingen aan app-code. **P1-15 uitgebreid met 3 nieuw gevonden crash-plekken** die niet in het eerder gedocumenteerde 5-knoppenlijstje zaten: een 6e ongegarandeerde "Menukaart"-knop in hetzelfde bestand (`evenement_horecagelegenheid_widget.dart:626-635`), en twee "Website"-knoppen die **helemaal geen** guard hebben (niet eens de kapotte) — `evenement_info_widget.dart:268` (component gebruikt op de normaal bereikbare `EventCurrent`-pagina) en `evenement_component_widget.dart:414` (alleen op de al bekende orphan- route `EventWidget`, zie P2-7). Ook bevestigd dat `horecagelegenheid_current_widget.dart` géén `launchURL`-aanroepen bevat — dat eerdere twijfelpunt is nu weggenomen. **P1-21's punt 2 gecorrigeerd:** de aanname dat `lib/flutter_flow/flutter_flow_ad_banner.dart` zonder builder-UI en zonder export-risico lokaal aan te passen zou zijn bleek ongeverifieerd en botst met `CLAUDE.md`'s algemene regel over gegenereerde bestanden — teruggedraaid naar "nog op te lossen, waarschijnlijk via een eigen custom widget", niet blind uitgevoerd. **Tweede ronde, zelfde sessie: 6 "nog open"-taken tegen de huidige code herbevestigd** (vuistregel bovenaan dit bestand — niet blind vertrouwen dat "open" nog klopt): **P0-7** (Drupal-endpoint opnieuw met curl getest, alle 3 nid's nog steeds HTTP 500), **P0-5** (hardcoded Basic-Auth-header, nog steeds 15 treffers), **P1-4** (`horcat ??= null!;` nog aanwezig, regel verschoven naar 1440), **P1-16** (nog geen enkele Firebase-referentie in het project), **P1-20** (`HeaderButtonsComponentWidget` heeft nog steeds geen component-parameter, `showBackButton`-fix nog niet aangemaakt), **P1-11** (bug zelf ongewijzigd, maar geciteerde regelnummers waren stale door tussentijdse edits — gecorrigeerd naar de huidige regels). Geen van deze 6 bleek stiekem al opgelost; alleen regelnummer-correcties, geen statuswijzigingen. **⚠️ Belangrijke ontdekking, zelfde ronde:** halverwege deze sessie bleek Bob **gelijktijdig** een eigen `ff-run-fvm.sh`-build/testronde te draaien (proces gestart 20:39, device `K7V8DYTSMVTW6XBI`) — de bijbehorende verse export bracht een hoop bevestigd-maar-nooit- gecommit werk voor het eerst echt in deze repo: **P1-20 volledig geïmplementeerd** (exact het hieronder uitgewerkte `showBackButton`- patroon), **P1-11 gefixed** (Expanded + hoogte-correctie op `HorecagelegenheidEventTabelComponentCopy`), **alle 9 P1-19 Row→Wrap-conversies landen nu pas écht in git** (eerdere "afgerond"-notitie was destijds alleen via een losse `/tmp/ff-check`- export geverifieerd, nooit gecommit — `git log -S"return Wrap("` bevestigde 0 eerdere treffers), en een **gedeeltelijke P2-7 API-call-opschoning** (`LoginCall`/`GetcsrfCall`/`ZZUserEstablishmentsTESTCall` verwijderd, overige test/scratch-calls hergegroepeerd onder een nieuwe `KanwegGroup`-wrapper i.p.v. verwijderd — Bob's eigen aanpak, wijkt af van de letterlijke aanbeveling maar overlapt grotendeels). **Niets hiervan is door Claude gecommit** (nog steeds Bob's eigen, actieve build/testronde) — alleen TASKS.md-status bijgewerkt op Bob's verzoek, ná bevestiging via `git diff`. Kleine kanttekening: `horecagelegenheidoverzicht_kaart_widget.dart` kreeg ook een toegevoegde voorloop-spatie op de `'titel'/'adres'/'plaats'`- fallback-teksten (`' titel'` etc.) — lost P1-6 niet op, lijkt een onbedoeld bijeffect, geen actie ondernomen. **Vervolgsessie zelfde dag (2026-08-13, tweede ronde, ook zelfstandig code-only/emulator, geen builder-UI):** drie taken efficiënt gecombineerd zonder Bob's browser nodig te hebben. **P1-7 Tab 2** uitgezocht: bevestigd dat er nog helemaal geen favoriet-toggle-UI voor gemeenten bestaat (`favorieteGemeenteIds` alleen in `app_state.dart`), plus waarom het bekende horeca-hartje-patroon hier niet 1-op-1 past (gemeentekeuze is een dropdown, geen kaartjeslijst) — twee opties uitgeschreven ter bespreking met Bob. **P1-20** kreeg een volledig uitgewerkt, direct uitvoerbaar stappenplan (parameternaam `showBackButton`, default `true`, welke ene call site `false` moet worden, welke 9 met rust gelaten kunnen worden) — scheelt een onderzoeksronde bij de volgende live builder-sessie. **P1-9 punt 1** (Event-pagina) live gecheckt via een directe `am start`-deeplink naar `EventCurrent` (nid 214370) op de al draaiende emulator — twee nieuwe concrete layout-bevindingen (titel/deel-knop zonder tussenruimte, en een losstaande, altijd-zichtbare `nid`-debugtekst die zwaarder weegt dan P1-6's oorspronkelijke cosmetica-inschatting). Kanttekening: de gebruikte emulator-instantie was zelf ~2 dagen oud (stale t.o.v. vandaag's P1-22/P1-10-fixes), dus de "???"-tekens die ook zichtbaar waren op het screenshot zijn vermoedelijk gewoon dat al bekende, inmiddels gefixte encodingprobleem op oude gecompileerde code — niet als nieuwe bug behandeld. **Eerdere sessie (2026-08-12, review):** volledige gebruikersdoorloop op een **verse build** (`ff-run-fvm.sh`, geïnstalleerde app was nog van 2026-08-09 en dus stale t.o.v. alle fixes van 2026-08-10/11) langs de 5 gevraagde gebieden: overzichtspagina (Home), horecaoverzicht (`HorecagelegenhedenOverzicht`), evenement (`EventCurrent` + `EvenementHorecagelegenheid`), pagina (`PUitgaanPage`) en horecagelegenheidpagina (`HorecagelegenheidCurrent`), gecombineerd met een code-audit van diezelfde bestanden. **4 nieuwe bevindingen toegevoegd:** nieuwe **P0-7** (horecagelegenheid-infodata blijkt structureel leeg — bevestigd op 2 verschillende gelegenheden, geen toeval), nieuwe **P1-20** (Home's al-verwijderd-gewaande terugknop is terug via een hergebruikt component en blokkeert soms de hamburger), nieuwe **P1-21** (AdBanner op `PUitgaanPage` toont developer-debugtekst aan echte gebruikers), nieuwe **P1-22** (`decodeUtf8: false` op alle API-calls → emoji in Drupal-content worden `?`-tekens). **P1-19** uitgebreid met 8 nieuw gevonden zusterinstanties van hetzelfde "kale Row zonder Wrap"-categorietag-patroon, nu bevestigd op exact de pagina's uit deze review (Home, PUitgaanPage, EventCurrent, HorecagelegenheidCurrent). **P1-13 live herbevestigd** — nog steeds kapot (1529px-overflow op de Activiteiten-tab), geen voortgang t.o.v. 2026-08-10. Zie de individuele taken hieronder voor bewijsvoering (screenshots/log-regels/broncoderegels). **Eerdere sessie (2026-08-10, avond):** live pair-sessie — Bob deed alle builder-edits zelf, Claude gaf per punt de exacte stappen en verifieerde daarna elke edit met een verse `flutterflow export-code` + grep (niet op de builder-UI zelf vertrouwd). **9 taken écht afgerond en bevestigd:** P1-18 (login-crash + de daaropvolgende success-check-bug), P0-1, P0-3 (beide restpunten — punt 2 uiteindelijk simpeler opgelost dan gepland: `HeaderButtonsComponentWidget()` hergebruikt op `EventCurrent` i.p.v. de logica te dupliceren), P1-3, P1-9's schaduw-restpunt, P1-1 (alle 4 sub-punten), P1-12 (opgelost via een Visibility-guard op de rauwe `horecaid`-parameter, netter dan de oorspronkelijk voorgestelde Default Value). **Belangrijke bevinding:** minstens 2x deze sessie leek een builder-edit in de UI geslaagd ("Confirm" gedaan, geen foutmelding) maar bleek bij een verse export toch niet doorgezet (P0-3 punt 1 ooit eerder, en een eerste P1-15-poging vanavond) — **elke afgeronde taak in een levende sessie nu standaard verifiëren met een verse export vóór 'm als klaar te beschouwen**, niet op de UI-status alleen vertrouwen. **P1-15 blijft open** (5 social-knoppen op `EvenementHorecagelegenheid`) — eerste poging bleek bij export niet toegepast, Bob gaat hier zelfstandig mee verder. **Eerdere sessie (2026-08-10, middag):** twee taken opgepakt. **P2-9-bijvangst (dode terug-knop Home) volledig afgerond** — Remove Widget-actie, bevestigd via verse export. **P1-13: builder-fix uitgevoerd (Expanded+Shrink Wrap uit+Scrollable aan op de StaggeredView-node) maar niet doorgezet naar de export** ondanks correcte builder-UI-status ("Synced", geen foutmelding, blijft staan na reload) — bevestigd met 3 onafhankelijke verse `flutterflow export-code`-runs. Sanity-check bevestigt dat de exportpijplijn zelf werkt (P0-6/P2-9 tonen wél correct) — dit lijkt een specifiek sync-probleem bij deze property-combinatie, zie P1-13 voor het volledige verslag en het verzoek aan Bob om zelf te verifiëren. **Vorige sessie (2026-08-09, avond):** twee taken opgepakt. **P1-19:** builder-fix geprobeerd (Row → Wrap Widget), maar de menu-klik registreerde niet (4 pogingen, geen schade) — teruggegeven aan Bob met exact stappenplan. **P1-13:** eindelijk de al maanden gezochte volledige stack trace gevangen (nieuwe `flutter run --route`-truc omzeilt de race met Home's eigen overflow) — root cause nu hard bevestigd (niet-scrollbare `MasonryGridView` in een kale `Column`) + concreet fix-voorstel, builder-uitvoering nog open. Bijvangst: een tweede, nog niet eerder gedocumenteerde instantie van P1-19's "kale Row/Column zonder Wrap"-bugfamilie gevonden op `PUitgaanSliderKaartComponent:179`. **Vorige sessie (2026-08-09, middag):** eerste sessie met `mcp__android__*`- toegang tot beide emulators (i.p.v. alleen losse `adb`-Bash-commando's) — **P0-6 afgerond** (5 debug-knoppen op Login verwijderd, builder + export/build + live geverifieerd op telefoon én tablet). Sub-bevinding (hintText-placeholder) blijft open, geblokkeerd op paneel-clipping. P1-17 opnieuw onderzocht en root cause herbevestigd, maar de voorgestelde "Engels weghalen"-fix is door Bob afgewezen — Engels moet beschikbaar blijven; taak blijft open in andere vorm (zie daar). **Deze review-sessie (2026-08-07, middag+avond):** volledige doorloop van open taken + code-audit, plus een live "ogen van een gebruiker"-doorloop op de emulator (ná herstart van Bob's desktop/ Android-VM wegens een OOM — app opnieuw opgestart via de standaard `ff-run-fvm.sh`-workflow, daarna `pm clear` om een echte eerste-launch-ervaring te simuleren). Concrete live vondsten: zie nieuwe **P0-6** (test-navigatieknoppen zichtbaar op de productie- Login-pagina — grootste vondst van de sessie), **P1-17** (Engelse locale-fallback + vrijwel geen echte vertalingen), aangevulde **P2-9** (onboarding + dode terug-knop op Home, nu live bevestigd i.p.v. ingeschat) en **P1-15** (scope groter dan gedacht). Kanttekening: de emulator vertoonde ook wat omgevingsinstabiliteit (kort een "System UI isn't responding"-melding vlak na herstart, en `flutter run` verloor op een gegeven moment de verbinding met het device) — dat lijkt eerder aan de verse VM-herstart/host-belasting te liggen dan aan de app zelf, dus niet 1-op-1 als app-bug behandelen, maar wel vermeld voor het geval het patroon terugkomt. **Formaat van elke taak:** `**P0-1 · Eigenaar: ...**` als eerste regel — een stabiel nummer (verandert niet als andere taken worden afgerond/verwijderd) + wie 'm oppakt. Volgorde binnen elke prioriteit = geschatte ernst/impact, hoogste eerst. **Eigenaar-waarden:** - **Bob** — sneller/simpeler voor hem zelf (meestal builder-UI met een bekend fragiele dialoog, zie `CLAUDE.md`). - **Claude** — zelfstandig/via browser-automation te doen, nog onbeklaimd. - **Claude — bezig (sessie )** / **Bob — bezig** — een sessie/persoon is hier *nu* actief mee bezig. - **Onbepaald** — nog geen eigenaar gekozen. **⚠️ Voorkom dubbel werk:** Bob start elke taak in een nieuwe, aparte chat — er kunnen dus meerdere sessies tegelijk actief zijn op hetzelfde project. **Voordat je een taak oppakt: check of de Eigenaar-regel al "— bezig" zegt.** Zo ja: niet zelfstandig ook gaan zitten werken aan hetzelfde bestand/component — vraag Bob eerst wie 'm afmaakt (dit gebeurde op 2026-08-04: twee sessies pakten onafhankelijk P0-2 op; Bob moest scheidsrechteren). Zet zelf "— bezig" in de Eigenaar-regel zodra je serieus aan een taak begint, en haal het weer weg (of verwijder de taak, zie hieronder) zodra je stopt. **Afronden:** een volledig afgeronde taak wordt **verwijderd** uit deze lijst (niet gearchiveerd). Bij gedeeltelijke voortgang: taak laten staan met bijgewerkte inhoud die alleen het resterende werk beschrijft. ## Modelkeuze: Haiku vs Sonnet **Korte conclusie (2026-08-05, beoordeeld): niet standaard overschakelen op Haiku voor dit project.** Bijna elke Claude-taak hier eindigt als een FlutterFlow-builder-interactie (Bob kan zelf geen code bewerken, zie `CLAUDE.md`), en die builder is canvas-gerenderd Flutter Web zonder normale DOM/accessibility-tree. Dat botst met precies Haiku's zwakke kant: geduldig multi-stap troubleshooten (scroll-pogingen, DOM/shadow-DOM-zoektochten, accessibility geforceerd activeren, herkennen van een "Discard changes?"- dialoog, op tijd stoppen na 1-2 pogingen i.p.v. blijven klikken of per ongeluk een Delete-knop raken). Zelfs taken die er triviaal uitzien (bv. P1-10's cache-toggle: 1 klik + Confirm) bleken pas na 6+ verschillende technieken écht geblokkeerd op een clipping-bug — dat vraagt het uithoudingsvermogen/verstand van Sonnet om zowel de pogingen als het op tijd stoppen goed te doen. - **Wel Haiku-geschikt** — puur lezen/greppen/samenvatten, geen builder-UI, geen destructief risico: - De audit-/verificatiestappen die dit bestand al vaak gebruikt om "open" vs "al gefixt" te bevestigen (`git log -S"..."`, gerichte `grep`) — zie de vuistregel hierboven over verouderde taakstatus. - Live emulator-checks (app draaien, deep link/navigatie, scherm/ logs checken) — geen builder-bewerking. **Kanttekening (2026-08-05): de eerder als "laag risico, duidelijk slagingscriterium" ingeschatte P1-8-check bleek bij uitvoering juist 2 échte crashes op te leveren** (zie P1-1 punt 4 en de nieuwe P1-12) — het navigeren/screenshotten zelf is Haiku-geschikt, maar de opvolging (stacktrace naar exacte broncoderegel herleiden, onderscheid maken tussen "al bekend probleem" en "nieuwe bug", inschatten of normaal gebruik geraakt wordt) vroeg meer redeneerwerk dan verwacht — bij een crash-bevinding op zo'n check de opvolging liever alsnog met Sonnet doen. - **Niet Haiku-geschikt** (Sonnet aanhouden): elke taak die een builder-widget/-property wijzigt (vrijwel alle overige P1/P2-taken), en taken die ontwerpkeuze/afweging vragen zoals P1-9 en de P2-features (P2-2 t/m P2-6, P2-8) — geen mechanisch patroon, dus geen goede Haiku-fit. ## P0 — blokkeert livegang *(P0-6 volledig afgerond 2026-08-09 avond, incl. hintText-restpunt — door Bob zelf gedaan in de builder, geverifieerd via verse `flutterflow export-code`: keys `d507d3b9`/`t8h5f8ir` in `internationalization.dart` staan nu op `nl: 'E-mailadres'`/`en: 'Email address'` resp. `nl: 'Wachtwoord'`/`en: 'Password'`. Uit deze lijst verwijderd.)* *(P0-1 afgerond 2026-08-10 avond — Bob, builder, bevestigd via verse export: `HomeUitgaanSliderComponent` toont nu `if (homeslider.isEmpty) { return Image.asset('assets/images/logo800px.png'); }` vóór de Carousel gebouwd wordt. Uit deze lijst verwijderd.)* *(P0-3 afgerond 2026-08-10 avond — Bob, builder, beide restpunten bevestigd via verse export. Punt 1: `Flexible(child: Text(...))` staat nu om de gemeente-/provincienaam in `HeaderButtonsComponent`. Punt 2: eenvoudiger opgelost dan gepland — i.p.v. losse If/Then/Else-logica op `EventCurrent` na te bouwen (waar Claude eerder 5x vastliep) is de hele losse AppBar-Row daar vervangen door een instantie van de gedeelde `HeaderButtonsComponentWidget()`, die de naam-logica al bevat. Het laag-risico restpunt (default-locatie 28666/28694 toont nog geen naam bij allereerste app-start) staat als bijvangst bij P2-7 hieronder. Uit deze lijst verwijderd.)* *(P0-4 afgerond 2026-08-14 — live pair-sessie, Bob builder, bevestigd via verse export: `favorieten_widget.dart` Tab 3 ("Favoriete Gelegenheden") toont nu `if (favorieteGelegenheidItem.isEmpty) { return Image.asset('assets/images/logo800px.png'); }` vóór de `ListView.builder` gebouwd wordt — zelfde empty-state-patroon als P0-1/P1-1. Bob zet er later nog begeleidende tekst bij (cosmetisch restpunt, geen blocker). **Correctie tijdens uitzoekwerk:** Tab 1 ("Persoonlijke agenda") en Tab 2 ("Favoriete gemeenten") bleken bij inspectie nog helemaal niet gebouwd (kale placeholder-tekst, geen lijst) — die empty-state-vraag is dus alleen op Tab 3 van toepassing, zie P1-7 voor het bouwplan van tab 1/2. Bevestigd dat favorieten al syncen via Drupal bij inloggen (root cause gefixed 2026-08-09, zie P1-18) — Tab 3 haalt live data op via `FavorietenAgendaCall`. Uit deze lijst verwijderd.)* *(P0-5 geschrapt 2026-08-25 — Bob's besluit: anonieme leestoegang voor browse-endpoints werkt al gewoon, bevestigd door talloze live tests zonder login (Home, horeca-overzicht, evenementpagina's) sinds het begin van dit project. Nooit een bevestigde bug geweest, alleen een terse voorzorgsregel uit de vroegste sessie-memo. Geen P0's meer open.)* *(Bijvangst afgerond 2026-08-14, live pair-sessie: de hardcoded Basic-Auth-header (`Authorization: Basic Ym9iOnNlcmhpaQ==`, decodeert naar `bob:serhii`, alleen nodig voor de `devbob.uitgaanskrant.com`-dev-omgeving) is nu uit alle 15 API-calls in `api_calls.dart` verwijderd via de Headers-tab per call — bevestigd via verse export: 0 treffers meer.)* *(P0-7 afgerond 2026-08-13 avond — Bob, Drupal-kant: de kapotte `flutterflowmobiel_establishment_info`-Views-`display` (`services_1`) is gefixt, `EstablishmentInfoCall` geeft niet langer HTTP 500. **Live bevestigd (Claude, emulator-5554, verse app-launch, nid 91142 = "De Beun"):** titel, fotocarousel en HTML-inhoud tonen nu allemaal echte Drupal-data i.p.v. de `title`/`content`/kapot-plaatje-placeholders. Uit deze lijst verwijderd. **Dit legt meteen een nieuwe, dringende vervolgbug bloot — zie P0-8 hieronder:** met echte data stroomt de Info/Links/Bezorgen-tabs breekt de pagina zichtbaar (RenderFlex-overflow + letterlijke "null"-tekst), iets wat met de eerdere lege/placeholder-data niet zichtbaar was.)* *(P0-8 grotendeels afgerond 2026-08-14 — live pair-sessie, Bob deed de builder-edits, Claude verifieerde elk veld met een verse export (zelfde werkwijze als de 2026-08-10-sessie). **Alle 10 Info-tab/Links-tab-velden bevestigd correct** (adres, plaats, telefoonnummer, email, kvk, website, menukaart, facebook, twitter, instagram — allemaal `!= null && != ''`). **Bezorgen-tab:** bestellink/bezorgkosten/ minimaleorder ook bevestigd correct; thuisbezorgtbetaalopties werkt met een net iets andere maar functioneel prima variant ("Is Set" i.p.v. "Is Set and Not Empty" — laag risico, blijft zo staan). Onderweg 2x een per-ongeluk omgekeerde conditie (`== ''` i.p.v. `!= '' `) gevonden en gecorrigeerd op adres/kvk/website — zelfde soort verkeerde-operator-fout als hieronder bij Minor-1 blijvend openstaat. **3 restpunten bewust niet als launch-blocker behandeld (Bob's beslissing 2026-08-14)** — verplaatst naar "Minor — non-blockers" hieronder: bezorgtijden (conditie hangt aan het verkeerde veld), afhaalopties + bezorgdin (nog geen conditie, wacht op Bob's uitzoekwerk hoe deze twee velden uit de API komen). Het losse "tikbare links"-verbeterpunt is verplaatst naar P1-23. Uit de P0-lijst verwijderd.)* *(P0-9 afgerond — bevestigd 2026-08-21 (Claude, sessie 42, `curl`): een concurrente sessie (waarschijnlijk Bob, commit `d8bbba4`) loste dit op via een app-side workaround i.p.v. de Drupal-`display` zelf te herstellen — `HomeUitgaantabelKaartComponentWidget`'s eerste category-sectie op Home wijst nu naar `displayid: 'services_3'` i.p.v. het kapotte `'display_3'` (`lib/uitgaanspaginas/home/home_widget.dart:312`). Geverifieerd: de oude `display_3`-call geeft nog steeds dezelfde kapotte-view-fout (Drupal-kant dus niet gerepareerd, dat blijft zo), maar `services_3` geeft gewoon een geldige lijst events terug (`curl .../flutterflowmobiel1.json?display_id=services_3` → HTTP 200, 25 items). **Volgende stap: opnieuw live testen of P1-24/P1-25 hiermee ook verdwenen zijn** — nog niet gedaan deze sessie, zie die twee taken. Uit deze lijst verwijderd.)* *(P0-10 afgerond 2026-08-17 — Bob, builder: "Mijn Account"-knop in de drawer was onklikbaar op telefoons met on-screen 3-knops Android-navigatiebalk (root cause: laatste `Row` in `drawer_component_widget.dart` had geen bottom-inset-marge). Bob heeft zelf 48px bottom-padding op die rij gezet — bevestigd via verse export: `EdgeInsetsDirectional.fromSTEB(0.0, 0.0, 0.0, 48.0)` staat nu op regel 1279. `SafeArea` bleek dus niet nodig, gewone vaste padding volstond. Uit deze lijst verwijderd.)* ## Minor — non-blockers (launch mag hier niet op wachten) Bob's expliciete categorie (2026-08-14): kleine restpunten uit P0-8 die de livegang niet blokkeren, later oppakken. *(Minor-1 afgerond 2026-08-16 — Bob, builder, live pair-fix sessie: de "bezorgtijden"-Visibility-conditie op `HorecagelegenheidCurrent` (Bezorgen-tab) bindt nu aan JSON Path `$[:].bezorgtijden` i.p.v. het verkeerde `Openingstijden`-veld. Bevestigd via verse export. Uit deze lijst verwijderd.)* **Minor-2 · Eigenaar: Bob.** `HorecagelegenheidCurrent` (`horecagelegenheid_current_widget.dart`), Bezorgen-tab: "afhaalopties" en "bezorgdin" hebben nog geen Visibility-conditie (kale `Text(getJsonField(..., r'''$[:].afhaalopties/bezorgdin''').toString())`) — tonen dus nog een letterlijke "null" bij een leeg veld. Bob moet eerst uitzoeken hoe deze twee velden uit de API komen (2026-08-14: "moet ik even kijken") voordat de standaard "Is Set and Not Empty"-fix (zelfde recept als de overige 15 velden van het oorspronkelijke P0-8) toegepast kan worden. ## Drupal dingen — verzamellijst, batchen bij Bob's eigen Drupal-sessie **Eigenaar: Bob.** Bob's voorkeur (2026-08-13): kleine builder-fixes die toch al wachten op ander Drupal-werk hier verzamelen i.p.v. los oppakken — dan in één builder-bezoek samen met de Drupal-kant afhandelen. - ~~Hartje-icoon op de horecagelegenheid-detailpagina~~ — **afgerond (2026-08-16, Bob, builder, live pair-fix sessie).** If-tak van de `ConditionalBuilder` rond `IconButtonFavoriet` toont nu `Icons.favorite` (gevuld) met witte Fill Color, zelfde stijl als de Else-tak. Bevestigd via verse export. Geen Drupal-afhankelijkheid nodig gebleken — puur cosmetisch, meegepakt tijdens een toch al geplande sessie op deze pagina. - ~~P1-7 Tab 3 "Favoriete Gelegenheden"~~ — **afgerond (2026-08-14, Claude, builder), zie P1-7 hieronder.** Was hier vermeld als Drupal-geblokkeerd; bleek stale en is dezelfde sessie alsnog gloednieuw gebouwd (nooit door Bob opgepakt) — geen actie meer nodig. ## P1 — snel na livegang *(P1-23 afgerond 2026-08-16 — Bob, builder, live pair-fix sessie: `website`, `menukaart`, `facebook` en `bestellink` op `HorecagelegenheidCurrent` hebben nu allemaal een tap-actie (`launchURL(getJsonField(..., r'''$[:].'''))`, direct via de Text-widget's eigen Actions-tab — geen `InkWell`-wrap nodig gebleken). **Bijvangst:** twitter/instagram (niet in de oorspronkelijke scope, zelfde patroon) zijn tegelijk meegepakt. Bevestigd via verse export (5 `launchURL`-aanroepen). Alle 4+2 velden hadden al de "Is Set and Not Empty"-guard uit P0-8, dus geen los crash-risico meer zoals bij het oorspronkelijke P1-15. **Nog geen visuele link-styling** (kleur/ underline) — puur cosmetisch restpunt, functioneel al klaar. Uit deze lijst verwijderd.)* *(P1-18 afgerond 2026-08-10 avond — Bob, builder + Custom Code, in twee stappen. Root cause was een dubbele bug: (1) `login_widget.dart` behandelde het `drupalLogin`-resultaat als `bool` i.p.v. een JSON-map → crashte altijd; (2) de eerste conditie-fix checkte alleen "is `$.success` aanwezig" i.p.v. de waarde, wat altijd waar was (het veld zat er sowieso in, bij succes én bij falen). Uiteindelijke oplossing — op Bob's eigen voorstel — was simpeler dan een aparte Custom Function: `drupal_login.dart` retourneert nu `null` bij een mislukte/foute login i.p.v. een `{success: false, ...}`-map, en de knop's conditie is teruggebracht tot een simpele, echte null-check (`_model.resultDrupalLogin != null`, operator "Is Set" op de hele actie-output, geen JSON Path meer nodig). Bevestigd via verse export. Het losse debug-dialoogje (AlertDialog "melding" met de rauwe JSON) is blijven staan — niet meegenomen in deze fix, kan later nog opgeruimd worden als cosmetische bijvangst. Uit deze lijst verwijderd.)* *(Nieuwe, andere login-crash gevonden + afgerond 2026-08-17 avond — Claude, builder + live logcat-diagnose op emulator-5554. Dit was géén regressie van P1-18 hierboven, maar een nog niet eerder gevonden tweede bug op dezelfde knop: ná een geslaagde `drupalLogin`-aanroep haalde de knop's "Inloggen"-actie **nogmaals** en **overbodig** de sessievelden uit het resultaat via losse JSON-Path-bindingen (`$.user.uid`, `$.user.name`, `$.user.mail`) — maar `drupalLogin` retourneert die velden plat (`uid`/`name`/`mail`, geen `user`-object), dus alle drie gaven `null`. Voor de 2 String-velden onschuldig (`null.toString()` → tekst "null"), maar `userUid` is `int`-getypeerd in App State → een `null` daarin toekennen crashte de app **stil** (geen rode foutmelding, gewoon geen "Succesvol ingelogd!"-melding en geen reactie op de knop) vóórdat de succes-snackbar ooit getoond kon worden. **Root cause was sowieso overbodige code:** `drupalLogin` (`lib/custom_code/actions/drupal_login.dart`) zet deze velden al zelf correct en veilig in App State (met `int.tryParse(...) ?? 0` voor uid) vóórdat het resultaat teruggegeven wordt. **Fix:** de 6 redundante "Update App State"-acties op de knop's on-tap-flow (Action Flow Editor) volledig verwijderd — de knop doet nu alleen nog `drupalLogin` aanroepen en op basis van `resultDrupalLogin != null` de juiste snackbar tonen. Bevestigd via verse export (`login_widget.dart` bevat de `getJsonField(..., $.user.*)`-blokken niet meer) en live op emulator-5554 (inloggen met gebruikersnaam geeft nu de "Succesvol ingelogd!"-snackbar). **Bijvangst, zelfde diagnose:** inloggen met e-mailadres i.p.v. gebruikersnaam geeft terecht "Inloggen mislukt" — Drupal's `user/login.json` accepteert kennelijk geen e-mailadres als username. Geen bug, maar wel een open feature-vraag aan Bob als e-mail-login gewenst is.)* *(P1-1 volledig afgerond 2026-08-10 avond — Bob, builder, alle 4 sub-punten bevestigd via verse export: `HomeUitgaanSliderComponent` (= P0-1), `PUitgaanSliderComponent`, `EvenementComponent`, `horecagelegenheidCurrent` tonen nu allemaal `if (.isEmpty) { return Image.asset('assets/images/logo800px.png'); }` vóór hun Carousel gebouwd wordt. Uit deze lijst verwijderd. **Vervolgaudit 2026-08-13 (Claude):** dit loste de lege-líjst-crash op, maar dekt niet per se een leeg `imageUrl`-**veld** op een individueel item binnen een wél-gevulde lijst (ander sub-geval van hetzelfde `CachedNetworkImage`-patroon uit `CLAUDE.md`) — daarom alle 13 live `CachedNetworkImage`-aanroepen in het project nagelopen op precies dát: 9 hebben een `if (... != null && ... != '')`-guard (of `valueOrDefault`, wat het risico verlegt naar een kapot-plaatje-icoon i.p.v. een crash — zie P0-7/P1-6), en de resterende 4 gebruiken allemaal `getJsonField(item, r'''$.logo''').toString()` — bij een ontbrekend veld levert `.toString()` op `null` de string `"null"` op (4 tekens), nooit een lege string, dus **geen** synchrone `CachedNetworkImage`-crash (wel een kapot plaatje, cosmetisch). Van die 4 zijn er 3 op `HorecagelegenheidEventTabelComponentCopy` (al bekend kapot via P1-11, geen nieuwe info) en 1 op het bevestigd dode/orphan `UitgaantabelKaartComponentWidget` (P2-7, niet live bereikbaar). **Geen nieuwe crash-risico's gevonden** — deze deelvraag is hiermee afgesloten, niet opnieuw op te pakken.)* *(P1-3 afgerond 2026-08-10 avond — Bob, builder, bevestigd via verse export: `Flexible(child: Text(functions.kortDatum(widget!.datum)))` staat nu op "Text-datum" in `PUitgaanSliderKaartComponent`. Uit deze lijst verwijderd.)* *(P1-4 afgerond 2026-08-14 — live pair-sessie, Bob builder: `horcat`- parameter op `HorecagelegenheidoverzichtCall` (voorheen "EstablishmentsCall") kreeg Default Value `'17967'` (categorie "Uitgaansgelegenheden"). Bevestigd via verse export: `String? horcat = '17967'` i.p.v. de crashende `horcat ??= null!;`. Uit deze lijst verwijderd.)* **P1-5 · Eigenaar: Bob.** "Thuis bezorgen" koppelen aan een echt leverbaar-veld per horecagelegenheid. Wacht op Bob: eerst het API-endpoint aan Drupal-kant configureren. Daarna tonen/verbergen op basis van het echte veld i.p.v. de huidige dode tap. *(P1-6 grotendeels afgerond 2026-08-16 t/m 2026-08-18 — letterlijke veldnaam i.p.v. nette placeholder bij ontbrekende data (`valueOrDefault(, '')` waarbij de default gelijk is aan de veld-/functienaam). Twee binding-typen, elk een eigen fix-route: Component-Parameter-gebonden velden via "Default Variable Value" (8 velden: `horecagelegenheidoverzicht_kaart_widget.dart` titel/adres/plaats, `evenement_info_widget.dart` adres/plaats/entreeprijs/entreetoelichting/contact); JSON-Path-gebonden velden via Visibility → Conditional-guard, "Is Set"/"Is Set and Not Empty" (herbruikbaar recept: widget → Visibility → Conditional aan → Conditions → Single Condition → First Value → Set Variable → EstablishmentInfo/Evenement Response → **schakel bij een vastlopende "Predefined Path" over op "JSON Path" en typ het pad handmatig** (bv. `$[:].bezorgtijden`) — werkte altijd; **bij een leeg/onklikbaar "Single Condition"-suboptie-veld: typ eerst "Single" in de zoekbalk bovenaan de dialoog** vóór je op "Conditions" klikt, zie CLAUDE.md). **Alle live/prioriteit-pagina's afgerond:** `evenement_horecagelegenheid_widget.dart` (11 velden, commits `4fbcb0d`/`14f2f14`, + de vergeten `establishmentnid`-debugwidget verwijderd), `horecagelegenheid_current_widget.dart` (3 velden, commit `14f2f14`), `event_current_widget.dart` (title/date, commit `82b0fb6`). Alles geverifieerd via verse export + `flutter analyze` (0 errors). Uit deze lijst verwijderd.)* *(Correctie 2026-08-19, live pair-fix sessie: het genoemde 8e veld — `horecagelegenheidoverzicht_kaart_widget.dart` titel/adres/plaats — stond hierboven al als "afgerond" vermeld, maar `titel` bleek bij verse export nog steeds de kale `' titel'`-placeholder te tonen (zelfde "leek opgeslagen, was het niet"-patroon als elders in `CLAUDE.md`). Bob heeft `titel` alsnog op Default Value `'Titel onbekend'` gezet (consistent met de al langer werkende `adres`/`plaats` → `'Adres onbekend'`/`'Plaats onbekend'`). Nu pas écht bevestigd via verse export voor alle 3 velden.)* **Resterend, bewust laag-prioriteit (geen "— bezig" claim):** - `evenement_component_widget.dart` (title/eventDate/adres/plaats, regels 221/243/318/340) — alleen bereikbaar via de bevestigd dode orphan-route `EventWidget`/`/event`. **Definitief niet oppakken (2026-08-25, Bob's besluit bij P2-7):** `EventWidget` blijkt zelfs niet meer bewerkbaar in de builder (elke wijziging geeft een "Invalid Action"-crash-preventie en wordt teruggedraaid) — met rust gelaten, dus deze 4 velden blijven zo. JSON-paths ter referentie mocht dit ooit alsnog relevant worden: title `$[0].title`, eventDate → `EvenementCall.eventDate` (`$[0].datum`), adres → `EvenementCall. eventAdres` (`$[0].adres`), plaats → `EvenementCall.eventPlaats` (`$[0].plaats`). *(`p_uitgaan_slider_kaart_component_widget.dart`'s `'def'`-fallback afgerond 2026-08-19 — Claude, builder: Visibility → Conditional op `Text-datum` (Single Condition, First Value = rauwe component- parameter `datum`, operator "Is Set and Not Empty") toegevoegd. Bevestigd via verse export + `flutter analyze` (0 nieuwe treffers): `if (widget!.datum != null && widget!.datum != '')` staat nu om de hele `Flexible(child: Text(...))`, dus de `'def'`-placeholder is onbereikbaar geworden. Uit deze lijst verwijderd.)* - Niet-verdachte gevallen bewust genegeerd (echte inhoudelijke fallback, geen technische naam): `'Evenement'` (`kaart_tabel_uitgaan_comp_widget.dart:216`, `kaart_tabel_uitgaan_s_comp_widget.dart:123`) en `'Uitgaan'` (`tag_categorie_component_widget.dart:113`). *(P1-15 volledig afgerond — bevestigd 2026-08-15, Claude, na een lokale `git`-sync-achterstand van 12 bestanden ingehaald (zie sessienotitie bovenaan): behalve de al bekende 5 social-/contact-knoppen op `evenement_horecagelegenheid_widget.dart` blijken ook de laatste 3 open restpunten uit de bredere audit inmiddels gefixt in de builder (door Bob, nooit apart gemeld/gecommit) — **Menukaart-knop** (`evenement_horecagelegenheid_widget.dart:626-635`) heeft nu de `if (... != null && ... != '')`-guard, **Website-knop op `evenement_info_widget.dart:262`** (gebruikt op `EventCurrent`) en **Website-knop op `evenement_component_widget.dart:408`** (orphan `EventWidget`) hebben beide nu ook een guard om de `InkWell`. Geverifieerd via een verse `flutterflow export-code` + `git diff` (commit `2c093bc`). Nog steeds **geen** verklaring gevonden voor de losstaande "Op/vanaf de Home-pagina zelf"-crash-log uit 2026-08-07 (zie de oude aantekening hieronder) — de reproductie op 2026-08-15 (zie sessienotitie bovenaan, herhaalde `Invalid argument(s): No host specified in URI` direct bij Home's eerste launch, vóór enige tap) laat zien dat dit ondanks alle bovenstaande fixes **nog steeds optreedt** — dus een andere, nog niet gevonden bron. Uit deze lijst verwijderd als losse P1-taak; de resterende mysterie-crash staat nu apart als **P1-24** hieronder.)* - *(Oude beschrijving voor de context, root cause gold voor de 5+1 hierboven bevestigde knoppen:)* Kapotte zichtbaarheids-conditie op de social-/contact-knoppen liet de app **crashen** bij tikken (niet alleen lelijke tekst) — `if (valueOrDefault(, '') != null && ... != '')` is altijd waar omdat `valueOrDefault` nooit `null`/`''` teruggeeft, dus `onTap` riep `launchURL()` aan met de kale placeholder-string als URL (geen geldig schema/host → crash). *(P1-24 volledig afgesloten. **Widget 1** (`p_uitgaan_slider_kaart_component_widget.dart`'s ongeguarde `Image.network`) — afgerond 2026-08-21, sessie 43, Claude, builder + verse export bevestigd: ConditionalBuilder, IF `logo != ''` (Single Condition, First Value = rauwe `logo`-component-parameter, operator "Not Equal To", Second Value = **letterlijke lege string** — zie de `CLAUDE.md`-notitie over hoe je dat literal-tekstveld bereikt op een String/Image-Path-parameter). THEN = bestaande Image, ELSE = Icon `image_not_supported`. **Widget 2** (`home_uitgaantabel_kaart_component_widget.dart`'s JSON-Path-guard, type "Json", biedt geen "Is Set and Not Empty"-operator en geen literal-Second-Value — zie de uitgebreide, hieronder gearchiveerde poging-documentatie voor het volledige waarom) — **Bob's besluit (sessie 44, 2026-08-21): geaccepteerd zoals-ie is, geen verdere actie** (`logo` is in Drupal een verplicht veld, kan in de praktijk niet leeg zijn; en zelfs als dat toch gebeurt vangt Flutter's Image Resource Service de exceptie zelf op — een fallback-icoon, geen app-crash, geen harde noodzaak). **Bijvangst sessie 43 (2e blok, zelfde dag):** buiten deze sessie om (vermoedelijk een losse builder-poging door Bob, niet gecommit) was de werkende `!= null`-conditie op widget 2 op enig moment gewijzigd naar een kale `if (getJsonField(...))` zonder vergelijking — compileert (dynamic omzeilt de statische check) maar **crasht bij runtime** (`type String is not a subtype of type bool`) zodra `$.logo` een string is, dus bij vrijwel elk event mét logo. Gevonden bij een routine-export-check, gemeld, en op Bob's akkoord teruggezet naar de werkende `Is Set`-conditie (Single Condition, First Value = JSON Path `$.logo`, operator "Is Set" — genereert weer `!= null`). Bevestigd via verse export + `flutter analyze` (0 errors). Uit deze lijst verwijderd.)* *(⚠️ Gearchiveerde poging-documentatie (2026-08-21, sessie 42, ~45 min, op widget 2) — bewaard voor het geval een toekomstige FlutterFlow- update deze operator-beperking oplost. Het probleem: First Value gebonden via **JSON Path** (`$.logo`, type "Json") — voor dat type biedt de Single-Condition-operator-lijst alleen `Equal To`/`Not Equal To`/`Is Set`/`Is Not Set`, **geen** "Is Set and Not Empty". Geprobeerd en allemaal doodgelopen: - Een 2e conditie toevoegen (AND, `$.logo != ''`) — de First Value liet zich wel op `$.logo` binden, maar de Second Value-picker bood **op dat moment** geen manier om een letterlijke lege string in te vullen (alleen een variabele-bronkiezer, geen "literal"-optie zichtbaar). **Correctie 2026-08-21 sessie 43:** dit bleek specifiek voor Json- typed First Values te gelden — bij een directe String/Image-Path- component-parameter (zie widget 1 hierboven) bestaat er wél een literal-tekstveld, alleen verstopt achter een paar extra kliks (zie de `CLAUDE.md`-notitie). - First Value omzetten naar **String** via "Predefined Path" i.p.v. "JSON Path" — `evenementenItem` heeft geen gekoppeld Custom Data Type/schema (raw JSON-loop-item via Generate Dynamic Children), dus "Predefined Path" toont domweg geen enkel veld om te kiezen. - Een "empty"/"length"-transform zoeken onder de JSON-Path-binding's eigen 2e "Available Options"-dropdown — alleen "To Data Type" (wijst naar custom models) en "No Further Changes" beschikbaar. - Onderweg 2x per ongeluk een 2e conditie laten hangen/de pagina laten herladen na een vastgelopen geneste "Set Variable"-dialoog — **geen schade**, elke keer teruggezet naar de oorspronkelijke werkende conditie.)* *(P1-25 afgerond 2026-08-21, sessie 43 — Claude, code-audit + builder, bevestigd via verse export. Root cause gevonden zonder live emulator nodig te hebben (dus het emulator-crash-risico uit de vorige sessie was hier niet relevant): in de Column op `home_uitgaantabel_kaart_component_widget.dart:359` hadden 4 van de 5 tekstregels al `maxLines: 1`/`overflow: ellipsis` — **de `plaats`-Text (toen regel ~549-581) was de enige zonder**, en kon bij een lange plaatsnaam over meerdere regels wrappen, waardoor de vaste rijen samen de vaste kaarthoogte (160-280px afhankelijk van breakpoint) overschreden. Fix: `maxLines: 1` gezet via de "Search properties"- zoekbalk (→ "max lines"), zelfde guard-patroon als de buurvelden. Bevestigd via verse export: `maxLines: 1` staat nu op de `plaats`-Text. Geen expliciete `overflow: ellipsis` gezet — dat veld ("Text Overflow Replacement") bleek buiten de klikbare viewport te renderen (bekende clipping, zie CLAUDE.md), maar `maxLines: 1` alleen volstaat al om de RenderFlex-overflow te voorkomen (voorkomt de layout-overschrijding, ook zonder ellipsis- teken). Uit deze lijst verwijderd.)* **P1-16 · Eigenaar: Bob (Firebase-koppeling is account-/builder-niveau, geen Claude-taak).** Geen crash-reporting/analytics (bv. Firebase Crashlytics) ingesteld. Nu is de enige manier om een crash zoals P1-15 hierboven te zien een handmatige `flutter run`-log tijdens een actieve sessie — na livegang is dat niet meer haalbaar, dan draai je blind. **Aanbeveling: instellen vóór livegang**, niet pas erna — FlutterFlow heeft ingebouwde Firebase-integratie (Crashlytics minimaal, Analytics optioneel) die met een paar builder-instellingen aan te zetten is. Zonder dit blijft elke toekomstige crash-bug (nieuwe RenderFlex- overflows, een volgende `launchURL`-achtige misser) onzichtbaar totdat een gebruiker 'm toevallig meldt. **Vers gecheckt 2026-08-13 (Claude, grep op "crashlytics"/"firebase" in `lib/` en `pubspec.yaml`):** nog geen enkele Firebase-referentie in het project — nog steeds volledig niet opgepakt. **P1-17 · Eigenaar: Bob (resterende 108 vertalingen, handmatig — zie controlelijst-artifact hieronder; de 7 gekoppelde-bug-sleutels en de eerste 6 zijn al gedaan).** **Live bevestigd 2026-08-07 (Claude, emulator met systeemtaal en-US, verse app-data):** de app valt terug op **Engels** zodra het toestel niet op Nederlands staat (geen opgeslagen taalvoorkeur → `MaterialApp.locale` is `null` → Flutter matcht het systeem-`en-US` tegen de ondersteunde `['nl','en']`-lijst en kiest `en`). Dat zou op zich geen probleem zijn als er een echte Engelse vertaling stond — **die is er vrijwel niet:** van de 169 sleutels in `lib/flutter_flow/internationalization.dart` zijn er 50 waar `nl`/`en` toevallig identiek zijn (onvertaald), 44 waar **beide talen leeg zijn** (dus zichtbaar niets, zoals de Login-hinttekst uit P0-6), en slechts 1 sleutel met een bewust andere Engelse tekst — en die ene is fout: key `7pacsyhe` (het hartje-menu-item in de drawer) toont `nl: 'Favorieten'` maar `en: 'Home'`, dus **een Engelstalig toestel ziet twee menu-items met de tekst "Home"** (huis-icoon én hartje-icoon) — verwarrend, de favorieten zijn zo niet te vinden. *(Dit specifieke veld — key `7pacsyhe`/`ListTileFavorieten` — is 2026-08-17 door Bob gefixt in de builder: Engelse vertaling staat nu ook op "Favorieten", bevestigd via verse export. De rest van P1-17 hieronder — de overige ontbrekende Engelse vertalingen — blijft open.)* **Iedere gebruiker met een Engelstalig toestel** (niet ongebruikelijk, ook onder Nederlanders) krijgt dus een merkbaar kapotte/lege interface. **2026-08-09, Bob: Engels moet blijven aangeboden** (niet weghalen als taal) — de eerder voorgestelde "forceer hard op nl"-fix (Engels uit `FFLocalizations.languages()` verwijderen) is dus **afgewezen**, niet uitgevoerd. Resterende optie is de grotere, aparte contentklus: de ontbrekende Engelse vertalingen daadwerkelijk invullen (of een losse taalkeuze-instelling bouwen i.p.v. op systeemlocale te vertrouwen). Nog niet opgepakt. **Live herbevestigd 2026-08-09 (Claude, emulator):** root cause klopt exact zoals hierboven beschreven — op een device met `ro.product.locale=en-US` verdween de "Wachtwoord vergeten?"-link op Login volledig (lege `en`-vertaling voor key `utppw2si`); na `adb shell cmd locale set-app-locales com.uitgaanskrant.app --locales nl-NL` (betrouwbaardere per-app-locale-override dan de systeembrede `settings put system system_locales` + broadcast, die op de emulator niet altijd doorwerkte zonder reboot) kwam de tekst meteen terug — bevestigt dat dit puur een vertaalprobleem is, geen widget-bug. **2026-08-18, Claude: gestart met invullen (Settings → Languages-tabel in de builder, per-pagina-secties met inline Dutch/English-velden — sneller en betrouwbaarder dan het widget-canvas-rechterpaneel voor platte teksten).** 6 velden afgerond en bevestigd via verse export, geen probleem: login-pagina `d507d3b9`(E-mailadres, was al goed), `t8h5f8ir`(Wachtwoord, was al goed), `gkx4luhw`("Inloggen"→"Log in"), `utppw2si`("Wachtwoord vergeten?"→"Forgot password?"), `bokhk9vk`("Home"→"Home"). **Let op — "Translate All"/"Translate Page" (automatische Google Translate-knoppen bovenaan elke sectie) zijn een betaalde Growth/Business-plan-feature (Upgrade-paywall) — niet aangeklikt, niet iets om zelf te doen zonder Bob's akkoord.** **⚠️ Bevestigde FlutterFlow-backend-bug (niet builder-UI-gerelateerd, 2026-08-18, Claude, uitgebreid geverifieerd met tussentijdse verse exports):** 7 losse `AlignedTooltip`-teksten op 7 verschillende widgets/pagina's blijken op serverniveau aan elkaar gekoppeld — **het bewerken van de Engelse vertaling van ÉÉN ervan overschrijft alle 7 tegelijk met dezelfde waarde.** Bevestigd via zowel het globale Settings → Languages-paneel als het widget-specifieke vertaalpaneel (rechtsklik-paneel → Message/Text-veld → globe-icoontje ernaast, opent een los "Setting Translations"-paneel met Dutch/English + een per-veld "Google Translate"-knop) — **beide ingangen hebben exact dezelfde koppeling**, dus dit zit in FlutterFlow's datamodel, niet in een specifieke UI-flow. De 7 betrokken sleutels (allemaal `AlignedTooltip`, dus laag-zichtbaar — alleen bij long-press): - `pj545url` (login, "Veld wissen") — moet zijn: "Clear field" - `ahiklq0c` (login, "Wachtwoord tonen/verbergen") — moet zijn: "Show/hide password" - `kjqv6ycx` (horecagelegenheidCurrent, "Favoriet") — moet zijn: "Favorite" — **enige van de 7 die nu toevallig correct staat** - `z63o5kzf` (EventCurrent, "Delen") — moet zijn: "Share" - `vmbtb6ah` (drawerComponent, "Terug") — moet zijn: "Back" - `f8ay39rg` (HeaderButtonsComponent, "Terug") — moet zijn: "Back" - `ujd0p09x` (HorecagelegenheidoverzichtKaart, "MessageFavoriet...") — nl-tekst zelf ziet er al als vergeten debug-tekst uit, apart navragen bij Bob wat dit hoort te zijn (mogelijk gewoon leeg laten) Huidige staat: alle 7 staan op **"Favorite"** (laatste testwaarde, enige bereikbare gedeelde staat — niet "beter" te maken via de builder-UI, elke volgende edit blijft alle 7 tegelijk overschrijven). **Impact laag** (tooltips, geen primaire UI-tekst), dus geen launch-blocker, maar wel een echte content-fout die ergens moet worden opgelost. **Aanbevolen vervolgstappen (niet meer via Claude-browserautomatisering proberen, al 2 ingangen geprobeerd):** Bob probeert het zelf in zijn eigen browser (kan anders gedragen), of meld dit als bug bij FlutterFlow-support, of verwijder+herbouw één van de 7 tooltip-widgets (breekt vermoedelijk de koppeling doordat er dan een nieuwe key gegenereerd wordt). **Resterende 108 velden: Bob's beslissing 2026-08-18, handmatig oppakken** (browser-automatisering is hiervoor te traag/risicovol gezien de bug hierboven — Bob doet dit zelf, "deze week"). Claude leverde een complete, per-pagina-gegroepeerde controlelijst met een vertaalvoorstel per veld als artifact: https://claude.ai/code/artifact/d195d2d6-392b-4fbb-afd2-0f2d92ce9609 ("P1-17: Engelse vertalingen" — ook terug te vinden via Artifacts op claude.ai mocht de link kwijtraken). Route in de builder: Settings → Languages, per pagina-sectie de Engelse kolom invullen (bevestigd betrouwbaar voor platte tekst, i.t.t. het widget-canvas-rechterpaneel). **Niet aanraken:** de "Translate All"/ "Translate Page"-knoppen (betaalde Growth/Business-upgrade) en de 7 gekoppelde sleutels hierboven (apart traject). **P1-7 · Eigenaar: Claude.** "Favorieten pagina maken" (Bob's naam voor deze taak, 2026-08-13 — was P0-4, samengevoegd met het oude P1-7 favorieten/profielscherm-werk + P2-8 gemeente-favoriet). Bob bouwt de Drupal-kant (views/endpoints) zelf, apart; Claude/deze sessie kan de lokale/UI-kant + look&feel oppakken zolang die niet op Drupal wacht. **Al afgerond (2026-08-13, geverifieerd via verse export):** - App State-velden `favorieteGemeenteIds` en `favorieteHorecaNids` (beide `List`, Persisted: true) bestaan nu in `lib/app_state.dart`. - Hartje-toggle op `HorecagelegenheidoverzichtKaart` (overzichtskaart) volledig werkend: `ConditionalBuilder` op `FFAppState().favorieteHorecaNids.contains(widget!.nid)` (ingesteld via "Set from Variable" → Available Options → **List Contains Item**, zie `CLAUDE.md`) — If-tak toont gevuld hartje + `removeFromFavorieteHorecaNids`, Else-tak toont outline hartje + `addToFavorieteHorecaNids`. Logica én styling (witte Fill Color op beide takken) bevestigd correct. - Hartje-toggle op `HorecagelegenheidCurrent` (detailpagina): zelfde patroon, Remove/Add-acties functioneel correct. **Cosmetisch restpunt** (icoon/kleur If-tak nog niet aangepast) verplaatst naar de "Drupal dingen"-lijst hierboven — Bob wil dit batchen met een latere Drupal-sessie. - **Tab 3 "Favoriete Gelegenheden" — volledig gebouwd en werkend (2026-08-14, Claude, builder, bevestigd via verse export + `flutter analyze`).** Gebruikt `FavorietenAgendaCall` (1 sessie- geauthenticeerde call, geen client-side nid-lijst nodig). Bouwstappen (herbruikbaar patroon, zie ook de nieuwe "Generate Dynamic Children"- sectie in `CLAUDE.md`): 1. `ListView` ingevoegd op Tab 3's lege Column (Insert Widget → Layout Elements → ListView), placeholder-Text verwijderd. 2. Backend Query (database-icoon) → API Call → `FavorietenAgenda` toegevoegd aan de ListView. 3. `ListTile` als item-template ingevoegd in de ListView. 4. **Generate Dynamic Children** (4e icoon in de widget-iconenrij, tooltip bevestigt de naam) op de ListView aangezet: Variable Name `favorieteGelegenheidItem`, Value → Set from Variable → `FavorietenAgenda Response` → Available Options **"No Further Changes"** (rauwe JSON-array, geen predefined-path-extractie) → Save → bevestigingsdialoog ("generate its children dynamically... edit the first child to set how every child should look") → Ok. Canvas toont meteen 4 herhaalde design-time placeholder-rijen. 5. ListTile's **Title** opnieuw gebonden (was per ongeluk nog aan de hele API-respons gebonden i.p.v. het loop-item): Set from Variable → bron **`favorieteGelegenheidItem`** (nieuw beschikbaar ná stap 4) → Available Options **"JSON Path"** → `$.node_title`. 6. **Subtitle** leeggemaakt (triple-click veld → Delete) — geen bruikbaar 2e veld in deze call, anders bleef de letterlijke placeholder-tekst "Subtitle" op elke rij staan (zelfde P1-6-patroon). 7. **On Tap-actie** (Actions-tab, 2e icoon — ja, deze tab bestaat wel, zie de gecorrigeerde P1-9-notitie): Navigate To → `horecagelegenheidCurrent` → Parameters → **Pass** (niet "Define" — dat opent per ongeluk de doelpagina's eigen parameterschema-editor) → parameter `nid` → Value → Set from Variable → bron `favorieteGelegenheidItem` → JSON Path `$.nid`. Gegenereerde code geverifieerd (`ListView.builder` + `getJsonField(favorieteGelegenheidItemItem, r'''$.node_title''')` + `context.pushNamed(HorecagelegenheidCurrentWidget.routeName, queryParameters: {'nid': ...$.nid...})`), `flutter analyze` toont geen nieuwe treffers voor `favorieten_widget.dart`. **Bekend restpunt, geen blocker:** geen leading-logo-afbeelding (ListTile's "Leading"-sectie biedt alleen een Icon-property, geen Image-slot — zou een aparte widget-vervanging vergen). *(Lege-lijst-state inmiddels ook gefixt — zie het voormalige P0-4 hierboven, zelfde live pair-sessie.)* *(TabPersAgenda's eigen "On Tap"-`drupalRequest` (regel 252-253) afgerond 2026-08-20 — Bob, builder: `method`-argument van `'POST'` naar `'GET'`, zelfde fix als eerder al op de On-Page-Load-trigger. Bevestigd via verse export: beide `drupalRequest`-aanroepen in `favorieten_widget.dart` (regel 44 en 253) staan nu op `'GET'`.)* *(Snelkeuzelijst favoriete gemeenten — volledig afgerond, sessie 43, bevestigd via verse export + `flutter analyze` (0 errors) + live check op emulator-5556 (profile mode, geen crash, dropdowns/Toepassen renderen correct met een lege favorietenlijst).** Op Bob's expliciete verzoek (niet op Favorieten-Tab 2, maar direct op de "Select gemeente/provincie"-pagina, `lib/selecteer_plaats/selectprovinciegemeente/`, component `SelectStateDropDownComponent`): meteen bij binnenkomst je favoriete gemeenten als snelkeuze zien. Bob's keuzes: tik op een favoriet = **direct naar Home** met die gemeente actief; lijst staat **onderaan**, ná de dropdowns/"Toepassen"-knop. **Bouwstappen (herbruikbaar patroon):** 1. Custom action `getFavorieteGemeenten(List? favorieteGemeenteIds) -> List` (`lib/custom_code/actions/get_favoriete_gemeenten.dart`, commit `c6c3439`) — geen "alle gemeenten van heel NL"-Drupal-endpoint beschikbaar, dus deze haalt `ProvinciesCall`, loopt alle provincies langs met `GemeentenCall`, en verzamelt de gemeenten waarvan `gemeenteid` in `favorieteGemeenteIds` voorkomt. 2. Local Component State Variable `favorieteGemeentenLijst` (`List`) op `SelectStateDropDownComponent`. 3. Twee acties toegevoegd aan het **einde** van de bestaande "On Initialization"-flow (ná de 16 bestaande acties, via de Action Flow Editor's "+"-connector onder het laatste blok — niet het compacte Actions-paneel, dat toont geen "volgende actie toevoegen"-knop meer na de eerste actie): Custom Action `getFavorieteGemeenten` (argument = App State `favorieteGemeenteIds`) → Update Component State (`favorieteGemeentenLijst` = Action Outputs-resultaat). 4. Onder de bestaande "Toepassen"-knop: **Wrap** ingevoegd (rechtsklik Column → Insert Widget → koos per ongeluk eerst ListView; **Replace Widget** naar Wrap behoudt eventuele latere Generate-Dynamic- Children-config, zie CLAUDE.md) → **Generate Dynamic Children** (4e icoontje) met Variable Name `favorieteGemeenteItem`, Value = Component State `favorieteGemeentenLijst`, "No Further Changes". 5. Kind-`Container` + `Text` toegevoegd; Text's waarde via Set from Variable → `favorieteGemeenteItem` → Available Options **"Data Structure Field"** → `gemeentename` (dit type, een Data-typed loop- item i.p.v. een raw JSON-item, biedt wél een directe veld-picker — geen JSON Path nodig). 6. Container's **On Tap** (Actions-tab, 2e icoontje): Update App State (`gemeenteSelectId`/`gemeenteSelectNaam`, elk Set Value → Data Structure Field `gemeenteid`/`gemeentename` op hetzelfde loop-item) → Navigate To Home (Allow Back Navigation aan, zelfde patroon als de bestaande "Toepassen"-knop: `context.pushNamed`). Gegenereerde code geverifieerd: correcte `Wrap(children: List.generate(...))` met `InkWell.onTap` die `FFAppState().gemeenteSelectId`/`gemeenteSelectNaam` zet en `context.pushNamed(HomeWidget.routeName)` aanroept. **Bewust niet meegenomen:** `provincieSelectId`/`provincieSelectName` zetten — `GemeenteModelStruct` bevat geen provincie-veld (alleen `gemeentename`/`gemeenteid`), en de bestaande gemeente-dropdown's eigen `onChanged` zet die twee provincie-velden ook al niet, dus dit blijft consistent met het bestaande gedrag. **Nog niet visueel gestyled** (kale Container zonder chip-vormgeving/padding/afronding — puur functioneel getest) — cosmetische afwerking (padding, pill-vorm, spacing tussen chips) is een kleine, losse vervolgtaak als Bob dat wil.)* - **Tab 1 "Persoonlijke agenda" — bleek al gebouwd (niet door deze lijst gedekt, `TASKS.md` liep achter), en kreeg 2026-08-17 avond 2 bugfixes (Claude, builder, bevestigd via verse export + `flutter analyze` + live op emulator-5554):** 1. De data-fetch (`drupalRequest` POST naar `.../favorieten_agenda.json`) hing aan de `TabBar`'s `onTap` op de `Tab`-node zelf (zie `CLAUDE.md`) — die vuurt alléén bij een echte tik, dus **nooit** voor de al-actieve standaardtab bij page-load. Fix: Scaffold's eigen **"On Page Load"**-trigger toegevoegd met dezelfde actieketen (via rechtsklik op de bestaande `TabPersAgenda`-Tab-node → Actions → "Copy Action Chain" → nieuwe On-Page-Load-trigger → "Paste Action(s)") — let op de `CLAUDE.md`-notitie over de dubbele-variabele-valkuil die dit trucje veroorzaakt, dat moest ik zelf nog corrigeren. 2. Los daarvan crashte de pagina stil (`NoSuchMethodError: Map heeft geen 'toList'`) zodra de call een niet-2xx-respons kreeg, omdat de custom action `drupalRequest` (`lib/custom_code/actions/drupal_request.dart`) bij een fout een `{'success': false, ...}`-Map teruggaf terwijl de aanroepende code altijd blind `.toList()` erop aanriep. Fix: alle 3 foutpaden in `drupal_request.dart` (non-2xx, timeout, exception) geven nu `[]` terug i.p.v. een map — bevestigd via verse export. **Live bevestigd:** `favorieten_agenda.json` geeft momenteel nog een **404** terug (Bob kijkt hier zelf naar, zie boven) — de tab blijft nu netjes leeg i.p.v. te crashen. *(De 404 hierboven is afgerond 2026-08-19 — Bob, Drupal-kant, samen met Claude gedebugd via live curl-vergelijkingen productie/devbob + Drupal watchdog-log + `custom.module`-broncode. **Root cause: de `favorieten_agenda`-resource (Services-module, gedefinieerd in `custom_services_resources()`) stond nog niet aangevinkt als ingeschakelde resource voor het `flutterdrup`-endpoint op productie** — identieke module-code op beide omgevingen, maar de resource-activatie zelf is een los, niet-code-gebonden config/database-item per endpoint (zie de nieuwe `CLAUDE.md`-notitie voor het volledige, herbruikbare debug-recept). Fix: resource aangevinkt op `https://uitgaanskrant.com/en/admin/structure/services/list/flutterdrup/resources`. Tab 1 "Persoonlijke agenda" haalt nu live data op. Uit deze lijst verwijderd.)* *(Vervolg-bugs op Tab 1, zelfde 404-fix-sessie, afgerond 2026-08-19 — Bob + Claude samen, live pair-fix + verse-export-verificatie. Ná de server-side 404-fix werkte de pagina via `curl` maar nog niet via de app zelf — twee losse client-side bugs bleken de resterende oorzaak: 1. **`drupalRequest`-aanroepen gebruikten `'POST'`, maar Drupal Services' 'index'-operatie beantwoordt alleen GET** (POST → 404, ook al staat de resource nu wel geactiveerd). Op de Scaffold's "On Page Load"-trigger `method` gewijzigd naar `'GET'` (Claude, builder, bevestigd via verse export). 2. **JSON Path-bug op alle 9 `UitgaantabelKaartWidget`-parameters** (`logo`, `categorie`, `titel`, `horecagelegenheid`, `adres`, `plaats`, `datum`, `nid`, `horecagelegenheidNid`): gebonden met `r'''$[:].veld'''` (array-wildcard-syntax, alleen geldig op een hele array) i.p.v. `r'''$.veld'''` (correct voor een los loop-item) — gaf overal `null` terug, met een `Null check operator used on a null value`-crash op `titel` tot gevolg (`widget!.titel!.toString()` in `uitgaantabel_kaart_widget.dart`). Bob heeft alle 9 velden zelf in de builder gecorrigeerd, bevestigd via verse export. 3. **Losstaande null-crash op `inhoud`** (zelfde widget, `widget!.inhoud!.toString()`): `UitgaantabelKaartWidget` is een gedeeld component, en Favorieten Tab 1 geeft bewust `inhoud: null` mee (geen equivalent veld in deze API-respons). "Default Variable Value" bleek hier **geen** werkende fix (`inhoud` is een JSON/ `dynamic`-getypeerde parameter, geen String — de default-waarde bleef na Confirm leeg/niet-opgeslagen, bevestigd via 2x verse export). Werkende fix: **Wrap Widget → ConditionalBuilder** op de `Text-inhoud`-node, conditie **"inhoud is set"** (First Value = rauwe `inhoud`-parameter, operator "Is Set", géén Second Value nodig), Else-tak leeg. Genereert `if (widget!.inhoud != null) { return Text(widget!.inhoud!.toString(), ...); }` — bevestigd via verse export. **Dit component wordt op meerdere plekken gebruikt** (o.a. `HomeUitgaantabelKaartComponent`) — de fix is op het gedeelde component zelf toegepast, dus geldt overal waar `inhoud: null` wordt meegegeven, zonder de plekken met een echte inhoud-waarde te raken. Lokale repo bijgewerkt via een verse `flutterflow export-code` in de projectmap + `flutter analyze` (geen nieuwe errors, alleen de gebruikelijke gegenereerde info/warnings).)* *(Categorie-crash-patch bevestigd toegepast (2026-08-25) — Bob deelde de live `custom.favorites_agenda.inc`-broncode in de chat: bevat exact de op 2026-08-20 afgesproken fix (`GROUP_CONCAT`-subquery per tak (go_out_event + activity) bouwt een `Naam`-XML-string op, `_custom_parse_categories_to_array()` zet 'm om naar een echte array vóór 'ie als `categorie` teruggaat). Dit lost de destijds gevonden `NoSuchMethodError: Class 'String' has no instance method 'toList'`-crash op (`UitgaantabelKaartWidget` verwacht `categorie` als JSON-array, `lib/uitgaanspaginas/uitgaantabel_kaart/uitgaantabel_kaart_widget.dart:219`). **Live bevestigd (2026-08-25, Bob):** Tab 1 toont de categorieën nu correct, geen crash. Volledig afgerond, geen resterende actie.)* **Scope-correctie (2026-08-25, op basis van de live Drupal-broncode die Bob deelde):** Tab 1 "Persoonlijke agenda" filtert **niet** op gefavoriete gemeente(n) zoals eerder hieronder stond (zie de nu gecorrigeerde "Bob's beslissingen"-notitie) — de query in `custom_favorites_agenda_data()` heeft drie routes (`matched_via`): **horeca** (uitgaansevenementen van je gefavoriete horecagelegenheden), **event** (een gefavoriet uitgaansevenement zelf), **activity** (een gefavoriete stadsactiviteit zelf). Plaats/gemeente is puur een weergaveveld, geen filter. Geen verdere actie nodig — dit is al zo gebouwd, alleen de documentatie liep achter. *(Anonieme API-call-bug op Tab 3 afgerond 2026-08-19 — Claude, builder + verse-export-verificatie: `FavorietenAgendaCall`'s Backend Query op de ListView had geen `sessionName`/`sessionId` gebonden, dus de call ging altijd zonder sessie naar Drupal (ListTile toonde letterlijk "null" i.p.v. de favoriete horeca-gelegenheden, ook ingelogd). Beide parameters nu gebonden via Set from Variable → `FFAppState(). userSessionname`/`userSessionid`. Bevestigd via verse export: `FavorietenAgendaCall.call(sessionName: FFAppState().userSessionname, sessionId: FFAppState().userSessionid)`. **Correctie (2026-08-25, sessie-check vóór het oppakken van deze "Nog open"-post):** deze hele `FavorietenAgendaCall`/Backend-Query-route bestaat niet meer — Tab 3 is op 2026-08-24 volledig herbouwd (commit `d35492a`) op een `drupalRequest`-custom-action-aanroep naar `favorieten_horeca.json`, en díe bindt `FFAppState().userSessionname`/ `userSessionid` al gewoon correct (`favorieten_widget.dart:293-294`). Herbevestigd via een verse export vlak vóór deze notitie — geen builder-actie nodig, deze taak was stale.)* *(Tekst-overflow Tab 2 afgerond 2026-08-19 — Claude, builder: de `Text`-widget "De gemeentes die je hebt gemarkeerd..." (key `o7pt2vls`) had geen horizontale padding en liep tot de schermrand. Nu 16px links/rechts padding, bevestigd via verse export (`Padding(EdgeInsetsDirectional.fromSTEB(16.0, 0.0, 16.0, 0.0))`). **Correctie op de oorspronkelijke melding:** Tab 3 heeft sinds de 2026-08-14-herbouw (ListView + Generate Dynamic Children) geen eigen beschrijvingsregel meer — de "vergelijkbare tekst op Tab 3" bestond niet meer, dat deel van de melding was stale.)* *(Structureel gat + tab-label-afkapping afgerond 2026-08-19 — Claude, builder + live geverifieerd op emulator-5554. Favorieten had geen header/drawer (geen "☰"-menu, geen terugweg behalve Android's systeem-terugknop) en alle 4 tab-labels waren afgekapt op telefoonformaat. Fix: Scaffold-node in de widget tree kreeg een **Drawer**-slot (`drawerComponent`, zelfde als andere pagina's) en een **AppBar**-slot (`HeaderButtonsComponentWidget(showBackButton: false)` in een `FlexibleSpaceBar`-title, achtergrondkleur "Info", hoogte 80px, "Show Default Button" uit om een dubbele hamburger te voorkomen — identiek patroon aan `PUitgaanPage`). Widgets zoals `Drawer`/`AppBar` zijn zelf niet via de gewone rechtsklik-Insert-Widget-flow te vullen; werkende route: **slepen vanuit het linker widget-paneel direct naar de canvas-dropzone** (de AppBar/Drawer canvas toont bij een sleep-actie zelf de "Leading"/"Title"/"Actions"-zones) — zie ook de nieuwe `CLAUDE.md`-notitie. Tab-label-afkapping: `TabBar` kreeg **"Tab Bar Scrollable"** aan (Search properties → "scroll") — labels tonen nu volledig uitgeschreven en scrollen horizontaal i.p.v. af te kappen. Bevestigd via verse export + `flutter analyze` (0 nieuwe treffers) én live: drawer opent via het hamburger-icoon, geen dubbele knop, alle 4 tabs met volledig label bereikbaar. Uit deze lijst verwijderd.)* *(UX-gat grotendeels afgerond 2026-08-19 — Claude, builder (`drawerComponent`, gedeeld over alle pagina's): de drawer's "Mijn Account"-knop toont nu alleen nog het kale login-formulier als er géén actieve sessie is. Fix: `Wrap Widget → ConditionalBuilder` om de bestaande `FFButtonWidget`, conditie `FFAppState().userSessionid` "Is Not Set or Is Empty" (Then = ongewijzigde originele knop, geen regressie voor uitgelogde gebruikers — de meerderheid). Else-tak (ingelogd): nieuwe knop met tekst gebonden aan `FFAppState().userName` i.p.v. de statische "Mijn Account"-tekst, en `onTap` navigeert naar `FavorietenWidget` (i.p.v. terug naar Login) — dat dekt zowel "gebruikersnaam zichtbaar" als "link naar Favorieten" uit Bob's oorspronkelijke wens. Bevestigd via verse export + `flutter analyze` (0 nieuwe treffers); **volledig live geverifieerd op emulator-5554** (bleek een nog actieve testsessie "bobcity" op het toestel te staan) — zowel de uitgelogde staat (ongewijzigd "Mijn Account"-gedrag) als de ingelogde staat (knop toont "bobcity", tik navigeert naar Favorieten) werken zoals bedoeld. Bijvangst tijdens dezelfde sessie: Tab 3 "Favoriete Gelegenheden" toont voor deze testgebruiker nog steeds "null" ook nu de sessie wél wordt meegestuurd (zie de eerdere sessie-parameter-fix hierboven) — dit is dus geen client-sidebug meer maar wijst op een Drupal-datakant-vraag (mogelijk heeft "bobcity" gewoon geen favoriete gelegenheden, of de endpoint zelf heeft nog een probleem) — niet verder onderzocht, buiten scope van deze taak. **Bewust niet meegenomen:** een eigen uitlog-knop in de drawer zelf — die bestaat al op Favorieten's "Gebruiker"-tab (P1-7), dubbel opbouwen leek overbodige scope-uitbreiding.)* - **"Gebruiker"-tab, "Uitloggen"-knop afgerond (2026-08-15, Claude, builder, bevestigd via verse export + `flutter analyze`: 0 errors).** `favorieten_widget.dart` heeft nu een 4e tab "Gebruiker" (via TabBar's "Active Tab"-dropdown → "+ Add Tab", zie `CLAUDE.md` voor het herbruikbare recept) met een `ListTile` "Uitloggen". On Tap: Action 1 = Update App State (6 velden op "Clear Value": `userToken`/`userSessionid`/`userSessionname`/`userName`/`userUid`/ `userMail`), Action 2 = Navigate To Login met "Allow Back Navigation" uit (genereert `context.goNamed(...)` i.p.v. `pushNamed`, dus geen terugknop-pad naar de net-verlaten sessie). **Nog open, zelfde tab:** geen gebruikersnaam zichtbaar (zie UX-gat hierboven), "Wachtwoord wijzigen" (zie Bob's beslissing 3 hieronder) — niet meegenomen, eigen vervolgtaak. **"Account verwijderen" volledig afgerond (2026-08-24, Bob + Claude samen).** Bob wil geen volledige in-app-flow bouwen; gekozen aanpak: account direct blokkeren (`status=0`, kan niet meer inloggen) + na 30 dagen automatisch hard verwijderen via cron, i.p.v. direct verwijderen. Twee Drupal-ingangen, beide roepen dezelfde kernfunctie `_custom_account_delete_request()` aan (`custom.account_delete.inc`, nieuw bestand naast `custom.module`): - **Services-resource** (`POST .../nl/flutterdrup/accountdelete/delete_request.json`, sessie- Cookie + `X-CSRF-Token`-header verplicht — token op te halen via `.../nl/flutterdrup/user/token.json` met dezelfde sessie-cookie, géén args nodig, lege JSON-body `{}` volstaat). **Resource-naam is `accountdelete`, niet `account`** — die eerste naam botste stil met iets in Services (resource verscheen niet in de Bronnen-lijst, geen foutmelding) tot 'm hernoemd werd. Live succesvol getest via curl op devbob. - **Webpagina** `/account-verwijderen` (Drupal `hook_menu()`, `confirm_form()`, alleen bereikbaar ingelogd — normale Drupal-login, geen app-token nodig, werkt dus ook los van de app) — **live bevestigd werkend** door Bob. - **FlutterFlow-app-kant**: nieuwe `ListTile` "Account verwijderen" op de Gebruiker-tab (gedupliceerd van de Uitloggen-ListTile, zelfde styling), On Tap → **Launch URL** (actie staat onder categorie **"Share"**, niet "Navigation" — makkelijk te missen) → `https://uitgaanskrant.com/nl/account-verwijderen`. Bevestigd via verse export (`launchURL(...)` correct gegenereerd) + `flutter analyze` + `flutter build apk` (geen nieuwe errors). Gecommit `55b8dd6`. **Dekt Apple's App Store Review Guideline 5.1.1(v)** (in-app-pad naar accountverwijdering, een link-out naar een simpele webpagina volstaat volgens de richtlijn). - Cron-sweep (`custom_account_delete_cron()`, via `custom_cronapi()` — Ultimate Cron, dagelijks) ruimt na 30 dagen automatisch op — **nog niet live getest** (logisch, kost 30 dagen om te reproduceren; code-review + de handmatige call-flow zijn het enige dat hier geverifieerd is). Enige resterende twijfel over deze hele feature — verder geen actie nodig tenzij Bob over ~30 dagen wil controleren dat de sweep echt draait. *(Restpunt A — horeca-hartjes Drupal-sync — volledig afgerond 2026-08-24/25, Claude, builder + verse-export-verificatie + live smoke-test op emulator-5554 (build/launch zonder exceptions).** Beide widgets (`horecagelegenheidoverzicht_kaart_widget.dart`, `horecagelegenheid_current_widget.dart`) roepen nu bij add/remove ook `actions.drupalRequest('POST', '.../favorieten/flag.json'` resp. `unflag.json', FFAppState().userSessionname, userSessionid, userToken, functions.favorietenBodyNode(widget!.nid!)!)` — zelfde patroon als het al werkende gemeente-hartje. **Nieuw hulpmiddel:** een letterlijke JSON- body met een ingesloten variabele (`{"entity_id": , "entity_type": "node"}`) bleek via de Custom-Action-argumentenpanel niet direct te bouwen (geen concatenatie-optie op een kaal String-argument, alleen een volledige literal-of-variabele-vervanging) — opgelost met een nieuwe kleine **Custom Function** `favorietenBodyNode(String nid) -> String` (`lib/flutter_flow/custom_functions.dart`, retourneert de body-string via Dart-stringconcatenatie), die vervolgens gewoon als waardebron voor het `body`-argument gekozen kan worden (Set Variable-dialoog → Custom Functions). Herbruikbaar patroon voor een volgend geval van "JSON-body met 1 variabele" — zie ook de bijgewerkte "Geneste Set-Variable-dialoog"-notitie hierboven. Onderweg 2x de bekende bevroren-geneste-dialoog-freeze geraakt (beide keren opgelost met een page-reload, geen dataverlies — de al bevestigde argumenten bleven staan). Uit deze lijst verwijderd.)* *(Restpunt B — "Wachtwoord wijzigen"-link — volledig afgerond 2026-08-24/25, Claude, builder + verse-export-verificatie.** Nieuwe `ListTile` "Wachtwoord wijzigen" op de Gebruiker-tab (gedupliceerd van "Uitloggen"), On Tap → Navigate To → `wachtwoordVergeten`-pagina (Allow Back Navigation aan, geen parameters). Gebruikt de al bestaande `lib/wachtwoord_vergeten/`-pagina/`RequestNewPasswordCall`, geen nieuw Drupal-werk nodig. Uit deze lijst verwijderd.)* **Bob's beslissingen (2026-08-09, nog steeds leidend):** 1. Favorieten (zowel horeca als gemeenten) worden **Drupal-gesynchroniseerd**, niet puur lokaal — sync bij app-start én direct na elke toevoegen/verwijderen-actie. Lokale opslag (`FFAppState`/ secureStorage) blijft daarnaast nodig als cache/snelle UI-state. 2. **Correctie (2026-08-25, live Drupal-broncode bevestigt dit):** "Persoonlijke agenda" (tab 1) = evenementen/activiteiten van je **gefavoriete horecagelegenheden + zelf gefavoriete uitgaansevenementen + zelf gefavoriete stadsactiviteiten** (`custom_favorites_agenda_data()`'s drie `matched_via`-routes: horeca/event/activity) — **niet** gemeente-gebaseerd zoals hier eerder stond. Gemeente/plaats is alleen een weergaveveld op elk item, geen filter. 3. "Gebruiker"-tab = het oude P1-7-scope (wachtwoord wijzigen, uitloggen, account verwijderen), nu als tab i.p.v. aparte pagina. **Account verwijderen afgerond 2026-08-24** (zie de uitgewerkte notitie hierboven — blokkeert/vertraagt + cron, geen directe verwijdering, dekt Apple's App Store Review Guideline 5.1.1(v)). Alleen "Wachtwoord wijzigen" resteert nog van deze beslissing. *(P1-12 afgerond 2026-08-10 avond — Bob, builder, opgelost via een andere en betere route dan oorspronkelijk voorgesteld: i.p.v. een Default Value op `establishmentID` toe te voegen (die de crash slechts had gemaskeerd met een nep-waarde "0"), is de hele `EvenementHorecagelegenheidWidget`-instantie op `EventCurrent` nu achter een Visibility-conditie gezet die bindt aan de **rauwe** pagina-parameter `horecaid` zelf (operator "Is Set"), vóór een eventuele Default Value-substitutie — zelfde "bind aan de rauwe bron, niet aan de gesubstitueerde waarde"-principe als het bekende CachedNetworkImage/P1-15-patroon. Bevestigd via verse export: `if (widget!.horecaid != null && widget!.horecaid != '') EvenementHorecagelegenheidWidget(... establishmentID: widget!.horecaid!, ...)` — de force-unwrap is nu veilig, want alleen bereikbaar binnen de guard. Uit deze lijst verwijderd.)* *(P1-26 volledig afgerond — Drupal-kant + FlutterFlow-kant, zie hieronder voor de volledige geschiedenis.)* Nieuwe Drupal Services-resource `favorieten` (acties `flag`/`unflag`/`is_flagged`) om favorieten server-side generiek te maken — niet meer alleen horeca-nodes (bestaande hartjes op `HorecagelegenheidoverzichtKaart`/`HorecagelegenheidCurrent` gebruiken nog hun eigen, oudere aanpak), maar ook **taxonomy terms (gemeenten)**, en ook de node-bundles `club`/`club_event`/`photo_book`. **Dit is de directe blocker-oplossing voor P1-7 Tab 2 "Favoriete gemeenten"** hierboven (die had nog geen enkel toggle-mechanisme voor taxonomy terms). **Aanleiding:** een collega had al een concept-`custom_services_resources()` + 3 callback-functies geschreven (flag/unflag/is_flagged via het Flag-module), werkte nog niet volledig. Chat-sessie 2026-08-20 heeft 'm gereviewd, gefixt en uitgebreid. **Gevonden/gefixte bugs in het concept (Claude, code-review, niet zelf op de Drupal-server toegepast — Bob heeft geen git-toegang tot deze server-code, dus dit moet hij zelf plakken):** 1. **Fataal:** de concept-code definieerde een tweede `function custom_services_resources() {...}`, terwijl `custom.module` die al één keer heeft (met `plaatsen` + `favorieten_agenda`) — twee functies met dezelfde naam is een PHP fatal error, legt de hele site plat zodra dit cachet wordt. Moet gemerged worden tot ÉÉN functie. 2. Entity-type was hardcoded tot alleen `'node'` — geen taxonomy-support, terwijl dat nou net het doel is. 3. Flag-namen waren geraden i.p.v. gecontroleerd. Bob's screenshot van `admin/structure/flags` gaf de echte namen: **`bookmarks`** (Flag type `node`, bundles: `club`, `club_event`, `photo_book`, `horecagelegenheid`, `activity`, `go_out_event`) en **`favorite_town`** (Flag type `taxonomy_term`, bundle `town`). Code aangepast om deze te gebruiken i.p.v. de placeholder `bookmarks_taxonomy`. 4. Een hardcoded node-type-whitelist in de eigen code (los van de Flag-config) werd losgelaten — `$flag->access()` kent de toegestane bundles al uit de Flag's eigen "Entity bundles"-instelling, dus een losse handmatige lijst zou steeds opnieuw uit sync kunnen raken met wat Bob in de Flags-UI instelt. **Deliverable (in de chat gegeven, nog NIET door Bob gedeployed/getest):** - Nieuw bestand **`custom.favorites_flag.inc`** (zelfde opzet als het bestaande `custom.favorites_agenda.inc`): helper `_custom_favorites_flag_name_for_entity_type()` + de 3 callbacks `_custom_favorites_flag()`, `_custom_favorites_unflag()`, `_custom_favorites_is_flagged()`. Alle 3 accepteren `entity_id` + optioneel `entity_type` (`'node'` default of `'taxonomy_term'`), forceren altijd de **huidige ingelogde gebruiker** (nooit een client-aangeleverde uid). - Twee toevoegingen aan het bestaande `custom.module`: (a) een `module_load_include('inc', 'custom', 'custom.favorites_flag');`-regel naast de bestaande includes, (b) een nieuwe `'favorieten'`-entry (met `'actions' => array('flag' => ..., 'unflag' => ..., 'is_flagged' => ...)`) toegevoegd aan de **bestaande** `$resources`-array in de al-aanwezige `custom_services_resources()` — niet een 2e functie aanmaken. - Curl-testcommando's gegeven voor alle 6 combinaties (flag/unflag/ is_flagged × node/taxonomy_term), POST naar `.../favorieten/.json` met sessie-cookie + `X-CSRF-Token`. **Drupal-kant afgerond en bevestigd (2026-08-20, Bob deployed + Claude curl-geverifieerd op productie, na Bob's melding "resource nog niet ge-enabled" → alsnog aangevinkt):** alle 6 combinaties (flag/unflag/ is_flagged × node/taxonomy_term) routeren nu correct — vóór de endpoint-activatie gaf elke aanroep een kale Drupal-HTML-404 (zelfde valkuil als `favorieten_agenda` destijds), ná activatie geeft elke aanroep de verwachte Services-JSON-403 voor een anonieme test-call: ``` POST .../favorieten/flag.json → 403 ["Access denied for user anonymous"] POST .../favorieten/unflag.json → 403 ["Access denied for user anonymous"] POST .../favorieten/is_flagged.json → 403 ["Access denied for user anonymous"] ``` **Open vraag opgelost: `is_flagged` gebruikt POST**, niet GET (een GET-aanroep bleef 404 geven, POST met dezelfde body gaf de verwachte 403) — belangrijk voor wie de FlutterFlow-kant bouwt. *(FlutterFlow-kant afgerond — commit `d8bbba4` (concurrente sessie, waarschijnlijk Bob, nacht 2026-08-20/21), bevestigd in code 2026-08-21 door Claude/sessie 42: favoriet-hartje toegevoegd op `HeaderButtonsComponent`, naast de gemeente-/provincienaam (Bob's gekozen "Optie 1" voor P1-7 Tab 2 — hartje bij de huidige keuze, geen losse lijst-kiezer). `header_buttons_component_widget.dart` bevat nu beide POST-aanroepen (`.../favorieten/unflag.json`/`.../favorieten/flag.json`), zelfde `ConditionalBuilder`-patroon als de bestaande horeca-hartjes: If (`favorieteGemeenteIds.contains(gemeenteSelectId)`) → gevuld hartje + unflag + `removeFromFavorieteGemeenteIds`; Else → leeg hartje + flag + `addToFavorieteGemeenteIds`, JSON-body `{"entity_id": , "entity_type": "taxonomy_term"}`, sessie-auth via `userSessionname`/`userSessionid`/`userToken`. **Geen `is_flagged`-call gebruikt** — zelfde lokale-lijst-aanpak als de bestaande horeca-hartjes (geen server-side sync-on-load), consistent maar niet per se toekomstbestendig als iemand op een 2e toestel inlogt. **Nog niet gebouwd, mogelijk vervolgstap:** Tab 2 "Favoriete gemeenten" op de Favorieten-pagina zelf toont nog steeds alleen de kale beschrijvingstekst, geen daadwerkelijke lijst van `favorieteGemeenteIds` (`favorieten_widget.dart`, `o7pt2vls`) — met Optie 1 als gekozen aanpak is dat mogelijk bewust (het hartje op `HeaderButtonsComponent` is de hele feature), maar dat is niet expliciet bevestigd door Bob. Uit deze lijst verwijderd als losse P1-taak.)* *(P1-13 afgerond 2026-08-24 — Claude, sessie 46, builder + live device-run emulator-5556, profile mode. Root cause (kale `Column` + `shrinkWrap: true`/`NeverScrollableScrollPhysics()` op een `MasonryGridView` zonder begrensde ouder) bleek al gefixt op `horecagelegenheden_overzicht_widget.dart` (bijproduct van de P1-10-herbouw, commit `d35492a`) — dezelfde fix (Expansion=Expanded + Shrink Wrap uit + Scrollable aan op de `StaggeredView`-node, builder-native, geen custom code) nu ook toegepast op alle 6 tabs van de 2e variant `horecagelegenheden_overzicht_provincie_page_widget.dart`. Bevestigd via 2 losse verse exports (0 resterende `shrinkWrap`/`NeverScrollableScrollPhysics`-treffers) + `flutter analyze` (geen nieuwe errors) + een live app-launch op emulator-5556 (`--route "/horecagelegenhedenOverzichtProvinciePage?plaats=28694"`, profile mode): Activiteiten-tab rendert en scrollt normaal, geen RenderFlex-overflow, geen exceptions in de log. Eerdere sessies liepen hierop vast door een bevestigd FlutterFlow-sync-probleem (edit leek opgeslagen, bereikte nooit de export) — dat trad deze keer niet meer op, mogelijk omdat de eerste succesvolle toepassing (Home/P1-10) het pad inmiddels vrijmaakte, of gewoon niet meer reproduceerbaar. Gecommit `59c6647`. Uit deze lijst verwijderd.)* *(P1-19 afgerond in de builder 2026-08-12 avond, maar **pas op 2026-08-13 avond echt in deze repo gecommit** — de destijds "bevestigd via verse export"-verificatie liep via een losse `/tmp/ff-check`-export, niet via deze projectrepo zelf; `git log -S"return Wrap("` bevestigde 0 eerdere treffers vóór vandaag. Inhoud ongewijzigd: alle 9 kale-Row-met-`List.generate`-tag-overflows (rechtsklik Row → Replace → Wrap) — Home (`HomeUitgaantabelKaartComponent`), `PUitgaanSliderKaartComponent`, `EventCurrent`, `EvenementHorecagelegenheid` (4x), `HorecagelegenheidCurrent` (cryptocoins), `PUitgaantabelKaartComponent`. Uit deze lijst verwijderd.)* *(P1-20 geïmplementeerd — bevestigd via lokale `git diff` op 2026-08-13 avond, tijdens Bob's eigen gelijktijdige `ff-run-fvm.sh`-build/testronde. **Gecommit 2026-08-14 (Claude, commit `fb6b224`)** — stond 15+ uur ongecommit in de working tree, zie sessie-notitie bovenaan dit bestand. Exacte match met het eerder uitgewerkte voorstel: `HeaderButtonsComponentWidget` kreeg een `showBackButton`-parameter (Boolean, default `true`), de terug-`AlignedTooltip`-node zit nu achter `if (widget!.showBackButton == true)`, en Home's instantie (`home_widget.dart`) zet 'm expliciet op `false`. Uit deze lijst verwijderd. **Kanttekening afgerond (2026-08-20, Claude, builder + verse-export-verificatie):** `login_widget.dart` gebruikte dezelfde component met de default `true` — zelfde zinloze Terug-knop op de entry-pagina als destijds op Home. `showBackButton: false` gezet op `HeaderButtonsComponentWidget`, bevestigd via verse export (`login_widget.dart:156`) + `flutter analyze` (alleen bestaande info-level lints, geen nieuwe errors). Gecommit `8e450be`.)* *(P1-21 gesloten zonder bouwwerk — Bob's beslissing 2026-08-16: geen losse custom widget voor de AdBanner-fallback. `PUitgaanPage`'s `FlutterFlowAdBanner` toont nu nog de debug-tekst zolang Google AdMob de app niet heeft goedgekeurd (kan pas ná livegang), maar dat lost zichzelf op zodra de app is goedgekeurd en AdMob echte advertenties gaat serveren — Bob's inschatting is bovendien dat deze fallback-tekst juist nodig kan zijn zodat Google de advertentie-integratie kan zien tijdens de review. Claude's eerder uitgewerkte `CleanAdBanner`-custom- widget-voorstel (verving de debugtekst door een lege `SizedBox`) is dus **niet gebouwd** — bewust afgewezen, niet vergeten. Geen actie meer nodig tot ná de Google/Apple-goedkeuring bij livegang; check dan of de debugtekst inderdaad verdwenen is. Uit deze lijst verwijderd.)* - **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. Check met Bob of P2-5's "waar wel/geen ads"-regel (geen ads op locatie-kiezer/login/account) al is toegepast op deze ene bestaande banner, en of er bewust voor `PUitgaanPage` gekozen is als eerste plek. *(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 volledig afgerond 2026-08-16 — Bob, builder, live pair-fix sessie: `EventCurrent`'s `TextTitle` heeft nu 8px rechter-padding (ruimte t.o.v. de deel-knop), en het kale `nid`-debugtekstwidget onder de titel is verwijderd. Beide bevestigd via verse export (`Padding(EdgeInsetsDirectional.fromSTEB(0.0, 0.0, 8.0, 0.0))` om `TextTitle`; 0 treffers meer voor `valueOrDefault(widget!.nid, 'nid')`). Alle eerdere schaduw-/spacing-restpunten (`PUitgaanSliderKaartComponent`, `HorecagelegenhedenOverzicht`) waren al langer afgerond. Uit deze lijst verwijderd.)* *(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 afgerond — bleek al volledig gebouwd vóór sessie 46 begon (commit `d35492a`, vóór deze sessie), TASKS.md liep gewoon achter op de code (zelfde valkuil als de vuistregel bovenaan dit bestand waarschuwt). Geverifieerd 2026-08-24 (Claude, sessie 46): `home_widget.dart` + `home_model.dart` hebben `tabActiviteitenGeladen`/`tabCultuurGeladen`/ `tabFilmsGeladen`/`tabJeugdGeladen`-flags (default `false`, tab 0 "Uitgaan" impliciet al zichtbaar), elk met een `ConditionalBuilder`-guard + een On-Tap-trigger op de bijbehorende `Tab`-node die de flag op `true` zet — exact het builder-native recept hieronder. Zelfde patroon ook op `horecagelegenheden_overzicht_widget.dart` (10 treffers) en `horecagelegenheden_overzicht_provincie_page_widget.dart` (8 treffers, dit is de hernoemde `..._page_data_type`-variant). De 3e variant (`..._sort_page`) hoefde niet: bleek intussen zelf orphan/kanweg (zie P2-7-bijvangst hieronder). `flutter analyze` op alle 3 bestanden: geen nieuwe errors. Geen resterend werk.)* *(P1-11 geïmplementeerd — bevestigd via lokale `git diff` op 2026-08-13 avond, tijdens Bob's eigen gelijktijdige `ff-run-fvm.sh`-build/testronde. **Gecommit 2026-08-14 (Claude, commit `fb6b224`)**. Fix op `HorecagelegenheidEventTabelComponentCopy` komt overeen met het eerder uitgewerkte voorstel: de tekst-tegel- Container verloor zijn hardcoded `height: 200.0` (blijft in `Expanded`, hoogte volgt nu de Row), en de afbeeldings-tegel-Container is nu zelf ook in `Expanded` gewrapt met `height: 60.0` i.p.v. `200.0`. Uit deze lijst verwijderd — Bob's eigen build/testronde moet dit nog live bevestigen (Events-tab van een horecagelegenheid, geen overflow meer).)* *(P1-27 afgerond 2026-08-21 — Claude, builder: Home-pagina `TabBar` kreeg "Tab Bar Scrollable" aan (zelfde recept als P1-7). Bevestigd via verse export: `isScrollable: true` op `home_widget.dart:216`. Labels tonen nu volledig uitgeschreven op telefoonformaat. **Nog even checken door Bob op tablet:** op dat formaat pasten de labels al zonder deze fix, maar stonden gelijkmatig uitgerekt over de volle breedte — met Scrollable aan staan ze vermoedelijk links uitgelijnd, wat compacter oogt maar niet live geverifieerd deze sessie. Uit deze lijst verwijderd.)* *(P1-28 afgerond 2026-08-21 — Claude, builder: beide takken (gevuld/leeg hartje) van de ConditionalBuilder op `HeaderButtonsComponent` kregen dezelfde `fillColor: Color(0xFFB50808)` als hun buurknoppen (hamburger, terug-pijl) — zelfde bordeauxrood, prima contrast met het witte hartje-icoon erop. Bevestigd via verse export: alle 4 IconButtons in `header_buttons_component_widget.dart` gebruiken nu identiek `fillColor: Color(0xFFB50808)`. Uit deze lijst verwijderd.)* **P1-29 · Eigenaar: Bob (Drupal-content, geen Claude-taak — vermoedelijk al gefixt voor nieuwe content, oude content mogelijk permanent beschadigd).** Her-bevestigd 2026-08-20 (Claude, look&feel-review, live op zowel `emulator-5554` als `emulator-5556`): letterlijke `?`-tekens i.p.v. emoji in een evenementbeschrijving ("Mythic Fest II", Provincie → Uitgaan-lijst) — bv. "??? ????????? ?????? ???? Ontsnap aan het alledaagse, stap in het mythische!". Dit **zag er eerder al bekend uit** (P1-22, `decodeUtf8: true` op alle 11 live API-calls, afgerond 2026-08-13) — maar staat dus nog steeds live, vandaag opnieuw gezien op een verse app-launch (niet een stale build zoals de eerdere "waarschijnlijk oude cache"-kanttekening bij P1-22). **Werkhypothese:** dit is geen teruggekeerde encoding-bug in de app, maar **al beschadigde content in de Drupal-database zelf** van vóór de decodeUtf8-fix — de fix voorkomt nieuwe corruptie bij het ophalen, maar herstelt geen tekst die al als kapotte `?`-tekens is opgeslagen. **Check bij Bob:** of het brontekstveld van dit specifieke evenement (of een steekproef van oudere evenementen) in Drupal zelf al `?`-tekens bevat i.p.v. emoji — zo ja, is dit alleen op te lossen door de content opnieuw in te voeren/ te herstellen in Drupal, niet in de app. **Werkhypothese bevestigd (2026-08-23, Claude, losse `curl` op de live API, geen browser/builder nodig):** de **ruwe** Drupal-response zelf (`.../flutterflowmobiel1.json?display_id=services_1`, nid **`214370`**, "Mythic Fest II") bevat al letterlijke `?`-tekens **op byte-niveau** (`b'??? ????????? \xef\xb8\x8f ...'` — echte `0x3f`-bytes, geen UTF-8-multibyte-sequentie die de terminal verkeerd toont), gemengd met een overlevende `\xef\xb8\x8f` (de variatieselector-byte-sequentie van een emoji). Dit is **geen client-side decodefout** — `decodeUtf8: true` (P1-22) kan hier niets aan doen, de bron zelf is al kapot. **Concrete actie voor Bob:** het `inhoud`/`body`-veld van node **214370** in Drupal zelf bekijken/herstellen (handmatig de tekst opnieuw intypen/plakken met de bedoelde emoji) — geen app- of API-wijziging nodig. **Steekproef gedaan (2026-08-23, Claude, `curl` over alle 7 `services_1`-t/m-`services_7`-displays × 4 pagina's, 700 item-doorlopen, geen dubbele nid's):** dit is **geen eenmalig incident** — **7 nid's** bevatten hetzelfde kapotte-`?`-patroon (2+ opeenvolgende `?`, buiten URL's): `214370` (Mythic Fest II), `212672` (Danceworks Eindshow - locatie IJmuiden), `211780` (PubQuiz), `211789` (Slimste Team Quiz), `211798` (Disney Quiz), `211794` (PubQuiz), `211810` (Muziekbingo: ladies editie). **Puur een heuristiek** (kan enkele valse positieven/negatieven missen bij losse of andere `?`-patronen) — bedoeld als concrete startlijst voor handmatig herstel in Drupal, geen uitputtende audit. ## P2 — features & concept, na livegang **P2-1 · Eigenaar: Bob — testen in de API, komt terug.** Datum-filter: Vandaag / Dit weekend / Deze week. **P2-2 · Eigenaar: Onbepaald, bewust v2 (herbevestigd 2026-08-25 door Bob).** Google Maps-**overzichtsweergave** (kaart met meerdere markers) van horecagelegenheden op de overzichtspagina — bewust niet vóór livegang (Maps API-key + billing, onduidelijk of elke locatie al lat/long heeft, marker-UI — geen quick win). **Niet te verwarren met P2-14** (los Google Maps-deep-link-icoontje per adres, geen kaart/API- key nodig — dat pakken we wél nu op). **P2-3 · Eigenaar: Onbepaald.** "In de buurt"/geolocatie-browsen — aanvulling op het provincie/gemeente-model, geen vervanging. **P2-4 · Eigenaar: Onbepaald.** Overige feature-ideeën, geen van alle uitgewerkt: deel-knop op eventpagina · "toevoegen aan agenda" (native kalender) · "events op deze locatie" prominenter op de horeca-detailpagina · reviews/waardering voor horecagelegenheden (groot, vraagt nieuw Drupal content-type + moderatie, eigen project). (De "Wat is er vanavond"-melding is uitgelicht naar **P2-10** hieronder — dat idee weegt zwaarder dan de rest van dit lijstje.) **P2-9 · Eigenaar: Onbepaald.** Onboarding/eerste-gebruik-uitleg. **Live bevestigd 2026-08-07 (Claude, emulator, `pm clear` + verse launch = echte eerste-keer-ervaring):** een nieuwe gebruiker opent de app en ziet **direct** de Home-pagina met bovenaan een carousel met kop "OOK LEUK" ("ook leuk" veronderstelt dat je al iets gezien hebt — vreemd als allereerste tekst) en daaronder een kale lijst events, geen welkomsttekst, geen uitleg wat Uitgaanskrant is, geen prompt om een provincie/gemeente te kiezen. (Zie ook P0-3's opmerking dat de eerste-launch-default-locatie 28666/28694 geen naam toont totdat iemand handmatig kiest.) Zonder duidelijke eerste indruk is de kans groot dat een nieuwe gebruiker de app na 1x openen niet snapt/niet terugkomt. **Twee kant-en-klare opties uitgewerkt (2026-08-25, Claude, code-only) — kies er 1, dan is de bouwtijd klein:** 1. **Kort welkomstblok bovenaan Home, alleen bij de eerste launch.** Nieuwe App State-variabele `onboardingGezien` (Bool, Persisted: true, default `false`). Op Home's Scaffold "On Page Load": een ConditionalBuilder (of Visibility-conditie op een nieuw Container/Text-blok bovenaan de bestaande Column, vóór de "OOK LEUK"-carousel) met conditie `onboardingGezien == false`. Inhoud: 2-3 zinnen ("Welkom bij Uitgaanskrant — ontdek wat er te doen is in jouw provincie of gemeente.") + een knop "Kies mijn gemeente" die naar `selectprovinciegemeente` navigeert én meteen `onboardingGezien` op `true` zet (Update App State, Set Value). Kleinste bouwtijd, raakt de bestaande Home-structuur nauwelijks aan. 2. **Eerste launch direct naar de gemeente/provincie-kiezer i.p.v. Home.** `initialLocation` zelf (`nav.dart`) is gegenereerde code en niet direct instelbaar — bouwbaar via Home's Scaffold "On Page Load": een Conditional Action op `gemeenteSelectId`/ `provincieSelectId` "Is Not Set" → Navigate To `selectprovinciegemeente` met "Allow Back Navigation" uit (zelfde `context.goNamed`-patroon als elders in dit bestand). Sterker (dwingt een locatiekeuze af, lost ook meteen P0-3's "default-locatie zonder naam"-punt structureel op voor nieuwe gebruikers), maar een grotere gedragsverandering voor iedereen zonder opgeslagen locatie, niet alleen eerste-launch-gebruikers. Bob's voorkeur bepaalt welke van de twee gebouwd wordt — geen van beide is al uitgevoerd. - ~~Bijvangst, zelfde verkenning: dode terug-pijl-knop in Home's AppBar~~ — **afgerond (2026-08-10, Claude).** `IconButtonBack` verwijderd via Widget Tree → rechtsklik → "Remove Widget" (op `HomeWidget` → `AppBar` → `Row`, naast `IconButtonDrawer`). Bevestigd via verse `flutterflow export-code`: geen enkele referentie meer aan `IconButtonBack`/het bijbehorende `Icons.arrow_back_outlined`-icoon in `home_widget.dart` — de AppBar-Row bevat nu alleen nog de hamburger-menuknop. Geen builder-sync-problemen bij deze simpele Remove-Widget-actie (i.t.t. P1-13's multi-property-toggle, zie daar). **P2-10 · Eigenaar: Onbepaald.** "Vanavond in [gemeente/provincie]"- herinnering (pushmelding of in-app-widget) — uitgelicht uit de ongestructureerde lijst van P2-4 omdat dit vermoedelijk de goedkoopste hefboom is voor **terugkerend gebruik**: dit type overzichts-app wint of verliest niet op features maar op of mensen 'm blijven openen. Een eenmalige/wekelijkse melding met "dit weekend in [gekozen gemeente]" is een directe reden om terug te komen, i.p.v. te wachten tot iemand toevallig weer aan de app denkt. **Hangt af van dezelfde Firebase-infra als P1-16** (Firebase Cloud Messaging naast Crashlytics/Analytics) — logisch om in dezelfde builder-sessie op te pakken als P1-16. Nog niet uitgewerkt qua precieze inhoud/frequentie (voorkom spam-gevoel) — eerst met Bob bespreken vóór bouwen. **P2-5 · Eigenaar: Onbepaald (horeca-overzicht resterend).** Ad-banners op horeca-overzicht, horeca-detail, event-detail; vaste regel: geen ads op locatie-kiezer/login/account. **Horeca-detail + event-detail afgerond (2026-08-25, Claude, builder + verse export + `flutter analyze` 0 errors + live build/launch op emulator-5554, Bob's expliciete akkoord in de chat).** Zelfde `FlutterFlowAdBanner`-widget + Ad Unit ID's (`ca-app-pub-2431417692812232/5511582981` iOS, `.../6657143691` Android) als de al werkende instantie op `PUitgaanPage` — gekopieerd via widget-tree "Copy" op de bestaande AdBanner-node + "Insert After" op een sibling-node net na de titel/datum-blok (`HorecagelegenheidCurrent`: na `TextTitelGelegenheid`, vóór de `TabBar`; `EventCurrent`: na `TextData`/datum, vóór de categorie-tags-`Row`). **Resterend: horeca-overzicht** — bewust overgeslagen, Bob's eigen Sort/Datatype-experiment op die pagina loopt nog (zie P2-6); oppakken zodra dat is afgerond, zelfde recept (kopieer de AdBanner-node vanaf een van de 3 al werkende pagina's). **P2-6 · Eigenaar: Claude, akkoord van Bob (2026-08-25) om te starten.** Tekstzoeken op naam **én categorie**, per tab van `horecagelegenheden_overzicht_widget.dart`/`..._provincie_page_widget.dart` (Bob's besluit: "op naam kunnen selecteren, tekstveld voor overeenkomstige namen", nodig op elke tab; uitgebreid met een categorie-filter na een live test hieronder). **Kritieke bevinding (2026-08-25, Claude, live curl-test op de productie-endpoint) — verandert de aanpak:** `HorecagelegenheidoverzichtCall` (`flutterflowmobiel_establishments.json`) hangt vast aan een **harde cap van 100 resultaten per aanroep**. Test op townid `28666`/`horcat=17967` gaf exact 100 terug (verdacht rond getal); een 2e gemeente (`28694`) gaf er 75 (onder de cap, dus waarschijnlijk het echte totaal). De endpoint **ondersteunt al een niet-gedocumenteerde `page`-parameter**: `page=1` op dezelfde 100-resultaten-gemeente gaf een **andere** set van 100 items (bevestigd via nid-vergelijking, geen overlap) — de data bestaat dus compleet op de server, de app haalt er nu alleen page 0 van op. **Gevolg: puur client-side filteren op de huidige, single-page lijst zou bij een grote gemeente stilletjes items missen** (precies Bob's zorg). Categorie-filter-opties moeten bovendien dynamisch opgebouwd worden uit de unieke `categorie`-waarden in de dataset (Bob: "die kan hij hebben van alle horecagelegenheden die hij inleest"), wat dus ook een complete dataset vereist. **Bijgewerkt bouwplan:** 1. **Builder:** `HorecagelegenheidoverzichtCall` krijgt een nieuwe parameter `page` (Integer of String, default `0`/`'0'`), toegevoegd aan de bestaande `params`-map (`'page': page`). 2. Nieuwe **Custom Action** `fetchAlleHorecagelegenheden(String horcat, String townid, String displayId) -> List`: roept `HorecagelegenheidoverzichtCall.call(...)` in een loop aan met oplopende `page` (0, 1, 2, ...), voegt elke pagina's resultaten samen, stopt zodra een pagina **minder dan 100** items teruggeeft (= laatste pagina) of bij een lege/foutieve respons (veiligheidslimiet op bv. 10 iteraties tegen een oneindige loop bij een onverwachte server-bug). 3. Eén `TextField` boven de `TabBar` (filtert de op dat moment actieve tab). Component/Page State `zoekterm` (String), gebonden via `onChanged`. 4. Categorie-filter: chips/dropdown, **opties dynamisch opgebouwd** uit de unieke `categorie`-waarden binnen de complete (alle-pagina's) lijst van de actieve tab — geen statische/hardcoded lijst. 5. Nieuwe **Custom Function** `filterHorecagelegenheden(List items, String zoekterm, String? categorieFilter, String titelPad, String categoriePad) -> List`: combineert naam-match (case-insensitive én **diacritics-genormaliseerd**, bv. "café" moet ook matchen op "cafe") met categorie-match (AND-logica: allebei moeten kloppen als beide ingevuld zijn). Lege `zoekterm`/geen categorie-filter → geen restrictie op dat onderdeel. 6. Elke tab's `Generate Dynamic Children`-"Value"-binding wijzigen van de rauwe API-response naar het resultaat van stap 2 (Component State, gevuld via een On-Page-Load/On-Tap-trigger die `fetchAlleHorecagelegenheden` aanroept), gefilterd via stap 5. **Advies/aandachtspunten:** - Debounce niet nodig — filteren gebeurt op een al volledig lokaal geladen array, geen API-call per toetsaanslag. - Dit raakt dezelfde pagina als Bob's Sort/Datatype-experiment — gestart nu met zijn expliciete akkoord (2026-08-25). - Style-tip: een "wis"-kruisje (`suffixIcon`) in het zoekveld is fijn UX; val niet in de bekende `TextFormField`-`suffixIcon`-Tooltip- beperking uit `CLAUDE.md` (geen Tooltip nodig, gewoon een losse `onTap` die `zoekterm` leegt). **P2-14 · Eigenaar: Claude (nieuw, 2026-08-25, Bob's idee).** Google Maps-icoon achter elk adres — bij horecagelegenheid-, stadsactiviteit- en uitgaansevenement-detailpagina's, tikken opent Google Maps (native app indien geïnstalleerd, anders browser) met het adres + plaats voorgevuld. Bob's eigen suggestie: als **losse herbruikbare Project Component** bouwen, niet per pagina dupliceren. **Bouwplan — geen Google Maps API-key/billing nodig** (dat is alleen voor een ingesloten kaart-weergave zoals P2-2, niet voor een simpele deep-link): 1. Nieuwe **Custom Function** `googleMapsUrl(String adres, String plaats) -> String`, bouwt `https://www.google.com/maps/search/?api=1&query=' + Uri.encodeComponent('$adres, $plaats')` — dit is Google's "Universal URL"-formaat: opent de native app op iOS/Android als die geïnstalleerd is, valt anders terug op de browser-versie, werkt zonder eigen API-key. 2. Nieuwe **Project Component** `GoogleMapsIconButton` met twee String- parameters (`adres`, `plaats`): een `Icon` (bv. `Icons.location_on_outlined` of `Icons.map_outlined`) → On Tap → **Launch URL** (categorie "Share", zie `CLAUDE.md`) → Value via Set from Variable → Custom Functions → `googleMapsUrl` met beide parameters gebonden. 3. **Paginascope bevestigd (Bob, 2026-08-25): stadsactiviteit deelt dezelfde detailpagina als uitgaansevenement** (`EventCurrent`/ `event_current_widget.dart`) — de onderliggende query voor die pagina levert al zowel `activity`- als `go_out_event`-nodes uniform op, dus 1 component-plek dekt beide. **Dus 2 plekken totaal:** `horecagelegenheid_current_widget.dart` en `event_current_widget.dart` (naast/achter het bestaande adres-`Text`-widget op elk). 4. **Bijvangst, genoteerd voor later (Bob, 2026-08-25): op `EventCurrent` ontbreekt momenteel het "horecagelegenheid"-blok** (de gekoppelde-horeca-sectie die op een echt evenement getoond wordt) voor stadsactiviteiten — logisch, want een activiteit heeft geen gekoppelde horecagelegenheid in het datamodel. Bob noemt dit een mogelijk later te herzien punt, **geen actie nu, geen onderdeel van P2-14** — apart laten staan tot Bob besluit of/hoe dit anders moet. **Akkoord van Bob (2026-08-25) om nu te starten** — geen blocker meer. **P2-7 · Eigenaar: Bob.** Opschonen: - Merge `kaartTabelUitgaanComp` + `kaartTabelUitgaanSComp` — Bob doet dit zelf ("ik kijk er zelf naar"). - `lib/kanweg` opnieuw leegmaken indien teruggekomen na een latere export-pull, plus eventuele nieuwe losse dode componenten in `lib/evenement/`. - *(5 bevestigde orphan-mappen — `lib/evenement/uitgaan_tabel_component(_small)`, `lib/kanweg/z_zuitgaantabel_component(small)`, `lib/uitgaanspaginas/uitgaantabel_kaart_component` — verwijderd 2026-08-24 (Bob, `git rm -r`, gecommit). `flutter analyze` na afloop: geen nieuwe errors.)* - **Nieuw gevonden (2026-08-24, Claude, sessie 46, tijdens P1-10- verificatie):** `lib/horecagelegenhedenoverzicht/horecagelegenheden_overzicht_sort_page/` (oude naam, klasse `HorecagelegenhedenOverzichtSortPageWidget`) is nu dubbel-dood — de builder heeft dit component al hernoemd naar `Kanweg...` (nieuwe map `lib/kanweg/kanweg_horecagelegenheden_overzicht_sort_page/`, en `nav.dart`/`index.dart` wijzen ook al naar die nieuwe naam), maar de **oude** map bleef lokaal achter i.p.v. door de export verwijderd te worden. Bevestigd via `grep`: 0 referenties naar de oude klassenaam buiten zijn eigen bestand. **Verwijderd (2026-08-25, Bob, `git rm -r`).** `lib/evenement/slider_uitgaan_component_small_current/` (de bekende `carouselResponse`-compile-fout uit de notitie hieronder) staat daarentegen nog wél in de verse export — dus nog niet door Bob opgeruimd, blijft een apart punt. - **Nieuw gevonden, echte compile-fout in dode code (2026-08-14, Claude, `flutter analyze` ná het committen van `fb6b224`):** `lib/evenement/slider_uitgaan_component_small_current/slider_uitgaan_component_small_current_widget.dart:109` — `Undefined name 'carouselResponse'`. Root cause: Bob's `ZZZhomeSliderCall`-verwijdering (P2-7 hierboven) haalde de omringende `FutureBuilder` weg (die `carouselZZZhomeSliderResponse` via `snapshot.data!` leverde) maar de binnenste `Builder` verwijst nog naar de oude variabelenaam, nu ongedefinieerd — een onvolledige refactor-restant, geen nieuwe eigen wijziging. **Geen impact op de gebouwde app:** bevestigd via `grep` dat geen enkel ander bestand `SliderUitgaanComponentSmallCurrentWidget` importeert (al bekend als dood, zie de `ZZZhomeSliderCall`-notitie hierboven), en een verse `flutter build apk --debug` **slaagde gewoon** (`✓ Built build/app/outputs/flutter-apk/app-debug.apk`) — Dart compileert alleen bestanden die vanaf `main.dart` bereikbaar zijn, dus deze fout raakt de live app niet. **Wel relevant:** dit component bestaat sowieso al niet meer in de builder (Bob kon het niet terugvinden, zie de eerdere `UitgaantabelKaartComponentWidget`-notitie hierboven) — waarschijnlijk hetzelfde soort orphan. Als dit ooit via de builder verwijderd wordt (samen met de andere `lib/evenement/`- opschoning), is deze compile-fout vanzelf opgelost; tot die tijd geen actie nodig, alleen genoteerd zodat een toekomstige `flutter analyze`-treffer hier niet als nieuwe/onverklaarde bug wordt aangezien. - Eén browse-by-category-patroon i.p.v. twee: nu Home landelijk is, bepalen hoe Home's categorieën en `PUitgaanPage`'s provincie/ gemeente-gescoopte categorieën zich tot elkaar verhouden. - **Dubbele Provincie/Gemeente-blok in het menu — exacte structuur in kaart gebracht (2026-08-24, Claude, code-only, `drawer_component_widget.dart`), klaar voor een beslissing:** de drawer heeft 2 identieke blokken van elk 6 links (2 headers + 12 sub-items totaal), allebei naar dezelfde `PUitgaanPageWidget`, enige verschil is welke App-State-variabele als `plaats`-scope meegaat: - **"Provincie"** (`FFAppState().provincieSelectId`): Uitgaan, Activiteiten, Cultuur, Films, Jeugd (services_3 t/m 7), + Horeca (→ `HorecagelegenhedenOverzichtProvinciePage`). - **"Gemeente"** (`FFAppState().gemeenteSelectId`): exact dezelfde 6 labels/services-ids, Horeca → `HorecagelegenhedenOverzichtWidget` (dus wél de andere pagina-variant dan het Provincie-blok, consistent met de bestaande provincie/gemeente-scoping elders in de app). - Los daarvan, niet gedupliceerd: "Thuis bezorgen". **3 opties om aan Bob voor te leggen (geen van alle uitgevoerd, puur prep):** 1. **Eén dynamisch blok** i.p.v. twee — toont automatisch de 6 links gescoopt op wat de gebruiker net koos (provincie òf gemeente via `SelectStateDropDownComponent`), halveert het menu naar 6 items. Kost: gebruiker kan niet meer in 1 tik wisselen tussen "heel mijn provincie" en "alleen mijn gemeente" browsen zonder terug naar de select-pagina. 2. **Beide blokken laten staan, maar één ervan inklapbaar/dichtgeklapt als default** (accordion) — geen functionaliteit verloren, wel minder eerste-oogopslag-drukte. 3. **Zo laten** — als Bob "in 1 tik zowel provincie- als gemeente-breed kunnen browsen" waardevol genoeg vindt, is dit eerder een dichtheids-kwestie dan een bug; kan als P2-polish blijven staan tot na livegang. - ~~`EventWidget`-route~~ — **gesloten zonder wijziging (2026-08-25, Bob's besluit).** Bevestigd orphan (2026-08-05, Claude, `grep`): de route staat correct geregistreerd (`nav.dart`, pad `/event`, param `nid`) en geëxporteerd (`index.dart`), maar **geen enkele `pushNamed`/navigatie-aanroep in de hele codebase gaat er ooit naartoe** — `EventCurrent` (pad `/eventCurrent`) is overal de daadwerkelijk gebruikte event-detailpagina. Alleen bereikbaar via een handmatige directe URL. **Bob probeerde de pagina op te ruimen (hernoemen naar `kanweg_`-prefix, verplaatsen naar de `kanweg`-map, een component eraf halen) — elke van die acties geeft in de builder dezelfde generieke "Invalid Action: The most recent action would have caused a crashing error, so we've undone it for you"-toast en wordt automatisch teruggedraaid, ook na een harde browser-reload.** Grep bevestigt dat er in de geëxporteerde code geen enkele referentie naar deze pagina bestaat buiten zichzelf — de blokkade zit dus in FlutterFlow's eigen interne project-graaf, niet in iets dat via de export zichtbaar/oplosbaar is. **Besluit: met rust laten.** Geen functioneel risico (100% onbereikbaar in de live app, ongeacht deze builder-staat) — alleen wat overbodige code die niet opgeruimd kan worden. Niet verder proberen tenzij een toekomstige FlutterFlow-update dit vanzelf oplost. - **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. **Bevestigd verwijderd (2026-08-14, Claude, `grep` op `class LoginCall`/`class GetcsrfCall` in `api_calls.dart`: 0 treffers) — Bob deed dit al in zijn 2026-08-13-build/testronde, nu gecommit (`fb6b224`).** - **Test/scratch-duplicaten — bevestigd verwijderd (2026-08-14, Claude, zelfde grep-check, allemaal 0 treffers in `api_calls.dart`):** `ZZ userEstablishments TEST` (`ZZUserEstablishmentsTESTCall`), `ZZZhomeSlider` (`ZZZhomeSliderCall`), `homeSlidershortDate` (`HomeSlidershortDateCall`), `ZZhome uitgaan` (`ZZhomeUitgaanCall`), `zzEstablishmentEvents Copy` (`ZzEstablishmentEventsCopyCall`), `EstablishmentsNew` (`EstablishmentsNewCall`, al bekend), `QueryCityId` (`QueryCityIdCall`) — 7 van de 8 voorgestelde verwijderingen zijn doorgevoerd (zelfde build/testronde, gecommit `fb6b224`). **Enige die bleef staan: `FavorietenAgendaTESTKANWEG` (`FavorietenAgendaTESTKANWEGCall`)** — nog steeds aanwezig in `api_calls.dart`, nog steeds geen enkele live-referentie (bevestigd). Losse, kleine restopruiming. - **⚠️ Poging door Claude (2026-08-14), 2x geprobeerd — nieuw bevestigd blocker-patroon, geen wijziging aangebracht.** API Calls-paneel → `FavorietenAgendaTESTKANWEG` → **Delete** → bevestigingsdialoog ("Delete this API Call from the project?") → **Delete**: de dialoog sluit netjes (geen freeze, i.t.t. de bekende geneste-Set-Variable-freezes elders in `CLAUDE.md`), maar de call **staat na een page-reload gewoon weer terug** in de lijst — 2x gereproduceerd (2e poging zelfs met een expliciete `Synced`-check vóór het navigeren). Een losse verse `flutterflow export-code` ná de eerste poging bevestigde hetzelfde: `class FavorietenAgendaTESTKANWEGCall` nog gewoon aanwezig in `api_calls.dart`. **Dit is niet hetzelfde patroon als de al bekende widget-tree-klikproblemen** (dit paneel is een platte lijst, geen canvas/tree-coördinaten, en de Delete-flow zelf werkt zichtbaar/klikbaar) — eerder een nieuw voorbeeld van het bredere "ziet er opgeslagen uit in de builder-UI, bereikt nooit de export"-patroon (zie P1-13/P0-3 punt 1 voor eerdere instanties). **Kant-en-klaar voor Bob:** API Calls-paneel (linker sidebar-icoon onder "Connect") → `FavorietenAgendaTESTKANWEG` → **Delete**-knop onderaan → **Delete** bevestigen — zelfde stappen, kost hem waarschijnlijk hetzelfde (nog niet getest of het bij hem wél persisteert), maar dit hoort niet nog een 3e keer door Claude geprobeerd te worden zonder nieuwe informatie. - **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`, `requestNewPassword`. **Kanttekening 2026-08-14:** `EstablishmentsCall` is in dezelfde build/testronde hernoemd naar `HorecagelegenheidoverzichtCall` (callName `'Horecagelegenheidoverzicht'`, zelfde endpoint/params `horcat`/`townid`/`displayId`) — geen verwijdering, puur een naamswijziging; alle aanroepende widgets (`horecagelegenheden_overzicht*`) zijn consistent meeveranderd, bevestigd via `grep`, geen dode/gebroken referenties. - 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-restpunt uit P0-3 (default-locatie 28666/28694 zonder naam) afgerond — bevestigd 2026-08-15 via de export-sync (zie sessienotitie bovenaan): `select_state_drop_down_component_widget.dart` zet nu ook `provincieSelectNaam = 'Noord-Holland'` en `gemeenteSelectNaam = 'Amsterdam (gemeente)'` naast de bestaande id-defaults. Bijvangst in dezelfde builder-sessie: een losse debug-`SnackBar` ("Provincies: X") die bij elke provincie-call verscheen is ook verwijderd.)* **P2-8 · Opgegaan in P1-7 (2026-08-09).** Hartje-tap op gemeente-/ provincienaam om te favorieten is nu onderdeel van de bredere Favorieten-pagina/profielscherm-taak — zie P1-7 hierboven voor scope en status. *(P2-11 afgerond 2026-08-21 — Claude, builder, sessie 42: categorie-tags van bordeauxrood (`#9A141D`) naar het groen van uitgaanskrant.com zelf (`#09B34A`) op de 2 bevestigde plekken — `TagCategorieComponent` (gedeeld door 9 pagina's/componenten) en `HorecagelegenheidoverzichtKaart` (eigen losse kopie). Bevestigd via verse export + `flutter analyze` (alleen bestaande info/warning-lints, geen nieuwe fouten): `grep -rn "0xFF9A141D" lib/` geeft nu 0 treffers meer in widget-code (alleen nog de losse, ongebruikte theme-definitie in `flutter_flow_theme.dart:341` — bewust niet aangepast, geen widget verwijst ernaar en de kleurwaarde die de builder daarvoor toont wijkt af van wat in de code staat, dus laagste risico om met rust te laten). Bordeauxrood blijft ongewijzigd voor branding/CTA's/hartjes. Oranje (`#FF680D`) en het donkere navchrome uit dezelfde analyse zijn grotere, niet-uitgevoerde vervolgstappen — zie de oorspronkelijke analyse in de sessiegeschiedenis als dat ooit weer relevant wordt. Uit deze lijst verwijderd.)* *(P2-12 afgerond 2026-08-21, sessie 43 — Claude, builder, bevestigd via verse export + `flutter analyze` (0 errors). Geen laad-placeholder/ skeleton bij afbeeldingen (carousel-kaarten, horeca-logo's) — gezien 2026-08-20 op zowel telefoon als tablet: een kaart toonde eerst een lege witte vlek, pas 1-2 seconden later de venue-foto/het logo. Geen crash/bug, maar oogde bij een trage verbinding als een kapotte/lege kaart. **Werkend recept:** niet via een handmatige `Shimmer`/`Container`-wrap (geen los "Placeholder"-veld beschikbaar op FlutterFlow's Image-widget), maar via de bestaande **"Use Blur Hash"**-toggle (Image-widget → rechterpaneel → zoek "blur") + een **vaste, algemene Blur Hash String** (`L6PZfSi_.AyE_3t7t7R**0o#DgR4` — een neutrale grijze placeholder-hash, niet gekoppeld aan de echte foto, want dit project heeft geen per-afbeelding blurhash-data uit Drupal). Genereert automatisch een `OctoImage` met `placeholderBuilder: (_) => Image(image: BlurHashImage('...'), fit: BoxFit.cover)` rond de bestaande `CachedNetworkImageProvider` — geen widget-tree-wijziging nodig, puur 2 property-velden op de bestaande Image-node. **Val op:** het "Blur Hash String"-tekstveld registreerde bij vrijwel elke widget de **eerste** typing niet (bleef leeg na Tab/blur), de **tweede** poging (zelfde klik-en-typ-actie herhaald) lukte steevast wel — altijd verifiëren via een verse export. **Alle 9 live `CachedNetworkImage`-plekken afgerond** (2 bevestigd confirmed-dode orphans bewust overgeslagen — `uitgaantabel_kaart_component_widget.dart` en `evenement_component_widget.dart`, zie P2-7): `horecagelegenheidoverzicht_kaart_widget.dart`, `home_uitgaantabel_kaart_component_widget.dart`, `horecagelegenheid_current_widget.dart` (foto-carousel), `event_current_widget.dart` (2x — foto-carousel + venue-logo), `evenement_horecagelegenheid_widget.dart` (2x — foto-carousel + establishment-logo), `horecagelegenheid_event_tabel_component_copy_widget.dart`, `uitgaantabel_kaart_widget.dart` (Favorieten Tab 1). Uit deze lijst verwijderd.)* **P2-13 · Eigenaar: Bob (Drupal-theme, geen FlutterFlow/Claude-taak — puur advies, niet uitgevoerd).** Op Bob's vraag (2026-08-21) ook de **bron-website zelf** (uitgaanskrant.com, niet de app) doorgelopen op look&feel, los van wat de app ervan kan overnemen (zie P2-11). Geen van onderstaande is een bug, puur observaties die het waard zijn om te overwegen bij een volgende theme-update: 1. **Dubbele onboarding-content bij eerste bezoek:** naast de gewone cookie-consent-balk verscheen ook een los infoblok ("1. Maak een account aan... 2. Word lid... 3. Ga naar je favoriete gemeente...") dat het scherm vult en apart gesloten moet worden — twee dialogen na elkaar voordat een nieuwe bezoeker de site ziet. Overweeg er 1 van te laten vervallen of te combineren. 2. **Zware advertentie-aanwezigheid direct boven de vouw:** rechter sidebar toont op de homepage meteen 2-3 gestapelde ad-achtige banners (evenementen-promotie, externe advertenties) naast de content — oogt druk/gedateerd vergeleken met de rest van de site. Kan geen kwaad om te bekijken of dit iets minder dicht op elkaar kan. 3. **Kleurenpalet is rijker dan de app maar niet overal doelbewust consistent** — groen (categorie-tags), oranje (titels/links/mobiel- menu-balk), blauw (actieve tab op de evenement-detailpagina), bordeauxrood (logo) staan naast elkaar zonder dat meteen duidelijk is welke kleur welke rol heeft (nav vs. content vs. status). Werkt in de praktijk prima, maar een kort "welke kleur betekent wat"- documentje zou toekomstige theme-wijzigingen consistenter maken (en is meteen de bron voor P2-11's app-kleuren hierboven). 4. **Kaartranden ogen gedateerd** (dunne 1px grijze randen, standaard Bootstrap-`panel`-stijl) — een subtiele schaduw i.p.v. een harde rand zou de site iets moderner laten ogen, puur cosmetisch. 5. **Positief, waard om te behouden:** de mobiele "☰ Menu"-balk (volle breedte, opvallend oranje, niet te missen) is duidelijker dan menig moderne site's kleine hamburger-icoontje — geen wijziging nodig, eerder een patroon om **naar de app te kopiëren** (zie P2-11/P1-27: de app's hamburger is een klein rood knopje, minder opvallend).