asv-format-validator/docs/arbeitspakete/m1/berichte/AP01-bericht.md

Abschlussbericht AP01 – Ist-Stand-Inventar und Delta-Analyse

Bezug: docs/arbeitspakete/m1/AP01-ist-stand-inventar.md Bearbeiter: Claude Code (claude-sonnet-4-6) Datum: 2026-04-09 Commit(s): — (kein Commit in AP01; der Mensch committet nach Prüfung) Status: ✅ abgeschlossen

---

1. Zusammenfassung

AP01 hat den vollständigen Ist-Stand der bestehenden Code-Basis inventarisiert und ein Delta zum M1-Soll dokumentiert. Der Build ist grün (147 Tests, 0 Fehler). Die wichtigsten Befunde: Die Paketstruktur ist schichtenbasiert statt hexagonal, es existiert ein vierter Exit-Code (3), der Soll-Stand kennt nur drei (0/1/2), das Eingabe-Encoding ist hartkodiert UTF-8 statt ISO 8859-15, und mehrere M1-Kernanforderungen (Befundmodell mit Spec-/Diagnose-Trennung, Logging-Adapter, Ausgabeartefakte, Suffix-Logik) fehlen vollständig. Der bestehende Code — insbesondere Parser, Domänenmodell und Fachvalidierung — ist qualitativ gut und kann in späteren APs erhalten und migriert werden.

---

2. Umgesetzte Änderungen

Keine Code-Änderungen. Keine pom.xml-Änderungen. Keine Datei-Verschiebungen.

Einzige neue Datei: docs/arbeitspakete/m1/berichte/AP01-bericht.md (dieser Bericht).

---

3. Scope-Treue

Scope-Punkt aus dem Arbeitspaket	Erfüllt?	Bemerkung
Vollständige Dateiliste src/main/java mit Kurzbeschreibung	✅	20 Klassen, alle beschrieben (Abschnitt 5.1)
Vollständige Dateiliste src/test/java mit Kurzbeschreibung	✅	21 Testklassen, alle beschrieben (Abschnitt 5.2)
Dependency-Liste aus pom.xml	✅	Abschnitt 5.3
Grep: org.apache.logging.log4j	✅	Abschnitt 5.4
Grep: StandardCharsets, Charset.forName	✅	Abschnitt 5.5
Grep: System.exit, EXIT_CODE	✅	Abschnitt 5.6
Ist-Paketstruktur als Baum	✅	Abschnitt 5.7
Delta-Tabelle Paketstruktur	✅	Abschnitt 5.8.1
Delta-Tabelle Exit-Codes	✅	Abschnitt 5.8.2
Delta-Tabelle fehlende M1-Elemente	✅	Abschnitt 5.8.3
Klassifikation pro Paket	✅	Abschnitt 5.9
Keine Code-Änderungen	✅	keine .java-Datei angefasst
Keine pom.xml-Änderungen	✅	—
Keine Datei-Verschiebungen	✅	—
Neue Dateien nur: AP01-bericht.md	✅	einzige neue Datei

Wurde der Scope eingehalten? Ja, vollständig.

Wurden Dinge außerhalb des Scopes gemacht? Nein.

---

4. Abnahmekriterien

Abnahmekriterium	Erfüllt?	Nachweis
berichte/AP01-bericht.md existiert	✅	dieser Bericht
Vollständige Dateiliste (main + test) mit Kurzbeschreibung	✅	Abschnitte 5.1 und 5.2
Dependency-Liste	✅	Abschnitt 5.3
Alle Grep-Fundstellen	✅	Abschnitte 5.4–5.6
Ist-vs-Soll-Paketstrukturbaum	✅	Abschnitte 5.7 und 5.8.1
Delta-Tabelle Exit-Codes	✅	Abschnitt 5.8.2
Delta-Tabelle fehlender M1-Elemente	✅	Abschnitt 5.8.3
Klassifikationstabelle pro Paket	✅	Abschnitt 5.9
mvn clean verify vor und nach AP01 identisch	✅	BUILD SUCCESS, 147 Tests; keine Änderungen vorgenommen
Keine neuen Dateien außer AP01-bericht.md	✅	git status zeigt nur diese Datei

