Mit Kunde geklärt (28.08.): jede Größe/Variante ist ein eigenes Shop-Produkt mit
eigener Artikelnummer, Bestand wird je Variante getrennt geführt (50 ml ≠ 5 ml).
Kein Roll-up auf ein Basisprodukt. Die umgesetzte AP-34-Logik entspricht damit
exakt dem Kundenmodell — keine Code-Änderung nötig. Nur Plan-Doku ergänzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Klärungspunkte beantwortet (26.08.): Varianten haben eigene Artikelnummer
(Connector sendet künftig Variations-Nr.); Gramm-Rechnung über ml+Dichte auf
Rohstoff- UND Produktebene (Produkt-Füllgewicht, Rohstoff-Dichte); getrennte
pflegbare Buchungsgründe Ein/Aus; Waldbröl auf Köln übernehmen, Funktion bleibt.
Nur D-3 (Shop-Status-Cron) noch kundenseitig in Prüfung. AP-34/35/42/48/50
entsprechend geschärft.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Kundenfeedback aus der Testphase am Code + Live-DB verifiziert und in einen
Umsetzungsplan überführt (AP-34…AP-51, ~15–26 PT): 9 bestätigte Bugs (u. a.
Varianten-Artikelnummer, Produktionsmengen 100 g statt Füllmenge, leere
Rezepturphasen, „Enthalten in"-Doppelung) plus Erweiterungen. WooCommerce-Ampel
ist voraussichtlich shopseitig (Status-Cron/Auth), kein ERP-Fehler. Sechs
Klärungspunkte (D-1…D-6) offen. Noch nichts umgesetzt.
Rohfeedback des Kunden liegt als entwicklungsplan-aktualisiert-2026-08-26.md bei.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bots klopfen /oauth/authorize ohne gültige OAuth-Parameter ab; Passport
wirft dann korrekt einen 4xx-Fehler. Da der Handler bei jeder gemeldeten
Exception mailt und die API ausschliesslich Personal Access Tokens nutzt
(Authorize-Flow nie legitim genutzt), war jede dieser Mails Rauschen.
OAuthServerException wandert in $dontReport – Endpoint-Verhalten bleibt
unveraendert, nur der Mail-Versand fuer diese Client-Fehler entfaellt.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
