Afsluitroutine: overdracht bijgewerkt, meetrecept naar CLAUDE.md

TASKS.md: 'Voor Claude' stond nog op de stand van 09-11. Nu twee concrete
punten: de contentstand hermeten zodra Bobs import klaar is (komende events
bleven op ~58 en alles lag nog binnen september), en wachten op het display_id
voor Thuis bezorgen inclusief de twee al gemeten voorwaarden.

CLAUDE.md: het recept om te meten of content de app bereikt (displays
pagineren, nids naast de volledige voorraad leggen), met de valkuil die mij
een verkeerde telling opleverde - classificeren op datetime, niet op datum.

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

CLAUDE.md

@@ -2893,6 +2893,20 @@ gebeuren** — een gewone pager in de view volstaat, `page` werkt al. Wat
 ontbreekt zit altijd aan de app-kant (een `page`-variabele op de API
 Call + Infinite Scroll op de Backend Query).
 
+**Meten of content de app daadwerkelijk bereikt: pagineer de displays en leg
+de nids naast de volledige voorraad — en classificeer op datum PLUS tijd.**
+Werkend recept, 2026-09-12 (taak 28): haal per `flutterflowmobiel1`-display
+alle pagina's op en verzamel de nids; haal daarnaast `flutterflow_events`
+volledig op; het verschil is precies wat in geen enkele tab terechtkomt. Zo
+bleek 7 van de 58 komende events onzichtbaar — zes zonder categorie, één met
+een categorie die geen display dekt.
+⚠️ **De valkuil waar ik zelf in trapte:** de `datum`-string bevat een tijd
+(`Saturday 12 Sep, 14:00`) maar geen jaar. Leid het jaar af uit de weekdag, en
+vergelijk op **datetime**, niet op datum. Doe je dat laatste, dan tel je events
+van vandaag die al begonnen zijn ten onrechte als "toekomstig" — die worden
+namelijk correct door het `>= -2 hours`-filter weggelaten. Dat gaf een telling
+van 10 in plaats van 7.
+
 **Bij het testen of een views-endpoint een filter-parameter accepteert:
 stuur altijd óók een verzonnen parameter mee als controle.** Drupal Views
 negeert onbekende query-parameters **stil** — zonder die controle bewijst

TASKS.md

@@ -383,13 +383,19 @@ een keuzefilter in de app is een tweede, wél exposed filter nodig:
    uitkomst niets.
 Daarna kan Claude de drie knoppen in de app bouwen.
 
-### Voor Claude — nog open
-
-- Niets. Taken 18 en 22 zijn 2026-09-11 afgerond, met een verse export
-  geverifieerd én live nagelopen op de telefoon-AVD (profile-build):
-  drawer → *Horeca* en detailpagina → *Alle horecagelegenheden* komen allebei
-  uit op het 6-tabs-overzicht met Amsterdamse data, en uitgelogd is het
-  "Gemeente volgen"-blok op de gemeentekeuze netjes onzichtbaar.
+### Voor Claude — nog open (stand 2026-09-12 einde dag)
+
+- **Hermeet de contentstand zodra Bob's import van 12 september klaar is.**
+  Hij liep nog toen deze sessie sloot (2007 → 2963 unieke events in ±40 min),
+  maar de *komende* events bleven op ~58 staan en **alles lag nog binnen
+  september**. Twee vragen die dan te beantwoorden zijn: is er oktober
+  bijgekomen, en beweegt het percentage onzichtbare events (nu 7 van 58) mee?
+  Het recept staat bij taak 28.
+- **Wacht op Bob voor het `display_id` van de bezorg-display** (taak 20). Zodra
+  dat er is: drawer-item *Thuis bezorgen* eraan hangen. Let op de twee
+  voorwaarden die al gemeten zijn — het `horcat`-filter moet van die display af
+  (lege `horcat` geeft 0), en de pagina heeft nog géén `display_id`-parameter,
+  dus die moet er eerst op.
 
 ### Uit taak 18 voortgekomen — voor Bob (hoort bij P2-7 / taak 24)