asv-format-validator/docs/arbeitspakete/m1

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