Umsetzung von M1

docs/arbeitspakete/m1/AP09-altlogik-einfrieren.md

@@ -1,86 +1,121 @@
-# AP09 – Altlogik aus M1 entkoppeln (Parser/Validator einfrieren)
+---
+model: sonnet
+---
+# AP09 – Altlogik einfrieren (Preview-Code deaktivieren)
+
+> **Meilenstein:** M1
+> **Vorgänger:** AP03, AP05, AP06 ✅ erforderlich
+> **Nachfolger:** AP10, AP11
+> **Grundlage:** AP00-ist-analyse.md §§ 7, 8
+> **Entscheidungsprotokoll:** `docs/arbeitspakete/m1/E00-entscheidungsprotokoll.md` (E-01 Option b, E-03 leere Testklasse)
 
 ## Ziel
 
-Die **bereits vorhandene Parser- und Validator-Logik** aus der früheren Implementierung (vor dieser M1-Planung) wird **nicht gelöscht**, aber sauber **entkoppelt** vom aktiven M1-Lauf. Sie wird als „Vorbau für M3 und folgende" explizit markiert und ist während M1 **nicht** Bestandteil der aktiven Verarbeitungskette.
+Die bestehende Preview-Parser- und Validator-Logik (`DefaultStructureValidator`, `DefaultFieldValidator`, `DefaultInputFileValidator`) wird **nicht gelöscht und nicht verschoben**, sondern im Bootstrap **nicht mehr verdrahtet**. Ein M1-Lauf erzeugt keine fachlichen ASVREC-/ASVFEH-Befunde mehr. Die Klassen bleiben physisch an ihrem Ort als M3-Vorbau.
 
-Hintergrund: Der ursprüngliche Stand im Repository enthält bereits `DefaultInputFileParser`, `DefaultSegmentLineTokenizer`, `DefaultStructureValidator`, `DefaultFieldValidator`, `DefaultInputFileValidator` und `validation.model.ValidationResult`. Das ist wertvoll und darf nicht verloren gehen — gehört aber fachlich in M3 (Parser), M5 (Feldregeln) und M6 (Beziehungen), nicht in M1.
+## Hintergrund und Entscheidung
+
+Laut AP00-Ist-Analyse läuft `DefaultStructureValidator` (19 ASVREC/ASVFEH-Regeln) aktiv im produktiven Lauf mit — was dem M1-Ziel „noch keine ASV-Fachvalidierung" widerspricht.
+
+**Entscheidung E-01: Option (b)** — Klassen bleiben in ihren Paketen, werden aber im Bootstrap nicht mehr verdrahtet. Für M3 kann die Verdrahtung direkt wieder aktiviert werden.
+
+Kein Paketumzug, keine Umbenennung, kein `@Deprecated`.
 
 ## Voraussetzungen
 
-- AP03 (Migration), AP05 (neues Befundmodell), AP06 (neuer Bootstrap/CLI)
+- AP03 (Paketstruktur)
+- AP05 (neues Befundmodell)
+- AP06 (neuer Bootstrap/CLI)
 
 ## Scope IN
 
-### Einfrieren statt Löschen
-- Die bestehenden Klassen bleiben **vollständig erhalten**, inklusive Tests
-- Sie werden in ein klar erkennbares Unterpaket verschoben, z.B.:
-  ```
-  de.gecheckt.asv.legacy.parser
-  de.gecheckt.asv.legacy.validation
-  de.gecheckt.asv.legacy.model
-  ```
-  oder alternativ:
-  ```
-  de.gecheckt.asv.application.preview
-  ```
-  Die Entscheidung zwischen `legacy` und `preview` wird im Bericht dokumentiert und begründet. Empfehlung: **`preview`**, weil „legacy" suggeriert, dass etwas alt und zu entsorgen ist — tatsächlich wird der Code in M3/M5/M6 weiterverwendet.
-- Jedes Paket bekommt ein `package-info.java` mit deutlichem Hinweis:
-  ```
-  Diese Klassen stammen aus einer früheren Implementierung und sind
-  für die Meilensteine M3 bis M6 vorgesehen. Sie sind in M1 nicht Teil
-  der aktiven Validierungskette. Änderungen an diesen Klassen während
-  M1 sind zu vermeiden.
-  ```
+### 1. Bootstrap-Verdrahtung anpassen
 
