marcus/asv-format-validator
1
0
Fork 0
Code Activity
Files
main
asv-format-validator/docs/arbeitspakete/m1/berichte/AP00-ist-analyse.md
T
marcus b5044f62a9 Umsetzung von M1
2026-04-20 10:11:19 +02:00

27 KiB
Raw Permalink Blame History

AP00 — Ist-Analyse Meilenstein M1

Bezug: M1 aus docs/specs/meilensteine.md v3, technischer Soll-Rahmen aus docs/specs/technik-und-architektur.md v5 Bearbeiter: Claude Code (claude-opus-4-7), Ist-Analyse auf Auftrag, keine Code-Änderungen Datum: 2026-04-20 Grundlage: HEAD auf main nach den Commits AP01–AP04 (letzter: cd6e522 docs: Review-Korrekturen aus Peer-Review anwenden) Status: Analyse abgeschlossen, reine Dokumentation

1. Zusammenfassung

Der aktuelle M1-Stand ist zu rund einem Drittel umgesetzt. Die Build-Infrastruktur (AP02), die hexagonale Paketstruktur (AP03) und die SLF4J-Logging-Fassade (AP04) sind fertig, mvn clean verify ist grün (147 Tests, 0 Fehler). Offen bleiben die fachlich tragenden Teile von M1: das Befundmodell mit Spec-/Diagnose-Trennung (AP05), das korrekte Exit-Code-Modell 0/1/2 (aktuell 4 Codes 0/1/2/3 mit vertauschter Semantik), der CLI-/Bootstrap-Zuschnitt (AP06), die Ausgabeartefakte (_v1/_v2-Suffixlogik, .txt/.log, AP07), der Minimalbericht bei Bedienfehlern (AP08), das Einfrieren der Altlogik (AP09) sowie der Architekturtest (AP10). Das Eingabeencoding ist aktuell hartkodiert UTF-8 statt ISO-8859-15, das Hauptartefakt-JAR referenziert eine noch nicht existierende bootstrap.Main-Klasse, und der Preview-DefaultStructureValidator (19 ASVREC/ASVFEH-Regeln) läuft im produktiven Lauf mit und erzeugt fachliche Befunde, die in M1 noch nicht vorgesehen sind.

2. Projektstruktur

2.1 Verzeichnisbaum (Wurzel)

