Dokumente hinzugefügt

docs/specs/meilensteine.md

@@ -0,0 +1,507 @@
+# Meilensteine
+
+> **Dokumentversion:** v3
+> **Stand:** 08.04.2026
+> **Status:** verbindliche Meilensteinstruktur für die Implementierung von Version 1
+> **Projekt:** ASV-Format-Validator
+> **Primärquelle:** `Spec.docx` – Technische Anlage ASV 1.09, Stand 09.10.2025, anzuwenden ab Leistungserbringungsquartal 2/2026
+> **Begleitdokumente:** `fachliche-anforderungen.md` v4, `technik-und-architektur.md` v5
+
+## 1. Zweck dieses Dokuments
+
+Dieses Dokument untergliedert die Implementierung des Projekts **ASV-Format-Validator** in fachlich und technisch sinnvolle **Meilensteine** für Version 1.
+
+**Rangfolge der Dokumente:**
+
+1. `Spec.docx` ist die normative fachlich-technische Wahrheit. Bei jeder Kollision gilt die Spezifikation.
+2. `fachliche-anforderungen.md` v4 ist der verbindliche fachliche Soll-Rahmen.
+3. `technik-und-architektur.md` v5 ist der verbindliche technische Soll-Rahmen.
+4. Dieses Dokument **strukturiert lediglich die Umsetzung** der oben genannten Grunddokumente in eine sinnvolle Reihenfolge. Es ersetzt sie nicht, reduziert sie nicht und darf ihnen nicht widersprechen.
+
+Dieses Dokument beschreibt **keine Arbeitspakete**, **keine KI-Prompts** und **keine konkreten Implementierungsschritte**, sondern nur die empfohlene Reihenfolge und Abgrenzung der größeren Umsetzungsschritte für Version 1.
+
+## 2. Leitplanken für die Meilensteinbildung
+
+Für alle Meilensteine gelten verbindlich folgende Grundsätze:
+
+1. Es geht **ausschließlich um Version 1**.
+2. Die Zielbasis ist **genau eine Spezifikationsversion**: Technische Anlage ASV 1.09.
+3. Themen aus `Ausblick.md` sind **nicht Bestandteil** dieser Meilensteinplanung.
+4. Jeder Meilenstein muss in einem **grünen, stabilen Zwischenstand** enden.
+5. Die Architektur wird **evolutionär** weiterentwickelt, nicht in einem riskanten Komplettumbau.
+6. Fachliche Regeln, technische Parserlogik, Berichtserzeugung und Infrastruktur bleiben **klar getrennt**.
+7. Bereiche, die laut Anforderungen in V1 **nicht belastbar prüfbar** sind (`V1-N`), werden nicht versehentlich als harte Pflichtvalidierung umgesetzt. Bereiche mit Kategorie `V1-T` werden nur so weit aktiv geprüft, wie es lokal belastbar möglich ist.
+8. Die Trennung zwischen **Spec-Urteil** und **diagnostischer Weiteranalyse** ist von Anfang an architektonisch verankert, nicht erst am Ende eingeführt.
+
+## 3. Überblick über die Meilensteinfolge
+
+| Meilenstein | Titel | Hauptnutzen |
+|---|---|---|
+| **M1** | Projektfundament, Logging und Ergebnismodell | startbare CLI, stabile Grundarchitektur, Logging-Adapter, Befundmodell mit Spec-/Diagnose-Trennung |
+| **M2** | Artefaktschicht, Dateizugriff, Dateinamen und globale Rahmenregeln | sauberes Einlesen, ISO-8859-15-Basis, Dateinamensschemata, Partnersicht |
+| **M3** | EDIFACT-Serviceebene und Transportstruktur | belastbare Strukturprüfung für `UNA`, `UNB`, `UNH`, `UNT`, `UNZ` inkl. Service-Crosschecks |
+| **M4** | KKS-Auftragssatz / AUF | vollständiger eigener Prüfpfad für Auftragsdateien und KKS-Crosschecks |
+| **M5** | ASVREC-Kernmodell und feldgenaue Einzelregeln | fachlich belastbare Validierung regulärer ASV-Abrechnungen |
+| **M6** | Beziehungsregeln, Summenlogik und Storno | Falllogik, Crosschecks und strukturierte Storno-Behandlung |
+| **M7** | ASVFEH und Fehlernachrichtenlogik | sauber getrennte Validierung von Fehlerdateien und `FHL`-Segmenten |
+| **M8** | PKCS#7, Krypto und Tiefenprüfung verschlüsselter Artefakte | Prüfung transportnaher bzw. verschlüsselter Eingaben bis zur inneren Nutzlast |
+| **M9** | Bericht, Diagnose, Produktreife und Release-Härtung | final nutzbare V1 mit stabiler Ausgabe, Qualitätssicherung und Dokumentation |
+
+## 4. Detaillierte Meilensteine
+
+---
+
+## M1 – Projektfundament, Logging und Ergebnismodell
+
+### Ziel
+
+Es entsteht der tragfähige technische Sockel für die weitere Implementierung, inklusive **Logging-Adapter** und **Befundmodell mit eingebauter Spec-/Diagnose-Trennung**. Die eigentliche ASV-Fachvalidierung ist hier noch nicht enthalten. Das Grundgerüst ist so geschnitten, dass alle späteren Meilensteine ohne architektonischen Umbau darauf aufbauen können.
+
+### Inhalt
+
+- Zielstruktur gemäß hexagonaler Architektur innerhalb des bestehenden Maven-Projekts anlegen bzw. schärfen (Paketzuschnitt gemäß `technik-und-architektur.md`)
+- manuellen Bootstrap mit Constructor Injection herstellen; kein DI-Framework
+- CLI-Grundaufruf mit **genau einer Eingabedatei als Positionsargument** herstellen
+- internes Ergebnis- und Befundmodell als stabiles Grundgerüst einführen; das Befundmodell unterscheidet **von Anfang an**:
+  - **Spec-Urteil** (verbindliches Prüfurteil gemäß Spezifikation)
+  - **diagnostische Weiteranalyse** (zusätzliche Befunde, die das Spec-Urteil niemals verändern)
+- Befundarten Fehler / Warnung / Hinweis strukturell im Modell verankern
+- Befund-Metadaten als Felder vorsehen: Artefaktschicht, Prüfstufe, Prüfbereich, Segmenttyp, Segmentindex, Feld-ID, Rohwert, Position, Nachrichtenbezug, optionaler offizieller Fehlercode
+- **Logging-Adapter** einführen:
+  - SLF4J als Fassade
+  - Log4j2 als Implementierungs-Bindung
+  - konkrete Log4j2-Bindung **ausschließlich** im Bootstrap und im Logging-Adapter sichtbar
+- Trennung zwischen fachlichem Kern, Infrastruktur, Bericht und Logging von Anfang an sauber festziehen
+- Grundverhalten für Bericht- und Log-Datei im Eingabeverzeichnis etablieren (Berichtdatei `.txt`, Log-Datei `.log`, beide UTF-8)
+- Suffix-Logik `_v1`, `_v2`, … für Mehrfachläufe auf denselben Dateibasisnamen etablieren
+- Exit-Code-Grundgerüst (`0`, `1`, `2`) implementieren
+- Minimalbericht auch für Bedien- oder Zugriffsfehler vorsehen (Exit-Code `2`)
+
+### Noch nicht Ziel von M1
+
+- echte EDIFACT-Nachrichtenvalidierung
+- KKS-Feldlogik
+- ASVREC-/ASVFEH-Fachmodell
+- PKCS#7-Verarbeitung
+- inhaltliche Bericht-Gestaltung
+
+### Abnahme von M1
+
+- Anwendung ist als JAR unter Windows mit Java 21 startbar
+- Eingabedatei wird technisch entgegengenommen; falsches oder fehlendes Argument führt zu Exit-Code `2` mit Minimalbericht
+- Bericht- und Log-Datei werden im Eingabeverzeichnis mit korrekter Suffix-Logik erzeugt
+- Log4j2-Bindung ist außerhalb von Bootstrap und Logging-Adapter nicht sichtbar
+- Befundmodell trennt Spec-Urteil und Diagnose strukturell
+- Build und Tests sind grün
+
+---
+
+## M2 – Artefaktschicht, Dateizugriff, Dateinamen und globale Rahmenregeln
+
+### Ziel
+
+Die Anwendung kann lokale Eingabedateien robust lesen, technisch einordnen und als äußeres Artefakt sauber modellieren. Die globalen fachlichen Rahmenregeln und die Dateinamenskonventionen der Spezifikation sind als harte Prüfregeln umgesetzt.
+
+### Inhalt
+
+- read-only Dateisystemzugriff in einem Infrastruktur-Adapter kapseln
+- Eingaben konsequent mit **ISO 8859-15** behandeln; keine Plattform-Default- oder stillschweigende UTF-8-Dekodierung
+- äußeres Artefaktmodell aufbauen:
+  - physische Datei
+  - Dateiname
+  - Extension
+  - mutmaßliche Artefaktart
+  - erkannte Schichten
+- **automatische Dateityperkennung** und **explizite Benutzervorgabe** als gleichrangige Eingänge umsetzen; bei Widerspruch wird die Benutzervorgabe verarbeitet und zusätzlich eine Warnung erzeugt (kein Abbruch allein wegen Widerspruch)
+- **Dateinamensschemata gemäß Spezifikation als harte Prüfregeln** umsetzen:
+  - unverschlüsselt: `B<VKNR><Jahr><Quartal><Zähler>` (11 Stellen)
+  - verschlüsselt: `<IK-Sender>_<IK-Kasse>_<E|T>ASV0<Zähler>`
+  - Auftragsdatei: identischer Basisname wie die zugehörige verschlüsselte Datei, Endung `.AUF`
+- **Übermittlungszähler** prüfen: Wertebereich `001`–`999`, 3-stellig numerisch; V1 prüft **keine** quartalsübergreifende Folgesequenz, markiert diese Grenze aber als bewusste V1-Einschränkung im Bericht
+- **globale fachliche Rahmenregeln** umsetzen (aus `fachliche-anforderungen.md` §5.1):
+  - ISO 8859-15 als Verfahrens-Zeichensatz, nur darstellbare Zeichen
+  - ASV-Dateien werden unkomprimiert übertragen
+  - eine Datei pro Kasse, keine kassenübergreifende Bündelung
+  - keine erzwungene Sortierreihenfolge der Nachrichten innerhalb einer Datei
+- exakte Partnerdatei-Ableitung für die zugehörige `.AUF` bzw. die zugehörige Transportdatei herstellen (deterministisch, nicht heuristisch)
+- fehlende oder nicht passende Partnerdatei als Warnung modellieren, nicht als Abbruch
+
+### Noch nicht Ziel von M2
+
+- tiefe Service-Segment-Validierung
+- KKS-Feldprüfung
+- fachliche Segmentbeziehungen in ASVREC
+
+### Abnahme von M2
+
+- äußere Datei wird robust gelesen, mit ISO 8859-15 dekodiert und klassifiziert
+- Dateinamensschemata werden feldgenau geprüft
+- Übermittlungszähler-Wertebereich wird geprüft und die V1-Einschränkung ist im Bericht kenntlich
+- die vier globalen Rahmenregeln aus §5.1 sind als eigene Regelbausteine umgesetzt
+- Partnerdateien werden deterministisch gesucht, nicht heuristisch geraten
+- Widerspruch zwischen Auto-Erkennung und Benutzervorgabe wird als Warnung erzeugt, ohne Abbruch
+- Build und Tests sind grün
+
+---
+
+## M3 – EDIFACT-Serviceebene und Transportstruktur
+
+### Ziel
+
+Die Anwendung kann die EDIFACT-Hüllstruktur zuverlässig parsen und die lokalen Prüfregeln der Stufen 1 und 2 auf Service-Ebene belastbar anwenden.
+
+### Inhalt
+
+- Parsing für `UNA`, `UNB`, `UNH`, `UNT`, `UNZ`
+- `UNA` als optionales Segment behandeln; Fallback auf die ASV-konformen Standardtrennzeichen, wenn `UNA` fehlt
+- Prüfung der Trennzeichen und ihrer Gültigkeit
+- technische Segmentgrenzen, Nachrichtenhüllen und Nachrichtenanzahl bestimmen
+- **Service-Crosschecks** umsetzen:
+  - **physischer Dateiname ↔ `UNB_0020`** (`UNB_0020` ist die Übertragungsreferenz bzw. der Dateiname der Übertragung, nicht die Senderkennung)
+  - `UNB_0020` ↔ `UNZ_0020` (Referenzgleichheit von Übertragungskopf und -ende)
+  - `UNH_0062` ↔ `UNT_0062` je Nachricht (Referenzgleichheit von Nachrichtenkopf und -ende)
+  - `UNZ_0010` (Nachrichtenzähler) ↔ tatsächliche Anzahl der `UNH`/`UNT`-Paare
+  - Testindikator `UNB 0035`: Echtdaten-/Testdaten-Konsistenz mit der `E`/`T`-Kennung im physischen Dateinamen; Wert `1` nur für Testübertragungen
+- Konsistenzprüfungen, die den KKS-Auftragssatz voraussetzen (insbesondere die Abstimmung zwischen `UNB 0035`/Dateiname und KKS-`VERFAHREN_KENNUNG`), sind **nicht** Bestandteil von M3 und werden in M4 zusammen mit den KKS-Crosschecks umgesetzt
+- unbekannte oder fremde Segmente nicht vorschnell verwerfen, sondern diagnostisch sichtbar halten
+- **Spec-Urteil und diagnostische Weiteranalyse strikt trennen** (Befundklassifizierung bereits beim Erzeugen)
+- parse-nahe Sofortprüfungen bleiben auf **strukturelle und technische** Befunde beschränkt (Lesbarkeit, Zeichensatz, Trennzeichen, grobe Segment- und Feldfehler); fachliche Regeln, feldwertbezogene Plausibilitäten und Bezugskontrollen gehören **nicht** in den Parser
+
+### Noch nicht Ziel von M3
+
+- KKS-Auftragssatz im Detail
+- fachliche Feldregeln der Nutzdaten
+- Katalog- oder Bestandsprüfungen
+
+### Abnahme von M3
+
+- Service-Segmente werden robust erkannt und geparst (mit und ohne `UNA`)
+- die in M3 genannten Crosschecks sind umgesetzt und als eigene Regeln nachweisbar
+- typische Stufe-1- und Stufe-2-Strukturfehler können belastbar gemeldet werden
+- Build und Tests sind grün
+
+---
+
+## M4 – KKS-Auftragssatz / AUF
+
+### Ziel
+
+Der KKS-Auftragssatz wird als eigenständiger, vollwertiger Prüfgegenstand umgesetzt und nicht als Anhängsel der Nutzdatendatei behandelt. Eine `.AUF`-Datei kann auch **eigenständig** (als einzige Eingabedatei pro Lauf) validiert werden.
+
+### Inhalt
+
+- Parser für den festen KKS-Auftragssatz aufbauen
+- **vollständige Umsetzung der KKS-Feldregeln** gemäß `fachliche-anforderungen.md` §9. Die nachfolgende Liste ist nicht abschließend, sondern nennt zentrale Anker; maßgeblich ist §9.
+- zentrale Festwerte und Strukturprüfungen:
+  - `IDENTIFIKATOR = 500000`
+  - `VERSION = 01`
+  - `LÄNGE_AUFTRAG = 00000348`
+  - `SEQUENZ_NR = 000` (keine Teillieferungen)
+  - `VERFAHREN_KENNUNG`: Stelle 20 `E`/`T`, Stellen 21–23 `ASV`, Stelle 24 `0`
+  - `VERFAHREN_KENNUNG_SPEZIFIKATION` als **Kann-Feld**: Blank zulässig; wenn belegt, nur aus der definierten Wertemenge (`ASVA0` für Abrechnung, `ASVF0` für Fehlermeldung)
+  - `TRANSFER_NUMMER`: Wertebereich `001`–`999`
+  - `DATUM_ERSTELLUNG`: 14-stellig `JJJJMMTThhmmss`, formal prüfen
+  - `DATEIVERSION = 000000`
+  - `KORREKTUR = 0`
+  - `FEHLER_NUMMER = 000000`, `FEHLER_MASSNAHME = 000000`
+  - `ZEICHENSATZ = I5` (formaler Anker für die ISO-8859-15-Annahme der gesamten Anwendung)
+  - `KOMPRIMIERUNG = 00`
+  - `VERSCHLÜSSELUNGSART = 03`
+  - `ELEKTRONISCHE_UNTERSCHRIFT = 03`
+- **Kommunikationspartner-Felder** (`ABSENDER_EIGNER`, `ABSENDER_PHYSIKALISCH`, `EMPFÄNGER_NUTZER`, `EMPFÄNGER_PHYSIKALISCH`): strukturell und formal auf IK-Format prüfen. Eine inhaltliche Kommunikationspartnerprüfung ist ohne Referenzbestände in V1 nicht belastbar möglich und daher nicht Gegenstand von M4 (`V1-T`)
+- Kann-Felder des KKS nach Nichtbelegungsregeln prüfen:
+  - numerisch → Nullfüllung (`HEX 30`)
+  - alphanumerisch → Blankfüllung (`HEX 20`)
+- **KKS-Crosschecks**:
+  - `TRANSFER_NUMMER` ↔ Zähler im physischen Dateinamen
+  - **Dateinamensbezug** (Begriffsklärung):
+    - der **physische Dateiname** der verschlüsselten Übertragungsdatei folgt dem Schema `<IK-Sender>_<IK-Kasse>_<E|T>ASV0<Zähler>`
+    - die zugehörige **Auftragsdatei** trägt denselben physischen Basisnamen und endet auf `.AUF`
+    - `UNB_0020` trägt, sobald die EDIFACT-Schicht vorliegt, die Übertragungsreferenz und entspricht dem Dateinamen der Übertragung
+    - die **KKS-`DATEINAME`**-Angabe im Auftragssatz entspricht dem **unverschlüsselten** Dateinamen nach dem Schema `B<VKNR><Jahr><Quartal><Zähler>`
+    - zu prüfen sind: KKS-`DATEINAME` gegen den aus Schema und Kontext abgeleiteten unverschlüsselten Dateinamen sowie – soweit beide Schichten vorliegen – die Konsistenz zwischen physischem Dateinamen der Übertragung, `UNB_0020` und KKS-`DATEINAME`
+  - `DATEIGRÖSSE_NUTZDATEN` gegen die tatsächliche Bytegröße der unverschlüsselten Nutzdatendatei, soweit die unverschlüsselte Schicht lokal vorliegt
+  - `DATEIGRÖSSE_ÜBERTRAGUNG` gegen die tatsächliche Bytegröße der verschlüsselten Übertragungsdatei
+  - Echtdaten-/Testdaten-Konsistenz zwischen Dateiname, KKS-`VERFAHREN_KENNUNG` und – soweit vorhanden – `UNB 0035`
+
+### Noch nicht Ziel von M4
+
+- vollständige fachliche ASVREC-Regelvalidierung
+- ASVFEH-Fachlogik
+- PKCS#7-Tiefenprüfung
+
+### Abnahme von M4
+
+- `.AUF`-Dateien sind eigenständig validierbar
+- die Regeln aus `fachliche-anforderungen.md` §9 sind umgesetzt
+- KKS-Festwerte und Feldlogik sind belastbar geprüft
+- KKS-Crosschecks funktionieren technisch sauber
+- AUF-bezogene Befunde sind im Ergebnis klar von EDIFACT-Nutzdaten-Befunden getrennt
+- Build und Tests sind grün
+
+---
+
+## M5 – ASVREC-Kernmodell und feldgenaue Einzelregeln
+
+### Ziel
+
+Reguläre ASV-Abrechnungsnachrichten (`ASVREC`) werden fachlich auf Segment- und Feldebene belastbar validierbar, soweit dies lokal ohne Referenzbestände möglich ist.
+
+### Inhalt
+
+- kanonisches internes Modell für `ASVREC` aufbauen
+- Segmentabbildung für die ASVREC-Nutzsegmente gemäß Spezifikation: `IFA`, `DGN`, `LEA`, `SAC`, `GEN`, `OPA`, `REA`, `IVA`
+- feldgenaue Regeln gemäß Fachlichen Anforderungen umsetzen, soweit in V1 lokal belastbar
+- Muss-/Kann-Logik und Vorkommensregeln pro Segment und Feld umsetzen
+- formale Prüfungen für Typ, Länge, Format, Schlüsselwerte und Sonderformate umsetzen
+- **Versichertennummer-Strukturprüfung** (`IVA 8.3.1`) umsetzen:
+  - Stelle 1: Alpha `A`–`Z` ohne Umlaute
+  - Stellen 2–9: numerisch
+  - Stelle 10: Prüfzifferstelle vorhanden (keine algorithmische Prüfziffernvalidierung in V1)
+- zentrale Sonderregeln und Ausnahmen korrekt berücksichtigen – diese **dürfen nicht fälschlich als Fehler gemeldet werden**:
+  - **Geburtsdatum im Ersatzverfahren** (`IVA 8.4.3`): im Format `JJJJMMTT` sind beliebige numerische Werte zulässig, zusätzlich die Platzhalter `00` (unbekannter Tag), `0000` (unbekannter Tag und Monat) und `00000000` (vollständig unbekannt); eine Datumsplausibilisierung in diesem Feld ist unzulässig
+  - **negative numerische Werte**: das führende Minuszeichen zählt nicht zur maximalen Feldlänge
+  - **Dezimalzeichen `,`** zählt nicht zur maximalen Feldlänge
+  - **Pseudo-GOP `88999` sowie regionale Pseudo-GOP** sind für Sachkosten ohne Sachzusammenhang zulässig
+  - **GOÄ-Sonderfall**: in `3/3.2.1` wird die Pseudo-GOP übertragen, in `3/3.2.5` die zugehörige GOÄ-Ziffer
+  - **obsolete Muss-Felder `4/4.2.4` und `4/4.2.5`**: füllpflichtig mit beliebigem Inhalt, aber **nicht ausschließlich Leerzeichen**; inhaltlich werden diese Felder nicht geprüft
+- **Vertretungs-Teamebene `4`**: Die Spezifikation legt fest, dass bei Teamebene `4` die Teamebene des Vertretenen maßgeblich ist. Eine belastbare Prüfung dieser Regel setzt einen Abgleich mit dem ASV-Verzeichnis voraus und ist in V1 ohne Referenzbestände nicht möglich (`V1-N`). V1 erzwingt deshalb insbesondere keine Plausibilitäten auf Teamebene `4` und markiert diesen Bereich als bewusst nicht geprüft.
+- ausdrücklich **keine** referenzbestandsabhängigen Prüfungen erzwingen (`V1-N`-Bereich: ICD, OPS, IK, BSNR, LANR, Teamnummer inhaltlich)
+- Bereiche mit `V1-N` im Bericht als „bewusst nicht geprüft" kenntlich machen
+
+### Noch nicht Ziel von M5
+
+- fallübergreifende bzw. komplexe Crosschecks
+- Storno-Sonderstruktur
+- ASVFEH
+- PKCS#7
+
+### Abnahme von M5
+
+- reguläre `ASVREC`-Nachrichten können segment- und feldgenau validiert werden
+- die genannten Sonderwerte und Ausnahmen werden nicht fälschlich als Fehler behandelt
+- die Versichertennummer-Strukturprüfung ist umgesetzt
+- lokal nicht belastbar prüfbare Bereiche bleiben sauber abgegrenzt und als `V1-N` markiert
+- das kanonische Modell ist stabil genug für Beziehungsregeln im nächsten Meilenstein
+- Build und Tests sind grün
+
+---
+
+## M6 – Beziehungsregeln, Summenlogik und Storno
+
+### Ziel
+
+Die fallinterne Logik von ASV-Abrechnungen wird vollständig genug, um reguläre Rechnungen und Storno-Fälle fachlich konsistent zu beurteilen.
+
+### Inhalt
+
+- segmentübergreifende Crosschecks umsetzen, insbesondere:
+  - `DGN` erforderlich bei regulärer Rechnung (`REA 7.2.4 = 0`)
+  - `LEA` erforderlich bei regulärer Rechnung
+  - Summenprüfung Rechnungsbetrag (`REA`) gegen `LEA` und `SAC`, soweit ohne externe Bestände lokal möglich
+  - Überweiserkontext ↔ Diagnoseart (`IFA 1.3.1` / `DGN 2.2.5`)
+  - externer und interner Überweiser nicht gleichzeitig (`IFA 1.3.1` / `1.3.2`)
+  - Pflicht-`GEN` bei bestimmten GOPs
+- Regeln für Pseudo-GOP, GOÄ-Sonderfall und Sachkosten-Sonderkonstellationen umsetzen, soweit lokal belastbar
+- Konsistenzprüfung zur globalen Regel „eine Datei pro Kasse" auf Basis der lokal verfügbaren Kassenbezüge (Andockstelle an die globale Rahmenregel aus M2)
+- **Storno als eigene Strukturvariante von `ASVREC`** sauber modellieren:
+  - reduzierte Segmentstruktur: nur die in der Spezifikation für Storno vorgesehenen Muss-Segmente und Muss-Felder
+  - bei Storno **unzulässige** Segmente gemäß Spezifikation: `DGN`, `LEA`, `SAC`, `GEN`, `OPA` – ihr Vorhandensein ist ein Fehler
+  - Rechnungskennzeichen Storno (`REA 7.2.4 = 1`)
+  - Rechnungsbetrag bei Storno `REA 7.2.1 = 0,00`
+  - Bezug auf die ursprüngliche Rechnungsnummer, soweit lokal prüfbar
+- saubere Vermeidung, dass Storno-Pflichten als „normale Rechnungspflichten" missbraucht werden und umgekehrt
+
+### Noch nicht Ziel von M6
+
+- Validierung von `ASVFEH`
+- PKCS#7-Tiefenprüfung
+
+### Abnahme von M6
+
+- reguläre Rechnungen und Storno-Nachrichten werden sauber unterschieden
+- die in M6 genannten segmentübergreifenden ASVREC-Regeln greifen
+- Summen- und Strukturfehler werden fachlich nachvollziehbar ausgewiesen
+- Storno wird als eigene Variante behandelt; bei Storno unzulässige Segmente werden erkannt
+- Build und Tests sind grün
+
+---
+
+## M7 – ASVFEH und Fehlernachrichtenlogik
+
+### Ziel
+
+Fehlernachrichten (`ASVFEH`) werden als eigener Nachrichtentyp mit eigener Struktur und eigenen Regeln vollständig separat validiert.
+
+### Inhalt
+
+- eigenes kanonisches Modell für `ASVFEH` einführen
+- beide Strukturvarianten unterstützen:
+  - **eigenständige Fehlerdatei** (typisch Stufe 1): `UNB`, `UNH` mit Nachrichtentyp `ASVFEH`, `FHL`, `UNT`, `UNZ`
+  - **eingebettete Fehlernachricht mit Originalnutzdaten** (typisch Stufen 2–4): `UNH`, Originalnutzdatensegmente, `FHL`, `UNT`
+- `FHL`-Segmentlogik umsetzen (Spezifikation sieht bis zu 99 Vorkommen vor)
+- Prüfung von Fehlercode, Fehlertext, Referenzen, Storno-/Korrekturkennzeichen und weiteren `FHL`-Feldern, soweit lokal belastbar
+- Regel abbilden: Kann-Datenelemente im `FHL` werden zu Muss-Datenelementen, **wenn** ihre Ermittelbarkeit aus der Fehlersituation belastbar ableitbar ist. V1 setzt dies nur dort als Fehler um, wo diese Ableitbarkeit aus der vorliegenden Datei wirklich gegeben ist.
+- **Umgang mit Originalnachricht** explizit umsetzen:
+  - die mitgelieferte Originalnachricht wird **nicht** als eigenständiger ASVREC-Validierungsgegenstand behandelt
+  - die Abwesenheit der Originalnachricht bei Prüfstufen 2–4 ist **kein Fehler**, sondern höchstens ein Hinweis, da die Originalnutzdaten laut Spezifikation nicht lesbar oder nicht syntaxkonform übertragbar gewesen sein dürfen
+  - die Verfahrensregel „eine Fehlernachricht darf nicht mit einer Fehlernachricht beantwortet werden" wird **nicht** als Validierungsregel umgesetzt, da sie an einer einzelnen isoliert übergebenen Datei nicht prüfbar ist (`V1-N`)
+- Vorrang spezifischer offizieller Fehlercodes vor Sammelcodes (`xx999`, `3A998`, `4A998`) berücksichtigen
+
+### Noch nicht Ziel von M7
+
+- PKCS#7-Tiefenprüfung
+- finale Berichtsveredelung
+
+### Abnahme von M7
+
+- `ASVFEH` ist sauber von `ASVREC` getrennt
+- beide `ASVFEH`-Strukturvarianten werden korrekt erkannt
+- `FHL`-Segmente sind feldgenau modelliert und strukturell für bis zu 99 Vorkommen unterstützt
+- das Fehlen der Originalnachricht bei Stufen 2–4 erzeugt keinen harten Fehler
+- offizielle Fehlercodebezüge können belastbar an Befunde angehängt werden; Sammelcodes werden nur genutzt, wenn kein spezifischerer offizieller Code einschlägig ist
+- Build und Tests sind grün
+
+---
+
+## M8 – PKCS#7, Krypto und Tiefenprüfung verschlüsselter Artefakte
+
+### Ziel
+
+Die Anwendung kann verschlüsselte bzw. transportnahe Artefakte technisch verarbeiten und – soweit Material nutzbar bereitgestellt wurde – bis zur inneren Nutzlast durchsteigen. **Die Tiefenprüfung nutzt die bereits in M3–M7 gebaute Validierungskette erneut**; es entsteht keine zweite, parallele Validierungslogik.
+
+### Inhalt
+
+- Krypto-Adapter hinter stabilen Ports einführen; Krypto-Verarbeitung erfolgt **innerhalb der Java-Anwendung**, keine externen Tools oder Binaries
+- explizite CLI-Übergabe von Schlüssel- und Passwortmaterial anbinden (konkrete Optionsnamen in der README dokumentiert)
+- Basisprüfung verschlüsselter Artefakte auch **ohne** nutzbares Material ermöglichen
+- Fallback-Verhalten sauber umsetzen: **Warnung statt Totalabbruch**, wenn Material technisch nicht nutzbar ist
+- nach erfolgreicher Entschlüsselung automatisch bis zur inneren fachlichen Schicht weiterarbeiten, indem die bereits bestehende Validierungskette aus M3–M7 auf die entschlüsselte Nutzlast angewendet wird
+- Mindestalgorithmusprüfungen gemäß technischem Soll-Rahmen modellieren, insbesondere:
+  - PKCS#7 als Containerformat
+  - AES-256-CBC als Session Key
+  - RSA 4096 Bit als Interchange Key
+  - SHA256withRSAandMGF1 / PSS
+  - RSA-Exponent Fermat-4 (`2^16 + 1`)
+- Nicht-PSS-Altverfahren müssen in V1 nicht aktiv unterstützt werden, dürfen aber als erkannte Abweichung gemeldet werden
+- Abweichungen sauber als technische Befunde modellieren
+- Krypto-Integration bleibt sauber von Domain und Application entkoppelt; Krypto-Typen sind außerhalb des Krypto-Adapters und des Bootstrap nicht sichtbar
+
+### Noch nicht Ziel von M8
+
+- zusätzliche Transportkanäle
+- E-Mail- oder Serverintegration
+- Mehrdateimodus
+
+### Abnahme von M8
+
+- verschlüsselte Artefakte sind technisch analysierbar
+- mit gültigem Material ist Tiefenprüfung bis zur Nutzlast möglich; das Ergebnis ist konsistent zu dem, was eine Direktvalidierung der unverschlüsselten Datei liefern würde
+- ohne nutzbares Material erfolgt nachvollziehbare Basisprüfung mit Warnung, kein Totalabbruch
+- Krypto-Integration ist entkoppelt
+- Build und Tests sind grün
+
+---
+
+## M9 – Bericht, Diagnose, Produktreife und Release-Härtung
+
+### Ziel
+
+Die bis dahin umgesetzte Funktionalität wird zu einer sauberen, benutzbaren und abnahmereifen Version 1 zusammengeführt.
+
+### Inhalt
+
+- finalen hierarchischen Bericht stabilisieren:
+  - Datei
+  - Schichten
+  - Nachrichten/Fälle
+  - Befunde
+- strukturierte Bestandsinformationen in den Bericht aufnehmen: erkannter Dateityp, erkannte Schichten, Anzahl Nachrichten/Fälle, relevante Kopfdaten, Übermittlungszähler, spec-konformes Prüfurteil, zusätzliche diagnostische Auffälligkeiten
+- klare Trennung zwischen **Spec-Urteil** und **diagnostischer Weiteranalyse** final durchziehen (architektonisch seit M1 vorhanden, hier nur in der Darstellung konsolidiert)
+- Befunde mit Metadaten und – soweit eindeutig – offiziellen Fehlercodes anreichern; Vorrangregel für Sammelcodes einhalten
+- Konsolenausgabe und Berichtdatei fachlich gleichziehen
+- technisches Logging sauber vom Bericht trennen
+- README und Nutzungsdokumentation vervollständigen, inklusive CLI-Optionsnamen und der PKCS#7-Materialübergabe
+- umfangreiche End-to-End-Testartefakte ergänzen: Parser-, KKS-, ASVFEH- und Storno-Fälle mit synthetischen, anonymisierten Testdaten
+- letzte Robustheits- und Randfalllücken schließen
+
+### Quality-Gates für Version 1 (verbindlich)
+
+- Build grün
+- alle Tests grün
+- **Coverage gesamtprojektweit ≥ 85 %**
+- **PIT-Mutation-Score gesamtprojektweit ≥ 70 %**
+- differenzierte Zielschwellen gemäß `technik-und-architektur.md`:
+
+| Bereich | Coverage | Mutation |
+|---|---|---|
+| `domain` | ≥ 95 % | ≥ 85 % |
+| `application` | ≥ 90 % | ≥ 80 % |
+| `adapter.out.*` | ≥ 90 % | ≥ 75 % |
+| `adapter.in.cli` | ≥ 80 % | ≥ 60 % |
+| `bootstrap` | ausgenommen | ausgenommen |
+
+- Abweichungen von den Schwellwerten sind nur mit dokumentierter Begründung zulässig
+
+### Noch nicht Ziel von M9
+
+- GUI
+- Batch-Verarbeitung
+- Mehrversionssupport
+- Referenzdatenbestände
+- spätere Erweiterungen aus `Ausblick.md`
+
+### Abnahme von M9
+
+- Version 1 ist fachlich und technisch in sich geschlossen nutzbar
+- Bericht und Logging sind stabil, verständlich und sauber getrennt
+- Spec-Urteil wird nie durch Diagnose „grün gerechnet"
+- alle Quality-Gates sind erreicht oder bewusst dokumentiert abgewichen
+- das Projekt ist bereit für nachgelagerte Feinschnitte in Arbeitspakete
+
+## 5. Empfohlene Umsetzungslogik für die spätere Arbeitspaketbildung
+
+Aus dieser Meilensteinstruktur ergibt sich für die spätere Arbeitspaketbildung folgende sinnvolle Logik:
+
+1. Zuerst immer den **tragfähigen Unterbau** herstellen – inklusive Logging und Befundmodell mit Spec-/Diagnose-Trennung.
+2. Danach die **äußere technische Struktur**, die **globalen Rahmenregeln** und den **KKS-Auftragssatz** stabilisieren.
+3. Erst dann die **fachliche Tiefe von ASVREC** aufbauen.
+4. Storno und ASVFEH nicht vermischen, sondern als **eigene Prüfdimensionen** schneiden.
+5. PKCS#7 erst aufsetzen, wenn die innere Nutzlastvalidierung bereits stabil steht; die bestehende Kette wird wiederverwendet.
+6. Produktreife, Bericht, Doku und Qualitäts-Härtung am Ende konsolidieren.
+
+## 6. Definition of Done über alle Meilensteine hinweg
+
+Ein Meilenstein gilt nur dann als sinnvoll abgeschlossen, wenn mindestens die folgenden Punkte erfüllt sind:
+
+- der Stand ist **fachlich und technisch konsistent** zu den Grunddokumenten
+- Build und zugehörige Tests sind **grün**
+- der Meilenstein erzeugt keinen architektonischen Widerspruch zu den Grunddokumenten
+- nicht prüfbare `V1-N`- und nur teilprüfbare `V1-T`-Bereiche wurden nicht versehentlich als harte Pflichtprüfung umgesetzt
+- keine Elemente aus späteren Ausbaustufen wurden unbemerkt in Version 1 hineingezogen
+- die im jeweiligen Meilenstein genannten Abnahmekriterien sind erfüllt
+- der Stand ist stabil genug, um daraus anschließend **Arbeitspakete** abzuleiten
+
+Die finalen Quality-Gates für Version 1 (Coverage, Mutation, Zielschwellen pro Paket) gelten am Ende von M9. Zwischenmeilensteine müssen lediglich grün sein, nicht die finalen Schwellwerte vorwegnehmen.
+
+## 7. Zusammenfassung
+
+Die Implementierung von Version 1 sollte nicht entlang technischer Zufälle, sondern entlang einer klaren fachlich-technischen Reifung erfolgen:
+
+- zuerst **Grundgerüst, Logging und Befundmodell mit Spec-/Diagnose-Trennung**,
+- dann **Artefaktschicht, Dateinamen und globale Rahmenregeln**,
+- dann **Service- und KKS-Ebene**,
+- danach **ASVREC mit Beziehungslogik und Storno**,
+- anschließend **ASVFEH**,
+- danach **PKCS#7-Tiefenprüfung unter Wiederverwendung der bestehenden Kette**,
+- und zum Schluss **Bericht, Qualität und Release-Härtung**.
+
+Damit entsteht eine Meilensteinfolge, die klein genug für kontrollierte Weiterentwicklung bleibt, aber groß genug ist, um daraus später präzise und in sich geschlossene Arbeitspakete abzuleiten.
+
+## 8. Dokumenthistorie
+
+| Version | Wesentliche Änderungen |
+|---|---|
+| v1 | Erstfassung mit Meilensteinfolge M1–M9 |
+| v2 | Logging-Adapter und Spec-/Diagnose-Trennung als Fundament in M1 verankert; Dateinamensschemata und globale Rahmenregeln in M2 ergänzt; Service-Crosschecks in M3 vollständiger; KKS-Regelsatz in M4 erweitert und eigenständige `.AUF`-Validierbarkeit klargestellt; Sonderregeln in M5 ergänzt; Umgang mit Originalnachricht in M7 präzisiert; Wiederverwendung der Validierungskette in M8 explizit; Quality-Gates in M9 mit Zahlen. |
+| v3 | Zweck entschärft und Rangfolge der Grunddokumente klargestellt (Spec.docx als Wahrheit; `meilensteine.md` strukturiert lediglich). M3: Crosscheck `physischer Dateiname ↔ UNB_0020` korrekt als Übertragungsreferenz benannt (nicht „Senderkennung"); Vorgriff auf KKS-`VERFAHREN_KENNUNG` aus M3 entfernt und nach M4 verschoben. M4: Dateinamensbezug (physischer Dateiname, `UNB_0020`, KKS-`DATEINAME`, `.AUF`-Basisname) sauber begrifflich getrennt; unscharfe „bzw."-Formulierung ersetzt. M5: regionale Pseudo-GOP neben `88999` ausdrücklich aufgenommen; Vertretungs-Teamebene `4` als `V1-N` gekennzeichnet statt als aktive Prüfung; `NAD`-Hinweis entfernt. Gesamtes Dokument: in v2 eingeführte Zwischen-Quality-Gates (Coverage/Mutation pro Meilenstein) entfernt, da nicht aus den Grunddokumenten folgend; finale Gates bleiben in M9 erhalten. `V1-T`-Sprachregelung in den Leitplanken präzisiert. Kleinere sprachliche Glättungen. |