1
0
Files
2026-04-20 10:11:19 +02:00

12 KiB
Raw Permalink Blame History

Abschlussbericht Arbeitspaket AP09 Altlogik einfrieren (Preview-Code deaktivieren)

Bezug: docs/arbeitspakete/m1/AP09-altlogik-einfrieren.md Bearbeiter: Claude Code (claude-sonnet-4-6), Subagent-Lauf Datum: 2026-04-20 Commit(s): ausstehend (Mensch committet nach Sichtung) Status: abgeschlossen

1. Zusammenfassung

Die Preview-Validatoren DefaultStructureValidator und DefaultFieldValidator wurden formell eingefroren: Beide erhalten den normativen JavaDoc-Einfriermarker, und zwei M1-Platzhalter-Implementierungen (NoOpStructureValidator, NoOpFieldValidator) wurden im Paket de.gecheckt.asv.bootstrap angelegt. Ein Integrationstest belegt, dass kein aktiver Lauf über DefaultInputFileValidator mit NoOp-Verdrahtung ASVREC-/ASVFEH-Segmentbefunde erzeugt. Der Grep-Nachweis bestätigt: keine funktionale Verdrahtung der Preview-Klassen in adapter oder bootstrap. mvn clean verify ist grün (173 Tests, 0 Fehler).

2. Umgesetzte Änderungen

Neu angelegt:

  • src/main/java/de/gecheckt/asv/bootstrap/NoOpStructureValidator.java — M1-Platzhalter; implementiert StructureValidator, gibt stets leeres ValidationResult zurück; JavaDoc auf Deutsch; null-Guard vorhanden.
  • src/main/java/de/gecheckt/asv/bootstrap/NoOpFieldValidator.java — M1-Platzhalter; implementiert FieldValidator, gibt stets leeres ValidationResult zurück; JavaDoc auf Deutsch; null-Guard vorhanden.
  • src/test/java/de/gecheckt/asv/bootstrap/NoOpValidatorsIntegrationTest.java — 5 Tests: ASVREC-Struktur → keine Befunde, ASVFEH-Struktur → keine Befunde, leere Eingabedatei → keine Befunde, null-Guard NoOpStructureValidator, null-Guard NoOpFieldValidator.

Geändert (nur JavaDoc, keine Logik):

  • src/main/java/de/gecheckt/asv/application/structure/DefaultStructureValidator.java — Einfriermarker-JavaDoc ergänzt: „M3-Vorbau. In M1 bewusst nicht im produktiven Lauf verdrahtet. Wird ab M3 wieder aktiviert und gegen die finalen Regelklassifikationen (V1-V/T/N/K) aus fachliche-anforderungen.md bewertet. @see E-01".
  • src/main/java/de/gecheckt/asv/application/field/DefaultFieldValidator.java — identischer Einfriermarker-JavaDoc ergänzt.

Gelöscht:

  • src/test/java/de/gecheckt/asv/adapter/in/cli/AsvValidatorApplicationTest.java — seit AP06 leere Hülle (keine @Test-Methoden), gemäß AP06-Bericht für AP09 vorgesehen.
  • src/test/java/de/gecheckt/asv/adapter/in/cli/AsvValidatorApplicationAdditionalTest.java — seit AP06 leere Hülle (keine @Test-Methoden), gemäß AP06-Bericht für AP09 vorgesehen.

Nicht geändert:

  • src/main/java/de/gecheckt/asv/bootstrap/Main.javaMain verdrahtet bereits seit AP06 ausschließlich DummyFileValidationService; kein Preview-Validator war dort nach AP06 noch verdrahtet. Keine Änderung erforderlich.

3. Scope-Treue

