Warenwirtschaft: Doku — Gegenprüfung 09.09. mit Nacharbeitsstand R-01/R-02, Nachprüfung/README/V7 aktualisiert

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

dev/product management /01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md

@@ -5,7 +5,7 @@
 > **Vorgänger:** V6.0 ([entwicklungsplan-aktualisiert-2026-07-06.md](entwicklungsplan-aktualisiert-2026-07-06.md))
 > **Verifikation:** Jeder Befund wurde am Code **und** an der eingespielten Live-DB geprüft (Dev-Container). Die Datei-/Zeilenangaben sind der aktuelle Stand.
 > **Status (historisch, 26.08.2026):** Planungsdokument — zu diesem Zeitpunkt noch nichts umgesetzt.
-> **Status (aktuell, 08.09.2026):** AP-34…AP-51 umgesetzt (Tabelle unten). Die anschließende [Umsetzungsprüfung vom 08.09.2026](../02-audit/umsetzungspruefung-2026-09-08.md) fand 18 Restfehler, die ebenfalls alle behoben sind (Abschnitt 9 dort); die [Nachprüfung](../02-audit/nachpruefung-befundbehebung-2026-09-08.md) ergab 6 weitere Restpunkte, ebenfalls behoben (Abschnitt 6 dort). Suite: 368 grün.
+> **Status (aktuell, 08.09.2026):** AP-34…AP-51 umgesetzt (Tabelle unten). Die anschließende [Umsetzungsprüfung vom 08.09.2026](../02-audit/umsetzungspruefung-2026-09-08.md) fand 18 Restfehler, die ebenfalls alle behoben sind (Abschnitt 9 dort); die [Nachprüfung](../02-audit/nachpruefung-befundbehebung-2026-09-08.md) ergab 6 weitere Restpunkte und die Gegenprüfung vom 09.09. zwei Randfälle — alle behoben. Suite: 370 grün.
 
 Die mit **`#`** markierten Punkte hat der Kunde als **buggy/dringend** priorisiert. Aufwände in Personentagen (PT), inkl. Test.
 
@@ -33,7 +33,7 @@ Die mit **`#`** markierten Punkte hat der Kunde als **buggy/dringend** priorisie
 | **AP-38** WooCommerce-Ampel (Cron/Auth) | ✅ erledigt (0c8d321 ERP+Connector, b6ca332 Cron-Selbstheilung) — Live-Ursache behoben |
 | übrige APs | — |
 
-Suite (26.08.2026): **338 grün**; nach der Nacharbeit und Nachprüfung vom 08.09.2026: **368 grün**. Erledigt: **AP-34…AP-51 vollständig** (AP-34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51). **Keine offenen APs mehr.** Verbleibend nur der **Connector-Rollout v1.6.0** in den Shop (AP-34 + AP-38).
+Suite (26.08.2026): **338 grün**; nach Nacharbeit, Nachprüfung und Gegenprüfung (08./09.09.2026): **370 grün**. Erledigt: **AP-34…AP-51 vollständig** (AP-34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51). **Keine offenen APs mehr.** Verbleibend nur der **Connector-Rollout v1.6.0** in den Shop (AP-34 + AP-38).
 
 > **AP-43-Hinweis:** „Zwischenspeichern" legt die Produktion als **Entwurf** ab (kein Bestand gebucht); erst **„Produktion abschließen"** bucht Roh-/Produkt-/Verpackungsbestand. Entwürfe zählen nirgends in den Bestand — auch nicht in die Chargenverfügbarkeit (F-01). Pflicht bleiben im Entwurf nur Produkt, Standort, Datum und Planmenge; Chargen- und Ergebniszeilen dürfen unvollständig sein und werden verlustfrei gesichert (F-03). Eine bereits abgeschlossene Produktion kann nicht zurück in den Entwurf.
 

dev/product management /02-audit/gegenpruefung-restbefunde-2026-09-09.md

