84 lines
5.3 KiB
Markdown
84 lines
5.3 KiB
Markdown
# 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
|