Kaynağa Gözat

Live pair-fix sessie 2026-08-10 avond: 9 taken afgerond en bevestigd via verse export (P1-18, P0-1, P0-3, P1-3, P1-9-restpunt, P1-1, P1-12), P1-15-poging bleek niet doorgezet. Nieuwe werkwijze vastgelegd in CLAUDE.md (export-verificatie na elke edit, standaardvraag om sessie mee te starten)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
bob 1 ay önce
ebeveyn
işleme
d6e6dfc937
2 değiştirilmiş dosya ile 184 ekleme ve 199 silme
  1. 70 0
      CLAUDE.md
  2. 114 199
      TASKS.md

+ 70 - 0
CLAUDE.md

@@ -73,6 +73,76 @@ zoeken of scannen — scope alle bestandsoperaties tot dit project.
   commit niet over andermans nog-niet-afgeronde wijziging heen zonder
   navraag.
 
+## Live pair-fix sessie — Bob doet de builder-klikken, Claude regisseert
+
+Bevestigd goed werkende aanpak (2026-08-10 avond) voor het gezamenlijk
+afwerken van `TASKS.md`: Bob voert alle builder-wijzigingen zelf uit in
+zijn eigen browser (geen clipping-/coördinaatproblemen daar), Claude
+geeft per taak de exacte stappen en **verifieert elke taak na afloop
+met een verse, losse export** in plaats van op de builder-UI ("Synced",
+geen foutmelding) te vertrouwen. In één avond leverde dit 9 afgeronde
+taken op tegen een prettig tempo, en ving het **minstens 2x** een edit
+die in de UI geslaagd leek maar bij export niet was doorgezet (zelfde
+stille-niet-opgeslagen-patroon als elders in dit bestand, nu ook
+bevestigd op een gewone Visibility-conditie, niet alleen bij de
+bekende clipping-gevallen).
+
+**Vaste aanpak per taak:**
+1. Claude geeft exacte builder-stappen voor **precies één taak** uit
+   `TASKS.md`, met taak-ID erbij (bv. "P1-3").
+2. Bob voert uit in eigen browser, meldt "gedaan".
+3. Claude verifieert met een losse, snelle export (geen emulator/build
+   nodig):
+   ```
+   export PATH="/home/bob/fvm/bin:$HOME/.pub-cache/bin:$PATH"
+   flutterflow export-code --project uitgaanskrant-1qhvtd \
+     --dest /tmp/ff-check --token "$(cat ~/.ff_token)" \
+     --no-parent-folder --as-debug
+   ```
+   gevolgd door een gerichte `grep`/`Read` op de betreffende regel(s).
+   Dit duurt seconden en is niet-destructief (los van de projectmap,
+   geen commit, geen emulator).
+4. Klopt het: taak-ID hardop bevestigen, meteen de eerstvolgende taak
+   geven (liefst al vooruit gecheckt terwijl Bob met de huidige bezig
+   is — zie punt hieronder). Klopt het niet: exact melden wat er nog
+   in de export staat, niet aannemen dat "Confirm geklikt" gelijk
+   staat aan "opgeslagen".
+5. **Vooruit checken terwijl Bob bezig is**: zodra Bob aan een taak
+   begint, kan Claude alvast de eerstvolgende taak in de wachtrij
+   pre-verifiëren (is hij nog steeds nodig, of intussen al door iemand
+   anders/een eerdere sessie opgelost?) — scheelt een aparte
+   heen-en-weer ronde.
+6. Bob geeft na afronding van een cluster ook een eigen commit in
+   FlutterFlow's interne versiebeheer ("main"/"Synced" bovenin) — los
+   vangnet naast Claude's export-verificatie.
+
+**Altijd het taak-ID noemen** bij elke gegeven stap en elke
+bevestiging (Bob's expliciete voorkeur) — voorkomt verwarring over
+welk punt van de lijst besproken wordt.
+
+**Standaardvraag om een nieuwe sessie mee te starten** (plak dit als
+eerste bericht in een nieuwe chat om meteen door te pakken):
+
+> Leg mijn actielijst (`TASKS.md`) voor me voor, één taak tegelijk —
+> ik voer de builder-stappen zelf uit, jij verifieert daarna met een
+> verse export voor je de volgende geeft. Noem altijd het taak-ID.
+> Begin met [P0 eerst / een specifiek gebied, bv. "Login-pagina" /
+> "verder waar we gebleven waren"].
+
+**Hoeveel taken per sessie — advies:** geen harde limiet, maar een
+sessie werkt het prettigst als hij **één samenhangend cluster** afmaakt
+(zelfde FlutterFlow-pagina/component-groep, sluit aan bij de bestaande
+"groepeer per paginagebied"-vuistregel hierboven) in plaats van
+kriskras door de hele lijst te gaan — dat scheelt heen-en-weer-
+navigeren én houdt de context overzichtelijk. Als praktisch richtgetal:
+**5-10 kleine, mechanische taken** (zoals vanavond) is een goede,
+vermoeidheid-arme klip; grotere/lastigere taken (P1-6's ~45 treffers,
+P1-15's conditie-gepuzzel) tellen zwaarder en verdienen een eigen
+sessie of een kleiner deelblok. Sluit elke sessie af met de
+afsluitroutine hieronder (`TASKS.md` bijwerken + committen) — dan kan
+een sessie ook prima na 2 taken stoppen zonder dat er iets verloren
+gaat.
+
 ## Sessiegeheugen — afsluitroutine
 
 Aan het eind van elke sessie/taak:

+ 114 - 199
TASKS.md

@@ -1,11 +1,32 @@
 # Uitgaanskrant — takenlijst
 
-Bijgewerkt: 2026-08-10 (Claude, builder-sessie). 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-10):** twee taken opgepakt. **P2-9-bijvangst
+Bijgewerkt: 2026-08-10, avond (Claude, live pair-sessie met Bob in de
+builder). 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-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
@@ -131,59 +152,21 @@ door Bob zelf gedaan in de builder, geverifieerd via verse
 'Email address'` resp. `nl: 'Wachtwoord'`/`en: 'Password'`. Uit deze
 lijst verwijderd.)*
 
-**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. **Bob dacht dit gedaan te hebben (2026-08-09
-   avond), maar geverifieerd via verse export: nog steeds niet
-   toegepast** — de Text staat nog kaal (geen Flexible/Expanded) in
-   `header_buttons_component_widget.dart` regel 199-216. Vermoedelijk
-   hetzelfde "edit hield niet vast"-patroon als elders gedocumenteerd
-   in `CLAUDE.md` (rechterpaneel-clipping) — check na een nieuwe
-   poging opnieuw via een verse export, niet alleen op het
-   rechterpaneel zelf vertrouwen.
-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`).
-- 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-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 · Eigenaar: Bob.** Werkende login + favorieten — resterende
 deeltjes. Basis is af: login gekoppeld, wachtwoord-vergeten-flow,