@@ -0,0 +1,110 @@
+# Warenwirtschaft: Gegenprüfung der zweiten Nacharbeit vom 09.09.2026
+
+**Ergebnis: Vier der sechs Restbefunde sind im geprüften Umfang behoben. Bei N-02 und N-04 bleiben jeweils konkrete Randfälle offen.** Die ursprünglichen Reproduktionsfälle funktionieren jetzt; die Aussage „alle sechs Restbefunde vollständig umgesetzt“ ist dennoch zu weitgehend.
+
+Die gemeldete Testsuite wurde bestätigt: **368 Tests bestanden, 1.482 Assertions**. Darüber hinaus wurden die vorherigen Diagnosen erneut ausgeführt und um die unten beschriebenen Fälle erweitert. Die beiden verbleibenden Fehler wurden anhand von Testrequests, Datenbankzustand und tatsächlich ausgeführter Formularlogik überprüft.
+
+## 1. Prüfstand und Vorgehen
+
+- Code-Prüfstand: `a439d05a6aa41d11d0eff06fade918173dd64995` einschließlich des vorhandenen Arbeitsverzeichnisses.
+- Geprüfte Änderungen: `520d4e2` (N-02), `313c627` (N-01/N-03/N-05), `9acb053` (N-04), `5d82875` (N-06), Doku-Commit `a439d05`.
+- Referenz: [Nachprüfung vom 08.09.2026](nachpruefung-befundbehebung-2026-09-08.md), einschließlich des nachträglich ergänzten Abschnitts 6 zur Umsetzung.
+- Methoden: Prüfung der geänderten und angrenzenden Codepfade, vollständige vorhandene Testsuite, zusätzliche temporäre PHPUnit-Diagnosen mit SQLite `:memory:`, DOM-Ausführung der von Blade gerenderten JavaScript-Formularlogik einschließlich Select2 beim Einkauf.
+- **Keine Änderungen am Anwendungscode, an bestehenden Tests, Migrationen oder Konfigurationen.** Ausschließlich dieses Dokument wurde im Projekt ergänzt. Keine bestehenden Datenbanken verändert und kein Deployment durchgeführt.
+
+Die schon vorhandenen Änderungen an `app/Repositories/InvoiceRepository.php`, `app/Services/Invoice.php`, `resources/lang/de/email.php` sowie `.claude/`, `AGENTS.md` und `app/Mail/MailCancellation.php` wurden unverändert beibehalten.
+
+## 2. Ergebnis je Restbefund
+
+| Befund | Gegenprüfung | Begründung |
+|---|---|---|
+| **N-01 – Ist-Menge ohne Charge** | **Behoben im ursprünglichen Fehlerfall** | 9,8 g ohne Chargenauswahl bleiben im Entwurf gespeichert; `formBatchKey()` liefert dafür die leere Auswahl. Die vorhandene Regression prüft Wiederöffnen sowie abgelehnten Abschluss ohne Charge und erfolgreichen Abschluss nach Ergänzung. Die unabhängige frühere Verlustdiagnose besteht jetzt. |
+| **N-02 – Stabile Rezepturphasen** | **Teilweise behoben** | Unverändertes Artikelspeichern erhält die Phasenbezüge bei Entwurf und abgeschlossener Produktion. Doppelte Rohstoffe in derselben Phase werden nun abgelehnt. Beim Einfügen und gleichzeitigen Umbenennen kann die Zuordnung über Namen/Reihenfolge jedoch eine bestehende ID der falschen Phase zuweisen. Siehe R-01. |
+| **N-03 – Chargensplit und Verpackungs-Snapshot** | **Behoben im geprüften Umfang** | Die Signatur summiert je Produkt. Der frühere Diagnosefall mit zehn Ergebnisstücken, anschließend geänderter Stückliste und Aufteilung auf 6 + 4 Stück erhält jetzt korrekt den Verbrauch von zehn Verpackungsstücken. |
+| **N-04 – Historische Verpackungsvorschau** | **Teilweise behoben** | Ein vorhandener, nicht leerer Snapshot wird korrekt angezeigt. Änderungen der Ergebnismengen führen zur aktuellen Stückliste, die Rückkehr zu den ursprünglichen Mengen wieder zum Snapshot. Ein gültiger leerer historischer Snapshot wird jedoch nicht berücksichtigt. Siehe R-02. |
+| **N-05 – Alt-Ausschuss ohne Chargenbezug** | **Behoben für die dokumentierte Verfügbarkeitsregel** | Die rein lesende FEFO-Anrechnung je Standort ist in Produktionsverfügbarkeit, Chargenübersicht, Gruppierung/Batch-Check und Chargen-Ausschussprüfung eingebunden. Der alte Fall „1.000 g Eingang minus 1.000 g ungebundener Ausschuss“ ergibt jetzt auch in der Chargenverfügbarkeit null. Die neue Projektregression prüft außerdem mehrere Chargen, einen zweiten Standort und die Ablehnung weiteren Chargenausschusses. |
+| **N-06 – Dichte-Fallback beim Bearbeiten** | **Behoben im ursprünglichen Fehlerfall** | Bei fehlender Stammdatendichte bleibt die kopierte Bestellung auch nach Initialisierung der Bearbeitungsmaske in ml. Speichern und Wareneingang erhalten bei 100 ml und Dichte 0,79 die korrekten 79 g. Der vorhandene Test für den Rohstoffwechsel bestätigt, dass keine fremde alte Dichte als Freigabe übernommen wird. |
+
+Zu N-05: Die implementierte Regel liefert eine rechnerische Verfügbarkeit. Sie rekonstruiert keine historisch belegte Charge der alten Ausschussbuchung und verändert deren Daten nicht. Das entspricht der ausdrücklich dokumentierten Entscheidung; ein nachträglicher Abgleich tatsächlicher Altchargen ist eine andere Aufgabe. Ein Zugriff auf reale Altbestände war für diese Codeprüfung nicht erforderlich und wurde nicht durchgeführt.
+
+## 3. Noch offene Fehler
+
+### R-01 / N-02 – Einfügen einer Phase und gleichzeitiges Umbenennen kann Produktionsmengen der falschen Phase zuordnen
+
+**Priorität: P1 – Gespeicherte Ist-Mengen fehlen beim Wiederöffnen; weiteres Zwischenspeichern kann sie verwerfen.**
+
+**Fundstelle:** `app/Repositories/ProductRepository.php:381`, besonders die Zuordnung des ersten verbliebenen Datensatzes ab Zeile 390. Folgewirkung in `resources/views/admin/inventory/productions/_scripts.blade.php:272` und `app/Http/Controllers/Admin/Inventory/ProductionController.php` in `existingLines()`.
+
+Die Phasen werden weiterhin nicht über eine vom Formular übermittelte stabile Identität zugeordnet. Zunächst werden gleiche Namen gesucht; danach erhält jeder noch nicht zugeordnete Formularblock die nächste übrige Phase. Ein neuer Block kann deshalb die ID einer umbenannten bestehenden Phase übernehmen.
+
+**Reproduktion mit zwei unterschiedlichen Rohstoffen, ohne doppelte Rezepturzeilen:**
+
+1. Phase A enthält Rohstoff X mit 6 g; Phase B enthält Rohstoff Y mit 4 g. Einen Produktionsentwurf mit diesen Ist-Mengen anlegen. Im Test haben die Phasen die IDs 1 und 2.
+2. Im Artikel eine neue reine Textphase „Vorbereitung“ voranstellen und die bisherige Phase B in „Phase B neu“ umbenennen. Rohstoff X bleibt in A, Rohstoff Y bleibt in der umbenannten B. Gemeinsam speichern.
+3. Die neue Zuordnung lautet:
+
+| Formularphase | Erwartete Identität | Tatsächliche Identität |
+|---|---|---|
+| Vorbereitung, neu und ohne Rohstoff | Neue ID | **Alte ID 2 der bisherigen Phase B** |
+| Phase A | Alte ID 1 | Alte ID 1 |
+| Phase B neu, weiterhin Rohstoff Y | Alte ID 2 | **Neue ID 3** |
+
+4. Die gespeicherte 4-g-Produktionszeile verweist weiterhin auf ID 2, die jetzt zur rohstofflosen Vorbereitung gehört. Im tatsächlich ausgeführten Produktionsformular erscheinen **6 g und ein leeres Feld statt 6 g und 4 g**. Die Summe der wiederhergestellten Eingaben sinkt von zehn auf sechs Gramm.
+
+**Nachweisgrenze:** Beim Artikelspeichern selbst wurden die vier Gramm noch nicht aus der Produktionsdatenbank gelöscht; ihre Phase wurde falsch zugeordnet. Der anschließende Verlust im Formular ist im DOM reproduziert. Dass ein weiterer Entwurfsspeichervorgang die nicht mehr übermittelten Zeilen entfernen kann, folgt aus dem vorhandenen Löschen/Neuanlegen der Verbrauchszeilen in `updateProduction()`.
+
+**Empfohlene Korrektur:** Bestehende Phasen-IDs im Artikelformular mitführen und serverseitig gegen Produkt und Rezepturtyp prüfen. Neue Phasen ausdrücklich als neu behandeln. Namen und Positionen dürfen sich ändern, ohne die Identität zu wechseln. Für tatsächlich entfernte Phasen die bereits diskutierte Behandlung historischer Produktionsbezüge separat festlegen.
+
+**Erforderliche Regression:** Neue Phase voranstellen und bestehende Phase im selben Speichervorgang umbenennen. Danach den Produktionsentwurf öffnen und prüfen, dass jede Ist-Menge in ihrer ursprünglichen fachlichen Phase steht. Zusätzlich Umordnen mit Umbenennen sowie gleiche Phasennamen abdecken.
+
+Der neue vorhandene Test prüft Umbenennen plus Anhängen einer weiteren Phase. Das funktioniert mit der gewählten Zuordnungsreihenfolge, deckt aber das Einfügen vor der umbenannten Phase nicht ab.
+
+### R-02 / N-04 – Ein historischer Verbrauch von null wird nicht als gültiger Snapshot erkannt
+
+**Priorität: P2 – Verpackungsvorschau widerspricht der tatsächlichen Speicherung.**
+
+**Fundstellen:** `resources/views/admin/inventory/productions/_scripts.blade.php:397` und `:407`; Datenübergabe in `app/Http/Controllers/Admin/Inventory/ProductionController.php:162`.
+
+Die Vorschau verwendet den historischen Verbrauch nur bei `packagingSnapshot.length > 0`. Eine abgeschlossene Produktion kann jedoch rechtmäßig ohne Verpackungsstückliste und damit ohne Verpackungszeilen gespeichert worden sein. Dieser leere historische Snapshot ist fachlich gültig; der Service erhält ihn bei unveränderten Produktsummen ebenso wie einen nicht leeren Snapshot.
+
+**Reproduktion:**
+
+1. Ein Ergebnisstück ohne hinterlegte Verpackung produzieren. Historischer Verbrauch: **0**.
+2. Am Artikel nachträglich eine Stückliste mit **2 Tiegeln je Stück** hinterlegen.
+3. Die abgeschlossene Produktion unverändert öffnen. Die Vorschau zeigt **2 Tiegel** und erkennt keinen historischen Snapshot.
+4. Nur die Notiz korrigieren und speichern. Der Service behält korrekt **0 Tiegel** bei.
+
+Der Datenbank-/Servicetest bestätigt die null vor und nach der Speicherung; die DOM-Prüfung bestätigt die falsche Vorschau von zwei Stück.
+
+**Empfohlene Korrektur:** Gesondert übermitteln, ob eine gebuchte Produktion mit anwendbarem historischem Snapshot bearbeitet wird. Dies nicht aus der Anzahl der Snapshot-Zeilen ableiten. Bei unveränderten Ergebnissummen auch einen leeren Snapshot als „kein Verpackungsverbrauch“ anzeigen; bei echter Mengen-/Produktänderung die vorgesehene Neuberechnung verwenden.
+
+**Erforderliche Regression:** Produktion ohne Verpackung buchen → Stückliste ergänzen → öffnen → Vorschau bleibt null → Notiz speichern → Verbrauch bleibt null. Anschließend tatsächliche Ergebnismenge ändern und prüfen, dass Vorschau und Speicherung gemeinsam zur aktuellen Stückliste wechseln.
+
+## 4. Prüfprotokoll
+
+| Prüfung | Ergebnis |
+|---|---|
+| `php artisan test` | **368 bestanden, 1.482 Assertions**, 5,76 s |
+| Zusätzliche PHPUnit-Diagnosen | **9 Tests, 56 Assertions: 8 bestanden, 1 fehlgeschlagen**; letzter Lauf 0,575 s. Der Fehlschlag belegt R-01. |
+| Zusätzliche DOM-Prüfungen | **16 Einzelprüfungen: 13 bestanden, 3 fehlgeschlagen**. Zwei Fehlschläge betreffen Verteilung und Summe bei R-01; einer betrifft R-02. Es handelt sich um zwei unterschiedliche Restfehler, nicht um drei. |
+
+Die zusätzlichen PHP-Tests wurden mit `vendor/bin/phpunit -c phpunit.xml --do-not-cache-result /tmp/WawiThirdProbeTest.php` ausgeführt. Die Testkonfiguration erzwingt SQLite `:memory:`; der Diagnoseaufbau prüft diese Konfiguration zusätzlich. Die JavaScript-Diagnose wurde mit `node /tmp/wawi-third-dom.cjs` ausgeführt, unter Verwendung des vorhandenen jsdom, jQuery und Select2. Sie verwendet über Laravel-Testrequests erzeugtes HTML und Rezeptur-JSON; externe Ressourcen werden nicht geladen.
+
+Die früheren Diagnosen wurden an zwei Stellen an die bewusst geänderten Regeln angepasst: Eine doppelte Rohstoffzeile in derselben Phase muss nun abgelehnt werden; beim ml-Update wird die jetzt im DOM nachweislich erhaltene Einheit `ml` übermittelt. Alte Fehlerannahmen wurden damit nicht als neue Fehlschläge gewertet.
+
+Die temporären Testprogramme und erzeugten Formularartefakte liegen ausschließlich unter `/tmp`, außerhalb des Repositories. Sie sind keine dauerhaft vorausgesetzten Projektdateien. Die relevanten Reproduktionsschritte und Soll-/Ist-Werte sind deshalb in diesem Dokument enthalten. Die bekannte PHPUnit-Deprecation zur XML-Konfiguration bleibt unabhängig von den fachlichen Ergebnissen bestehen.
+
+## 5. Abnahmeeinschätzung
+
+**N-01, N-03, N-05 und N-06 können im oben beschriebenen Umfang als behoben bestätigt werden. N-02 und N-04 sollten wegen R-01 und R-02 noch offen bleiben.** Vorrang hat die Phasenidentität, da dort Arbeitsdaten beim Wiederöffnen fehlen und bei weiterer Bearbeitung verloren gehen können.
+
+Die bereits bekannten offenen Betriebsnachweise bleiben unverändert: MySQL-Parallelität, reale iPad-Abnahme, Anwendung der drei Migrationen vom 08.09.2026 auf den vorgesehenen Entwicklungs-/Live-Datenbanken, Connector-Rollout 1.6.0 und nachgelagerte Pakete. Die lokale grüne Testsuite ersetzt diese Nachweise nicht. Die DOM-Prüfungen belegen Formularlogik, keine vollständige Browser-/Touch-Abnahme.
+
+## 6. Stand der Nacharbeit zu R-01/R-02 (09.09.2026)
+
+| Befund | Status | Umsetzung |
+|---|---|---|
+| R-01 / N-02 | ✅ `fda37d5` | Das Artikelformular führt je Phasenblock eine stabile ID (`mfg_phase_id[]`, leer für neue Blöcke). `persistRecipePhases()` ordnet bestehende Phasen 1. über die übermittelte ID (gegen Produkt/Typ geprüft), 2. über den Namen, 3. über gemeinsame Rohstoffe zu — **keine** Zuordnung mehr nach Reihenfolge. Nicht zugeordnete Phasen werden gelöscht (Verbrauchszeilen: nullOnDelete, wie bisher). Regression: Textphase voranstellen + Umbenennen mit IDs; Umordnen + Umbenennen ohne IDs; Wiederöffnen des Entwurfs zeigt 6 g und 4 g je Phase; Produktformular trägt die IDs. |
+| R-02 / N-04 | ✅ `bdaac3b` | Das Bearbeitungsformular übermittelt getrennt, ob ein historischer Snapshot gilt (`data-packaging-snapshot-applies`, = gebucht). Bei unveränderten Produktsummen zeigt die Vorschau auch einen leeren Snapshot („Kein Verpackungsverbrauch gebucht“); Entwürfe rechnen weiter mit der Stückliste. Regression: ohne Verpackung buchen → Stückliste ergänzen → öffnen (leer) → Notiz speichern (0) → Menge ändern (Neuberechnung). |
+
+Suite danach: **370 Tests grün, 1.506 Assertions**. Offen bleiben unverändert die Betriebsnachweise (MySQL-Parallelität, iPad, Migrationen auf Dev-/Live-DB, Connector 1.6.0) und die nachgelagerten Pakete.