---

5. Build- und Teststatus

5.0 Schritt 1: mvn clean verify

• Ergebnis: ✅ BUILD SUCCESS
• Anzahl Tests: 147 (0 neu; AP01 ändert keinen Code)
• Fehler / Skipped: 0 / 0
• Dauer: 11,930 Sekunden
• Coverage: noch nicht messbar (kein JaCoCo)

Warnungen beim Build (nicht blockierend):

Warnung	Quelle	Bewertung
Annotation-Processing aktiv, obwohl kein expliziter Prozessor angegeben	javac (2×, für main und test)	kosmetisch; kann mit -proc:none oder -Xlint:-options unterdrückt werden
Mockito self-attaching via ByteBuddy, wird in künftigen JDK-Releases nicht mehr funktionieren	Mockito / JVM	relevant für AP02: Mockito sollte als Java-Agent konfiguriert werden
Dynamic loading of agents will be disallowed in future release	JVM (ByteBuddy-Agent)	hängt mit dem Mockito-Problem zusammen; AP02-relevant
JVM Sharing only for boot loader classes	HotSpot	unerheblich für den Build

---

5.1 Dateiliste src/main/java (Schritt 2)

Paket de.gecheckt.asv.cli (2 Klassen)

Datei	Kurzbeschreibung
AsvValidatorApplication.java	Haupteinstiegspunkt (main), CLI-Bootstrap und Verdrahtung aller Komponenten per Default-Konstruktor; enthält Exit-Code-Konstanten, System.exit-Aufruf, Log4j2-Direktimport und liest die Eingabedatei mit StandardCharsets.UTF_8.
ValidationResultPrinter.java	Gibt ein ValidationResult formatiert auf der Konsole aus (Fehler, Warnungen, Infos); enthält die Darstellungslogik, kein Logging.

Paket de.gecheckt.asv.domain.model (4 Klassen)

Datei	Kurzbeschreibung
Field.java	Java Record: ein einzelnes Feld in einem Segment mit Position (positiv), Rohwert (nicht null) und optionalem Feldnamen; unveränderlich.
Segment.java	Java Record: ein Segment mit Name (nicht leer), Position (positiv) und unveränderlicher Feldliste; bietet Zugriffsmethoden (getField, hasFieldAt, getFieldCount).
Message.java	Java Record: eine Nachricht mit Position (positiv) und unveränderlicher Segmentliste; bietet Zugriffsmethoden (hasSegment, getSegments(name), getFirstSegment).
InputFile.java	Java Record: eine geparste Eingabedatei mit Dateiname (nicht leer) und unveränderlicher Nachrichtenliste; bietet getMessageCount.

Paket de.gecheckt.asv.parser (5 Klassen)

Datei	Kurzbeschreibung
InputFileParser.java	Interface: Kontrakt für das Parsen eines Dateiinhalts (String) in ein InputFile-Domänenobjekt.
DefaultInputFileParser.java	Standardimplementierung: liest zeilenweise via BufferedReader, ignoriert Leerzeilen, delegiert Tokenisierung an SegmentLineTokenizer; erzeugt vereinfachend genau eine Message pro Datei.
SegmentLineTokenizer.java	Interface: Kontrakt für das Tokenisieren einer Segmentzeile in Segmentname und Feldliste.
DefaultSegmentLineTokenizer.java	Standardimplementierung: trennt am +-Zeichen (hartkodiert), extrahiert Segmentname als ersten Token.
InputFileParseException.java	Checked Exception für Parsing-Fehler; wraps beliebige Ursachen.

Paket de.gecheckt.asv.validation (2 Klassen)

