@flowselections/logistiek-engine 1.0.17 → 1.0.19

package/dist-lib/lib/modulePrompts.js

@@ -9,155 +9,155 @@
 import { LOGISTICS_MODULES } from "./logisticsTasks";
 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 +170,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 +187,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 +204,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 +256,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,46 +290,102 @@ 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.`,
             },
+            {
+                number: 6,
+                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.
+- De beslisregel van 26-08 (B1/B2/B3) niet wijzigen — alleen overnemen.`,
+            },
         ],
     },
     afhandeling: {
@@ -342,15 +398,15 @@ Regels:
                 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.`,
             },
             {
@@ -358,28 +414,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.`,
             },
             {
@@ -387,53 +443,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.`,
             },
             {
@@ -441,50 +497,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.`,
             },
             {
@@ -492,131 +548,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.`,
             },
             {
@@ -624,40 +680,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.`,
             },
             {
@@ -665,31 +721,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.`,
             },
             {
@@ -697,28 +753,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.`,
             },
             {
@@ -727,23 +783,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.`,
             },
             {
@@ -751,72 +807,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.`,
             },
         ],
@@ -831,12 +887,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.`,
             },
             {
@@ -844,26 +900,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.`,
             },
             {
@@ -871,32 +927,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.`,
             },
             {
@@ -904,29 +960,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.`,
             },
             {
@@ -934,41 +990,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.`,
             },
             {
@@ -976,50 +1032,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.`,
             },
             {
@@ -1027,37 +1083,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.`,
             },
             {
@@ -1065,38 +1121,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.`,
             },
             {
@@ -1104,29 +1160,29 @@ CONTROLELIJST
                 title: "Layout per ordersoort uit de Engine, anders de actieve layout",
                 date: "2026-08-26",
                 summary: "De Engine stuurt per werkwijze (ordersoort) een layout mee; is dat veld leeg, dan wint de actieve layout uit de Layout maker.",
-                body: `Deze prompt vervangt niets uit prompt 1 t/m 8; hij komt er bovenop.
-
-Wat er verandert in de Logistiek Engine: per werkwijze (ordersoort) kan een
-gebruiker voor pakbon, sticker, verzendbrief en productiebon kiezen welke
-layout gebruikt wordt. Kiest hij "Automatisch", dan blijft print_jobs.layout_id
-leeg. Dat is een geldige situatie, geen fout.
-
-Vaste volgorde bij het bepalen van wat er geprint wordt:
-1. Kant-en-klare PDF (pdf_url / pdf_base64, bijvoorbeeld Floriday- of
-   klantstickers): ongewijzigd printen, layout negeren.
-2. print_jobs.layout_id gevuld: exact die layout renderen.
-3. Layout_id leeg: de layout die bij dat documenttype op actief staat.
-4. Geen van alle: opdracht op mislukt met de leesbare reden
-   "Maak een layout aan en zet die op actief."
-
-Regels:
-- Kies nooit zelf een andere layout wanneer layout_id gevuld is.
-- Verander de meegestuurde printplek niet; de printer komt uit de Layout maker.
-- Hardcode geen layout-, printer- of documenttypenamen.
-
-CONTROLELIJST
-[ ] Order met meegestuurde layout gebruikt exact die layout.
-[ ] Order zonder layout gebruikt de actieve layout van dat documenttype.
+                body: `Deze prompt vervangt niets uit prompt 1 t/m 8; hij komt er bovenop.
+
+Wat er verandert in de Logistiek Engine: per werkwijze (ordersoort) kan een
+gebruiker voor pakbon, sticker, verzendbrief en productiebon kiezen welke
+layout gebruikt wordt. Kiest hij "Automatisch", dan blijft print_jobs.layout_id
+leeg. Dat is een geldige situatie, geen fout.
+
+Vaste volgorde bij het bepalen van wat er geprint wordt:
+1. Kant-en-klare PDF (pdf_url / pdf_base64, bijvoorbeeld Floriday- of
+   klantstickers): ongewijzigd printen, layout negeren.
+2. print_jobs.layout_id gevuld: exact die layout renderen.
+3. Layout_id leeg: de layout die bij dat documenttype op actief staat.
+4. Geen van alle: opdracht op mislukt met de leesbare reden
+   "Maak een layout aan en zet die op actief."
+
+Regels:
+- Kies nooit zelf een andere layout wanneer layout_id gevuld is.
+- Verander de meegestuurde printplek niet; de printer komt uit de Layout maker.
+- Hardcode geen layout-, printer- of documenttypenamen.
+
+CONTROLELIJST
+[ ] Order met meegestuurde layout gebruikt exact die layout.
+[ ] Order zonder layout gebruikt de actieve layout van dat documenttype.
 [ ] Floriday-PDF wordt ongewijzigd geprint.`,
             },
         ],
@@ -1141,12 +1197,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.`,
             },
         ],
@@ -1161,11 +1217,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.`,
             },
         ],
@@ -1180,10 +1236,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.`,
             },
         ],
