TASKS.md: P0-7 afgerond bevestigd (Bob's Drupal-fix, live gecheckt op De Beun) + nieuwe P0-8 (Info/Links/Bezorgen-tabs HorecagelegenheidCurrent breken zichtbaar met echte data: RenderFlex-overflow + 17x letterlijke 'null'-tekst, mechanisch fix-recept uitgeschreven). P1-9/P1-15 EventCurrent-punten teruggezet naar Bob na herhaald geblokkeerde widget-tree-klikprecisie deze sessie (geen wijziging aangebracht, exacte stappen genoteerd).

TASKS.md

@@ -1,12 +1,28 @@
 # Uitgaanskrant — takenlijst
 
-Bijgewerkt: 2026-08-13 (Claude, zelfstandige code-audit-sessie, geen
-builder-toegang gebruikt).
+Bijgewerkt: 2026-08-13 avond (Claude, builder + emulator-sessie, Bob
+gelijktijdig actief).
 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-13, zelfstandig, code-only — geen builder-UI
+**Deze 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
@@ -313,92 +329,82 @@ die zonder functie is zodra de app alleen tegen productie draait.
 treffers van deze exacte header in `api_calls.dart` — geen voortgang,
 taak blijft valide.
 
-**P0-7 · Eigenaar: Bob (Drupal-niveau — root cause bevestigd server-side,
-geen Claude/app-taak).** Horecagelegenheid-infodata (titel/inhoud/logo)
-komt **structureel niet aan** — bevestigd 2026-08-12 op een verse
-build, live op 2 verschillende gelegenheden (niet 1 incident).
-**Root cause definitief bevestigd (2026-08-12, Claude, directe curl
-op de Drupal-endpoint, buiten de app om):** het endpoint achter
-`EstablishmentInfoCall`
-(`https://uitgaanskrant.com/en/flutterdrup/views/flutterflowmobiel_establishment_info.json?display_id=services_1&nid=<nid>`,
-`lib/backend/api_requests/api_calls.dart:907-908`) geeft voor **elke**
-geteste `nid` een **HTTP 500** terug (Drupal's generieke "The website
-encountered an unexpected error. Please try again later."-pagina, geen
-JSON) — getest met 3 verschillende echte nid's uit de live
-establishments-lijst (`91142` = De Beun, `91140` = Hotel Den Helder,
-`58844` = Brasserie Veldt), allemaal 500. Ook geprobeerd met `/nl/`
-i.p.v. `/en/` als taalprefix (de andere API-calls in dit project
-gebruiken allemaal `/nl/` — dit ene endpoint wijkt af) en zonder
-taalprefix: **blijft 500**, dus de taalprefix-inconsistentie is niet de
-oorzaak (wel een aparte kleine inconsistentie om ooit recht te trekken).
-De app-kant (`getJsonField`/`valueOrDefault`/JSONPath) doet exact wat
-hij moet doen met een kapotte respons: stil terugvallen op de
-design-time placeholder — **dit is dus geen Flutter/FlutterFlow-bug,
-het is een kapotte Drupal Views-`display` (`services_1` op de
-`flutterflowmobiel_establishment_info`-view)**. Fix zit aan
-Drupal-kant: de Drupal-watchdog/PHP-errorlog raadplegen voor de exacte
-exceptie (productie toont geen foutdetails naar buiten, dus die is
-alleen server-side te vinden) — vermoedelijk een kapotte
-Views-relatie/veld sinds een eerdere wijziging aan het content-model
-(bv. de recente favorieten/media-uitbreidingen). **Bijvangst tijdens
-het testen:** de establishments-lijst-endpoint (`EstablishmentsCall`)
-werkt zelf prima — dat verklaart ook waarom de "events op deze
-locatie"-carousel op dezelfde pagina wél goede data toont: die gebruikt
-een ander, werkend endpoint.
-
-**Live bevindingen in de app zelf (2026-08-12, symptoombeeld — de
-root cause hierboven is inmiddels het echte aanknopingspunt, dit is
-puur de zichtbare impact):**
-- **`HorecagelegenheidCurrent`** (horecagelegenheidpagina, bereikt via
-  `HorecagelegenhedenOverzicht` → kaart tikken): zowel bij "De Beun"
-  (Heiloo) als "Hotel Den Helder" bleef de infosectie **permanent**
-  (8+ seconden gewacht, geen verandering) op de letterlijke
-  design-time placeholders staan: kop toont **"title"**, body toont
-  **"content"**, logo toont een **kapot-plaatje-icoon** (rode
-  driehoek). Dit zijn dezelfde velden als P1-6's al gedocumenteerde
-  `horecagelegenheid_current_widget.dart:377/500/747`
-  (titel/logo/content) — **maar dit weerlegt P1-6's aanname dat het om
-  incidentele ontbrekende data gaat**: het gebeurde bij *beide* geteste
-  gelegenheden, terwijl een ándere sectie op diezelfde pagina (de
-  "events op deze locatie"-carousel onderaan) voor "Hotel Den Helder"
-  wél gewoon echte, gelegenheid-specifieke data toonde. Een betere
-  Default-Value-tekst (P1-6's voorgestelde fix) verhelpt dus niets
-  hier — de onderliggende data komt al niet aan.
-- **`EvenementHorecagelegenheid`** (embedded op `EventCurrent`, bv. bij
-  evenement "Mythic Fest II", nid `214370`, alleen zichtbaar als het
-  evenement een `horecaid` heeft): toont **"HorecaNaam"** (letterlijke
-  fallback-tekst, niet ingevuld) i.p.v. een echte gelegenheidsnaam, plus
-  een forse layout-overflow. In de `flutter run`-log verschijnen hierbij
-  herhaaldelijk (in bursts van 3, telkens gelijktijdig met deze sectie):
-  ```
-  Another exception was thrown: RangeError (length): Invalid value: Valid value range is empty: 0
-  Another exception was thrown: A RenderFlex overflowed by 109 pixels on the bottom.
-  Another exception was thrown: Invalid argument(s): No host specified in URI Logo
-  ```
-  Geen volledige stack trace gevangen deze sessie (het "1x volledige
-  dump per proceslevensduur"-limiet, zie `CLAUDE.md`, werd al verbruikt
-  door Home's eigen overflow vóór deze pagina bereikt werd; een gerichte
-  herhaling met `--route "/eventCurrent?nid=214370&horecaid=<echte
-  id>"` ná een schone process-start zou de exacte regel moeten opleveren
-  — nid `214370` zonder `horecaid` reproduceert de crash niet, dus de
-  volgende poging heeft een evenement met een **wél ingevulde**
-  `horecaid` nodig, bv. via de widget-tree of een gerichte API-check
-  welk evenement een horecaid heeft).
-- **Twee eerder overwogen app-side kandidaat-oorzaken zijn met de
-  curl-test hierboven uitgesloten** (voor de volledigheid, om te
-  voorkomen dat een volgende sessie ze opnieuw onderzoekt): het is
-  niet een JSONPath/response-vorm-mismatch in `EstablishmentInfoCall`,
-  en niet de `getJsonField(item, r'''$.nid''').toString()`-constructie in
-  de overzicht-kaart-navigatie (`horecagelegenheden_overzicht_page_data_type_widget.dart:397-403`
-  e.v.) die een `null`-veld als de string `"null"` zou doorgeven — de
-  geteste nid's (`91142`/`91140`/`58844`) waren stuk voor stuk gewoon
-  geldig (bevestigd via de werkende establishments-lijst), en de
-  endpoint faalde alsnog voor alle drie. **P0** omdat dit een
-  kernpagina raakt (horecagelegenheidpagina) die voor *iedere* bezochte
-  gelegenheid vrijwel leeg oogt voor een eindgebruiker.
-- **Vers herbevestigd 2026-08-13 (Claude, directe curl buiten de app
-  om, dezelfde 3 nid's):** alle drie nog steeds HTTP 500 — geen
-  Drupal-side fix sindsdien, taak blijft volledig valide.
+*(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 · Eigenaar: Claude (mechanisch herhaald patroon — builder,
+`HorecagelegenheidCurrent`).** Nu P0-7 is opgelost en de horeca-detailpagina
+echte Drupal-data toont, blijken de Info/Links/Bezorgen-tabs zelf **kapot**
+te zijn — bevestigd live 2026-08-13 (Claude, emulator-5554, nid `91142`
+"De Beun", zie screenshots in scratchpad-sessie):
+- **RenderFlex-overflow op alle 3 tabs**, o.a. **"BOTTOM OVERFLOWED BY 209
+  PIXELS"** op de Info-tab — de linkerkolom (logo + adres/plaats/
+  telefoon/email/kvk/cryptocoins) wordt grotendeels **onzichtbaar achter
+  de gele/zwarte dev-overflow-band** geschoven, incl. het echte logo.
+  Root cause (`lib/horecagelegenhedenoverzicht/horecagelegenheid_current/horecagelegenheid_current_widget.dart:511-793`):
+  de Info-tab is een kale `Row` met twee `Column`s (`mainAxisSize.max`,
+  geen `Expanded`/`SingleChildScrollView`) direct in de `TabBarView`'s
+  `Expanded` (regel 507) — zelfde "kale Column/Row zonder scroll-wrapper
+  in een bounded-height ouder"-familie als het al bekende, nog open
+  P1-13 (`MasonryGridView` op `HorecagelegenhedenOverzicht`). Fix:
+  **Wrap Widget → SingleChildScrollView** om de Row (of om de hele
+  `TabBarView`'s children), zelfde patroon dat al elders in het project
+  werkt. **Let op:** probeer niet de Expanded/Shrink-Wrap/Scrollable-
+  toggle-route die bij P1-13 al 2x bevestigd niet doorzet naar de export
+  — ga hier direct voor de SingleChildScrollView-wrap.
+- **Letterlijke `"null"`-tekst op het scherm bij een leeg veld** — erger
+  dan het al bekende P1-6-patroon (dat toont tenminste een neutrale
+  placeholdertekst). Hier ontbreekt zelfs een `valueOrDefault`-fallback:
+  de code doet direct `getJsonField(..., r'''$[:].<veld>''').toString()`,
+  en `.toString()` op een `null`-resultaat geeft de string `"null"` —
+  live bevestigd op de Links-tab (`http://debeun.nl` gevolgd door een
+  losse regel **"null"**, daarna de Facebook-URL, dan weer **"null"**)
+  en op de Bezorgen-tab (**vier keer op rij "null"**, want De Beun heeft
+  geen bezorgopties ingevuld). **17 velden** in dit bestand hebben dit
+  exacte patroon, geen enkel met guard:
+  - Info-tab (regel ~538-687): `adres`, `plaats`, `telefoonnummer`,
+    `email`, `kvk`.
+  - Links-tab (regel ~798-947): `website`, `menukaart`, `facebook`,
+    `twitter`, `instagram`.
+  - Bezorgen-tab (regel ~953-1161): `afhaalopties`, `bestellink`,
+    `bezorgtijden`, `bezorgkosten`, `minimaleorder`,
+    `thuisbezorgtbetaalopties`, `bezorgdin`.
+  - **Fix (builder, per veld, mechanisch herhaalbaar):** zet op elk van
+    deze 17 `Text`-widgets een Visibility-conditie op het **rauwe**
+    API-veld (dezelfde JSON Path als de Text's eigen binding), operator
+    **"Is Set and Not Empty"** — zelfde recept als het
+    `CachedNetworkImage`/P1-15-patroon in `CLAUDE.md`. Zo verdwijnt de
+    hele regel i.p.v. "null" te tonen wanneer een gelegenheid dat veld
+    niet heeft ingevuld (waarschijnlijk de meeste, gezien de huidige
+    schaarse Drupal-content).
+  - **Kanttekening:** geen van deze 17 `Text`-widgets heeft een
+    `launchURL`/`InkWell` eromheen in dit bestand (bevestigd, apart van
+    de al bekende P1-15-knoppen elders) — het zijn platte tekstregels,
+    dus geen crash-risico zoals P1-15, puur een zichtbaarheids-/
+    presentatieprobleem. Wel een gemiste kans dat `website`/`facebook`/
+    `bestellink` niet tikbaar zijn — zie het aparte verbeterpunt
+    hieronder.
+  - **Overlap met P1-5:** de 7 Bezorgen-velden bevestigen exact P1-5's
+    aanname (nog geen enkele gelegenheid heeft bruikbare bezorgdata) —
+    dit maakt P1-5's "koppel aan een echt leverbaar-veld" nog relevanter
+    zodra Drupal-kant die data ooit vult.
+- **Los verbeterpunt (geen bug, wel P1-waardig):** `website`, `facebook`,
+  `menukaart` en `bestellink` op deze pagina zijn nu platte tekst i.p.v.
+  tikbare links (in tegenstelling tot het vergelijkbare
+  `evenement_horecagelegenheid_widget.dart`, waar deze velden wél
+  `launchURL`-knoppen zijn, zie P1-15). Zodra de "null"-fix hierboven
+  staat, is dit een logische vervolgstap: dezelfde velden `InkWell` +
+  `launchURL` geven, met dezelfde "Is Set"-guard (voorkomt meteen ook
+  een nieuwe P1-15-achtige crash-bij-lege-URL).
 
 ## Drupal dingen — verzamellijst, batchen bij Bob's eigen Drupal-sessie
 
@@ -595,7 +601,12 @@ verwarren — twee losse foutmeldingen in dezelfde log).
       gebruikt op `EventCurrent`** (`event_current_widget.dart`) — dus
       een normaal bereikbare, veelbezochte pagina (niet een edge case).
       Een event zonder website-URL laat de gebruiker de app laten
-      crashen door simpelweg op "Website" te tikken.
+      crashen door simpelweg op "Website" te tikken. **Nog niet
+      aangepakt** (2026-08-13: sessie werd omgeleid naar P0-8 zodra
+      Bob's Drupal-fix voor P0-7 binnenkwam, niet meer aan toegekomen) —
+      wel een geïsoleerd, ondiep component, dus vermoedelijk minder
+      gevoelig voor het widget-tree-klikprobleem dat P1-9/P1-15's andere
+      punten deze sessie blokkeerde.
     - `evenement_component_widget.dart:414` —
       `onTap: () async { await launchURL(EvenementCall.eventWebsiteg(columnEvenementResponse.jsonBody)!); }`
       binnen `EvenementComponentWidget`. Dit component wordt alleen
@@ -1131,7 +1142,9 @@ ronde gemist (niet te verwarren met het dode `EstablishmentsNewCall`,
 zelfde-klinkende naam), in een 2e verse export alsnog bevestigd
 correct. Uit deze lijst verwijderd.)*
 
-**P1-9 · Eigenaar: Onbepaald.** Visuele polish (los, per pagina) —
+**P1-9 · Eigenaar: Bob (builder-klikken op Claude's viewport vandaag
+onbetrouwbaar, zie hieronder — beide restpunten zijn triviaal in Bob's
+eigen browser).** Visuele polish (los, per pagina) —
 resterend na sessie 2026-08-06:
 1. **Event-pagina (typografie/contrast/spacing) — live gecheckt
    2026-08-13 (Claude, emulator-5554, `EventCurrent` via
@@ -1173,6 +1186,26 @@ resterend na sessie 2026-08-06:
      deel-knop hierboven, deze losse tekstweergave lijkt puur
      debug-restant), of anders achter een Visibility zetten die 'm
      standaard verbergt.
+   - **Poging door Claude (2026-08-13 avond), beide punten geblokkeerd
+     op Widget Tree-klikprecisie — geen wijziging aangebracht.** Zelfde
+     probleem als het al bekende P1-15-precedent (2026-08-09): een klik
+     op een zichtbare tree-rij selecteerde herhaaldelijk een andere rij,
+     en de offset bleek **niet constant** binnen dezelfde sessie (soms
+     ~46px, soms ~61px) — zelfs ná de al bekende kalibratietruc uit
+     `CLAUDE.md` bleef dit onvoorspelbaar. Widget-selectie zelf lukte
+     na 5-8 pogingen per node (TextTitle, de losse `Text`-node voor
+     `nid`), maar de vervolgacties liepen alsnog vast: de Padding-
+     sectie's "Independent Padding"-toggle deselecteerde telkens de
+     widget i.p.v. te schakelen (5x gereproduceerd), en het rechtsklik-
+     contextmenu's "Remove Widget"-item registreerde de klik niet (3x
+     geprobeerd, inclusief met vooraf ingezoomde exacte coördinaten).
+     **Exacte stappen voor Bob (seconden werk in zijn eigen browser):**
+     (1) spacing: selecteer `TextTitle` (Widget Tree → `EventCurrent` →
+     `Column` → `Row` (titel+deel-knop) → `TextTitle`) → Padding →
+     Independent Padding aan → Right = 8 (of wrap de node in `Flexible`).
+     (2) nid-tekst: selecteer de losse `Text`-node net onder de
+     titel-Row (toont "nid" in de design-time preview) → rechtsklik →
+     Remove Widget.
 - *(Restpunt `PUitgaanSliderKaartComponent`-schaduw Offset Y afgerond
   2026-08-10 avond — Bob, builder, bevestigd via verse export: beide
   `BoxShadow`s staan nu op `Offset(0.0, 2.0)`, blur 4.0.)*