P2-6: zoekfunctie live geverifieerd op toestel

Profile-build op telefoon-emulator via deep-link naar Copy3 (Arnhem).
Zoeken werkt: Activiteiten 2 kaarten -> 'vue' geeft 1; Eetgelegenheden 20 ->
'pizza' geeft 5, nagerekend tegen de API. Werkt ook op een
ConditionalBuilder-tab, en de zoekterm blijft staan bij tabwissel.

Twee bijvangsten voor Bob genoteerd: de twee oude lege TextField-placeholders
in tab 0 en 1 zijn nu overbodig en vallen half over de TabBar, en Drupal
bevat echte duplicaten (nid 53455/50584 en 53454/50583).

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

TASKS.md

@@ -2142,8 +2142,50 @@ Omvang op de huidige agenda: 2 van 235 nodes.
 
 ## P2 — features & concept, na livegang
 
-**P2-1 · Eigenaar: Bob — bezig (sessie 2026-09-04a, Drupal/infra-blok; testen in de API).** Datum-filter:
-Vandaag / Dit weekend / Deze week.
+**P2-1 · Eigenaar: Bob (Drupal/views-werk; app-werk pas daarna).**
+Datum-filter Vandaag / Dit weekend / Deze week. **Uitgezocht 2026-09-05
+(Claude, live `curl`) — dit kan niet in de app alleen:**
+- **Er is geen exposed datumfilter.** Getest op
+  `flutterflow_events.json` met `date`, `datum`, `field_date_value`,
+  `date_filter`, `date_filter[value][date]` — alle 25 items bleven
+  identiek. Controle met een verzonnen `onzin_param=123` gaf hetzelfde
+  resultaat, dus de view negeert onbekende parameters stil: "geen
+  verschil" bewijst hier écht dat de filter ontbreekt.
+- **Client-side filteren is geen alternatief.** (1) `datum` is een
+  geformatteerde string **zonder jaartal** (`"woensdag 9 sep, 20:00"` op
+  `/nl/`, `"Wednesday 9 Sep, 20:00"` op `/en/`) — parsen is fragiel en
+  rond de jaarwisseling ambigu. (2) De lijst is gepagineerd op 25 items,
+  dus je kunt alleen filteren binnen de pagina die je toevallig binnen
+  hebt.
+- **Benodigd:** een exposed date-filter (of aparte displays voor
+  vandaag/weekend/week) op `flutterflowmobiel1`. Pak dit samen met P1-42
+  hieronder — dat is dezelfde view en dezelfde sorteer/filter-laag.
+
+**P1-42 · Eigenaar: Bob (Drupal/views).** **De uitgaanslijsten tonen
+overwegend verlopen evenementen.** Gevonden 2026-09-05 (Claude, live
+`curl` tijdens P2-1-onderzoek), geldt voor `flutterflowmobiel1`
+services_1/2/3 — de views waar Home zijn tabs mee vult.
+- Gemeten op 2026-09-05 over de eerste 6 pagina's (150 items):
+  **juli 66, augustus 48, september 36** — dus ±76% van wat de lijst
+  toont was op de meetdatum al geweest.
+- De lijst gaat vrijwel eindeloos terug: `page=40` levert nog steeds 25
+  items (eind mei), `page=80` idem (half mei). Met infinite scroll aan
+  scrollt een gebruiker dus de geschiedenis in.
+- **Oorzaak:** de view sorteert op `created DESC` (zichtbaar in Bob's
+  view-export van `flutterflowmobiel_establishment_info`, en het gedrag
+  van `flutterflowmobiel1` past daarbij) — dus op **wanneer iemand het
+  evenement invoerde**, niet op wanneer het plaatsvindt. Dat verklaart
+  ook waarom de volgorde binnen een pagina rommelig is (95 van de 149
+  opeenvolgende paren staan op datum, de rest niet).
+- **Fix, één ingreep in de view:** filter `datum >= vandaag` én sorteer
+  **oplopend** op de datum-veldwaarde i.p.v. `created DESC`. Dan staat
+  het eerstvolgende evenement bovenaan en loopt scrollen de toekomst in.
+- **Waarom dit vóór P2-1 moet:** een filter "Vandaag / Dit weekend /
+  Deze week" op een lijst die grotendeels uit verleden bestaat en op
+  aanmaakdatum sorteert, levert onvoorspelbare resultaten op.
+- ⚠️ **Nog te verifiëren door Bob:** of dit ook echt zo in de app oogt
+  (gemeten op de API, niet op een toestel), en of de horeca-/
+  favorieten-lijsten dezelfde sortering hebben.
 
 **P2-2 · Eigenaar: Onbepaald, bewust v2 (herbevestigd 2026-08-25 door
 Bob).** Google Maps-**overzichtsweergave** (kaart met meerdere markers)