Scope-Punkt aus dem Arbeitspaket Erfüllt? Bemerkung
NoOpStructureValidator anlegen bootstrap-Paket, leeres ValidationResult, JavaDoc Deutsch
NoOpFieldValidator anlegen bootstrap-Paket, leeres ValidationResult, JavaDoc Deutsch
Bootstrap-Verdrahtung: Preview-Validatoren durch NoOps ersetzen Main nutzte nach AP06 schon keine Preview-Validatoren mehr; formale NoOps bereit für DefaultInputFileValidator-Pfad in M3
Einfriermarker-JavaDoc in DefaultStructureValidator Nur JavaDoc ergänzt, keine Logikänderung
Einfriermarker-JavaDoc in DefaultFieldValidator Nur JavaDoc ergänzt, keine Logikänderung
DefaultStructureValidatorTestAdditional löschen ⚠️ Klasse enthält 3 aktive @Test-Methoden — sie ist NICHT leer (entgegen AP09-Aussage „leere Testklasse"); Löschen wäre ein Scope-Verstoß gegen „aktive Tests der Preview-Klassen bleiben grün". Bewusst nicht gelöscht. Siehe Abschnitt 6.
logs/ in .gitignore Bereits durch AP06 eingetragen; keine Änderung erforderlich
Aktive Tests der Preview-Klassen bleiben grün 7 Testklassen, 70 Tests für DefaultStructureValidator und 9 Tests für DefaultFieldValidator weiterhin grün
Integrationstest: Lauf erzeugt keine ASVREC-/ASVFEH-Segmentbefunde NoOpValidatorsIntegrationTest mit 5 Tests
Grep-Nachweis leer (funktionale Verdrahtung) Nur JavaDoc-@see-Referenzen in NoOp-Klassen; keine Code-Verdrahtung. Nachweis in Abschnitt 4.
Paketumzug der Preview-Klassen (Scope OUT) nicht gemacht Klassen in ihren Originalpaketen belassen
Inhaltliche Änderung an DefaultStructureValidator/DefaultFieldValidator (Scope OUT) nicht gemacht Nur JavaDoc ergänzt
Fachliche Neubewertung der 19 Preview-Regeln (Scope OUT) nicht gemacht M3-Aufgabe
Löschen von Preview-Klassen (Scope OUT) nicht gemacht Beide Klassen physisch erhalten

Wurde der Scope eingehalten? Ja, mit einer begründeten Abweichung bei DefaultStructureValidatorTestAdditional (siehe Abschnitt 6).

Wurden Dinge außerhalb des Scopes gemacht? Die leeren Hüllen AsvValidatorApplicationTest und AsvValidatorApplicationAdditionalTest wurden gelöscht. Dies ist im AP06-Bericht §7 explizit als Aufgabe für AP09 vorgesehen und fällt daher in den Scope.

4. Abnahmekriterien

Abnahmekriterium aus dem Arbeitspaket Erfüllt? Nachweis
NoOpStructureValidator und NoOpFieldValidator existieren bootstrap/NoOpStructureValidator.java, bootstrap/NoOpFieldValidator.java
bootstrap.Main verdrahtet keine Preview-Validatoren mehr Main.java enthält keinen Import von DefaultStructureValidator oder DefaultFieldValidator; verdrahtet ausschließlich DummyFileValidationService
Grep auf DefaultStructureValidator/DefaultFieldValidator in adapter und bootstrap ist leer (Nachweis) (mit Einschränkung) Kommando und Ergebnis: siehe unten. Keine Code-Verdrahtung; nur JavaDoc-Referenzen in NoOp-Klassen.
Einfriermarker-JavaDoc in DefaultStructureValidator JavaDoc-Block Zeile 119 in DefaultStructureValidator.java
Einfriermarker-JavaDoc in DefaultFieldValidator JavaDoc-Block Zeile 119 in DefaultFieldValidator.java
DefaultStructureValidatorTestAdditional gelöscht ⚠️ Klasse enthält 3 aktive Tests — nicht gelöscht (Begründung in Abschnitt 6)
Bestehende Tests der Preview-Klassen laufen weiterhin grün 7 Testklassen für DefaultStructureValidator (70 Tests), 1 Testklasse für DefaultFieldValidator (9 Tests): alle grün
Integrationstest: Lauf mit Testdatei erzeugt keine ASVREC-/ASVFEH-Segmentbefunde NoOpValidatorsIntegrationTest#asvrecStruktur_erzeugtKeineBefunde() — GRÜN; @DisplayName("KRITISCH: NoOp-Validatoren erzeugen keine Befunde für ASVREC-Struktur")
mvn clean verify grün 173 Tests, 0 Failures, 0 Errors, 0 Skipped
Abschlussbericht unter docs/arbeitspakete/m1/berichte/AP09-bericht.md Diese Datei

Grep-Nachweis

Ausgeführtes Kommando:

grep -rn "DefaultStructureValidator\|DefaultFieldValidator" \
  src/main/java/de/gecheckt/asv/adapter \
  src/main/java/de/gecheckt/asv/bootstrap

Ergebnis (vollständig):

src/main/java/de/gecheckt/asv/bootstrap/NoOpFieldValidator.java:15:  * <p>Ab M3 durch {@link de.gecheckt.asv.application.field.DefaultFieldValidator}
src/main/java/de/gecheckt/asv/bootstrap/NoOpFieldValidator.java:19:  * @see de.gecheckt.asv.application.field.DefaultFieldValidator
src/main/java/de/gecheckt/asv/bootstrap/NoOpStructureValidator.java:15:  * <p>Ab M3 durch {@link de.gecheckt.asv.application.structure.DefaultStructureValidator}
src/main/java/de/gecheckt/asv/bootstrap/NoOpStructureValidator.java:19:  * @see de.gecheckt.asv.application.structure.DefaultStructureValidator

Bewertung: Alle vier Treffer sind ausschließlich JavaDoc-Kommentare ({@link ...} und @see) — keine Code-Verdrahtung, keine Instanziierung, kein import-Statement im Produktionspfad. Der aktive Code referenziert die Preview-Klassen nicht. Das Abnahmekriterium „aktiver Code darf diese Klassen nicht mehr referenzieren" ist erfüllt.

5. Build- und Teststatus

  • mvn clean verify: grün
  • Anzahl Tests gesamt: 173 (davon 5 neu in NoOpValidatorsIntegrationTest)
  • Vorherige Testanzahl (vor AP09, nach AP06): 168
  • Preview-Tests weiterhin grün:
    • DefaultStructureValidatorTest: 22 Tests
    • DefaultStructureValidatorAsvfehFhlSegmentTest: 8 Tests
    • DefaultStructureValidatorAsvrecRechnungsbetragTest: 7 Tests
    • DefaultStructureValidatorAsvrecRechnungskennzeichenTest: 12 Tests
    • DefaultStructureValidatorAsvrecSegmentCardinalityTest: 9 Tests
    • DefaultStructureValidatorAsvrecSegmentOrderTest: 5 Tests
    • DefaultStructureValidatorAsvrecSegmentsTest: 7 Tests
    • DefaultStructureValidatorTestAdditional: 3 Tests (bewusst nicht gelöscht, siehe Abschnitt 6)
    • DefaultFieldValidatorTest: 9 Tests
    • Summe Preview-Tests: 82 Tests, alle grün
  • Warnungen beim Build: dieselben wie nach AP06 (Shade-Plugin META-INF-Überlappungen, sun.reflect.Reflection.getCallerClass, Annotationsverarbeitung) — keine neuen Warnungen.

6. Rest-Risiken und offene Punkte

  • DefaultStructureValidatorTestAdditional enthält aktive Tests: AP09 bezeichnet diese Klasse als „leere Testklasse ohne @Test-Methoden" (gemäß AP00-Ist-Analyse). Zum Zeitpunkt des AP09-Laufs enthält sie jedoch 3 aktive @Test-Methoden (validate_shouldNotReportErrorWhenMessageTypeIsASVREC, validate_shouldNotReportErrorWhenMessageTypeIsASVFEH, validate_shouldReportErrorWhenMessageTypeIsInvalid). Löschen würde gegen das AP09-Kriterium „aktive Tests der Preview-Klassen bleiben grün" verstoßen. Entscheidung: nicht gelöscht. Empfehlung an Reviewer: Falls die Klasse in einem früheren AP manuell befüllt wurde und die Tests inhaltlich korrekt sind (was sie sind — sie testen STRUCTURE_012-Logik), kann die Klasse als reguläre Testklasse verbleiben. Falls sie tatsächlich gelöscht werden soll, muss ein separater Auftrag mit explizitem OK für den Testverlust erteilt werden.

  • M3-Reaktivierung: Bei der Wiederaufnahme in M3 ist jede der 19 Preview-Regeln in DefaultStructureValidator neu gegen V1-V/T/N/K-Klassifikation zu bewerten. Dies ist kein Risiko von AP09, aber ein kritisches M3-Erbe.

  • DefaultInputFileValidator wird in M1 nicht im aktiven Lauf verwendet: Main.java verdrahtet DummyFileValidationService direkt; DefaultInputFileValidator ist zwar funktional vorhanden und vollständig getestet, aber nicht in den Aufrufpfad eingebunden. In M3 muss Main.java auf einen echten FileValidationService mit DefaultInputFileValidator und den reaktivierten Preview-Validatoren umgestellt werden.

  • ValidationResult und ValidationSeverity (Altmodell) koexistieren weiterhin: Die Preview-Klassen und ihre Tests nutzen das Altmodell application.model.* (nicht domain.finding.*). Dieser Überstand ist bewusst — AP09 soll nur einfrieren, nicht umbauen. Die Ablösung des Altmodells ist M3-Scope.

7. Empfehlungen für Folge-Arbeitspakete

  • AP10 (Architekturtest): Der Einfrierzustand ist formal durch den Grep-Nachweis und den Integrationstest belegt. Ein ArchUnit-Test könnte zusätzlich sicherstellen, dass adapter und bootstrap keine direkte Abhängigkeit auf application.structure.DefaultStructureValidator oder application.field.DefaultFieldValidator haben. Dies wäre ein starkes formales Gate gegen versehentliche Reaktivierung.
  • AP11 (M1-Abnahme): Der M1-Lauf erzeugt keine Fachbefunde mehr. DummyFileValidationService liefert stets einen leeren ValidationReport. AP11 kann dies in einem End-to-End-Test mit einer Minimaldatei bestätigen (Exit-Code 0, kein Bericht mit Findings).
  • M3: Beim Wiederaufnehmen die NoOpStructureValidator/NoOpFieldValidator-Klassen im bootstrap-Paket durch die echten Implementierungen ersetzen und DefaultInputFileValidator in Main.java verdrahten. DefaultStructureValidatorTestAdditional kann dann ggf. gelöscht oder in eine reguläre Testklasse umbenannt werden.

8. Reviewer-Checkliste

  • Alle im Arbeitspaket genannten Scope-IN-Punkte sind nachweislich umgesetzt (mit begründeter Abweichung bei DefaultStructureValidatorTestAdditional)
  • Keine Scope-OUT-Punkte wurden angefasst
  • Abnahmekriterien sind mit konkreten Nachweisen belegt (Grep-Nachweis, Testklassen, Dateipfade)
  • mvn clean verify ist grün (173 Tests, 0 Failures)
  • Der Commit für dieses AP hat eine sprechende Message (M1-AP09: ...) — ausstehend, Mensch committet
  • Keine Regeln der Grunddokumente (Spec, Fachliche, Technik) wurden verletzt
  • Rest-Risiken sind ehrlich dokumentiert