-### Entkopplung vom Lauf
-- `CliRunner` und `Bootstrap` dürfen die Preview-Klassen **nicht** aufrufen
-- der aktive M1-Lauf verwendet ausschließlich den Dummy-Pfad aus AP06 (Datei einlesen, leeren `ValidationReport` erzeugen)
-- die alten Tests der Preview-Klassen laufen **weiterhin grün mit**, damit der Code nicht verrottet
-- `validation.model.ValidationResult` (alt) bleibt im Preview-Paket und wird **nicht** mit dem neuen `ValidationReport` aus AP05 verwechselt
+In `bootstrap.Main`: `DefaultInputFileValidator` erhält statt `DefaultStructureValidator` und `DefaultFieldValidator` jeweils eine **Null-Implementation** — eine leere Implementierung der jeweiligen Interfaces, die keine Befunde produziert.
 
-### Saubere Kennzeichnung
-- In `README.md` des Repos (falls vorhanden, sonst anlegen) ein kurzer Abschnitt „Preview-Code" mit Verweis auf `docs/arbeitspakete/m1/AP09-altlogik-einfrieren.md`
-- Kein `@Deprecated`! Deprecated würde bedeuten „wird entfernt" — das Gegenteil ist der Fall.
+Die Null-Implementierungen können als benannte Klassen in `bootstrap` oder `application` angelegt werden:
+
+```java
+/** M1-Platzhalter. Ab M3 durch DefaultStructureValidator ersetzen. */
+public final class NoOpStructureValidator implements StructureValidator {
+    @Override
+    public List<Finding> validate(ValidationContext ctx) {
+        return List.of(); // bewusst leer in M1
+    }
+}
+```
+
+Analog für `NoOpFieldValidator`.
+
+### 2. Einfriermarker als JavaDoc-Kommentar
+
+`DefaultStructureValidator` und `DefaultFieldValidator` erhalten folgenden JavaDoc-Kommentar — keine andere Änderung:
+
+```java
+/**
+ * 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 docs/arbeitspakete/m1/E00-entscheidungsprotokoll.md E-01
+ */
+```
+
+### 3. Abnahmetest
+
+Ein Integrationstest prüft, dass ein Lauf mit einer beliebigen Testdatei **keine** fachlichen Findings mit Bezug auf ASVREC-/ASVFEH-Segmentregeln erzeugt.
+
+### 4. Aufräumen
+
+- `DefaultStructureValidatorTestAdditional` (leere Testklasse ohne `@Test`-Methoden) löschen (gemäß E-03)
+- Sicherstellen dass `logs/` in `.gitignore` steht (falls AP06 das noch nicht erledigt hat)
+- Aktive Tests von `DefaultStructureValidator` und `DefaultFieldValidator` bleiben **erhalten und grün** — sie testen den M3-Vorbau
+
+### 5. Grep-Nachweis im Bericht
+
+```bash
+grep -rn "DefaultStructureValidator\|DefaultFieldValidator" \
+  src/main/java/de/gecheckt/asv/adapter \
+  src/main/java/de/gecheckt/asv/bootstrap
+```
+
+Muss **leer** sein — der aktive Code darf diese Klassen nicht mehr referenzieren.
 
 ## Scope OUT
 
-- Weiterentwicklung der Preview-Klassen
-- Änderung der Preview-Tests (außer notwendige Import-Anpassungen durch den Package-Umzug)
-- Integration der Preview-Klassen in die neue `domain.finding`-Struktur (das ist explizit M3+)
-- Löschung von Preview-Klassen, auch wenn sie wie Duplikate wirken
+- Paketumzug der Preview-Klassen (explizit **nicht** — Entscheidung E-01 Option b)
+- Inhaltliche Änderung an `DefaultStructureValidator` oder `DefaultFieldValidator`
+- Fachliche Neubewertung der 19 Preview-Regeln (das ist M3)
+- Löschen von Preview-Klassen
 
 ## Schritte
 
