Página Principal Explorar Ajuda
Registe-se Iniciar Sessão
Uitgaanskrant.com
/
flutterflow
2
0
Fork 0
Ficheiros Problemas 0 Pull Requests 0 Wiki
Árvore: 0ab109fe9e
Ramos Etiquetas
flutterflow
/
TASKS.md

TASKS.md 63 KB
Histórico Em bruto

Uitgaanskrant — takenlijst

Bijgewerkt: 2026-08-09 (Claude, builder-sessie via MCP + live emulator-verificatie). 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-09): 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 · Eigenaar: Bob (restpunt — hintText, zie hieronder). De Login-pagina toonde onder de "Wachtwoord vergeten?"-link 5 interne test-/debug-navigatieknoppen — verwijderd (Claude, builder, 2026-08-09), live bevestigd op zowel emulator-5554 (telefoon) als emulator-5556 (tablet): geen enkele van de 5 knoppen ("HorecagelegenhedenOverzichtPage", "selectprovinciegemeent", "horecagelegenheid 57897", "puitgaan", "kanwegtest") staat nog in de Widget Tree of op het scherm. Geen regressie geconstateerd elders op de pagina (zie ook de valse-alarm-notitie bij P1-17 hieronder).

    Resterend (sub-bevinding, hetzelfde scherm) — geblokkeerd voor Claude, klein klusje voor Bob: de e-mail- en wachtwoordvelden hebben nog geen echte placeholder-tekst — hintText staat nog op de FlutterFlow-standaardtekst "TextField" (keys d507d3b9/t8h5f8ir in lib/flutter_flow/internationalization.dart, nl: 'TextField', en: '', live bevestigd op beide velden op beide emulators). Fix: widget UsernameField/PasswordField selecteren → rechterpaneel → zoek "hint" → Hint Text-veld → klik het kleine bolletje/ globe-icoontje rechts van het "Text"-label (Bob's eigen tip, 2026-08-09) om de vertaling te openen, i.p.v. direct in het tekstveld typen. Zet nl: 'E-mailadres' / en: 'Email address' resp. nl: 'Wachtwoord' / en: 'Password'. Waarom niet door Claude: het rechterpaneel is op dit scherm (393px-breed mobile-canvas-preview) te smal geclipt om dat globe-icoontje te bereiken — noch direct typen in het Hint Text-veld zelf werkte (geen enkele druk/toets kwam aan, ook niet via Localization-instellingen los, zie CLAUDE.md "bekende problemen").

    P0-1 · Eigenaar: Bob (10 sec klusje) — bevestigd nog open (2026-08-05). Home-slider crasht (RangeError) bij 0 API-resultaten. Bob koos: bij 0 resultaten component overslaan (niets tonen), geen melding. CarouselSlider.builder met itemCount: 0 crasht. Native fix: Carousel-widget (component HomeUitgaanSliderComponent → Widget Tree → ConditionalBuilder → If → Container → Carousel) → rechterpaneel → "Empty List Widget" → vink "Show Empty List Widget" aan → Widget Type instellen (bv. Image → Asset "logo800px.png", zelfde als het werkende patroon op HorecagelegenhedenOverzicht, zie P1-1). 2026-08-05, read-only gecheckt in de builder (Claude, geen klik op de checkbox zelf i.v.m. clipping-risico): "Widget Type" staat nog op "Unset". Bob dacht dit al ingesteld te hebben ("volgens mij heb ik dat ingesteld, bij geen gegevens dan een plaatje") — dat klopt dus nog niet, of de instelling ging niet door. De checkbox zelf viel niet af te lezen (rechterpaneel- clipping, zie CLAUDE.md), maar "Unset" bij Widget Type is op zichzelf al genoeg bewijs dat de configuratie niet compleet is. Bob: graag opnieuw instellen en dit keer een Widget Type kiezen (niet alleen de checkbox).

    P0-3 · Eigenaar: Bob (2 restpunten, allebei clipping/freeze-geblokkeerd voor Claude). Gemeente-/provincienaam tonen i.p.v. alleen het ID — basis is af (naam wordt al getoond via HeaderButtonsComponent op Home/PUitgaanPage/HorecagelegenhedenOverzicht+varianten/ HorecagelegenheidCurrent/SelectProvincieGemeente/Login, gevuld door provincieNaamById/gemeenteNaamById in de dropdown-acties). Hartje- tap-actie is losgekoppeld naar P2-8. Nog open:

    1. HeaderButtonsComponent → Widget Tree → node "Text" (3e kind van de Row, na de twee Tooltips) → rechterpaneel → Expansion → Flexible (staat nu op None — rechterpaneel-Expansion-control was niet bereikbaar voor Claude, clipping). Zonder Flexible kan een lange gemeente/provincienaam een RenderFlex overflowed-fout geven op smalle schermen.
    2. EventCurrent heeft geen gedeeld header-component (AppBar → Row met IconButtonBack/IconButtonDrawer, geen naam-Text). Toevoegen: nieuwe Text-widget als 3e kind van die Row → Conditional Value (If/Then/Else) → IF App State gemeenteSelectNaam Is Set and Not Empty → THEN gemeenteSelectNaam → ELSE provincieSelectName → Expansion → Flexible. Definitief bij Bob — Claude liep hier 5x vast op een bevroren Confirm-klik van de If/Then/Else-conditie (reproduceerbaar specifiek op dit widget/actie-type, zie CLAUDE.md).
    3. Laag risico, niet blokkerend: de component-load default-toewijzing (eerste app-start, id 28666/28694) krijgt nog geen bijbehorende naam mee — valt terug op lege naam tot iemand handmatig een provincie/gemeente kiest.

    P0-4 · Eigenaar: Bob. Werkende login + favorieten — resterende deeltjes. Basis is af: login gekoppeld, wachtwoord-vergeten-flow, favorieten drawer-link + 3-tabblad-pagina, hartje op horeca-kaart + -detailpagina. Nog open:

    • Lege-lijst empty-state op de favorietenpagina (nu kale/lege Container als er nog geen favorieten zijn). lib/favorieten/favorieten_widget.dart.
    • Bevestigen dat favorieten écht syncen via Drupal bij inloggen — root cause gevonden + gefixed (Claude, 2026-08-09), zie P1-18. De eerder aan Cloudflare Bot Management toegeschreven "FavorietenAgenda 403-fout" (lege Cookie-header bij FlutterFlow- requests) bleek gewoon het gevolg van de login-sessie die nooit werd opgeslagen — niets met Cloudflare/IP-reputatie te maken. Live bevestigd met testaccount bobcity op emulator: na de fix geeft flutterfavorietenagenda.json status 200 + geldige Cookie/X-CSRF-Token-headers + echte data i.p.v. de eerdere lege/anonieme 403. Kan hiermee als afgerond beschouwd worden zodra Bob dit ook zelf in de FavorietenAgenda-flow (niet alleen de kanweg-testpagina) bevestigt.

    P0-5 · Eigenaar: Bob. Drupal: anonieme leestoegang onderzoeken voor browse-endpoints. Drupal-niveau, geen Claude-taak.

    P1 — snel na livegang

    P1-18 · Eigenaar: Bob (1 conditie-edit in de builder — Claude vond het Actions-paneel voor deze knop niet, zie CLAUDE.md). Login-knop (login-pagina, "Inloggen") crasht altijd stil na een druk erop — geen succes-/foutmelding, en (belangrijker) de sessie werd nooit opgeslagen, waardoor elke beveiligde pagina (favorieten, kanweg) zonder sessie-cookie draaide. Root cause (bevestigd via flutter run-log, 2026-08-09): login_widget.dart:534 — if (_model.resultDrupalLogin!) { — behandelt het resultaat van de custom action drupalLogin (een JSON-map: {success, sessid, session_name, token, uid, name, mail}) alsof het een bool is. Dat crasht altijd met type '_Map<String, dynamic>' is not a subtype of type 'bool', ongeacht of de credentials kloppen — dus ook de regels daarna (FFAppState().userSessionid = ...) draaiden nooit. Functioneel al gefixed (Claude, Custom Code-editor): lib/custom_code/actions/drupal_login.dart zet de sessievelden (userSessionid/userSessionname/userToken/userName/userUid/ userMail) nu zelf al in FFAppState() vóórdat de crashende regel in de knop bereikt wordt — dat gebeurt dus altijd, ook al crasht de knop daarna nog steeds. Live bevestigd (emulator, testaccount bobcity): na inloggen + navigeren naar kanweg komt er nu een Cookie-header mee en status 200 i.p.v. de eerdere lege/403-request. Resterend (cosmetisch, builder-only): de If/Then-conditie ná de Custom Action-stap in de Inloggen-knop's Actions aanpassen van "resultDrupalLogin is true" naar een check op het JSON-veld $.success (zelfde recept als het bekende "Is Set and Not Empty tegen valueOrDefault"-patroon hieronder: bind tegen de rauwe getJsonField($.success)-expressie, operator "Is Set"/"== true"), zodat de succes-/foutmelding weer verschijnt. Claude kon het Actions-paneel voor deze knop niet vinden ondanks uitgebreid zoeken (widget-tree, canvas, rechtsklik-context-menu's, Cmd+K) — zie CLAUDE.md voor wat wel/niet geprobeerd is.

    P1-1 · Eigenaar: Bob (mechanisch, ~10 sec per stuk) — audit compleet, wachtend op Bob. Loading/foutafhandeling-patroon uitrollen naar overige lijst-/detailpagina's. Referentiepatroon bevestigd (2026-08-04, builder): rechterpaneel → "Empty List Widget" → "Show Empty List Widget" aan → Widget Type: Image → Asset "logo800px.png". Op HorecagelegenhedenOverzicht zelf al op alle 5 tabs aanwezig (geverifieerd via verse export 2026-08-04/05). 2026-08-05: volledige audit afgerond (Claude) van resterende Carousel-widgets zonder deze fix — allemaal read-only bevestigd "Widget Type: Unset"/leeg:

    1. HomeUitgaanSliderComponent → Carousel (= P0-1, zie daar)
    2. PUitgaanSliderComponent → Carousel — ontbreekt zelfs de ConditionalBuilder-wrapper om de Carousel (i.t.t. de andere 3), dus mogelijk P0-ernstig: dezelfde itemCount:0-RangeError-crash als P0-1 kan hier nog optreden zonder enige vangnet.
    3. EvenementComponent → Carousel (foto-carousel van één evenement)
    4. horecagelegenheidCurrent → Carousel (foto-carousel van één horecagelegenheid) — live bevestigd 2026-08-05 (Claude, emulator, deep link ?nid=999999999, niet-bestaand item): exact het verwachte RangeError (length): Invalid value: Valid value range is empty: 0 op-scherm, 3x. Bevestigt dat dit al een échte crash is, niet alleen een theoretisch risico.
    5. Waarom bij Bob i.p.v. Claude: de "Show Empty List Widget"- checkbox is structureel onbereikbaar via Claude's browser-automation-viewport (bevestigd op alle 4 hierboven, zie CLAUDE.md bekende problemen) — geen per-component toeval, dus verder proberen door Claude heeft geen zin. Bob: dezelfde twee klikken (checkbox aan + Widget Type instellen) 4x herhalen op bovenstaand lijstje, kost in eigen browser seconden per stuk.

    P1-3 · Eigenaar: Bob — geblokkeerd op rechterpaneel-clipping. Sliderkaartje: datumregel mist de Flexible-wrap. Bevestigd nog open (2026-08-04: regels 310/351 in p_uitgaan_slider_kaart_component_widget.dart hebben Flexible om de Text, regel 273-281 niet). Fix zit in builder: component PUitgaanSliderKaartComponent → Widget Tree → node "Text-datum" (Text-widget, kind van de Row met Icons.calendar_month, tussen "Text-title" en de horecagelegenheid-Row) → rechterpaneel → property "Expansion" → moet net als bij "Text-horecagelegenheid"/"Text-adres" op Flexible gezet worden i.p.v. None. Geblokkeerd: de 3 Expansion-type-iconen (None/Expanded/Flexible) renderen net buiten het zichtbare/klikbare canvas rechts van het "Flex"-invoerveld — bekend rechterpaneel-clippingprobleem (zie CLAUDE.md). Geprobeerd: directe klik op geschatte positie, paneel-scroll, paneel-drag-resize, "Wrap Widget"-dialoog (geen Flexible-optie daarin, alleen structurele widgets) — geen succes. Kost Bob vermoedelijk seconden op zijn eigen scherm.

    P1-4 · Eigenaar: Bob. EstablishmentsCall crasht zonder categoriefilter. horcat ??= null!; — bevestigd nog aanwezig, regel

    1. Nu geen probleem omdat elke aanroep toevallig altijd een filter meegeeft, wel een landmijn voor de toekomst. lib/backend/api_requests/api_calls.dart. Fix zit vermoedelijk in de FlutterFlow API-call-configuratie (default parameterwaarde), niet in lokale code.

    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 · Eigenaar: Bob (mechanisch, maar groot — spreid over sessies). Letterlijke veldnaam i.p.v. nette placeholder bij ontbrekende data. 2026-08-05: audit herhaald (Claude, verse grep) — scope flink groter dan de eerdere 13 treffers van 2026-08-04, met name evenement_horecagelegenheid_widget.dart bleek nog niet meegenomen. Patroon overal hetzelfde: valueOrDefault<String>(<bron>, '<default>') waarbij de default gelijk is aan de veld-/functienaam. Fix is mechanisch (Default Value-tekst aanpassen in de builder op het Text-widget), maar raakt dezelfde "Set from Variable"-property als de Empty-URL-fix — zelfde risico-inschatting als het CachedNetworkImage-patroon. Niet in één sessie proberen af te maken gezien de omvang hieronder (~45 treffers); pak het file-voor-file op.

    • horecagelegenheidoverzicht_kaart_widget.dart:359/383/410 — titel/adres/plaats
    • evenement_info_widget.dart:136/158/213/238/293 — adres/plaats/entreeprijs/entreetoelichting/contact
    • evenement_component_widget.dart:221/242/317/339 — title/eventDate/adres/plaats (317/339 zijn nieuw t.o.v. de 2026-08-04-audit, waren toen nog niet aanwezig of gemist)
    • horecagelegenheid_current_widget.dart:377/500/747 — title/logo/content (volledig nieuw gevonden, stond niet in de vorige audit)
    • event_current_widget.dart:327/418/442 — title/nid/date (327 en 442 zijn nieuw t.o.v. de 2026-08-04-audit, alleen nid stond er al in)
    • evenement_horecagelegenheid_widget.dart — grootste blok, ~30 treffers, volledig nieuw t.o.v. de vorige audit (waarschijnlijk pas zichtbaar geworden na de P1-image-crash-fix-uitbreiding van dit component): regels 178(HorecaNaam), 418(establishmentnid), 445(email), 476(Logo), 499(Plaats), 533(Adres), 577/586/597 (Telefoon, 3x — icoon/tekst/tooltip-varianten), 642(menukaart), 710(entreeprijs), 743(EntreeToelichting), 818/827/843(facebook, 3x), 885/894/910(instagram, 3x), 952/961(twitter, 2x), 1016/1025/1041(Website, 3x), 1083/1092/1108(urluk, 3x), 1194(Openingstijden), 1222(OpeningstijdenUitzondering), 1310(Bezorgtijden), 1337(bezorgkosten), 1364(bestellink).
    • Grensgeval (geen letterlijke veldnaam maar wel technische/zinloze placeholder, zelfde fix-aanpak): p_uitgaan_slider_kaart_component_widget.dart:284 toont 'def' als datum ontbreekt.
    • 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).
    • Let op — voor de Facebook/Instagram/Twitter/Website/urluk-knoppen op evenement_horecagelegenheid_widget.dart is dit géén puur cosmetisch probleem, zie P1-15 hieronder: de Default-Value-tekst aanpassen lost daar de crash niet op, alleen de zichtbare tekst als hij (na de P1-15-fix) wél verborgen wordt.

    P1-15 · Eigenaar: Bob (builder — Claude geblokkeerd, zie hieronder). Kapotte zichtbaarheids-conditie op de social-/ contact-knoppen laat de app crashen bij tikken (niet alleen lelijke tekst) — vermoedelijke verklaring voor de herhaalde Invalid argument(s): No host specified in URI-excepties die 2026-08-07 in de live flutter run-log van de andere sessie verschenen (naast de al bekende P1-13-overflows, niet met elkaar verwarren — twee losse foutmeldingen in dezelfde log).

    • Root cause bevestigd (code-niveau, lib/evenement/evenement_horecagelegenheid/evenement_horecagelegenheid_widget.dart): de Facebook- (r. 812-829), Instagram- (879-896), Twitter- (~946-961), Website- (1010-1027) en urluk-knop (1077-1094) zijn elk gewrapt in if (valueOrDefault<String>(<veld>, '<placeholder>') != null && valueOrDefault<String>(...) != ''). Omdat valueOrDefault bij een lege/ontbrekende bron altijd de placeholder-tekst teruggeeft (nooit null/''), is deze conditie altijd waar — de knop is dus altijd zichtbaar én tikbaar, ook zonder échte link. Bij tikken roept onTap launchURL(valueOrDefault<String>(...)) aan (lib/flutter_flow/flutter_flow_util.dart:61, Uri.parse(url) → launchUrl(uri)) met de kale placeholder-string (bv. 'facebook', 'Website', 'urluk') als URL — geen geldig schema/host, vandaar de crash. Hetzelfde broken-guard-patroon staat ook op de Telefoon-tekst (r. 571-588) maar die crasht niet (geen launchURL, alleen Text) — daar is het wél puur het P1-6-cosmetica-probleem.
    • Fix (builder): op elk van de 5 knoppen de Visibility/If-conditie niet tegen de valueOrDefault-uitkomst laten toetsen, maar tegen het rale API-veld zelf (dezelfde JSON Path-expressie als de Image-URL-fix in CLAUDE.md, operator "Is Set" i.p.v. != null && != '') — zelfde patroon als het al gedocumenteerde CachedNetworkImage-fix-recept. Zonder deze fix blijft ook een betere Default-Value-tekst (P1-6) een tikbare crash-knop.
    • Nog te controleren of hetzelfde patroon ook elders voorkomt (bv. horecagelegenheid_current_widget.dart heeft vergelijkbare velden, maar daar is maar 1 losse != null &&-treffer gevonden — niet diep genoeg nagekeken deze sessie om zeker te zijn dat het daar wél goed staat).
    • Scope vermoedelijk groter dan gedacht: 2026-08-07, live op de emulator, verscheen Invalid argument(s): No host specified in URI al herhaaldelijk op/vanaf de Home-pagina zelf, vóór enige navigatie naar een horecagelegenheid-detailpagina. Dat wijst erop dat hetzelfde kapotte-guard-patroon ook in Home-gerelateerde componenten zit (bv. de Home-sliderkaartjes of de "OOK LEUK"-tegels), niet alleen in evenement_horecagelegenheid_widget.dart. Nog niet tot de exacte plek herleid — bij oppakken van deze taak breder zoeken dan alleen het al gevonden bestand.
    • Poging door Claude (2026-08-09 avond), geblokkeerd op Widget-Tree-coördinaten — geen wijziging aangebracht. Component EvenementHorecagelegenheid geopend, maar de 5 knoppen (diep genest onder TabBar → TabBarPageInfo) bleken niet betrouwbaar te bereiken: klik-coördinaten op een zichtbare tree-rij selecteerden herhaaldelijk een andere rij, en de offset was niet constant (eerste meting +42px, twee stappen later +21px) — dus geen vaste correctie toe te passen zoals CLAUDE.md's kalibratietruc suggereert. De "Search for widget..."-zoekbalk in het paneel pakte maar één keer focus (na een klik op het "collapse"-icoontje ernaast), en zelfs toen gaf zoeken op Facebook geen enkel resultaat (wijst erop dat de knoppen intern niet zo genoemd zijn — zoek in de builder dus niet blind op die letterlijke naam). Concreet stappenplan voor Bob (in eigen browser, geen coördinaat-problemen): component EvenementHorecagelegenheid openen → Widget Tree → TabBar → TabBarPageInfo-tak uitklappen tot de Facebook/Instagram/Twitter/Website/urluk-knoppen (rond regel 812-829/879-896/946-961/1010-1027/1077-1094 in de geëxporteerde code, zie hierboven) → op elk van de 5: Visibility/If-conditie open → First Value aanpassen van de valueOrDefault-gebonden expressie naar de rauwe API-veld-expressie (zelfde JSON Path, vóór de Default Value-substitutie) → operator van != null && != '' naar "Is Set". Zelfde recept als de al werkende CachedNetworkImage-fix in CLAUDE.md.

    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.

    P1-17 · Eigenaar: Onbepaald. 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. 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.

    P1-7 · Eigenaar: Claude — bezig (2026-08-09). Favorieten-pagina + profielscherm — Bob heeft de scope + designbeslissingen 2026-08-09 gegeven, absorbeert ook het oude P2-8 (gemeente-favoriet). Belangrijke bevinding vooraf (code-audit, niet eerder gedocumenteerd): de 3-tabblad-structuur op FavorietenWidget bestaat al (Persoonlijke agenda/Favoriete gemeenten/Favoriete Gelegenheden), maar alle 3 tabs zijn pure placeholder-tekst — geen enkele API-call/FutureBuilder. Én: het hartje op zowel de horeca-overzichtskaart als de horeca-detailpagina is een kale print('IconButtonFavoriet pressed ...')-stub (horecagelegenheidoverzicht_kaart_widget.dart:334, horecagelegenheid_current_widget.dart:364) — er bestaat nergens in de codebase een POST/toggle-call om een favoriet daadwerkelijk op te slaan, alleen de GET-only FavorietenAgendaCall (ondanks de naam: geeft favoriete horecagelegenheden terug, geen agenda/events). De eerdere P0-4-aantekening "hartje... af" klopte dus alleen voor het zichtbare icoon, niet voor de functionaliteit erachter.

    Bob's beslissingen (2026-08-09):

    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. "Persoonlijke agenda" (tab 1) = events in de door de gebruiker gefavoriete gemeente(n) (niet de her-toegekende naam "agenda" op de bestaande horeca-GET-call — dat is een aparte, nog te bouwen view).
    3. "Gebruiker"-tab = het oude P1-7-scope (wachtwoord wijzigen, uitloggen, account verwijderen), nu als tab i.p.v. aparte pagina. Account verwijderen heeft mogelijk AVG-implicaties aan Drupal-kant. Let op prioriteit: Apple's App Store Review Guideline 5.1.1(v) eist in-app accountverwijdering voor een app met accountaanmaak — zonder dit scherm blokkeert een iOS-submissie, niet alleen P1.

    Open vraag aan Bob (blokkeert het schrijf-/sync-gedeelte): bestaat er al een Drupal-endpoint om een favoriet (horeca of gemeente) toe te voegen/verwijderen voor een ingelogde gebruiker (bv. Flag-module of een custom Services-resource), of moet dat nog gebouwd worden? Zonder endpoint-naam/-vorm kan Claude alleen de lokale kant (state, UI, hartje-toggle-optimistic-update, logout) bouwen, niet de sync. Onbelemmerd te bouwen, ongeacht antwoord: FFAppState-velden voor lokale favorieten-lijsten (gemeenten + horeca), hartje-toggle die lokaal al werkt (optimistic UI), uitloggen op de Gebruiker-tab (geen backend nodig — alleen FFAppState-sessievelden wissen + terug naar Login).

    Geblokkeerd voor Claude (2026-08-09), klein klusje voor Bob: de "+ Add App State Variable"-knop (?tab=appValues&appValuesTab=state) reageert niet op Claude's klikken — geen dialoog, geen nieuwe rij, 6+ pogingen zonder resultaat (zie CLAUDE.md voor details). Bob: graag deze 2 App State-velden zelf toevoegen (kost seconden in eigen browser):

    1. favorieteGemeenteIds — type List<String> (gemeente-ID's, zelfde ID-vorm als gemeenteSelectId/gemeentelijst), Persisted: true.
    2. favorieteHorecaNids — type List<String> (horeca-nid's, zelfde vorm als FavorietenAgendaCall.establishmentNid), Persisted: true.

    Zodra deze 2 velden bestaan kan Claude verder (hartje-toggle, tab-content vullen) — de rest van de bouw hangt hier niet losstaand van vast.

    P1-12 · Eigenaar: Bob (builder, gegenereerde code niet lokaal te fixen). EventCurrent crasht direct (Null check operator used on a null value) op een deep link met wél nid maar zonder horecaid query-param. Gevonden 2026-08-05 (Claude), live bevestigd op emulator via adb shell am start -d "uitgaanskrant://uitgaanskrant.com/eventCurrent?nid=999999999" (bewust zonder horecaid). Root cause: event_current_widget.dart:808, establishmentID: widget!.horecaid! — geen fallback. Alle in-app navigatie naar EventCurrent stuurt nid+horecaid altijd samen mee (gecheckt, alle pushNamed-aanroepen vullen beide), dus dit raakt geen normaal gebruik — wel elke deep link/gedeelde link/push-notificatie die ooit alleen nid meegeeft (bv. een toekomstige "deel-knop", zie P2-4). Fix: in de builder op EventCurrent → widget-tree → de EvenementHorecagelegenheidWidget-instantie → establishmentID-param een Default Variable Value/valueOrDefault toevoegen i.p.v. de kale !, zelfde patroon als P1-6. (Losstaand: de bekende Carousel- RangeError op deze en de horecagelegenheidCurrent-pagina bij een niet-bestaande nid is al gedekt door P1-1 punt 4 — live bevestigd, zie daar.)

    P1-13 · Eigenaar: Onbepaald. Op HorecagelegenhedenOverzicht → tab "Activiteiten" gooit de kaartjesgrid herhaaldelijk RenderFlex overflowed-fouten — zowel "on the right" (oplopend van 16 tot 243 pixels, tientallen keren) als één keer "on the bottom" (2653 pixels). 2026-08-07 (Claude): logcat-onderzoek geprobeerd, geen resultaat — geen actieve flutter run/attach-sessie beschikbaar deze sessie (leeg terminal, adb logcat toonde geen Flutter-frames), dus geen verse stack trace te pakken. Op basis van codelezing wél een concrete, nog niet geverifieerde hypothese: HorecagelegenheidoverzichtKaartWidget (horecagelegenheidoverzicht_kaart_widget.dart:337-349) kiest de breedte van de tekst-kolom via MediaQuery.sizeOf(context).width (200/250/300/350px) — dat is de volledige schermbreedte, terwijl deze kaart altijd in een 2- of 3-koloms MasonryGridView staat (horecagelegenheden_overzicht_widget.dart:346-361). Bij logische breedte tussen kBreakpointMedium(767) en kBreakpointLarge(991) → grid met 2 kolommen, kaart-tekstkolom kiest 300px — dat past mogelijk niet meer naast de afbeeldingskolom in een halve-schermbreedte grid-cel. Onzeker of dit de daadwerkelijke overflow-oorzaak is: de tekstkolom staat in een Expanded, en Expanded geeft normaliter tight constraints die een child's eigen width-property juist overschrijven (BoxConstraints.enforce) — dus in theorie zou dit net NIET mogen overflowen op Row-niveau. Kon dit niet verifiëren zonder Flutter DevTools/Layout Explorer in een live debug-sessie. Volgende sessie: als er een live flutter run/flutter attach-sessie beschikbaar is (met console-output), reproduceer de overflow op tab Activiteiten en lees de volledige stack trace — die geeft de exacte widget/regel. Zonder dat blijft dit gokken. 2026-08-07 middag, opnieuw reconfirmed (read-only logtail van de andere sessie's actieve flutter run): de "on the right"-overflows blijven zich herhaaldelijk voordoen (16 t/m 219px, tientallen keren) — nog steeds niet opgelost. In diezelfde log ook Invalid argument(s): No host specified in URI-excepties gezien — dat is een los probleem, zie het nieuwe P1-15 (niet dezelfde oorzaak als deze RenderFlex-overflow).

    • **2026-08-09 avond (Claude): eigen flutter run-sessie gestart, overflow live gereproduceerd (screenshot, tab Activiteiten op emulator-5554) — maar nog steeds geen verse stack trace specifiek voor déze overflow te pakken, om een structurele reden (zie CLAUDE.md "Slechts één volledige RenderFlex-stack trace per flutter run-sessie"): Flutter dumpt maar één keer per proceslevensduur de volledige details; die ene keer ging naar de al langer bekende PUitgaanSliderKaartComponent-overflow op de Home-pagina (P1-3), niet naar deze Activiteiten-tab-kaart, omdat de app bij het opstarten al op HorecagelegenhedenOverzicht stond (onthouden vorige route) en dáár al eerder overflowede vóór ik kon navigeren. Een hot-restart zou de teller resetten maar dat kon niet: ff-run-fvm.sh draait via Bash run_in_background met stdin op /dev/null (niet-interactief), dus geen R-toets te sturen. Flutter DevTools (devtools-URL uit de log) bleek zelf ook een Flutter-Web-canvas-app zonder toegankelijke DOM/accessibility-tree — dezelfde soort blokkade als de FlutterFlow-builder, niet verder onderzocht.
      • **Code-niveau heronderzoek van de 2026-08-05-hypothese (Expanded+width-Container in HorecagelegenheidoverzichtKaartWidget, regels nu 343-357 i.p.v. 337-349 — lichte regelverschuiving, geen inhoudelijke wijziging t.o.v. eerdere audit): de Row op regel 152 (mainAxisSize: MainAxisSize.max, kinderen Flexible(...) + Expanded(...)) kan qua Flutter-constraint-model niet zelf overflowen — dat is precies het doel van Flexible/Expanded: de flex-child krijgt hoe dan ook nooit meer dan zijn toegewezen Row-ruimte, ongeacht een eigen width-property. Bevestigt de eerdere twijfel in de hypothese hierboven. Er zit ook geen geneste Row verderop in deze widget die zónder Flexible/Expanded-wrap zou kunnen overflowen (title/adres/plaats zijn losse Text-widgets in een Column, geen Row). Conclusie: deze widget is vermoedelijk niet de bron — de werkelijke oorzaak moet elders liggen (bv. de buitenste Container(width: 600.0, height: 225.0) in horecagelegenheden_overzicht_widget.dart:388-390 die als itemBuilder-return in de MasonryGridView staat, of iets in het logo/categorie-tag-Stack dat nog niet volledig nagelopen is).
      • Volgende sessie, concrete aanpak om wél een verse stack trace te pakken: start flutter run niet via de standaard run_in_background-Bash-aanroep maar met stdin gekoppeld aan een named pipe (mkfifo), zodat een R (hot restart) tussentijds te versturen is — reset Flutter's interne _errorCount en dwingt de eerstvolgende exceptie weer een volledige dump af. Navigeer direct na de restart zo snel mogelijk naar Activiteiten-tab vóórdat een andere pagina (Home) een eigen overflow veroorzaakt en de dump-slot opsoupeert.
    • **2026-08-09 avond, tweede sessie: de mkfifo-aanpak hierboven uitgeprobeerd en bevestigd niet werkend — geen doodlopende hypothese meer, dus niet opnieuw proberen.** flutter run gestart met stdin gekoppeld aan een named pipe (met een losse sleep 3600 > $FIFO & als permanente writer om de pipe open te houden) en daarna R/R\n in de pipe geschreven — geen "Performing hot restart..." verschijnt ooit in de log, de toetsaanslag komt nooit aan. Waarschijnlijke oorzaak: Flutter's interactieve keyboard-handler test op een echte TTY (stdin.hasTerminal/Terminal.usesTerminalUi) vóór hij raw keypresses verwerkt — een FIFO is geen TTY, dus de handler activeert zich niet, ook al accepteert flutter run de pipe zonder foutmelding. Een echte fix zou script -qc/socat+pty nodig hebben (niet geprobeerd, groter tijdsrisico dan de opbrengst rechtvaardigt).

    • Werkende alternatieve route (geen hot-restart nodig): cold-start direct de doelpagina via deep link + kale adb logcat, geen flutter run-attach nodig. Activiteiten is toevallig al initialIndex: 0/de eerste tab van HorecagelegenhedenOverzicht (horecagelegenheden_overzicht_widget.dart:49/238-241) — dus adb logcat -c → am force-stop com.uitgaanskrant.app → am start -a android.intent.action.VIEW -d "uitgaanskrant://uitgaanskrant.com/horecagelegenhedenOverzicht" com.uitgaanskrant.app landt bij cold start meteen op de juiste tab, vóórdat Home ooit gebouwd wordt — omzeilt het hele dump-slot-race-probleem zonder pipe-trucs. adb logcat (debug builds) toont dumpErrorToConsole-output gewoon via de flutter-tag, onafhankelijk van een actieve flutter run-sessie. Nog niet tot een verse stack trace gekomen bij uitvoering, om twee losse praktische redenen, niet omdat de methode niet deugt:

      1. Geprobeerd op emulator-5556 (tablet, 1280px logische breedte) — landde correct op tab Activiteiten maar toonde een lege grijze Container, geen kaarten, geen overflow (zie ook bijvangst hieronder). Dat spoort met de bestaande breedte-hypothese: bij 1280px logische breedte pakt de MasonryGridView vermoedelijk de 3-koloms/"large"-breakpoint, niet de 2-koloms/"medium" waar het probleem wordt vermoed — tablet is dus niet het device om dit op te reproduceren, gebruik emulator-5554 (telefoon).
      2. emulator-5554 had op het moment van onderzoek al 80+ minuten een eigen actieve ff-run-fvm.sh-sessie draaien (PID zichtbaar via ps aux, sinds 14:55) — een read-only screenshot bevestigde live dat de overflow-banner daar al zichtbaar stond ("BOTTOM OVERFLOWED BY 5382 PIXELS" op tab Activiteiten, dus het probleem is nog steeds aanwezig, nu met een andere/grotere pixelwaarde dan de eerder gelogde 2653px — mogelijk meerdere losse overflow-plekken op dezelfde tab). Bewust niet force-stopt/herstart om die sessie niet te verstoren (kon niet vaststellen of dat Bob's eigen live sessie was of restant-state) — zie CLAUDE.md-concurrency-regel. Een logcat -d-check op dat moment vond geen EXCEPTION CAUGHT/RenderFlex overflowed-tekst meer terug — de ring buffer was na 80+ minuten al doorgerouleerd, de oorspronkelijke dump is dus sowieso niet meer terug te halen uit die sessie.
      3. Volgende sessie, snelste concrete pad: bevestig eerst dat emulator-5554 vrij is (geen recente sessie, zie CLAUDE.md-concurrency-regel), dan de bovenstaande logcat+deep-link-cold-start-procedure dáár uitvoeren (niet op de tablet) — geen mkfifo nodig, geen flutter run-attach nodig, dus ook uitvoerbaar met alleen adb/Bash zonder run_in_background.
      4. Bijvangst, mogelijk apart P1-1-achtig puntje: op de tablet- breedte toont tab Activiteiten bij (schijnbaar) geen/nog niet geladen resultaten een kale lege grijze Container, geen nette empty-state-afbeelding zoals het HorecagelegenhedenOverzicht- patroon elders in dit bestand (P1-1) beschrijft — niet geverifieerd of dit een echt lege dataset was of een timing- kwestie (deep-link-cold-start kan nog geen gemeente/provincie- context gezet hebben). Bij het oppakken van bovenstaand punt even meenemen: als tab Activiteiten op tablet-breedte structureel leeg blijft zonder duidelijke reden, is dat een aparte bug.
      5. Zelfde avond, direct vervolg (Bob akkoord om zelfstandig door te werken op emulator-5554): het lege-databeeld hierboven verklaard én opgelost — plaats-query-param ontbrak. HorecagelegenhedenOverzichtWidget verwacht een plaats-param (= FFAppState().gemeenteSelectId, zie nav.dart:194/drawer_component_widget.dart:1173-1180) — zonder param geen data. Deep link uitgaanskrant://uitgaanskrant.com/ horecagelegenhedenOverzicht?plaats=28666 (bekende default-gemeente-id uit P0-3) cold-start op emulator-5554 reproduceerde de bug meteen en consistent ("BOTTOM OVERFLOWED BY 5382 PIXELS", exact dezelfde waarde als eerder die avond) — mét echte kaarten (De Beun, Hotel Den Helder), zónder ooit Home te bouwen. Dit lost het dump-slot-race- probleem dus wél op — maar de opvolgende adb logcat -d-check bevatte alsnog geen enkele regel met "overflow"/"RenderFlex"/ "exception", ondanks dat de banner zichtbaar op het scherm stond. Conclusie: FlutterError.dumpErrorToConsole-output komt op dit device/deze Flutter-versie niet via de "flutter"-tag in adb logcat terecht (eerdere sessies kregen de stack trace altijd via een live flutter run's eigen STDOUT/VM-service-verbinding, nooit via logcat zelf — dat onderscheid was tot nu toe niet expliciet vastgesteld). Herziening van het "volgende sessie"-advies hierboven: de logcat-route alléén volstaat niet, ondanks de succesvolle reproductie. Nodig blijft een echte VM-service- verbinding. Twee opties, geen van beide deze sessie nog beproefd (tijdsbudget op):
      6. flutter run starten met stdin aan een echte pty (bv. via script -qc "fvm flutter run -d emulator-5554" /dev/null of socat) i.p.v. de kale mkfifo hierboven (bevestigd niet-werkend — geen TTY) — dan ná de deep-link-reproductie een R sturen is niet eens meer nodig omdat de deep-link zelf al vóór Home reproduceert; gewoon de sessie starten, dan de deep-link-cold-start hierboven uitvoeren, dan STDOUT lezen.
      7. Rechtstreeks praten met de Dart VM Service (JSON-RPC over WebSocket, poort staat in flutter run's opstart-log) via curl/een klein script — geeft toegang tot foutmeldingen/ widget-inspector zonder DevTools' canvas-UI nodig te hebben. Niet geprobeerd, onbekend hoeveel opzoekwerk de exacte RPC-methode kost. Herbruikbaar ongeacht welke optie: de plaats=28666-deep-link- truc hierboven blijft de snelste manier om exact op het probleem te landen zonder Home's eigen overflow ertussen te krijgen.
      8. Optie 1 (script -qc) meteen geprobeerd, ook niet werkend — maar om een andere, environment-specifieke reden dan de TTY-check. script -qc "fvm flutter run -d emulator-5554" logfile < fifo gestart (fifo + een losse sleep 3600 > fifo &-writer om de pipe open te houden, zelfde patroon als eerder): flutter run boot prima op (key-commands-lijst toont nu correct zowel r als R, een teken dat de pty-laag wél als terminal herkend wordt — beter dan de kale fifo), maar het hele proces beëindigde zichzelf binnen enkele seconden (Script done ... COMMAND_EXIT_CODE="0") — dus vóórdat er ooit een toets verstuurd kon worden. Waarschijnlijke oorzaak: dit was gestart binnen een Claude Code run_in_background-Bash-aanroep; zodra het getrackte voorgrondcommando binnen die aanroep klaar is (hier: na de echo ok), lijkt de tool-harness de hele procesgroep op te ruimen — óók de losse, disown'de achtergrond- subshell die de fifo openhield, en daarmee indirect ook script/ flutter run zelf (EOF op stdin zodra de laatste writer weg is). Dit is dus niet (alleen) een Flutter/TTY-beperking maar een beperking van hoe deze sandbox achtergrondprocessen beheert — losse disown'de kindprocessen overleven een run_in_background- aanroep hier niet betrouwbaar zodra het main-commando zelf eindigt. Nog niet geprobeerd: nohup + setsid (volledig loskoppelen van de procesgroep, niet alleen disown) — theoretisch zou dat dit specifieke reap-probleem kunnen omzeilen, onbevestigd.

      9. Update, zelfde avond: setsid bevestigd de fix — interactieve flutter run (incl. werkende R-hot-restart) is nu een betrouwbaar herhaalbaar recept, bewaar dit:

        mkfifo /pad/naar/fifo
setsid bash -c "exec 9>'/pad/naar/fifo'; sleep 3600" < /dev/null > /dev/null 2>&1 &
disown
# in een aparte run_in_background Bash-call:
setsid script -qc "fvm flutter run -d <device>" /pad/naar/logfile < /pad/naar/fifo > /dev/null 2>&1 &
disown
# later, in weer een eigen call, om te restarten:
printf 'R' > /pad/naar/fifo

        De sleutel is setsid op beide achtergrondprocessen (niet alleen disown) — dat geeft ze een eigen sessie, los van de run_in_background-Bash-call die ze opstartte, en ze overleven daarna gewoon zolang nodig, ook over meerdere losse tool-calls heen. Hiermee wél een verse, volledige stack trace gevangen — alleen niet (nog) voor de Activiteiten-tab-overflow zelf: het gat tussen R versturen en de daaropvolgende deep-link-navigatie (adb shell am start -a android.intent.action.VIEW -d "...") bleek 2x achter elkaar te laat (~0.3-1s vertraging door tool-call-overhead) — Home's eigen overflow (zie P1-19 hieronder) vuurt binnen die tijd al. Race dus nog niet gewonnen; wel de infrastructuur om het te proberen nu solide. Idee voor een volgende poging (niet meer beproefd deze sessie): de deep-link vanuit een tweede, al-vooraf-klaarstaande adb-aanroep zonder tussenliggende Bash-tool-round-trip versturen (bv. beide commando's — R sturen én de deep-link — in één Bash-aanroep met een zo kort mogelijke sleep ertussen, i.p.v. twee losse tool-calls), of onderzoeken of flutter attach (i.p.v. flutter run) op een al lopend, via deep-link cold-started proces een raceloze combinatie oplevert.

    P1-19 · Eigenaar: Onbepaald. Nieuwe, nog niet eerder gedocumenteerde RenderFlex overflowed-crash op de Home-pagina, live bevestigd met een volledige, verse stack trace (2026-08-09, via de setsid- interactieve-flutter run-sessie hierboven, 2x identiek reproduceerbaar bij elke fresh app-start/hot-restart):

    A RenderFlex overflowed by 113 pixels on the right.
Row:file:///.../lib/uitgaanspaginas/home_uitgaantabel_kaart_component/home_uitgaantabel_kaart_component_widget.dart:301:50
constraints: BoxConstraints(0.0<=w<=111.5, 0.0<=h<=152.0)
size: Size(111.5, 40.0)

    Root cause (code-niveau bevestigd, home_uitgaantabel_kaart_component_widget.dart:299-301): een Row (mainAxisSize: MainAxisSize.max) met children: List.generate(categorieitem.length, ...) — voor elk element in de dynamische categorie-lijst van een evenement wordt een TagCategorieComponentWidget-pilletje in de Row gezet, zonder Wrap, zonder horizontale scroll, zonder Expanded/Flexible per tag. Zodra een evenement 2+ categorieën heeft (of één lange categorienaam), passen de pilletjes niet in de ~111px die de Row van zijn ouder krijgt. Dit is dezelfde soort bug als de al bekende ontbrekende-Flexible-patronen (P1-3/P1-11), maar op een ander component dan beide daar genoemde — niet eerder in dit bestand vermeld. Fix (builder): component HomeUitgaantabelKaartComponent → Widget Tree → de Row met de TagCategorieComponentWidget-kinderen (rond de hierboven genoemde code) → wrappen in een Wrap-widget (i.p.v. Row) zodat tags naar een volgende regel overlopen, of een horizontale SingleChildScrollView eromheen zodat ze scrollen i.p.v. overflowen — zelfde afweging als Bob eerder maakte voor vergelijkbare tag-rijen elders. Nog niet gecheckt of hetzelfde patroon (kale Row van List.generate-tags, geen wrap) ook voorkomt op de niet-Home-varianten van dit component (PUitgaantabelKaartComponent/kaartTabelUitgaanComp/ kaartTabelUitgaanSComp, zie ook de P2-7-opschoonnotitie over die laatste twee) — bij het oppakken van deze taak even meenemen.

    P1-9 · Eigenaar: Onbepaald. Visuele polish (los, per pagina) — resterend na sessie 2026-08-06:

    1. Nog niet opgepakt: Event-pagina (typografie/contrast/spacing).
    2. Restpunt PUitgaanSliderKaartComponent-schaduw (builder → Widget Tree → beide Containers binnen de root-Row, rechterpaneel- eigenschappenzoekbalk "offset"): Offset Y staat op beide containers nog op 12 (target: 2, zelfde als PUitgaantabelKaartComponent). Blur (nu 4) en Offset X (nu 0, bevestigd via geëxporteerde code) staan al goed — alleen Offset Y bleek herhaaldelijk niet via Claude's browser-automation in te stellen (rechterveld rendert buiten het klikbare venster, en een Tab-naar-volgend-veld-workaround liet de waarde niet altijd vasthouden). Hoekafronding is al prima opgelost (uniform 24px op de afbeelding-Container, 12px — exact gelijk aan het tabel-kaartje — op de tekst-Container). Bob: Offset Y typen via het gewone rechterpaneel-veld lukt in eigen browser vermoedelijk gewoon (geen bekende clipping bij hem).
    3. Al afgerond sessie 2026-08-06 (Claude, builder): PUitgaanSliderKaartComponent schaduw verzacht (blur 6→4, offsetX 12→0, hoekafronding asymmetrisch→uniform) zodat die minder afwijkt van het tabel-kaartje; PUitgaanPage padding toegevoegd tussen advertentiebanner en tabellijst; HorecagelegenheidoverzichtKaart titel kreeg maxLines: 2 (voorkomt ongelijke kaarthoogtes in de grid); categorie-tag-kleur op datzelfde kaartje gelijkgetrokken naar huisstijlrood #9A141D (was paars-blauw #CC4B39EF, afweek van het gedeelde TagCategorieComponentWidget elders in de app).
    4. Al afgerond sessie 2026-08-07 (Claude, builder), live bevestigd op emulator: HorecagelegenhedenOverzicht — TabBar nu gewrapt in een Container met een zachte onderschaduw (#33000000, blur 4, offsetY 2 — zelfde stijl als de kaartjes) zodat de lijst niet meer direct tegen de tabs plakt bij scrollen. HorecagelegenheidoverzichtKaart — de categorie-tag-pilletjes (bv. "Bioscoop"/"Theater" op "De Beun") overlapten rommelig met logo-afbeeldingen; de omringende Column kreeg een halfdoorzichtige donkere achtergrond (#40000000, geen eigen padding — leunt op de al bestaande 8px Padding eromheen) als zachte "backing" tussen tags en logo-artwork.
    5. Bevinding voor volgende sessies (builder-workflow): de "Search properties..."-zoekbalk bovenaan het rechterpaneel is een betrouwbare workaround voor het bekende clipping/scroll-probleem — filtert eigenschappen op naam (bv. "blur", "offset", "radius", "padding") i.p.v. moeten scrollen door een niet-scrollende paneel- sectie. Voor een enkel numeriek veld: klik veld → Ctrl+A → typen → Tab/Enter werkt niet altijd betrouwbaar (soms blijft de oude waarde staan zonder foutmelding) — controleer na elke edit met een screenshot van het gefilterde veld; bij twijfel triple-click + Delete
      • typen i.p.v. Ctrl+A gebruiken, werkte in deze sessie consistenter. Verificatie via View Code (rechtsboven </>-icoon) is nuttig maar risicovol te bereiken: de icoontjes rechtsboven verschuiven afhankelijk van app-state (commit-icoon verschijnt/verdwijnt) — 3x per ongeluk een ander icoon geraakt (2x "Create Commit"-dialoog, 1x "Make Project Public"-dialoog, 1x app-preview) door te gokken op vaste coördinaten. Veiliger: direct navigeren naar https://app.flutterflow.io/code/uitgaanskrant-1qhvtd?component=<Naam> i.p.v. op het icoon te klikken, en binnen die code-view Ctrl+F gebruiken (werkt als browser-find) i.p.v. handmatig scrollen (scroll- wheel-events op die pagina reageren nauwelijks).

    P1-10 · Eigenaar: Bob (10 sec-klusje, geblokkeerd voor Claude — clipping). Performance — resterend werk (audit afgerond 2026-08-05, Claude, code-niveau):

    1. Low-risk quick win, builder-only (geen codewijziging): zet cache: true op HomeTabelCall (api_calls.dart:465) en op GemeentenCall/ProvinciesCall (api_calls.dart:1274/1306, gebruikt in select_state_drop_down_component_widget.dart) — nu cache: false, terwijl de onderliggende data (categorielijst per Home-tab resp. provincie/gemeente-referentielijst) binnen een sessie feitelijk statisch is. EstablishmentsCall heeft dit al goed staan (cache: true, werkt functioneel correct — ApiCallOptions extends Equatable met params/headers in de props, dus geen reference-equality-bug) en is het te volgen voorbeeld. **2026-08-05, geprobeerd door Claude op homeTabel (API Calls → Advanced Settings → "Cache API Results"-toggle aanzetten): toggle zet zelf prima aan, maar de "Confirm"-knop van de daaropvolgende opslag-bar (Cancel/Confirm) rendert buiten het browservenster — nieuw bevestigd geval van het bekende rechterpaneel/actiebalk- clippingprobleem uit CLAUDE.md (nu ook horizontaal op de API-Calls-pagina, niet alleen op Widget Tree-panelen). Geprobeerd: directe klik, scroll, DOM/shadow-DOM-doorzoeking op tekst "Confirm"/ "Cancel" (niets gevonden — Flutter Web HTML-renderer, geen standaard-knoppen), Flutter-accessibility-semantics geforceerd geactiveerd (flt-semantics-placeholder, hielp niet), Tab- toetsnavigatie. Geen succes — wijziging veilig teruggedraaid (toggle weer uit, geen halve state). Bob: 3x deze toggle aanzetten (homeTabel, gemeenten, provincies) en de Confirm-knop rechtsonder klikken (in eigen browser wél gewoon zichtbaar/klikbaar).
    2. Groter/structureel, nog te beoordelen: 4 pagina's (Home, horecagelegenheden_overzicht(_sort_page/_page_data_type)_widget.dart) hebben een TabBarView met 6-7 tabs die allemaal gelijktijdig hun eigen API-call vuren bij page-load (Flutter bouwt alle tabs eager, geen lazy-tabs) — ook de tabs die de gebruiker nog niet ziet. cache: true (punt 1) verhelpt dit niet — dat voorkomt alleen herhaling bij een latere rebuild, niet de eerste gelijktijdige burst. Echte fix vraagt een structurele herbouw (bv. IndexedStack met on-demand FutureBuilder per tab-activatie i.p.v. TabBarView) — vermoedelijk custom code. Geen bekend rate-limit-probleem op de Drupal-API, dus mogelijk lage prioriteit ondanks de N×-overhead.
    3. Bijvangst tijdens de audit: dode EstablishmentsNewCall verplaatst naar de P2-7-opschoonlijst.

    P1-11 · Eigenaar: Bob — geblokkeerd op rechterpaneel-clipping (zelfde patroon als P1-3). Responsive/screensize. 2026-08-05: venue-event-grid-bug uitgezocht (Claude, code-niveau) — root cause gevonden, mechanische builder-fix, nog niet uitgevoerd:

    • Component: HorecagelegenheidEventTabelComponentCopy (lib/horecagelegenhedenoverzicht/horecagelegenheid_event_tabel_component_copy/...widget.dart), gebruikt op de "Events"-tab van HorecagelegenheidCurrent (enige gebruiksplek — geen niet-"_copy"-variant meer aanwezig om simpel in te wisselen).
    • GridView (regel 165-172): crossAxisCount: 2, childAspectRatio: 3.0 → elke grid-cel wordt ≈ (schermbreedte/2) breed × (celbreedte/3) hoog — op een telefoon van 390px breed dus ≈190×63px per cel.
    • Binnen elke cel (regel 178-315): een Row met twee Containers die beide hardcoded width: 200.0, height: 200.0 hebben (tekst-tegel regel 186-187, afbeeldings-tegel regel 294-295/311-312 incl. de CachedNetworkImage zelf). De tekst-Container zit wel in Expanded (dus de breedte krimpt mee), maar de hoogte (200) niet — Expanded in een Row regelt alleen de hoofdas (breedte), niet de dwarsas (hoogte). De afbeeldings-Container zit zelfs helemaal niet in Expanded — noch breedte noch hoogte passen zich aan.
    • Gevolg: content wil 200px hoog zijn in een cel van ≈63px hoog, en de afbeeldings-tegel wil alléén al 200px breed zijn terwijl de hele cel maar ≈190px breed is (gedeeld met de tekst-tegel ernaast) — RenderFlex overflowed-fouten/afgeknipte layout op de Events-tab van elke horecagelegenheid-detailpagina.
    • Voorgestelde fix (mechanisch, builder-property-wijzigingen, geen nieuwe widgets nodig): in de builder op HorecagelegenheidEventTabelComponentCopy → Widget Tree → de twee Containers binnen de Row (tekst- en afbeeldings-tegel): (1) hoogte 200 vervangen door een responsieve waarde (bv. Expanded ook op de dwarsas laten werken via een buitenste AspectRatio, of de vaste height: 200 gewoon verwijderen en de Row's hoogte laten bepalen door childAspectRatio), (2) de afbeeldings-Container ook in Expanded wrappen zodat beide tegels de celbreedte delen i.p.v. allebei 200px te claimen.
    • 2026-08-05, poging door Claude: in Widget Tree op de tekst- Container geselecteerd — het "Height"-veld (Container Properties) en de "Expansion"-segmented-control (None/Expanded/Flexible) renderen beide net buiten het browservenster, exact hetzelfde structurele rechterpaneel-clippingprobleem als P1-3 (bevestigd met eigenschappen-zoekfilter, scroll, directe klik op geschatte positie — geen succes, geen wijziging aangebracht). Bob: fix hierboven + P1-3's Expansion-fix in dezelfde sessie oppakken, scheelt heen-en- weer-navigeren.

    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. Google Maps-weergave van horecagelegenheden — bewust niet vóór livegang (Maps API-key + billing, onduidelijk of elke locatie al lat/long heeft, marker-UI — geen quick win).

    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. Nog geen concrete builder-fix uitgewerkt — eerst met Bob bespreken wat voor onboarding gewenst is (korte welkomsttekst? meteen naar provincie/gemeente-keuze i.p.v. Home?) vóórdat dit gebouwd wordt.

    • Bijvangst, zelfde verkenning: Home's AppBar heeft een hardcoded terug-pijl-knop (Icons.arrow_back_outlined, roept context.pop() aan) naast het hamburger-menu-icoon (lib/uitgaanspaginas/home/home_widget.dart, rond de FlexibleSpaceBar). Op de root-pagina is er niets om naar terug te gaan — live getest, de knop doet niets (geen crash, stille no-op), maar oogt verwarrend/onafgemaakt op het allereerste scherm. Kleine fix: knop weghalen op Home, of automaticallyImplyLeading/ conditie gebruiken zodat hij alleen verschijnt op pagina's waar terug-navigeren zinvol is.

    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. Ad-banners op horeca-overzicht, horeca-detail, event-detail; vaste regel: geen ads op locatie-kiezer/login/account.

    P2-6 · Eigenaar: Onbepaald. Tekstzoeken op titel op de horeca-overzichtspagina (los van de Datatype/Sort-experimenten die Bob daar zelf op test — die zijn actief werk-in-uitvoering, geen dode code).

    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/.
    • 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 opruimen (12 menu-items waar 6 zouden volstaan).
    • EventWidget-route: heraansluiten of definitief schrappen (losse orphan-route). Bevestigd orphan 2026-08-05 (Claude, grep): 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. Beslissing (verwijderen uit nav.dart+index.dart, of alsnog ergens aan koppelen) ligt bij Bob.
    • EstablishmentsNewCall (lib/backend/api_requests/api_calls.dart:845) wordt nergens meer aangeroepen — dode API-call-definitie (gevonden bij de P1-10-performance-audit 2026-08-05).

    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.