TASKS.md: afsluitroutine vorige sessie alsnog gecommit (Minor-1, hartje-icoon, P1-23, P1-21 afgerond op 2026-08-16)

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

TASKS.md

@@ -503,18 +503,11 @@ daarmee ook verdwijnen**, dat bevestigt of de link klopte.
 Bob's expliciete categorie (2026-08-14): kleine restpunten uit P0-8 die
 de livegang niet blokkeren, later oppakken.
 
-**Minor-1 · Eigenaar: Bob.** `HorecagelegenheidCurrent`
-(`horecagelegenheid_current_widget.dart`), Bezorgen-tab: de
-Visibility-conditie op de "bezorgtijden"-tekst controleert het
-verkeerde veld. Bevestigd 2026-08-14 via export:
-`if (EstablishmentInfoCall.establishmentOpeningstijden(...) != null && ... != '') Text(..., r'''$[:].bezorgtijden''', ...)`
-— de zichtbaarheid hangt dus af van het **Openingstijden**-veld i.p.v.
-bezorgtijden zelf (waarschijnlijk per ongeluk het verkeerde item
-gekozen uit de velden-lijst, namen lijken op elkaar). Fix: First Value
-van de Single Condition omzetten naar JSON Path `$[:].bezorgtijden`
-(dezelfde bron als de Text's eigen binding), operator blijft "Is Set
-and Not Empty". Geen crash, puur verkeerde zichtbaarheidslogica — Bob
-(2026-08-14): "moet ik later fixen, voor nu blijft er wat staan".
+*(Minor-1 afgerond 2026-08-16 — Bob, builder, live pair-fix sessie:
+de "bezorgtijden"-Visibility-conditie op `HorecagelegenheidCurrent`
+(Bezorgen-tab) bindt nu aan JSON Path `$[:].bezorgtijden` i.p.v. het
+verkeerde `Openingstijden`-veld. Bevestigd via verse export. Uit deze
+lijst verwijderd.)*
 
 **Minor-2 · Eigenaar: Bob.** `HorecagelegenheidCurrent`
 (`horecagelegenheid_current_widget.dart`), Bezorgen-tab: "afhaalopties"
@@ -532,13 +525,13 @@ oorspronkelijke P0-8) toegepast kan worden.
 toch al wachten op ander Drupal-werk hier verzamelen i.p.v. los oppakken
 — dan in één builder-bezoek samen met de Drupal-kant afhandelen.
 
-- **Hartje-icoon op de horecagelegenheid-detailpagina** (hoort bij
-  P1-7 stap 3, component `HorecagelegenheidCurrent`): de If-tak
-  (favoriet) van de `ConditionalBuilder` rond `IconButtonFavoriet`
-  toont nog `Icons.favorite_border` i.p.v. het gevulde `Icons.favorite`,
-  en Fill Color staat op `Color(0x0AFFFFFF)` i.p.v. wit (zoals de
-  Else-tak). Functioneel al correct (Remove/Add-acties kloppen, bevestigd
-  via export 2026-08-13) — puur cosmetisch restpunt.
+- ~~Hartje-icoon op de horecagelegenheid-detailpagina~~ — **afgerond
+  (2026-08-16, Bob, builder, live pair-fix sessie).** If-tak van de
+  `ConditionalBuilder` rond `IconButtonFavoriet` toont nu
+  `Icons.favorite` (gevuld) met witte Fill Color, zelfde stijl als de
+  Else-tak. Bevestigd via verse export. Geen Drupal-afhankelijkheid
+  nodig gebleken — puur cosmetisch, meegepakt tijdens een toch al
+  geplande sessie op deze pagina.
 - ~~P1-7 Tab 3 "Favoriete Gelegenheden"~~ — **afgerond (2026-08-14,
   Claude, builder), zie P1-7 hieronder.** Was hier vermeld als
   Drupal-geblokkeerd; bleek stale en is dezelfde sessie alsnog
@@ -546,16 +539,18 @@ toch al wachten op ander Drupal-werk hier verzamelen i.p.v. los oppakken
 
 ## P1 — snel na livegang
 