@@ -2340,6 +2382,42 @@ nog (zie P2-6); oppakken zodra dat is afgerond, zelfde recept
 >
 > ---
 >
+> ### ✅ Live geverifieerd op een toestel (2026-09-05)
+> Profile-build van een verse export, telefoon-emulator (411 dp), gestart met
+> `fvm flutter run --profile -d emulator-5556 --route "/horecagelegenhedenOverzichtCopy3?plaats=25434"`
+> (25434 = Arnhem). **Het zoeken werkt echt:**
+> - Tab **Activiteiten**: 2 kaarten (klopt met de API), "vue" → 1 kaart.
+>   Hoofdletterongevoelig.
+> - Tab **Eetgelegenheden**: 20 kaarten, "pizza" → 5 kaarten. Nagerekend tegen
+>   de API: er zíjn precies 5 records met "pizza" in de titel. **Dit is meteen
+>   het bewijs dat het ook op een `ConditionalBuilder`-tab werkt**, niet alleen
+>   op de twee kale tabs.
+> - Zoekterm blijft staan bij het wisselen van tab (veld staat immers boven de
+>   `TabBar`) — precies de bedoeling.
+> - De **2 s debounce is goed merkbaar**: de lijst springt pas ~2 s nadat je
+>   stopt met typen.
+>
+> **Bijvangst 1 — twee lege `TextField`-placeholders zijn nu overbodig
+> (Eigenaar: Bob).** In tab 0 (Activiteiten) en tab 1 (Cultuur) staat nog het
+> oude, ongebonden `TextField` (hint letterlijk "TextField"). Op het toestel is
+> dat een zwevend wit vak dat half over de `TabBar` valt — lelijk en
+> verwarrend naast het echte zoekveld. De eerdere afspraak "laten staan tot
+> deze taak ze van een echte binding voorziet" is hiermee afgehandeld: het
+> echte zoekveld staat nu bóven de `TabBar`, dus deze twee zijn overbodig
+> geworden. Claude verwijdert niets — weghalen is aan Bob.
+>
+> **Bijvangst 2 — duplicaten in Drupal (Eigenaar: Bob, los van P2-6).** Voor
+> Arnhem/Eetgelegenheden staan dezelfde zaken dubbel in de view, met
+> verschillende categorie-sets: nid **53455** en **50584** heten allebei "New
+> York Pizza Arnhem Zuid", nid **53454** en **50583** allebei "New York Pizza
+> Arnhem Centrum". De app toont ze dus terecht dubbel; het zit in de data.
+>
+> *(Geen bug: dat de header "Amsterdam (gemeente)" toont terwijl de lijst
+> Arnhem-data bevat, komt doordat de deep-link alleen de page-parameter
+> `plaats` zet en niet de App State-gemeente. Artefact van de testmethode.)*
+>
+> ---
+>
 > ### Openstaande taken
 >
 > **A. Tab 6 (Verhuur, catering) koppelen · Eigenaar: Bob**
@@ -2369,6 +2447,14 @@ nog (zie P2-6); oppakken zodra dat is afgerond, zelfde recept
 >   Fors minder bindwerk en minder kans op de dialoogblokkade.
 > Zeg welke je wilt, dan bouwt Claude de functie én de dropdown (invoegen in
 > de root-`Column` is bewezen werkend, net als bij het zoekveld).
+> ⚠️ **`categorie` is in de API een LIJST, geen string** — bevestigd 2026-09-05
+> met een curl op Arnhem (`townid=25434`): `"categorie": ["Bioscoop"]`,
+> `["Entertainment Centre"]`. De bestaande `filterHorecagelegenheden` gaat daar
+> al goed mee om (`lijst.any((c) => c.toString()... == catFilter...)`), maar de
+> nieuwe unieke-categorieën-functie moet de binnenlijst **plat slaan** en niet
+> `.toString()` op het hele veld doen — anders krijg je opties als `[Bioscoop]`
+> die nooit matchen. Realistische aantallen per tab in Arnhem: Activiteiten 2
+> items / 2 categorieën, Eetgelegenheden 20 / 19, Uitgaan 4 / 4.
 >
 > **C. `Max Items` staat per tab op 25 · Eigenaar: Bob (beslissing)**
 > Bestond al vóór deze taak. Filteren gebeurt vóór het afkappen, dus zoeken