dev/product management /02-audit/nachpruefung-befundbehebung-2026-09-08.md

@@ -179,7 +179,7 @@ Die im Erstbericht getrennt aufgeführten nachgelagerten Arbeitspakete, fehlende
 
 ## 6. Stand der Nacharbeit zu N-01…N-06 (08.09.2026)
 
-Alle sechs Restbefunde wurden am 08.09.2026 umgesetzt, jeweils mit Regressionstest entlang der oben genannten Abnahmekriterien. Suite danach: **368 Tests grün, 1.482 Assertions**.
+Alle sechs Restbefunde wurden am 08.09.2026 umgesetzt, jeweils mit Regressionstest entlang der oben genannten Abnahmekriterien. Suite danach: **368 Tests grün, 1.482 Assertions**. Die [Gegenprüfung vom 09.09.2026](gegenpruefung-restbefunde-2026-09-09.md) bestätigte N-01/N-03/N-05/N-06 und fand zu N-02 und N-04 je einen Randfall (R-01: Einfügen + Umbenennen ohne stabile Phasen-ID; R-02: leerer Snapshot nicht erkannt). Beide sind umgesetzt (Abschnitt 6 dort; Suite 370 grün).
 
 | Befund | Status | Umsetzung |
 |---|---|---|

dev/product management /README.md

