P1-43 afgerond: sorteer-/verlopen-audit over alle lijstviews + P1-44 gevonden

- Alle 7 displays van flutterflowmobiel1 zijn 90-100% verlopen en niet
  chronologisch gesorteerd; met townid (Arnhem) zelfs 177 items, 0 toekomstig.
- Horeca-zaakagenda: 42 van 97 gemeten events verlopen, 4 zaken uitsluitend.
- Horeca-overzicht sorteert op nid aflopend, nooit alfabetisch.
- Favorieten-agenda alleen met sessie te meten (anoniem 403 -> lege lijst).
- P1-44 nieuw: alle vijf Home-tabs tonen dezelfde lijst omdat
  HomeUitgaantabelKaartComponent zijn displayid-parameter nergens gebruikt.

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

TASKS.md

@@ -24,8 +24,16 @@ tonen ±76% verlopen evenementen door sortering op `created DESC`) en
 **P2-1** (datumfilter) — één ingreep in dezelfde view lost beide op.
 **P1-5** (Thuis bezorgen) vergt ook views-werk en kan in diezelfde ronde.
 
-**Voor Claude:** **P1-43** — de sorteer-/verlopen-audit afmaken over de
-overige lijstviews. Code- en API-only, geen builder nodig.
+**P1-43 is afgerond (2026-09-06)** — de volledige audit staat als tabel
+bij P1-42. Kort: het raakt **alle zeven** displays van
+`flutterflowmobiel1` (90-100% verlopen), de horeca-zaakagenda, en het
+horeca-overzicht sorteert op nieuwste-inschrijving-eerst i.p.v.
+alfabetisch. Eén Drupal-ronde lost het hele rijtje op.
+
+**Nieuw gevonden en belangrijker dan de rest: P1-44** — alle vijf
+Home-tabs tonen dezelfde lijst, omdat `HomeUitgaantabelKaartComponent`
+zijn `displayid`-parameter nergens gebruikt. Builder-fix, staat bij
+P1-42/P1-43 verderop beschreven.
 
 ---
 
@@ -2216,26 +2224,95 @@ services_1/2/3 — de views waar Home zijn tabs mee vult.
   (gemeten op de API, niet op een toestel), en of de horeca-/
   favorieten-lijsten dezelfde sortering hebben.
 
-**P1-43 · Eigenaar: Claude — bezig (sessie 2026-09-06)** (code/API-only, geen builder — dus ook
-geschikt als Bob niet achter zijn scherm zit). Afmaken van de audit die
-P1-42 opleverde: **is de sorteer-/verlopen-bug beperkt tot
-`flutterflowmobiel1`, of raakt hij meer lijsten?** Na te lopen:
-1. De overige evenement-displays (`flutterflowmobiel1` services_2 t/m
-   services_7, `flutterflow_events`, `flutterflowmobiel_establishment_events`,
-   `flutterfavorietenagenda`) op dezelfde manier meten: maandspreiding
-   over de eerste ~6 pagina's, en hoe diep de paginering teruggaat.
-   Recept staat bij P1-42; let op dat `/nl/` Nederlandse maandafkortingen
-   geeft (`sep`) en `/en/` Engelse (`Sep`) — parser daarop aanpassen.
-2. De **favorieten-agenda** apart bekijken: die is per gebruiker en
-   vraagt een sessiecookie, dus meten met
-   `-H "Cookie: <session_name>=<sessid>"`.
-3. Vaststellen of de horeca-overzichten hetzelfde probleem hebben — die
-   hebben geen datum, dus daar gaat het om de vraag of `created DESC`
-   een zinnige volgorde is of dat sortering op naam/relevantie beter is.
-4. Uitkomst als één lijstje "welke view, welke sortering, hoeveel
-   verlopen" bij P1-42 zetten, zodat Bob alle views in één Drupal-sessie
-   kan afwerken i.p.v. één voor één.
+**Audit afgerond 2026-09-06 (P1-43, Claude — live `curl`, 6 pagina's =
+150 items per display, peildatum 6 sep 2026). Het probleem is NIET
+beperkt tot services_1/2/3 — het raakt elke evenementenlijst in de app:**
 
