@flowselections/logistiek-engine 1.0.27 → 1.0.29

package/dist-lib/lib/modulePrompts.js

@@ -18,155 +18,155 @@ export const PROMPT_MODULE_LABELS = {
 };
 function sharedBlock(moduleKey) {
     const key = moduleKey === "<modulesleutel>" ? "<modulesleutel>" : moduleKey;
-    return `Alle communicatie met de Logistics Engine loopt uitsluitend via de gedeelde
-Supabase-database. Je leest en schrijft gewoon tabellen met de bestaande
-Supabase-client van deze module (ingelogde gebruiker, RLS). Geen API-key,
-geen header, geen secret, geen edge function.
-
-Verbinding — verplicht en fail-closed:
-- Gebruik de Supabase-client van je EIGEN module, lazy geïnstantieerd en
-  uitsluitend gevoed door import.meta.env.VITE_SUPABASE_URL en
-  import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY. Ontbreekt er een waarde, gooi
-  dan een harde fout; raad nooit een verbinding.
-- Hardcodeer NOOIT een Supabase project-ref, URL of anon-key — ook niet als
-  fallback, voorbeeld of default. De shell bepaalt via env welke database geldt.
-- Importeer NOOIT uit "@/integrations/supabase/client": dat bestand wordt door
-  de Supabase-integratie automatisch gegenereerd en overschreven met een
-  vastgezette project-ref, wat in een andere shell naar de verkeerde database
-  schrijft. Zet je eigen client in bijvoorbeeld
-  "@/integrations/supabase/moduleClient" en sluit het gegenereerde bestand uit
-  van je library-build.
-
-De Engine beslist alles over buffering, belading, picken, controle, printen en
-transport. Deze module voert alleen nog taken uit en beslist zelf niets meer.
-
---- Gebeurtenis melden: RPC logistics_emit_event (idempotent) ---
-const { data } = await supabase.rpc("logistics_emit_event", {
-  p_source_module: "${key}",
-  p_event_type: "order.received",      // of order.changed, stock.changed
-  p_order_ref: "SO-12345",
-  p_payload: {
-    checkinAt: "2026-08-01T10:00:00Z",
-    pickupAt: "2026-08-01T14:00:00Z",
-    customerRef: "CUST-1",
-    deliveryLocationRef: "LOC-1",
-    bufferRef: null,
-    loadCarriers: [{ type: "trolley", count: 3 }],
-    ruleVersion: null,                 // optioneel: plan op een vastgelegde regelversie
-  },
-  p_strategy_id: null,                 // uuid van logistics_strategies indien bekend
-  p_shadow: true,
-  p_idempotency_key: "${key}:SO-12345:order.received:v1",
-});
-// data = { eventId, planRunId, status, duplicate }
-Geef ALTIJD een p_idempotency_key mee die uniek is per gebeurtenis. Stuur je
-dezelfde melding twee keer (retry, dubbele webhook), dan plant de Engine maar
-één keer en krijg je duplicate: true terug.
-De Engine pakt de rij direct op (status pending -> processed), plant de keten en
-zet plan_run_id en error terug op dezelfde rij.
-
---- Taken ophalen: SELECT op public.logistics_tasks ---
-const { data } = await supabase
-  .from("logistics_tasks")
-  .select("*")
-  .eq("owner_module", "${key}")
-  .eq("status", "planned")
-  .order("planned_start", { ascending: true });
-Kolommen: order_ref, buffer_ref, task_type, sequence, depends_on,
-planned_start, planned_end, due_at, status, shadow, payload, result,
-rule_version, claimed_by, claimed_at, error.
-
-Realtime kan gewoon met supabase.channel() op logistics_tasks (in useEffect,
-met removeChannel in de cleanup).
-
---- Taak claimen: ALTIJD via RPC, nooit met een eigen UPDATE ---
-const { data: taak } = await supabase.rpc("logistics_claim_task", {
-  p_task_id: taskId, p_worker: "station-3",
-});
-if (!taak) { /* al door iemand anders geclaimd */ }
-
-// of automatisch de eerstvolgende taak van deze module:
-const { data: volgende } = await supabase.rpc("logistics_claim_next_task", {
-  p_owner_module: "${key}", p_worker: "station-3",
-});
-
---- Taak afmelden: ook via RPC ---
-await supabase.rpc("logistics_complete_task", { p_task_id: taskId, p_result: { ... } });
-await supabase.rpc("logistics_fail_task", { p_task_id: taskId, p_error: "reden" });
-
---- Order annuleren ---
-await supabase.rpc("logistics_emit_event", {
-  p_source_module: "${key}",
-  p_event_type: "order.cancelled",
-  p_order_ref: "SO-12345",
-  p_payload: { reason: "klant belde af" },
-  p_idempotency_key: "${key}:SO-12345:cancel:v1",
-});
-Al afgeronde taken blijven staan. Annuleer nooit zelf met een eigen UPDATE.
-
---- Order splitsen ---
-await supabase.rpc("logistics_emit_event", {
-  p_source_module: "${key}",
-  p_event_type: "order.split",
-  p_order_ref: "SO-12345",
-  p_payload: {
-    checkinAt: "...", pickupAt: "...",
-    children: [
-      { orderRef: "SO-12345-A", loadCarriers: [{ type: "trolley", count: 1 }] },
-      { orderRef: "SO-12345-B", loadCarriers: [{ type: "trolley", count: 2 }] },
-    ],
-  },
-  p_idempotency_key: "${key}:SO-12345:split:v1",
-});
-
---- Spoed / prioriteit ---
-await supabase.rpc("logistics_set_order_priority", {
-  p_order_ref: "SO-12345", p_priority: 100,
-});
-
---- Instellingen inzien (nooit zelf beslissen) ---
-public.logistics_strategies    de logistieke strategieën
-public.logistics_rule_configs  settings (jsonb) per strategie + current_version
-public.logistics_plan_runs     momentopname van de instellingen per planronde
-Alleen lezen, en alleen om te tonen.
-
-Ladingdragers: trolley, danish_container, euro_rolcontainer, pallet, euro_pallet, loose
-Taakstatussen: planned, claimed, in_progress, done, skipped, cancelled,
-superseded, failed
-
-Eigenaarschap: meldingen, planruns en taken hebben een kolom user_id die de
-database automatisch vult met het ingelogde account.
-
-Start in schaduwmodus (shadow: true): eigen logica blijft draaien, Engine-taken
-worden alleen getoond en vergeleken. Elke taak draagt rule_version — een lopende
+    return `Alle communicatie met de Logistics Engine loopt uitsluitend via de gedeelde
+Supabase-database. Je leest en schrijft gewoon tabellen met de bestaande
+Supabase-client van deze module (ingelogde gebruiker, RLS). Geen API-key,
+geen header, geen secret, geen edge function.
+
+Verbinding — verplicht en fail-closed:
+- Gebruik de Supabase-client van je EIGEN module, lazy geïnstantieerd en
+  uitsluitend gevoed door import.meta.env.VITE_SUPABASE_URL en
+  import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY. Ontbreekt er een waarde, gooi
+  dan een harde fout; raad nooit een verbinding.
+- Hardcodeer NOOIT een Supabase project-ref, URL of anon-key — ook niet als
+  fallback, voorbeeld of default. De shell bepaalt via env welke database geldt.
+- Importeer NOOIT uit "@/integrations/supabase/client": dat bestand wordt door
+  de Supabase-integratie automatisch gegenereerd en overschreven met een
+  vastgezette project-ref, wat in een andere shell naar de verkeerde database
+  schrijft. Zet je eigen client in bijvoorbeeld
+  "@/integrations/supabase/moduleClient" en sluit het gegenereerde bestand uit
+  van je library-build.
+
+De Engine beslist alles over buffering, belading, picken, controle, printen en
+transport. Deze module voert alleen nog taken uit en beslist zelf niets meer.
+
+--- Gebeurtenis melden: RPC logistics_emit_event (idempotent) ---
+const { data } = await supabase.rpc("logistics_emit_event", {
+  p_source_module: "${key}",
+  p_event_type: "order.received",      // of order.changed, stock.changed
+  p_order_ref: "SO-12345",
+  p_payload: {
+    checkinAt: "2026-08-01T10:00:00Z",
+    pickupAt: "2026-08-01T14:00:00Z",
+    customerRef: "CUST-1",
+    deliveryLocationRef: "LOC-1",
+    bufferRef: null,
+    loadCarriers: [{ type: "trolley", count: 3 }],
+    ruleVersion: null,                 // optioneel: plan op een vastgelegde regelversie
+  },
+  p_strategy_id: null,                 // uuid van logistics_strategies indien bekend
+  p_shadow: true,
+  p_idempotency_key: "${key}:SO-12345:order.received:v1",
+});
+// data = { eventId, planRunId, status, duplicate }
+Geef ALTIJD een p_idempotency_key mee die uniek is per gebeurtenis. Stuur je
+dezelfde melding twee keer (retry, dubbele webhook), dan plant de Engine maar
+één keer en krijg je duplicate: true terug.
+De Engine pakt de rij direct op (status pending -> processed), plant de keten en
+zet plan_run_id en error terug op dezelfde rij.
+
+--- Taken ophalen: SELECT op public.logistics_tasks ---
+const { data } = await supabase
+  .from("logistics_tasks")
+  .select("*")
+  .eq("owner_module", "${key}")
+  .eq("status", "planned")
+  .order("planned_start", { ascending: true });
+Kolommen: order_ref, buffer_ref, task_type, sequence, depends_on,
+planned_start, planned_end, due_at, status, shadow, payload, result,
+rule_version, claimed_by, claimed_at, error.
+
+Realtime kan gewoon met supabase.channel() op logistics_tasks (in useEffect,
+met removeChannel in de cleanup).
+
+--- Taak claimen: ALTIJD via RPC, nooit met een eigen UPDATE ---
+const { data: taak } = await supabase.rpc("logistics_claim_task", {
+  p_task_id: taskId, p_worker: "station-3",
+});
+if (!taak) { /* al door iemand anders geclaimd */ }
+
+// of automatisch de eerstvolgende taak van deze module:
+const { data: volgende } = await supabase.rpc("logistics_claim_next_task", {
+  p_owner_module: "${key}", p_worker: "station-3",
+});
+
+--- Taak afmelden: ook via RPC ---
+await supabase.rpc("logistics_complete_task", { p_task_id: taskId, p_result: { ... } });
+await supabase.rpc("logistics_fail_task", { p_task_id: taskId, p_error: "reden" });
+
+--- Order annuleren ---
+await supabase.rpc("logistics_emit_event", {
+  p_source_module: "${key}",
+  p_event_type: "order.cancelled",
+  p_order_ref: "SO-12345",
+  p_payload: { reason: "klant belde af" },
+  p_idempotency_key: "${key}:SO-12345:cancel:v1",
+});
+Al afgeronde taken blijven staan. Annuleer nooit zelf met een eigen UPDATE.
+
+--- Order splitsen ---
+await supabase.rpc("logistics_emit_event", {
+  p_source_module: "${key}",
+  p_event_type: "order.split",
+  p_order_ref: "SO-12345",
+  p_payload: {
+    checkinAt: "...", pickupAt: "...",
+    children: [
+      { orderRef: "SO-12345-A", loadCarriers: [{ type: "trolley", count: 1 }] },
+      { orderRef: "SO-12345-B", loadCarriers: [{ type: "trolley", count: 2 }] },
+    ],
+  },
+  p_idempotency_key: "${key}:SO-12345:split:v1",
+});
+
+--- Spoed / prioriteit ---
+await supabase.rpc("logistics_set_order_priority", {
+  p_order_ref: "SO-12345", p_priority: 100,
+});
+
+--- Instellingen inzien (nooit zelf beslissen) ---
+public.logistics_strategies    de logistieke strategieën
+public.logistics_rule_configs  settings (jsonb) per strategie + current_version
+public.logistics_plan_runs     momentopname van de instellingen per planronde
+Alleen lezen, en alleen om te tonen.
+
+Ladingdragers: trolley, danish_container, euro_rolcontainer, pallet, euro_pallet, loose
+Taakstatussen: planned, claimed, in_progress, done, skipped, cancelled,
+superseded, failed
+
+Eigenaarschap: meldingen, planruns en taken hebben een kolom user_id die de
+database automatisch vult met het ingelogde account.
+
+Start in schaduwmodus (shadow: true): eigen logica blijft draaien, Engine-taken
+worden alleen getoond en vergeleken. Elke taak draagt rule_version — een lopende
 order verandert nooit stilletjes mee als de Rule Engine wijzigt.`;
 }
-const STOCK_CONTRACT = `De Engine bepaalt of een bestelling met producten die niet op voorraad zijn
-überhaupt aangemaakt mag worden. Die keuze staat in de Rule Engine
-(Order verwerking -> "Bestellingen uitleveren wanneer een product niet op
-voorraad is"). Beslis dit NOOIT zelf.
-
-Roep vóór het opslaan van een nieuwe order (of het wijzigen van de aantallen)
-altijd deze RPC aan:
-
-const { data: check } = await supabase.rpc("logistics_check_order_allowed", {
-  p_lines: [
-    { productId: "<uuid of artikelnummer of barcode of floriday trade item id>", quantity: 12 },
-  ],
-  p_strategy_id: null, // uuid van logistics_strategies indien bekend
-});
-// check = { allowed, allowBackorder, shortages: [{ productId, product, wanted, available, missing }], reason }
-
-Regels:
-- allowed === false -> blokkeer het aanmaken/opslaan van de order volledig en
-  toon per regel uit check.shortages:
-  "<product>: besteld <wanted>, beschikbaar <available>, tekort <missing>".
-  Geen omweg, geen "toch doorgaan"-knop. reason = "insufficient_stock".
-- allowed === true en shortages niet leeg -> order mag wél aangemaakt worden
-  (uitleveren zonder voorraad staat aan); de Engine maakt zelf de melding en/of
-  e-mail aan. Toon de tekorten alleen ter informatie.
-- Alleen de instelling opvragen (bv. live waarschuwing tijdens typen):
-  const { data: mag } = await supabase.rpc("logistics_backorder_allowed", { p_strategy_id: null });
+const STOCK_CONTRACT = `De Engine bepaalt of een bestelling met producten die niet op voorraad zijn
+überhaupt aangemaakt mag worden. Die keuze staat in de Rule Engine
+(Order verwerking -> "Bestellingen uitleveren wanneer een product niet op
+voorraad is"). Beslis dit NOOIT zelf.
+
+Roep vóór het opslaan van een nieuwe order (of het wijzigen van de aantallen)
+altijd deze RPC aan:
+
+const { data: check } = await supabase.rpc("logistics_check_order_allowed", {
+  p_lines: [
+    { productId: "<uuid of artikelnummer of barcode of floriday trade item id>", quantity: 12 },
+  ],
+  p_strategy_id: null, // uuid van logistics_strategies indien bekend
+});
+// check = { allowed, allowBackorder, shortages: [{ productId, product, wanted, available, missing }], reason }
+
+Regels:
+- allowed === false -> blokkeer het aanmaken/opslaan van de order volledig en
+  toon per regel uit check.shortages:
+  "<product>: besteld <wanted>, beschikbaar <available>, tekort <missing>".
+  Geen omweg, geen "toch doorgaan"-knop. reason = "insufficient_stock".
+- allowed === true en shortages niet leeg -> order mag wél aangemaakt worden
+  (uitleveren zonder voorraad staat aan); de Engine maakt zelf de melding en/of
+  e-mail aan. Toon de tekorten alleen ter informatie.
+- Alleen de instelling opvragen (bv. live waarschuwing tijdens typen):
+  const { data: mag } = await supabase.rpc("logistics_backorder_allowed", { p_strategy_id: null });
 - Cache het antwoord niet: de instelling kan op elk moment wijzigen.`;
 const MODULES = {
     verkoop: {
@@ -179,16 +179,16 @@ const MODULES = {
                 date: "2026-07-24",
                 summary: "Orderbufferlogica eruit, events en taken via Supabase.",
                 withSharedContract: true,
-                body: `Haal weg: alle eigen orderbufferlogica, eigen samenvoegregels en alle
-fetch-calls naar een Engine-URL plus eventuele secrets.
-
-Bouw:
-- Bij nieuwe/gewijzigde order een gebeurtenis melden via logistics_emit_event
-  (event_type order.received of order.changed).
-- Taken van type buffer.close lezen uit logistics_tasks (owner_module "verkoop"),
-  uitvoeren en afmelden via logistics_claim_task + logistics_complete_task.
-- Buffer-samenstelling tonen zoals die in payload staat (matchCriteria, release).
-- release "manual" -> knop Vrijgeven. release "none" -> alleen tonen, niets doen.
+                body: `Haal weg: alle eigen orderbufferlogica, eigen samenvoegregels en alle
+fetch-calls naar een Engine-URL plus eventuele secrets.
+
+Bouw:
+- Bij nieuwe/gewijzigde order een gebeurtenis melden via logistics_emit_event
+  (event_type order.received of order.changed).
+- Taken van type buffer.close lezen uit logistics_tasks (owner_module "verkoop"),
+  uitvoeren en afmelden via logistics_claim_task + logistics_complete_task.
+- Buffer-samenstelling tonen zoals die in payload staat (matchCriteria, release).
+- release "manual" -> knop Vrijgeven. release "none" -> alleen tonen, niets doen.
 - In schaduwmodus: Engine-buffersluittijd naast de eigen berekening tonen.`,
             },
             {
@@ -196,16 +196,16 @@ Bouw:
                 title: "Voorraadcontrole vóór het aanmaken van een order",
                 date: "2026-07-31",
                 summary: "Nieuwe eis bovenop prompt 1: order blokkeren als een product niet op voorraad is.",
-                body: `AANVULLING op koppelprompt 1 (die blijft gewoon geldig, niets terugdraaien).
-
-Nieuwe verplichting: vóór het aanmaken of wijzigen van een order eerst de
-voorraadcontrole van de Engine aanroepen.
-
-${STOCK_CONTRACT}
-
-In de Verkoop-module concreet:
-- Blokkeer de opslaan-knop van de order zolang allowed false is.
-- Toon de tekorten in het orderscherm, per regel bij het product.
+                body: `AANVULLING op koppelprompt 1 (die blijft gewoon geldig, niets terugdraaien).
+
+Nieuwe verplichting: vóór het aanmaken of wijzigen van een order eerst de
+voorraadcontrole van de Engine aanroepen.
+
+${STOCK_CONTRACT}
+
+In de Verkoop-module concreet:
+- Blokkeer de opslaan-knop van de order zolang allowed false is.
+- Toon de tekorten in het orderscherm, per regel bij het product.
 - Doe de controle ook opnieuw bij het wijzigen van aantallen of regels.`,
             },
             {
@@ -213,51 +213,51 @@ In de Verkoop-module concreet:
                 title: "Bufferen mag alleen als de Engine dat zegt",
                 date: "2026-07-31",
                 summary: "Nieuwe eis bovenop prompt 1 en 2: geen eigen bufferbesluit meer, altijd eerst logistics_buffer_decision aanroepen.",
-                body: `AANVULLING op koppelprompt 1 en 2 (die blijven gewoon geldig).
-
-Probleem: er stonden orders in een orderbuffer terwijl bufferen in de Rule Engine
-UIT stond. De Verkoop-module beslist dat dus nog zelf. Dat moet eruit.
-
-Haal weg: elke eigen regel, instelling of code die bepaalt of een order in een
-orderbuffer / gecombineerde order terechtkomt, inclusief automatisch aanmaken of
-toewijzen van een buffer bij het opslaan van een order.
-
-Nieuwe verplichting: vraag het per order aan de Engine.
-
-const { data: besluit } = await supabase.rpc("logistics_buffer_decision", {
-  p_order: {
-    orderRef: "SO-12345",
-    checkinAt: "2026-08-01T10:00:00Z",
-    customerRef: "CUST-1",
-    floridayCustomerRef: "FLOR-1",
-    bvoCustomerRef: "BVO-1",
-    deliveryLocationRef: "LOC-1",
-    deliveryDate: "2026-08-01",
-    carrierRef: "TRANS-1",
-    loadCarrierType: "trolley",
-    orderType: "standaard",
-  },
-  p_strategy_id: null, // uuid van logistics_strategies indien bekend
-});
-// besluit = { buffer, reason, bufferRef, bufferKey, matchCriteria,
-//             closeBeforeMinutes, bufferCloseAt, release }
-
-Regels:
-- besluit.buffer === false (reason "buffering_disabled") -> de order gaat LOS door.
-  Geen buffer aanmaken, geen bestaande buffer toewijzen, geen buffer tonen.
-- besluit.buffer === true -> gebruik exact besluit.bufferRef als buffersleutel.
-  Orders met dezelfde bufferRef horen in dezelfde gecombineerde order. Bepaal die
-  groepering nooit zelf op eigen criteria.
-- Toon buffersluittijd uit besluit.bufferCloseAt, en de vrijgave uit
-  besluit.release ("auto" | "manual" | "none"). Bij "manual" een knop Vrijgeven,
-  bij "none" alleen tonen.
-- Cache het antwoord niet: de instelling kan op elk moment wijzigen. Vraag het
-  opnieuw bij elke wijziging van de order (aanmeldtijd, klant, locatie, aantallen).
-- Stuur bufferRef mee in de payload van logistics_emit_event (veld bufferRef),
-  zodat de Engine en de Verkoop-module dezelfde buffer bedoelen.
-
-Eenmalige opschoning: haal bij bestaande, nog niet afgehandelde orders de
-bufferkoppeling weg zodra logistics_buffer_decision voor die order buffer=false
+                body: `AANVULLING op koppelprompt 1 en 2 (die blijven gewoon geldig).
+
+Probleem: er stonden orders in een orderbuffer terwijl bufferen in de Rule Engine
+UIT stond. De Verkoop-module beslist dat dus nog zelf. Dat moet eruit.
+
+Haal weg: elke eigen regel, instelling of code die bepaalt of een order in een
+orderbuffer / gecombineerde order terechtkomt, inclusief automatisch aanmaken of
+toewijzen van een buffer bij het opslaan van een order.
+
+Nieuwe verplichting: vraag het per order aan de Engine.
+
+const { data: besluit } = await supabase.rpc("logistics_buffer_decision", {
+  p_order: {
+    orderRef: "SO-12345",
+    checkinAt: "2026-08-01T10:00:00Z",
+    customerRef: "CUST-1",
+    floridayCustomerRef: "FLOR-1",
+    bvoCustomerRef: "BVO-1",
+    deliveryLocationRef: "LOC-1",
+    deliveryDate: "2026-08-01",
+    carrierRef: "TRANS-1",
+    loadCarrierType: "trolley",
+    orderType: "standaard",
+  },
+  p_strategy_id: null, // uuid van logistics_strategies indien bekend
+});
+// besluit = { buffer, reason, bufferRef, bufferKey, matchCriteria,
+//             closeBeforeMinutes, bufferCloseAt, release }
+
+Regels:
+- besluit.buffer === false (reason "buffering_disabled") -> de order gaat LOS door.
+  Geen buffer aanmaken, geen bestaande buffer toewijzen, geen buffer tonen.
+- besluit.buffer === true -> gebruik exact besluit.bufferRef als buffersleutel.
+  Orders met dezelfde bufferRef horen in dezelfde gecombineerde order. Bepaal die
+  groepering nooit zelf op eigen criteria.
+- Toon buffersluittijd uit besluit.bufferCloseAt, en de vrijgave uit
+  besluit.release ("auto" | "manual" | "none"). Bij "manual" een knop Vrijgeven,
+  bij "none" alleen tonen.
+- Cache het antwoord niet: de instelling kan op elk moment wijzigen. Vraag het
+  opnieuw bij elke wijziging van de order (aanmeldtijd, klant, locatie, aantallen).
+- Stuur bufferRef mee in de payload van logistics_emit_event (veld bufferRef),
+  zodat de Engine en de Verkoop-module dezelfde buffer bedoelen.
+
+Eenmalige opschoning: haal bij bestaande, nog niet afgehandelde orders de
+bufferkoppeling weg zodra logistics_buffer_decision voor die order buffer=false
 teruggeeft. Al verwerkte/verzonden orders laat je met rust.`,
             },
             {
@@ -265,33 +265,33 @@ teruggeeft. Al verwerkte/verzonden orders laat je met rust.`,
                 title: "Correctie bufferbesluit: nieuwe velden en uitleg",
                 date: "2026-08-02",
                 summary: "Nieuwe eis bovenop prompt 3: logistics_buffer_decision is gecorrigeerd, stuur alle matchvelden mee en gebruik de uitleg (trace).",
-                body: `AANVULLING op koppelprompt 1, 2 en 3 (die blijven gewoon geldig).
-
-Wat er is gewijzigd aan de Engine-kant:
-- logistics_buffer_decision las de Rule Engine-instellingen fout uit en negeerde de
-  aangevinkte criteria. Dat is opgelost: de gekozen criteria worden nu echt vergeleken.
-- De buffersleutel bevat niet langer het exacte sluitmoment. Orders met dezelfde
-  gegevens maar een iets andere aanmeldtijd komen nu wél in dezelfde buffer.
-- De functie heeft een derde parameter p_user_id (laat die weg of op null staan).
-- Het antwoord bevat nu ook een veld trace: per criterium waarom het klopt of niet.
-
-Wat de Verkoop-module moet doen:
-1. Stuur bij elke aanroep ALLE velden mee die als criterium gekozen kunnen zijn.
-   Ontbreekt een waarde van een aangevinkt criterium, dan combineert de Engine de
-   order bewust NIET (reason "buffering_enabled_missing_data").
-   Verplichte velden in p_order:
-     orderRef, checkinAt, deliveryDate, customerRef, floridayCustomerRef,
-     bvoCustomerRef, deliveryLocationRef, carrierRef, loadCarrierType, orderType
-   deliveryLocationRef moet een stabiele sleutel zijn van het afleveradres
-   (locatie-id of genormaliseerd adres), niet een vrije tekst die per order verschilt.
-2. Toon in het orderscherm de reden uit besluit.reason en, bij twijfel, de regels uit
-   besluit.trace ("waarom zit deze order niet bij die andere order?").
-3. Vraag het besluit opnieuw op zodra een van bovenstaande velden wijzigt, en
-   verplaats de order dan naar de nieuwe bufferRef.
-4. Bepaal nooit zelf of twee orders bij elkaar horen; vergelijk alleen bufferRef.
-
-Eenmalige opschoning: haal voor alle nog niet verwerkte orders opnieuw het besluit op
-en werk de bufferkoppeling bij. Orders die volgens de Engine samen horen, moeten daarna
+                body: `AANVULLING op koppelprompt 1, 2 en 3 (die blijven gewoon geldig).
+
+Wat er is gewijzigd aan de Engine-kant:
+- logistics_buffer_decision las de Rule Engine-instellingen fout uit en negeerde de
+  aangevinkte criteria. Dat is opgelost: de gekozen criteria worden nu echt vergeleken.
+- De buffersleutel bevat niet langer het exacte sluitmoment. Orders met dezelfde
+  gegevens maar een iets andere aanmeldtijd komen nu wél in dezelfde buffer.
+- De functie heeft een derde parameter p_user_id (laat die weg of op null staan).
+- Het antwoord bevat nu ook een veld trace: per criterium waarom het klopt of niet.
+
+Wat de Verkoop-module moet doen:
+1. Stuur bij elke aanroep ALLE velden mee die als criterium gekozen kunnen zijn.
+   Ontbreekt een waarde van een aangevinkt criterium, dan combineert de Engine de
+   order bewust NIET (reason "buffering_enabled_missing_data").
+   Verplichte velden in p_order:
+     orderRef, checkinAt, deliveryDate, customerRef, floridayCustomerRef,
+     bvoCustomerRef, deliveryLocationRef, carrierRef, loadCarrierType, orderType
+   deliveryLocationRef moet een stabiele sleutel zijn van het afleveradres
+   (locatie-id of genormaliseerd adres), niet een vrije tekst die per order verschilt.
+2. Toon in het orderscherm de reden uit besluit.reason en, bij twijfel, de regels uit
+   besluit.trace ("waarom zit deze order niet bij die andere order?").
+3. Vraag het besluit opnieuw op zodra een van bovenstaande velden wijzigt, en
+   verplaats de order dan naar de nieuwe bufferRef.
+4. Bepaal nooit zelf of twee orders bij elkaar horen; vergelijk alleen bufferRef.
+
+Eenmalige opschoning: haal voor alle nog niet verwerkte orders opnieuw het besluit op
+en werk de bufferkoppeling bij. Orders die volgens de Engine samen horen, moeten daarna
 dezelfde bufferRef hebben.`,
             },
             {
@@ -299,44 +299,44 @@ dezelfde bufferRef hebben.`,
                 title: "Alleen ladingdragers tonen die de Engine toestaat",
                 date: "2026-08-03",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 4: uitgeschakelde ladingdragers mogen niet meer kiesbaar zijn.",
-                body: `AANVULLING op koppelprompt 1, 2, 3 en 4 (die blijven gewoon geldig).
-
-In de Rule Engine (stap Beladingindeling) staat welke ladingdragers zijn toegestaan.
-Staat een ladingdrager uit, dan mag die in de Verkoop-module nergens meer te kiezen
-zijn.
-
-Haal weg: elke eigen, vaste lijst met ladingdragers / verzendmethodes in de code,
-in constanten, in dropdowns of in filters.
-
-Nieuwe verplichting: haal de lijst op bij de Engine.
-
-const { data: dragers } = await supabase.rpc("logistics_allowed_load_carriers", {
-  p_strategy_id: null, // uuid van logistics_strategies indien bekend
-});
-// dragers = {
-//   allowed: ["trolley","pallet"],
-//   default: "trolley",
-//   carriers: [{ code, label, enabled, isDefault }, ...]
-// }
-
-Codes en namen (gebruik exact deze codes):
-  trolley            Stapelwagen
-  danish_container   Deense container
-  euro_rolcontainer  Euro-rolcontainer
-  pallet             Pallet
-  euro_pallet        Euro-pallet
-  loose              Geen ladingdrager
-
-Regels:
-- Toon in elk keuzeveld (order, orderregel, verzendmethode, filter) alleen de
-  dragers met enabled === true. Uitgeschakelde dragers niet grijs tonen: weglaten.
-- Voorselectie = dragers.default.
-- Blokkeer opslaan als een order een ladingdrager heeft die niet in allowed staat,
-  met melding: "Deze ladingdrager is uitgeschakeld in de Logistics Engine."
-- Cache de lijst niet langer dan één schermsessie; de instelling kan wijzigen.
-- Bestaande, nog niet verwerkte orders met een inmiddels uitgeschakelde drager:
-  markeer die in het overzicht zodat een medewerker een andere drager kiest.
-- Stuur loadCarrierType in logistics_emit_event en logistics_buffer_decision altijd
+                body: `AANVULLING op koppelprompt 1, 2, 3 en 4 (die blijven gewoon geldig).
+
+In de Rule Engine (stap Beladingindeling) staat welke ladingdragers zijn toegestaan.
+Staat een ladingdrager uit, dan mag die in de Verkoop-module nergens meer te kiezen
+zijn.
+
+Haal weg: elke eigen, vaste lijst met ladingdragers / verzendmethodes in de code,
+in constanten, in dropdowns of in filters.
+
+Nieuwe verplichting: haal de lijst op bij de Engine.
+
+const { data: dragers } = await supabase.rpc("logistics_allowed_load_carriers", {
+  p_strategy_id: null, // uuid van logistics_strategies indien bekend
+});
+// dragers = {
+//   allowed: ["trolley","pallet"],
+//   default: "trolley",
+//   carriers: [{ code, label, enabled, isDefault }, ...]
+// }
+
+Codes en namen (gebruik exact deze codes):
+  trolley            Stapelwagen
+  danish_container   Deense container
+  euro_rolcontainer  Euro-rolcontainer
+  pallet             Pallet
+  euro_pallet        Euro-pallet
+  loose              Geen ladingdrager
+
+Regels:
+- Toon in elk keuzeveld (order, orderregel, verzendmethode, filter) alleen de
+  dragers met enabled === true. Uitgeschakelde dragers niet grijs tonen: weglaten.
+- Voorselectie = dragers.default.
+- Blokkeer opslaan als een order een ladingdrager heeft die niet in allowed staat,
+  met melding: "Deze ladingdrager is uitgeschakeld in de Logistics Engine."
+- Cache de lijst niet langer dan één schermsessie; de instelling kan wijzigen.
+- Bestaande, nog niet verwerkte orders met een inmiddels uitgeschakelde drager:
+  markeer die in het overzicht zodat een medewerker een andere drager kiest.
+- Stuur loadCarrierType in logistics_emit_event en logistics_buffer_decision altijd
   met een van bovenstaande codes mee, nooit met een eigen naam of vrije tekst.`,
             },
             {
@@ -344,55 +344,55 @@ Regels:
                 title: "Karindeling: eigen planner eruit, Engine-planner erin",
                 date: "2026-08-27",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 5: /api/public/cron/replan-carts schrijft nog eigen karren met algorithm_version 1 en valt terug op 1×1×1.",
-                body: `AANVULLING op koppelprompt 1 t/m 5 (die blijven gewoon geldig).
-
-GEMETEN PROBLEEM (Mathot productie, 27-08-2026)
-public.order_carts bevat 11.560 rijen met algorithm_version = 1, nog steeds
-groeiend (laatste 13:12:59). Zetten we cron 113 (elke minuut naar
-/api/public/cron/replan-carts) uit, dan stopt de aanwas onmiddellijk. De
-schrijver is dus de Verkoop-module.
-
-Bewijs in de Verkoop-module:
-- src/lib/cart-replan.functions.ts, regel ~178-190: INSERT in order_carts met
-  algorithm_version: CART_PLANNER_VERSION.
-- src/lib/cart-planner.ts, regel 14: export const CART_PLANNER_VERSION = 1.
-- src/lib/cart-replan.functions.ts, regel ~208: INSERT in order_cart_items.
-- src/lib/create-order.functions.ts, regel ~1196 + ~1203 en ~1296 + ~1313:
-  INSERTs die algorithm_version en source helemaal niet zetten, dus de
-  kolomdefaults ('auto', 1) gebruiken.
-- Dit pad rekent zélf (planCarts uit src/lib/cart-planner.ts). Het roept de
-  gedeelde Engine-planner (loadCarrierPlanning / planByFloridayPacking,
-  LOAD_CARRIER_PLANNER_VERSION = 3) NIET aan.
-- Terugval bij ontbrekende belading: in de mapping naar PlannerInputItem staat
-  overal \`?? 1\` (plants_per_crate, crates_per_layer, layers_per_cart). Bij een
-  order zonder bekende belading levert dat stilzwijgend 1×1×1 op — precies wat de
-  beslisregel van 26-08 verbiedt. De guard (B1/B2/B3) zit niet in dit pad.
-
-WAT ER MOET GEBEUREN — voorkeur A, minimaal B.
-
-A (voorkeur). Laat /api/public/cron/replan-carts niet meer zelf rekenen.
-Roep de gedeelde planner van de Logistics Engine aan
-(@flowselections/logistiek-engine → loadCarrierPlanning /
-planByFloridayPacking) en schrijf uitsluitend het resultaat weg. Verwijder
-src/lib/cart-planner.ts als schrijfpad. Reden: één rekenhart, dus geen derde
-afwijkende indeling naast TS en SQL.
-
-B (alleen als A nu te groot is, en dan als tussenstap):
-- Zet in ELKE INSERT in order_carts expliciet
-  algorithm_version: LOAD_CARRIER_PLANNER_VERSION (nu 3) en source
-  ('auto' | 'manual' | 'floriday'). Ook in create-order.functions.ts regel
-  ~1196 en ~1296. Vertrouw nooit op de kolomdefault.
-- Neem dezelfde guard over als de Engine: is de belading van een orderregel
-  onbekend (geen plants_per_crate / crates_per_layer / layers_per_cart op de
-  regel én niet op het product), dan wordt die regel NIET ingedeeld. Geen
-  \`?? 1\`, nooit terugvallen op 1×1×1. Meld het als blokkade op de order,
-  zodat een medewerker de belading invult.
-- Verwijder alle bestaande rijen met algorithm_version < 3 pas nadat A of B
-  live is; anders komen ze binnen een minuut terug.
-
-NIET DOEN
-- De kolomdefaults van order_carts niet weghalen en algorithm_version niet
-  NOT NULL maken; dat kan pas als alle schrijfpaden de kolom zetten.
+                body: `AANVULLING op koppelprompt 1 t/m 5 (die blijven gewoon geldig).
+
+GEMETEN PROBLEEM (Mathot productie, 27-08-2026)
+public.order_carts bevat 11.560 rijen met algorithm_version = 1, nog steeds
+groeiend (laatste 13:12:59). Zetten we cron 113 (elke minuut naar
+/api/public/cron/replan-carts) uit, dan stopt de aanwas onmiddellijk. De
+schrijver is dus de Verkoop-module.
+
+Bewijs in de Verkoop-module:
+- src/lib/cart-replan.functions.ts, regel ~178-190: INSERT in order_carts met
+  algorithm_version: CART_PLANNER_VERSION.
+- src/lib/cart-planner.ts, regel 14: export const CART_PLANNER_VERSION = 1.
+- src/lib/cart-replan.functions.ts, regel ~208: INSERT in order_cart_items.
+- src/lib/create-order.functions.ts, regel ~1196 + ~1203 en ~1296 + ~1313:
+  INSERTs die algorithm_version en source helemaal niet zetten, dus de
+  kolomdefaults ('auto', 1) gebruiken.
+- Dit pad rekent zélf (planCarts uit src/lib/cart-planner.ts). Het roept de
+  gedeelde Engine-planner (loadCarrierPlanning / planByFloridayPacking,
+  LOAD_CARRIER_PLANNER_VERSION = 3) NIET aan.
+- Terugval bij ontbrekende belading: in de mapping naar PlannerInputItem staat
+  overal \`?? 1\` (plants_per_crate, crates_per_layer, layers_per_cart). Bij een
+  order zonder bekende belading levert dat stilzwijgend 1×1×1 op — precies wat de
+  beslisregel van 26-08 verbiedt. De guard (B1/B2/B3) zit niet in dit pad.
+
+WAT ER MOET GEBEUREN — voorkeur A, minimaal B.
+
+A (voorkeur). Laat /api/public/cron/replan-carts niet meer zelf rekenen.
+Roep de gedeelde planner van de Logistics Engine aan
+(@flowselections/logistiek-engine → loadCarrierPlanning /
+planByFloridayPacking) en schrijf uitsluitend het resultaat weg. Verwijder
+src/lib/cart-planner.ts als schrijfpad. Reden: één rekenhart, dus geen derde
+afwijkende indeling naast TS en SQL.
+
+B (alleen als A nu te groot is, en dan als tussenstap):
+- Zet in ELKE INSERT in order_carts expliciet
+  algorithm_version: LOAD_CARRIER_PLANNER_VERSION (nu 3) en source
+  ('auto' | 'manual' | 'floriday'). Ook in create-order.functions.ts regel
+  ~1196 en ~1296. Vertrouw nooit op de kolomdefault.
+- Neem dezelfde guard over als de Engine: is de belading van een orderregel
+  onbekend (geen plants_per_crate / crates_per_layer / layers_per_cart op de
+  regel én niet op het product), dan wordt die regel NIET ingedeeld. Geen
+  \`?? 1\`, nooit terugvallen op 1×1×1. Meld het als blokkade op de order,
+  zodat een medewerker de belading invult.
+- Verwijder alle bestaande rijen met algorithm_version < 3 pas nadat A of B
+  live is; anders komen ze binnen een minuut terug.
+
+NIET DOEN
+- De kolomdefaults van order_carts niet weghalen en algorithm_version niet
+  NOT NULL maken; dat kan pas als alle schrijfpaden de kolom zetten.
 - De beslisregel van 26-08 (B1/B2/B3) niet wijzigen — alleen overnemen.`,
             },
             {
@@ -400,40 +400,40 @@ NIET DOEN
                 title: "Orderoverzicht uit de Engine: één waarheid voor alle modules",
                 date: "2026-09-01",
                 summary: "De verkooplijst toont karren, planten en pickdag uit logistics_order_overview, zodat Verkoop, Afhandeling en Pick exact dezelfde cijfers laten zien.",
-                body: `AANVULLING op koppelprompt 1 t/m 6 (die blijven geldig).
-
-WAAROM
-Elke module telde tot nu toe zelf karren: de pick agenda telde payload-velden van
-taken (3517 karren), Controle karren telde cart_numbers (27) en Verkoop telde
-order_carts. Drie tellingen, drie antwoorden. De Engine heeft nu één index:
-public.logistics_cart_index. Alle schermen lezen daaruit.
-
-BOUW DIT
-- Haal de orderlijst op met:
-
-  const { data, error } = await supabase.rpc("logistics_order_overview", {
-    p_from: null, p_to: null,
-  });
-  if (error) throw new Error(error.message);
-  const orders = Array.isArray(data) ? data : [];
-
-- Kolommen: order_uuid, order_number, customer_name, order_source,
-  delivery_date, status, pick_date, cart_count, plant_count, shifted,
-  printed_at.
-- Toon cart_count en plant_count exact zoals ze binnenkomen; niet zelf
-  hertellen uit order_carts of order_items.
-- pick_date is de pickdag van de Engine; die ligt nooit in het verleden.
-- shifted = true toont het label "te laat aangemeld".
-- printed_at gevuld = de order is al uitgeprint.
-
-NIET DOEN
-- Geen eigen count op order_carts / order_cart_items voor weergave.
-- Geen eigen pickdagberekening uit delivery_date.
-- Geen datum, project-ref of Supabase-URL hardcoden.
-
-CONTROLELIJST
-[ ] Karrenaantal in Verkoop is gelijk aan dat in de pick agenda en in Controle.
-[ ] Een gemengde kar telt bij elke deelnemende order mee, maar per dag één keer.
+                body: `AANVULLING op koppelprompt 1 t/m 6 (die blijven geldig).
+
+WAAROM
+Elke module telde tot nu toe zelf karren: de pick agenda telde payload-velden van
+taken (3517 karren), Controle karren telde cart_numbers (27) en Verkoop telde
+order_carts. Drie tellingen, drie antwoorden. De Engine heeft nu één index:
+public.logistics_cart_index. Alle schermen lezen daaruit.
+
+BOUW DIT
+- Haal de orderlijst op met:
+
+  const { data, error } = await supabase.rpc("logistics_order_overview", {
+    p_from: null, p_to: null,
+  });
+  if (error) throw new Error(error.message);
+  const orders = Array.isArray(data) ? data : [];
+
+- Kolommen: order_uuid, order_number, customer_name, order_source,
+  delivery_date, status, pick_date, cart_count, plant_count, shifted,
+  printed_at.
+- Toon cart_count en plant_count exact zoals ze binnenkomen; niet zelf
+  hertellen uit order_carts of order_items.
+- pick_date is de pickdag van de Engine; die ligt nooit in het verleden.
+- shifted = true toont het label "te laat aangemeld".
+- printed_at gevuld = de order is al uitgeprint.
+
+NIET DOEN
+- Geen eigen count op order_carts / order_cart_items voor weergave.
+- Geen eigen pickdagberekening uit delivery_date.
+- Geen datum, project-ref of Supabase-URL hardcoden.
+
+CONTROLELIJST
+[ ] Karrenaantal in Verkoop is gelijk aan dat in de pick agenda en in Controle.
+[ ] Een gemengde kar telt bij elke deelnemende order mee, maar per dag één keer.
 [ ] Verwijderde orders verdwijnen uit de lijst zonder losse taken achter te laten.`,
             },
             {
@@ -441,29 +441,29 @@ CONTROLELIJST
                 title: "Statusvelden en leverdatum in het orderoverzicht",
                 date: "2026-09-01",
                 summary: "logistics_order_overview blijft de enige lijst; de karindex levert nu ook aangemeld/geprint/gecontroleerd en de leverdatum.",
-                body: `AANVULLING op prompt 1 t/m 7 (die blijven geldig).
-
-WAT ER VERANDERT
-public.logistics_cart_index geeft per (order, kar) nu ook:
-delivery_date, is_announced, is_printed, is_controlled.
-Daarop draaien logistics_pick_agenda, logistics_delivery_agenda,
-control_get_todays_carts, logistics_order_overview en het Picking Station.
-
-BOUW DIT
-- Blijf de orderlijst uitsluitend uit logistics_order_overview halen.
-- Wil je voortgang per order tonen, lees dan de statusvelden uit de index of
-  uit logistics_delivery_agenda; bereken zelf niets bij.
-- Een filter op status (bijv. "alleen nog niet geprint") mag regels verbergen,
-  maar nooit het totaal aan karren veranderen.
-
-CONTROLE OP AFWIJKING
-  const { data } = await supabase.rpc("logistics_consistency_check");
-Velden: agenda_carts, control_carts, raw_carts, delivery_carts, station_carts,
-sales_carts, announced_carts, orphan_tasks, ok.
-Is ok === false, toon een discrete melding en corrigeer niets zelf.
-
-CONTROLELIJST
-[ ] Verkoop, pick agenda, lever agenda, controle en picking station tonen hetzelfde aantal.
+                body: `AANVULLING op prompt 1 t/m 7 (die blijven geldig).
+
+WAT ER VERANDERT
+public.logistics_cart_index geeft per (order, kar) nu ook:
+delivery_date, is_announced, is_printed, is_controlled.
+Daarop draaien logistics_pick_agenda, logistics_delivery_agenda,
+control_get_todays_carts, logistics_order_overview en het Picking Station.
+
+BOUW DIT
+- Blijf de orderlijst uitsluitend uit logistics_order_overview halen.
+- Wil je voortgang per order tonen, lees dan de statusvelden uit de index of
+  uit logistics_delivery_agenda; bereken zelf niets bij.
+- Een filter op status (bijv. "alleen nog niet geprint") mag regels verbergen,
+  maar nooit het totaal aan karren veranderen.
+
+CONTROLE OP AFWIJKING
+  const { data } = await supabase.rpc("logistics_consistency_check");
+Velden: agenda_carts, control_carts, raw_carts, delivery_carts, station_carts,
+sales_carts, announced_carts, orphan_tasks, ok.
+Is ok === false, toon een discrete melding en corrigeer niets zelf.
+
+CONTROLELIJST
+[ ] Verkoop, pick agenda, lever agenda, controle en picking station tonen hetzelfde aantal.
 [ ] Geen eigen kartelling meer in de verkoopcode.`,
             },
             {
@@ -471,31 +471,244 @@ CONTROLELIJST
                 title: "Stamgegevens voor indelen op afmetingen",
                 date: "2026-09-03",
                 summary: "Producten krijgen een fusttype en een planthoogte, zodat de Engine op fysieke afmetingen kan indelen.",
-                body: `AANVULLING op prompt 1 t/m 8 (die blijven geldig).
-
-WAT ER VERANDERT
-De Logistiek Engine kent één globale instelling "Methode voor karrenindeling":
-"belading" (huidig gedrag) of "afmetingen". Bij "afmetingen" rekent de Engine
-met echte maten en verzint hij niets.
-
-WAT JIJ BOUWT
-1. In het productbeheer twee velden tonen en opslaan op public.products:
-   - fust_type_id -> keuzelijst uit public.fust_types (naam tonen)
-   - plant_height_cm -> hoogte van de plant boven het fust, in centimeters
-   Beide mogen leeg blijven; ze zijn alleen nodig bij methode "afmetingen".
-2. Toon per product een discrete markering "afmetingen onvolledig" wanneer
-   fust_type_id of plant_height_cm leeg is. Geen standaardwaarde invullen.
-3. Verzin nooit maten en kopieer ze niet van een ander product.
-
-WAT JE NIET DOET
-- Geen keuze per order voor de indelingsmethode: die staat alleen in de Engine.
-- Geen eigen karrenberekening; de Engine blijft de enige bron.
-
-CONTROLELIJST
-[ ] Fusttype en planthoogte zijn per product in te vullen en op te slaan.
-[ ] Producten met ontbrekende maten zijn herkenbaar in de lijst.
+                body: `AANVULLING op prompt 1 t/m 8 (die blijven geldig).
+
+WAT ER VERANDERT
+De Logistiek Engine kent één globale instelling "Methode voor karrenindeling":
+"belading" (huidig gedrag) of "afmetingen". Bij "afmetingen" rekent de Engine
+met echte maten en verzint hij niets.
+
+WAT JIJ BOUWT
+1. In het productbeheer twee velden tonen en opslaan op public.products:
+   - fust_type_id -> keuzelijst uit public.fust_types (naam tonen)
+   - plant_height_cm -> hoogte van de plant boven het fust, in centimeters
+   Beide mogen leeg blijven; ze zijn alleen nodig bij methode "afmetingen".
+2. Toon per product een discrete markering "afmetingen onvolledig" wanneer
+   fust_type_id of plant_height_cm leeg is. Geen standaardwaarde invullen.
+3. Verzin nooit maten en kopieer ze niet van een ander product.
+
+WAT JE NIET DOET
+- Geen keuze per order voor de indelingsmethode: die staat alleen in de Engine.
+- Geen eigen karrenberekening; de Engine blijft de enige bron.
+
+CONTROLELIJST
+[ ] Fusttype en planthoogte zijn per product in te vullen en op te slaan.
+[ ] Producten met ontbrekende maten zijn herkenbaar in de lijst.
 [ ] Geen standaardwaardes of gekopieerde maten.`,
             },
+            {
+                number: 10,
+                title: "Gesloten orderbuffer neemt geen orders meer op",
+                date: "2026-09-03",
+                summary: "De Engine sluit een gecombineerde order op het ingestelde moment; daarna start een nieuwe combinatie.",
+                body: `AANVULLING op prompt 1 t/m 9 (die blijven geldig).
+
+WAT ER VERANDERT
+In de Rule Engine staat nu waar het sluitmoment vandaan komt: de aanmeldtijd of
+de start van het picken. Zodra dat moment is bereikt — of de order al richting
+het pickstation is — is de buffer gesloten. Een nieuwe order krijgt dan een
+nieuwe combinatie in plaats van de gesloten buffer.
+
+WAT JIJ BOUWT
+1. Toon per order het sluitmoment uit het bufferbesluit: velden bufferCloseAt,
+   closeBeforeMinutes en closeReference ("checkin" of "pick_start").
+2. Toon "Buffer gesloten" zodra bufferCloseAt is gepasseerd, en meld dat de order
+   in een nieuwe combinatie komt. Nooit zelf een order aan een gesloten buffer
+   toevoegen of het sluitmoment zelf berekenen.
+3. Blijf het besluit ophalen bij de Engine (logistics_buffer_decision of /decision).
+
+CONTROLELIJST
+[ ] Sluitmoment en de reden ervan zijn zichtbaar bij de order.
+[ ] Na sluiting komen nieuwe orders zichtbaar in een nieuwe combinatie.
+[ ] Geen eigen berekening van het sluitmoment.`,
+            },
+            {
+                number: 11,
+                title: "Afmetingen komen uit de Engine — handmatig invullen is optioneel",
+                date: "2026-09-03",
+                summary: "Fusttype en planthoogte leidt de Engine zelf af uit Floriday of uit de belading; Verkoop toont alleen de herkomst.",
+                body: `AANVULLING op prompt 1 t/m 10 (die blijven geldig). Dit vervangt de
+verplichting uit prompt 9: fusttype en planthoogte hoeven niet meer handmatig
+te worden ingevuld.
+
+WAT ER VERANDERT
+De Engine bepaalt de afmetingen per product zelf, in deze vaste volgorde:
+1. Handmatig ingevuld op het product (products.fust_type_id, products.plant_height_cm).
+2. Uit Floriday: verpakkingscode van het handelsitem -> fusttype; kenmerk S15
+   (transporthoogte), anders S02, als planthoogte.
+3. Afgeleid uit de belading: bruikbare hoogte van de ladingdrager gedeeld door
+   het aantal lagen per ladingdrager, min de fusthoogte.
+Levert geen van de drie een bruikbare waarde op, dan wordt die kar bewust niet
+ingedeeld en volgt een leesbare reden.
+
+WAT JIJ BOUWT
+1. Lees per product public.logistics_product_dimensions (alleen-lezen):
+   fust_type_id, fust_name, fust_length_mm, fust_width_mm, fust_height_mm,
+   plant_height_cm, fust_source, height_source, dimension_source, missing_reason.
+2. Toon bij het product de herkomst in gewone taal: "handmatig", "uit Floriday"
+   of "afgeleid uit de belading". Bij missing_reason die tekst letterlijk tonen.
+3. De velden fust_type_id en plant_height_cm blijven bestaan als handmatige
+   correctie, maar zijn niet langer verplicht en niet langer als waarschuwing
+   markeren zolang de Engine een waarde levert.
+
+WAT JE NIET DOET
+- Zelf een hoogte of fustmaat berekenen, afronden of kopiëren van een ander product.
+- De afgeleide hoogte wegschrijven naar products.plant_height_cm.
+- Een keuze per order voor de indelingsmethode; die staat alleen in de Engine.
+
+CONTROLELIJST
+[ ] Bij elk product is zichtbaar waar fust en planthoogte vandaan komen.
+[ ] Producten zonder bruikbare maten tonen de reden uit missing_reason.
+[ ] Geen eigen berekening en geen wegschrijven van afgeleide waarden.`,
+            },
+            {
+                number: 12,
+                title: "Laagindeling netjes tekenen — coördinaten één op één overnemen",
+                date: "2026-09-03",
+                summary: "De Engine levert niet-overlappende posities in millimeters; Verkoop schaalt ze alleen en draait niets meer zelf.",
+                body: `AANVULLING op prompt 1 t/m 11 (die blijven geldig).
+
+WAT ER VERANDERT
+De Engine legt de fusten nu per artikel in uitgelijnde rijen. De opgeslagen
+breedte en hoogte zijn al de daadwerkelijke maten in de gekozen stand; het veld
+rotation is daarom altijd 0. Alle posities liggen binnen de laag en overlappen
+nooit (gecontroleerd in de database).
+
+WAT JIJ BOUWT
+1. Lees public.order_cart_layer_positions per kar: layer, keg_id, x, y, width,
+   height, layer_width, layer_height, label, product_id, order_item_id.
+2. Teken per laag één rechthoek met vaste verhouding layer_width : layer_height
+   en plaats elk fust met factor = tekenbreedte / layer_width. Dus:
+   left = x * factor, top = y * factor, width = width * factor,
+   height = height * factor. Geen extra marges, geen eigen uitlijning.
+3. Draai NIETS meer: pas geen transform: rotate toe op basis van rotation.
+   Een gedraaid fust zit al in de opgeslagen breedte en hoogte.
+4. Rustige weergave: dunne rand, zachte vulkleur per product uit de eigen
+   designtokens, label alleen als het fust groot genoeg is, anders in een tooltip.
+   Lagen onder elkaar met een kop "Laag 1", "Laag 2", enzovoort.
+5. Zijn er voor een kar geen rijen, toon dan één korte melding met de reden uit
+   logistics_product_dimensions.missing_reason. Nooit een lege gekleurde kaart.
+
+WAT JE NIET DOET
+- Zelf posities berekenen, verschuiven, sorteren of fusten samenvoegen.
+- Rotatie of spiegeling toepassen.
+- Vaste pixelmaten of hardgecodeerde kleuren gebruiken.
+
+VEELGEMAAKTE FOUTEN (dit gaat nu mis in de weergave)
+- Elk fust als eigen blok in een verticale lijst of flex-kolom zetten. Daardoor
+  wordt één fust van 400x300 mm zo groot als de hele laag. Fusten zijn absoluut
+  gepositioneerde kinderen (position: absolute) van één laagvlak met
+  position: relative.
+- Een min-height, aspect-square, flex-1 of grid-rij op het fust zetten. De hoogte
+  komt uitsluitend uit height * factor.
+- Een eigen schaal per fust berekenen. Er is één factor per laag.
+- Reuzelabels: het label is klein en secundair, niet het grootste element in beeld.
+  Toon "F2" alleen als bijschrift, niet als display-tekst.
+- Het venster laten scrollen tot buiten beeld. Het laagvlak past binnen de
+  breedte van het venster; lagen staan onder elkaar met normale tussenruimte.
+
+MINIMALE STRUCTUUR
+<div style="position:relative;width:100%;aspect-ratio:{layer_width}/{layer_height}">
+  {posities.map(p => (
+    <div style="position:absolute;
+                left:{p.x/layer_width*100}%; top:{p.y/layer_height*100}%;
+                width:{p.width/layer_width*100}%; height:{p.height/layer_height*100}%" />
+  ))}
+</div>
+
+CONTROLELIJST
+[ ] Geen enkel fust overlapt of steekt buiten de laag.
+[ ] De laagverhouding klopt met layer_width en layer_height.
+[ ] Een laag met 25 fusten toont ook echt 25 kleine vakjes naast en onder elkaar.
+[ ] Labels zijn klein; het laagvlak is het grootste element.
+[ ] Karren zonder maten tonen één leesbare reden.`,
+            },
+            {
+                number: 13,
+                title: "Karnummer per order: cart_seq en cart_number tonen",
+                date: "2026-09-03",
+                summary: "Karnummers komen uit de Engine: toon cart_seq en cart_number, nooit cart_index, en reken zelf niets om.",
+                body: `AANVULLING op de eerdere prompts (die blijven geldig).
+
+WAT ER VERANDERT
+De Engine levert vanaf nu per kar een stabiel karnummer. Modules rekenen zelf
+NIETS meer om en hernummeren niet.
+
+VELDEN (uit de Engine-RPC's)
+- cart_seq  : stabiel, 1-gebaseerd volgnummer van de kar binnen zijn order.
+  Identiek aan het nummer op de pakbon in de verkoopmodule. Verandert niet als
+  karren op verschillende dagen gepickt of gecontroleerd worden, en niet als een
+  deel van de karren al is afgehandeld.
+- cart_number : het definitieve karnummer-label (bijv. het toegewezen
+  karnummer uit de karnummering). Toon dit als label.
+- cart_total  : het aantal karren van die order ("Kar X van Y" = cart_seq van
+  cart_total).
+- cart_index  : INTERN. Technische index, niet gedefinieerd als 0- of
+  1-gebaseerd. NOOIT tonen en nooit als basis voor eigen nummering gebruiken.
+
+WAAR STAAN DE VELDEN
+control_get_todays_carts(), logistics_pick_agenda(p_from, p_to) (per order in
+cartList), logistics_cart_index(p_from, p_to), logistics_control_scan_lookup(
+p_barcode) (cartSeq / cartNumber / cartTotal) en
+logistics_control_scan_overview(p_scanner_id, p_date).
+
+GEBRUIK IN DEZE MODULE
+Het nummer op de pakbon is cart_seq; het label is cart_number. Ditzelfde
+nummer zien alle andere modules.
+
+NIET DOEN
+- Niet zelf nummeren, sorteren op index, of +1 optellen bij cart_index.
+- Geen aparte nummering per dag, per pickronde of per controlesessie.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Elk karnummer in het scherm komt uit cart_seq / cart_number.
+[ ] "Kar X van Y" gebruikt cart_seq en cart_total.
+[ ] Een order met 4 karren toont 1 t/m 4, ook als er al karren afgehandeld zijn.
+[ ] Het getoonde nummer is gelijk aan het nummer op de pakbon.
+[ ] cart_index komt nergens in de weergave voor.`,
+            },
+            {
+                number: 14,
+                title: "Laagindeling alleen tonen bij indelen op afmetingen",
+                date: "2026-09-05",
+                summary: "Bij indelen op belading rekent de Engine geen fustposities uit; verberg dan de hele laagindeling in plaats van een lege kaart of melding.",
+                body: `AANVULLING op prompt 12 (die blijft geldig voor de tekening zelf).
+
+WAT ER VERANDERT
+De methode voor karrenindeling is een globale instelling van de Engine:
+- "Indelen op belading": de Engine berekent GEEN fustposities. Er is dus geen
+  laagindeling en die hoort ook niet in beeld te komen.
+- "Indelen op afmetingen": de Engine levert wel posities per laag en die worden
+  in deze module getoond zoals beschreven in prompt 12.
+
+WAT JIJ BOUWT
+1. Lees de methode op met de RPC public.logistics_cart_layout_method().
+   Die geeft { layoutMethod: 'belading' | 'afmetingen', showLayerLayout: boolean }.
+2. showLayerLayout = false → laat het hele blok "Laagindeling" weg: geen kaart,
+   geen tabs, geen melding "nog geen laagindeling". De rest van het orderdetail
+   blijft ongewijzigd.
+3. showLayerLayout = true → toon de laagindeling per kar uit
+   public.order_cart_layer_positions volgens prompt 12, en toon per kar zonder
+   posities één korte reden uit logistics_product_dimensions.missing_reason.
+4. Ververs de methode bij het openen van het scherm en na een wijziging in de
+   Engine-instellingen; cache hem niet langer dan de sessie.
+
+WAT JE NIET DOET
+- Zelf posities of laagverdelingen berekenen wanneer de Engine ze niet levert.
+- De laagindeling tonen op basis van alleen de aanwezigheid van rijen: bij
+  belading kunnen oude rijen zijn opgeruimd, de instelling is leidend.
+- Terugvallen op 'afmetingen' als de RPC faalt. Bij een fout: blok verbergen.
+
+NIET DOEN (algemeen)
+Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Bij "indelen op belading" is nergens een laagindeling of lege kaart zichtbaar.
+[ ] Bij "indelen op afmetingen" verschijnt de tekening met de posities van de Engine.
+[ ] Omschakelen van methode is na verversen direct zichtbaar.
+[ ] Bij een fout in de RPC blijft het blok verborgen, zonder foutmelding in beeld.`,
+            },
         ],
     },
     afhandeling: {
@@ -508,15 +721,15 @@ CONTROLELIJST
                 date: "2026-07-24",
                 summary: "Eigen beladings- en documentlogica eruit, taken uitvoeren.",
                 withSharedContract: true,
-                body: `Haal weg: eigen beladingindeling, eigen documentmomenten, eigen controle-instellingen.
-
-Consumeer deze taaktypes:
-- load.compose        payload: loadCarriers, fillMode (generated | manual_scan)
-- control.execute     payload: controlMode (paper), noticeAt
-- print.control_note  payload: printItems (control_note | control_note_and_shipping)
-- print.shipping_note payload: moment (with_packing_slip | with_control | after_control | after_scan)
-- transport.dispatch
-
+                body: `Haal weg: eigen beladingindeling, eigen documentmomenten, eigen controle-instellingen.
+
+Consumeer deze taaktypes:
+- load.compose        payload: loadCarriers, fillMode (generated | manual_scan)
+- control.execute     payload: controlMode (paper), noticeAt
+- print.control_note  payload: printItems (control_note | control_note_and_shipping)
+- print.shipping_note payload: moment (with_packing_slip | with_control | after_control | after_scan)
+- transport.dispatch
+
 Wat er geprint wordt en wanneer komt volledig uit de taak-payload. Geen eigen keuzes meer.`,
             },
             {
@@ -524,28 +737,28 @@ Wat er geprint wordt en wanneer komt volledig uit de taak-payload. Geen eigen ke
                 title: "Documentvrijgave komt volledig van de Engine",
                 date: "2026-08-03",
                 summary: "Pakbon, stickers, verzendbrief en productiebon alleen nog via Engine-taken.",
-                body: `Deze prompt vervangt niets uit prompt 1; hij komt er bovenop.
-
-Haal weg: elke eigen regel over wanneer een pakbon, sticker, verzendbrief of
-productiebon wordt vrijgegeven of geprint. De Logistics Engine beslist dit nu.
-
-Nieuwe taaktypes die je moet verwerken (tabel logistics_tasks):
-- print.packing_slip     payload: release (with_pick_release | hours_before_pick),
-                         pickStationId, pickStationTypeId, requiresApproval
-- print.sticker          payload: idem als print.packing_slip
-- print.shipping_note    payload: release (after_checkin | after_scan |
-                         with_packing_slip | manual_approval), pickStationId,
-                         pickStationTypeId, requiresApproval
-- print.production_note  payload: release (on_stock_upgrade |
-                         manual_approval_after_upgrade), trigger, pickStationId,
-                         pickStationTypeId, requiresApproval
-
-Regels:
-- planned_start van de taak is het vrijgavemoment. Nooit eerder printen.
-- pickStationId verwijst naar public.pick_stations.id; pickStationTypeId naar
-  public.pick_station_types.id. Stuur het document uitsluitend naar dat station.
-- requiresApproval = true: het document blijft in de wachtrij tot iemand het op
-  het pickstation goedkeurt. Meld de goedkeuring met logistics_complete_task.
+                body: `Deze prompt vervangt niets uit prompt 1; hij komt er bovenop.
+
+Haal weg: elke eigen regel over wanneer een pakbon, sticker, verzendbrief of
+productiebon wordt vrijgegeven of geprint. De Logistics Engine beslist dit nu.
+
+Nieuwe taaktypes die je moet verwerken (tabel logistics_tasks):
+- print.packing_slip     payload: release (with_pick_release | hours_before_pick),
+                         pickStationId, pickStationTypeId, requiresApproval
+- print.sticker          payload: idem als print.packing_slip
+- print.shipping_note    payload: release (after_checkin | after_scan |
+                         with_packing_slip | manual_approval), pickStationId,
+                         pickStationTypeId, requiresApproval
+- print.production_note  payload: release (on_stock_upgrade |
+                         manual_approval_after_upgrade), trigger, pickStationId,
+                         pickStationTypeId, requiresApproval
+
+Regels:
+- planned_start van de taak is het vrijgavemoment. Nooit eerder printen.
+- pickStationId verwijst naar public.pick_stations.id; pickStationTypeId naar
+  public.pick_station_types.id. Stuur het document uitsluitend naar dat station.
+- requiresApproval = true: het document blijft in de wachtrij tot iemand het op
+  het pickstation goedkeurt. Meld de goedkeuring met logistics_complete_task.
 - Is er geen taak voor een document, dan wordt dat document niet geprint.`,
             },
             {
@@ -553,53 +766,53 @@ Regels:
                 title: "Order- en karindeling altijd via de Logistics Engine",
                 date: "2026-08-04",
                 summary: "Nieuwe eis bovenop prompt 1 en 2: geen eigen indeling van orders en karren meer; stap 3 'Order picken' van de Rule Engine is leidend.",
-                body: `Deze prompt vervangt niets uit prompt 1 en 2; hij komt er bovenop.
-
-Geconstateerd probleem: deze module deelt orders en karren nog zelf in en houdt
-zich daardoor niet aan stap 3 "Order picken" van de Rule Engine. Dat moet stoppen.
-
-Haal weg: elke eigen berekening van
-- welke orders samen op één belading/kar komen,
-- hoeveel orders, klanten, lagen of dozen er op een drager passen,
-- wanneer er met picken gestart wordt,
-- of er met of zonder scanner gewerkt wordt.
-
-Zo werkt het vanaf nu:
-
-1) Vraag altijd eerst het besluit op voordat je iets indeelt:
-const { data: besluit } = await supabase.rpc("logistics_buffer_decision", {
-  p_order_ref: "SO-12345",
-  p_customer_ref: "CUST-1",
-  p_delivery_location_ref: "LOC-1",
-  p_checkin_at: "2026-08-01T10:00:00Z",
-  p_pickup_at: "2026-08-01T14:00:00Z",
-  p_load_carrier_type: "trolley",
-  p_strategy_id: null,
-});
-// besluit = { buffer, bufferRef, matchCriteria, release, trace }
-Deel de order uitsluitend in bij bufferRef. Is buffer=false, dan blijft de order
-los staan: nooit zelf alsnog samenvoegen.
-
-2) De feitelijke belading komt uit de taak load.compose in logistics_tasks
-   (owner_module = "afhandeling"). De payload bevat loadCarriers, fillMode
-   (generated | manual_scan) en de picksettings uit stap 3: pickMode,
-   pickStartMode, pickMinutes, staff, reserveMinutes, scanner.
-   - fillMode = generated: neem de indeling exact over zoals aangeleverd.
-   - fillMode = manual_scan: laat de medewerker scannen en meld het resultaat
-     terug; corrigeer de indeling niet zelf.
-   - scanner = required: geen afronding zonder scan.
-
-3) planned_start en planned_end van de taak zijn leidend voor het pickmoment.
-   Herbereken die nooit zelf, ook niet bij drukte.
-
-4) Is er nog geen load.compose taak voor een order, dan meld je dat met
-   logistics_emit_event (order.received of order.changed) en wacht je op de taak.
-   Zelf alvast indelen is niet toegestaan.
-
-5) Elke taak draagt rule_version. Rond een lopende belading altijd af op de
-   rule_version van de taak, ook als de Rule Engine intussen is gewijzigd.
-
-Meld afwijkingen terug met logistics_fail_task inclusief toelichting, zodat de
+                body: `Deze prompt vervangt niets uit prompt 1 en 2; hij komt er bovenop.
+
+Geconstateerd probleem: deze module deelt orders en karren nog zelf in en houdt
+zich daardoor niet aan stap 3 "Order picken" van de Rule Engine. Dat moet stoppen.
+
+Haal weg: elke eigen berekening van
+- welke orders samen op één belading/kar komen,
+- hoeveel orders, klanten, lagen of dozen er op een drager passen,
+- wanneer er met picken gestart wordt,
+- of er met of zonder scanner gewerkt wordt.
+
+Zo werkt het vanaf nu:
+
+1) Vraag altijd eerst het besluit op voordat je iets indeelt:
+const { data: besluit } = await supabase.rpc("logistics_buffer_decision", {
+  p_order_ref: "SO-12345",
+  p_customer_ref: "CUST-1",
+  p_delivery_location_ref: "LOC-1",
+  p_checkin_at: "2026-08-01T10:00:00Z",
+  p_pickup_at: "2026-08-01T14:00:00Z",
+  p_load_carrier_type: "trolley",
+  p_strategy_id: null,
+});
+// besluit = { buffer, bufferRef, matchCriteria, release, trace }
+Deel de order uitsluitend in bij bufferRef. Is buffer=false, dan blijft de order
+los staan: nooit zelf alsnog samenvoegen.
+
+2) De feitelijke belading komt uit de taak load.compose in logistics_tasks
+   (owner_module = "afhandeling"). De payload bevat loadCarriers, fillMode
+   (generated | manual_scan) en de picksettings uit stap 3: pickMode,
+   pickStartMode, pickMinutes, staff, reserveMinutes, scanner.
+   - fillMode = generated: neem de indeling exact over zoals aangeleverd.
+   - fillMode = manual_scan: laat de medewerker scannen en meld het resultaat
+     terug; corrigeer de indeling niet zelf.
+   - scanner = required: geen afronding zonder scan.
+
+3) planned_start en planned_end van de taak zijn leidend voor het pickmoment.
+   Herbereken die nooit zelf, ook niet bij drukte.
+
+4) Is er nog geen load.compose taak voor een order, dan meld je dat met
+   logistics_emit_event (order.received of order.changed) en wacht je op de taak.
+   Zelf alvast indelen is niet toegestaan.
+
+5) Elke taak draagt rule_version. Rond een lopende belading altijd af op de
+   rule_version van de taak, ook als de Rule Engine intussen is gewijzigd.
+
+Meld afwijkingen terug met logistics_fail_task inclusief toelichting, zodat de
 Engine kan herplannen. Val nooit terug op eigen logica.`,
             },
             {
@@ -607,50 +820,50 @@ Engine kan herplannen. Val nooit terug op eigen logica.`,
                 title: "Karren verdelen over meerdere ophaalmomenten",
                 date: "2026-08-04",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 4: de Engine verdeelt complete karren over de ophaalmomenten van een dag; deze module toont dat en verzet nooit zelf.",
-                body: `LEES DIT EERST — hoe je deze prompt uitvoert
-
-Alles uit prompt 1 t/m 4 blijft gelden. Hier komt er één ding bij: een dag kan
-MEERDERE ophaalmomenten hebben, en de Logistics Engine bepaalt welke kar bij
-welk ophaalmoment hoort. Jij rekent NIETS zelf uit en verplaatst NOOIT zelf een
-kar op basis van eigen logica.
-
-1) Ophaalmomenten lezen
-   Tabel: public.logistics_pickup_moments
-   Kolommen: id, moment_date, sequence, label, pickup_time, carrier_ref
-   Toon per dag de ophaalmomenten op volgorde van sequence/pickup_time.
-
-2) Karren per ophaalmoment
-   Tabel public.order_carts heeft nieuwe kolommen:
-   - pickup_moment_id      → bij welk ophaalmoment de kar hoort
-   - moved_from_moment_id  → het ophaalmoment waar de kar oorspronkelijk stond
-   - moved_reason          → 'capacity_shift' als de Engine hem doorschoof
-   - moved_at              → wanneer dat gebeurde
-   - pickup_locked         → true = deze kar mag NIET doorgeschoven worden
-
-   Groepeer de pickagenda en de leveringsplanning voortaan op pickup_moment_id,
-   niet meer alleen op de dag. Een kar met moved_reason = 'capacity_shift' toon
-   je met een duidelijk label "doorgeschoven vanaf <label vorig moment>".
-
-3) Regels die je moet respecteren
-   - Alleen COMPLETE karren wisselen van ophaalmoment. Splits nooit een kar en
-     verplaats nooit losse orderregels naar een ander moment.
-   - Karren uit een buffer mogen mee, maar alleen als geheel.
-   - Wil een gebruiker een kar vastzetten op een moment, zet dan
-     pickup_locked = true. Meer doe je niet; de Engine slaat die kar over.
-
-4) Herberekenen
-   Na elke wijziging die de planning raakt (nieuwe order, annulering, andere
-   ophaaltijd, andere kar-indeling) roep je aan:
-     await supabase.rpc("logistics_capacity_plan_day", { p_date: "2026-08-04" })
-   De functie geeft per ophaalmoment terug: requiredMinutes, availableMinutes,
-   feasible en movedCarts. Toon die uitkomst; verzin geen eigen berekening.
-
-5) Tekort tonen
-   Tabel public.logistics_capacity_alerts bevat per dag/ophaalmoment het tekort
-   (shortage_minutes, carts_short, moved_carts, unplanned_carts). Staat er een
-   rij met status = 'open', toon dan bij dat ophaalmoment een rode waarschuwing
-   met het tekort en het aantal karren dat niet op tijd verwerkt kan worden.
-
+                body: `LEES DIT EERST — hoe je deze prompt uitvoert
+
+Alles uit prompt 1 t/m 4 blijft gelden. Hier komt er één ding bij: een dag kan
+MEERDERE ophaalmomenten hebben, en de Logistics Engine bepaalt welke kar bij
+welk ophaalmoment hoort. Jij rekent NIETS zelf uit en verplaatst NOOIT zelf een
+kar op basis van eigen logica.
+
+1) Ophaalmomenten lezen
+   Tabel: public.logistics_pickup_moments
+   Kolommen: id, moment_date, sequence, label, pickup_time, carrier_ref
+   Toon per dag de ophaalmomenten op volgorde van sequence/pickup_time.
+
+2) Karren per ophaalmoment
+   Tabel public.order_carts heeft nieuwe kolommen:
+   - pickup_moment_id      → bij welk ophaalmoment de kar hoort
+   - moved_from_moment_id  → het ophaalmoment waar de kar oorspronkelijk stond
+   - moved_reason          → 'capacity_shift' als de Engine hem doorschoof
+   - moved_at              → wanneer dat gebeurde
+   - pickup_locked         → true = deze kar mag NIET doorgeschoven worden
+
+   Groepeer de pickagenda en de leveringsplanning voortaan op pickup_moment_id,
+   niet meer alleen op de dag. Een kar met moved_reason = 'capacity_shift' toon
+   je met een duidelijk label "doorgeschoven vanaf <label vorig moment>".
+
+3) Regels die je moet respecteren
+   - Alleen COMPLETE karren wisselen van ophaalmoment. Splits nooit een kar en
+     verplaats nooit losse orderregels naar een ander moment.
+   - Karren uit een buffer mogen mee, maar alleen als geheel.
+   - Wil een gebruiker een kar vastzetten op een moment, zet dan
+     pickup_locked = true. Meer doe je niet; de Engine slaat die kar over.
+
+4) Herberekenen
+   Na elke wijziging die de planning raakt (nieuwe order, annulering, andere
+   ophaaltijd, andere kar-indeling) roep je aan:
+     await supabase.rpc("logistics_capacity_plan_day", { p_date: "2026-08-04" })
+   De functie geeft per ophaalmoment terug: requiredMinutes, availableMinutes,
+   feasible en movedCarts. Toon die uitkomst; verzin geen eigen berekening.
+
+5) Tekort tonen
+   Tabel public.logistics_capacity_alerts bevat per dag/ophaalmoment het tekort
+   (shortage_minutes, carts_short, moved_carts, unplanned_carts). Staat er een
+   rij met status = 'open', toon dan bij dat ophaalmoment een rode waarschuwing
+   met het tekort en het aantal karren dat niet op tijd verwerkt kan worden.
+
 Val nooit terug op eigen logica. Wat de Engine teruggeeft, is leidend.`,
             },
             {
@@ -658,131 +871,131 @@ Val nooit terug op eigen logica. Wat de Engine teruggeeft, is leidend.`,
                 title: "Order handmatig verzetten en ophaaltijd wijzigen",
                 date: "2026-08-04",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 3: een medewerker mag een order handmatig naar een andere dag en/of ophaaltijd zetten, via twee vaste RPC's van de Engine.",
-                body: `LEES DIT EERST — hoe je deze prompt uitvoert
-
-Deze prompt beschrijft één nieuwe functie in de Afhandeling-module: "Order
-verzetten". Je bouwt hem volledig, niet gedeeltelijk. Alles wat hieronder staat
-is verplicht. Er is GEEN eigen rekenwerk: de Logistics Engine levert twee kant-en-
-klare database-functies, jij bouwt alleen het scherm eromheen en toont wat de
-Engine teruggeeft.
-
-Concreet ben je klaar als dit alle vier waar is:
-  1. Er is een knop "Verzetten" bij een order (planning-/agenda-/leverscherm).
-  2. Het dialoogvenster toont een DAGKEUZE en een OPHAALTIJD (van/tot).
-  3. Voor het opslaan is logistics_reschedule_preview aangeroepen en wordt de
-     uitkomst daarvan letterlijk aan de gebruiker getoond.
-  4. Opslaan gebeurt uitsluitend met logistics_reschedule_order.
-
-------------------------------------------------------------------
-DE TWEE REGELS DIE DE GEBRUIKER WIL
-------------------------------------------------------------------
-
-A. Order gaat NAAR VOREN (nieuwe ophaaldag is eerder dan de huidige)
-   -> Het AFLEVERMOMENT (leverdatum naar de klant) blijft ONGEWIJZIGD.
-      De order wordt dus eerder klaargemaakt en opgehaald, maar de klant krijgt
-      hem op dezelfde dag als afgesproken. Je verandert de leverdatum NIET.
-      Er gaat GEEN melding naar de klant.
-
-B. Order gaat NAAR ACHTEREN (nieuwe ophaaldag is later)
-   -> Het aflevermoment schuift mee.
-   -> De gebruiker MOET in het dialoogvenster de keuze krijgen:
-      "Klant informeren over de nieuwe leverdatum" (aan/uit) plus een reden.
-      Staat het aan, dan zorgt de Engine voor de klantmelding. Bouw daar zelf
-      geen mailflow voor.
-
-C. Alleen de OPHAALTIJD wijzigen (zelfde dag, andere van/tot-tijd) mag altijd
-   en geldt niet als verzetten: geen klantmelding, leverdatum blijft gelijk.
-
-------------------------------------------------------------------
-STAP 1 — VOORVERTONING (verplicht vóór opslaan)
-------------------------------------------------------------------
-const { data: preview } = await supabase.rpc("logistics_reschedule_preview", {
-  p_order_ref: "SO-12345",       // orders.order_number
-  p_pickup_date: "2026-08-07",   // nieuwe ophaaldag (YYYY-MM-DD), null = ongewijzigd
-  p_pickup_from: "06:00",        // nieuwe starttijd, null = ongewijzigd
-  p_pickup_to: "09:00",          // nieuwe eindtijd, null = ongewijzigd
-});
-
-preview bevat:
-{
-  ok: true,
-  orderRef, orderId, bufferId, planLocked,
-  current: { pickupDate, pickupFrom, pickupTo, deliveryDate },
-  next:    { pickupDate, pickupFrom, pickupTo, deliveryDate },
-  direction: "earlier" | "later" | "same",
-  dayShift: -2,                  // aantal dagen verschil
-  timeChanged: true,
-  keepDeliveryMoment: true,      // true bij naar voren: leverdatum blijft
-  customerNoticeRequired: true,  // true bij naar achteren: toon de klantoptie
-  affectedTasks: 8               // aantal taken dat opnieuw wordt ingepland
-}
-
-Wat je met deze velden DOET in het scherm:
-- ok === false -> toon preview.error en blokkeer opslaan.
-- direction === "earlier" -> toon: "Order wordt X dag(en) eerder opgehaald. Het
-  aflevermoment blijft {current.deliveryDate}." Verberg de klantoptie.
-- direction === "later" -> toon: "Order wordt X dag(en) later. Nieuwe leverdatum:
-  {next.deliveryDate}." Toon de schakelaar "Klant informeren" (standaard AAN) en
-  een verplicht redenveld.
-- direction === "same" && timeChanged -> toon alleen de nieuwe ophaaltijd.
-- Toon altijd affectedTasks: "X taken worden opnieuw ingepland."
-
-------------------------------------------------------------------
-STAP 2 — OPSLAAN
-------------------------------------------------------------------
-const { data: result } = await supabase.rpc("logistics_reschedule_order", {
-  p_order_ref: "SO-12345",
-  p_pickup_date: "2026-08-07",
-  p_pickup_from: "06:00",
-  p_pickup_to: "09:00",
-  p_notify_customer: true,        // alleen relevant bij direction "later"
-  p_reason: "Aanvoer bloemen vertraagd",
-  p_source_module: "afhandeling",
-  p_user_id: null,
-});
-// result = preview-velden + { applied: true, rescheduleId, delayAlertId,
-//                             customerNotified, pickupMoment }
-
-De Engine doet hierbij zelf al ALLES hieronder — doe dit dus niet nogmaals:
-- orders.custom_fields.pickup_moment bijwerken ("YYYY-MM-DD|van|tot");
-- leverdatum alleen aanpassen bij naar achteren;
-- de order uit zijn orderbuffer halen zodat hij niet aan de oude dag vastzit;
-- de klantmelding aanmaken als p_notify_customer true is;
-- een order.changed-melding sturen en de hele takenketen (buffer, pick, controle,
-  printen, transport) opnieuw inplannen met logistics_schedule_tasks;
-- het verzetten vastleggen in public.logistics_reschedules.
-
-------------------------------------------------------------------
-WAT JE ABSOLUUT NIET DOET
-------------------------------------------------------------------
-- Geen eigen UPDATE op orders, order_buffers, order_carts of logistics_tasks om
-  een datum of tijd te verzetten. Uitsluitend via de twee RPC's hierboven.
-- Zelf planned_start / planned_end / due_at van taken herberekenen. Na het
-  opslaan lees je de taken gewoon opnieuw; ze staan dan al goed.
-- Bij naar voren de leverdatum meeschuiven. Dat is expliciet fout.
-- Bij naar achteren de klant informeren zonder dat de gebruiker dat heeft
-  aangevinkt, of een eigen mail sturen buiten de Engine om.
-
-------------------------------------------------------------------
-NA HET OPSLAAN
-------------------------------------------------------------------
-1. Herlaad de taken van deze order uit logistics_tasks (planned_start bepaalt
-   waar de order in de pickagenda en het leverscherm verschijnt).
-2. Toon een bevestiging met de nieuwe ophaaldag, de ophaaltijd, de leverdatum en
-   of de klant is geïnformeerd (result.customerNotified).
-3. De verzetgeschiedenis kun je tonen met:
-   supabase.from("logistics_reschedules").select("*").eq("order_ref", ref)
-     .order("created_at", { ascending: false });
-
-------------------------------------------------------------------
-CONTROLELIJST VOOR JEZELF (loop deze af voor je klaar meldt)
-------------------------------------------------------------------
-[ ] Knop "Verzetten" bestaat bij een order.
-[ ] Dagkeuze én ophaaltijd van/tot zijn in te vullen.
-[ ] preview wordt live aangeroepen bij elke wijziging in het formulier.
-[ ] Naar voren: leverdatum ongewijzigd, geen klantoptie zichtbaar.
-[ ] Naar achteren: nieuwe leverdatum zichtbaar + klantoptie + reden.
-[ ] Opslaan gaat via logistics_reschedule_order, nergens een eigen UPDATE.
+                body: `LEES DIT EERST — hoe je deze prompt uitvoert
+
+Deze prompt beschrijft één nieuwe functie in de Afhandeling-module: "Order
+verzetten". Je bouwt hem volledig, niet gedeeltelijk. Alles wat hieronder staat
+is verplicht. Er is GEEN eigen rekenwerk: de Logistics Engine levert twee kant-en-
+klare database-functies, jij bouwt alleen het scherm eromheen en toont wat de
+Engine teruggeeft.
+
+Concreet ben je klaar als dit alle vier waar is:
+  1. Er is een knop "Verzetten" bij een order (planning-/agenda-/leverscherm).
+  2. Het dialoogvenster toont een DAGKEUZE en een OPHAALTIJD (van/tot).
+  3. Voor het opslaan is logistics_reschedule_preview aangeroepen en wordt de
+     uitkomst daarvan letterlijk aan de gebruiker getoond.
+  4. Opslaan gebeurt uitsluitend met logistics_reschedule_order.
+
+------------------------------------------------------------------
+DE TWEE REGELS DIE DE GEBRUIKER WIL
+------------------------------------------------------------------
+
+A. Order gaat NAAR VOREN (nieuwe ophaaldag is eerder dan de huidige)
+   -> Het AFLEVERMOMENT (leverdatum naar de klant) blijft ONGEWIJZIGD.
+      De order wordt dus eerder klaargemaakt en opgehaald, maar de klant krijgt
+      hem op dezelfde dag als afgesproken. Je verandert de leverdatum NIET.
+      Er gaat GEEN melding naar de klant.
+
+B. Order gaat NAAR ACHTEREN (nieuwe ophaaldag is later)
+   -> Het aflevermoment schuift mee.
+   -> De gebruiker MOET in het dialoogvenster de keuze krijgen:
+      "Klant informeren over de nieuwe leverdatum" (aan/uit) plus een reden.
+      Staat het aan, dan zorgt de Engine voor de klantmelding. Bouw daar zelf
+      geen mailflow voor.
+
+C. Alleen de OPHAALTIJD wijzigen (zelfde dag, andere van/tot-tijd) mag altijd
+   en geldt niet als verzetten: geen klantmelding, leverdatum blijft gelijk.
+
+------------------------------------------------------------------
+STAP 1 — VOORVERTONING (verplicht vóór opslaan)
+------------------------------------------------------------------
+const { data: preview } = await supabase.rpc("logistics_reschedule_preview", {
+  p_order_ref: "SO-12345",       // orders.order_number
+  p_pickup_date: "2026-08-07",   // nieuwe ophaaldag (YYYY-MM-DD), null = ongewijzigd
+  p_pickup_from: "06:00",        // nieuwe starttijd, null = ongewijzigd
+  p_pickup_to: "09:00",          // nieuwe eindtijd, null = ongewijzigd
+});
+
+preview bevat:
+{
+  ok: true,
+  orderRef, orderId, bufferId, planLocked,
+  current: { pickupDate, pickupFrom, pickupTo, deliveryDate },
+  next:    { pickupDate, pickupFrom, pickupTo, deliveryDate },
+  direction: "earlier" | "later" | "same",
+  dayShift: -2,                  // aantal dagen verschil
+  timeChanged: true,
+  keepDeliveryMoment: true,      // true bij naar voren: leverdatum blijft
+  customerNoticeRequired: true,  // true bij naar achteren: toon de klantoptie
+  affectedTasks: 8               // aantal taken dat opnieuw wordt ingepland
+}
+
+Wat je met deze velden DOET in het scherm:
+- ok === false -> toon preview.error en blokkeer opslaan.
+- direction === "earlier" -> toon: "Order wordt X dag(en) eerder opgehaald. Het
+  aflevermoment blijft {current.deliveryDate}." Verberg de klantoptie.
+- direction === "later" -> toon: "Order wordt X dag(en) later. Nieuwe leverdatum:
+  {next.deliveryDate}." Toon de schakelaar "Klant informeren" (standaard AAN) en
+  een verplicht redenveld.
+- direction === "same" && timeChanged -> toon alleen de nieuwe ophaaltijd.
+- Toon altijd affectedTasks: "X taken worden opnieuw ingepland."
+
+------------------------------------------------------------------
+STAP 2 — OPSLAAN
+------------------------------------------------------------------
+const { data: result } = await supabase.rpc("logistics_reschedule_order", {
+  p_order_ref: "SO-12345",
+  p_pickup_date: "2026-08-07",
+  p_pickup_from: "06:00",
+  p_pickup_to: "09:00",
+  p_notify_customer: true,        // alleen relevant bij direction "later"
+  p_reason: "Aanvoer bloemen vertraagd",
+  p_source_module: "afhandeling",
+  p_user_id: null,
+});
+// result = preview-velden + { applied: true, rescheduleId, delayAlertId,
+//                             customerNotified, pickupMoment }
+
+De Engine doet hierbij zelf al ALLES hieronder — doe dit dus niet nogmaals:
+- orders.custom_fields.pickup_moment bijwerken ("YYYY-MM-DD|van|tot");
+- leverdatum alleen aanpassen bij naar achteren;
+- de order uit zijn orderbuffer halen zodat hij niet aan de oude dag vastzit;
+- de klantmelding aanmaken als p_notify_customer true is;
+- een order.changed-melding sturen en de hele takenketen (buffer, pick, controle,
+  printen, transport) opnieuw inplannen met logistics_schedule_tasks;
+- het verzetten vastleggen in public.logistics_reschedules.
+
+------------------------------------------------------------------
+WAT JE ABSOLUUT NIET DOET
+------------------------------------------------------------------
+- Geen eigen UPDATE op orders, order_buffers, order_carts of logistics_tasks om
+  een datum of tijd te verzetten. Uitsluitend via de twee RPC's hierboven.
+- Zelf planned_start / planned_end / due_at van taken herberekenen. Na het
+  opslaan lees je de taken gewoon opnieuw; ze staan dan al goed.
+- Bij naar voren de leverdatum meeschuiven. Dat is expliciet fout.
+- Bij naar achteren de klant informeren zonder dat de gebruiker dat heeft
+  aangevinkt, of een eigen mail sturen buiten de Engine om.
+
+------------------------------------------------------------------
+NA HET OPSLAAN
+------------------------------------------------------------------
+1. Herlaad de taken van deze order uit logistics_tasks (planned_start bepaalt
+   waar de order in de pickagenda en het leverscherm verschijnt).
+2. Toon een bevestiging met de nieuwe ophaaldag, de ophaaltijd, de leverdatum en
+   of de klant is geïnformeerd (result.customerNotified).
+3. De verzetgeschiedenis kun je tonen met:
+   supabase.from("logistics_reschedules").select("*").eq("order_ref", ref)
+     .order("created_at", { ascending: false });
+
+------------------------------------------------------------------
+CONTROLELIJST VOOR JEZELF (loop deze af voor je klaar meldt)
+------------------------------------------------------------------
+[ ] Knop "Verzetten" bestaat bij een order.
+[ ] Dagkeuze én ophaaltijd van/tot zijn in te vullen.
+[ ] preview wordt live aangeroepen bij elke wijziging in het formulier.
+[ ] Naar voren: leverdatum ongewijzigd, geen klantoptie zichtbaar.
+[ ] Naar achteren: nieuwe leverdatum zichtbaar + klantoptie + reden.
+[ ] Opslaan gaat via logistics_reschedule_order, nergens een eigen UPDATE.
 [ ] Na opslaan worden de taken opnieuw geladen en klopt de agenda.`,
             },
             {
@@ -790,40 +1003,40 @@ CONTROLELIJST VOOR JEZELF (loop deze af voor je klaar meldt)
                 title: "Capaciteitswaarschuwing tonen in de pick agenda",
                 date: "2026-08-04",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 5: als er op een dag meer karren gepland staan dan er met het beschikbare personeel gepickt kunnen worden, moet de planning dat zichtbaar waarschuwen.",
-                body: `LEES DIT EERST
-
-De Logistics Engine rekent per pickdag uit hoeveel picktijd alle geplande karren
-kosten en hoeveel picktijd er beschikbaar is (aantal medewerkers x werktijden uit
-"4. Pickstations"). Jij rekent NIETS zelf uit; je toont alleen wat de Engine geeft.
-
-STAP 1 — BEREKENEN (bij het openen van een week/dag)
-const { data: dagen } = await supabase.rpc("logistics_capacity_day_check", {
-  p_from: "2026-08-03",   // eerste dag van de getoonde periode
-  p_to:   "2026-08-09",   // laatste dag
-});
-
-dagen is een array met per dag:
-{ date, carts, requiredMinutes, availableMinutes, shortageMinutes, staff }
-
-STAP 2 — OPEN WAARSCHUWINGEN LEZEN
-const { data: alerts } = await supabase
-  .from("logistics_capacity_alerts")
-  .select("plan_date, required_minutes, available_minutes, shortage_minutes, carts_total, carts_short")
-  .eq("status", "open");
-
-STAP 3 — TONEN (verplicht)
-- Weekoverzicht: elke dag met shortageMinutes > 0 krijgt een duidelijk zichtbare
-  waarschuwing (amber/rood) met de tekst:
-  "Te weinig capaciteit: {carts} karren vragen {requiredMinutes} min picktijd,
-   beschikbaar is {availableMinutes} min ({staff} medewerkers).
-   Circa {carts_short} karren passen niet op deze dag."
-- Dagdetails: dezelfde waarschuwing bovenaan het dagscherm.
-- Dagen zonder tekort krijgen GEEN waarschuwing.
-- Verzin geen eigen drempels, kleuren-logica of eigen berekening van picktijd.
-
-CONTROLELIJST
-[ ] logistics_capacity_day_check wordt aangeroepen bij elke periodewissel.
-[ ] Dagen met tekort tonen de waarschuwing in het weekoverzicht én in dagdetails.
+                body: `LEES DIT EERST
+
+De Logistics Engine rekent per pickdag uit hoeveel picktijd alle geplande karren
+kosten en hoeveel picktijd er beschikbaar is (aantal medewerkers x werktijden uit
+"4. Pickstations"). Jij rekent NIETS zelf uit; je toont alleen wat de Engine geeft.
+
+STAP 1 — BEREKENEN (bij het openen van een week/dag)
+const { data: dagen } = await supabase.rpc("logistics_capacity_day_check", {
+  p_from: "2026-08-03",   // eerste dag van de getoonde periode
+  p_to:   "2026-08-09",   // laatste dag
+});
+
+dagen is een array met per dag:
+{ date, carts, requiredMinutes, availableMinutes, shortageMinutes, staff }
+
+STAP 2 — OPEN WAARSCHUWINGEN LEZEN
+const { data: alerts } = await supabase
+  .from("logistics_capacity_alerts")
+  .select("plan_date, required_minutes, available_minutes, shortage_minutes, carts_total, carts_short")
+  .eq("status", "open");
+
+STAP 3 — TONEN (verplicht)
+- Weekoverzicht: elke dag met shortageMinutes > 0 krijgt een duidelijk zichtbare
+  waarschuwing (amber/rood) met de tekst:
+  "Te weinig capaciteit: {carts} karren vragen {requiredMinutes} min picktijd,
+   beschikbaar is {availableMinutes} min ({staff} medewerkers).
+   Circa {carts_short} karren passen niet op deze dag."
+- Dagdetails: dezelfde waarschuwing bovenaan het dagscherm.
+- Dagen zonder tekort krijgen GEEN waarschuwing.
+- Verzin geen eigen drempels, kleuren-logica of eigen berekening van picktijd.
+
+CONTROLELIJST
+[ ] logistics_capacity_day_check wordt aangeroepen bij elke periodewissel.
+[ ] Dagen met tekort tonen de waarschuwing in het weekoverzicht én in dagdetails.
 [ ] De getoonde cijfers komen letterlijk uit de Engine.`,
             },
             {
@@ -831,31 +1044,31 @@ CONTROLELIJST
                 title: "Geen capaciteitsmeldingen in Planning en leveringen",
                 date: "2026-08-04",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 6: verwijder alle capaciteits- en foutmeldingen uit de agenda Planning en leveringen; de Engine blijft op de achtergrond controleren.",
-                body: `AANVULLING op prompt 1 t/m 6. Deze nieuwste eis vervangt uitsluitend de
-zichtbare meldingen uit prompt 5 en 6 binnen het scherm "Planning en leveringen".
-
-Verwijder uit het weekoverzicht en de dagdetails van "Planning en leveringen":
-- de melding "Te weinig capaciteit";
-- aantallen tekortkomende minuten, medewerkers of karren;
-- rode, amberkleurige of andere fout-/waarschuwingsblokken uit
-  public.logistics_capacity_alerts;
-- foutmeldingen die afkomstig zijn van logistics_capacity_day_check.
-
-De agenda toont alleen de planning, bestellingen, karren, planten en statussen.
-Een tekort mag de agenda niet visueel blokkeren of als foutmelding worden getoond.
-
-BELANGRIJK — alleen de zichtbaarheid vervalt:
-- Blijf logistics_capacity_day_check en logistics_capacity_plan_day uitvoeren waar
-  dat nodig is voor de planning en automatische herverdeling.
-- Verwijder of sluit public.logistics_capacity_alerts niet.
-- Capaciteitsmeldingen blijven beschikbaar in het Regieoverzicht van de Logistics
-  Engine en in het centrale Meldingencentrum.
-- Verberg echte technische fouten niet: een mislukte laad- of opslagactie mag nog
-  steeds via een normale toast worden gemeld, maar niet als melding in de agenda.
-
-CONTROLELIJST
-[ ] In Planning en leveringen staat bij geen enkele dag een capaciteitsmelding.
-[ ] Het openen en wisselen van weken blijft de Engine-berekening uitvoeren.
+                body: `AANVULLING op prompt 1 t/m 6. Deze nieuwste eis vervangt uitsluitend de
+zichtbare meldingen uit prompt 5 en 6 binnen het scherm "Planning en leveringen".
+
+Verwijder uit het weekoverzicht en de dagdetails van "Planning en leveringen":
+- de melding "Te weinig capaciteit";
+- aantallen tekortkomende minuten, medewerkers of karren;
+- rode, amberkleurige of andere fout-/waarschuwingsblokken uit
+  public.logistics_capacity_alerts;
+- foutmeldingen die afkomstig zijn van logistics_capacity_day_check.
+
+De agenda toont alleen de planning, bestellingen, karren, planten en statussen.
+Een tekort mag de agenda niet visueel blokkeren of als foutmelding worden getoond.
+
+BELANGRIJK — alleen de zichtbaarheid vervalt:
+- Blijf logistics_capacity_day_check en logistics_capacity_plan_day uitvoeren waar
+  dat nodig is voor de planning en automatische herverdeling.
+- Verwijder of sluit public.logistics_capacity_alerts niet.
+- Capaciteitsmeldingen blijven beschikbaar in het Regieoverzicht van de Logistics
+  Engine en in het centrale Meldingencentrum.
+- Verberg echte technische fouten niet: een mislukte laad- of opslagactie mag nog
+  steeds via een normale toast worden gemeld, maar niet als melding in de agenda.
+
+CONTROLELIJST
+[ ] In Planning en leveringen staat bij geen enkele dag een capaciteitsmelding.
+[ ] Het openen en wisselen van weken blijft de Engine-berekening uitvoeren.
 [ ] Het Regieoverzicht kan de capaciteitsmeldingen nog steeds tonen.`,
             },
             {
@@ -863,28 +1076,28 @@ CONTROLELIJST
                 title: "Tekort in medewerkers tonen in de capaciteitswaarschuwing",
                 date: "2026-08-04",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 7: elke capaciteitswaarschuwing vermeldt hoeveel medewerkers er tekort zijn, niet alleen minuten en karren.",
-                body: `AANVULLING op prompt 6. De waarschuwing blijft weg uit "Planning en
-leveringen" (prompt 7); overal waar je hem WEL toont (Regieoverzicht,
-Meldingencentrum, dagdetails buiten de agenda) geldt onderstaande tekst.
-
-BEREKENING (verplicht, geen eigen variant)
-minutenPerMedewerker = availableMinutes / staff      // staff > 0
-medewerkersTekort    = Math.ceil(shortageMinutes / minutenPerMedewerker)
-Is staff 0 of availableMinutes 0, toon dan geen aantal maar de tekst
-"vul het gemiddeld aantal medewerkers in bij 3. Order picken".
-
-TEKST
-"Te weinig capaciteit: {carts} karren vragen {requiredMinutes} min picktijd,
- beschikbaar is {availableMinutes} min ({staff} medewerkers).
- Je komt {medewerkersTekort} medewerker(s) tekort — samen
- {staff + medewerkersTekort} nodig. Circa {carts_short} karren passen niet
- op deze dag."
-
-Gebruik enkelvoud "medewerker" bij 1, anders "medewerkers".
-
-CONTROLELIJST
-[ ] Elke zichtbare capaciteitswaarschuwing noemt het tekort in medewerkers.
-[ ] Het aantal komt uit de formule hierboven, niet uit een eigen aanname.
+                body: `AANVULLING op prompt 6. De waarschuwing blijft weg uit "Planning en
+leveringen" (prompt 7); overal waar je hem WEL toont (Regieoverzicht,
+Meldingencentrum, dagdetails buiten de agenda) geldt onderstaande tekst.
+
+BEREKENING (verplicht, geen eigen variant)
+minutenPerMedewerker = availableMinutes / staff      // staff > 0
+medewerkersTekort    = Math.ceil(shortageMinutes / minutenPerMedewerker)
+Is staff 0 of availableMinutes 0, toon dan geen aantal maar de tekst
+"vul het gemiddeld aantal medewerkers in bij 3. Order picken".
+
+TEKST
+"Te weinig capaciteit: {carts} karren vragen {requiredMinutes} min picktijd,
+ beschikbaar is {availableMinutes} min ({staff} medewerkers).
+ Je komt {medewerkersTekort} medewerker(s) tekort — samen
+ {staff + medewerkersTekort} nodig. Circa {carts_short} karren passen niet
+ op deze dag."
+
+Gebruik enkelvoud "medewerker" bij 1, anders "medewerkers".
+
+CONTROLELIJST
+[ ] Elke zichtbare capaciteitswaarschuwing noemt het tekort in medewerkers.
+[ ] Het aantal komt uit de formule hierboven, niet uit een eigen aanname.
 [ ] Zonder ingevuld personeel toont de melding de invulhint in plaats van 0.`,
             },
             {
@@ -893,23 +1106,23 @@ CONTROLELIJST
                 date: "2026-08-19",
                 summary: "Nieuwe orders worden binnen seconden automatisch ingedeeld door de Engine.",
                 withSharedContract: false,
-                body: `De Logistics Engine deelt nieuwe en gewijzigde orders voortaan automatisch in.
-Een order komt bij binnenkomst in de wachtrij public.logistics_plan_queue en wordt
-direct verwerkt (doorgaans binnen enkele seconden, uiterlijk binnen 2 minuten).
-
-REGELS
-- Deel NOOIT zelf orders in en maak geen eigen taken aan als er nog geen indeling is.
-- Toon de melding "wacht op een indeling van de Logistics Engine" pas als de order
-  langer dan 2 minuten geleden is aangemaakt/gewijzigd EN er nog geen taken zijn.
-  Binnen die marge toon je niets — dat is normale verwerkingstijd.
-- Ververs de weergave automatisch (realtime of polling) zodra taken verschijnen,
-  zodat de gebruiker niets hoeft te doen.
-- Reserveringen (orders.is_reservation = true) en vastgezette orders
-  (orders.plan_locked_at gevuld) tel je nooit mee in deze melding.
-
-CONTROLELIJST
-[ ] Geen melding binnen 2 minuten na aanmaken/wijzigen van een order.
-[ ] Geen eigen indeling of eigen taken als fallback.
+                body: `De Logistics Engine deelt nieuwe en gewijzigde orders voortaan automatisch in.
+Een order komt bij binnenkomst in de wachtrij public.logistics_plan_queue en wordt
+direct verwerkt (doorgaans binnen enkele seconden, uiterlijk binnen 2 minuten).
+
+REGELS
+- Deel NOOIT zelf orders in en maak geen eigen taken aan als er nog geen indeling is.
+- Toon de melding "wacht op een indeling van de Logistics Engine" pas als de order
+  langer dan 2 minuten geleden is aangemaakt/gewijzigd EN er nog geen taken zijn.
+  Binnen die marge toon je niets — dat is normale verwerkingstijd.
+- Ververs de weergave automatisch (realtime of polling) zodra taken verschijnen,
+  zodat de gebruiker niets hoeft te doen.
+- Reserveringen (orders.is_reservation = true) en vastgezette orders
+  (orders.plan_locked_at gevuld) tel je nooit mee in deze melding.
+
+CONTROLELIJST
+[ ] Geen melding binnen 2 minuten na aanmaken/wijzigen van een order.
+[ ] Geen eigen indeling of eigen taken als fallback.
 [ ] Weergave werkt bij zonder handmatig verversen.`,
             },
             {
@@ -917,72 +1130,72 @@ CONTROLELIJST
                 title: "Instellingen opschonen: planning en printen komen van de Engine/Layout maker",
                 date: "2026-08-27",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 9: de settingscard 'Afhandeling — Planning' wordt opgeruimd.",
-                body: `AANVULLING op prompt 1 t/m 9 (die blijven gewoon geldig).
-
-De settingscard "Afhandeling — Planning" bevat een aantal velden die inmiddels
-worden bepaald door de Logistics Engine of de Layout maker. Deze module mag die
-velden niet meer zelf uitlezen of tonen.
-
-Haal weg uit de settingscard en bijbehorende schermen:
-
-1. "Aantal pickdagen (werkdagen vóór ophaaldag)"
-2. "Extra pickdagen bij stickers"
-3. "Orderpickdagen (werkdagen)"
-4. "Pickverdeling over werkdagen"
-5. "Automatische Floriday-verwerking pauzeren"
-6. "Afleverbrief automatisch printen"
-7. "Werkplek (voor printen)"
-
-Waarom deze velden overbodig zijn:
-- Aantal pickdagen, extra pickdagen, orderpickdagen en pickverdeling worden
-  volledig bepaald door de Logistics Engine (stap 3 "Order picken" en
-  ophaalmomenten). De Engine plant planned_start en planned_end per taak.
-- "Automatische Floriday-verwerking pauzeren" heeft geen lezer meer in deze
-  module.
-- "Afleverbrief automatisch printen" is geen printerkeuze maar een trigger.
-  De Logistics Engine neemt die trigger over: Afhandeling maakt zelf geen
-  printopdrachten meer aan voor afleverbrieven, maar consumeert
-  print.shipping_note-taken uit public.logistics_tasks. De Engine bepaalt of
-  en wanneer een afleverbrief wordt vrijgegeven voor printen.
-- "Werkplek (voor printen)" is overbodig omdat locatiegebonden printen het
-  domein is van de Logistics Engine (via print_plek_id in de taak-payload).
-  Zonder werkplek en zonder print_plek_id valt de Layout maker terug op de
-  standaardlayout of standaardregels voor documenttype "afleverbrief".
-
-Printer-beslisvolgorde in de Layout maker:
-
-    1. printer_id op de opdracht (expliciet meegegeven)
-    2. print_plek_id -> regel van de printplek
-    3. werkplek      -> printplek van die computer, dan werkplek-uitzondering
-    4. printer gekoppeld aan de (standaard)layout van het documenttype
-    5. standaardregel: documenttype + papierformaat
-    6. standaardregel: documenttype alleen
-
-Zonder werkplek en zonder print_plek_id slaat een afleverbrief-print stap 1-3
-over en komt hij op de printer van de standaardlayout of de standaardregels
-uit. Wil men locatiegebonden printen, dan moet dat via de Logistics Engine
-(print_plek_id) of een expliciete printer_id op de opdracht.
-
-Wat blijft staan:
-- "Aanmeldmail vervoerders" (+ minuten vóór aanmelddeadline en e-mail-doeleinde)
-  blijft bestaan. Dat is eigen functionaliteit van de Afhandeling-module.
-
-Voorwaarde:
-Er moet minstens één printer voor documenttype "afleverbrief" zijn ingesteld
-in de Layout maker: hetzij aan de standaardlayout, hetzij via
-Layouts en printers -> Standaardregels. Ontbreekt die, dan mislukt de
-automatische print met de leesbare foutmelding:
-"Geen printer voor afleverbrief — stel dit in bij Layouts en printers → Routering".
-
-Database:
-- Droppen geen kolommen of rijen. De kolommen in afhandeling_settings blijven
-  staan, maar worden niet meer gelezen of getoond.
-
-CONTROLELIJST
-[ ] Alle zeven velden zijn verwijderd uit de settingscard.
-[ ] Aanmeldmail-instellingen zijn nog zichtbaar en werken nog.
-[ ] Er worden geen eigen planningsberekeningen meer gedaan; alles komt uit public.logistics_tasks.
-[ ] Afleverbrieven worden alleen nog aangemaakt via print.shipping_note-taken, niet spontaan.
+                body: `AANVULLING op prompt 1 t/m 9 (die blijven gewoon geldig).
+
+De settingscard "Afhandeling — Planning" bevat een aantal velden die inmiddels
+worden bepaald door de Logistics Engine of de Layout maker. Deze module mag die
+velden niet meer zelf uitlezen of tonen.
+
+Haal weg uit de settingscard en bijbehorende schermen:
+
+1. "Aantal pickdagen (werkdagen vóór ophaaldag)"
+2. "Extra pickdagen bij stickers"
+3. "Orderpickdagen (werkdagen)"
+4. "Pickverdeling over werkdagen"
+5. "Automatische Floriday-verwerking pauzeren"
+6. "Afleverbrief automatisch printen"
+7. "Werkplek (voor printen)"
+
+Waarom deze velden overbodig zijn:
+- Aantal pickdagen, extra pickdagen, orderpickdagen en pickverdeling worden
+  volledig bepaald door de Logistics Engine (stap 3 "Order picken" en
+  ophaalmomenten). De Engine plant planned_start en planned_end per taak.
+- "Automatische Floriday-verwerking pauzeren" heeft geen lezer meer in deze
+  module.
+- "Afleverbrief automatisch printen" is geen printerkeuze maar een trigger.
+  De Logistics Engine neemt die trigger over: Afhandeling maakt zelf geen
+  printopdrachten meer aan voor afleverbrieven, maar consumeert
+  print.shipping_note-taken uit public.logistics_tasks. De Engine bepaalt of
+  en wanneer een afleverbrief wordt vrijgegeven voor printen.
+- "Werkplek (voor printen)" is overbodig omdat locatiegebonden printen het
+  domein is van de Logistics Engine (via print_plek_id in de taak-payload).
+  Zonder werkplek en zonder print_plek_id valt de Layout maker terug op de
+  standaardlayout of standaardregels voor documenttype "afleverbrief".
+
+Printer-beslisvolgorde in de Layout maker:
+
+    1. printer_id op de opdracht (expliciet meegegeven)
+    2. print_plek_id -> regel van de printplek
+    3. werkplek      -> printplek van die computer, dan werkplek-uitzondering
+    4. printer gekoppeld aan de (standaard)layout van het documenttype
+    5. standaardregel: documenttype + papierformaat
+    6. standaardregel: documenttype alleen
+
+Zonder werkplek en zonder print_plek_id slaat een afleverbrief-print stap 1-3
+over en komt hij op de printer van de standaardlayout of de standaardregels
+uit. Wil men locatiegebonden printen, dan moet dat via de Logistics Engine
+(print_plek_id) of een expliciete printer_id op de opdracht.
+
+Wat blijft staan:
+- "Aanmeldmail vervoerders" (+ minuten vóór aanmelddeadline en e-mail-doeleinde)
+  blijft bestaan. Dat is eigen functionaliteit van de Afhandeling-module.
+
+Voorwaarde:
+Er moet minstens één printer voor documenttype "afleverbrief" zijn ingesteld
+in de Layout maker: hetzij aan de standaardlayout, hetzij via
+Layouts en printers -> Standaardregels. Ontbreekt die, dan mislukt de
+automatische print met de leesbare foutmelding:
+"Geen printer voor afleverbrief — stel dit in bij Layouts en printers → Routering".
+
+Database:
+- Droppen geen kolommen of rijen. De kolommen in afhandeling_settings blijven
+  staan, maar worden niet meer gelezen of getoond.
+
+CONTROLELIJST
+[ ] Alle zeven velden zijn verwijderd uit de settingscard.
+[ ] Aanmeldmail-instellingen zijn nog zichtbaar en werken nog.
+[ ] Er worden geen eigen planningsberekeningen meer gedaan; alles komt uit public.logistics_tasks.
+[ ] Afleverbrieven worden alleen nog aangemaakt via print.shipping_note-taken, niet spontaan.
 [ ] De kolommen in afhandeling_settings zijn niet gedropt.`,
             },
             {
@@ -990,51 +1203,51 @@ CONTROLELIJST
                 title: "Controle karren rechtstreeks uit de agenda van de Engine",
                 date: "2026-09-01",
                 summary: "De controlepagina toont alle karren van de pickagenda van vandaag, inclusief gemengde, ongeprinte en nog niet ingedeelde karren.",
-                body: `AANVULLING op prompt 1 t/m 10 (die blijven geldig).
-
-GEMETEN PROBLEEM
-Het scherm "Controle karren" blijft leeg doordat cartControl.functions.ts zelf
-alleen logistics_tasks van type load.compose leest, met owner_module =
-"afhandeling" en een beperkte statuslijst. De pickagenda wordt echter bepaald
-door pick.execute. Daardoor kan de agenda wel orders tonen terwijl de controlelijst
-0 karren toont.
-
-BOUW DIT
-- Verwijder loadEngineCartsForToday en de lokale datum-/taakfilter als bron voor
-  de controlelijst.
-- Laat getTodaysControlCarts rechtstreeks deze RPC aanroepen:
-
-  const { data, error } = await supabase.rpc("control_get_todays_carts");
-  if (error) throw new Error(error.message);
-
-- Map iedere RPC-rij naar ControlCart. Gebruik cart_number_id als stabiele sleutel,
-  order_id, order_source, cart_index, pick_date, status, printed_at en
-  printed_today letterlijk uit het resultaat.
-- De RPC is de enige bron voor welke karren vandaag zichtbaar zijn. Voeg in de
-  frontend geen extra filter toe op load.compose, owner_module, taskstatus,
-  orderstatus of printedCount.
-- De RPC bevat bewust:
-  1. alle pick.execute-taken met planned_start vandaag in Europe/Amsterdam;
-  2. alle orders die vandaag zijn aangemeld of uitgeprint;
-  3. normale én gemengde karren via order_cart_items -> order_items;
-  4. tijdelijke regels voor agenda-orders die nog geen order_carts hebben.
-- Gebruik printed_today voor de kolom "Uitgeprint". Een kar hoeft niet geprint te
-  zijn om zichtbaar en goed te keuren te zijn.
-- Ververs bij wijzigingen in logistics_tasks, pick_queue, print_jobs, order_carts,
-  order_cart_items en cart_numbers, plus de bestaande polling.
-- Gebruik dezelfde RPC-uitkomst ook als basis voor submitControlSession, zodat de
-  getoonde en afgemelde verzameling nooit van elkaar afwijkt.
-
-NIET DOEN
-- Niet terugvallen op loadTodaysPickstationOrders als de RPC nul regels geeft.
-- Niet zelf kar-aantallen herberekenen.
-- Geen project-ref, Supabase-URL of datum hardcoden.
-
-CONTROLELIJST
-[ ] Een ongeprinte kar op de pickagenda van vandaag staat in Controle karren.
-[ ] Een vandaag geprinte kar met een oudere pickdatum blijft zichtbaar.
-[ ] Een gemengde kar verschijnt zonder dubbele regels.
-[ ] De teller en tabel gebruiken exact dezelfde RPC-data.
+                body: `AANVULLING op prompt 1 t/m 10 (die blijven geldig).
+
+GEMETEN PROBLEEM
+Het scherm "Controle karren" blijft leeg doordat cartControl.functions.ts zelf
+alleen logistics_tasks van type load.compose leest, met owner_module =
+"afhandeling" en een beperkte statuslijst. De pickagenda wordt echter bepaald
+door pick.execute. Daardoor kan de agenda wel orders tonen terwijl de controlelijst
+0 karren toont.
+
+BOUW DIT
+- Verwijder loadEngineCartsForToday en de lokale datum-/taakfilter als bron voor
+  de controlelijst.
+- Laat getTodaysControlCarts rechtstreeks deze RPC aanroepen:
+
+  const { data, error } = await supabase.rpc("control_get_todays_carts");
+  if (error) throw new Error(error.message);
+
+- Map iedere RPC-rij naar ControlCart. Gebruik cart_number_id als stabiele sleutel,
+  order_id, order_source, cart_index, pick_date, status, printed_at en
+  printed_today letterlijk uit het resultaat.
+- De RPC is de enige bron voor welke karren vandaag zichtbaar zijn. Voeg in de
+  frontend geen extra filter toe op load.compose, owner_module, taskstatus,
+  orderstatus of printedCount.
+- De RPC bevat bewust:
+  1. alle pick.execute-taken met planned_start vandaag in Europe/Amsterdam;
+  2. alle orders die vandaag zijn aangemeld of uitgeprint;
+  3. normale én gemengde karren via order_cart_items -> order_items;
+  4. tijdelijke regels voor agenda-orders die nog geen order_carts hebben.
+- Gebruik printed_today voor de kolom "Uitgeprint". Een kar hoeft niet geprint te
+  zijn om zichtbaar en goed te keuren te zijn.
+- Ververs bij wijzigingen in logistics_tasks, pick_queue, print_jobs, order_carts,
+  order_cart_items en cart_numbers, plus de bestaande polling.
+- Gebruik dezelfde RPC-uitkomst ook als basis voor submitControlSession, zodat de
+  getoonde en afgemelde verzameling nooit van elkaar afwijkt.
+
+NIET DOEN
+- Niet terugvallen op loadTodaysPickstationOrders als de RPC nul regels geeft.
+- Niet zelf kar-aantallen herberekenen.
+- Geen project-ref, Supabase-URL of datum hardcoden.
+
+CONTROLELIJST
+[ ] Een ongeprinte kar op de pickagenda van vandaag staat in Controle karren.
+[ ] Een vandaag geprinte kar met een oudere pickdatum blijft zichtbaar.
+[ ] Een gemengde kar verschijnt zonder dubbele regels.
+[ ] De teller en tabel gebruiken exact dezelfde RPC-data.
 [ ] Goedkeuren verwerkt exact de zichtbare verzameling.`,
             },
             {
@@ -1042,50 +1255,50 @@ CONTROLELIJST
                 title: "Pick agenda: nooit een pickdag in het verleden",
                 date: "2026-09-01",
                 summary: "De weekagenda leest de pickdagen uit de Engine; orders met een verstreken pickmoment staan automatisch op vandaag.",
-                body: `AANVULLING op prompt 1 t/m 11 (die blijven geldig).
-
-GEMETEN PROBLEEM
-De weekagenda toont orders op maandag 31 aug terwijl het dinsdag 1 sep is. In
-public.logistics_tasks staat geen enkele open pick.execute-taak in het verleden:
-de Engine klemt planned_start al op nu. De agenda rekent dus nog zelf een pickdag
-uit (delivery_date minus pick_days), en die kan in het verleden liggen.
-
-BOUW DIT
-- Verwijder de eigen pickdagberekening uit de weekagenda (delivery_date,
-  pick_days_before_transport, max_workdays_earlier_pick, pick_weekdays).
-- Haal de agenda op met:
-
-  const { data, error } = await supabase.rpc("logistics_pick_agenda", {
-    p_from: weekStartIso, // yyyy-mm-dd
-    p_to: weekEndIso,
-  });
-  if (error) throw new Error(error.message);
-  const dagen = Array.isArray(data) ? data : [];
-
-- Kolommen per dag: pick_date, order_count, cart_count, plant_count,
-  in_preparation, ready, shifted_count, orders (jsonb array met taskId, orderRef,
-  status, carts, plants, shifted).
-- Vul de tegels "bestellingen", "karren" en "planten" met order_count, cart_count
-  en plant_count. "In voorbereiding" = in_preparation, "Verzendklaar" = ready.
-- Toon bij shifted_count > 0 op die dag het label "te laat aangemeld" (zelfde
-  betekenis als in de Regie-pagina van de Engine).
-- Dagen zonder rij tonen simpelweg nullen; niet zelf aanvullen met eigen data.
-- Ververs bij realtime-wijzigingen op logistics_tasks.
-
-REGEL
-Een order kan nooit in het verleden gepickt worden. Elke open pick.execute-taak
-met een planning vóór vandaag wordt door de Engine (en nogmaals door deze RPC)
-op vandaag getoond. Bouw dus geen eigen "inhaal"- of "achterstand"-dag.
-
-NIET DOEN
-- Geen eigen datumafronding, werkdagenlogica of tijdzoneconversie meer.
-- Geen orders uit de agenda filteren op status buiten wat de RPC teruggeeft.
-- Geen datum, project-ref of Supabase-URL hardcoden.
-
-CONTROLELIJST
-[ ] De agenda toont geen enkele dag vóór vandaag met openstaande orders.
-[ ] Een gisteren aangemelde, nog niet gepickte order staat vandaag in de agenda.
-[ ] Tegels boven de agenda tellen exact op met de dagregels van de RPC.
+                body: `AANVULLING op prompt 1 t/m 11 (die blijven geldig).
+
+GEMETEN PROBLEEM
+De weekagenda toont orders op maandag 31 aug terwijl het dinsdag 1 sep is. In
+public.logistics_tasks staat geen enkele open pick.execute-taak in het verleden:
+de Engine klemt planned_start al op nu. De agenda rekent dus nog zelf een pickdag
+uit (delivery_date minus pick_days), en die kan in het verleden liggen.
+
+BOUW DIT
+- Verwijder de eigen pickdagberekening uit de weekagenda (delivery_date,
+  pick_days_before_transport, max_workdays_earlier_pick, pick_weekdays).
+- Haal de agenda op met:
+
+  const { data, error } = await supabase.rpc("logistics_pick_agenda", {
+    p_from: weekStartIso, // yyyy-mm-dd
+    p_to: weekEndIso,
+  });
+  if (error) throw new Error(error.message);
+  const dagen = Array.isArray(data) ? data : [];
+
+- Kolommen per dag: pick_date, order_count, cart_count, plant_count,
+  in_preparation, ready, shifted_count, orders (jsonb array met taskId, orderRef,
+  status, carts, plants, shifted).
+- Vul de tegels "bestellingen", "karren" en "planten" met order_count, cart_count
+  en plant_count. "In voorbereiding" = in_preparation, "Verzendklaar" = ready.
+- Toon bij shifted_count > 0 op die dag het label "te laat aangemeld" (zelfde
+  betekenis als in de Regie-pagina van de Engine).
+- Dagen zonder rij tonen simpelweg nullen; niet zelf aanvullen met eigen data.
+- Ververs bij realtime-wijzigingen op logistics_tasks.
+
+REGEL
+Een order kan nooit in het verleden gepickt worden. Elke open pick.execute-taak
+met een planning vóór vandaag wordt door de Engine (en nogmaals door deze RPC)
+op vandaag getoond. Bouw dus geen eigen "inhaal"- of "achterstand"-dag.
+
+NIET DOEN
+- Geen eigen datumafronding, werkdagenlogica of tijdzoneconversie meer.
+- Geen orders uit de agenda filteren op status buiten wat de RPC teruggeeft.
+- Geen datum, project-ref of Supabase-URL hardcoden.
+
+CONTROLELIJST
+[ ] De agenda toont geen enkele dag vóór vandaag met openstaande orders.
+[ ] Een gisteren aangemelde, nog niet gepickte order staat vandaag in de agenda.
+[ ] Tegels boven de agenda tellen exact op met de dagregels van de RPC.
 [ ] Verschoven orders krijgen het label "te laat aangemeld".`,
             },
             {
@@ -1093,40 +1306,40 @@ CONTROLELIJST
                 title: "Karrentelling: alles uit de gedeelde karindex",
                 date: "2026-09-01",
                 summary: "Agenda en Controle karren tellen karren uit logistics_cart_index; payload-velden zoals cartCount worden niet meer gebruikt.",
-                body: `AANVULLING op prompt 1 t/m 12 (die blijven geldig).
-
-GEMETEN PROBLEEM
-De pick agenda toonde 3517 karren voor vandaag terwijl Controle karren er 27
-toonde. Oorzaak: de agenda telde payload->>'cartCount' van taken op (dubbeltelling
-over meerdere taken per order), Controle telde cart_numbers. Beide waren fout.
-
-WAT DE ENGINE NU LEVERT
-public.logistics_cart_index(p_from, p_to) — één rij per (order, kar):
-pick_date, order_uuid, order_number, order_source, cart_id, cart_index,
-cart_label, is_shared, task_status, shifted, printed_at.
-Daarop draaien logistics_pick_agenda en control_get_todays_carts.
-
-BOUW DIT
-- Gebruik uitsluitend cart_count uit logistics_pick_agenda voor de dagtegels.
-  Een gemengde kar telt per dag één keer, ook als meerdere orders erin zitten.
-- In een orderregel toont "carts" uit de orders-array het aantal karren waarin
-  die order zit (gedeelde karren tellen daar wél mee).
-- Gebruik voor de controlelijst alleen control_get_todays_carts; die geeft nu
-  cart_id als cart_number_id terug, ook voor karren zonder karnummer.
-- Verwijder elke lezing van payload->>'cartCount' en elke eigen count op
-  order_carts.
-
-CONTROLE OP AFWIJKING
-Roep bij het laden van de agenda eenmalig aan:
-
-  const { data } = await supabase.rpc("logistics_consistency_check");
-
-Is ok === false, toon dan een discrete waarschuwing "aantallen worden opnieuw
-uitgelijnd" en niets meer. Niet zelf corrigeren.
-
-CONTROLELIJST
-[ ] Agenda-karren van vandaag = karren in Controle karren.
-[ ] Geen enkel scherm leest nog cartCount uit een taak-payload.
+                body: `AANVULLING op prompt 1 t/m 12 (die blijven geldig).
+
+GEMETEN PROBLEEM
+De pick agenda toonde 3517 karren voor vandaag terwijl Controle karren er 27
+toonde. Oorzaak: de agenda telde payload->>'cartCount' van taken op (dubbeltelling
+over meerdere taken per order), Controle telde cart_numbers. Beide waren fout.
+
+WAT DE ENGINE NU LEVERT
+public.logistics_cart_index(p_from, p_to) — één rij per (order, kar):
+pick_date, order_uuid, order_number, order_source, cart_id, cart_index,
+cart_label, is_shared, task_status, shifted, printed_at.
+Daarop draaien logistics_pick_agenda en control_get_todays_carts.
+
+BOUW DIT
+- Gebruik uitsluitend cart_count uit logistics_pick_agenda voor de dagtegels.
+  Een gemengde kar telt per dag één keer, ook als meerdere orders erin zitten.
+- In een orderregel toont "carts" uit de orders-array het aantal karren waarin
+  die order zit (gedeelde karren tellen daar wél mee).
+- Gebruik voor de controlelijst alleen control_get_todays_carts; die geeft nu
+  cart_id als cart_number_id terug, ook voor karren zonder karnummer.
+- Verwijder elke lezing van payload->>'cartCount' en elke eigen count op
+  order_carts.
+
+CONTROLE OP AFWIJKING
+Roep bij het laden van de agenda eenmalig aan:
+
+  const { data } = await supabase.rpc("logistics_consistency_check");
+
+Is ok === false, toon dan een discrete waarschuwing "aantallen worden opnieuw
+uitgelijnd" en niets meer. Niet zelf corrigeren.
+
+CONTROLELIJST
+[ ] Agenda-karren van vandaag = karren in Controle karren.
+[ ] Geen enkel scherm leest nog cartCount uit een taak-payload.
 [ ] Orders van verwijderde bestellingen verschijnen nergens meer.`,
             },
             {
@@ -1134,44 +1347,232 @@ CONTROLELIJST
                 title: "Lever agenda uit dezelfde karindex als de pick agenda",
                 date: "2026-09-01",
                 summary: "De lever agenda leest logistics_delivery_agenda; geen eigen telling meer op orders of order_carts.",
-                body: `AANVULLING op prompt 1 t/m 13 (die blijven geldig).
-
-WAAROM
-Pick agenda, Controle karren en Verkoop tellen al uit dezelfde karindex. De
-lever agenda telde nog zelf. Daardoor konden dezelfde orders op twee schermen
-een ander aantal karren tonen.
-
-WAT DE ENGINE LEVERT
-public.logistics_delivery_agenda(p_from date, p_to date) — één rij per leverdag:
-delivery_date, order_count, cart_count, plant_count, announced_count,
-printed_count, controlled_count, orders (jsonb array met order_uuid,
-order_number, pick_date, cart_count, plant_count, announced, printed,
-controlled).
-
-Zelfde telbron als logistics_pick_agenda; alleen gegroepeerd op leverdatum in
-plaats van pickdag.
-
-BOUW DIT
-- Haal de lever agenda op met:
-
-    const { data } = await supabase.rpc("logistics_delivery_agenda", {
-      p_from: vanDatum, p_to: totDatum,
-    });
-    const dagen = Array.isArray(data) ? data : [];
-
-- Toon cart_count en plant_count exact zoals teruggegeven; niets optellen of
-  omrekenen.
-- Statusfilters (aangemeld / geprint / gecontroleerd) filteren regels; ze mogen
-  het totaal nooit herberekenen.
-
-NIET DOEN
-- Geen eigen query op orders, order_carts of de Floriday-cache voor aantallen.
-- Geen datums, project-refs of URL's hardcoden.
-
-CONTROLELIJST
-[ ] Een order toont in de lever agenda hetzelfde aantal karren als in de pick agenda.
+                body: `AANVULLING op prompt 1 t/m 13 (die blijven geldig).
+
+WAAROM
+Pick agenda, Controle karren en Verkoop tellen al uit dezelfde karindex. De
+lever agenda telde nog zelf. Daardoor konden dezelfde orders op twee schermen
+een ander aantal karren tonen.
+
+WAT DE ENGINE LEVERT
+public.logistics_delivery_agenda(p_from date, p_to date) — één rij per leverdag:
+delivery_date, order_count, cart_count, plant_count, announced_count,
+printed_count, controlled_count, orders (jsonb array met order_uuid,
+order_number, pick_date, cart_count, plant_count, announced, printed,
+controlled).
+
+Zelfde telbron als logistics_pick_agenda; alleen gegroepeerd op leverdatum in
+plaats van pickdag.
+
+BOUW DIT
+- Haal de lever agenda op met:
+
+    const { data } = await supabase.rpc("logistics_delivery_agenda", {
+      p_from: vanDatum, p_to: totDatum,
+    });
+    const dagen = Array.isArray(data) ? data : [];
+
+- Toon cart_count en plant_count exact zoals teruggegeven; niets optellen of
+  omrekenen.
+- Statusfilters (aangemeld / geprint / gecontroleerd) filteren regels; ze mogen
+  het totaal nooit herberekenen.
+
+NIET DOEN
+- Geen eigen query op orders, order_carts of de Floriday-cache voor aantallen.
+- Geen datums, project-refs of URL's hardcoden.
+
+CONTROLELIJST
+[ ] Een order toont in de lever agenda hetzelfde aantal karren als in de pick agenda.
 [ ] Geen eigen kartelling meer in de leveringencode.`,
             },
+            {
+                number: 15,
+                title: "Scancontrole: pakbon scannen, goedkeuren en afleverbrief printen",
+                date: "2026-09-03",
+                summary: "Het controlescherm scant pakbonnen via de Engine-RPC's; de Engine bepaalt FO of niet-FO en zet de afleverbrief klaar op de gekozen printer.",
+                body: `AANVULLING op prompt 1 t/m 14 (die blijven geldig).
+
+WAT ER VERANDERT
+In de Logistiek Engine, stap 6 "Controle", kiest de gebruiker bij "Scancontrole"
+nu ook een scanner (control_scanner_id) en een printer (control_printer_id).
+Die keuze staat in de werkwijze in de database. Afhandeling kiest zelf geen
+scanner, printer, layout of documentsoort meer.
+
+WAT DE ENGINE LEVERT (alles via supabase.rpc)
+- logistics_control_settings() -> { controlMode, scannerId, printerId }
+  De ingestelde controlepost. Ontbreekt scannerId of printerId, toon dan een
+  duidelijke melding en scan niet verder; niet zelf een apparaat kiezen.
+- logistics_control_scan_lookup(p_barcode text)
+  Herkent aan de barcode/QR op de pakbon: order, kar ("Kar X van Y"), de
+  belading van die kar, de klant, of het een Floriday-order is (isFloriday /
+  salesOrderId) en of deze kar al eerder gescand is (scan, alreadyControlled).
+  Onbekende barcode geeft ok:false met een leesbare tekst; toon die letterlijk.
+- logistics_control_scan_approve(p_barcode, p_scanner_id, p_printer_id,
+  p_allow_reprint boolean default false)
+  Keurt de gescande pakbon goed. Niet-Floriday: de eigen afleverbrief wordt
+  direct als printjob klaargezet op de gekozen printer. Floriday: de definitieve
+  belading gaat naar Floriday, de Engine haalt daarna de officiële Floriday-
+  afleverbrief op en print die. Dubbel scannen geeft ok:false met errorCode
+  "al_gecontroleerd"; alleen bij een bewuste keuze opnieuw printen mag je
+  p_allow_reprint = true meesturen.
+- logistics_control_scan_overview(p_scanner_id uuid, p_date date)
+  Alle scans van vandaag met hun status, voor de statuslijst in het scherm.
+- logistics_control_scan_retry(p_id uuid)
+  Opnieuw proberen na een mislukte Floriday-afleverbrief.
+
+STATUSSEN (letterlijk tonen, niet hertalen naar eigen statussen)
+gescand -> goedgekeurd -> afleverbrief_aangevraagd -> geprint, of mislukt.
+Zolang een Floriday-order op de afleverbrief wacht blijft de status
+afleverbrief_aangevraagd; hij mag dan NIET als afgerond gelden.
+
+BOUW DIT
+- Een scanscherm bij de controlepost: invoerveld/scanner-invoer -> lookup tonen
+  ter controle (order, kar, belading, FO of niet) -> knop "Goedkeuren" die
+  approve aanroept. Meerdere pakbonnen achter elkaar scannen moet kunnen.
+- Een lijst met de scans van vandaag uit logistics_control_scan_overview, met
+  status, foutmelding en bij "mislukt" een knop "Opnieuw proberen" (retry).
+- Blokkeer de goedkeurknop zolang een aanroep loopt, zodat dubbelklikken geen
+  tweede afleverbrief oplevert. De database blokkeert dubbel scannen ook, maar
+  de melding moet zichtbaar zijn.
+- Ververs op wijzigingen in logistics_control_scan.
+
+NIET DOEN
+- Geen eigen afleverbrief maken voor een Floriday-order; die komt altijd uit
+  Floriday via de Engine.
+- Geen eigen printjobs aanmaken, geen layout kiezen, geen printer raden.
+- Geen order of kar als afgerond markeren zolang de afleverbrief niet geprint is.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste apparaat-id's in code.
+
+CONTROLELIJST
+[ ] Scannen van een pakbon toont order, kar, belading en of het een FO-order is.
+[ ] Goedkeuren van een niet-FO-kar levert direct een afleverbrief op de gekozen printer.
+[ ] Goedkeuren van een FO-kar levert de Floriday-afleverbrief op, niet de eigen.
+[ ] Tweede scan van dezelfde kar geeft een melding en maakt geen tweede brief.
+[ ] Een mislukte Floriday-afleverbrief is zichtbaar en opnieuw te proberen.`,
+            },
+            {
+                number: 16,
+                title: "Karnummer per order: cart_seq en cart_number tonen",
+                date: "2026-09-03",
+                summary: "Karnummers komen uit de Engine: toon cart_seq en cart_number, nooit cart_index, en reken zelf niets om.",
+                body: `AANVULLING op de eerdere prompts (die blijven geldig).
+
+WAT ER VERANDERT
+De Engine levert vanaf nu per kar een stabiel karnummer. Modules rekenen zelf
+NIETS meer om en hernummeren niet.
+
+VELDEN (uit de Engine-RPC's)
+- cart_seq  : stabiel, 1-gebaseerd volgnummer van de kar binnen zijn order.
+  Identiek aan het nummer op de pakbon in de verkoopmodule. Verandert niet als
+  karren op verschillende dagen gepickt of gecontroleerd worden, en niet als een
+  deel van de karren al is afgehandeld.
+- cart_number : het definitieve karnummer-label (bijv. het toegewezen
+  karnummer uit de karnummering). Toon dit als label.
+- cart_total  : het aantal karren van die order ("Kar X van Y" = cart_seq van
+  cart_total).
+- cart_index  : INTERN. Technische index, niet gedefinieerd als 0- of
+  1-gebaseerd. NOOIT tonen en nooit als basis voor eigen nummering gebruiken.
+
+WAAR STAAN DE VELDEN
+control_get_todays_carts(), logistics_pick_agenda(p_from, p_to) (per order in
+cartList), logistics_cart_index(p_from, p_to), logistics_control_scan_lookup(
+p_barcode) (cartSeq / cartNumber / cartTotal) en
+logistics_control_scan_overview(p_scanner_id, p_date).
+
+GEBRUIK IN DEZE MODULE
+Karrencontrole toont het karnummer uit control_get_todays_carts (cart_seq,
+cart_number, cart_total). De eerdere eigen hernummering vervalt.
+
+NIET DOEN
+- Niet zelf nummeren, sorteren op index, of +1 optellen bij cart_index.
+- Geen aparte nummering per dag, per pickronde of per controlesessie.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Elk karnummer in het scherm komt uit cart_seq / cart_number.
+[ ] "Kar X van Y" gebruikt cart_seq en cart_total.
+[ ] Een order met 4 karren toont 1 t/m 4, ook als er al karren afgehandeld zijn.
+[ ] Het getoonde nummer is gelijk aan het nummer op de pakbon.
+[ ] cart_index komt nergens in de weergave voor.`,
+            },
+            {
+                number: 17,
+                title: "Controle karren alleen tonen bij picken per kar",
+                date: "2026-09-04",
+                summary: "De submodule Controle karren staat alleen in de balk als de actieve werkwijze picken per kar gebruikt.",
+                body: `AANVULLING op de eerdere prompts (die blijven geldig).
+
+WAT ER VERANDERT
+Karrencontrole hoort alleen bij de pickmethode "Picken per kar". Bij elke andere
+pickmethode (per order, kleinste telt, per orderbuffer) bestaat er geen
+karcontrolestap en mag de submodule "Controle karren" niet in de balk staan.
+
+BRON — DE ENGINE BESLIST
+Nieuwe RPC:
+
+  select public.logistics_pick_mode();
+
+Geeft terug:
+- pickMode        : 'order' | 'cart' | 'smallest' | 'buffer' | null
+- showCartControl : true alleen bij pickMode = 'cart'
+
+GEBRUIK IN DEZE MODULE
+- Roep de RPC aan bij het opbouwen van de navigatie.
+- showCartControl = true  -> menu-item "Controle karren" tonen.
+- showCartControl = false -> menu-item weglaten en de route afschermen
+  (direct benaderen leidt terug naar het overzicht).
+- Is de RPC nog niet geladen of geeft hij een fout, toon het item dan NIET
+  (fail closed) en geen eigen aanname over de pickmethode.
+- Ververs bij het wisselen van werkwijze, zodat de balk direct meeloopt.
+
+NIET DOEN
+- Niet zelf de rule-config uitlezen of de pickmethode afleiden uit karren die
+  je toevallig ziet.
+- Geen eigen instelling of schakelaar voor het tonen van Controle karren.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Bij "Picken per kar" staat Controle karren in de balk en werkt hij.
+[ ] Bij elke andere pickmethode staat Controle karren niet in de balk.
+[ ] De route is ook rechtstreeks niet bereikbaar als hij verborgen is.
+[ ] Zonder antwoord van de RPC blijft het item verborgen.`,
+            },
+            {
+                number: 18,
+                title: "Een bufferorder is één order in Afhandeling",
+                date: "2026-09-05",
+                summary: "Pick agenda, Lever agenda en Karrencontrole tonen orders uit één orderbuffer als één order met één karrenindeling.",
+                body: `AANVULLING op de eerdere prompts (die blijven geldig).
+
+WAT ER VERANDERT
+Orders die samen in één orderbuffer zitten, zijn logistiek één order. De Engine
+levert ze als één eenheid aan onder het leidende ordernummer (unit_ref).
+
+BRON
+- logistics_pick_agenda(p_from, p_to) -> orders[]: orderRef is de eenheid, met
+  isBuffer en bufferOrders[] erbij; carts/cartList/cartTotal gelden voor de hele
+  eenheid.
+- logistics_delivery_agenda(p_from, p_to) -> orders[]: order_number is de
+  eenheid, met is_buffer en buffer_orders[].
+- control_get_todays_carts(): order_number is de eenheid, cart_seq/cart_total
+  lopen door over alle karren van die eenheid.
+- logistics_cart_units(p_from, p_to) is de onderliggende karindex per eenheid.
+
+GEBRUIK IN DEZE MODULE
+- Tel en toon per eenheid, nooit per los bufferlid.
+- Toon bij isBuffer de losse ordernummers als toelichting, niet als eigen regel.
+- Karrencontrole vinkt af per kar van de eenheid; een kar komt maar één keer voor.
+
+NIET DOEN
+- Geen eigen query op order_carts of orders om karren te tellen.
+- Niet hernummeren per los ordernummer.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Een buffer met twee orders telt als één order op de pick agenda.
+[ ] Dezelfde eenheid en hetzelfde karrenaantal staan op de lever agenda.
+[ ] Karrencontrole toont elke kar precies één keer, onder de eenheid.`,
+            },
         ],
     },
     pickschermen: {
@@ -1184,12 +1585,12 @@ CONTROLELIJST
                 date: "2026-07-24",
                 summary: "Pick-taken tonen en terugmelden.",
                 withSharedContract: true,
-                body: `Haal weg: eigen pickvolgorde en eigen bepaling van de starttijd.
-
-Bouw:
-- pick.execute taken tonen, gesorteerd op planned_start.
-- Payload: pickMode, pickStartMode, pickMinutes, staff, reserveMinutes, scanner, loadCarriers.
-- Voortgang terugmelden via RPC: logistics_claim_task bij starten, logistics_complete_task bij afronden.
+                body: `Haal weg: eigen pickvolgorde en eigen bepaling van de starttijd.
+
+Bouw:
+- pick.execute taken tonen, gesorteerd op planned_start.
+- Payload: pickMode, pickStartMode, pickMinutes, staff, reserveMinutes, scanner, loadCarriers.
+- Voortgang terugmelden via RPC: logistics_claim_task bij starten, logistics_complete_task bij afronden.
 - Te-laat-dreigende belading markeren op basis van planned_end; niet zelf herrekenen.`,
             },
             {
@@ -1197,26 +1598,26 @@ Bouw:
                 title: "Documenten per pickstation vanuit de Engine",
                 date: "2026-08-03",
                 summary: "Documenttaken tonen op het juiste pickstation, inclusief goedkeuring.",
-                body: `Deze prompt vervangt niets uit prompt 1; hij komt er bovenop.
-
-Haal weg: eigen logica over welk document op welk pickstation verschijnt en
-wanneer. De Logistics Engine bepaalt dit volledig.
-
-Verwerk deze taaktypes uit logistics_tasks:
-- print.packing_slip, print.sticker, print.shipping_note, print.production_note
-
-Payload per taak:
-- release            wanneer het document vrijkomt
-- pickStationId      public.pick_stations.id waar het document heen moet
-- pickStationTypeId  public.pick_station_types.id dat het document mag ontvangen
-- requiresApproval   true = eerst handmatige goedkeuring op het pickstation
-
-Regels:
-- Toon een document pas vanaf planned_start van de taak.
-- Filter de wachtrij van een pickstation op pickStationId; is die leeg, gebruik
-  dan pickStationTypeId. Toon nooit documenten van een ander station.
-- requiresApproval = true: toon een goedkeurknop; pas na goedkeuren printen en
-  daarna logistics_complete_task aanroepen (bij weigeren logistics_fail_task).
+                body: `Deze prompt vervangt niets uit prompt 1; hij komt er bovenop.
+
+Haal weg: eigen logica over welk document op welk pickstation verschijnt en
+wanneer. De Logistics Engine bepaalt dit volledig.
+
+Verwerk deze taaktypes uit logistics_tasks:
+- print.packing_slip, print.sticker, print.shipping_note, print.production_note
+
+Payload per taak:
+- release            wanneer het document vrijkomt
+- pickStationId      public.pick_stations.id waar het document heen moet
+- pickStationTypeId  public.pick_station_types.id dat het document mag ontvangen
+- requiresApproval   true = eerst handmatige goedkeuring op het pickstation
+
+Regels:
+- Toon een document pas vanaf planned_start van de taak.
+- Filter de wachtrij van een pickstation op pickStationId; is die leeg, gebruik
+  dan pickStationTypeId. Toon nooit documenten van een ander station.
+- requiresApproval = true: toon een goedkeurknop; pas na goedkeuren printen en
+  daarna logistics_complete_task aanroepen (bij weigeren logistics_fail_task).
 - Bepaal nooit zelf een vrijgavemoment en print nooit vooruit.`,
             },
             {
@@ -1224,32 +1625,32 @@ Regels:
                 title: "Documenten ophalen via de Floriday-gateway",
                 date: "2026-08-04",
                 summary: "Geen eigen Floriday-token of florydayFetch meer; gebundeld printen per kar.",
-                body: `Deze prompt vervangt niets uit prompt 1 en 2; hij komt er bovenop.
-
-Haal weg: eigen Floriday-tokenlogica, eigen florydayFetch, eigen keuze van
-staging/live en eigen HTTP-aanroepen naar de Floriday-gateway.
-
-Alle modules draaien in dezelfde shell op dezelfde database. Importeer de
-gateway daarom rechtstreeks en geef de service-role supabase-client van de
-shell mee:
-
-import {
-  runActiveEnvironment,
-  runPdf,
-  runPdfBulkMerged,
-} from "@flowselections/floriday-authenticatie-module/gateway";
-
-Regels:
-- De omgeving komt altijd uit runActiveEnvironment(supabase). Nooit zelf kiezen.
-- Eén document (print.packing_slip, print.sticker, print.shipping_note,
-  print.production_note): runPdf.
-- Trigger "kar afgemeld" of "kar-scan": bundel alle regels van die kar en roep
-  runPdfBulkMerged aan, zodat het pickstation één printjob krijgt in plaats van
-  losse documenten.
-- Toon bovenin het scherm welke koppeling actief is (label, GLN, staging/live).
-- Print nooit twee keer hetzelfde: controleer public.logistics_document_prints
-  op (order_ref, document_type, trigger) voordat je print.
-- Trigger en pickstation blijven van de Logistics Engine; de gateway levert
+                body: `Deze prompt vervangt niets uit prompt 1 en 2; hij komt er bovenop.
+
+Haal weg: eigen Floriday-tokenlogica, eigen florydayFetch, eigen keuze van
+staging/live en eigen HTTP-aanroepen naar de Floriday-gateway.
+
+Alle modules draaien in dezelfde shell op dezelfde database. Importeer de
+gateway daarom rechtstreeks en geef de service-role supabase-client van de
+shell mee:
+
+import {
+  runActiveEnvironment,
+  runPdf,
+  runPdfBulkMerged,
+} from "@flowselections/floriday-authenticatie-module/gateway";
+
+Regels:
+- De omgeving komt altijd uit runActiveEnvironment(supabase). Nooit zelf kiezen.
+- Eén document (print.packing_slip, print.sticker, print.shipping_note,
+  print.production_note): runPdf.
+- Trigger "kar afgemeld" of "kar-scan": bundel alle regels van die kar en roep
+  runPdfBulkMerged aan, zodat het pickstation één printjob krijgt in plaats van
+  losse documenten.
+- Toon bovenin het scherm welke koppeling actief is (label, GLN, staging/live).
+- Print nooit twee keer hetzelfde: controleer public.logistics_document_prints
+  op (order_ref, document_type, trigger) voordat je print.
+- Trigger en pickstation blijven van de Logistics Engine; de gateway levert
   alleen het PDF-bestand.`,
             },
             {
@@ -1257,29 +1658,29 @@ Regels:
                 title: "Strikte documentroutering per pickstation",
                 date: "2026-08-04",
                 summary: "Een pickstation toont uitsluitend de documentsoorten die eraan gekoppeld zijn.",
-                body: `Deze prompt vervangt niets uit prompt 1 t/m 3; hij komt er bovenop.
-
-Probleem: op "Pickstation Orders" verschenen naast pakbonnen ook veilingbrieven
-en transportbrieven. Dat mag nooit.
-
-Haal weg: elke query die de wachtrij alleen op station_id filtert, en elke
-fallback die "overige documenten" toch ergens toont.
-
-Regels:
-- Filter de wachtrij ALTIJD op screen_id van het geopende scherm, niet op
-  station_id. Elk scherm heeft via public.pick_screen_document_types precies de
-  documenttypes die het mag tonen.
-- Toon nooit een document waarvan het document_type_id niet aan dat scherm is
-  gekoppeld. Geen "rest"-categorie, geen samengevoegde stationweergave.
-- De koppeling documentsoort -> pickstation komt uit de Logistiek Engine
-  (Rule Engine, stap "Pickstations"). In de database is dat opvraagbaar met
-  select public.logistics_document_station('pakbon').
-- De printwachtrij public.pick_queue heeft een trigger die station_id en
-  screen_id herschrijft volgens die instelling. Schrijf zelf nooit een
-  station_id dat daarvan afwijkt; dat wordt overschreven of geweigerd.
-- Taken uit logistics_tasks dragen payload.documentType en payload.pickStationId.
-  Gebruik die twee samen; nooit alleen het taaktype.
-- Standaardweergave is "documenten van vandaag". Oudere, niet-geprinte regels
+                body: `Deze prompt vervangt niets uit prompt 1 t/m 3; hij komt er bovenop.
+
+Probleem: op "Pickstation Orders" verschenen naast pakbonnen ook veilingbrieven
+en transportbrieven. Dat mag nooit.
+
+Haal weg: elke query die de wachtrij alleen op station_id filtert, en elke
+fallback die "overige documenten" toch ergens toont.
+
+Regels:
+- Filter de wachtrij ALTIJD op screen_id van het geopende scherm, niet op
+  station_id. Elk scherm heeft via public.pick_screen_document_types precies de
+  documenttypes die het mag tonen.
+- Toon nooit een document waarvan het document_type_id niet aan dat scherm is
+  gekoppeld. Geen "rest"-categorie, geen samengevoegde stationweergave.
+- De koppeling documentsoort -> pickstation komt uit de Logistiek Engine
+  (Rule Engine, stap "Pickstations"). In de database is dat opvraagbaar met
+  select public.logistics_document_station('pakbon').
+- De printwachtrij public.pick_queue heeft een trigger die station_id en
+  screen_id herschrijft volgens die instelling. Schrijf zelf nooit een
+  station_id dat daarvan afwijkt; dat wordt overschreven of geweigerd.
+- Taken uit logistics_tasks dragen payload.documentType en payload.pickStationId.
+  Gebruik die twee samen; nooit alleen het taaktype.
+- Standaardweergave is "documenten van vandaag". Oudere, niet-geprinte regels
   horen in een apart tabblad, niet in de dagwachtrij.`,
             },
             {
@@ -1287,41 +1688,41 @@ Regels:
                 title: "Documenten altijd renderen met de layout uit de Layout maker",
                 date: "2026-08-04",
                 summary: "Geen eigen pakbon-opmaak meer; de layout komt uit public.document_layouts.",
-                body: `Deze prompt vervangt niets uit prompt 1 t/m 4; hij komt er bovenop.
-
-Probleem: het pickstation print een eigen, hardgecodeerde pakbon. De pakbon die
-in de module "Layout maker (pakbonnen, verzendbrieven, extra)" is ontworpen
-wordt genegeerd.
-
-Haal weg: elke eigen HTML/PDF-opmaak van pakbonnen, verzendbrieven, stickers,
-productiebonnen en controlelijsten. Ook alle vaste kolommen, logo's, marges en
-papierformaten die in de pickstation-code staan.
-
-Regels:
-- De opmaak komt ALTIJD uit public.document_layouts (+ document_layout_elements,
-  document_layout_variables, document_layout_versions, layout_logos). Nooit een
-  eigen sjabloon, ook niet als fallback.
-- Welke layout bij een documentsoort hoort, bepaal je niet zelf. Gebruik:
-    select public.logistics_document_layout('pakbon');
-  Dat geeft { layoutId, layoutName, layoutVersion, layoutDocumentType } van de
-  actieve layout (voorkeur: is_standaard).
-- Elke regel in public.pick_queue draagt deze gegevens al mee in payload:
-  documentType, layoutId, layoutName, layoutVersion. Gebruik payload.layoutId
-  als die er staat; val alleen terug op de functie hierboven als hij ontbreekt.
-- Render met de renderer van de Layout maker, niet met eigen code. Papierformaat,
-  oriëntatie en marges komen uit de layoutrij (papierformaat, breedte_mm,
-  hoogte_mm, marge_*, orientatie, page_settings).
-- Ontbreekt er een actieve layout voor een documentsoort? Print dan niet, maar
-  toon "Geen layout ingesteld voor <documentsoort>" met een verwijzing naar de
-  Layout maker. Nooit stilzwijgend een eigen pakbon printen.
-- Floriday-documenten (prompt 3) blijven via de gateway lopen; alles wat we zelf
-  opmaken loopt via de Layout maker.
-- Log bij het afronden van de taak welke layoutId en layoutVersion zijn gebruikt
-  in het result van logistics_complete_task.
-
-CONTROLELIJST
-[ ] Geen enkel eigen documentsjabloon meer in de code.
-[ ] Pakbon in het pickstation is visueel identiek aan de preview in de Layout maker.
+                body: `Deze prompt vervangt niets uit prompt 1 t/m 4; hij komt er bovenop.
+
+Probleem: het pickstation print een eigen, hardgecodeerde pakbon. De pakbon die
+in de module "Layout maker (pakbonnen, verzendbrieven, extra)" is ontworpen
+wordt genegeerd.
+
+Haal weg: elke eigen HTML/PDF-opmaak van pakbonnen, verzendbrieven, stickers,
+productiebonnen en controlelijsten. Ook alle vaste kolommen, logo's, marges en
+papierformaten die in de pickstation-code staan.
+
+Regels:
+- De opmaak komt ALTIJD uit public.document_layouts (+ document_layout_elements,
+  document_layout_variables, document_layout_versions, layout_logos). Nooit een
+  eigen sjabloon, ook niet als fallback.
+- Welke layout bij een documentsoort hoort, bepaal je niet zelf. Gebruik:
+    select public.logistics_document_layout('pakbon');
+  Dat geeft { layoutId, layoutName, layoutVersion, layoutDocumentType } van de
+  actieve layout (voorkeur: is_standaard).
+- Elke regel in public.pick_queue draagt deze gegevens al mee in payload:
+  documentType, layoutId, layoutName, layoutVersion. Gebruik payload.layoutId
+  als die er staat; val alleen terug op de functie hierboven als hij ontbreekt.
+- Render met de renderer van de Layout maker, niet met eigen code. Papierformaat,
+  oriëntatie en marges komen uit de layoutrij (papierformaat, breedte_mm,
+  hoogte_mm, marge_*, orientatie, page_settings).
+- Ontbreekt er een actieve layout voor een documentsoort? Print dan niet, maar
+  toon "Geen layout ingesteld voor <documentsoort>" met een verwijzing naar de
+  Layout maker. Nooit stilzwijgend een eigen pakbon printen.
+- Floriday-documenten (prompt 3) blijven via de gateway lopen; alles wat we zelf
+  opmaken loopt via de Layout maker.
+- Log bij het afronden van de taak welke layoutId en layoutVersion zijn gebruikt
+  in het result van logistics_complete_task.
+
+CONTROLELIJST
+[ ] Geen enkel eigen documentsjabloon meer in de code.
+[ ] Pakbon in het pickstation is visueel identiek aan de preview in de Layout maker.
 [ ] Ontbrekende layout geeft een duidelijke melding in plaats van een print.`,
             },
             {
@@ -1329,50 +1730,50 @@ CONTROLELIJST
                 title: "Sectie-layouts uit de Layout maker correct printen",
                 date: "2026-08-04",
                 summary: "Een geldige pakbon in document_layouts.config mag nooit als ontbrekende layout worden afgewezen.",
-                body: `Deze prompt vervangt niets uit prompt 1 t/m 5; hij komt er bovenop.
-
-Probleem: de gekoppelde layout "packbon hoofd" is een geldige sectie-layout.
-De opbouw staat in public.document_layouts.config.pakbon.secties en niet in
-public.document_layout_elements. Het pickstation ondersteunt nu alleen
-canvas-elementen en toont daardoor ten onrechte "Geen layout ingesteld".
-
-Haal weg:
-- elke controle die een layout als ontbrekend beschouwt wanneer
-  document_layout_elements leeg is;
-- elke renderer die uitsluitend document_layout_elements ondersteunt;
-- de algemene MissingLayoutError voor een wel bestaande, actieve layoutrij.
-
-Regels:
-- Een layout ontbreekt uitsluitend als public.document_layouts geen actieve rij
-  voor het door de Engine aangeleverde layoutId bevat. Nul canvas-elementen is
-  geen ontbrekende layout.
-- Lees eerst payload.layoutId (of payload.layout_id) uit public.pick_queue.
-  De huidige pakbonnen verwijzen daarmee naar de gekoppelde layoutrij.
-- Kies daarna de renderer op basis van de opgeslagen layoutvorm:
-  1. config.pakbon.secties is een array: gebruik dezelfde sectie-/pakbonrenderer
-     en dezelfde datamapping als de preview van de Layout maker;
-  2. document_layout_elements bevat rijen: gebruik de canvasrenderer;
-  3. geen van beide bevat inhoud: meld "Layout heeft nog geen inhoud", niet
-     "Geen layout ingesteld".
-- Importeer de renderer en bijbehorende types bij voorkeur rechtstreeks uit de
-  Layout maker-module. Kopieer geen pakbonsjabloon naar deze module. Als de
-  Layout maker de renderer nog niet exporteert, voeg daar named exports toe voor
-  de sectierenderer en de order-naar-pakbon-datamapping en gebruik die hier.
-- Respecteer config.pakbon.secties volledig: volgorde, zichtbaar, condities,
-  opties, karren, lagen, producten, totalen en logo. Respecteer daarnaast
-  papierformaat, oriëntatie, marges en page_settings van document_layouts.
-- Vul vóór renderen de volledige ordercontext voor payload.orderId of
-  order_number: order, klant, afleveradres, orderregels, karren, lagen,
-  producten en fusten. De wachtrijregel alleen bevat hiervoor onvoldoende data.
-- Markeer de wachtrijregel pas als geprint nadat renderen is gelukt en de
-  printdialoog is geopend. Laat de regel bij een renderfout in de wachtrij staan.
-
-CONTROLELIJST
-[ ] "packbon hoofd" opent vanuit Pickstation Orders zonder MissingLayoutError.
-[ ] De afdruk is visueel gelijk aan de preview in de Layout maker.
-[ ] Karren, lagen en producten van de gekozen order staan op de pakbon.
-[ ] Een lege layout geeft "Layout heeft nog geen inhoud".
-[ ] Een werkelijk ontbrekende/inactieve layoutrij geeft pas "Geen layout ingesteld".
+                body: `Deze prompt vervangt niets uit prompt 1 t/m 5; hij komt er bovenop.
+
+Probleem: de gekoppelde layout "packbon hoofd" is een geldige sectie-layout.
+De opbouw staat in public.document_layouts.config.pakbon.secties en niet in
+public.document_layout_elements. Het pickstation ondersteunt nu alleen
+canvas-elementen en toont daardoor ten onrechte "Geen layout ingesteld".
+
+Haal weg:
+- elke controle die een layout als ontbrekend beschouwt wanneer
+  document_layout_elements leeg is;
+- elke renderer die uitsluitend document_layout_elements ondersteunt;
+- de algemene MissingLayoutError voor een wel bestaande, actieve layoutrij.
+
+Regels:
+- Een layout ontbreekt uitsluitend als public.document_layouts geen actieve rij
+  voor het door de Engine aangeleverde layoutId bevat. Nul canvas-elementen is
+  geen ontbrekende layout.
+- Lees eerst payload.layoutId (of payload.layout_id) uit public.pick_queue.
+  De huidige pakbonnen verwijzen daarmee naar de gekoppelde layoutrij.
+- Kies daarna de renderer op basis van de opgeslagen layoutvorm:
+  1. config.pakbon.secties is een array: gebruik dezelfde sectie-/pakbonrenderer
+     en dezelfde datamapping als de preview van de Layout maker;
+  2. document_layout_elements bevat rijen: gebruik de canvasrenderer;
+  3. geen van beide bevat inhoud: meld "Layout heeft nog geen inhoud", niet
+     "Geen layout ingesteld".
+- Importeer de renderer en bijbehorende types bij voorkeur rechtstreeks uit de
+  Layout maker-module. Kopieer geen pakbonsjabloon naar deze module. Als de
+  Layout maker de renderer nog niet exporteert, voeg daar named exports toe voor
+  de sectierenderer en de order-naar-pakbon-datamapping en gebruik die hier.
+- Respecteer config.pakbon.secties volledig: volgorde, zichtbaar, condities,
+  opties, karren, lagen, producten, totalen en logo. Respecteer daarnaast
+  papierformaat, oriëntatie, marges en page_settings van document_layouts.
+- Vul vóór renderen de volledige ordercontext voor payload.orderId of
+  order_number: order, klant, afleveradres, orderregels, karren, lagen,
+  producten en fusten. De wachtrijregel alleen bevat hiervoor onvoldoende data.
+- Markeer de wachtrijregel pas als geprint nadat renderen is gelukt en de
+  printdialoog is geopend. Laat de regel bij een renderfout in de wachtrij staan.
+
+CONTROLELIJST
+[ ] "packbon hoofd" opent vanuit Pickstation Orders zonder MissingLayoutError.
+[ ] De afdruk is visueel gelijk aan de preview in de Layout maker.
+[ ] Karren, lagen en producten van de gekozen order staan op de pakbon.
+[ ] Een lege layout geeft "Layout heeft nog geen inhoud".
+[ ] Een werkelijk ontbrekende/inactieve layoutrij geeft pas "Geen layout ingesteld".
 [ ] De wachtrij wordt alleen afgerond na een geslaagde render/printactie.`,
             },
             {
@@ -1380,37 +1781,37 @@ CONTROLELIJST
                 title: "Altijd de actuele layout, behalve bij kant-en-klare PDF's",
                 date: "2026-08-14",
                 summary: "Layout wint boven meegestuurde HTML; klantstickers en Floriday-documenten gaan als bestaande PDF ongewijzigd naar de printer.",
-                body: `Deze prompt vervangt niets uit prompt 1 t/m 6; hij komt er bovenop.
-
-Uitgangspunt: wat er geprint wordt is ALTIJD de actuele layout uit de Layout
-maker, gevuld met de echte gegevens van de order en de klant. Enige uitzondering:
-documenten die al als kant-en-klare PDF bestaan (klantstickers en
-Floriday-documenten). Die worden ongewijzigd doorgestuurd.
-
-Volgorde van beslissen bij een printopdracht in public.print_jobs:
-1. Is er een kant-en-klare PDF meegegeven (pdf-veld op de opdracht / bron uit
-   floriday_customer_sticker_pdfs_cache): die PDF ongewijzigd naar de printer.
-   Niet opnieuw opmaken, niet renderen.
-2. Is print_jobs.layout_id gevuld: die layout wint. Negeer een eventueel
-   meegestuurde render_html en render vers uit public.document_layouts.
-3. Pas als beide leeg zijn: meegestuurde render_html, en anders de actieve
-   layout bij het documenttype.
-
-Haal weg:
-- elke eigen HTML-sjabloon die om de layout heen print;
-- elke gecachte kopie van een layout; de layout wordt per opdracht live gelezen.
-
-Regels:
-- layout_id en printer_id komen uit de Engine (public.pick_enqueue_print_job).
-  Kies zelf nooit een andere layout of printer wanneer die velden gevuld zijn.
-- Statussen blijven binnen de enum print_job_status: wachtend, bezig, voltooid,
-  mislukt, geannuleerd. Andere modules luisteren daarop.
-- Geen PDF én geen layout: markeer de opdracht als mislukt met een leesbare
-  reden in foutmelding. Nooit blanco printen.
-
-CONTROLELIJST
-[ ] Layout aangepast in de Layout maker -> eerstvolgende print toont de wijziging.
-[ ] Klantsticker en Floriday-document komen er exact uit zoals aangeleverd.
+                body: `Deze prompt vervangt niets uit prompt 1 t/m 6; hij komt er bovenop.
+
+Uitgangspunt: wat er geprint wordt is ALTIJD de actuele layout uit de Layout
+maker, gevuld met de echte gegevens van de order en de klant. Enige uitzondering:
+documenten die al als kant-en-klare PDF bestaan (klantstickers en
+Floriday-documenten). Die worden ongewijzigd doorgestuurd.
+
+Volgorde van beslissen bij een printopdracht in public.print_jobs:
+1. Is er een kant-en-klare PDF meegegeven (pdf-veld op de opdracht / bron uit
+   floriday_customer_sticker_pdfs_cache): die PDF ongewijzigd naar de printer.
+   Niet opnieuw opmaken, niet renderen.
+2. Is print_jobs.layout_id gevuld: die layout wint. Negeer een eventueel
+   meegestuurde render_html en render vers uit public.document_layouts.
+3. Pas als beide leeg zijn: meegestuurde render_html, en anders de actieve
+   layout bij het documenttype.
+
+Haal weg:
+- elke eigen HTML-sjabloon die om de layout heen print;
+- elke gecachte kopie van een layout; de layout wordt per opdracht live gelezen.
+
+Regels:
+- layout_id en printer_id komen uit de Engine (public.pick_enqueue_print_job).
+  Kies zelf nooit een andere layout of printer wanneer die velden gevuld zijn.
+- Statussen blijven binnen de enum print_job_status: wachtend, bezig, voltooid,
+  mislukt, geannuleerd. Andere modules luisteren daarop.
+- Geen PDF én geen layout: markeer de opdracht als mislukt met een leesbare
+  reden in foutmelding. Nooit blanco printen.
+
+CONTROLELIJST
+[ ] Layout aangepast in de Layout maker -> eerstvolgende print toont de wijziging.
+[ ] Klantsticker en Floriday-document komen er exact uit zoals aangeleverd.
 [ ] Geen enkele printer- of layoutnaam hardcoded in deze module.`,
             },
             {
@@ -1418,38 +1819,38 @@ CONTROLELIJST
                 title: "Pickstation koppelen aan een printplek",
                 date: "2026-08-25",
                 summary: "Elk pickstation krijgt een printplek uit de Layout maker; de Engine stuurt die printplek mee en kiest zelf geen printer meer.",
-                body: `Deze prompt vervangt niets uit prompt 1 t/m 7; hij komt er bovenop.
-
-Wat er verandert in de Logistiek Engine: public.pick_enqueue_print_job kiest
-geen printer meer. De opdracht krijgt de printplek van het pickstation mee
-(top-level in payload.print_plek_id en in payload.data.print_plek_id) en gaat
-altijd als status 'wachtend' de wachtrij in. De Layout maker bepaalt daarna de
-printer: printplek -> bedrijfsbrede standaardregel, en meldt zelf de reden als
-dat niet lukt.
-
-Wat deze module moet doen:
-- Beheer per pickstation de koppeling naar een printplek in
-  public.print_plek_koppelingen met bron = 'pickstation', bron_id =
-  public.pick_stations.id als tekst, print_plek_id = de gekozen rij uit
-  public.print_plekken. Eén actieve koppeling per pickstation.
-- Toon bij het aanmaken en wijzigen van een pickstation een keuzelijst met
-  actieve printplekken uit public.print_plekken (naam + omschrijving).
-  Verwijder je een pickstation, verwijder dan ook de koppelrij.
-- Hardcode nooit een printplek-, printer- of stationsnaam of -id; alles komt
-  uit de database.
-- Geef _printer_id alleen mee aan pick_enqueue_print_job wanneer een gebruiker
-  bewust handmatig een printer kiest (bijvoorbeeld opnieuw printen). Anders
-  leeg laten.
-- Een pickstation zonder printplek: toon een duidelijke waarschuwing
-  ("Nog geen printplek gekoppeld — de opdracht blijft in de wachtrij staan")
-  in plaats van zelf een printer te kiezen.
-- Blijf de status van public.print_jobs volgen (wachtend, bezig, voltooid,
-  mislukt, geannuleerd) en toon foutmelding van de Layout maker met een knop
-  "opnieuw printen".
-
-CONTROLELIJST
-[ ] Elk pickstation heeft een rij in print_plek_koppelingen.
-[ ] Nieuwe printopdrachten bevatten payload.print_plek_id.
+                body: `Deze prompt vervangt niets uit prompt 1 t/m 7; hij komt er bovenop.
+
+Wat er verandert in de Logistiek Engine: public.pick_enqueue_print_job kiest
+geen printer meer. De opdracht krijgt de printplek van het pickstation mee
+(top-level in payload.print_plek_id en in payload.data.print_plek_id) en gaat
+altijd als status 'wachtend' de wachtrij in. De Layout maker bepaalt daarna de
+printer: printplek -> bedrijfsbrede standaardregel, en meldt zelf de reden als
+dat niet lukt.
+
+Wat deze module moet doen:
+- Beheer per pickstation de koppeling naar een printplek in
+  public.print_plek_koppelingen met bron = 'pickstation', bron_id =
+  public.pick_stations.id als tekst, print_plek_id = de gekozen rij uit
+  public.print_plekken. Eén actieve koppeling per pickstation.
+- Toon bij het aanmaken en wijzigen van een pickstation een keuzelijst met
+  actieve printplekken uit public.print_plekken (naam + omschrijving).
+  Verwijder je een pickstation, verwijder dan ook de koppelrij.
+- Hardcode nooit een printplek-, printer- of stationsnaam of -id; alles komt
+  uit de database.
+- Geef _printer_id alleen mee aan pick_enqueue_print_job wanneer een gebruiker
+  bewust handmatig een printer kiest (bijvoorbeeld opnieuw printen). Anders
+  leeg laten.
+- Een pickstation zonder printplek: toon een duidelijke waarschuwing
+  ("Nog geen printplek gekoppeld — de opdracht blijft in de wachtrij staan")
+  in plaats van zelf een printer te kiezen.
+- Blijf de status van public.print_jobs volgen (wachtend, bezig, voltooid,
+  mislukt, geannuleerd) en toon foutmelding van de Layout maker met een knop
+  "opnieuw printen".
+
+CONTROLELIJST
+[ ] Elk pickstation heeft een rij in print_plek_koppelingen.
+[ ] Nieuwe printopdrachten bevatten payload.print_plek_id.
 [ ] Deze module kiest nergens zelf een printer.`,
             },
             {
@@ -1457,29 +1858,29 @@ CONTROLELIJST
                 title: "Layout per ordersoort uit de Engine, anders de actieve layout",
                 date: "2026-08-26",
                 summary: "De Engine stuurt per werkwijze (ordersoort) een layout mee; is dat veld leeg, dan wint de actieve layout uit de Layout maker.",
-                body: `Deze prompt vervangt niets uit prompt 1 t/m 8; hij komt er bovenop.
-
-Wat er verandert in de Logistiek Engine: per werkwijze (ordersoort) kan een
-gebruiker voor pakbon, sticker, verzendbrief en productiebon kiezen welke
-layout gebruikt wordt. Kiest hij "Automatisch", dan blijft print_jobs.layout_id
-leeg. Dat is een geldige situatie, geen fout.
-
-Vaste volgorde bij het bepalen van wat er geprint wordt:
-1. Kant-en-klare PDF (pdf_url / pdf_base64, bijvoorbeeld Floriday- of
-   klantstickers): ongewijzigd printen, layout negeren.
-2. print_jobs.layout_id gevuld: exact die layout renderen.
-3. Layout_id leeg: de layout die bij dat documenttype op actief staat.
-4. Geen van alle: opdracht op mislukt met de leesbare reden
-   "Maak een layout aan en zet die op actief."
-
-Regels:
-- Kies nooit zelf een andere layout wanneer layout_id gevuld is.
-- Verander de meegestuurde printplek niet; de printer komt uit de Layout maker.
-- Hardcode geen layout-, printer- of documenttypenamen.
-
-CONTROLELIJST
-[ ] Order met meegestuurde layout gebruikt exact die layout.
-[ ] Order zonder layout gebruikt de actieve layout van dat documenttype.
+                body: `Deze prompt vervangt niets uit prompt 1 t/m 8; hij komt er bovenop.
+
+Wat er verandert in de Logistiek Engine: per werkwijze (ordersoort) kan een
+gebruiker voor pakbon, sticker, verzendbrief en productiebon kiezen welke
+layout gebruikt wordt. Kiest hij "Automatisch", dan blijft print_jobs.layout_id
+leeg. Dat is een geldige situatie, geen fout.
+
+Vaste volgorde bij het bepalen van wat er geprint wordt:
+1. Kant-en-klare PDF (pdf_url / pdf_base64, bijvoorbeeld Floriday- of
+   klantstickers): ongewijzigd printen, layout negeren.
+2. print_jobs.layout_id gevuld: exact die layout renderen.
+3. Layout_id leeg: de layout die bij dat documenttype op actief staat.
+4. Geen van alle: opdracht op mislukt met de leesbare reden
+   "Maak een layout aan en zet die op actief."
+
+Regels:
+- Kies nooit zelf een andere layout wanneer layout_id gevuld is.
+- Verander de meegestuurde printplek niet; de printer komt uit de Layout maker.
+- Hardcode geen layout-, printer- of documenttypenamen.
+
+CONTROLELIJST
+[ ] Order met meegestuurde layout gebruikt exact die layout.
+[ ] Order zonder layout gebruikt de actieve layout van dat documenttype.
 [ ] Floriday-PDF wordt ongewijzigd geprint.`,
             },
             {
@@ -1487,41 +1888,41 @@ CONTROLELIJST
                 title: "Karren en orders uit de gedeelde karindex van de Engine",
                 date: "2026-09-01",
                 summary: "pickstation_get_orders_raw geeft nu een veld 'engine' met de canonieke karlijst; die is leidend boven de eigen berekening.",
-                body: `AANVULLING op prompt 1 t/m 9 (die blijven geldig).
-
-GEMETEN PROBLEEM
-Het Picking Station bouwde zijn lijst zelf op uit floriday_salesorders_cache en
-kwam voor vandaag op 2 karren, terwijl de Engine er 38 gepland had staan. Twee
-schermen, twee verhalen.
-
-WAT ER VERANDERT
-public.pickstation_get_orders_raw() geeft dezelfde velden als voorheen
-(floriday, manual, overrides, print_counts) plus twee nieuwe:
-
-  engine        array met één object per (order, kar):
-                pick_date, delivery_date, order_uuid, order_number,
-                order_source, cart_id, cart_index, cart_label, is_shared,
-                task_status, shifted, announced, printed, controlled
-  engine_window { from, to, today } — het venster en de dag volgens de Engine
-
-BOUW DIT
-- Is 'engine' gevuld, gebruik die array als enige bron voor de orderlijst en de
-  karrentelling. Geen eigen indeling of telling meer uit de Floriday-cache.
-- Gebruik engine_window.today als "vandaag"; niet de lokale browserklok.
-- Statusvelden gebruiken om te filteren of te kleuren:
-  announced = staat in de pickwachtrij, printed = al geprint,
-  controlled = al gecontroleerd. Een filter verandert nooit het totaal.
-- Gedeelde kar (is_shared true) telt per dag één keer, maar hoort bij elke
-  order waarin hij zit.
-
-NIET DOEN
-- Geen eigen kartelling uit salesorders, order_carts of taak-payloads.
-- Geen eigen datumvenster of tijdzoneconversie.
-- Geen URL's, project-refs of sleutels hardcoden.
-
-CONTROLELIJST
-[ ] Picking Station, Pick agenda en Controle karren tonen voor vandaag hetzelfde aantal karren.
-[ ] Een geplande maar nog niet aangemelde kar is zichtbaar met status "gepland".
+                body: `AANVULLING op prompt 1 t/m 9 (die blijven geldig).
+
+GEMETEN PROBLEEM
+Het Picking Station bouwde zijn lijst zelf op uit floriday_salesorders_cache en
+kwam voor vandaag op 2 karren, terwijl de Engine er 38 gepland had staan. Twee
+schermen, twee verhalen.
+
+WAT ER VERANDERT
+public.pickstation_get_orders_raw() geeft dezelfde velden als voorheen
+(floriday, manual, overrides, print_counts) plus twee nieuwe:
+
+  engine        array met één object per (order, kar):
+                pick_date, delivery_date, order_uuid, order_number,
+                order_source, cart_id, cart_index, cart_label, is_shared,
+                task_status, shifted, announced, printed, controlled
+  engine_window { from, to, today } — het venster en de dag volgens de Engine
+
+BOUW DIT
+- Is 'engine' gevuld, gebruik die array als enige bron voor de orderlijst en de
+  karrentelling. Geen eigen indeling of telling meer uit de Floriday-cache.
+- Gebruik engine_window.today als "vandaag"; niet de lokale browserklok.
+- Statusvelden gebruiken om te filteren of te kleuren:
+  announced = staat in de pickwachtrij, printed = al geprint,
+  controlled = al gecontroleerd. Een filter verandert nooit het totaal.
+- Gedeelde kar (is_shared true) telt per dag één keer, maar hoort bij elke
+  order waarin hij zit.
+
+NIET DOEN
+- Geen eigen kartelling uit salesorders, order_carts of taak-payloads.
+- Geen eigen datumvenster of tijdzoneconversie.
+- Geen URL's, project-refs of sleutels hardcoden.
+
+CONTROLELIJST
+[ ] Picking Station, Pick agenda en Controle karren tonen voor vandaag hetzelfde aantal karren.
+[ ] Een geplande maar nog niet aangemelde kar is zichtbaar met status "gepland".
 [ ] Geen enkele query meer rechtstreeks op floriday_salesorders_cache voor aantallen.`,
             },
             {
@@ -1529,34 +1930,34 @@ CONTROLELIJST
                 title: "Volle kar of deelorder: pickeenheid en pakbonvariant uit de taak",
                 date: "2026-09-03",
                 summary: "De Engine kent nu de werkwijze \"kleinste telt\" en zet pickUnit en slipVariant in de taak-payload; het pickscherm rekent niets zelf uit.",
-                body: `AANVULLING op prompt 1 t/m 10 (die blijven geldig).
-
-WAT ER VERANDERT
-In de Rule Engine kan als pickmethode "Picken per kar of order, kleinste telt"
-gekozen worden: past een order binnen één kar, dan is de order de pickeenheid;
-gaat hij over meerdere karren, dan wordt er per kar gepickt.
-
-De Engine zet dit in de payload van pick.execute en print.packing_slip:
-
-  pickMode      de ingestelde werkwijze (order | cart | smallest | buffer)
-  pickUnit      de werkelijke eenheid van deze opdracht: "order" of "cart"
-  totalCarriers aantal ladingdragers van de order
-  slipVariant   "full_cart" of "partial_order"
-
-BOUW DIT
-- Toon en groepeer pickopdrachten op basis van pickUnit, niet op pickMode.
-- Stuur slipVariant ongewijzigd mee bij het aanvragen of printen van de pakbon.
-- De layoutkeuze gebeurt in de database (logistics_document_layout_v2); het
-  pickscherm kiest zelf geen layout en geen documenttype.
-
-NIET DOEN
-- Niet zelf bepalen of een order een volle kar is.
-- Geen eigen kartelling; de karindex uit prompt 10 blijft de bron.
-- Geen URL's, project-refs, sleutels of klantnamen hardcoden.
-
-CONTROLELIJST
-[ ] Order binnen één kar levert één pickopdracht per order op.
-[ ] Order over meerdere karren levert een opdracht per kar op.
+                body: `AANVULLING op prompt 1 t/m 10 (die blijven geldig).
+
+WAT ER VERANDERT
+In de Rule Engine kan als pickmethode "Picken per kar of order, kleinste telt"
+gekozen worden: past een order binnen één kar, dan is de order de pickeenheid;
+gaat hij over meerdere karren, dan wordt er per kar gepickt.
+
+De Engine zet dit in de payload van pick.execute en print.packing_slip:
+
+  pickMode      de ingestelde werkwijze (order | cart | smallest | buffer)
+  pickUnit      de werkelijke eenheid van deze opdracht: "order" of "cart"
+  totalCarriers aantal ladingdragers van de order
+  slipVariant   "full_cart" of "partial_order"
+
+BOUW DIT
+- Toon en groepeer pickopdrachten op basis van pickUnit, niet op pickMode.
+- Stuur slipVariant ongewijzigd mee bij het aanvragen of printen van de pakbon.
+- De layoutkeuze gebeurt in de database (logistics_document_layout_v2); het
+  pickscherm kiest zelf geen layout en geen documenttype.
+
+NIET DOEN
+- Niet zelf bepalen of een order een volle kar is.
+- Geen eigen kartelling; de karindex uit prompt 10 blijft de bron.
+- Geen URL's, project-refs, sleutels of klantnamen hardcoden.
+
+CONTROLELIJST
+[ ] Order binnen één kar levert één pickopdracht per order op.
+[ ] Order over meerdere karren levert een opdracht per kar op.
 [ ] De pakbon van een deelorder gebruikt de deelorder-layout als die ingesteld is.`,
             },
             {
@@ -1564,44 +1965,44 @@ CONTROLELIJST
                 title: "Eén order in beeld, picken per kar: \u201cKar X van Y\u201d en een pakbon per kar",
                 date: "2026-09-03",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 11: de order blijft één geheel in het scherm, maar het picken en de pakbonnen lopen per kar via logistics_cart_slip_plan.",
-                body: `AANVULLING op prompt 1 t/m 11 (die blijven geldig).
-
-WAT ER VERANDERT
-Bij "kleinste telt" blijft een order in het Pick Station één order, ook als hij
-over meerdere karren gaat. Tijdens het picken moet zichtbaar zijn met welke kar
-de medewerker bezig is en welke regels bij die kar horen.
-
-BRON — verplicht
-const { data } = await supabase.rpc("logistics_cart_slip_plan", { p_order_id });
-
-Levert per order:
-  cartTotal                       aantal karren van de order
-  carts[].cartId                  unieke identificatie van de kar
-  carts[].cartIndex / cartTotal   voor "Kar 2 van 3"
-  carts[].cartLabel               kant-en-klare tekst "Kar 2 van 3"
-  carts[].isFullCart              volle kar of deelkar
-  carts[].slipVariant             "full_cart" of "partial_order"
-  carts[].barcode                 vaste barcode van die kar
-  carts[].items[]                 producten en aantallen VAN DIE KAR
-  carts[].isShared                gemengde kar (meerdere orders)
-
-BOUW DIT
-- Toon de order als één regel/kaart met daarin de karren uit carts[].
-- Toon per kar de cartLabel en uitsluitend carts[].items van die kar.
-- Een kar kan afzonderlijk afgerond worden; de order is pas klaar als alle
-  karren klaar zijn.
-- Bij printen van de pakbon stuur je cart_id mee in de payload van de
-  wachtrijregel (veld "cartId" of "cart_id"). De database bepaalt daarmee
-  automatisch de juiste pakbonvariant, "Kar X van Y" en de barcode.
-
-NIET DOEN
-- Niet zelf verdelen over karren of aantallen per kar uitrekenen.
-- Niet zelf de layout of de pakbonvariant kiezen.
-- Geen URL's, project-refs, sleutels of klantnamen hardcoden.
-
-CONTROLELIJST
-[ ] Een order van 3 karren staat als één order in beeld, met 3 karren eronder.
-[ ] Elke kar toont alleen zijn eigen producten en aantallen.
+                body: `AANVULLING op prompt 1 t/m 11 (die blijven geldig).
+
+WAT ER VERANDERT
+Bij "kleinste telt" blijft een order in het Pick Station één order, ook als hij
+over meerdere karren gaat. Tijdens het picken moet zichtbaar zijn met welke kar
+de medewerker bezig is en welke regels bij die kar horen.
+
+BRON — verplicht
+const { data } = await supabase.rpc("logistics_cart_slip_plan", { p_order_id });
+
+Levert per order:
+  cartTotal                       aantal karren van de order
+  carts[].cartId                  unieke identificatie van de kar
+  carts[].cartIndex / cartTotal   voor "Kar 2 van 3"
+  carts[].cartLabel               kant-en-klare tekst "Kar 2 van 3"
+  carts[].isFullCart              volle kar of deelkar
+  carts[].slipVariant             "full_cart" of "partial_order"
+  carts[].barcode                 vaste barcode van die kar
+  carts[].items[]                 producten en aantallen VAN DIE KAR
+  carts[].isShared                gemengde kar (meerdere orders)
+
+BOUW DIT
+- Toon de order als één regel/kaart met daarin de karren uit carts[].
+- Toon per kar de cartLabel en uitsluitend carts[].items van die kar.
+- Een kar kan afzonderlijk afgerond worden; de order is pas klaar als alle
+  karren klaar zijn.
+- Bij printen van de pakbon stuur je cart_id mee in de payload van de
+  wachtrijregel (veld "cartId" of "cart_id"). De database bepaalt daarmee
+  automatisch de juiste pakbonvariant, "Kar X van Y" en de barcode.
+
+NIET DOEN
+- Niet zelf verdelen over karren of aantallen per kar uitrekenen.
+- Niet zelf de layout of de pakbonvariant kiezen.
+- Geen URL's, project-refs, sleutels of klantnamen hardcoden.
+
+CONTROLELIJST
+[ ] Een order van 3 karren staat als één order in beeld, met 3 karren eronder.
+[ ] Elke kar toont alleen zijn eigen producten en aantallen.
 [ ] Er komt één pakbon per kar; de laatste, niet-volle kar krijgt de deelkar-layout.`,
             },
             {
@@ -1609,51 +2010,322 @@ CONTROLELIJST
                 title: "Pakbon scannen levert de juiste verzendbrief",
                 date: "2026-09-03",
                 summary: "Nieuwe eis bovenop prompt 1 t/m 12: scan de barcode van de pakbon en laat de Engine de bijbehorende verzendbrief klaarzetten.",
-                body: `AANVULLING op prompt 1 t/m 12 (die blijven geldig).
-
-WERKWIJZE
-Picken -> pakbon printen -> barcode van de pakbon scannen -> verzendbrief.
-
-STAP 1 — opzoeken (leest alleen, maakt niets aan)
-const { data } = await supabase.rpc("logistics_barcode_lookup", { p_barcode });
-Antwoord bij succes: ok true, orderId, order.orderNumber, order.customerName,
-cart (met cartLabel, items, slipVariant) en alreadyPrinted/printCount.
-Antwoord bij een probleem: ok false met errorCode
-(leeg | ongeldig | onbekend | geen_order) en een kant-en-klare Nederlandse tekst
-in "error". Toon die tekst letterlijk; verzin geen eigen melding.
-
-STAP 2 — bevestigen en aanmaken
-Laat de gevonden order en kar eerst ter controle zien. Pas na een expliciete
-bevestiging:
-const { data } = await supabase.rpc("logistics_shipping_note_from_barcode", {
-  p_barcode, p_allow_reprint: false, p_station_id: <pickstation of null>
-});
-Is er al eerder een verzendbrief voor deze kar gemaakt, dan komt errorCode
-"al_geprint" terug. Alleen als de medewerker daarna bewust kiest voor opnieuw
-printen roep je dezelfde RPC aan met p_allow_reprint: true.
-
-De RPC zet zelf een printopdracht klaar (print_jobs, status wachtend) met de
-juiste layout en printplek. Ontbreekt de layout, dan staat dat leesbaar in
-"warning" en blijft de job wachten — toon die waarschuwing.
-
-NIET DOEN
-- Nooit een verzendbrief aanmaken zonder bevestigde lookup.
-- Niet zelf print_jobs vullen of zelf een layout kiezen.
-- Geen tweede verzendbrief bij een dubbele scan zonder bewuste keuze.
-- Geen URL's, project-refs, sleutels of klantnamen hardcoden.
-
-LAYOUT MAKER
-Op de pakbon-template hoort een barcode-element met als waarde het veld
-"barcode" uit de meegeleverde printgegevens (ook beschikbaar als
-payload.data.cart.barcode). Positie en weergave bepaal je in de template zelf.
-Er zijn twee pakbonvarianten: volledige kar en resterende order / deelkar.
-
-CONTROLELIJST
-[ ] Scannen van een pakbon toont eerst order, kar en aantallen.
-[ ] Na bevestigen staat er een verzendbrief klaar bij de juiste printer.
-[ ] Een onbekende barcode geeft de melding uit de RPC en maakt niets aan.
+                body: `AANVULLING op prompt 1 t/m 12 (die blijven geldig).
+
+WERKWIJZE
+Picken -> pakbon printen -> barcode van de pakbon scannen -> verzendbrief.
+
+STAP 1 — opzoeken (leest alleen, maakt niets aan)
+const { data } = await supabase.rpc("logistics_barcode_lookup", { p_barcode });
+Antwoord bij succes: ok true, orderId, order.orderNumber, order.customerName,
+cart (met cartLabel, items, slipVariant) en alreadyPrinted/printCount.
+Antwoord bij een probleem: ok false met errorCode
+(leeg | ongeldig | onbekend | geen_order) en een kant-en-klare Nederlandse tekst
+in "error". Toon die tekst letterlijk; verzin geen eigen melding.
+
+STAP 2 — bevestigen en aanmaken
+Laat de gevonden order en kar eerst ter controle zien. Pas na een expliciete
+bevestiging:
+const { data } = await supabase.rpc("logistics_shipping_note_from_barcode", {
+  p_barcode, p_allow_reprint: false, p_station_id: <pickstation of null>
+});
+Is er al eerder een verzendbrief voor deze kar gemaakt, dan komt errorCode
+"al_geprint" terug. Alleen als de medewerker daarna bewust kiest voor opnieuw
+printen roep je dezelfde RPC aan met p_allow_reprint: true.
+
+De RPC zet zelf een printopdracht klaar (print_jobs, status wachtend) met de
+juiste layout en printplek. Ontbreekt de layout, dan staat dat leesbaar in
+"warning" en blijft de job wachten — toon die waarschuwing.
+
+NIET DOEN
+- Nooit een verzendbrief aanmaken zonder bevestigde lookup.
+- Niet zelf print_jobs vullen of zelf een layout kiezen.
+- Geen tweede verzendbrief bij een dubbele scan zonder bewuste keuze.
+- Geen URL's, project-refs, sleutels of klantnamen hardcoden.
+
+LAYOUT MAKER
+Op de pakbon-template hoort een barcode-element met als waarde het veld
+"barcode" uit de meegeleverde printgegevens (ook beschikbaar als
+payload.data.cart.barcode). Positie en weergave bepaal je in de template zelf.
+Er zijn twee pakbonvarianten: volledige kar en resterende order / deelkar.
+
+CONTROLELIJST
+[ ] Scannen van een pakbon toont eerst order, kar en aantallen.
+[ ] Na bevestigen staat er een verzendbrief klaar bij de juiste printer.
+[ ] Een onbekende barcode geeft de melding uit de RPC en maakt niets aan.
 [ ] Een tweede scan waarschuwt en print pas na een bewuste keuze opnieuw.`,
             },
+            {
+                number: 14,
+                title: "Stickers printen automatisch mee met de pakbon",
+                date: "2026-09-03",
+                summary: "Nieuwe eis bovenop prompt 1 t/m 13: bij de instelling \u201cgelijk met de bijbehorende pakbon\u201d maakt de Engine de stickerprintopdracht zelf aan.",
+                body: `AANVULLING op prompt 1 t/m 13 (die blijven geldig).
+
+WAT ER VERANDERT
+Staat in de Logistiek Engine bij Stickers de keuze "Gelijk met de bijbehorende
+pakbon" aan, dan zet pick_enqueue_print_job naast de pakbon meteen ook een
+stickerprintopdracht klaar. Dat gebeurt in de database, dus voor elk pickstation
+precies hetzelfde. Het pickscherm hoeft daar niets extra's voor te doen.
+
+REGELS
+- Roep gewoon pick_enqueue_print_job aan zoals nu; niet zelf een tweede
+  printopdracht voor stickers aanmaken.
+- De sticker krijgt dezelfde printplek als de pakbon (het pickstation van de
+  regel) en de stickerlayout uit de Engine-instelling.
+- Herken de bijbehorende stickerjob aan payload.trigger = "with_packing_slip"
+  en payload.packing_slip_job_id; toon hem bij de pakbon in de statusweergave.
+- Ontbreekt er een actieve stickerlayout, dan blijft de job op "wachtend" staan
+  met een leesbare foutmelding; toon die melding.
+- Geen eigen stationkeuze voor stickers meer: die volgt de pakbon.
+
+CONTROLELIJST
+[ ] Eén druk op "uitprinten" levert pakbon en sticker samen.
+[ ] Beide jobs staan op dezelfde printplek.
+[ ] Zonder stickerlayout is de reden zichtbaar in het scherm.`,
+            },
+            {
+                number: 15,
+                title: "Afgehandelde karren en orders verdwijnen uit het pickscherm",
+                date: "2026-09-03",
+                summary: "Nieuwe eis bovenop prompt 1 t/m 14: wat bij Karrencontrole is afgemeld, wordt niet meer getoond in het pickingscherm.",
+                body: `AANVULLING op prompt 1 t/m 14 (die blijven geldig).
+
+WAT ER VERANDERT
+Zodra een kar bij Karrencontrole in de Afhandelmodule is afgemeld (goedgekeurd
+of afgeleverd), is die kar "afgehandeld". Is elke kar van een order afgehandeld,
+dan is de hele order afgehandeld. De Engine haalt die karren en orders zelf weg:
+
+- public.logistics_cart_handled(order_id, cart_index) - is deze kar afgehandeld?
+- public.logistics_order_handled(order_uuid) - is de hele order afgehandeld?
+- pickstation_get_orders_raw levert afgehandelde karren en volledig afgehandelde
+  orders niet meer terug (ook niet in de floriday- en handmatige lijst).
+- pick_queue-regels van een volledig afgehandelde order worden direct verwijderd,
+  ook tijdens de pickdag.
+
+REGELS
+- Bouw geen eigen "verbergen"-logica en filter niet zelf op controlestatus;
+  wat de RPC teruggeeft is de volledige werkvoorraad.
+- Een kar die verdwijnt terwijl het scherm openstaat is normaal: ververs op de
+  gebruikelijke manier en toon geen foutmelding.
+- Reeds geprinte documenten blijven geldig; herprinten van een afgehandelde kar
+  gebeurt niet meer vanuit het pickscherm.
+- Geen omgevingswaarden of klantspecifieke ID's in code.
+
+CONTROLELIJST
+[ ] Kar afmelden bij Karrencontrole -> kar weg uit het pickscherm.
+[ ] Laatste kar van een order afmelden -> hele order weg uit het pickscherm.
+[ ] Nog niet afgehandelde karren blijven gewoon zichtbaar.`,
+            },
+            {
+                number: 16,
+                title: "Karnummer per order: cart_seq en cart_number tonen",
+                date: "2026-09-03",
+                summary: "Karnummers komen uit de Engine: toon cart_seq en cart_number, nooit cart_index, en reken zelf niets om.",
+                body: `AANVULLING op de eerdere prompts (die blijven geldig).
+
+WAT ER VERANDERT
+De Engine levert vanaf nu per kar een stabiel karnummer. Modules rekenen zelf
+NIETS meer om en hernummeren niet.
+
+VELDEN (uit de Engine-RPC's)
+- cart_seq  : stabiel, 1-gebaseerd volgnummer van de kar binnen zijn order.
+  Identiek aan het nummer op de pakbon in de verkoopmodule. Verandert niet als
+  karren op verschillende dagen gepickt of gecontroleerd worden, en niet als een
+  deel van de karren al is afgehandeld.
+- cart_number : het definitieve karnummer-label (bijv. het toegewezen
+  karnummer uit de karnummering). Toon dit als label.
+- cart_total  : het aantal karren van die order ("Kar X van Y" = cart_seq van
+  cart_total).
+- cart_index  : INTERN. Technische index, niet gedefinieerd als 0- of
+  1-gebaseerd. NOOIT tonen en nooit als basis voor eigen nummering gebruiken.
+
+WAAR STAAN DE VELDEN
+control_get_todays_carts(), logistics_pick_agenda(p_from, p_to) (per order in
+cartList), logistics_cart_index(p_from, p_to), logistics_control_scan_lookup(
+p_barcode) (cartSeq / cartNumber / cartTotal) en
+logistics_control_scan_overview(p_scanner_id, p_date).
+
+GEBRUIK IN DEZE MODULE
+Het pickstation toont per kar "Kar cart_seq van cart_total" en het label
+cart_number, gelijk aan de pakbon.
+
+NIET DOEN
+- Niet zelf nummeren, sorteren op index, of +1 optellen bij cart_index.
+- Geen aparte nummering per dag, per pickronde of per controlesessie.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Elk karnummer in het scherm komt uit cart_seq / cart_number.
+[ ] "Kar X van Y" gebruikt cart_seq en cart_total.
+[ ] Een order met 4 karren toont 1 t/m 4, ook als er al karren afgehandeld zijn.
+[ ] Het getoonde nummer is gelijk aan het nummer op de pakbon.
+[ ] cart_index komt nergens in de weergave voor.`,
+            },
+            {
+                number: 17,
+                title: "Een bufferorder is één order op het pickscherm",
+                date: "2026-09-05",
+                summary: "Orders die samen in een orderbuffer zitten, tonen als één order met één gezamenlijke karrenindeling.",
+                body: `AANVULLING op de eerdere prompts (die blijven geldig).
+
+WAT ER VERANDERT
+Orders die samen in één orderbuffer zitten, zijn logistiek één order. De Engine
+levert ze vanaf nu ook als één eenheid aan. Het pickscherm toont ze dus als ÉÉN
+order met ÉÉN karrenindeling, niet als losse orders met elk hun eigen karren.
+
+BRON
+- pickstation_get_orders_raw() -> engine[]: per kar met
+  order_number (= unit_ref, het leidende ordernummer van de eenheid),
+  unit_ref, is_buffer, buffer_id, buffer_orders[] (alle ordernummers in de
+  buffer), member_order_number (intern), cart_id, cart_seq, cart_number,
+  cart_total.
+- Dezelfde eenheid staat in logistics_cart_units(p_from, p_to),
+  logistics_pick_agenda() en control_get_todays_carts().
+- pickstation_get_orders_raw().units is een map ordernummer -> eenheid, om een
+  losse order naar zijn eenheid te vertalen.
+
+GEBRUIK IN DEZE MODULE
+- Groepeer alles op unit_ref. Toon één regel/kaart per eenheid.
+- Karnummering loopt door over de hele eenheid: cart_seq 1..cart_total.
+- Is is_buffer waar, toon dan de losse ordernummers uit buffer_orders als
+  subregel ("bevat: HO-... , HO-..."), maar nooit als aparte pickorders.
+- De pakbon komt op het leidende ordernummer (PB-<unit_ref>); er is per eenheid
+  één pakbonregel in pick_queue.
+
+NIET DOEN
+- Niet groeperen op member_order_number of op de losse orders uit manual[].
+- Niet zelf karren optellen of hernummeren per losse order.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Twee orders in dezelfde buffer staan als één order op het scherm.
+[ ] De karren van beide orders staan onder één doorlopende nummering.
+[ ] Er is één pakbon per eenheid, niet één per losse order.
+[ ] Losse orders zonder buffer werken exact zoals voorheen.`,
+            },
+            {
+                number: 18,
+                title: "Ook bij handmatig kiezen van een pickdag één bufferregel",
+                date: "2026-09-05",
+                summary: "Voorkom dat het laden van een gekozen pickdag de losse leden van een buffer opnieuw als aparte pakbonregels toevoegt.",
+                body: `AANVULLING op prompt 17 (die blijft geldig).
+
+PROBLEEM
+De algemene Engine-synchronisatie groepeert een buffer correct, maar
+pick_sync_pick_day(_day) kan de leden opnieuw afzonderlijk in public.pick_queue
+zetten. Daardoor verschijnen na het kiezen van een datum toch twee regels.
+
+VASTE WERKWIJZE
+- Gebruik public.logistics_pick_units() als leidende vertaling van order_number
+  naar unit_ref, unit_buffer, is_buffer en unit_orders.
+- Verwerk bij het laden van een pickdag één keer per unit_ref, nooit één keer
+  per los ordernummer.
+- Schrijf de pakbonregel op het leidende unit_ref met documentnummer
+  PB-<unit_ref>.
+- Tel line_count over alle order-id's uit de eenheid en tel alle unieke karren
+  van de orders én de gezamenlijke buffer.
+- Neem in payload altijd unitRef, bufferId, isBuffer, bufferOrders en orderIds
+  op. Gebruik geen stil alternatief op basis van het losse ordernummer.
+- Ruim vóór het tonen niet-leidende, nog niet afgeronde bufferregels op via
+  public.logistics_prune_buffer_member_queue().
+
+WEERGAVE
+- Groepeer de zichtbare wachtrij aanvullend op payload.unitRef; gebruik bij
+  oudere rijen de units-map uit pickstation_get_orders_raw() om order_number
+  eerst naar unit_ref te vertalen.
+- Toon bufferOrders alleen als subregel en nooit als losse tabelregels.
+
+NIET DOEN
+- pick_sync_pick_day niet rechtstreeks gebruiken zonder bovenstaande
+  buffer-normalisatie.
+- Niet groeperen op order_number, document_number of payload.orderId.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Een buffer met twee orders levert na datum wisselen precies één regel op.
+[ ] De regel bevat het totaal van alle orderregels en alle unieke bufferkarren.
+[ ] Terugschakelen van dag of verversen maakt geen tweede regel aan.
+[ ] Een al geprinte historische regel blijft bewaard, maar is niet opnieuw zichtbaar.`,
+            },
+            {
+                number: 19,
+                title: "Bufferorder tonen als bufferorder, ook bij printopdrachten",
+                date: "2026-09-05",
+                summary: "Toon nooit de losse ordernummers van een buffer; gebruik het bufferlabel en negeer geannuleerde printopdrachten van bufferleden.",
+                body: `AANVULLING op prompt 17 en 18 (die blijven geldig).
+
+PROBLEEM
+De wachtrij toonde de buffer één keer, maar het scherm vult zichzelf ook aan
+met wachtende rijen uit public.print_jobs. Van een meelopend bufferlid stond
+daar nog een wachtende pakbon, waardoor de buffer alsnog als twee losse orders
+(PB-HO-... en PB-HO-...) op het scherm kwam.
+
+VASTE WERKWIJZE
+- Toon uitsluitend printopdrachten met status 'wachtend'; opdrachten met status
+  'geannuleerd' verdwijnen direct uit de lijst.
+- Vertaal het ordernummer van elke printopdracht eerst via
+  public.logistics_pick_units() naar unit_ref en toon maximaal één regel per
+  unit_ref per documentsoort.
+- Gebruik als zichtbare titel payload.unitLabel wanneer die aanwezig is
+  (bijvoorbeeld "Bufferorder <unit_ref> (2 orders)"). Toon de losse
+  ordernummers uit bufferOrders alleen als subregel onder die ene regel.
+- De Engine annuleert wachtende printopdrachten van niet-leidende bufferleden
+  bij elke opruimronde; maak zelf nooit een nieuwe aan voor een meelopend lid.
+
+NIET DOEN
+- Geen regel tonen op basis van alleen print_jobs.payload.order_number.
+- Geen eigen documentnummer of ordernummer verzinnen voor een buffer.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Een buffer met twee orders geeft precies één regel, met bufferlabel.
+[ ] Geannuleerde printopdrachten van bufferleden zijn niet meer zichtbaar.
+[ ] De subregels tonen de losse ordernummers van de buffer.`,
+            },
+            {
+                number: 20,
+                title: "Karplanning opvragen bij de Engine, nooit zelf bepalen",
+                date: "2026-09-05",
+                summary: "Eén vraag aan de Engine bepaalt of het karplan klaar is en of de order vrijgegeven is; alleen dan een seintje sturen.",
+                body: `AANVULLING op prompt 17 t/m 19 (die blijven geldig).
+
+PROBLEEM
+Het pickscherm meldt "karplanning nog niet klaar" terwijl de Engine wél een
+sluitend karplan heeft vastgelegd. Het scherm zoekt zelf naar karren bij een
+pakbonnummer en concludeert bij een misser onterecht dat het plan ontbreekt.
+Daarnaast verschijnen orders die door de Engine nog niet zijn vrijgegeven.
+
+VASTE WERKWIJZE
+- Vraag per order of pakbon exact één keer:
+  select public.logistics_cart_plan_status('<ordernummer of PB-nummer>')
+  De uitkomst is één JSON-object met:
+  ready, reason, orderId, orderRef, released, cartTotal en
+  carts[] met cartId, cartNumber, cartSeq, cartTotal, cartLabel, barcode,
+  isShared, isFullCart, slipVariant.
+- ready = true: gebruik uitsluitend deze karren, karnummers, labels en
+  barcodes. Nooit zelf tellen, nummeren of een barcode afleiden.
+- ready = false: toon reason letterlijk als reden en stuur pas dán het seintje
+  cartplan.missing in public.logistics_events (zoals in de bestaande afspraak).
+- released = false: toon de order nog niet als te printen of te picken. Het
+  vrijgavemoment komt van de Engine (logistics_order_released), niet van de
+  leverdatum of de pickdag.
+- Voor een bufferorder geeft elk lid via zijn eigen order-UUID hetzelfde plan
+  met dezelfde cartId's en hetzelfde totaal; toon één regel per unit_ref.
+
+NIET DOEN
+- Geen eigen zoekopdracht op order_carts of print_jobs om te bepalen of er een
+  karplan bestaat.
+- Geen "voorlopig één pakbon als één document" fallback bij ready = false;
+  fail closed met de reden uit de Engine.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Een order met een bestaand plan toont nooit meer "karplanning nog niet klaar".
+[ ] Een niet-vrijgegeven order staat niet op het pickscherm.
+[ ] Karnummers, labels en barcodes komen letterlijk uit de Engine.
+[ ] Bij ready = false gaat er één seintje cartplan.missing uit, met de reden.`,
+            },
         ],
     },
     scanners: {
@@ -1666,14 +2338,236 @@ CONTROLELIJST
                 date: "2026-07-24",
                 summary: "Scan- en controletaken uitvoeren.",
                 withSharedContract: true,
-                body: `Haal weg: eigen aannames over wat en wanneer er gescand moet worden.
-
-Bouw:
-- scan.verify taken; payload reason = pick_scanner_required of kar_vullen_manual_scan.
-- control.execute taken met controlMode "scanner" = de scancontrole.
-- Scanresultaat meesturen in logistics_complete_task (p_result).
+                body: `Haal weg: eigen aannames over wat en wanneer er gescand moet worden.
+
+Bouw:
+- scan.verify taken; payload reason = pick_scanner_required of kar_vullen_manual_scan.
+- control.execute taken met controlMode "scanner" = de scancontrole.
+- Scanresultaat meesturen in logistics_complete_task (p_result).
 - Bij afwijking logistics_fail_task met toelichting.`,
             },
+            {
+                number: 2,
+                title: "Een gescande code eerst door de Engine laten herkennen",
+                date: "2026-09-03",
+                summary: "Nieuwe eis bovenop prompt 1: pakbon-/karbarcodes niet meer als onbekend product melden, maar opzoeken via logistics_scan_resolve.",
+                body: `AANVULLING op koppelprompt 1 (die blijft gewoon geldig).
+
+Probleem: een barcode van een pakbon (formaat LC + 16 tekens, bijvoorbeeld
+LC5E28A9B4B9124ED1) werd afgewezen met "Onbekend product". Die code hoort niet
+bij een product maar bij een kar en de pakbon van die kar.
+
+Bouw:
+- Elke gescande of ingetypte code die niet als product wordt herkend, eerst
+  door de Engine laten herkennen:
+
+  const { data } = await supabase.rpc("logistics_scan_resolve", { p_code: code });
+
+  Losse spaties, kleine letters of extra tekens rond de code hoeven niet zelf
+  te worden opgeschoond; dat doet de RPC.
+
+- data.kind = "kar_pakbon" en data.ok = true -> toon:
+    data.order.orderNumber, data.order.customerName, data.order.deliveryDate
+    data.cart.cartNumber, data.cart.cartIndex / data.cart.cartTotal
+    data.packingSlip.documentName (het pakbonnummer, kan null zijn)
+    data.alreadyPrinted / data.printCount (al eerder gescand)
+    data.warning (indien gevuld: tonen als waarschuwing, niet als fout)
+  Ga daarna verder in de karflow; behandel dit NOOIT als productscan.
+
+- data.ok = false -> toon data.error letterlijk. Verzin geen eigen tekst.
+  errorCode "kar_vervallen" betekent: de pakbon is verouderd, de kar is opnieuw
+  ingedeeld; toon de order erbij en vraag om een nieuwe pakbon te printen.
+  errorCode "onbekend"/"ongeldig" -> pas dan mag de melding "Onbekend product".
+
+- Doe zelf geen lookup op order_carts, logistics_cart_barcode of op stukjes van
+  een uuid. De koppeling barcode -> kar -> pakbon is van de Engine.`,
+            },
+            {
+                number: 3,
+                title: "Gedrukte pakbon is leidend bij het scannen",
+                date: "2026-09-03",
+                summary: "Pakbonbarcodes worden vóór productcodes opgezocht in de blijvende pakbonregistratie, ook wanneer de oorspronkelijke kar opnieuw is ingedeeld.",
+                body: `AANVULLING op koppelprompt 1 en 2 (die blijven geldig, niets samenvoegen
+of terugdraaien).
+
+BEVESTIGD PROBLEEM
+Een pakbonbarcode staat blijvend in pakbon_barcode_inhoud, maar de tijdelijke
+order_carts-rij kan na een herindeling zijn verwijderd. De code is dan nog
+steeds een geldige pakbonbarcode en mag nooit als "Onbekend product" worden
+behandeld.
+
+BOUW DIT
+- Herken het formaat LC + 16 hextekens direct na de camerascan, vóór iedere
+  productlookup. Stuur zo'n code altijd eerst naar de Engine:
+
+    const { data } = await supabase.rpc("logistics_scan_resolve", {
+      p_code: gescandeCode,
+    });
+
+- data.kind = "kar_pakbon" betekent dat dit de pakbon-/karflow is. Stuur deze
+  code nooit daarna nog door naar de productlookup.
+- data.ok = true: toon exact de meegeleverde packingSlip, orders, klant,
+  cartLabel/cartIndex/cartTotal en regels/belading.
+- data.stale = true of data.processingAllowed = false: de barcode is wel als
+  pakbon herkend, maar de indeling is gewijzigd. Toon data.warning of
+  data.error letterlijk en blokkeer goedkeuren. Bied alleen "Pakbon opnieuw
+  printen" aan via de bestaande Engine-flow.
+- data.ok = false en errorCode = "onbekend" of "ongeldig": pas dan mag de
+  bestaande productlookup volgen. Alleen wanneer ook die lookup niets vindt,
+  toon je "Onbekend product".
+- Ondersteun meerdere orders in data.orders; kies of raad nooit zelf één order
+  bij een gedeelde kar.
+- Blokkeer de actieknop tijdens de RPC en verwerk één camerascan maar één keer.
+
+NIET DOEN
+- Niet eisen dat de oorspronkelijke order_carts-rij nog bestaat om een
+  gedrukte pakbon te herkennen.
+- Geen eigen query op pakbon_barcode_inhoud, logistics_cart_barcode,
+  order_carts, print_jobs of uuid-fragmenten.
+- Geen eigen pakbon-, order- of kargegevens samenstellen.
+- Geen URL's, sleutels, project-refs, klantnamen of apparaat-ID's hardcoden.
+
+CONTROLELIJST
+[ ] Een actuele LC-code opent direct de juiste pakbon-/karflow.
+[ ] Een LC-code van vóór een herindeling wordt als verouderde pakbon herkend,
+    niet als onbekend product.
+[ ] Pakbonnummer, order(s), klant, Kar X van Y en belading komen uit de Engine.
+[ ] Een gedeelde kar toont alle gekoppelde orders.
+[ ] Een dubbele camerascan start geen dubbele controle of afleverbrief.`,
+            },
+            {
+                number: 4,
+                title: "Alleen echte geprinte pakbonnen tonen",
+                date: "2026-09-03",
+                summary: "Vervang demo- en lokale pakbonlijsten door het canonieke overzicht van werkelijk voltooide pakbonprints uit de Engine.",
+                body: `AANVULLING op koppelprompt 1 t/m 3 (die blijven geldig, niets
+samenvoegen of terugdraaien).
+
+BEVESTIGD PROBLEEM
+De zichtbare voorbeeldkaarten kwamen uit oude demodata in scan_pakbonnen. De
+echte pakbonnen worden bij het printen
+blijvend geregistreerd in pakbon_barcode_inhoud. De Scanner-module mag daarom
+geen lokale voorbeeldlijst, seed of directe query op scan_pakbonnen meer gebruiken.
+
+BOUW DIT
+- Haal de lijst "Open pakbonnen" uitsluitend op via:
+
+    const { data, error } = await supabase.rpc("scan_open_pakbonnen", {
+      p_dagen: 1,
+    });
+
+- Bewaak serverdata altijd voordat je erover itereert:
+
+    const openPakbonnen = Array.isArray(data) ? data : [];
+
+- De RPC levert alleen werkelijk voltooide pakbonprints en restpakbonnen die nog
+  verwerkt moeten worden. Gebruik de velden letterlijk uit het resultaat:
+  barcode, order_number, order_ref, klant_naam, cart_label, cart_index,
+  cart_total, soort, bron en created_at.
+- Gebruik barcode als duurzame selectie-identiteit. Gebruik NOOIT een zelf
+  verzonnen UUID of een id uit scan_pakbonnen voor een gewone geprinte pakbon.
+- Start/vervolg de verwerking van een gekozen kaart via dezelfde barcodeflow:
+
+    const { data: toegevoegd } = await supabase.rpc("scan_pakbon_toevoegen", {
+      p_scanner_id: scannerId,
+      p_barcode: pakbon.barcode,
+      p_regels: null,
+      p_medewerker: medewerkerNaam ?? null,
+    });
+
+  Gebruik scan_start_kar(p_pakbon_ids) NIET voor deze kaarten; die oude functie
+  verwacht UUID's uit scan_pakbonnen en hoort niet bij het duurzame contract.
+- Een klik op een kaart en een camera-/handscan moeten exact dezelfde pakbonflow
+  openen. Een LC-code gaat altijd eerst naar:
+
+    const { data: resolved } = await supabase.rpc("logistics_scan_resolve", {
+      p_code: barcode,
+    });
+
+- Toon alleen gegevens die de Engine teruggeeft. Als een veld ontbreekt, laat de
+  betreffende regel weg; gebruik geen vaste aantallen of verzonnen buffernaam.
+- Gebruik voor status, regels, meerdere orders en de beslissing of verwerken is
+  toegestaan uitsluitend het resultaat van logistics_scan_resolve. Bij
+  resolved.stale = true of resolved.processingAllowed = false: toon de pakbon
+  met de waarschuwing van de Engine, maar blokkeer "Volgende" en goedkeuren.
+- Een gedeelde kar kan meerdere orders bevatten. Toon alle resolved.orders en
+  kies of raad nooit zelf één order.
+- Na printen, vergrendelen, scannen en afhandelen moet de lijst direct opnieuw
+  worden opgehaald. Een Realtime-subscription mag alleen in useEffect worden
+  gemaakt en moet in de cleanup via supabase.removeChannel(channel) verdwijnen.
+- Is openPakbonnen leeg, toon dan alleen de lege staat "Geen open pakbonnen".
+  Voeg NOOIT demo-, mock- of fallbackpakbonnen toe.
+- Blokkeer knoppen tijdens een lopende RPC. Eén barcode, dubbelklik of dubbele
+  cameradetectie mag nooit twee sessies, controles of documenten aanmaken.
+
+VERWIJDER UIT DE MODULE
+- Alle arrays, fixtures, voorbeeldorders, voorbeeldklanten en voorbeeldbuffers.
+- Iedere directe .from("scan_pakbonnen")-query voor de open lijst.
+- Iedere aanroep van scan_start_kar met ids van kaarten uit scan_open_pakbonnen.
+- Iedere terugval op voorbeelddata wanneer de database leeg is of een fout geeft.
+
+FOUTAFHANDELING
+- Bij een RPC-fout: toon een leesbare fout en een knop "Opnieuw proberen"; toon
+  nooit oude of voorbeelddata als vervanging.
+- Gebruik voor scannen en verwerken uitsluitend de status, warning, error en
+  errorCode die de Engine teruggeeft.
+- Hardcodeer geen URL's, sleutels, project-refs, klantnamen, orders, database-ID's
+  of apparaat-ID's.
+
+CONTROLELIJST
+[ ] Voorbeeldpakbonnen en voorbeeldorders zijn nergens zichtbaar.
+[ ] Een nieuw voltooide pakbonprint verschijnt in de lijst.
+[ ] Een herprint geeft geen dubbele kaart.
+[ ] Kaartselectie en LC-scan openen dezelfde pakbon.
+[ ] Pakbonnummer, klant, order(s), Kar X van Y en aantallen komen uit de Engine.
+[ ] Een afgehandelde kar verdwijnt direct.
+[ ] Een lege database toont geen demo-fallback.`,
+            },
+            {
+                number: 5,
+                title: "Karnummer per order: cart_seq en cart_number tonen",
+                date: "2026-09-03",
+                summary: "Karnummers komen uit de Engine: toon cart_seq en cart_number, nooit cart_index, en reken zelf niets om.",
+                body: `AANVULLING op de eerdere prompts (die blijven geldig).
+
+WAT ER VERANDERT
+De Engine levert vanaf nu per kar een stabiel karnummer. Modules rekenen zelf
+NIETS meer om en hernummeren niet.
+
+VELDEN (uit de Engine-RPC's)
+- cart_seq  : stabiel, 1-gebaseerd volgnummer van de kar binnen zijn order.
+  Identiek aan het nummer op de pakbon in de verkoopmodule. Verandert niet als
+  karren op verschillende dagen gepickt of gecontroleerd worden, en niet als een
+  deel van de karren al is afgehandeld.
+- cart_number : het definitieve karnummer-label (bijv. het toegewezen
+  karnummer uit de karnummering). Toon dit als label.
+- cart_total  : het aantal karren van die order ("Kar X van Y" = cart_seq van
+  cart_total).
+- cart_index  : INTERN. Technische index, niet gedefinieerd als 0- of
+  1-gebaseerd. NOOIT tonen en nooit als basis voor eigen nummering gebruiken.
+
+WAAR STAAN DE VELDEN
+control_get_todays_carts(), logistics_pick_agenda(p_from, p_to) (per order in
+cartList), logistics_cart_index(p_from, p_to), logistics_control_scan_lookup(
+p_barcode) (cartSeq / cartNumber / cartTotal) en
+logistics_control_scan_overview(p_scanner_id, p_date).
+
+GEBRUIK IN DEZE MODULE
+Zowel de open-pakbonlijst als het scanresultaat tonen het karnummer uit de
+Engine. Sorteer een order op cart_seq.
+
+NIET DOEN
+- Niet zelf nummeren, sorteren op index, of +1 optellen bij cart_index.
+- Geen aparte nummering per dag, per pickronde of per controlesessie.
+- Geen URL's, sleutels, project-refs, klantnamen of vaste id's in code.
+
+CONTROLELIJST
+[ ] Elk karnummer in het scherm komt uit cart_seq / cart_number.
+[ ] "Kar X van Y" gebruikt cart_seq en cart_total.
+[ ] Een order met 4 karren toont 1 t/m 4, ook als er al karren afgehandeld zijn.
+[ ] Het getoonde nummer is gelijk aan het nummer op de pakbon.
+[ ] cart_index komt nergens in de weergave voor.`,
+            },
         ],
     },
     voorraad: {
@@ -1686,11 +2580,11 @@ Bouw:
                 date: "2026-07-24",
                 summary: "Reserveringstaken uitvoeren en voorraadwijzigingen melden.",
                 withSharedContract: true,
-                body: `Haal weg: eigen beslissing wanneer er gereserveerd of afgeboekt wordt.
-
-Bouw:
-- stock.reserve taken uitvoeren; payload bevat loadCarriers.
-- Bij relevante voorraadwijziging een gebeurtenis melden met event_type
+                body: `Haal weg: eigen beslissing wanneer er gereserveerd of afgeboekt wordt.
+
+Bouw:
+- stock.reserve taken uitvoeren; payload bevat loadCarriers.
+- Bij relevante voorraadwijziging een gebeurtenis melden met event_type
   stock.changed en dezelfde order_ref, zodat de Engine kan herplannen.`,
             },
         ],