@@ -1198,18 +1254,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.`,
             },
             {
@@ -1217,39 +1273,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.`,
             },
             {
@@ -1257,39 +1313,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.`,
             },
         ],
@@ -1304,56 +1360,56 @@ Regels:
                 date: "2026-08-04",
                 withSharedContract: true,
                 summary: "Deze module schrijft de dagbezetting weg en toont per dag of de Logistics Engine alle ophaalmomenten haalt.",
-                body: `LEES DIT EERST — hoe je deze prompt uitvoert
-
-Deze module is de bron van de bezetting. De Logistics Engine rekent daarmee uit
-of alle karren voor ieder ophaalmoment op tijd gepickt kunnen worden. Je bouwt
-twee dingen: wegschrijven van de planning, en het tonen van de waarschuwing.
-Zelf rekenen doe je niet.
-
-1) Dagbezetting wegschrijven
-   Tabel: public.logistics_staff_planning
-   Kolommen: plan_date (date), staff_count (aantal medewerkers),
-   start_time, end_time (werktijden), source_module, note.
-   Eén rij per dag (uniek op gebruiker + plan_date). Schrijf of update deze rij
-   telkens wanneer de gebruiker de bezetting of de werktijden van een dag
-   wijzigt:
-
-   await supabase.from("logistics_staff_planning").upsert({
-     plan_date: "2026-08-04",
-     staff_count: 7,
-     start_time: "06:00",
-     end_time: "16:00",
-     source_module: "personeelsplanning",
-   }, { onConflict: "user_id,plan_date" })
-
-2) Direct laten herrekenen
-   Roep na iedere wijziging aan:
-     await supabase.rpc("logistics_capacity_plan_day", { p_date: "2026-08-04" })
-   De Engine berekent dan opnieuw of alle ophaalmomenten haalbaar zijn en
-   verplaatst waar nodig automatisch COMPLETE karren naar een later
-   ophaalmoment. Jij verplaatst zelf nooit karren.
-
-3) Rode waarschuwing tonen
-   Tabel: public.logistics_capacity_alerts, filter op plan_date en
-   status = 'open'. Toon op de betreffende dag een duidelijk rode melding met:
-   - shortage_minutes  → hoeveel capaciteit tekort is (toon in uren + minuten)
-   - pickup_label / pickup_time → welk ophaalmoment niet gehaald wordt
-   - carts_short       → hoeveel karren niet op tijd verwerkt kunnen worden
-   - moved_carts       → welke karren automatisch zijn doorgeschoven
-   - unplanned_carts   → welke karren nog steeds niet ingepland kunnen worden
-   Zijn er geen open rijen, toon dan géén waarschuwing (groen/neutraal).
-
-4) Ophaalmomenten
-   Tabel public.logistics_pickup_moments bevat per dag de ophaalmomenten
-   (sequence, label, pickup_time). Gebruik die om de waarschuwing per
-   ophaalmoment te tonen. Aanmaken of wijzigen van ophaalmomenten mag alleen
-   als de gebruiker daar in deze module om vraagt; anders alleen lezen.
-
-5) Wat je NIET doet
-   - Geen eigen capaciteitsberekening of eigen picktijden.
-   - Geen karren splitsen of verplaatsen.
-   - Geen eigen mail sturen bij een tekort; de Engine regelt e-mail en het
+                body: `LEES DIT EERST — hoe je deze prompt uitvoert
+
+Deze module is de bron van de bezetting. De Logistics Engine rekent daarmee uit
+of alle karren voor ieder ophaalmoment op tijd gepickt kunnen worden. Je bouwt
+twee dingen: wegschrijven van de planning, en het tonen van de waarschuwing.
+Zelf rekenen doe je niet.
+
+1) Dagbezetting wegschrijven
+   Tabel: public.logistics_staff_planning
+   Kolommen: plan_date (date), staff_count (aantal medewerkers),
+   start_time, end_time (werktijden), source_module, note.
+   Eén rij per dag (uniek op gebruiker + plan_date). Schrijf of update deze rij
+   telkens wanneer de gebruiker de bezetting of de werktijden van een dag
+   wijzigt:
+
+   await supabase.from("logistics_staff_planning").upsert({
+     plan_date: "2026-08-04",
+     staff_count: 7,
+     start_time: "06:00",
+     end_time: "16:00",
+     source_module: "personeelsplanning",
+   }, { onConflict: "user_id,plan_date" })
+
+2) Direct laten herrekenen
+   Roep na iedere wijziging aan:
+     await supabase.rpc("logistics_capacity_plan_day", { p_date: "2026-08-04" })
+   De Engine berekent dan opnieuw of alle ophaalmomenten haalbaar zijn en
+   verplaatst waar nodig automatisch COMPLETE karren naar een later
+   ophaalmoment. Jij verplaatst zelf nooit karren.
+
+3) Rode waarschuwing tonen
+   Tabel: public.logistics_capacity_alerts, filter op plan_date en
+   status = 'open'. Toon op de betreffende dag een duidelijk rode melding met:
+   - shortage_minutes  → hoeveel capaciteit tekort is (toon in uren + minuten)
+   - pickup_label / pickup_time → welk ophaalmoment niet gehaald wordt
+   - carts_short       → hoeveel karren niet op tijd verwerkt kunnen worden
+   - moved_carts       → welke karren automatisch zijn doorgeschoven
+   - unplanned_carts   → welke karren nog steeds niet ingepland kunnen worden
+   Zijn er geen open rijen, toon dan géén waarschuwing (groen/neutraal).
+
+4) Ophaalmomenten
+   Tabel public.logistics_pickup_moments bevat per dag de ophaalmomenten
+   (sequence, label, pickup_time). Gebruik die om de waarschuwing per
+   ophaalmoment te tonen. Aanmaken of wijzigen van ophaalmomenten mag alleen
+   als de gebruiker daar in deze module om vraagt; anders alleen lezen.
+
+5) Wat je NIET doet
+   - Geen eigen capaciteitsberekening of eigen picktijden.
+   - Geen karren splitsen of verplaatsen.
+   - Geen eigen mail sturen bij een tekort; de Engine regelt e-mail en het
      Meldingencentrum via de instellingen in de Rule Engine.`,
             },
         ],
@@ -1372,16 +1428,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) {
@@ -1389,18 +1445,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) {