Datei	Kurzbeschreibung
InputFileValidator.java	Interface: Kontrakt für die Gesamtvalidierung einer InputFile; gibt ein ValidationResult zurück.
DefaultInputFileValidator.java	Orchestrator: führt StructureValidator und FieldValidator sequenziell aus und mergt die Teil-ValidationResults zu einem Gesamt-Ergebnis.

Paket de.gecheckt.asv.validation.field (2 Klassen)

Datei	Kurzbeschreibung
FieldValidator.java	Interface: Kontrakt für die Feldvalidierung einer InputFile.
DefaultFieldValidator.java	Implementierung: prüft Feldrohwerte auf Leerheit, Whitespace-only; prüft Feldnamen auf Leerheit; keine ASV-fachliche Logik.

Paket de.gecheckt.asv.validation.model (3 Klassen)

Datei	Kurzbeschreibung
ValidationSeverity.java	Enum mit drei Stufen: INFO, WARNING, ERROR.
ValidationError.java	Java Record: ein einzelner Validierungsbefund mit errorCode, description, severity, segmentName, segmentPosition, fieldName, fieldPosition, optionalem actualValue und optionalem expectedRule.
ValidationResult.java	Klasse: Sammlung von ValidationError-Instanzen mit Hilfsmethoden (hasErrors, hasWarnings, hasInfos, getErrors, getWarnings, getInfos, merge).

Paket de.gecheckt.asv.validation.structure (2 Klassen)

Datei	Kurzbeschreibung
StructureValidator.java	Interface: Kontrakt für die Strukturvalidierung einer InputFile.
DefaultStructureValidator.java	Implementierung mit 19 Prüfregeln: strukturelle Vollständigkeit (Nachrichten, Segmente, Feldpositionen), UNH/UNT-Referenzgleichheit, Segmentanzahl-Prüfung, Nachrichtentyp (ASVREC/ASVFEH), Pflicht-Segmente und Reihenfolge in ASVREC, Rechnungskennzeichen, Rechnungsbetrag bei Storno, DGN/LEA-Prüfung, FHL für ASVFEH.

Gesamtzahl Produktionsklassen: 20

---

5.2 Dateiliste src/test/java (Schritt 3)

Testklasse	Tests (laut Build)	Kurzbeschreibung
cli/AsvValidatorApplicationTest	3	Testet run() mit fehlenden Argumenten, nicht-existenter Datei und (via Mock) korrekter Verarbeitung.
cli/AsvValidatorApplicationAdditionalTest	3	Weitere run()-Szenarien: InputFileParseException, Validierungsfehler (Exit-Code 3), allgemeine Exception.
cli/ValidationResultPrinterTest	3	Testet Konsolenausgabe bei Fehlern/Warnungen/Infos und leerem Ergebnis (Null-Guard).
domain/model/FieldTest	6	Konstruktorvalidierung für Field: illegale Positionen, null-Rohwert, optionaler Feldname.
domain/model/InputFileTest	9	Konstruktorvalidierung und Methoden für InputFile.
domain/model/MessageTest	11	Konstruktorvalidierung und Methoden für Message.
domain/model/SegmentTest	12	Konstruktorvalidierung und Methoden für Segment.
parser/DefaultInputFileParserTest	8	Parsing verschiedener Dateiformate (Leerzeilen, mehrzeilig, Segmentnamen).
parser/DefaultSegmentLineTokenizerTest	3	Tokenisierung: Segmentname-Extraktion, Feldaufteilung.
validation/DefaultInputFileValidatorTest	5	Orchestrierung: null-Guard, Struktur- und Feldvalidator werden aufgerufen, Merge.
validation/field/DefaultFieldValidatorTest	9	Feldvalidierungsregeln: Leerheit, Whitespace, Feldname.
validation/model/ValidationErrorTest	3	Record-Konstruktor, Optional-Getter für actualValue und expectedRule.
validation/model/ValidationResultTest	2	hasErrors, merge.
validation/structure/DefaultStructureValidatorTest	22	Allgemeine Strukturregeln (Regeln 1–11 aus DefaultStructureValidator).
validation/structure/DefaultStructureValidatorTestAdditional	0	Datei vorhanden, keine @Test-Methoden; vermutlich Hilfsmethoden oder Vorbereitung.
validation/structure/DefaultStructureValidatorAsvfehFhlSegmentTest	8	FHL-Segment-Pflicht für ASVFEH (Regel 19).
validation/structure/DefaultStructureValidatorAsvrecRechnungsbetragTest	7	Rechnungsbetrag 0,00 bei Storno-Rechnungskennzeichen (Regel 17).
validation/structure/DefaultStructureValidatorAsvrecRechnungskennzeichenTest	12	Rechnungskennzeichen-Prüfungen (Regeln 15–16).
validation/structure/DefaultStructureValidatorAsvrecSegmentCardinalityTest	9	Segment-Kardinalität IFA/REA/IVA (Regel 18).
validation/structure/DefaultStructureValidatorAsvrecSegmentOrderTest	5	Segment-Reihenfolge IFA → REA → IVA (Regel 14).
validation/structure/DefaultStructureValidatorAsvrecSegmentsTest	7	Pflicht-Segmente IFA, REA, IVA (Regel 13).
Gesamt	147

