Dokumentation und Arbeitspakete angelegt

docs/arbeitspakete/m1/README.md

@@ -0,0 +1,83 @@
+# M1 – Arbeitspakete (Übersicht)
+
+> **Bezug:** Meilenstein 1 aus `docs/specs/meilensteine.md` v3
+> **Ziel:** tragfähiger technischer Sockel mit Logging-Adapter und Befundmodell (Spec-/Diagnose-Trennung); noch keine ASV-Fachvalidierung
+> **Ist-Zustand:** Repo enthält bereits eine frühere, schichtenbasierte Implementierung mit Parser-, Validator- und Feldlogik (Commit `32d50ec` vom 27.03.2026). Diese muss erhalten, aber ins hexagonale Zielbild überführt werden.
+> **Vorgehen:** **evolutionär, nicht in einem Wurf.** Jedes Arbeitspaket endet in einem grünen, stabilen Zwischenstand.
+
+## Leitprinzipien für alle M1-Arbeitspakete
+
+1. **So viel wie möglich aus dem Ist-Stand erhalten und refactoren**, nicht wegwerfen. Insbesondere Parser, Tokenizer und Validator-Gerüst sind wertvoll und gehören später in `adapter.out.parsing` bzw. `application`.
+2. **Jedes Arbeitspaket endet mit einem Bericht** (`berichte/AP-MX-XX.md`) nach dem Schema in `templates/ap-bericht.md`.
+3. **Jedes Arbeitspaket endet grün:** `mvn clean verify` muss durchlaufen. Build, Compile, Tests.
+4. **Keine Fachvalidierung in M1.** Wer versucht, schon EDIFACT-Strukturprüfungen o.ä. einzubauen, verletzt den Scope. Bestehende Fachvalidierung darf erhalten bleiben, aber sie wird in M1 **nicht weiterentwickelt**.
+5. **Commit-Strategie:** ein Commit pro Arbeitspaket, Commit-Message `M1-APxx: <Titel>`.
+6. **Reviewbarkeit:** Der Bericht pro Arbeitspaket muss so präzise sein, dass ein unabhängiger Rezensent ohne Rückfragen prüfen kann, ob alles korrekt und in-scope umgesetzt wurde.
+
+## Arbeitspaket-Folge
+
+| AP | Titel | Hauptnutzen | Abhängigkeit |
+|---|---|---|---|
+| **AP01** | Ist-Stand-Inventar und Delta-Analyse | dokumentierter Ausgangspunkt, keine Überraschungen später | — |
+| **AP02** | Build-Infrastruktur härten: SLF4J, JaCoCo, PIT, maven-jar-plugin, .editorconfig | `pom.xml` ist M1-tauglich, Quality-Gates messbar vorbereitet | AP01 |
+| **AP03** | Hexagonale Paketstruktur anlegen und Ist-Code migrieren | Soll-Paketstruktur steht, bestehender Code ist eingeordnet, nichts geht kaputt | AP02 |
+| **AP04** | Logging-Adapter (SLF4J-Fassade + Log4j2-Bindung) | Log4j2-Imports sind nur noch im Logging-Adapter und im Bootstrap sichtbar | AP03 |
+| **AP05** | Befundmodell mit Spec-/Diagnose-Trennung (Domain) | `Finding`, `Severity`, `Verdict`, Metadata-Felder, strikt getrennt | AP03 |
+| **AP06** | Bootstrap und CLI-Adapter: ein Positionsargument, Exit-Codes 0/1/2 | Exit-Codes sind spec-konform, Bootstrap verdrahtet manuell | AP05 |
+| **AP07** | Ausgabeartefakte: Berichtdatei und Log-Datei im Eingabeverzeichnis mit Suffix-Logik | `.txt`/`.log` werden erzeugt, Suffix `_v1/_v2/...` funktioniert, UTF-8 | AP06 |
+| **AP08** | Minimalbericht bei Exit-Code 2 (Bedienfehler) | auch bei fehlendem/falschem Argument oder nicht lesbarer Datei entsteht ein nachvollziehbarer Bericht | AP07 |
+| **AP09** | Altlogik aus M1 entkoppeln: Parser/Validator in Adapter-/Application-Schicht eingefroren | bestehende Parser-/Validator-Logik ist erhalten, aber explizit als „Vorbau für M3+" markiert und nicht aktiv in den M1-Lauf verdrahtet | AP06 |
+| **AP10** | Architekturtest: Log4j2-Sichtbarkeit, Paketabhängigkeiten, M1-Abnahme | ArchUnit-Test oder einfacher Klassenpfad-Scan stellt sicher, dass die Regeln eingehalten werden | AP04, AP09 |
+| **AP11** | M1-Abnahme: grüner End-to-End-Lauf mit Minimaldatei, alle AP-Berichte konsolidiert | Meilenstein abgeschlossen, Übergabe an M2 möglich | alle vorigen |
+
+## Verzeichnisstruktur (im Repo anzulegen)
+
+```
+docs/
+  arbeitspakete/
+    m1/
+      README.md                    (diese Datei)
+      templates/
+        ap-bericht.md              (Berichtsvorlage)
+      AP01-ist-stand-inventar.md
+      AP02-build-infrastruktur.md
+      AP03-hexagonale-paketstruktur.md
+      AP04-logging-adapter.md
+      AP05-befundmodell.md
+      AP06-bootstrap-cli.md
+      AP07-ausgabeartefakte.md
+      AP08-minimalbericht.md
+      AP09-altlogik-einfrieren.md
+      AP10-architekturtest.md
+      AP11-m1-abnahme.md
+      berichte/
+        AP01-bericht.md            (nach Abschluss)
+        AP02-bericht.md
+        ...
+```
+
+## Grobumfang pro AP
+
+Jedes Arbeitspaket hat eine eigene Datei mit:
+- **Ziel** (was soll erreicht werden)
+- **Voraussetzungen** (welche APs müssen abgeschlossen sein)
+- **Scope IN** (was explizit Teil dieses APs ist)
+- **Scope OUT** (was explizit NICHT Teil dieses APs ist)
+- **Schritte** (konkrete Handlungsanleitung)
+- **Abnahmekriterien** (messbar, reviewbar)
+- **Rest-Risiken und offene Punkte** (was kann schiefgehen, was bleibt offen)
+- **Berichtsschablone** (Hinweis, den Abschlussbericht nach `templates/ap-bericht.md` anzulegen)
+
+## Definition of Done für den gesamten M1
+
+Ein M1 ist abgenommen, wenn:
+
+- alle 11 Arbeitspakete grün abgeschlossen sind
+- für jedes Arbeitspaket ein Abschlussbericht in `docs/arbeitspakete/m1/berichte/` existiert
+- die Anwendung als ausführbares JAR vorliegt und mit `java -jar asv-format-validator.jar <datei>` startbar ist
+- die Exit-Codes 0/1/2 spec-konform sind
+- Bericht- und Log-Datei im Eingabeverzeichnis erzeugt werden
+- Log4j2-Typen außerhalb von Bootstrap und Logging-Adapter nicht mehr importiert werden (per Architekturtest nachweisbar)
+- Befundmodell trennt Spec-Urteil und diagnostische Weiteranalyse
+- `mvn clean verify` ist grün
+- M1-Abnahmebericht (`AP11-bericht.md`) fasst alles zusammen