@flowselections/logistiek-engine 1.0.25 → 1.0.26

package/dist-lib/lib/modulePrompts.js

@@ -7,157 +7,166 @@
 // staan en stuur je alleen het nieuwe stuk door.
 // ============================================================================
 import { LOGISTICS_MODULES } from "./logisticsTasks";
+/**
+ * Modules met een koppelprompt. Naast de modules die taken uitvoeren staat hier
+ * ook de Layout maker: die voert geen logistieke taken uit, maar levert wel de
+ * documentlayouts waarmee de Engine print.
+ */
+export const PROMPT_MODULE_LABELS = {
+    ...LOGISTICS_MODULES,
+    layoutmaker: "Layout maker (pakbonnen, verzendbrieven, extra)",
+};
 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: {
@@ -170,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.`,
             },
             {
@@ -187,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.`,
             },
             {
@@ -204,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.`,
             },
             {
@@ -256,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.`,
             },
             {
@@ -290,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.`,
             },
             {
@@ -335,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.`,
             },
             {
@@ -391,42 +400,72 @@ 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.`,
             },
+            {
+                number: 8,
+                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.
+[ ] Geen eigen kartelling meer in de verkoopcode.`,
+            },
         ],
     },
     afhandeling: {
@@ -439,15 +478,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.`,
             },
             {
@@ -455,28 +494,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.`,
             },
             {
@@ -484,53 +523,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.`,
             },
             {
@@ -538,50 +577,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.`,
             },
             {
@@ -589,131 +628,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.`,
             },
             {
@@ -721,40 +760,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.`,
             },
             {
@@ -762,31 +801,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.`,
             },
             {
@@ -794,28 +833,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.`,
             },
             {
@@ -824,23 +863,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.`,
             },
             {
@@ -848,72 +887,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.`,
             },
             {
@@ -921,51 +960,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.`,
             },
             {
@@ -973,50 +1012,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".`,
             },
             {
@@ -1024,42 +1063,85 @@ 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.`,
             },
+            {
+                number: 14,
+                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.
+[ ] Geen eigen kartelling meer in de leveringencode.`,
+            },
         ],
     },
     pickschermen: {
@@ -1072,12 +1154,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.`,
             },
             {
@@ -1085,26 +1167,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.`,
             },
             {
@@ -1112,32 +1194,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.`,
             },
             {
@@ -1145,29 +1227,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.`,
             },
             {
@@ -1175,41 +1257,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.`,
             },
             {
@@ -1217,50 +1299,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.`,
             },
             {
@@ -1268,37 +1350,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.`,
             },
             {
@@ -1306,38 +1388,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.`,
             },
             {
@@ -1345,31 +1427,203 @@ 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.`,
             },
+            {
+                number: 10,
+                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".
+[ ] Geen enkele query meer rechtstreeks op floriday_salesorders_cache voor aantallen.`,
+            },
+            {
+                number: 11,
+                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.
+[ ] De pakbon van een deelorder gebruikt de deelorder-layout als die ingesteld is.`,
+            },
+            {
+                number: 12,
+                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.
+[ ] Er komt één pakbon per kar; de laatste, niet-volle kar krijgt de deelkar-layout.`,
+            },
+            {
+                number: 13,
+                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.
+[ ] Een tweede scan waarschuwt en print pas na een bewuste keuze opnieuw.`,
+            },
         ],
     },
     scanners: {
@@ -1382,12 +1636,12 @@ 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.`,
             },
         ],
@@ -1402,11 +1656,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.`,
             },
         ],
@@ -1421,10 +1675,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.`,
             },
         ],
@@ -1439,18 +1693,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.`,
             },
             {
@@ -1458,39 +1712,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.`,
             },
             {
@@ -1498,39 +1752,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.`,
             },
         ],
@@ -1545,65 +1799,149 @@ 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.`,
             },
         ],
     },
+    layoutmaker: {
+        order: 9,
+        summary: "Levert de documentlayouts. Kiest zelf geen layout en geen printer: de Engine bepaalt welke layout en welke printplek bij een document horen.",
+        revisions: [
+            {
+                number: 1,
+                title: "De Engine kiest de layout, de Layout maker maakt hem",
+                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.
+[ ] Herprints gebruiken dezelfde layout als de oorspronkelijke print.`,
+            },
+            {
+                number: 2,
+                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.
+[ ] "Kar X van Y" en de karregels staan op de juiste pakbon.`,
+            },
+        ],
+    },
 };
 export const MODULE_PROMPTS = Object.keys(MODULES)
     .map((moduleKey) => ({
     moduleKey,
-    label: LOGISTICS_MODULES[moduleKey],
+    label: PROMPT_MODULE_LABELS[moduleKey],
     order: MODULES[moduleKey].order,
     summary: MODULES[moduleKey].summary,
     revisions: [...MODULES[moduleKey].revisions].sort((a, b) => a.number - b.number),
@@ -1613,16 +1951,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) {
@@ -1630,18 +1968,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) {