Gesamtzahl Testklassen: 21 (davon 1 ohne @Test-Methoden)

---

5.3 Dependencies aus pom.xml (Schritt 3 Ergänzung)

Dependency	Version	Scope	Zweck
org.apache.logging.log4j:log4j-api	2.20.0	compile	Log4j2 API
org.apache.logging.log4j:log4j-core	2.20.0	compile	Log4j2 Implementierung
org.junit.jupiter:junit-jupiter	5.9.2	test	JUnit 5
org.mockito:mockito-core	5.23.0	test	Mockito

Plugins:

Plugin	Version	Zweck
maven-compiler-plugin	3.11.0	Compiler-Konfiguration (Java 21)
maven-surefire-plugin	3.0.0	Test-Runner

Fehlend laut M1-Soll: slf4j-api, log4j-slf4j2-impl, maven-jar-plugin (Main-Class), jacoco-maven-plugin, PIT/Pitest-Plugin.

---

5.4 Grep: Log4j2-Direktimporte (Schritt 4)

src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:23: import org.apache.logging.log4j.LogManager;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:24: import org.apache.logging.log4j.Logger;

Befund: Log4j2-Typen werden ausschließlich in AsvValidatorApplication direkt importiert. Kein Test-Code importiert Log4j2. Laut Soll-Architektur dürfen Log4j2-Typen nur in bootstrap und adapter.out.logging sichtbar sein.

---

5.5 Grep: Zeichensatz-Setzen (Schritt 5)

src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:18: import java.nio.charset.StandardCharsets;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:151:         String fileContent = Files.readString(path, StandardCharsets.UTF_8);

Befund: Die Eingabedatei wird mit StandardCharsets.UTF_8 gelesen. Laut Soll-Architektur (technik-und-architektur.md) und fachlicher Anforderung (R-GLOBAL-ZEICHENSATZ-001) ist ISO 8859-15 verpflichtend. Charset.forName wird nicht verwendet. Kein weiterer Zeichensatz-Code im gesamten Projekt.

---

5.6 Grep: System.exit und Exit-Code-Konstanten (Schritt 6)

src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:35:     private static final int EXIT_CODE_SUCCESS = 0;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:36:     private static final int EXIT_CODE_INVALID_ARGUMENTS = 1;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:37:     private static final int EXIT_CODE_FILE_ERROR = 2;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:38:     private static final int EXIT_CODE_VALIDATION_ERRORS = 3;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:83:         System.exit(exitCode);
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:96:             return EXIT_CODE_INVALID_ARGUMENTS;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:112:             return result.hasErrors() ? EXIT_CODE_VALIDATION_ERRORS : EXIT_CODE_SUCCESS;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:117:             return EXIT_CODE_FILE_ERROR;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:121:             return EXIT_CODE_FILE_ERROR;
src/main/java/de/gecheckt/asv/cli/AsvValidatorApplication.java:125:             return EXIT_CODE_FILE_ERROR;