@@ -210,101 +193,33 @@ 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.
-**Update 2026-08-09 avond: Bob heeft de conditie zelf aangepast — de
-crash is inderdaad weg, maar de nieuwe conditie heeft een andere bug
-en er kwam een tweede probleem aan het licht, allebei bevestigd via
-verse `flutterflow export-code` (`login_widget.dart:534-538`):**
-1. **De conditie is nu `getJsonField(_model.resultDrupalLogin,
-   r'''$.success''') != null` — dat staat feitelijk altijd op waar.**
-   `drupalLogin` retourneert namelijk ALTIJD een `success`-veld, zowel
-   bij een geslaagde login (`success: true`) als bij een mislukte
-   (`success: false`, zie `drupal_login.dart`) — het veld is dus nooit
-   afwezig/`null`, alleen de *waarde* verschilt. Een "Is Set"-achtige
-   `!= null`-check ziet dat verschil niet. **Gevolg: een fout
-   wachtwoord of netwerkfout wordt nu stil behandeld alsof het inloggen
-   gelukt is** — de `else`-tak met "Inloggen mislukt..." is
-   onbereikbare code geworden, en `FFAppState().userSessionid` etc.
-   worden gevuld met lege/`"null"`-strings uit de mislukte respons.
-   **Fix:** conditie moet de daadwerkelijke boolean-waarde vergelijken
-   (`== true`), niet alleen of het veld aanwezig is — in de builder dus
-   niet "Is Set" maar een echte gelijkheids-check tegen `true`.
-2. **Nieuw zichtbaar geworden (was eerder gemaskeerd door de crash):**
-   ná de if/else staat een onvoorwaardelijke `showDialog(...)` (regel
-   577-593) die bij **elke** inlogpoging een AlertDialog met titel
-   "melding" toont met de rauwe JSON-respons als platte tekst erin —
-   oogt als achtergebleven debug/testcode, vergelijkbaar met de al
-   verwijderde testknoppen van P0-6. Nu de crash weg is, ziet elke
-   gebruiker dit bij elke inlogpoging. Aanbevolen: dit dialoogblok
-   (regel 577-593) verwijderen.
-
-**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.
-- **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-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.)*
+
+*(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 (<lijst>.isEmpty) { return Image.asset('assets/images/logo800px.png'); }`
+vóór hun Carousel gebouwd wordt. Uit deze lijst verwijderd.)*
+
+*(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 · Eigenaar: Bob.** EstablishmentsCall crasht zonder
 categoriefilter. `horcat ??= null!;` — bevestigd nog aanwezig, regel
@@ -421,17 +336,28 @@ verwarren — twee losse foutmeldingen in dezelfde log).
   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.
+  letterlijke naam).
+- **Poging door Bob (2026-08-10 avond), alle 5 knoppen ingesteld —
+  bleek bij verse export toch niet toegepast.** Bob zette op alle 5
+  knoppen de conditie om (naar eigen zeggen), maar een export vlak
+  erna toonde voor in ieder geval de Facebook-knop nog exact het oude
+  patroon (`valueOrDefault<String>(EstablishmentInfoCall.establishmentFacebook(...), 'facebook') != null && ... != ''`,
+  regel 812 van `evenement_horecagelegenheid_widget.dart`) — dus de
+  edit hield niet vast, zelfde "ziet er goed uit in de builder maar
+  komt niet door" patroon als eerder bij P0-3 punt 1. **Nuttige
+  precisering deze sessie:** de Facebook-waarde komt hier niet via een
+  Component Parameter binnen, maar rechtstreeks uit een API-call die
+  dit component zelf al draait (`EstablishmentInfoCall.establishmentFacebook(columnEstablishmentInfoResponse.jsonBody)`)
+  — dus geen Component-Parameter-Default-Value-omweg nodig. Bind First
+  Value in de Visibility-conditie direct aan die API-call-respons (in
+  de builder waarschijnlijk zichtbaar als een bronnaam als
+  "columnEstablishmentInfoResponse"/"Establishment Info Response" →
+  veld "Facebook"), operator **"Is Set and Not Empty"**, zonder de
+  `valueOrDefault`-wrap. Bob gaat hier zelfstandig mee verder. **Tip
+  voor de volgende poging:** ná het instellen even wegnavigeren en de
+  conditie opnieuw openen om te bevestigen dat hij écht bewaard is,
+  vóórdat je naar de volgende knop gaat — dat had dit keer de vroege
+  ontdekking gescheeld.
 
 **P1-16 · Eigenaar: Bob (Firebase-koppeling is account-/builder-niveau,
 geen Claude-taak).** Geen crash-reporting/analytics (bv. Firebase
@@ -536,26 +462,19 @@ browser):
 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-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-13 · Eigenaar: Onbepaald — builder-fix toegepast maar NIET
 bevestigd in de export, zie blocker hieronder vóór verder bouwen.**
@@ -812,19 +731,9 @@ 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 `Container`s 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).
+- *(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.)*
 - **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;
@@ -909,7 +818,9 @@ afgerond 2026-08-05, Claude, code-niveau):
   naar de P2-7-opschoonlijst.
 
 **P1-11 · Eigenaar: Bob — geblokkeerd op rechterpaneel-clipping
-(zelfde patroon als P1-3).** Responsive/screensize. **2026-08-05:
+(zelfde patroon als P1-3).** Responsive/screensize. **Vers gecheckt
+2026-08-10 avond (Claude, export): nog steeds ongewijzigd, taak blijft
+volledig valide.** **2026-08-05:
 venue-event-grid-bug uitgezocht (Claude, code-niveau) — root cause
 gevonden, mechanische builder-fix, nog niet uitgevoerd:**
 - Component: `HorecagelegenheidEventTabelComponentCopy`
@@ -1044,6 +955,10 @@ code).
 - `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).
+- Laag risico, uit P0-3 gehaald (2026-08-10): de component-load
+  default-toewijzing (eerste app-start, provincie/gemeente-id
+  `28666`/`28694`) krijgt nog geen bijbehorende naam mee — valt terug
+  op lege naam tot iemand handmatig een provincie/gemeente kiest.
 
 **P2-8 · Opgegaan in P1-7 (2026-08-09).** Hartje-tap op gemeente-/
 provincienaam om te favorieten is nu onderdeel van de bredere