Dokumentation und Arbeitspakete angelegt

docs/arbeitspakete/m1/AP06-bootstrap-cli.md

@@ -0,0 +1,96 @@
+# AP06 – Bootstrap und CLI-Adapter
+
+## Ziel
+
+Die bestehende `AsvValidatorApplication` wird in zwei klar getrennte Verantwortlichkeiten zerlegt:
+
+1. **Bootstrap** (`de.gecheckt.asv.bootstrap.Main`) — verdrahtet die Komponenten manuell per Constructor Injection und ist der einzige `public static void main`.
+2. **CLI-Adapter** (`de.gecheckt.asv.adapter.in.cli.CliRunner` oder ähnlich) — nimmt CLI-Argumente entgegen, ruft die Application-Schicht auf, übersetzt das Ergebnis in einen Exit-Code.
+
+Zusätzlich werden die **Exit-Codes spec-konform** auf `0/1/2` umgestellt.
+
+## Voraussetzungen
+
+- AP03, AP04, AP05
+
+## Scope IN
+
+### Bootstrap
+- Klasse `de.gecheckt.asv.bootstrap.Main` mit `public static void main(String[] args)`
+- verdrahtet manuell:
+  - Logging-Konfigurator
+  - CLI-Runner
+  - (Application-Service — Platzhalter, wird in AP09 feingeschnitten)
+- ruft `CliRunner.run(args)` auf, gibt den zurückgegebenen Exit-Code an `System.exit` weiter
+
+### CLI-Adapter
+- Klasse `CliRunner` im Paket `adapter.in.cli`
+- Methode `int run(String[] args)`
+- akzeptiert **genau ein Positionsargument**: den Pfad zur Eingabedatei
+- bei 0 oder ≥2 Argumenten → Exit-Code `2`, Minimalbericht-Vorbereitung (vollständige Minimalbericht-Logik kommt in AP08)
+- bei nicht existierender, nicht lesbarer oder nicht regulärer Eingabedatei → Exit-Code `2`
+- bei erfolgreichem Lauf ohne Spec-Fehler → Exit-Code `0`
+- bei erfolgreichem Lauf mit Spec-Fehlern → Exit-Code `1`
+
+### Exit-Code-Konstanten
+- Konstanten **nur noch in einer Klasse** (z.B. `ExitCode` im Paket `adapter.in.cli`)
+- Werte:
+  - `0` = gültig, keine Fehler-Befunde
+  - `1` = ungültig, mindestens ein Spec-Fehler
+  - `2` = Bedienfehler
+- Die alten Konstanten (`EXIT_CODE_INVALID_ARGUMENTS=1`, `EXIT_CODE_FILE_ERROR=2`, `EXIT_CODE_VALIDATION_ERRORS=3`) werden **gelöscht**
+
+### Verdrahtung mit Befundmodell (AP05)
+- `CliRunner` gibt am Ende einen `ValidationReport` aus AP05 weiter oder erzeugt selbst einen Minimal-`ValidationReport` mit einem `Finding` des Kinds `SPEC`, Severity `ERROR`, Layer `ARTIFACT` im Bedienfehlerfall
+- das eigentliche Einlesen und Verarbeiten der Datei kann für M1 noch ein **Dummy-Pfad** sein: die Datei wird gelesen, die Bytes gezählt, ein leerer `ValidationReport` mit `fileName` und `timestamp` zurückgegeben. Echte Validierung gehört nicht in M1.
+
+### Zeichensatz-Korrektur
+- beim Einlesen der Eingabedatei wird **ISO 8859-15** verwendet, nicht UTF-8. Das ist eine harte Spec-Vorgabe aus `fachliche-anforderungen.md` §5.1 und muss ab jetzt dauerhaft so bleiben.
+  ```java
+  Files.readString(path, StandardCharsets.ISO_8859_1);  // nicht ideal — besser Charset.forName("ISO-8859-15")
+  ```
+  Achtung: Java kennt `StandardCharsets.ISO_8859_1`, aber **nicht** `ISO_8859_15`. Daher `Charset.forName("ISO-8859-15")` verwenden.
+
+## Scope OUT
+
+- Berichtdatei und Log-Datei im Eingabeverzeichnis (AP07)
+- vollständiger Minimalbericht bei Exit-Code `2` (AP08)
+- Entkopplung der Altlogik (AP09)
+- Architekturtest (AP10)
+
+## Schritte
+
+1. Branch `m1/ap06-bootstrap-cli`
+2. `de.gecheckt.asv.bootstrap.Main` anlegen mit `public static void main`
+3. `CliRunner` in `adapter.in.cli` anlegen
+4. `ExitCode`-Konstantenklasse anlegen
+5. `AsvValidatorApplication` schrittweise entkernen: Code wandert nach `CliRunner` und `Main`
+6. Einlese-Encoding auf `Charset.forName("ISO-8859-15")` umstellen
+7. `maven-jar-plugin` in `pom.xml` auf `de.gecheckt.asv.bootstrap.Main` setzen (Platzhalter aus AP02 konkretisieren)
+8. Alle Tests, die auf `AsvValidatorApplication` direkt zeigen, auf `CliRunner` umziehen
+9. `mvn clean package` laufen lassen, das erzeugte JAR manuell mit `java -jar target/asv-format-validator-*.jar <test-datei>` prüfen
+10. `mvn clean verify` grün bekommen
+11. Commit `M1-AP06: Bootstrap, CLI-Adapter, Exit-Codes 0/1/2, ISO 8859-15`
+12. Abschlussbericht schreiben
+
+## Abnahmekriterien
+
+- `de.gecheckt.asv.bootstrap.Main` existiert und ist `Main-Class` des JAR
+- `CliRunner` ist der einzige Ort mit CLI-Argument-Parsing
+- Exit-Codes `0`, `1`, `2` sind definiert und spec-konform eingesetzt
+- **Test:** Aufruf ohne Argument → Exit-Code `2`
+- **Test:** Aufruf mit nicht existierender Datei → Exit-Code `2`
+- **Test:** Aufruf mit leerer, lesbarer Datei → Exit-Code `0` (Dummy-Pfad, leerer `ValidationReport`)
+- Einlese-Encoding ist ISO 8859-15 (per Test belegt: eine Datei mit Byte `0xA4` ergibt beim Einlesen `€`, weil `0xA4` in ISO 8859-15 auf Euro-Zeichen liegt)
+- ausführbares JAR unter `target/` ist manuell startbar
+- `mvn clean verify` ist grün
+- Abschlussbericht liegt vor
+
+## Rest-Risiken und offene Punkte
+
+- Der Dummy-Pfad (Datei wird gelesen, leerer Report zurückgegeben) ist bewusst dünn. Die Einbindung der alten Parser-Logik passiert in AP09.
+- Es ist verlockend, schon hier in AP06 die bestehende Parser-/Validator-Kette mit dem neuen Modell zu verknüpfen. **Nicht tun.** AP06 soll nur die äußere Hülle geradeziehen.
+
+## Bericht
+
+`docs/arbeitspakete/m1/berichte/AP06-bericht.md` nach `templates/ap-bericht.md`.