@@ -1705,10 +2599,10 @@ Bouw:
                 date: "2026-07-24",
                 summary: "Strategie koppelen aan klant en klantgroep.",
                 withSharedContract: true,
-                body: `Bouw:
-- Per klant en per klantgroep een koppelveld naar de logistieke strategie
-  (logistics_strategies.id), zodat de Engine weet welke rule config geldt.
-- Dit veld meegeven als strategy_id bij logistics_emit_event, of beschikbaar
+                body: `Bouw:
+- Per klant en per klantgroep een koppelveld naar de logistieke strategie
+  (logistics_strategies.id), zodat de Engine weet welke rule config geldt.
+- Dit veld meegeven als strategy_id bij logistics_emit_event, of beschikbaar
   maken zodat de Verkoop-module het kan meegeven.`,
             },
         ],
@@ -1723,18 +2617,18 @@ Bouw:
                 date: "2026-07-31",
                 summary: "Eerste koppelprompt: mail alleen omzetten naar order als de Engine dat toestaat.",
                 withSharedContract: true,
-                body: `Haal weg: eigen aannames over of een bestelling met te weinig voorraad
-toch mag worden aangemaakt.
-
-${STOCK_CONTRACT}
-
-In de Mailbox-module concreet:
-- Vóór het omzetten van een mail naar een bestelling altijd
-  logistics_check_order_allowed aanroepen met alle orderregels.
-- allowed = false -> maak de bestelling NIET aan. Zet de mail op status
-  "geblokkeerd - onvoldoende voorraad" en toon per product wanted/available/missing
-  uit check.shortages, zodat een medewerker het handmatig kan oplossen.
-- allowed = true -> bestelling normaal aanmaken en daarna de gebeurtenis melden
+                body: `Haal weg: eigen aannames over of een bestelling met te weinig voorraad
+toch mag worden aangemaakt.
+
+${STOCK_CONTRACT}
+
+In de Mailbox-module concreet:
+- Vóór het omzetten van een mail naar een bestelling altijd
+  logistics_check_order_allowed aanroepen met alle orderregels.
+- allowed = false -> maak de bestelling NIET aan. Zet de mail op status
+  "geblokkeerd - onvoldoende voorraad" en toon per product wanted/available/missing
+  uit check.shortages, zodat een medewerker het handmatig kan oplossen.
+- allowed = true -> bestelling normaal aanmaken en daarna de gebeurtenis melden
   via logistics_emit_event (order.received) met een unieke p_idempotency_key.`,
             },
             {
@@ -1742,39 +2636,39 @@ In de Mailbox-module concreet:
                 title: "Bufferbesluit altijd bij de Engine opvragen",
                 date: "2026-08-02",
                 summary: "Nieuwe eis bovenop prompt 1: geen eigen bufferlogica; bufferRef komt uit logistics_buffer_decision.",
-                body: `AANVULLING op koppelprompt 1 (die blijft gewoon geldig).
-
-Haal weg: elke eigen regel of aanname over het samenvoegen van bestellingen uit
-dezelfde mail, dezelfde afzender of hetzelfde afleveradres.
-
-Nieuwe verplichting: vraag na de voorraadcontrole, vóór het aanmaken van de
-bestelling, het bufferbesluit op bij de Engine:
-
-const { data: besluit } = await supabase.rpc("logistics_buffer_decision", {
-  p_order: {
-    orderRef: "MAIL-12345",
-    checkinAt: "2026-08-03T09:00:00Z",
-    deliveryDate: "2026-08-03",
-    customerRef: "CUST-1",
-    floridayCustomerRef: "FLOR-1",
-    bvoCustomerRef: "BVO-1",
-    deliveryLocationRef: "LOC-1",
-    carrierRef: "TRANS-1",
-    loadCarrierType: "trolley",
-    orderType: "standaard",
-  },
-  p_strategy_id: null,
-});
-// besluit = { buffer, reason, bufferRef, bufferKey, matchCriteria,
-//             closeBeforeMinutes, bufferCloseAt, release, trace }
-
-Regels:
-- besluit.buffer === false -> bestelling los aanmaken, geen buffer toewijzen.
-- besluit.buffer === true -> gebruik exact besluit.bufferRef en stuur die mee in de
-  payload van logistics_emit_event.
-- Ontbrekende velden zorgen ervoor dat de Engine NIET combineert; vul daarom altijd
-  alle bovenstaande velden zo compleet mogelijk uit de mail/klantgegevens.
-- Toon besluit.reason en besluit.trace in het mailscherm, zodat een medewerker ziet
+                body: `AANVULLING op koppelprompt 1 (die blijft gewoon geldig).
+
+Haal weg: elke eigen regel of aanname over het samenvoegen van bestellingen uit
+dezelfde mail, dezelfde afzender of hetzelfde afleveradres.
+
+Nieuwe verplichting: vraag na de voorraadcontrole, vóór het aanmaken van de
+bestelling, het bufferbesluit op bij de Engine:
+
+const { data: besluit } = await supabase.rpc("logistics_buffer_decision", {
+  p_order: {
+    orderRef: "MAIL-12345",
+    checkinAt: "2026-08-03T09:00:00Z",
+    deliveryDate: "2026-08-03",
+    customerRef: "CUST-1",
+    floridayCustomerRef: "FLOR-1",
+    bvoCustomerRef: "BVO-1",
+    deliveryLocationRef: "LOC-1",
+    carrierRef: "TRANS-1",
+    loadCarrierType: "trolley",
+    orderType: "standaard",
+  },
+  p_strategy_id: null,
+});
+// besluit = { buffer, reason, bufferRef, bufferKey, matchCriteria,
+//             closeBeforeMinutes, bufferCloseAt, release, trace }
+
+Regels:
+- besluit.buffer === false -> bestelling los aanmaken, geen buffer toewijzen.
+- besluit.buffer === true -> gebruik exact besluit.bufferRef en stuur die mee in de
+  payload van logistics_emit_event.
+- Ontbrekende velden zorgen ervoor dat de Engine NIET combineert; vul daarom altijd
+  alle bovenstaande velden zo compleet mogelijk uit de mail/klantgegevens.
+- Toon besluit.reason en besluit.trace in het mailscherm, zodat een medewerker ziet
   waarom een bestelling wel of niet is samengevoegd.`,
             },
             {
@@ -1782,39 +2676,39 @@ Regels:
                 title: "Alleen ladingdragers gebruiken die de Engine toestaat",
                 date: "2026-08-03",
                 summary: "Nieuwe eis bovenop prompt 1 en 2: uitgeschakelde ladingdragers mogen niet meer worden gekozen of ingelezen.",
-                body: `AANVULLING op koppelprompt 1 en 2 (die blijven gewoon geldig).
-
-In de Rule Engine (stap Beladingindeling) staat welke ladingdragers zijn toegestaan.
-Staat een ladingdrager uit, dan mag de Mailbox-module die niet meer kiezen of
-automatisch invullen.
-
-Haal weg: elke eigen lijst met ladingdragers / verzendmethodes en elke eigen
-vertaling van tekst uit een mail naar een ladingdrager die niet uit de Engine komt.
-
-Nieuwe verplichting: haal de lijst op bij de Engine.
-
-const { data: dragers } = await supabase.rpc("logistics_allowed_load_carriers", {
-  p_strategy_id: null,
-});
-// dragers = { allowed: [...], default: "trolley",
-//             carriers: [{ code, label, enabled, isDefault }, ...] }
-
-Codes en namen (gebruik exact deze codes):
-  trolley            Stapelwagen
-  danish_container   Deense container
-  euro_rolcontainer  Euro-rolcontainer
-  pallet             Pallet
-  euro_pallet        Euro-pallet
-  loose              Geen ladingdrager
-
-Regels:
-- In het mailscherm alleen dragers met enabled === true tonen; de rest weglaten.
-- Herkent de mail een ladingdrager die niet in allowed staat, maak de bestelling dan
-  NIET automatisch aan. Zet de mail op "handmatig controleren - ladingdrager
-  uitgeschakeld" en toon welke drager in de mail stond.
-- Is er niets herkend, gebruik dan dragers.default.
-- Stuur loadCarrierType in logistics_check_order_allowed, logistics_buffer_decision
-  en logistics_emit_event altijd met een van bovenstaande codes mee.
+                body: `AANVULLING op koppelprompt 1 en 2 (die blijven gewoon geldig).
+
+In de Rule Engine (stap Beladingindeling) staat welke ladingdragers zijn toegestaan.
+Staat een ladingdrager uit, dan mag de Mailbox-module die niet meer kiezen of
+automatisch invullen.
+
+Haal weg: elke eigen lijst met ladingdragers / verzendmethodes en elke eigen
+vertaling van tekst uit een mail naar een ladingdrager die niet uit de Engine komt.
+
+Nieuwe verplichting: haal de lijst op bij de Engine.
+
+const { data: dragers } = await supabase.rpc("logistics_allowed_load_carriers", {
+  p_strategy_id: null,
+});
+// dragers = { allowed: [...], default: "trolley",
+//             carriers: [{ code, label, enabled, isDefault }, ...] }
+
+Codes en namen (gebruik exact deze codes):
+  trolley            Stapelwagen
+  danish_container   Deense container
+  euro_rolcontainer  Euro-rolcontainer
+  pallet             Pallet
+  euro_pallet        Euro-pallet
+  loose              Geen ladingdrager
+
+Regels:
+- In het mailscherm alleen dragers met enabled === true tonen; de rest weglaten.
+- Herkent de mail een ladingdrager die niet in allowed staat, maak de bestelling dan
+  NIET automatisch aan. Zet de mail op "handmatig controleren - ladingdrager
+  uitgeschakeld" en toon welke drager in de mail stond.
+- Is er niets herkend, gebruik dan dragers.default.
+- Stuur loadCarrierType in logistics_check_order_allowed, logistics_buffer_decision
+  en logistics_emit_event altijd met een van bovenstaande codes mee.
 - Cache de lijst niet; de instelling kan op elk moment wijzigen.`,
             },
         ],
