Document Shopify webhook worker

docs/modules/erp/import-integration/processes/main/erp.import-integration.shopify_order_sync.md

@@ -4,7 +4,7 @@ Status: Verbindliche Prozess-Spezifikation
 
 ## 1. Zweck
 
-Read-only-Annahme und technische Übergabe von Shopify-Bestellereignissen an das owning Bestellmodul, ohne Schreibzugriffe auf Shopify und ohne Kundenkommunikation.
+Read-only-Annahme und technische Persistenz von Shopify-Bestellereignissen. Die fachliche Verarbeitung erfolgt anschliessend durch den lokalen Webhook-Worker.
 
 ## 2. Prozess-Einbettung
 
@@ -31,8 +31,9 @@ Es werden keine vorbereiteten Geschäftsdaten an nachgelagerte Prozesse übergeb
 6. Für definierte Shopify-Read-Schritte einen kurzlebigen Admin-API-Token über den Client-Credentials-Flow beziehen; der Token wird ausschließlich serverseitig verwendet.
 7. Shopify Order-GID aus dem Ereignis oder durch den definierten Shopify-Read-Schritt bestimmen.
 8. Nur die stabile Ereignis-/Order-Identität an das owning Bestellmodul übergeben.
-9. Keine Shopify-Mutation, keine Fulfillment-Aktion, keine Label-Aktion, kein n8n-Versand und kein Klaviyo-Event auslösen.
+9. Das angenommene Event mit Status `received` für den lokalen Worker bereitstellen.
-10. Technischen Lauf mit kompaktem Ergebnis abschliessen.
+10. Keine Shopify-Mutation und keine fachliche Verarbeitung im HTTP-Request ausführen.
+11. Technischen Lauf mit kompaktem Ergebnis abschliessen.
 
 Read sources:
 
@@ -71,18 +72,22 @@ HTTP 2xx mit kompaktem JSON bei akzeptiertem Eingang, einschliesslich Duplicate-
 - ungültige Signatur wird abgewiesen
 - derselbe Webhook erzeugt keine doppelte Verarbeitung
 - Shopify Order-GID bleibt nachvollziehbar
-- kein externer Schreib- oder Kommunikations-Trigger wird ausgeführt
+- der HTTP-Request bleibt schnell und führt keine fachliche oder externe Verarbeitung aus
 - technischer Lauf ist vollständig protokolliert
 
-## 8. Fehlerschranke
+## 8. Nachgelagerte Verarbeitung
+
+`erp.import-integration.shopify_webhook_worker` verarbeitet `received`-Events lokal, lädt die vollständige Bestellung read-only aus Shopify, projiziert sie ins ERP und löst nach erfolgreichem Commit beide n8n-Webhooks aus. Der Worker läuft ausserhalb des HTTP-Requests und wird über den Synology-Zeitplaner gestartet.
+
+## 9. Fehlerschranke
 
 Ungültige Requests werden ohne fachliche Verarbeitung abgewiesen. Technische Fehler beim Persistieren oder bei der definierten Übergabe führen zu einem technischen Fehler. Wiederholte gültige Eingänge werden idempotent bestätigt. Teilfehler innerhalb der nachgelagerten Batch-/Reconciliation-Prozesse gehören nicht in diesen Einzel-Webhook-Prozess.
 
-## 9. Fachliche Betriebsregel
+## 10. Fachliche Betriebsregel
 
 Shopify ist die führende Quelle für Shop-Bestellungen. Die ERP-Anwendung liest Shopify-Daten; sie schreibt keine Bestell-, Kunden-, Produkt-, Zahlungs-, Refund- oder Fulfillmentdaten zurück nach Shopify. Historische Migration und laufender Sync sind getrennte Prozesse.
 
-## 10. Sub-Prozess-Referenzen
+## 11. Sub-Prozess-Referenzen
 
 - `erp.import-integration.shopify_webhook_authentication`
 - `erp.import-integration.shopify_event_persistence`
@@ -90,26 +95,26 @@ Shopify ist die führende Quelle für Shop-Bestellungen. Die ERP-Anwendung liest
 
 Die genannten Sub-Prozesse müssen vor der Implementierung als eigene verbindliche Verträge dokumentiert werden.
 
-## 11. End-to-End Sub-Prozess-Kette
+## 12. End-to-End Sub-Prozess-Kette
 
 Shopify HTTP-Webhook → Authentifizierung → technische Eingangspersistenz → Bestellmodul-Übergabe → technischer Abschluss.
 
-## 12. Sub-Prozess-Wiederverwendung
+## 13. Sub-Prozess-Wiederverwendung
 
 Bestehende technische Webhook- und DB-Bausteine werden wiederverwendet, sofern sie HMAC-Prüfung, Idempotenz und technische Laufpersistenz ohne fachliche Shopify-Annahmen unterstützen. Eine neue fachliche Bestelllogik im Import-Submodul ist nicht zulässig.
 
-## 13. Step-Liste
+## 14. Step-Liste
 
 1. `shopify_webhook_authentication`
 2. `shopify_event_persistence`
 3. `shopify_order_sync_handoff`
 4. `shopify_sync_result_finalization`
 
-## 14. Parallelisierung
+## 15. Parallelisierung
 
 Nicht anwendbar für den Einzel-Webhook. Parallelisierung erfolgt ausschließlich in einem separaten, batchbasierten Reconciliation-Prozess.
 
-## 15. Output-Payload
+## 16. Output-Payload
 
 ```json
 {
@@ -124,7 +129,7 @@ Nicht anwendbar für den Einzel-Webhook. Parallelisierung erfolgt ausschließlic
 
 Keine Rohpayloads, Kundendaten oder Geschäftsdatasets werden im Response-Payload zurückgegeben.
 
-## 16. Done-Kriterien
+## 17. Done-Kriterien
 
 - Prozess und Sub-Prozesse sind dokumentiert.
 - Endpoint validiert Shopify-HMAC und Pflichtheader.

docs/modules/erp/import-integration/shopify-umstellung-checkliste.md

@@ -159,6 +159,9 @@ Fachliche Übergabe: `erp/bestellungen`
 - [x] Authentifizierungsweg festgelegt: serverseitiger Client-Credentials-Flow für die interne Dev-Dashboard-App.
 - [x] Interaktiver OAuth-Callback als für das API-only-Ziel nicht erforderlich bewertet.
 - [x] Webhook-URL implementiert: `https://erpnaurua.imhochrain.ch/api/shopify/webhooks.php`.
+- [x] Shopify-Subscription `ORDERS_CREATE` auf dem ERP-Webhook registriert.
+- [x] Lokalen Webhook-Worker implementiert, deployed und mit signiertem Testevent verifiziert.
+- [ ] Synology-Zeitplaner für den Worker einrichten.
 - [ ] Webhook-URL in Shopify registrieren.
 - [x] Belegt: Root-Domain ist erreichbar.
 - [x] Belegt: `POST /api/shopify/webhooks.php` liefert bei ungültiger HMAC `401`.