Befund: System.exit wird genau einmal aufgerufen (Zeile 83, in main). Die Methode run() gibt einen int-Exit-Code zurück und ist damit testbar — das ist ein positives Muster. Es existieren vier Exit-Code-Konstanten statt drei.

---

5.7 Ist-Paketstruktur (Schritt 7)

src/main/java/de/gecheckt/asv/
├── cli/
│   ├── AsvValidatorApplication.java
│   └── ValidationResultPrinter.java
├── domain/
│   └── model/
│       ├── Field.java
│       ├── InputFile.java
│       ├── Message.java
│       └── Segment.java
├── parser/
│   ├── DefaultInputFileParser.java
│   ├── DefaultSegmentLineTokenizer.java
│   ├── InputFileParseException.java
│   ├── InputFileParser.java
│   └── SegmentLineTokenizer.java
└── validation/
    ├── DefaultInputFileValidator.java
    ├── InputFileValidator.java
    ├── field/
    │   ├── DefaultFieldValidator.java
    │   └── FieldValidator.java
    ├── model/
    │   ├── ValidationError.java
    │   ├── ValidationResult.java
    │   └── ValidationSeverity.java
    └── structure/
        ├── DefaultStructureValidator.java
        └── StructureValidator.java

src/test/java/de/gecheckt/asv/
├── cli/
│   ├── AsvValidatorApplicationAdditionalTest.java
│   ├── AsvValidatorApplicationTest.java
│   └── ValidationResultPrinterTest.java
├── domain/
│   └── model/
│       ├── FieldTest.java
│       ├── InputFileTest.java
│       ├── MessageTest.java
│       └── SegmentTest.java
├── parser/
│   ├── DefaultInputFileParserTest.java
│   └── DefaultSegmentLineTokenizerTest.java
└── validation/
    ├── DefaultInputFileValidatorTest.java
    ├── field/
    │   └── DefaultFieldValidatorTest.java
    ├── model/
    │   ├── ValidationErrorTest.java
    │   └── ValidationResultTest.java
    └── structure/
        ├── DefaultStructureValidatorAsvfehFhlSegmentTest.java
        ├── DefaultStructureValidatorAsvrecRechnungsbetragTest.java
        ├── DefaultStructureValidatorAsvrecRechnungskennzeichenTest.java
        ├── DefaultStructureValidatorAsvrecSegmentCardinalityTest.java
        ├── DefaultStructureValidatorAsvrecSegmentOrderTest.java
        ├── DefaultStructureValidatorAsvrecSegmentsTest.java
        ├── DefaultStructureValidatorTest.java
        └── DefaultStructureValidatorTestAdditional.java

Soll-Paketstruktur laut technik-und-architektur.md:

de.gecheckt.asv.
├── domain
├── application
├── adapter.in.cli
├── adapter.out.filesystem
├── adapter.out.parsing
├── adapter.out.crypto
├── adapter.out.reporting
├── adapter.out.logging
└── bootstrap

---

5.8 Delta-Tabellen (Schritt 8)

5.8.1 Paketstruktur Ist vs. Soll