@@ -1,8 +1,8 @@
 # Warenwirtschaft — Projektübersicht & Entwicklungsplan
 
-> **Stand:** 08.09.2026
+> **Stand:** 09.09.2026
 > **Status:** Modul ist **live** und in der **Kundentestphase** (Dev-Container mit eingespielter Live-Datenbank inkl. Testdaten).
-> **Testsuite:** 368 Tests grün (1.482 Assertions, 0 Failures).
+> **Testsuite:** 370 Tests grün (1.506 Assertions, 0 Failures).
 
 Dieses Dokument ist der Einstieg in den Ordner. Es skizziert den Gesamtstand,
 listet die erledigten und die noch offenen Arbeitspakete und verweist auf die
@@ -17,7 +17,7 @@ Detaildokumente. Die maßgebliche, aktuellste Aufwands-/Leistungssicht ist die
 |---|---|
 | [`00-konzept/`](00-konzept/) | Ausgangs-Briefings, Fachkonzept, frühes Feedback (März–April 2026) |
 | [`01-entwicklungsplaene/`](01-entwicklungsplaene/) | Versionierte Entwicklungspläne — maßgeblich ist die neueste Fassung [`entwicklungsplan-V7-2026-08-26.md`](01-entwicklungsplaene/entwicklungsplan-V7-2026-08-26.md) (V7.0); V6.0 = `entwicklungsplan-aktualisiert-2026-07-06.md` |
