12 KiB
Abschlussbericht Arbeitspaket AP09 – Altlogik einfrieren (Preview-Code deaktivieren)
Bezug:
docs/arbeitspakete/m1/AP09-altlogik-einfrieren.mdBearbeiter: 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; implementiertStructureValidator, gibt stets leeresValidationResultzurück; JavaDoc auf Deutsch; null-Guard vorhanden.src/main/java/de/gecheckt/asv/bootstrap/NoOpFieldValidator.java— M1-Platzhalter; implementiertFieldValidator, gibt stets leeresValidationResultzurü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.java—Mainverdrahtet bereits seit AP06 ausschließlichDummyFileValidationService; 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 1–19 in DefaultStructureValidator.java |
Einfriermarker-JavaDoc in DefaultFieldValidator |
✅ | JavaDoc-Block Zeile 1–19 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
-
DefaultStructureValidatorTestAdditionalenthä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
DefaultStructureValidatorneu gegen V1-V/T/N/K-Klassifikation zu bewerten. Dies ist kein Risiko von AP09, aber ein kritisches M3-Erbe. -
DefaultInputFileValidatorwird in M1 nicht im aktiven Lauf verwendet:Main.javaverdrahtetDummyFileValidationServicedirekt;DefaultInputFileValidatorist zwar funktional vorhanden und vollständig getestet, aber nicht in den Aufrufpfad eingebunden. In M3 mussMain.javaauf einen echtenFileValidationServicemitDefaultInputFileValidatorund den reaktivierten Preview-Validatoren umgestellt werden. -
ValidationResultundValidationSeverity(Altmodell) koexistieren weiterhin: Die Preview-Klassen und ihre Tests nutzen das Altmodellapplication.model.*(nichtdomain.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
adapterundbootstrapkeine direkte Abhängigkeit aufapplication.structure.DefaultStructureValidatoroderapplication.field.DefaultFieldValidatorhaben. Dies wäre ein starkes formales Gate gegen versehentliche Reaktivierung. - AP11 (M1-Abnahme): Der M1-Lauf erzeugt keine Fachbefunde mehr.
DummyFileValidationServiceliefert stets einen leerenValidationReport. 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 imbootstrap-Paket durch die echten Implementierungen ersetzen undDefaultInputFileValidatorinMain.javaverdrahten.DefaultStructureValidatorTestAdditionalkann 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 verifyist 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