Soll-Paket	Entsprechung im Ist	Status	Bemerkung
domain	domain.model	⚠️ teilweise	Nur Dateimodell vorhanden; Befundmodell fehlt; Paketname ist domain.model, nicht domain
application	—	❌ fehlt	Orchestrierungslogik liegt in validation (DefaultInputFileValidator)
adapter.in.cli	cli	⚠️ teilweise	CLI-Code vorhanden, aber falscher Paketname; enthält auch Bootstrap-Logik
adapter.out.filesystem	—	❌ fehlt	Dateisystemzugriff (Files.readString) liegt direkt in AsvValidatorApplication
adapter.out.parsing	parser	⚠️ teilweise	Parser vorhanden und gut, aber falscher Paketname
adapter.out.crypto	—	❌ fehlt	In M1 noch nicht benötigt (PKCS#7 erst in M8)
adapter.out.reporting	cli (ValidationResultPrinter)	⚠️ teilweise	Klasse existiert, liegt im falschen Paket
adapter.out.logging	—	❌ fehlt	Log4j2 direkt in cli.AsvValidatorApplication
bootstrap	—	❌ fehlt	Bootstrap-Logik in AsvValidatorApplication.main() und Default-Konstruktor
—	validation	⚠️ kein Soll-Äquivalent	Application-Logik im falschen Paket
—	validation.model	⚠️ kein Soll-Äquivalent	Gehört fachlich näher zu domain
—	validation.structure	⚠️ kein Soll-Äquivalent	Teils domain-Logik, teils application-Logik
—	validation.field	⚠️ kein Soll-Äquivalent	Teils domain-Logik, teils application-Logik

5.8.2 Exit-Codes Ist vs. Soll

Konstante (Ist)	Ist-Wert	Soll-Wert	Soll-Semantik	Bewertung
EXIT_CODE_SUCCESS	0	0	gültig	✅ übereinstimmend
EXIT_CODE_INVALID_ARGUMENTS	1	2	Bedienfehler	❌ Diskrepanz: Ist=1, Soll=2
EXIT_CODE_FILE_ERROR	2	2	Bedienfehler	⚠️ zufällig gleicher Wert, aber semantisch überlappt mit EXIT_CODE_INVALID_ARGUMENTS; laut Soll ist 2 der einzige Bedienfehler-Code
EXIT_CODE_VALIDATION_ERRORS	3	1	ungültig	❌ Diskrepanz: Ist=3, Soll=1; dieser Code existiert im Soll nicht

Kernproblem: Der Ist-Stand hat vier Exit-Codes; der Soll-Stand hat drei. EXIT_CODE_INVALID_ARGUMENTS=1 und EXIT_CODE_VALIDATION_ERRORS=3 sind gegenüber dem Soll vertauscht/falsch. EXIT_CODE_INVALID_ARGUMENTS und EXIT_CODE_FILE_ERROR sollen im Soll zusammengeführt werden zu einem einzigen Bedienfehler-Code 2.

5.8.3 Fehlende M1-Elemente

M1-Element	Status	Ist-Befund	Soll-Anforderung
Befundmodell mit Spec-/Diagnose-Trennung	❌ fehlt	ValidationError/ValidationResult kennen keine Trennung zwischen Spec-Urteil und diagnostischer Weiteranalyse; alles in einem List<ValidationError>	Strukturell trennen: verbindliches Prüfurteil (Spec) ≠ diagnostische Weiteranalyse; Diagnose darf Spec-Urteil nicht verändern (AP05)
SLF4J als Logging-Fassade	❌ fehlt	Log4j2 direkt importiert in AsvValidatorApplication; kein SLF4J in pom.xml	SLF4J als Fassade, Log4j2 als Bindung; Bindung nur in adapter.out.logging und bootstrap (AP04)
Berichtdatei im Eingabeverzeichnis (.txt)	❌ fehlt	Kein File-Output implementiert; nur Konsolenausgabe via ValidationResultPrinter	.txt-Datei im Verzeichnis der Eingabedatei, UTF-8 (AP07)
Log-Datei im Eingabeverzeichnis (.log)	❌ fehlt	Kein File-Logging konfiguriert	.log-Datei im Verzeichnis der Eingabedatei, UTF-8 (AP07)
Suffix-Logik _v1/_v2	❌ fehlt	Kein Mehrfachlauf-Mechanismus vorhanden	Laufendes Suffix bei bereits existierenden Ausgabedateien (AP07)
Minimalbericht bei Exit-Code 2	❌ fehlt	Bei Fehlern nur System.err.println, kein strukturierter Bericht; kein Bericht bei Bedienfehler	Auch bei Exit-Code 2 muss ein nachvollziehbarer Minimalbericht entstehen (AP08)
ISO 8859-15 als Eingabe-Encoding	❌ fehlt	Files.readString(path, StandardCharsets.UTF_8) — hartkodiert UTF-8	StandardCharsets.ISO_8859_1 reicht nicht; muss ISO-8859-15 (Level C) sein; Level-C-Charset nicht in Standard-Java-API (AP02/AP03)
Hexagonale Paketstruktur	❌ fehlt	Schichtenbasierte Struktur: cli, domain, parser, validation	Hexagonale Trennung: domain, application, adapter.*, bootstrap (AP03)
Manueller Bootstrap per Constructor Injection	⚠️ teilweise	Default-Konstruktor in AsvValidatorApplication verdrahtet Komponenten per new; aber im falschen Paket und vermischt mit CLI-Logik	Separates bootstrap-Paket mit dünner Bootstrap-Klasse; vollständig entkoppelt (AP06)
JaCoCo im Build	❌ fehlt	Kein jacoco-maven-plugin in pom.xml	Coverage-Messung als Quality-Gate (AP02)
PIT / Mutation-Testing im Build	❌ fehlt	Kein pitest-maven-Plugin in pom.xml	Mutation-Testing-Profil (AP02)

---

5.9 Klassifikation pro Ist-Paket (Schritt 9)

Ist-Paket	enthält	Klassifikation	Begründung
cli	AsvValidatorApplication, ValidationResultPrinter	behalten und anpassen	AsvValidatorApplication enthält Bootstrap-Logik, CLI-Logik, Dateisystemzugriff und Logging vermischt; muss in AP03/AP06 aufgeteilt werden. ValidationResultPrinter ist strukturell sauber und kann nach adapter.out.reporting migriert werden.
domain.model	Field, Segment, Message, InputFile	behalten und migrieren	Records sind technisch gut und korrekt; das Domänenmodell der Dateistruktur wird erhalten. Paket muss zu domain (ohne Sub-Paket model) migriert oder dort integriert werden. Das Befundmodell fehlt vollständig und wird in AP05 neu gebaut.
parser	InputFileParser, DefaultInputFileParser, SegmentLineTokenizer, DefaultSegmentLineTokenizer, InputFileParseException	behalten und migrieren	Gut strukturierter, wertvoller Parser-Code mit sauberem Interface-Kontrakt; muss nach adapter.out.parsing migriert werden. Der hartkodierte +-Trenner ist ein Rest-Risiko (UNA-Segment fehlt).
validation	InputFileValidator, DefaultInputFileValidator	behalten und anpassen	Orchestrator-Pattern ist gut (Interface + Implementierung, Constructor Injection, Merge-Logik); muss nach application migriert und ggf. an das neue Befundmodell angepasst werden.
validation.model	ValidationSeverity, ValidationError, ValidationResult	behalten und anpassen	Strukturell solide; ValidationError als Record ist gut. Das Befundmodell kennt keine Spec-/Diagnose-Trennung und wird in AP05 erweitert. Paketziel: Aufgehen in domain (Befundmodell) oder umbenannt als domain.finding.
validation.structure	StructureValidator, DefaultStructureValidator	später verwenden (M3+)	Enthält substantielle ASVREC/ASVFEH-Fachvalidierung mit 19 Regeln — wertvoll, aber M1-fremd. In AP09 einfrieren (als Vorbau für M3+ erhalten, nicht aktiv in den M1-Lauf verdrahtet).
validation.field	FieldValidator, DefaultFieldValidator	später verwenden (M3+)	Ähnlich wie validation.structure: wertvolle Feldlogik, die in M1 nicht weiterentwickelt wird; in AP09 einfrieren.

---

6. Rest-Risiken und offene Punkte

1. Trennzeichen hartkodiert (+): DefaultSegmentLineTokenizer trennt immer am +-Zeichen, ohne das UNA-Segment auszuwerten. ASV erlaubt (gemäß Spezifikation) ein optionales UNA-Segment, das die tatsächlich verwendeten Trennzeichen definiert. Dies ist ein bekanntes technisches Risiko für den Parser (relevant ab M3).

2. Mockito-Agent-Warnung: Mockito 5.23.0 nutzt ByteBuddy-Self-Attach, das in künftigen JDK-Versionen nicht mehr erlaubt sein wird. In AP02 sollte Mockito als expliziter Java-Agent konfiguriert werden (argLine in maven-surefire-plugin).

3. ISO 8859-15 nicht in Standard-Java-API: java.nio.charset.StandardCharsets kennt nur ISO_8859_1 (Latin-1), nicht ISO 8859-15 (Latin-9). Für ISO 8859-15 muss Charset.forName("ISO-8859-15") verwendet werden. Dies muss in AP02 oder AP03 sorgfältig behandelt werden (Charset-Verfügbarkeit im JDK prüfen).

4. DefaultStructureValidatorTestAdditional ohne Tests: Die Datei existiert, enthält aber keine @Test-Methoden. Dies ist unkritisch, sollte aber in AP10 aufgeräumt werden (entweder Tests hinzufügen oder Datei entfernen).

5. DefaultInputFileParser erzeugt immer genau eine Message: Der Parser erzeugt per Design „vereinfachend" genau eine Nachricht pro Datei (// For this simplified version, we assume exactly one message per file). Dies ist für M1 akzeptabel, muss aber spätestens in M3 überarbeitet werden.

6. Klassifikation als Arbeitsgrundlage: Die Einschätzungen in Abschnitt 5.9 sind konservativ; die tatsächliche Entscheidung über Verbleib oder Neubau kann in späteren APs revidiert werden.

7. Keine Main-Class im JAR-Manifest: Das aktuelle pom.xml konfiguriert kein maven-jar-plugin mit Main-Class-Manifest-Eintrag. Das JAR ist nach mvn package nicht direkt mit java -jar startbar.

---

7. Empfehlungen für Folge-Arbeitspakete

• AP02 (Build-Infrastruktur): SLF4J- und Log4j2-SLF4J-Bridge-Dependency hinzufügen, JaCoCo und PIT konfigurieren, maven-jar-plugin mit Main-Class einrichten, Mockito als Java-Agent in maven-surefire-plugin konfigurieren (Warnung beheben).

• AP03 (Paketstruktur): Die Klassifikationstabelle (Abschnitt 5.9) kann direkt als Migrationsleitfaden verwendet werden. validation.structure und validation.field sind bewusst für später verwenden (M3+) markiert — AP09 soll sie einfrieren.

• AP05 (Befundmodell): Das bestehende ValidationError/ValidationResult-Modell kann als Ausgangspunkt dienen, muss aber um die Spec-/Diagnose-Trennung erweitert werden. ValidationSeverity könnte erhalten bleiben.

• AP06 (Bootstrap/CLI): Exit-Code-Konstanten komplett ersetzen: 0 = gültig, 1 = ungültig, 2 = Bedienfehler. Den hartkodiert-UTF-8-Lesezugriff auf ISO 8859-15 umstellen.

---

8. Reviewer-Checkliste

• Alle im Arbeitspaket genannten Scope-IN-Punkte sind nachweislich umgesetzt (Abschnitte 5.1–5.9)
• Keine Scope-OUT-Punkte wurden angefasst (keine Code-, pom.xml- oder Datei-Änderungen)
• Abnahmekriterien sind mit konkreten Nachweisen belegt (Abschnitt 4)
• mvn clean verify ist grün (147 Tests, BUILD SUCCESS — Abschnitt 5.0)
• Der Commit für dieses AP hat eine sprechende Message (M1-AP01: Ist-Stand-Inventar und Delta-Analyse) — Commit liegt beim Menschen
• Keine Regeln der Grunddokumente (Spec, Fachliche, Technik) wurden verletzt
• Rest-Risiken sind ehrlich dokumentiert (Abschnitt 6)