-| [`02-audit/`](02-audit/) | Qualitäts- & Sicherheits-Audit vom 15.07.2026; [Umsetzungsprüfung 08.09.2026](02-audit/umsetzungspruefung-2026-09-08.md) (18 Befunde) und [Nachprüfung der Behebung](02-audit/nachpruefung-befundbehebung-2026-09-08.md) (6 Restbefunde) — alle umgesetzt |
+| [`02-audit/`](02-audit/) | Qualitäts- & Sicherheits-Audit vom 15.07.2026; [Umsetzungsprüfung 08.09.2026](02-audit/umsetzungspruefung-2026-09-08.md) (18 Befunde) [Nachprüfung der Behebung](02-audit/nachpruefung-befundbehebung-2026-09-08.md) (6 Restbefunde) und [Gegenprüfung 09.09.2026](02-audit/gegenpruefung-restbefunde-2026-09-09.md) (2 Randfälle) — alle umgesetzt |
 | [`03-status-und-vorschlaege/`](03-status-und-vorschlaege/) | Aktuelle Leistungsübersicht, AP-32-Brückenlösung, Vorschlag Deckel-Varianten |
 | [`screens/`](screens/) | Screenshots / Mockups zu Beständen, Rezeptur-Phasen, Produktion |
 
@@ -115,7 +115,7 @@ Regressionstest, Abschnitt 9 des Berichts). Eine anschließende
 [Nachprüfung](02-audit/nachpruefung-befundbehebung-2026-09-08.md) fand sechs Restfehler
 (N-01…N-06: Entwurfsmenge ohne Charge, Phasenverlust beim Artikelspeichern, Chargensplit vs.
 Snapshot, Vorschau vs. Snapshot, Alt-Ausschuss ohne Charge, ml-Kopie im Bearbeiten), die
-ebenfalls behoben sind (Abschnitt 6 dort). Drei neue Migrationen (`2026_09_08_*`) müssen
+ebenfalls behoben sind (Abschnitt 6 dort); die Gegenprüfung vom 09.09.2026 fand zu N-02/N-04 zwei Randfälle (R-01 stabile Phasen-IDs, R-02 leerer Snapshot), ebenfalls behoben. Drei neue Migrationen (`2026_09_08_*`) müssen
 auf Dev-/Live-DB laufen. Weiterhin offen: die im Bericht (Abschnitte 4.3/4.4/5) genannten
 nachgelagerten Pakete, Optimierungen, Connector-Rollout v1.6.0 und die Browser-/iPad-Abnahme.