asv-format-validator/
├── .editorconfig, .gitattributes, .gitignore
├── CLAUDE.md, README.md, Spec.docx
├── pom.xml
├── Apply-ReviewPatches.ps1
├── docs/
│   ├── arbeitspakete/m1/{APxx.md, berichte/, templates/}
│   └── specs/{fachliche-anforderungen.md, technik-und-architektur.md, meilensteine.md}
├── logs/                       # wurde vom Log4j2-File-Appender im Vorlauf angelegt
├── src/
│   ├── main/java/...
│   ├── main/resources/log4j2.xml
│   ├── test/java/...
│   └── test/resources/*.asv    # Parser-Testartefakte
└── target/                     # Maven Build-Output

2.2 Maven-Module

Ein einziges Modul: de.gecheckt:asv-format-validator:0.0.1-SNAPSHOT. Keine Submodule, keine Multi-Module-Struktur — wie vom Soll (M1) gefordert (evolutionär, kein Modulschnitt).

2.3 Java-Pakete (Ist-Stand)

de.gecheckt.asv
├── domain                              (package-info.java)
│   └── model
│       ├── Field               (record)
│       ├── Segment             (record)
│       ├── Message             (record)
│       └── InputFile           (record)
├── application                         (package-info.java)
│   ├── InputFileValidator                             (Interface)
│   ├── DefaultInputFileValidator                      (Orchestrator)
│   ├── model
│   │   ├── ValidationSeverity  (enum INFO/WARNING/ERROR)
│   │   ├── ValidationError     (record, 9 Felder)
│   │   └── ValidationResult    (final class)
│   ├── field
│   │   ├── FieldValidator                             (Interface)
│   │   └── DefaultFieldValidator                      (Preview-Fachlogik)
│   └── structure
│       ├── StructureValidator                         (Interface)
│       └── DefaultStructureValidator                  (Preview, 19 ASVREC/ASVFEH-Regeln)
├── adapter
│   ├── in
│   │   └── cli                         (package-info.java)
│   │       └── AsvValidatorApplication (main, run, parseFile, printUsage)
│   └── out
│       ├── filesystem                  (package-info.java – leer, AP07-Vorbehalt)
│       ├── parsing                     (package-info.java)
│       │   ├── InputFileParser                        (Interface)
│       │   ├── DefaultInputFileParser                 (ein Message pro Datei)
│       │   ├── SegmentLineTokenizer                   (Interface)
│       │   ├── DefaultSegmentLineTokenizer            (hartes '+')
│       │   └── InputFileParseException
│       ├── reporting                   (package-info.java)
│       │   └── ValidationResultPrinter                (Konsole)
│       └── logging                     (package-info.java)
│           └── LoggingConfigurator                    (Stub, AP07-Vorbehalt)
└── bootstrap                           (package-info.java – leer, AP06-Vorbehalt)

Noch nicht angelegt: adapter.out.crypto (planmäßig erst in M8).

2.4 Konfigurationsdateien

Datei Zweck Status
pom.xml Maven-Build, Dependencies, Plugins AP02-gehärtet (SLF4J, JaCoCo, PIT-Profil, Mockito-Agent, maven-jar-plugin mit Platzhalter-Main-Class)
src/main/resources/log4j2.xml Log4j2-Konfiguration (Console→STDERR, File→logs/asv-format-validator.log) AP04-gesetzt
.editorconfig Encoding UTF-8, LF, 4 Spaces AP02
.gitattributes LF-Policy AP02
.classpath, .project, .settings/ Eclipse-Projektfiles Repo-Altbestand, unverändert

2.5 Testklassen

21 Testklassen, 147 Tests gesamt (bestätigt durch mvn clean verify):

  • domain/model/* — 4 Testklassen, 38 Tests (Record-Konstruktoren, Null-Guards)
  • adapter/out/parsing/* — 2 Testklassen, 11 Tests
  • adapter/out/reporting/* — 1 Testklasse, 3 Tests
  • adapter/in/cli/* — 2 Testklassen, 6 Tests (AsvValidatorApplicationTest, …AdditionalTest)
  • application/* — 1 Testklasse, 5 Tests (Orchestrator)
  • application/field/* — 1 Testklasse, 9 Tests
  • application/model/* — 2 Testklassen, 5 Tests
  • application/structure/* — 8 Testklassen, 70 Tests (Preview-Regelabdeckung)

Eine Testklasse fällt auf: DefaultStructureValidatorTestAdditional enthält keine @Test-Methoden (seit AP01 dokumentiert, Aufräumen ist AP10 zugeordnet).

3. M1-Abnahmekriterien — Status je Punkt

Bewertung je Kriterium gegen den tatsächlichen Code (nicht gegen die bisherigen Berichte).

3.1 „Anwendung ist als JAR unter Windows mit Java 21 startbar"

🔶 TEILWEISE.

Der pom.xml konfiguriert zwar maven-jar-plugin mit <mainClass>de.gecheckt.asv.bootstrap.Main</mainClass> (pom.xml:126), doch diese Klasse existiert noch nicht (Paket bootstrap enthält ausschließlich package-info.java). Ein mvn clean package würde ein JAR mit ungültigem Manifest-Eintrag erzeugen; java -jar asv-format-validator.jar <datei> schlägt mit Error: Could not find or load main class de.gecheckt.asv.bootstrap.Main fehl. Der aktuelle tatsächliche Einstiegspunkt ist de.gecheckt.asv.adapter.in.cli.AsvValidatorApplication#main — der wird aber vom Manifest nicht referenziert. AP06 muss die bootstrap.Main-Klasse anlegen.

3.2 „Eingabedatei wird technisch entgegengenommen; falsches oder fehlendes Argument führt zu Exit-Code 2 mit Minimalbericht"

❌ FEHLT (semantisch falsch und ohne Minimalbericht).

Kritische Abweichungen (AsvValidatorApplication.java:36-39):

private static final int EXIT_CODE_SUCCESS = 0;
private static final int EXIT_CODE_INVALID_ARGUMENTS = 1;   // Soll: 2
private static final int EXIT_CODE_FILE_ERROR = 2;          // Soll: 2 (gleicher Wert, aber semantisch mit invalid args zu vereinen)
private static final int EXIT_CODE_VALIDATION_ERRORS = 3;   // Soll: 1

Konsequenzen gegen den Soll-Rahmen:

  • Fehlendes Argument → Exit 1 (sollte 2) — AsvValidatorApplication.java:97
  • Validierungsfehler → Exit 3 (sollte 1) — AsvValidatorApplication.java:113
  • Es existiert vier Exit-Codes statt der in Spec und technik-und-architektur.md vorgeschriebenen drei (0/1/2).
  • Ein Minimalbericht bei Bedienfehlern wird nicht erzeugt. Bei fehlenden Argumenten ruft printUsage() nur System.out.println(…) auf; bei nicht lesbarer Datei wird System.err.println("Fehler beim …") geschrieben. Beide Wege erzeugen weder Berichtdatei noch strukturierten Text.

3.3 „Bericht- und Log-Datei werden im Eingabeverzeichnis mit korrekter Suffix-Logik erzeugt (_v1, _v2, …)"

❌ FEHLT vollständig.

  • Keine Berichtdatei-Erzeugung im Code. ValidationResultPrinter#printToConsole schreibt ausschließlich auf System.out (ValidationResultPrinter.java:22).
  • Die Log-Datei wird statisch nach logs/asv-format-validator.log relativ zum Arbeitsverzeichnis geschrieben (log4j2.xml:7), nicht in das Verzeichnis der Eingabedatei.
  • Keine Suffix-Logik _v1/_v2/… vorhanden (Grep _v1 im Hauptcode: keine Treffer).
  • adapter.out.filesystem ist leer. LoggingConfigurator#configureLogFile(Path) ist ein Stub (// TODO: dynamische Log-Datei-Umleitung in AP07).

3.4 „Log4j2-Bindung ist außerhalb von Bootstrap und Logging-Adapter nicht sichtbar"

✅ ERFÜLLT.

Grep über src/: org.apache.logging.log4j erscheint in keinem einzigen Produktions- oder Testcode-Import (Grep org.apache.logging.log4j → keine Treffer). Die Log4j2-Abhängigkeit wird ausschließlich per Runtime-Binding (log4j-slf4j2-impl, Scope runtime) gebunden. LoggingConfigurator liegt korrekt im erlaubten Paket, importiert aktuell aber noch keine Log4j2-Typen (Stub-Zustand). Das in AP10 vorgesehene Architekturgate kann diese Regel formal sichern.

3.5 „Befundmodell trennt Spec-Urteil und Diagnose strukturell"

❌ FEHLT vollständig.

Der bestehende ValidationError-Record (ValidationError.java:20) hat neun Felder (errorCode, description, severity, segmentName, segmentPosition, fieldName, fieldPosition, actualValue, expectedRule). Keines davon trägt die Unterscheidung zwischen verbindlichem Spec-Urteil und zusätzlicher diagnostischer Weiteranalyse — beides wandert undifferenziert in eine gemeinsame List<ValidationError> in ValidationResult. Zentrale Soll-Metadaten (Artefaktschicht, Prüfstufe, Prüfbereich, Rohwert, Position, Nachrichtenbezug, optionaler offizieller Fehlercode) fehlen ebenfalls. Das ist AP05-Scope.

3.6 „Build und Tests sind grün"

✅ ERFÜLLT.

mvn clean verify → BUILD SUCCESS, Tests run: 147, Failures: 0, Errors: 0, Skipped: 0 (lokal reproduziert am 2026-04-20). JaCoCo-Report wird erzeugt, keine Schwellwerte (kommt erst M9). Warnungen: nur die bekannte HotSpot-Sharing-Warnung aus AP02 (kosmetisch). Bei den CLI-Tests wird eine erwartete ERROR-Zeile „Fehler beim Lesen der Datei: File does not exist: /non/existent/file.txt" ausgegeben — Test-Nebeneffekt, nicht fehlerhaft.

3.7 Ergebnis-Tabelle

Abnahmekriterium Status
JAR unter Windows mit Java 21 startbar 🔶
Eingabedatei/Exit-Code 2/Minimalbericht ❌
Bericht/Log im Eingabeverzeichnis mit Suffix-Logik ❌
Log4j2-Bindung gekapselt ✅
Befundmodell Spec-/Diagnose-Trennung ❌
Build und Tests grün ✅

Zwei von sechs erfüllt, einer teilweise, drei fehlend.

4. Soll-Ist-Vergleich Paketstruktur

Soll-Paket Ist-Stand Bewertung
domain Unterpaket domain.model mit 4 Records (Field, Segment, Message, InputFile); package-info.java auf domain-Ebene vorhanden vorhanden, aber flach — noch kein Befundmodell, noch keine fachliche Schichtung
application Orchestrator DefaultInputFileValidator + application.model.* + application.field.* + application.structure.* vorhanden, mischt Orchestrierung und Preview-Fachregeln — AP09 muss entscheiden, wie die Preview-Teile markiert/abgetrennt werden
adapter.in.cli AsvValidatorApplication (main + run + parseFile + printUsage) vorhanden, aber überladen — enthält Bootstrap-Wiring, Dateisystemzugriff, CLI-Parsing und Fehlerbehandlung in einer Klasse
adapter.out.filesystem leer (nur package-info.java) angelegt, unbefüllt — AP07-Vorbehalt
adapter.out.parsing 5 Klassen (Parser/Tokenizer + Exception) vorhanden — Preview-Parser mit hartem + als Separator
adapter.out.crypto nicht angelegt fehlt planmäßig — ist M8-Scope, in M1 nicht gefordert
adapter.out.reporting ValidationResultPrinter vorhanden — nur Konsolenformat, kein Dateioutput
adapter.out.logging LoggingConfigurator (Stub) angelegt, unbefüllt — dynamische Log-Datei-Umleitung ist AP07
bootstrap leer (nur package-info.java) angelegt, unbefüllt — Main ist AP06-Scope

Fazit: Die Paketstruktur ist aus AP03 heraus formal vollständig. Die Inhalte sind asymmetrisch — das Parser-, Validator- und Modellpaket ist „voll" (z.T. mit Preview-Code), das Bootstrap- und das Filesystem-Paket sind leer.

5. Architekturprinzipien — Befunde

5.1 Keine Log4j2-Typen außerhalb adapter.out.logging/bootstrap

✅ eingehalten. Grep org.apache.logging.log4j über src/ liefert keine Treffer. Nach AP04 ist die einzig erlaubte Anlaufstelle LoggingConfigurator (der aktuell selbst keine Log4j2-Typen importiert, da er nur Stub ist).

5.2 Keine Infrastrukturabhängigkeiten in domain oder application

⚠️ größtenteils eingehalten, mit einem Rest-Risiko.

  • domain.* importiert nur java.util.* und java.util.Optional — sauber.
  • application.* importiert keine CLI-, Filesystem-, Logging- oder Parser-Typen. Grep bestätigt: kein java.nio.file, kein System.out/err, kein org.slf4j in application/.
  • Rest-Risiko: Die Klassen application.structure.DefaultStructureValidator (19 Regeln, u.a. zu UNH/UNT, ASVREC/ASVFEH, Rechnungskennzeichen, FHL) und application.field.DefaultFieldValidator enthalten bereits fachliche ASV-Regelkenntnis. Formal gehören solche Regeln ins Domänen- bzw. Regelpaket, nicht in die „Application"-Orchestrierungsschicht. Da AP09 vorsieht, diese Altlogik explizit als Vorbau einzufrieren und erst in M3+ wieder aufzunehmen, ist das derzeit akzeptierte Schulden — aber es verletzt den Soll-Zuschnitt leise (Fachregeln in application/* statt in einer eigenständigen Regelschicht).

5.3 Manuelle Constructor Injection, kein DI-Framework

✅ eingehalten. AsvValidatorApplication besitzt einen Default-Konstruktor, der alle Komponenten manuell per new verdrahtet (AsvValidatorApplication.java:50-60), und einen Test-Konstruktor mit Constructor Injection (AsvValidatorApplication.java:70). DefaultInputFileValidator nimmt StructureValidator und FieldValidator per Constructor entgegen (DefaultInputFileValidator.java:33). Kein Spring, kein Quarkus, kein CDI, kein Guice in den Dependencies.

Anmerkung: Die Wiring-Logik liegt derzeit im CLI-Adapter selbst; der Soll-Zuschnitt will sie in bootstrap sehen (AP06).

5.4 Befundmodell unterscheidet Spec-Urteil und Diagnose

❌ nicht eingehalten. Siehe 3.5. Das aktuelle ValidationResult kennt nur ERROR/WARNING/INFO, keine Dimension „spec-verbindlich vs. diagnostisch".

5.5 Exit-Codes 0/1/2 korrekt verdrahtet

❌ nicht eingehalten. Siehe 3.2. Ist-Stand ist 0/1/2/3 mit teilweise invertierter Semantik. Konkrete Stellen: AsvValidatorApplication.java:36-39 (Konstanten), :97 (falscher Code bei fehlendem Argument), :113 (falscher Code bei Validierungsfehler).

5.6 Weitere prinzipielle Befunde

  • Eingabe-Encoding ISO-8859-15 (technik-und-architektur.md §„Zeichensätze"): Das Ist liest mit StandardCharsets.UTF_8 (AsvValidatorApplication.java:152). java.nio.charset.StandardCharsets bietet kein ISO-8859-15, man muss Charset.forName("ISO-8859-15") nutzen. Aktuelle Fehlkodierung verfälscht alle Umlaute (ä=0xE4 statt UTF-8-Doppelbyte) und jeden Euro-Sonderfall (€).
  • Schreiben statt Speichern der Bericht-/Log-Datei: Die Bericht- und Log-Dateien müssten laut Soll in UTF-8 in das Verzeichnis der Eingabedatei geschrieben werden. Keine dieser Anforderungen ist umgesetzt.
  • EDIFACT-Konformität des Tokenizers: DefaultSegmentLineTokenizer trennt starr an + (Zeile 13). Das UNA-Segment und die Gruppenelementtrennung : werden nicht ausgewertet. Nicht M1-Scope (gehört zu M3), aber Rest-Risiko bei Tests und als Vorbau.
  • Parser-Vereinfachung: DefaultInputFileParser erzeugt pro Datei genau eine Message (Zeile 54), unabhängig von UNH/UNT-Gruppen. Preview-Verhalten.

6. Qualitätsstatus (Build/Test)

Hinweis zu den widersprüchlichen Vorgaben des Auftrags: Die Einleitung spricht von „machst kein mvn", Abschnitt 5 fordert jedoch explizit mvn clean verify, der abschließende Teil präzisiert auf „kein mvn package". Der Autor dieses Berichts interpretiert den spezifischen Auftrag in Abschnitt 5 als maßgeblich; mvn clean verify wurde einmalig ausgeführt. Kein mvn package, kein git, kein Schreiben außerhalb dieses Berichts.

  • mvn clean verify: ✅ BUILD SUCCESS (lokal, 2026-04-20).
  • Tests: 147 gesamt, 0 Failures, 0 Errors, 0 Skipped. Alle Testklassen der hexagonalen Struktur laufen durch.
  • Compile-/Javac-Warnungen: keine über die aus AP02 bekannten hinaus.
  • JVM-Warnungen zur Laufzeit:
    • Java HotSpot(TM) 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended — kosmetisch, stammt vom JaCoCo-Agent, bekannt seit AP02.
    • Eine erwartete ERROR-Log-Zeile aus dem CLI-Test (nicht-existente Datei) ist sichtbar, wird aber nicht als Testfehler gewertet. Sie wäre zum M1-Ende über ein Logback-Test-Filter oder eine angepasste Test-Log-Konfiguration in AP10 unterdrückbar — kein Blocker.
  • Mutation Testing: In AP02 einmalig ausgeführt (249 Mutationen, 83 % getötet), Schwellwerte kommen erst M9.
  • Coverage: JaCoCo-Report unter target/site/jacoco/; keine Schwellwerte aktiv.

7. Preview-Code / Altlogik

7.1 Identifikation

Als Preview-Code der Sondierungsphase (README, Abschnitt „Preview-Code"; AP01 Klassifikation) gelten:

Klasse Paket M1-Bewertung Verdrahtung im Lauf
DefaultInputFileParser adapter.out.parsing Behalten, für M3 überarbeiten (Trennzeichen, Multi-Message) aktiv in AsvValidatorApplication
DefaultSegmentLineTokenizer adapter.out.parsing Behalten, für M3 überarbeiten (UNA) aktiv
InputFileParser/SegmentLineTokenizer/InputFileParseException adapter.out.parsing Behalten als stabile Ports aktiv
DefaultFieldValidator application.field einzufrieren (AP09) — keine M1-Weiterentwicklung aktiv über DefaultInputFileValidator
DefaultStructureValidator (19 ASVREC/ASVFEH-Regeln) application.structure einzufrieren (AP09) — 19 fachliche Regeln, M3+-Vorbau aktiv über DefaultInputFileValidator
ValidationError, ValidationResult, ValidationSeverity application.model umzubauen/abzulösen durch Befundmodell mit Spec-/Diagnose-Trennung (AP05) aktiv als einzige Befundträger
ValidationResultPrinter adapter.out.reporting Behalten als Konsolen-Formatierer aktiv

7.2 Aktiv oder eingefroren?

Alle Preview-Klassen sind aktiv in den Lauf verdrahtet: Der Default-Konstruktor von AsvValidatorApplication baut parser + validator + printer komplett mit der Preview-Logik zusammen (AsvValidatorApplication.java:52-59). Der produktive Lauf führt deshalb heute schon fachliche ASVREC-/ASVFEH-Prüfungen aus — nominell M3+-Scope, real vorhandenes Verhalten. Ein formales „Einfrieren" (Kommentar-Marker, Paketumzug oder gezielte Deaktivierung) ist bis zum AP09 noch nicht erfolgt.

7.3 Risiken des Preview-Codes für M1

  1. Fachliche Befunde in M1: Solange DefaultStructureValidator aktiv bleibt, liefert ein M1-Lauf bereits ASVREC-/ASVFEH-Befunde. Das widerspricht der M1-Vorgabe „noch keine ASV-Fachvalidierung" (meilensteine.md §M1 Ziel, und AP-README „Keine Fachvalidierung in M1").
  2. Exit-Code-Verwechslung: Weil Fachbefunde schon produziert werden, schlagen sie über hasErrors() auf den (falschen) Exit-Code 3 durch. Ein M1-Lauf einer beliebigen Textdatei liefert deshalb heute realistisch 3, nicht das geplante 0 (gültig mangels Regeln) oder das korrekte 1 (ungültig).
  3. Hartkodiertes + als Trennzeichen: Jede Datei ohne ASV-typische EDIFACT-Struktur wird stumm „erfolgreich" geparst. Für M1-Akzeptanz mit einer Minimaldatei akzeptabel; für alles Reale gefährlich.
  4. UTF-8-Lesen: Alle Preview-Tests laufen auf UTF-8-kodierten *.asv-Testressourcen. Beim Umstellen auf ISO-8859-15 werden vorhandene Testdaten zum Risiko — Umstellung muss zusammen mit Testressourcen-Anpassung erfolgen.
  5. DefaultStructureValidatorTestAdditional leer: Eine Testklasse ohne @Test-Methoden bleibt seit AP01 bestehen und ist ein Restposten für AP10.
  6. Preview-Regeln als „V1-N"-Kandidaten: Einige der 19 Regeln (z.B. strikte Reihenfolgeerzwingung der ASVREC-Segmente, FHL-Pflicht für ASVFEH) greifen zu rigide, wenn sie gegen die finalen Soll-Regelklassifikationen (V1-V/T/N/K) gestellt werden. Beim Wiederaufnehmen ab M3 ist jede Preview-Regel neu zu bewerten — das ist kein M1-Problem, aber ein M3-Erbe.

8. Offene Punkte und Risiken

8.1 Architekturrisiken

  • R-ARCH-01 — Exit-Code-Semantik falsch und erweitert. Der Ist-Code hat vier Codes mit vertauschter Bedeutung. Muss in AP06 korrigiert werden, damit AP11 abnehmbar ist. Bis dahin ist ein M1-Lauf nicht spec-konform.
  • R-ARCH-02 — Eingabe-Encoding hartkodiert UTF-8. Widerspricht direkt dem Soll-Rahmen. StandardCharsets kennt kein ISO-8859-15; Charset.forName("ISO-8859-15") muss genutzt werden, JDK-Verfügbarkeit ist zu verifizieren. Umstellung ist in AP06 oder spätestens in AP07 zu verankern.
  • R-ARCH-03 — Keine Spec-/Diagnose-Trennung im Befundmodell. Das aktuelle ValidationError/ValidationResult reicht für die Fortführung ab M2 nicht aus. Es muss in AP05 komplett neu geschnitten (oder stark erweitert) werden, inklusive aller Metadatenfelder aus technik-und-architektur.md § „Befundarten". Weil der Preview-DefaultStructureValidator dieses Modell produktiv befüllt, wird der Umbau nicht kostenlos — AP09 muss die Altlogik zuvor entkoppeln.
  • R-ARCH-04 — Ausgabeartefakte fehlen komplett. Weder Berichtdatei noch Logdatei werden im Eingabeverzeichnis erzeugt; die Suffix-Logik existiert nicht. Das ist der größte Einzel-Arbeitsblock in M1 (AP07).
  • R-ARCH-05 — Preview-Code läuft produktiv mit und erzeugt Fachbefunde. Siehe 7.3. AP09 muss klären: entkoppeln, per Default deaktivieren oder nur inert im Classpath behalten.

8.2 Implementierungslücken (aus M1 noch offen)

  • L-AP05 — Befundmodell mit Spec-/Diagnose-Trennung.
  • L-AP06 — bootstrap.Main-Klasse, sauberes CLI-Wiring, Exit-Codes 0/1/2, ISO-8859-15.
  • L-AP07 — adapter.out.filesystem mit Dateioutput; LoggingConfigurator mit dynamischer Log-Datei-Umleitung; Suffix-Logik _v1/_v2/….
  • L-AP08 — Minimalbericht bei Bedienfehlern (Exit-Code 2).
  • L-AP09 — Altlogik einfrieren (oder deaktivieren), damit M1-Läufe keine unerwarteten Fachbefunde mehr erzeugen.
  • L-AP10 — Architekturtest (Paketabhängigkeiten, Log4j2-Sichtbarkeit, idealerweise auch Exit-Code-Semantik und Preview-Deaktivierung).
  • L-AP11 — End-to-End-Abnahme mit Minimaldatei; Berichtskonsolidierung.

8.3 Unklarheiten / Entscheidungsbedarf

  • E-01: Wie wird der Preview-DefaultStructureValidator in AP09 konkret eingefroren? Drei Optionen: (a) in ein Sub-Paket application.preview.structure verschieben und den Orchestrator gegen eine Null-Implementation austauschen; (b) in Ort belassen, den Orchestrator im Bootstrap aber nicht mehr damit verdrahten; (c) weiterlaufen lassen, aber dessen Befunde im neuen Befundmodell als „Diagnose" klassifizieren. Jede Option hat andere Auswirkungen auf AP05 und AP10.
  • E-02: Wie wird der Test-Log-Rauschen (ERROR-Zeile im Negativ-Test) eliminiert? Eigene Test-Log-Konfiguration oder bewusst stehen lassen? AP10 sollte hier eine Entscheidung zusichern.
  • E-03: Was passiert mit DefaultStructureValidatorTestAdditional? Stummes Artefakt seit AP01 — in AP10 entfernen oder mit Tests füllen?
  • E-04: Soll der aktuelle Inhalt logs/asv-format-validator.log (Arbeitsverzeichnis) nach AP07 noch eine Rolle spielen? Wenn die Logdatei künftig neben die Eingabedatei geschrieben wird, wird der aus AP04 konfigurierte statische Pfad überflüssig. Der logs/-Ordner im Repo-Root ist Resultat früherer Läufe und gehört vermutlich .gitignore'd.
  • E-05: JAR-Aufbau als „fat jar" oder als JAR mit Classpath? maven-jar-plugin alleine erzeugt kein Uber-JAR — java -jar asv-format-validator.jar würde ohne maven-shade-plugin oder Class-Path-Manifest ohne Log4j2/SLF4J starten. AP06 muss dies entscheiden (die AP-Texte nennen nur maven-jar-plugin).

9. Empfehlung: nächste sinnvolle Arbeitspakete für M1

Reihenfolge auf Basis der Abhängigkeiten in docs/arbeitspakete/m1/README.md und der oben sichtbaren Risiken:

  1. AP05 — Befundmodell mit Spec-/Diagnose-Trennung. Höchste Hebelwirkung: freigeschaltet sind danach AP06 (Exit-Codes bauen auf dem neuen Urteil auf), AP07 (Bericht rendert das neue Modell) und AP09 (Preview-Befunde lassen sich als Diagnose klassifizieren). Unmittelbar angreifbar, keine vorangehenden APs mehr offen.
  2. AP06 — Bootstrap und CLI. Exit-Codes 0/1/2 korrigieren, bootstrap.Main anlegen, Wiring aus AsvValidatorApplication herauslösen, ISO-8859-15 einziehen. Nur mit AP05-Modell sinnvoll, weil hasErrors() des neuen Befundmodells den Urteils-Exit-Code speist.
  3. AP09 — Altlogik einfrieren. Direkt nach AP06 sinnvoll, weil ab dann der Bootstrap sauber entscheiden kann, ob und wie die Preview-Validatoren verdrahtet werden. Ohne AP09 bringt AP05 keinen realen Effekt — DefaultStructureValidator produziert weiter Fachbefunde.
  4. AP07 — Ausgabeartefakte. Nach AP06 sinnvoll, weil dann eine stabile Ausgangs-CLI vorliegt, in die die Dateilogik eingezogen werden kann. LoggingConfigurator wird hier Leben bekommen.
  5. AP08 — Minimalbericht. Reine Veredelung der Bedienfehler-Pfade auf Basis von AP07.
  6. AP10 — Architekturtest. Sobald AP04–AP09 stehen, kann ein ArchUnit-Scan die Log4j2-Sichtbarkeit, die Paketabhängigkeiten, die Exit-Codes (als Konstanten) und die Preview-Deaktivierung formell prüfen.
  7. AP11 — M1-Abnahme. Abschlusslauf mit Minimaldatei, Konsolidierung aller Berichte.

Wichtig: Jedes dieser APs bleibt ein eigener Claude-Lauf. Diese Ist-Analyse hier bündelt nur die Ausgangslage; sie darf in späteren APs zitiert, aber nicht als implizite Entscheidung missverstanden werden — insbesondere die Optionen zu E-01 bis E-05 sind weiterhin offen.

View Git Blame Copy Permalink