@flowselections/logistiek-engine 1.0.1

package/dist-lib/lib/modulePrompts.js

@@ -0,0 +1,1195 @@
+// ============================================================================
+// src/lib/modulePrompts.ts — koppelprompts per aangesloten module
+// ============================================================================
+// Elke module heeft een LIJST met prompts. Nieuwe eisen worden NOOIT in een
+// bestaande prompt verwerkt: er komt altijd een nieuwe prompt onder de module
+// bij (oplopend genummerd). Zo kan een al verstuurde prompt gewoon blijven
+// staan en stuur je alleen het nieuwe stuk door.
+// ============================================================================
+import { LOGISTICS_MODULES } from "./logisticsTasks";
+export const LOGISTICS_ENGINE_PROJECT_REF = "wieomvgjyxoerzndxnla";
+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.
+
+Supabase project ref: ${LOGISTICS_ENGINE_PROJECT_REF}
+Client: import { supabase } from "../integrations/supabase/client"
+
+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 });
+- Cache het antwoord niet: de instelling kan op elk moment wijzigen.`;
+const MODULES = {
+    verkoop: {
+        order: 1,
+        summary: "Meldt orders aan de Engine en voert het bufferbesluit uit.",
+        revisions: [
+            {
+                number: 1,
+                title: "Basiskoppeling via de database",
+                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.
+- In schaduwmodus: Engine-buffersluittijd naast de eigen berekening tonen.`,
+            },
+            {
+                number: 2,
+                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.
+- Doe de controle ook opnieuw bij het wijzigen van aantallen of regels.`,
+            },
+            {
+                number: 3,
+                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
+teruggeeft. Al verwerkte/verzonden orders laat je met rust.`,
+            },
+            {
+                number: 4,
+                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
+dezelfde bufferRef hebben.`,
+            },
+            {
+                number: 5,
+                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
+  met een van bovenstaande codes mee, nooit met een eigen naam of vrije tekst.`,
+            },
+        ],
+    },
+    afhandeling: {
+        order: 2,
+        summary: "Voert belading, controle, printen en transport uit volgens de taak-payload.",
+        revisions: [
+            {
+                number: 1,
+                title: "Basiskoppeling via de database",
+                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
+
+Wat er geprint wordt en wanneer komt volledig uit de taak-payload. Geen eigen keuzes meer.`,
+            },
+            {
+                number: 2,
+                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.
+- Is er geen taak voor een document, dan wordt dat document niet geprint.`,
+            },
+            {
+                number: 3,
+                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
+Engine kan herplannen. Val nooit terug op eigen logica.`,
+            },
+            {
+                number: 5,
+                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.
+
+Val nooit terug op eigen logica. Wat de Engine teruggeeft, is leidend.`,
+            },
+            {
+                number: 4,
+                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.
+[ ] Na opslaan worden de taken opnieuw geladen en klopt de agenda.`,
+            },
+            {
+                number: 6,
+                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.
+[ ] De getoonde cijfers komen letterlijk uit de Engine.`,
+            },
+            {
+                number: 7,
+                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.
+[ ] Het Regieoverzicht kan de capaciteitsmeldingen nog steeds tonen.`,
+            },
+            {
+                number: 8,
+                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.
+[ ] Zonder ingevuld personeel toont de melding de invulhint in plaats van 0.`,
+            },
+        ],
+    },
+    pickschermen: {
+        order: 3,
+        summary: "Toont pick-taken op de door de Engine berekende starttijd.",
+        revisions: [
+            {
+                number: 1,
+                title: "Basiskoppeling via de database",
+                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.
+- Te-laat-dreigende belading markeren op basis van planned_end; niet zelf herrekenen.`,
+            },
+            {
+                number: 2,
+                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).
+- Bepaal nooit zelf een vrijgavemoment en print nooit vooruit.`,
+            },
+            {
+                number: 3,
+                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
+  alleen het PDF-bestand.`,
+            },
+            {
+                number: 4,
+                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
+  horen in een apart tabblad, niet in de dagwachtrij.`,
+            },
+            {
+                number: 5,
+                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.
+[ ] Ontbrekende layout geeft een duidelijke melding in plaats van een print.`,
+            },
+            {
+                number: 6,
+                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".
+[ ] De wachtrij wordt alleen afgerond na een geslaagde render/printactie.`,
+            },
+        ],
+    },
+    scanners: {
+        order: 4,
+        summary: "Voert scanverificatie en scancontrole uit wanneer de Engine dat vraagt.",
+        revisions: [
+            {
+                number: 1,
+                title: "Basiskoppeling via de database",
+                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).
+- Bij afwijking logistics_fail_task met toelichting.`,
+            },
+        ],
+    },
+    voorraad: {
+        order: 5,
+        summary: "Reserveert voorraad op commando en meldt wijzigingen terug.",
+        revisions: [
+            {
+                number: 1,
+                title: "Basiskoppeling via de database",
+                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
+  stock.changed en dezelfde order_ref, zodat de Engine kan herplannen.`,
+            },
+        ],
+    },
+    klanten: {
+        order: 6,
+        summary: "Koppelt klanten en klantgroepen aan een logistieke strategie.",
+        revisions: [
+            {
+                number: 1,
+                title: "Basiskoppeling via de database",
+                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
+  maken zodat de Verkoop-module het kan meegeven.`,
+            },
+        ],
+    },
+    mailbox: {
+        order: 7,
+        summary: "Maakt bestellingen aan uit binnenkomende mail; controleert eerst de voorraad.",
+        revisions: [
+            {
+                number: 1,
+                title: "Voorraadcontrole vóór het aanmaken van een bestelling",
+                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
+  via logistics_emit_event (order.received) met een unieke p_idempotency_key.`,
+            },
+            {
+                number: 2,
+                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
+  waarom een bestelling wel of niet is samengevoegd.`,
+            },
+            {
+                number: 3,
+                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.
+- Cache de lijst niet; de instelling kan op elk moment wijzigen.`,
+            },
+        ],
+    },
+    personeelsplanning: {
+        order: 8,
+        summary: "Levert per dag het aantal medewerkers en de werktijden, en toont de rode capaciteitswaarschuwing van de Engine.",
+        revisions: [
+            {
+                number: 1,
+                title: "Personeelsplanning koppelen aan de capaciteitsberekening",
+                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
+     Meldingencentrum via de instellingen in de Rule Engine.`,
+            },
+        ],
+    },
+};
+export const MODULE_PROMPTS = Object.keys(MODULES)
+    .map((moduleKey) => ({
+    moduleKey,
+    label: LOGISTICS_MODULES[moduleKey],
+    order: MODULES[moduleKey].order,
+    summary: MODULES[moduleKey].summary,
+    revisions: [...MODULES[moduleKey].revisions].sort((a, b) => a.number - b.number),
+}))
+    .sort((a, b) => a.order - b.order);
+/** Eén losse prompt (één regel uit de lijst van een module). */
+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
+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}
+`;
+}
+export function buildModulePrompt(prompt) {
+    return prompt.revisions.map((r) => buildRevisionPrompt(prompt, r)).join("\n---\n\n");
+}
+/** 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}
+
+${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.
+
+${sections}`;
+}
+export function modulePromptFilename(moduleKey, revisionNumber) {
+    return revisionNumber
+        ? `logistics-engine-${moduleKey}-prompt-${revisionNumber}.md`
+        : `logistics-engine-${moduleKey}.md`;
+}