# 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. |