# 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