TASKS.md: P0-7 root cause definitief bevestigd - Drupal-endpoint flutterflowmobiel_establishment_info.json (services_1) geeft HTTP 500 voor elke geteste nid, dus geen app-bug maar Drupal-side (eigenaar Bob). Kandidaat-oorzaken (JSONPath-mismatch, null.toString()) uitgesloten via directe curl-test met 3 echte nid's. P0-5-bijvangst gecorrigeerd o.b.v. Bob's toelichting: hardcoded Basic-Auth is voor devbob.uitgaanskrant.com, doet niets op productie.

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

TASKS.md

@@ -218,17 +218,54 @@ voor browse-endpoints. Drupal-niveau, geen Claude-taak. **Bijvangst
 **hardcoded Basic-Auth-header mee** (`Authorization: Basic
 Ym9iOnNlcmhpaQ==`, decodeert naar `bob:serhii`) — dit staat letterlijk
 in de gecompileerde APK en is dus met een gratis decompiler
-(bv. `jadx`) door iedereen uit te lezen. Neem dit mee in de
-P0-5-afweging: als het achterliggende Drupal-account meer kan dan
-alleen lezen (bv. schrijven t.b.v. de favorieten-sync uit P1-7), is dit
-een device-brede, niet-intrekbare credential zolang de app in de wild
-is. Oplossing hangt af van wat P0-5 uitwijst (anonieme leestoegang zou
-dit hele Basic-Auth-blok overbodig maken).
+(bv. `jadx`) door iedereen uit te lezen. **Verduidelijkt door Bob
+(2026-08-12): dit account is alleen nodig voor de
+`devbob.uitgaanskrant.com`-omgeving (dev/staging zit achter een
+username/wachtwoord-poort) — tegen de productie-URL
+(`uitgaanskrant.com`, wat de app daadwerkelijk aanroept) doet de header
+niets schadelijks, geeft geen foutmelding, is dus effectief dood
+gewicht daar.** Praktisch gevolg: minder urgent dan eerder
+ingeschat (geen live-productie-credential-lek), maar nog steeds het
+opruimen waard — een onnodige hardcoded header die alsnog een
+dev-omgevingswachtwoord blootlegt zodra iemand de APK decompileert, en
+die zonder functie is zodra de app alleen tegen productie draait.
 
-**P0-7 · Eigenaar: Onbepaald (onderzoek nodig vóór builder-fix).**
-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):
+**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**
@@ -264,37 +301,18 @@ gelegenheden (niet 1 incident):
   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).
-- **Nog niet hard bevestigd, wel plausibele kandidaat-oorzaken (verder
-  onderzoek nodig vóór een builder-fix zin heeft):**
-  1. `EstablishmentInfoCall`'s JSONPath-expressies
-     (`r'''$[:].nid'''`/`titel`/`content`/etc.,
-     `lib/backend/api_requests/api_calls.dart:925` e.v.) versus de
-     werkelijke vorm van de Drupal-JSON-respons — als de respons niet
-     een array-met-1-object is zoals verwacht, levert `getJsonField`
-     stilzwijgend `null` (geen crash, geen foutmelding) en valt alles
-     terug op de design-time placeholder.
-  2. De `nid` die de overzicht-kaart doorgeeft bij navigatie
-     (`horecagelegenheden_overzicht_page_data_type_widget.dart:397-403`
-     en de 5 vergelijkbare blokken verderop in hetzelfde bestand, regel
-     606/790/974/1158/1342) gebruikt
-     `getJsonField(item, r'''$.nid''').toString()` — als het onderliggende
-     veld `null` is, geeft Dart's `null.toString()` de **letterlijke
-     string `"null"`** terug (geen exceptie), die dan als een
-     "geldige" nid wordt doorgegeven aan `EstablishmentInfoCall`. Let
-     op: dit verklaart *niet zonder meer* waarom de events-carousel op
-     dezelfde pagina wél de juiste gelegenheid vond (die lijkt een
-     eigen/werkende nid-scoping te hebben) — dus mogelijk is dit niet
-     de (enige) oorzaak; vandaar "kandidaat", niet "bevestigd".
-  - **Aanbevolen volgende stap:** één gelegenheid opzoeken waarvan de
-    echte `nid` bekend is (bv. via Widget Inspector/`View Code` of een
-    directe Drupal-check) en `EstablishmentInfoCall`'s endpoint
-    (`https://uitgaanskrant.com/en/flutterdrup/views/flutterflowmobiel_establishment_info.json?display_id=services_1&nid=<echte-nid>`)
-    los curlen (met de Basic-Auth-header uit P0-5's bijvangst) om te
-    zien of de JSON-vorm klopt met wat `EstablishmentInfoCall`
-    verwacht — dat scheidt kandidaat 1 en 2 definitief. **P0** omdat
-    dit een kernpagina raakt (horecagelegenheidpagina) die voor
-    *iedere* bezochte gelegenheid vrijwel leeg oogt voor een
-    eindgebruiker.
+- **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.
 
 ## P1 — snel na livegang