+| view / display | waar in de app | verlopen | volgorde |
+|---|---|---|---|
+| `flutterflowmobiel1` services_1 | Home-slider | 135/150 (90%) | 97/149 paren oplopend |
+| `flutterflowmobiel1` services_2 | Home-tabs (alle vijf, zie P1-44) | 142/150 (94%) | 87/149 |
+| `flutterflowmobiel1` services_3 | Uitgaan-tab + P-pagina's | 143/150 (95%) | 100/149 |
+| `flutterflowmobiel1` services_4 | Activiteiten-tab | **150/150 (100%)** | 75/149 |
+| `flutterflowmobiel1` services_5 | Cultuur & Info-tab | 142/150 (94%) | 87/149 |
+| `flutterflowmobiel1` services_6 | Films-tab | **150/150 (100%)** | 84/149 |
+| `flutterflowmobiel1` services_7 | Jeugd-tab | 149/150 (99%) | 89/149 |
+| `flutterflow_events` services_1 | evenement-detail (op nid) | 117/150 (78%) | 102/149 |
+| `flutterflowmobiel_establishment_events` | horeca-detail, agenda van de zaak | 42/97 (43%) | niet chronologisch |
+| `flutterflowmobiel_establishments` | horeca-overzicht | n.v.t. (geen datum) | **nid aflopend = nieuwste zaak eerst** |
+| `flutterfavorietenagenda` | Favorieten tab 1 | niet gemeten | niet gemeten |
+
+Wat daar per regel bij hoort:
+- **services_4, _6 en _7 zijn feitelijk archief**: over 150 items geen
+  enkel (services_4, _6) of één (services_7) toekomstig evenement.
+  services_4 loopt terug tot november 2025, services_7 zit voor 110 van
+  de 150 items in mei 2026.
+- **Met een `townid` erbij wordt het erger, niet beter.** services_3 met
+  `townid=25434` (Arnhem) geeft over de **volledige** paginering 177
+  evenementen, waarvan **0 toekomstig**; oudste 25 oktober 2025. Dat is
+  deels een inhoudsgat (Willemeen en Theater a/d Rijn hebben in
+  `establishment_events` óók geen toekomstige data), maar door
+  `created DESC` krijgt de bezoeker wel een pagina die volledig uit
+  verleden bestaat, zonder enige aanwijzing dat dat zo is.
+- **De horeca-agenda op een zaakpagina heeft hetzelfde probleem in het
+  klein**: maximaal 10 items, geen datumfilter, niet op datum gesorteerd.
+  In een steekproef van 15 zaken hadden 4 zaken uitsluitend verlopen
+  evenementen in hun agenda staan (75620, 75633, 67258, 70176).
+- **Het horeca-overzicht sorteert op nid aflopend** — geverifieerd over
+  6 categorieën in Arnhem, telkens exact aflopend en nooit alfabetisch.
+  Dat is dus "nieuwste inschrijving eerst", wat voor een naslaglijst
+  weinig betekent. Voorstel: alfabetisch op naam (voorspelbaar, en het
+  zoekveld uit P2-6 sluit daarop aan).
+- **De favorieten-agenda is niet zonder sessie te meten**: anoniem geeft
+  `favorieten_agenda.json` een **403** met body
+  `["Toegang geweigerd voor gebruiker anonymous"]`. `drupalRequest` maakt
+  daar (sinds de wijziging van 2026-08-17) een lege `[]` van, dus de app
+  crasht niet — maar een verlopen sessie ziet er in de app uit als "je
+  hebt geen favorieten", zonder melding. Klein los punt, niet dringend.
+- Meetscript staat in de scratchpad van deze sessie
+  (`audit/measure.py` + `run1..8.py`); het is 20 regels en zo weer
+  opgetuigd — jaartal komt uit het `/20xx/`-segment van het `url`-veld,
+  want `datum` bevat geen jaar.
+
+**Wat dit betekent voor de ingreep in Drupal:** het is één patroon over
+alle displays van `flutterflowmobiel1` heen, plus
+`flutterflowmobiel_establishment_events`. Zelfde fix (filter
+`datum >= vandaag`, sorteren oplopend op de datumveldwaarde) op alle
+zeven displays + de zaak-agenda in één ronde, en apart de vraag of het
+horeca-overzicht niet gewoon alfabetisch moet.
+
+**P1-43 · AFGEROND 2026-09-06 (Claude, code/API-only).** De audit uit
+P1-42 is afgemaakt; de uitkomst staat hierboven bij P1-42 als tabel. Deze
+taak kan weg zodra Bob de view-ronde in Drupal gedaan heeft.
+
+**P1-44 · Eigenaar: Bob (FlutterFlow-builder) — ALLE VIJF HOME-TABS
+TONEN DEZELFDE LIJST.** Gevonden 2026-09-06 tijdens P1-43, hard
+aantoonbaar in de code, nog niet op een toestel nagekeken.
+- `home_widget.dart` geeft elke tab een eigen display mee
+  (`displayid: 'services_3'` t/m `'services_7'`, regels 303/328/365/402/439)
+  aan `HomeUitgaantabelKaartComponentWidget`.
+- Dat component **gebruikt die parameter nergens**: `displayid` komt in
+  `home_uitgaantabel_kaart_component_widget.dart` alleen voor in de
+  declaratie (regels 25 en 28), en de enige API-aanroep is
+  `HomeTabelCall.call(page: ...)` (regel 135) — zonder display-argument.
+- `HomeTabelCall` heeft ook helemaal geen `displayId`-parameter en heeft
+  `display_id=services_2` **hardcoded in zijn URL**
+  (`api_calls.dart` regel ~252).
+- Gevolg: Uitgaan / Activiteiten / Cultuur & Info / Films / Jeugd tonen
+  alle vijf de inhoud van `services_2`. Alleen "Cultuur & Info" klopt bij
+  toeval — `services_2` en `services_5` leveren op de API exact dezelfde
+  nids (geverifieerd op pagina 0).
+- Ter vergelijking: de slider ernaast doet het wél goed
+  (`HomeSliderCall.call(displayId: widget!.displayid)`), en
+  `UitgaanstabelCall` heeft de parameter ook gewoon.
+- **Fix (builder):** `homeTabel` API Call een `displayId`-variabele geven
+  (net als `Uitgaanstabel`), en in de Backend Query van
+  `HomeUitgaantabelKaartComponent` binden aan de component-parameter
+  `displayid`. Let op de bekende paginerings-valkuil: bij het bewerken van
+  een Backend Query met Infinite Scroll moet de `page`-binding daarna terug
+  op "Next Page Index (StaggeredView)".
+- ⚠️ Doe dit **vóór** P1-42's view-ingreep opgeleverd wordt, anders wordt
+  daar per tab iets gemeten dat de gebruiker helemaal niet ziet.
 
 **P2-2 · Eigenaar: Onbepaald, bewust v2 (herbevestigd 2026-08-25 door
 Bob).** Google Maps-**overzichtsweergave** (kaart met meerdere markers)