@@ -1829,56 +2723,56 @@ Regels:
                 date: "2026-08-04",
                 withSharedContract: true,
                 summary: "Deze module schrijft de dagbezetting weg en toont per dag of de Logistics Engine alle ophaalmomenten haalt.",
-                body: `LEES DIT EERST — hoe je deze prompt uitvoert
-
-Deze module is de bron van de bezetting. De Logistics Engine rekent daarmee uit
-of alle karren voor ieder ophaalmoment op tijd gepickt kunnen worden. Je bouwt
-twee dingen: wegschrijven van de planning, en het tonen van de waarschuwing.
-Zelf rekenen doe je niet.
-
-1) Dagbezetting wegschrijven
-   Tabel: public.logistics_staff_planning
-   Kolommen: plan_date (date), staff_count (aantal medewerkers),
-   start_time, end_time (werktijden), source_module, note.
-   Eén rij per dag (uniek op gebruiker + plan_date). Schrijf of update deze rij
-   telkens wanneer de gebruiker de bezetting of de werktijden van een dag
-   wijzigt:
-
-   await supabase.from("logistics_staff_planning").upsert({
-     plan_date: "2026-08-04",
-     staff_count: 7,
-     start_time: "06:00",
-     end_time: "16:00",
-     source_module: "personeelsplanning",
-   }, { onConflict: "user_id,plan_date" })
-
-2) Direct laten herrekenen
-   Roep na iedere wijziging aan:
-     await supabase.rpc("logistics_capacity_plan_day", { p_date: "2026-08-04" })
-   De Engine berekent dan opnieuw of alle ophaalmomenten haalbaar zijn en
-   verplaatst waar nodig automatisch COMPLETE karren naar een later
-   ophaalmoment. Jij verplaatst zelf nooit karren.
-
-3) Rode waarschuwing tonen
-   Tabel: public.logistics_capacity_alerts, filter op plan_date en
-   status = 'open'. Toon op de betreffende dag een duidelijk rode melding met:
-   - shortage_minutes  → hoeveel capaciteit tekort is (toon in uren + minuten)
-   - pickup_label / pickup_time → welk ophaalmoment niet gehaald wordt
-   - carts_short       → hoeveel karren niet op tijd verwerkt kunnen worden
-   - moved_carts       → welke karren automatisch zijn doorgeschoven
-   - unplanned_carts   → welke karren nog steeds niet ingepland kunnen worden
-   Zijn er geen open rijen, toon dan géén waarschuwing (groen/neutraal).
-
-4) Ophaalmomenten
-   Tabel public.logistics_pickup_moments bevat per dag de ophaalmomenten
-   (sequence, label, pickup_time). Gebruik die om de waarschuwing per
-   ophaalmoment te tonen. Aanmaken of wijzigen van ophaalmomenten mag alleen
-   als de gebruiker daar in deze module om vraagt; anders alleen lezen.
-
-5) Wat je NIET doet
-   - Geen eigen capaciteitsberekening of eigen picktijden.
-   - Geen karren splitsen of verplaatsen.
-   - Geen eigen mail sturen bij een tekort; de Engine regelt e-mail en het
+                body: `LEES DIT EERST — hoe je deze prompt uitvoert
+
+Deze module is de bron van de bezetting. De Logistics Engine rekent daarmee uit
+of alle karren voor ieder ophaalmoment op tijd gepickt kunnen worden. Je bouwt
+twee dingen: wegschrijven van de planning, en het tonen van de waarschuwing.
+Zelf rekenen doe je niet.
+
+1) Dagbezetting wegschrijven
+   Tabel: public.logistics_staff_planning
+   Kolommen: plan_date (date), staff_count (aantal medewerkers),
+   start_time, end_time (werktijden), source_module, note.
+   Eén rij per dag (uniek op gebruiker + plan_date). Schrijf of update deze rij
+   telkens wanneer de gebruiker de bezetting of de werktijden van een dag
+   wijzigt:
+
+   await supabase.from("logistics_staff_planning").upsert({
+     plan_date: "2026-08-04",
+     staff_count: 7,
+     start_time: "06:00",
+     end_time: "16:00",
+     source_module: "personeelsplanning",
+   }, { onConflict: "user_id,plan_date" })
+
+2) Direct laten herrekenen
+   Roep na iedere wijziging aan:
+     await supabase.rpc("logistics_capacity_plan_day", { p_date: "2026-08-04" })
+   De Engine berekent dan opnieuw of alle ophaalmomenten haalbaar zijn en
+   verplaatst waar nodig automatisch COMPLETE karren naar een later
+   ophaalmoment. Jij verplaatst zelf nooit karren.
+
+3) Rode waarschuwing tonen
+   Tabel: public.logistics_capacity_alerts, filter op plan_date en
+   status = 'open'. Toon op de betreffende dag een duidelijk rode melding met:
+   - shortage_minutes  → hoeveel capaciteit tekort is (toon in uren + minuten)
+   - pickup_label / pickup_time → welk ophaalmoment niet gehaald wordt
+   - carts_short       → hoeveel karren niet op tijd verwerkt kunnen worden
+   - moved_carts       → welke karren automatisch zijn doorgeschoven
+   - unplanned_carts   → welke karren nog steeds niet ingepland kunnen worden
+   Zijn er geen open rijen, toon dan géén waarschuwing (groen/neutraal).
+
+4) Ophaalmomenten
+   Tabel public.logistics_pickup_moments bevat per dag de ophaalmomenten
+   (sequence, label, pickup_time). Gebruik die om de waarschuwing per
+   ophaalmoment te tonen. Aanmaken of wijzigen van ophaalmomenten mag alleen
+   als de gebruiker daar in deze module om vraagt; anders alleen lezen.
+
+5) Wat je NIET doet
+   - Geen eigen capaciteitsberekening of eigen picktijden.
+   - Geen karren splitsen of verplaatsen.
+   - Geen eigen mail sturen bij een tekort; de Engine regelt e-mail en het
      Meldingencentrum via de instellingen in de Rule Engine.`,
             },
         ],
@@ -1893,38 +2787,38 @@ Zelf rekenen doe je niet.
                 date: "2026-09-03",
                 withSharedContract: true,
                 summary: "Vaste rolverdeling: de Engine bepaalt documentsoort, variant, layout en printplek; de Layout maker rendert en print.",
-                body: `ROLVERDELING
-De Logistics Engine beslist WELK document, in WELKE variant, met WELKE layout,
-op WELKE printplek gedrukt wordt. De Layout maker maakt en rendert de layouts.
-
-WAT DE ENGINE AANLEVERT
-Een printopdracht komt binnen als rij in public.print_jobs met status
-"wachtend". In de payload staan onder meer:
-
-  document_code    pakbon | verzendbrief | afleverbrief | veilingbrief | sticker |
-                   controlelijst | productiebon
-  layout_id        de door de Engine gekozen layout (mag je NIET overrulen)
-  layout_variant   "full_cart" of "partial_order" bij een pakbon
-  print_plek_id    de plek waar het document uit moet komen
-  is_herprint      true bij handmatig opnieuw printen
-  data             de gegevens van het document
-
-BOUW DIT
-- Neem layout_id, print_plek_id en document_code over zoals ze binnenkomen.
-- Kun je niet renderen, zet de job dan op "mislukt" met een leesbare
-  Nederlandse foutmelding in het foutveld; verzin geen vervangende layout.
-- Ontbreekt layout_id, laat de job dan op "wachtend" staan met de melding die de
-  Engine heeft meegegeven; de gebruiker moet de layout in de Rule Engine kiezen.
-
-NIET DOEN
-- Nooit zelf de actieve layout pakken als de Engine er één meestuurt.
-- Nooit zelf een printer of printplek kiezen als print_plek_id gevuld is.
-- Geen URL's, project-refs, sleutels of klantnamen hardcoden; alles uit env
-  en uit de database.
-
-CONTROLELIJST
-[ ] Een job met layout_id gebruikt exact die layout.
-[ ] Een job zonder layout blijft wachten met een leesbare melding.
+                body: `ROLVERDELING
+De Logistics Engine beslist WELK document, in WELKE variant, met WELKE layout,
+op WELKE printplek gedrukt wordt. De Layout maker maakt en rendert de layouts.
+
+WAT DE ENGINE AANLEVERT
+Een printopdracht komt binnen als rij in public.print_jobs met status
+"wachtend". In de payload staan onder meer:
+
+  document_code    pakbon | verzendbrief | afleverbrief | veilingbrief | sticker |
+                   controlelijst | productiebon
+  layout_id        de door de Engine gekozen layout (mag je NIET overrulen)
+  layout_variant   "full_cart" of "partial_order" bij een pakbon
+  print_plek_id    de plek waar het document uit moet komen
+  is_herprint      true bij handmatig opnieuw printen
+  data             de gegevens van het document
+
+BOUW DIT
+- Neem layout_id, print_plek_id en document_code over zoals ze binnenkomen.
+- Kun je niet renderen, zet de job dan op "mislukt" met een leesbare
+  Nederlandse foutmelding in het foutveld; verzin geen vervangende layout.
+- Ontbreekt layout_id, laat de job dan op "wachtend" staan met de melding die de
+  Engine heeft meegegeven; de gebruiker moet de layout in de Rule Engine kiezen.
+
+NIET DOEN
+- Nooit zelf de actieve layout pakken als de Engine er één meestuurt.
+- Nooit zelf een printer of printplek kiezen als print_plek_id gevuld is.
+- Geen URL's, project-refs, sleutels of klantnamen hardcoden; alles uit env
+  en uit de database.
+
+CONTROLELIJST
+[ ] Een job met layout_id gebruikt exact die layout.
+[ ] Een job zonder layout blijft wachten met een leesbare melding.
 [ ] Herprints gebruiken dezelfde layout als de oorspronkelijke print.`,
             },
             {
@@ -1932,39 +2826,119 @@ CONTROLELIJST
                 title: "Twee pakbonvarianten en een barcode op de pakbon",
                 date: "2026-09-03",
                 summary: "Nieuwe eis bovenop prompt 1: aparte templates voor een volle kar en een deelkar, plus een barcode-element dat de verzendbrief-scan mogelijk maakt.",
-                body: `AANVULLING op prompt 1 (die blijft geldig).
-
-TWEE PAKBONVARIANTEN
-De Engine kent twee pakbon-instellingen:
-  "Pakbon volledige kar"              → layout_variant "full_cart"
-  "Pakbon resterende order / deelkar" → layout_variant "partial_order"
-De Engine stuurt de bijbehorende layout_id mee. De Layout maker hoeft alleen te
-zorgen dat beide layouts als documenttype "pakbon" te kiezen zijn. Toon
-layout_variant desgewenst in de voorvertoning, maar kies er niets mee.
-
-BARCODE-ELEMENT OP DE PAKBON
-Voeg aan de pakbon-template een barcode-element toe waarvan de gebruiker zelf
-positie, formaat en weergave bepaalt. De waarde komt UIT de printgegevens:
-
-  payload.barcode            de vaste barcode van deze kar
-  payload.data.cart.barcode  zelfde waarde, in het karblok
-
-Genereer die waarde nooit zelf en tel er niets bij op: de barcode hoort bij
-precies één kar van precies één order en blijft gelijk bij een herprint. De
-verzendbrief wordt later gemaakt door deze barcode te scannen.
-
-KARGEGEVENS DIE JE KUNT AFDRUKKEN
-  cart_label   bijvoorbeeld "Kar 2 van 3"
-  cart_index / cart_total
-  cart_items   producten en aantallen VAN DIE KAR
-  cart_id      interne identificatie
-
-CONTROLELIJST
-[ ] Beide pakbonvarianten zijn als aparte layout aan te maken en te kiezen.
-[ ] De barcode op de afdruk is scanbaar en gelijk aan payload.barcode.
-[ ] Een herprint levert dezelfde barcode op.
+                body: `AANVULLING op prompt 1 (die blijft geldig).
+
+TWEE PAKBONVARIANTEN
+De Engine kent twee pakbon-instellingen:
+  "Pakbon volledige kar"              → layout_variant "full_cart"
+  "Pakbon resterende order / deelkar" → layout_variant "partial_order"
+De Engine stuurt de bijbehorende layout_id mee. De Layout maker hoeft alleen te
+zorgen dat beide layouts als documenttype "pakbon" te kiezen zijn. Toon
+layout_variant desgewenst in de voorvertoning, maar kies er niets mee.
+
+BARCODE-ELEMENT OP DE PAKBON
+Voeg aan de pakbon-template een barcode-element toe waarvan de gebruiker zelf
+positie, formaat en weergave bepaalt. De waarde komt UIT de printgegevens:
+
+  payload.barcode            de vaste barcode van deze kar
+  payload.data.cart.barcode  zelfde waarde, in het karblok
+
+Genereer die waarde nooit zelf en tel er niets bij op: de barcode hoort bij
+precies één kar van precies één order en blijft gelijk bij een herprint. De
+verzendbrief wordt later gemaakt door deze barcode te scannen.
+
+KARGEGEVENS DIE JE KUNT AFDRUKKEN
+  cart_label   bijvoorbeeld "Kar 2 van 3"
+  cart_index / cart_total
+  cart_items   producten en aantallen VAN DIE KAR
+  cart_id      interne identificatie
+
+CONTROLELIJST
+[ ] Beide pakbonvarianten zijn als aparte layout aan te maken en te kiezen.
+[ ] De barcode op de afdruk is scanbaar en gelijk aan payload.barcode.
+[ ] Een herprint levert dezelfde barcode op.
 [ ] "Kar X van Y" en de karregels staan op de juiste pakbon.`,
             },
+            {
+                number: 3,
+                title: "Eén pakbonlayout: bundelen, barcode en variant horen bij de Layout maker",
+                date: "2026-09-03",
+                summary: "De Engine kiest nog maar één pakbonlayout. Of gelijke karren gebundeld worden, of de barcode zichtbaar is en hoe een volle kar en een deelkar eruitzien, bepaalt de Layout maker binnen die layout.",
+                body: `AANVULLING op prompt 1 en 2 (die blijven geldig, met één correctie).
+
+WAT ER VERANDERT
+De Logistiek Engine heeft de dubbele instellingen laten vervallen:
+  - "Gelijke karren op één pakbon"          → vervalt in de Engine
+  - "Barcode op de pakbon" (aan/uit)        → vervalt in de Engine
+  - "Pakbon resterende order / deelkar"     → vervalt als apart layoutveld
+
+Er is nog één instelling: "Pakbon layout". Die layout_id stuurt de Engine bij
+elke printopdracht mee.
+
+WAT DE ENGINE BLIJFT LEVEREN
+  layout_id        de gekozen pakbonlayout
+  layout_variant   "full_cart" of "partial_order" (per opdracht)
+  payload.barcode en payload.data.cart.barcode (alleen bij pickmethode
+                   "kleinste telt"; waarde is vast en blijft gelijk bij herprint)
+  cart_label, cart_index, cart_total, cart_items, cart_id
+
+WAT DE LAYOUT MAKER BEPAALT
+  - bundelen van identieke karren (optie "bundel_identiek")
+  - of en waar de barcode wordt afgedrukt
+  - hoe een volle kar en een deelkar binnen dezelfde layout worden getoond
+    (pickmethode "beide": full_cart toont de karindeling, partial_order alleen
+    de te verzamelen fusten)
+
+Blijft een bestaande installatie twee losse layouts gebruiken, dan blijft dat
+werken: de Engine valt bij een deelkar terug op de enige ingestelde layout.
+
+CONTROLELIJST
+[ ] Eén pakbonlayout van de Engine is genoeg voor beide varianten.
+[ ] De layout bepaalt zelf of gelijke karren gebundeld worden.
+[ ] De barcode wordt alleen afgedrukt als de layout hem bevat én de opdracht een
+    waarde meestuurt; de Layout maker genereert nooit zelf een waarde.
+[ ] Ontbreekt layout_variant bij een layout met methode "beide", dan blijft de
+    job wachten met een leesbare melding.`,
+            },
+            {
+                number: 4,
+                title: "Herprint van Engine-pakbonnen altijd via de Engine",
+                date: "2026-09-04",
+                summary: "Voorkomt orderbrede herprints zonder kar-ID: de knop Opnieuw vraagt de Engine om actuele, afzonderlijke karopdrachten.",
+                body: `AANVULLING op prompt 1 t/m 3; voeg deze eis als afzonderlijke wijziging toe.
+
+PROBLEEM
+De knop "Opnieuw" in de Printwachtrij kopieert nu rechtstreeks een bestaande
+rij uit public.print_jobs. Bij een pakbon van de Logistics Engine kan dat een
+oude orderopdracht zonder cart_id kopiëren. De Layout maker blokkeert die daarna
+terecht, omdat één barcode nooit voor meerdere karren gebruikt mag worden.
+
+HERPRINTREGEL
+Herken een Engine-pickdocument aan payload.queue_item_id in combinatie met
+payload.source = "pickstation" of payload.data.source = "logistiek-engine".
+
+- Roep voor zo'n document public.pick_reprint_document aan met:
+    _queue_item_id = payload.queue_item_id
+    _session_id = een unieke waarde voor deze gebruikersactie
+- Voeg voor dit pad NOOIT rechtstreeks een kopie toe aan public.print_jobs.
+- De Engine leest de actuele karindeling en maakt per kar precies één job met
+  een eigen cart_id en vaste barcode.
+- Toon de herprint als geslaagd wanneer de RPC zonder fout afrondt en ververs
+  daarna de wachtrij.
+- Toon de letterlijke RPC-fout wanneer de order, wachtrijregel of karindeling
+  niet meer bestaat; maak dan geen vervangende orderbrede job.
+
+NORMALE DOCUMENTEN
+Alleen documenten zonder Engine queue_item_id mogen de bestaande algemene
+maakPrintJob-kopieerroute blijven gebruiken.
+
+CONTROLELIJST
+[ ] Een Engine-pakbon met twee karren levert na "Opnieuw" twee karjobs op.
+[ ] Iedere karjob heeft payload.cart_id en een eigen payload.barcode.
+[ ] Er ontstaat nooit een nieuwe Engine-pakbonjob met cart_id null.
+[ ] Een oude of vervallen order geeft een leesbare fout en geen lege job.
+[ ] Geen URL's, sleutels, project-refs, klantnamen of vaste database-id's.`,
+            },
         ],
     },
 };
@@ -1981,16 +2955,16 @@ export const MODULE_PROMPTS = Object.keys(MODULES)
 export function buildRevisionPrompt(prompt, revision) {
     const shared = revision.withSharedContract
         ? `\n## Gedeeld contract\n\n${sharedBlock(prompt.moduleKey)}\n`
-        : `\n(Deze prompt is een aanvulling. Het gedeelde contract uit koppelprompt 1 blijft
+        : `\n(Deze prompt is een aanvulling. Het gedeelde contract uit koppelprompt 1 blijft
 onverkort gelden — niets terugdraaien.)\n`;
-    return `# Koppelprompt ${revision.number} — ${prompt.label}
-## ${revision.title}  (${revision.date})
-
-${revision.summary}
-${shared}
-## Wat deze module moet doen
-
-${revision.body}
+    return `# Koppelprompt ${revision.number} — ${prompt.label}
+## ${revision.title}  (${revision.date})
+
+${revision.summary}
+${shared}
+## Wat deze module moet doen
+
+${revision.body}
 `;
 }
 export function buildModulePrompt(prompt) {
@@ -1998,18 +2972,18 @@ export function buildModulePrompt(prompt) {
 }
 /** Alle modules, met per module de volledige promptgeschiedenis. */
 export function buildAllModulePrompts() {
-    const sections = MODULE_PROMPTS.map((p) => `# ${p.order}. ${p.label} (module: ${p.moduleKey})
-
-${p.summary}
-
+    const sections = MODULE_PROMPTS.map((p) => `# ${p.order}. ${p.label} (module: ${p.moduleKey})
+
+${p.summary}
+
 ${p.revisions.map((r) => buildRevisionPrompt(p, r)).join("\n---\n\n")}`).join("\n\n====================\n\n");
-    return `# Koppelprompts voor de aangesloten modules
-
-Per module staan de prompts op volgorde. Een nieuwe eis komt er altijd als
-NIEUWE prompt bij; eerdere prompts blijven geldig en worden niet herschreven.
-Er worden geen secrets gebruikt: alle communicatie loopt via de gedeelde
-Supabase-database.
-
+    return `# Koppelprompts voor de aangesloten modules
+
+Per module staan de prompts op volgorde. Een nieuwe eis komt er altijd als
+NIEUWE prompt bij; eerdere prompts blijven geldig en worden niet herschreven.
+Er worden geen secrets gebruikt: alle communicatie loopt via de gedeelde
+Supabase-database.
+
 ${sections}`;
 }
 export function modulePromptFilename(moduleKey, revisionNumber) {