# 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-`ValidationResult`s 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

- [x] Alle im Arbeitspaket genannten Scope-IN-Punkte sind nachweislich umgesetzt (Abschnitte 5.1–5.9)
- [x] Keine Scope-OUT-Punkte wurden angefasst (keine Code-, `pom.xml`- oder Datei-Änderungen)
- [x] Abnahmekriterien sind mit konkreten Nachweisen belegt (Abschnitt 4)
- [x] `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_
- [x] Keine Regeln der Grunddokumente (Spec, Fachliche, Technik) wurden verletzt
- [x] Rest-Risiken sind ehrlich dokumentiert (Abschnitt 6)