CLAUDE.md: drie inzichten uit taak 131

- Plaats vs. adres: welk veld de app echt leest, en dat Drupal de
  locality sinds 2026-09-21 zelf vult (domeincontext).
- Het argumentenpaneel van een custom action is wel degelijk tot
  onderaan bereikbaar: trigger-kolom inklappen met |<, en meerdere
  chevron-kliks in een batch landen daar wel. Nuanceert de notitie dat
  het laatste argument altijd aan Bob overgedragen moet worden.
- Vertaalpaneel: triple_click selecteert maar een regel bij een
  meerregelige tekst, en een export vlak na het sluiten kan nog de oude
  waarde geven - kijk eerst naar het canvas voor je opnieuw typt.

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

CLAUDE.md

@@ -1268,6 +1268,21 @@ lange lijst aan Bob overgedragen moet worden** (in zijn eigen, hogere venster
 staat het gewoon in beeld). Noem daarbij letterlijk de doelwaarde en géén
 alternatieven in dezelfde zin — een terzijde in een keuzevraag ("X… nee, Y")
 leverde 2026-09-03 prompt de verkeerde binding op.
+- **✅ Genuanceerd 2026-09-21: bij 20 argumenten lukte het wél, en vlot.** Twee
+  dingen maakten het verschil. (1) **Klap eerst de trigger-kolom links in met het
+  `|<`-icoontje** (naast "Action Flow Editor" bovenin) — dan schuift het hele
+  rechterpaneel in beeld en staan de chevrons van elk argument op x≈paneelrand
+  in plaats van erbuiten. (2) **Meerdere inklap-kliks in één `browser_batch`
+  landen hier wél**, anders dan in het gewone rechterpaneel — zes chevrons met
+  2 s ertussen kwamen allemaal door. Klap ze van **onder naar boven** in, dan
+  blijven de coördinaten van de nog te klikken chevrons kloppen. Zo waren
+  argument 11-13 van `stadsactiviteitCreate` (20 stuks) in twee tool-aanroepen
+  in beeld. Probeer dit dus eerst vóór je overdraagt; de venstergrootte doet er
+  wel toe (dit was 1381 px breed).
+- **Een binding weghálen gaat via de Set-Variable-dialoog → knop `Remove`**
+  (rood, links naast Cancel/Confirm). Het veld springt daarna netjes op `Unset`,
+  en een optioneel String-argument mag zo blijven staan — de export zet er dan
+  `''` neer, geen `null`. Alleen List-types mogen niet Unset blijven (zie elders).
 
 **Een dropdown die zichzelf moet voorselecteren: de waarde moet op TWEE
 plekken gezet worden, want de lijst leeft alleen binnen de FutureBuilder.**
@@ -3696,6 +3711,16 @@ globe klikken (eigen aanroep) → `triple_click`+`triple_click`+`type` voor Dutc
 (eigen aanroep) → idem voor English (eigen aanroep) → `zoom` ter controle na
 elke. Reken op 3-4 aanroepen per tekst, plus 2 voor het selecteren van het
 widget.
+- **Bij een MEERREGELIGE tekst selecteert `triple_click` maar één regel** — daar
+  is het `left_click` + `ctrl+a` + typen (2026-09-21, een hulptekst van drie
+  regels; beide talen kwamen in één ronde door).
+- ⚠️ **Een export direct na het sluiten van het vertaalpaneel kan nog de OUDE
+  tekst geven.** Gebeurde 2026-09-21: de export toonde onveranderd de oude NL
+  én EN, terwijl het **canvas** de nieuwe tekst al liet zien. Twintig seconden
+  later gaf een tweede export beide nieuwe waarden. Conclusie vóór je opnieuw
+  gaat typen (en dan dubbel werk riskeert): **kijk eerst naar het canvas** —
+  staat de nieuwe tekst daar, wacht dan even en exporteer opnieuw in plaats van
+  de wijziging over te doen.
 
 **Het eigenschappen-zoekveld pakt de eerste typ-actie na een SELECTIEWISSEL niet,
 maar wél als het widget al geselecteerd was.** Praktisch: `left_click` op de
@@ -5181,6 +5206,28 @@ minder calls per scherm, niet in Views.
 
 ## Domein/architectuurcontext
 
+- **Plaats en adres zijn twee losse velden, en de app leest er maar één van.**
+  Bij een stadsactiviteit is `field_act_state_municipality_tow` de taxonomie-tid
+  (uit de dropdown-cascade) en `field_address1` het addressfield. De app toont
+  `plaats` uit de **taxonomie**; uit het adres neemt de view
+  `flutterflow_events` alleen **`field_address1_thoroughfare`** (de straat) mee.
+  `locality` wordt door de app **nergens** gelezen — ook niet via de twee
+  endpoints die het wél uitleveren (`favorieten_agenda` → `woonplaats`,
+  `mijn_aanmeldingen` → `adres_plaats`). Op de website staat het adresveld op de
+  activiteit-detailpagina op display `hidden`; alleen het "meer
+  activiteiten"-blok toont het (`City: <locality>`).
+  **Sinds 2026-09-21 vult `_custom_stadsactiviteit_create()` die locality zelf**
+  met `$term->name` van de gekozen plaats (en zet `country` op NL), zodat het
+  adresveld altijd gevuld is — het is `required` op het contenttype. De app
+  vraagt de plaats daarom niet meer los uit; het veld is van
+  `stadsactiviteitAanmaken` verwijderd. Geeft een client tóch een `locality` mee,
+  dan wint die. **Consequentie voor de kloon-knop:** `aanmelding_kloonbron`
+  levert `adres_plaats` nog steeds uit, maar dat hoef je niet te binden.
+  *Waarom dit klopt:* het website-formulier gebruikt voor datzelfde veld een
+  autocomplete op dezelfde town-vocabulary (vid 5), en van de 21 bestaande
+  activiteiten had geen enkele een locality die terecht van de taxonomie-plaats
+  afweek (12 gelijk, 9 rommel zoals een kale tid `28750`).
+
 - **Publicatiegedrag van via de app ingediende content.** Een **evenement**
   (`evenementCreate`, hangt altijd aan een eigen horecagelegenheid) wordt
   **direct gepubliceerd** (`$node->status = 1`) — de indiener is per definitie de