-**P1-23 · Eigenaar: Bob.** `HorecagelegenheidCurrent`
-(`horecagelegenheid_current_widget.dart`): `website`, `facebook`,
-`menukaart` en `bestellink` zijn 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). Nu de
-"null"-tekst-fix van het voormalige P0-8 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). Geen van deze 4 `Text`-widgets
-heeft momenteel een `launchURL`/`InkWell` eromheen in dit bestand.
+*(P1-23 afgerond 2026-08-16 — Bob, builder, live pair-fix sessie:
+`website`, `menukaart`, `facebook` en `bestellink` op
+`HorecagelegenheidCurrent` hebben nu allemaal een tap-actie
+(`launchURL(getJsonField(..., r'''$[:].<veld>'''))`, direct via de
+Text-widget's eigen Actions-tab — geen `InkWell`-wrap nodig gebleken).
+**Bijvangst:** twitter/instagram (niet in de oorspronkelijke scope,
+zelfde patroon) zijn tegelijk meegepakt. Bevestigd via verse export
+(5 `launchURL`-aanroepen). Alle 4+2 velden hadden al de "Is Set and
+Not Empty"-guard uit P0-8, dus geen los crash-risico meer zoals bij
+het oorspronkelijke P1-15. **Nog geen visuele link-styling** (kleur/
+underline) — puur cosmetisch restpunt, functioneel al klaar. Uit deze
+lijst verwijderd.)*
 
 *(P1-18 afgerond 2026-08-10 avond — Bob, builder + Custom Code, in
 twee stappen. Root cause was een dubbele bug: (1) `login_widget.dart`
@@ -1191,76 +1186,25 @@ gebruikt dezelfde component (default `true`, dus nog steeds een
 zichtbare Terug-knop) — mogelijk net zo zinloos op een entry-pagina
 als op Home was, niet onderzocht/aangepast.)*
 
-**P1-21 · Eigenaar: Onbepaald.** AdBanner op `PUitgaanPage`
-(`lib/uitgaanspaginas/p_uitgaan_page/p_uitgaan_page_widget.dart:200-207`)
-toont **letterlijke developer-instructietekst** aan echte gebruikers
-i.p.v. een advertentie of een net leeg vak. Dit is FlutterFlow's eigen
-`FlutterFlowAdBanner`-widget
-(`lib/flutter_flow/flutter_flow_ad_banner.dart`): zolang er geen
-geladen advertentie is, rendert hij een zwart vlak met de tekst "Ad
-Loading... If this takes a long time, you may have to check whether
-the ad is being covered from a parent widget. ... AdBanner will
-automatically match the size of the banner to the device screen." —
-bedoeld als build-time debughulp, niet als eindgebruikers-UI.
-**Bevestigd live (2026-08-12):** dit bleef **8+ seconden onveranderd**
-zichtbaar (geen doorontwikkeling naar een echte advertentie), en de
-`flutter run`-log toonde de reden:
-```
-BannerAd failedToLoad: LoadAdError(code: 0, domain: com.google.android.gms.ads, message: Internal error., ...)
-```
-- **Punt 1 (`showsTestAd`) geschrapt als bug — bevestigd verwacht
-  gedrag (2026-08-13, Bob):** er is **geen** losse "test ad"-instelling
-  in de builder (bevestigd via het AdBanner-widget-eigenschappenpaneel —
-  alleen Visibility/Expansion/Padding/Alignment/Ad Properties/
-  Dimensions, geen test-toggle). De testadvertentie verschijnt omdat
-  Google AdMob de app nog niet heeft goedgekeurd — dat kan pas ná
-  livegang (Google keurt pas goed als de app in productie draait).
-  **Actie bij livegang (niet nu, geen losse builder-stap):** ná het
-  live zetten van de app bij Google/Apple de advertenties laten
-  reviewen/goedkeuren — pas daarna serveert AdMob automatisch echte
-  advertenties i.p.v. de testvariant.
-- **Punt 2 blijft een echte taak, los van goedkeuring:** de fallback-UI
-  zelf moet sowieso weg/anders — een gebruiker mag nooit deze
-  debugtekst zien, ook niet ná goedkeuring als een advertentie een keer
-  traag laadt of faalt (bv. geen advertentie-inventory voor deze
-  gebruiker/regio). Voorstel: `flutter_flow_ad_banner.dart`'s
-  fallback-`Container` vervangen door iets neutraals (leeg vlak met
-  dezelfde hoogte, of gewoon `SizedBox.shrink()`) i.p.v. de zwarte
-  debug-tekst-box.
-  - **Correctie (2026-08-13, Claude): de eerdere aanname "wél
-    rechtstreeks in de code aan te passen zonder builder-UI, net als
-    `lib/custom_code/`" is ongeverifieerd en vermoedelijk fout —
-    niet blind uitvoeren.** Dit bestand staat in `lib/flutter_flow/`,
-    niet in `lib/custom_code/` — dat is precies het generatedbestanden-
-    pad dat `CLAUDE.md` expliciet als **niet-duurzaam** bestempelt
-    ("directe Edit/Write-wijzigingen aan gegenereerde bestanden worden
-    bij de volgende export overschreven"). `git log` op dit bestand
-    toont alleen de allereerste commit (nooit een diff bij een van de
-    vele latere `flutterflow export-code`-syncs) — dat bewijst niet dat
-    een lokale edit zou overleven, alleen dat de FlutterFlow-standaard-
-    versie van dit bestand zelf nooit gewijzigd is. Zonder een bevestigd
-    precedent (een eerdere lokale `lib/flutter_flow/*`-edit die een
-    export overleefde) een gok nemen op een gebruikersgerichte
-    UI-tekst is niet de moeite waard. Het AdBanner-widget-paneel in de
-    builder heeft **geen fallback-tekst/-widget-property** (bevestigd
-    2026-08-13 bij het onderzoeken van punt 1 hierboven — alleen
-    Visibility/Expansion/Padding/Alignment/Ad Properties/Dimensions),
-    dus ook geen bestaande builder-route naar deze fix.
-  - **Enige betrouwbare pad die overblijft:** een eigen custom widget
-    in `lib/custom_code/widgets/` bouwen die AdMob rechtstreeks aanroept
-    (vergelijkbare `BannerAd`/`AdWidget`-logica als hierboven, maar met
-    een nette fallback) en die op `PUitgaanPage` de bestaande
-    `FlutterFlowAdBanner`-instantie vervangt via de builder (Insert
-    Widget → Custom Widget). Groter dan een 1-regelige tekstwijziging —
-    eigen sessie/blok waard, niet iets voor een snelle mechanische
-    doorloop. Nog niet opgepakt.
+*(P1-21 gesloten zonder bouwwerk — Bob's beslissing 2026-08-16: geen
+losse custom widget voor de AdBanner-fallback. `PUitgaanPage`'s
+`FlutterFlowAdBanner` toont nu nog de debug-tekst zolang Google AdMob
+de app niet heeft goedgekeurd (kan pas ná livegang), maar dat lost
+zichzelf op zodra de app is goedgekeurd en AdMob echte advertenties
+gaat serveren — Bob's inschatting is bovendien dat deze fallback-tekst
+juist nodig kan zijn zodat Google de advertentie-integratie kan zien
+tijdens de review. Claude's eerder uitgewerkte `CleanAdBanner`-custom-
+widget-voorstel (verving de debugtekst door een lege `SizedBox`) is
+dus **niet gebouwd** — bewust afgewezen, niet vergeten. Geen actie
+meer nodig tot ná de Google/Apple-goedkeuring bij livegang; check dan
+of de debugtekst inderdaad verdwenen is. Uit deze lijst verwijderd.)*
 - **Kanttekening bij P2-5** ("Ad-banners..., na livegang"): P2-5 gaat
   er nog van uit dat advertenties een niet-gebouwd P2-idee zijn — in
-  werkelijkheid staat er dus al minstens 1 banner live in de code
-  (alleen nog kapot/debug). Check met Bob of P2-5's "waar wel/geen
-  ads"-regel (geen ads op locatie-kiezer/login/account) al is
-  toegepast op deze ene bestaande banner, en of er bewust voor
-  `PUitgaanPage` gekozen is als eerste plek.
+  werkelijkheid staat er dus al minstens 1 banner live in de code. Check
+  met Bob of P2-5's "waar wel/geen ads"-regel (geen ads op
+  locatie-kiezer/login/account) al is toegepast op deze ene bestaande
+  banner, en of er bewust voor `PUitgaanPage` gekozen is als eerste
+  plek.
 
 *(P1-22 volledig afgerond 2026-08-13 — live pair-sessie, Bob builder +
 Claude verse-export-verificatie, gecombineerd met P1-10's cache-toggle