-1. Branch `m1/ap09-preview-einfrieren`
-2. Zielpaket wählen (`preview` empfohlen) und im Bericht begründen
-3. Alle Parser-Klassen verschieben
-4. Alle Validator-Klassen verschieben
-5. `validation.model.ValidationResult` und `validation.model.*` mit verschieben
-6. Tests entsprechend verschieben; Imports anpassen
-7. `CliRunner`/`Bootstrap` auf Preview-Imports prüfen — **darf keine haben**, sonst entkoppeln
-8. `package-info.java` mit Warnhinweis in jedem Preview-Unterpaket anlegen
-9. README-Abschnitt „Preview-Code" ergänzen
-10. `mvn clean verify` grün bekommen (alle Tests der Preview-Klassen laufen weiter mit)
-11. Commit `M1-AP09: Alt-Parser und Alt-Validator nach preview-Paket, vom M1-Lauf entkoppelt`
-12. Abschlussbericht schreiben
+1. `NoOpStructureValidator` und `NoOpFieldValidator` anlegen
+2. `bootstrap.Main` umverdrahten: Preview-Validatoren durch NoOp-Implementierungen ersetzen
+3. JavaDoc-Einfriermarker in `DefaultStructureValidator` und `DefaultFieldValidator` ergänzen
+4. `DefaultStructureValidatorTestAdditional` löschen
+5. Grep-Nachweis ausführen und im Bericht dokumentieren
+6. Integrationstest: Lauf erzeugt keine ASVREC-/ASVFEH-Segmentbefunde
+7. `mvn clean verify` grün — alle bisherigen Tests der Preview-Klassen müssen weiterhin grün sein
+8. Abschlussbericht schreiben
 
 ## Abnahmekriterien
 
-- alle ursprünglich vorhandenen Parser- und Validator-Klassen liegen im Preview-Paket
-- alle zugehörigen Tests laufen weiterhin grün
-- `grep -rn "de.gecheckt.asv.preview" src/main/java/de/gecheckt/asv/adapter src/main/java/de/gecheckt/asv/bootstrap src/main/java/de/gecheckt/asv/application` ist **leer** (keine Referenzen aus dem aktiven Code)
-- `package-info.java` mit Warnhinweis in jedem Preview-Unterpaket
-- README enthält Abschnitt „Preview-Code"
-- keine Klasse wurde gelöscht (`git log --diff-filter=D` für diesen Commit zeigt nur Verschiebungen)
-- `mvn clean verify` ist grün
-- Abschlussbericht liegt vor
+- [ ] `NoOpStructureValidator` und `NoOpFieldValidator` existieren
+- [ ] `bootstrap.Main` verdrahtet keine Preview-Validatoren mehr
+- [ ] Grep auf `DefaultStructureValidator`/`DefaultFieldValidator` in `adapter` und `bootstrap` ist leer (Nachweis im Bericht)
+- [ ] Einfriermarker-JavaDoc in beiden Preview-Klassen vorhanden
+- [ ] `DefaultStructureValidatorTestAdditional` ist gelöscht
+- [ ] Bestehende Tests der Preview-Klassen laufen weiterhin grün
+- [ ] Integrationstest: Lauf mit Testdatei erzeugt keine ASVREC-/ASVFEH-Segmentbefunde
+- [ ] `mvn clean verify` grün
+- [ ] Abschlussbericht unter `docs/arbeitspakete/m1/berichte/AP09-bericht.md`
 
 ## Rest-Risiken und offene Punkte
 
-- Bei Wiederaufnahme in M3 wird zu klären sein, wie der Preview-Code an das neue Befundmodell angebunden wird. Das ist explizit M3-Aufgabe, nicht M1.
-- Falls die Preview-Tests beim Package-Umzug brechen (wegen relativer Ressourcenpfade o.ä.), müssen sie einmalig angepasst werden. Das ist kein Scope-Verstoß, sondern Teil des Umzugs.
+- Bei Wiederaufnahme in M3: jede der 19 Preview-Regeln ist neu gegen V1-V/T/N/K-Klassifikation zu bewerten. Explizit M3-Aufgabe.
+- Falls Preview-Tests beim Einfrieren brechen (z.B. wegen Interface-Änderungen durch AP05): einmalige Anpassung der Testimports ist kein Scope-Verstoß, sondern Teil der Konsolidierung.
 
 ## Bericht
 
-`docs/arbeitspakete/m1/berichte/AP09-bericht.md` nach `templates/ap-bericht.md`.
+`docs/arbeitspakete/m1/berichte/AP09-bericht.md` nach `docs/arbeitspakete/m1/templates/ap-bericht.md`.