# M6 - Arbeitspakete ## Geltungsbereich Dieses Dokument beschreibt ausschließlich die Arbeitspakete für den definierten Meilenstein **M6 – Dateinamensbildung, Dublettenbehandlung und Zielkopie**. Die Meilensteine **M1**, **M2**, **M3**, **M4** und **M5** werden als vollständig umgesetzt vorausgesetzt. Die Arbeitspakete sind bewusst so geschnitten, dass: - **KI 1** daraus je Arbeitspaket einen klaren Einzel-Prompt ableiten kann, - **KI 2** genau dieses eine Arbeitspaket in **einem Durchgang** vollständig umsetzen kann, - nach **jedem** Arbeitspaket wieder ein **fehlerfreier, buildbarer Stand** vorliegt. Die Reihenfolge der Arbeitspakete ist verbindlich. ## Zusätzliche Schnittregeln für die KI-Bearbeitung - Pro Arbeitspaket nur die **minimal notwendigen Querschnitte** durch Domain, Application, Adapter und Bootstrap ändern. - Keine Annahmen treffen, die nicht durch dieses Dokument oder die verbindlichen Spezifikationen gedeckt sind. - Kein Vorgriff auf **M7+**. - Kein Umbau bestehender M1–M5-Strukturen ohne direkten M6-Bezug. - Neue Typen, Ports, Statusübergänge, Migrationen und Adapter so schneiden, dass sie aus einem einzelnen Arbeitspaket heraus **klar benennbar, testbar und reviewbar** sind. - M6 baut auf dem in M5 persistierten, validierten Benennungsvorschlag auf und führt **keine zweite Wahrheitsquelle** für Datum, Titel oder Reasoning ein. - Jedes Arbeitspaket muss so präzise sein, dass **KI 1** keine offenen Fach- oder Architekturentscheidungen an **KI 2** delegieren muss. - M6 endet fachlich mit dem **echten Enderfolg**: korrekt benannte Zielkopie vorhanden und Erfolg konsistent persistiert. ## Explizit nicht Bestandteil von M6 - fachliche Retry-Logik des Endstands über mehrere spätere Läufe hinaus, soweit sie über die bereits vorhandene Minimalfehlersemantik hinausgeht - technischer Sofort-Wiederholversuch für Zielkopierfehler innerhalb desselben Laufs - Logging-Feinschliff und Sensibilitätsregeln des Endstands aus M7 - neue KI-Funktionalität, Prompt-Evolution oder M5-Fachlogik jenseits der für M6 nötigen Weiterverwendung - manuelle Nachbearbeitung oder Benutzerinteraktion - Reporting-, Statistik- oder Auswertungsfunktionen - spätere Betriebsoptimierungen, die nicht für den M6-Zielstand notwendig sind ## Verbindliche M6-Regeln für **alle** Arbeitspakete ### 1. Führende Quelle des Benennungsvorschlags - Die führende Quelle für Datum, Datumsquelle, validierten Titel und Reasoning bleibt in M6 der **neueste Versuchshistorieneintrag mit Ergebnisstatus `PROPOSAL_READY`**. - M6 rekonstruiert diesen Benennungsvorschlag **nicht** aus dem Dokument-Stammsatz. - M6 erzeugt **keinen neuen KI-Aufruf**, wenn bereits ein nutzbarer `PROPOSAL_READY`-Versuch vorliegt. - Ein Dokumentzustand `PROPOSAL_READY` ohne lesbaren, konsistenten `PROPOSAL_READY`-Versuch gilt in M6 als **dokumentbezogener technischer Fehler**, nicht als stiller Anlass für eine heimliche Neuinterpretation. - Ein geladener `PROPOSAL_READY`-Versuch mit fachlich oder technisch unbrauchbaren Kernwerten für Datum oder Titel gilt ebenfalls als **inkonsistenter Persistenzzustand** und damit als **dokumentbezogener technischer Fehler**. ### 2. Positive Status- und Übergangssemantik in M6 Ab M6 gilt verbindlich: - `READY_FOR_AI` bleibt verarbeitbar. - `FAILED_RETRYABLE` bleibt verarbeitbar. - `PROPOSAL_READY` ist der **fachlich korrekte Eingangszustand** für Dateinamensbildung, Dublettenbehandlung und Zielkopie. - `SUCCESS` ist ab M6 der **echte terminale Enderfolg** nach erfolgreicher Zielkopie und konsistenter Persistenz. - `FAILED_FINAL` bleibt terminal und wird nicht erneut fachlich verarbeitet. - `SUCCESS` wird in späteren Läufen nicht erneut verarbeitet, sondern mit `SKIPPED_ALREADY_PROCESSED` historisiert. - `FAILED_FINAL` wird in späteren Läufen nicht erneut verarbeitet, sondern mit `SKIPPED_FINAL_FAILURE` historisiert. ### 3. Verbindliche Dateinamensregeln in M6 Der finale Zieldateiname folgt technisch verbindlich diesem Muster: ```text YYYY-MM-DD - Titel.pdf ``` Dabei gilt: - das Datum stammt aus dem führenden M5-Benennungsvorschlag, - der Titel stammt aus dem führenden M5-Benennungsvorschlag, - die **20 Zeichen** gelten nur für den **Basistitel**, - das Dubletten-Suffix zählt **nicht** zu diesen 20 Zeichen, - die fachliche Titelregel **„keine Sonderzeichen außer Leerzeichen“** bleibt auch in M6 verbindlich abgesichert, - Windows-unzulässige Zeichen werden nur im Rahmen der **technischen Dateisystemzulässigkeit** kontrolliert entfernt oder ersetzt, - diese technische Bereinigung darf **keine neue fachliche Titelinterpretation** erzeugen, - wenn ein geladener Proposal-Titel entgegen der M5-Semantik die fachlichen Titelregeln verletzt, wird dieser Zustand **nicht stillschweigend geheilt**, sondern als **inkonsistenter technischer Dokumentzustand** behandelt, - die Quelldatei bleibt unverändert. ### 4. Dublettenregel in M6 - Die Dublettenregel wird im **Zielordner** physisch gegen bereits vorhandene Dateien aufgelöst. - Der erste freie Name ist zu verwenden: - `YYYY-MM-DD - Titel.pdf` - `YYYY-MM-DD - Titel(1).pdf` - `YYYY-MM-DD - Titel(2).pdf` - usw. - Das Suffix wird unmittelbar vor `.pdf` angehängt. - Die Dublettenauflösung ist rein technisch und führt **keine** neue fachliche Titelvariante ein. ### 5. Zielkopie und Dateisystemsemantik - M6 erzeugt bei Erfolg **eine Kopie** im Zielordner. - Die Quelldatei wird **nicht** verändert, verschoben, gelöscht oder überschrieben. - Die Zielerzeugung erfolgt über eine temporäre Zieldatei mit anschließendem finalem Move/Rename, soweit dies im Zielkontext technisch möglich ist. - M6 führt **keinen** fachlichen oder technischen Sofort-Mehrfachversuch für die Zielkopie ein; dieser ist M7 vorbehalten. ### 6. Persistenzerweiterung und Historisierung in M6 Die Persistenz wird in M6 gezielt erweitert: - Der **Dokument-Stammsatz** speichert zusätzlich mindestens: - letzten Zielpfad, - letzten Zieldateinamen. - Die **Versuchshistorie** speichert zusätzlich mindestens: - finalen Zieldateinamen. - Datum, Datumsquelle, validierter Titel und Reasoning bleiben weiterhin führend in der Versuchshistorie des `PROPOSAL_READY`-Versuchs und werden nicht redundant in den Stammsatz gespiegelt. - Ein M6-Enderfolg oder M6-Fehler wird als **zusätzlicher neuer Versuch** historisiert; der führende `PROPOSAL_READY`-Versuch bleibt dabei **unverändert erhalten**. - M6 überschreibt oder ersetzt **nicht** nachträglich den führenden Proposal-Versuch, sondern baut fachlich und historisch auf ihm auf. ### 7. Reihenfolge pro Dokument in M6 Die Verarbeitung eines einzelnen Kandidaten erfolgt in M6 verbindlich in dieser Reihenfolge: 1. Fingerprint berechnen 2. Dokument-Stammsatz laden 3. terminale Skip-Fälle entscheiden 4. falls nötig den bestehenden M5-Pfad bis zu einem gültigen Benennungsvorschlag ausführen 5. führenden `PROPOSAL_READY`-Versuch laden 6. finalen Basis-Dateinamen bilden 7. Dubletten-Suffix im Zielordner bestimmen 8. Zielkopie technisch schreiben 9. einen **neuen** M6-Versuch für Enderfolg oder technischen Fehler historisieren 10. Dokument-Stammsatz konsistent fortschreiben ### 8. Erfolg und Konsistenz in M6 - `SUCCESS` darf erst gesetzt werden, wenn: 1. die Zielkopie erfolgreich geschrieben wurde, 2. der finale Zieldateiname bestimmt ist, 3. die zugehörige Persistenz konsistent fortgeschrieben wurde. - Es darf **kein** Fall entstehen, in dem ein Dokument als `SUCCESS` persistiert ist, ohne dass die Zielkopie erfolgreich vorliegt. - Wenn die Persistenz nach erfolgreicher Zielkopie scheitert, ist **kein** `SUCCESS` zu setzen; ein best-effort Rückbau der neu erzeugten Zielkopie ist in M6 zweckmäßig und architekturtreu vorzusehen. - Wenn dieser Rückbau selbst nur teilweise gelingt, bleibt der Fall ein **dokumentbezogener technischer Fehler**; M6 erfindet daraus weder einen Erfolg noch eine neue finale Fehlerkategorie. ### 9. Fehlersemantik in M6 - Technische Fehler bei Proposal-Quelllesung, Zielpfadbildung, Dublettenauflösung, Zielkopie oder M6-relevanter Persistenz nach erfolgreicher Fingerprint-Ermittlung sind in M6 **dokumentbezogene technische Fehler**. - Diese Fehler bleiben retryable und laufen über den **Transientfehlerzähler**. - M6 führt **keine** neue finale Fehlerkategorie nur für Zielkopierfehler ein. - Dokumentbezogene M6-Fehler dürfen den Batch-Lauf für andere Dokumente nicht unnötig abbrechen. ### 10. Kein Vorgriff auf M7 M6 liefert den vollständigen Erfolgspfad für Dateinamensbildung, Dublettenbehandlung und Zielkopie, aber ausdrücklich **nicht**: - den technischen Sofort-Wiederholversuch beim Schreiben, - den finalen Logging-Feinschliff, - die vollständige Betriebsrobustheit und Retry-Ausarbeitung des Endstands. --- ## AP-001 M6-Kernobjekte, Zielerfolgssemantik und Port-Verträge präzisieren ### Voraussetzung Keine. Dieses Arbeitspaket ist der M6-Startpunkt. ### Ziel Die M6-relevanten Typen, Erfolgskriterien, Zielartefakt-Begriffe und Port-Verträge werden eindeutig eingeführt, damit spätere Arbeitspakete ohne Interpretationsspielraum implementiert werden können. ### Muss umgesetzt werden - Neue M6-relevante Kernobjekte bzw. Application-nahe Typen anlegen, insbesondere für: - finalen Dateinamenkandidaten, - Dublettenauflösung bzw. Namenskollision, - Zielartefakt-Planung, - Zielschreib-Ergebnis, - M6-bezogene Persistenzdaten für den Enderfolg, - lesbaren führenden Benennungsvorschlag aus dem neuesten `PROPOSAL_READY`-Versuch, - inkonsistenten Proposal-Quellzustand. - Die M6-Statussemantik in JavaDoc und ggf. `package-info` so schärfen, dass klar ist: - `PROPOSAL_READY` ist M6-verarbeitbar, - `SUCCESS` ist nur nach echter Zielkopie plus konsistenter Persistenz zulässig, - `SUCCESS` und `FAILED_FINAL` bleiben terminale Skip-Zustände, - ein inkonsistenter Zustand `PROPOSAL_READY` ohne lesbare führende Versuchsdaten ein technischer Dokumentfehler ist, - ein M6-Endversuch zusätzlich zum Proposal-Versuch historisiert wird und diesen nicht ersetzt. - Outbound-Ports definieren oder gezielt erweitern für: - Laden des führenden `PROPOSAL_READY`-Versuchs, - technische Dublettenauflösung im Zielordner, - Zielkopie/Schreiboperation, - Persistenz der M6-Zieldaten. - Port-Verträge so schneiden, dass **weder `Path`/`File` noch NIO-/JDBC-Typen** in Domain oder Application durchsickern. - Rückgabemodelle so anlegen, dass spätere Arbeitspakete ohne Zusatzannahmen unterscheiden können zwischen: - nutzbarem führenden Benennungsvorschlag, - fehlendem oder inkonsistentem Proposal-Quellzustand, - erfolgreicher Dublettenauflösung, - technischem Zielschreibfehler, - technischem Persistenzfehler nach Zielkopie, - konsistentem M6-Enderfolg. - Explizit dokumentieren, dass M6 **keine zweite Wahrheitsquelle** für Datum, Titel und Reasoning einführt. - Explizit dokumentieren, dass M6 **keinen Sofort-Wiederholversuch** der Zielkopie einführt. ### Explizit nicht Teil - konkrete Dateisystem-Implementierung - konkrete SQLite-Schemaänderungen - Batch-Integration - reale Zielkopie - Tests für das Endverhalten ### Fertig wenn - die M6-relevanten Typen und Port-Verträge vorhanden sind, - Zielerfolg, Proposal-Quelle, inkonsistente Proposal-Zustände und technische Fehlerarten klar unterscheidbar modelliert sind, - Domain und Application frei von Infrastrukturtypen bleiben, - der Build weiterhin fehlerfrei ist. --- ## AP-002 Technische Dateinamensbildung für den finalen M6-Basisnamen implementieren ### Voraussetzung AP-001 ist abgeschlossen. ### Ziel Aus dem führenden M5-Benennungsvorschlag kann ein technischer, finaler M6-Basisdateiname im Zielformat erzeugt werden, ohne bereits eine physische Zielkopie oder Dublettenauflösung im Dateisystem auszuführen. ### Muss umgesetzt werden - Einen M6-Baustein für die technische Dateinamensbildung implementieren. - Das verbindliche Zielformat exakt umsetzen: ```text YYYY-MM-DD - Titel.pdf ``` - Den Basistitel aus dem führenden M5-Benennungsvorschlag übernehmen und technisch in einen final verwendbaren M6-Basisdateinamen überführen. - Die fachliche Titelregel **„keine Sonderzeichen außer Leerzeichen“** im M6-Kontext explizit absichern: - regulärer Happy-Path: der bereits validierte M5-Titel wird unverändert weiterverwendet, - inkonsistenter Persistenzfall: ein geladener Proposal-Titel, der diese Regel verletzt, wird **nicht** stillschweigend fachlich umgedeutet, sondern als technischer Dokumentfehler behandelt. - Windows-unzulässige Zeichen kontrolliert entfernen oder ersetzen, **soweit dies ausschließlich der technischen Dateisystemzulässigkeit dient**. - Sicherstellen, dass die **20-Zeichen-Regel** ausschließlich für den **Basistitel** gilt und nicht für ein späteres Dubletten-Suffix. - Keine neue fachliche Titelinterpretation einführen; M6 baut auf dem bereits validierten M5-Titel auf. - Einen defensiven technischen Schutz für inkonsistente Persistenzzustände vorsehen, falls ein geladener Proposal-Titel oder Proposal-Datumswert entgegen der M5-Semantik nicht verwertbar ist. - JavaDoc für Zielformat, fachliche Titelregel, Windows-Kompatibilität, Basistitelbegriff und Nicht-Ziele von M6 ergänzen. ### Explizit nicht Teil - Dublettenprüfung gegen den Zielordner - physische Zielkopie - Persistenzänderungen - Batch-Orchestrierung - Zielpfadbildung im Dateisystem ### Fertig wenn - aus einem nutzbaren M5-Benennungsvorschlag deterministisch ein M6-Basisdateiname erzeugt werden kann, - das Zielformat exakt eingehalten wird, - die fachliche Titelregel und die technische Windows-Kompatibilität **klar getrennt** behandelt werden, - inkonsistente Proposal-Daten nicht stillschweigend fachlich bereinigt werden, - weiterhin keine physische Zielkopie oder Dublettenauflösung erfolgt, - der Stand fehlerfrei buildbar bleibt. --- ## AP-003 Zielordnerzugriff, Dublettenauflösung und Zielpfadplanung im Adapter-Out implementieren ### Voraussetzung AP-001 und AP-002 sind abgeschlossen. ### Ziel Der Zielordner kann technisch bewertet werden, der erste freie finale Zieldateiname im Zielkontext wird bestimmt und eine konsistente Zielpfadplanung steht für die spätere Kopieroperation bereit. ### Muss umgesetzt werden - Dateisystem-Adapter für den Zielordnerzugriff implementieren. - Technische Dublettenauflösung im Zielordner umsetzen. - Den ersten freien Namen nach folgender Regel bestimmen: - ohne Suffix, - dann `(1)`, `(2)`, … direkt vor `.pdf`. - Sicherstellen, dass das Dubletten-Suffix **nicht** in die 20-Zeichen-Regel des Basistitels eingerechnet wird. - Die Zielpfadplanung so schneiden, dass sie den finalen Zielnamen und eine technische temporäre Zieldatei im Zielkontext vorbereiten kann. - Technische Fehler beim Lesen des Zielordners oder bei der Namensauflösung kontrolliert in den Port-Vertrag überführen. - JavaDoc für Zielordnerzugriff, Kollisionserkennung, Suffixlogik und technische Grenzen ergänzen. ### Explizit nicht Teil - tatsächliches Kopieren der Datei - Persistenz von Zielpfad oder Zieldateiname - Batch-Use-Case-Integration - M7-Sofort-Wiederholversuch ### Fertig wenn - der Zielordner technisch ausgewertet werden kann, - der erste freie finale Zieldateiname korrekt bestimmbar ist, - eine temporäre und finale Zielpfadplanung bereitsteht, - technische Fehler kontrolliert über den Port geliefert werden, - der Build weiterhin fehlerfrei ist. --- ## AP-004 Zielkopie mit temporärer Zieldatei und finalem Move/Rename implementieren ### Voraussetzung AP-001 bis AP-003 sind abgeschlossen. ### Ziel Eine Quelldatei kann als M6-Zielartefakt technisch in den Zielordner kopiert werden, wobei temporäre Zielerzeugung und finaler Move/Rename sauber gekapselt sind. ### Muss umgesetzt werden - Einen Adapter-Out für die physische Zielkopie implementieren. - Die Zielerzeugung so umsetzen, dass mindestens folgender technischer Ablauf möglich ist: 1. Kopie in eine temporäre Zieldatei im Zielkontext, 2. finaler Move/Rename auf den zuvor geplanten finalen Zieldateinamen. - Sicherstellen, dass die Quelldatei unverändert bleibt. - Kontrolliertes technisches Fehlerverhalten mindestens für folgende Fälle umsetzen: - Zielordner nicht schreibbar, - temporäre Zieldatei nicht anlegbar, - Kopieren scheitert, - finaler Move/Rename scheitert, - technische Aufräumarbeiten nach Fehler nur teilweise möglich. - Das Ergebnis so modellieren, dass spätere Arbeitspakete zwischen erfolgreicher Zielerzeugung, technischem Schreibfehler und technischem Teil-Cleanup unterscheiden können. - JavaDoc für Zielkopie, temporäre Datei, finalen Move/Rename und Quellunverändertheit ergänzen. ### Explizit nicht Teil - Statusfortschreibung im Use Case - Persistenz von Enderfolg oder Zielpfad - Batch-Integration - technischer Sofort-Wiederholversuch im selben Lauf ### Fertig wenn - eine Zielkopie technisch erzeugt werden kann, - temporäre und finale Schreibschritte sauber gekapselt sind, - die Quelldatei unverändert bleibt, - technische Zielschreibfehler kontrolliert abgebildet werden, - der Build weiterhin fehlerfrei ist. --- ## AP-005 SQLite-Schema von M5 nach M6 evolvieren und M6-Zieldaten sowie Proposal-Quelle gezielt nutzbar machen ### Voraussetzung AP-001 bis AP-004 sind abgeschlossen. ### Ziel Die bestehende M5-Persistenz wird kontrolliert auf den M6-Stand erweitert, sodass Zielpfad, finaler Zieldateiname und der führende `PROPOSAL_READY`-Versuch technisch sauber nutzbar sind, ohne die M5-Historie umzudeuten oder zu überschreiben. ### Muss umgesetzt werden - Das bestehende SQLite-Schema **evolvieren**, nicht neu erfinden. - Die Schema-Initialisierung so erweitern, dass ein vorhandenes M5-Schema kontrolliert auf den M6-Stand gebracht werden kann. - Den Dokument-Stammsatz um die für M6 benötigten Felder erweitern, mindestens für: - letzten Zielpfad, - letzten Zieldateinamen. - Die Versuchshistorie um das für M6 benötigte Feld erweitern, mindestens für: - finalen Zieldateinamen. - Repository-Mapping so erweitern, dass die neuen M6-Zieldaten technisch schreib- und lesbar sind. - Eine gezielte Lesefähigkeit bereitstellen oder erweitern, um den **neuesten Versuch mit `PROPOSAL_READY`** als führende Proposal-Quelle für M6 zu laden. - Explizit sicherstellen, dass M6 bei Enderfolg oder technischem M6-Fehler **einen neuen Versuchseintrag** anlegt und den führenden Proposal-Versuch **nicht überschreibt**. - Sicherstellen, dass: - bestehende M5-Daten weiterhin lesbar bleiben, - die M6-Erweiterung idempotent initialisierbar ist, - keine M7+-Felder vorweggenommen werden, - keine redundante zweite Persistenzwahrheit für Datum, Titel und Reasoning im Stammsatz entsteht. - JavaDoc für Schemaevolution, führende Proposal-Quelle, neue M6-Versuchseinträge, M6-Zieldaten und Rückwärtsverträglichkeit ergänzen. ### Explizit nicht Teil - Batch-Use-Case-Integration - reale Zielkopie - Status- und Zählerentscheidungen im laufenden Dokumentprozess - M7-Retry-Ausarbeitung ### Fertig wenn - das M5-Schema kontrolliert auf M6 erweitert werden kann, - Zielpfad und Zieldateiname technisch persistierbar sind, - der neueste `PROPOSAL_READY`-Versuch gezielt lesbar ist, - M6-Enderfolg/-Fehler historisch **zusätzlich** speicherbar sind, ohne den Proposal-Versuch zu ersetzen, - bestehende M5-Daten nicht unbrauchbar werden, - der Stand fehlerfrei buildbar bleibt. --- ## AP-006 M6-Entscheidungslogik und Batch-Integration für Enderfolg, Proposal-Quelle, Skip-Semantik und technische Fehlerfortschreibung umsetzen ### Voraussetzung AP-001 bis AP-005 sind abgeschlossen. ### Ziel Der bestehende M5-Lauf wird zu einem echten M6-Lauf erweitert, der aus geeigneten Dokumenten eine korrekt benannte Zielkopie erzeugt, den Enderfolg als `SUCCESS` persistiert und technische M6-Fehler sauber im vorhandenen Zähler- und Statusrahmen fortschreibt. ### Muss umgesetzt werden - Den bestehenden Batch-Use-Case so erweitern, dass pro geeignetem Dokument zusätzlich gilt: 1. terminale Skip-Fälle auswerten, 2. falls nötig den M5-Pfad bis zu einem gültigen `PROPOSAL_READY` durchlaufen, 3. bei vorhandenem `PROPOSAL_READY` den führenden Proposal-Versuch laden, 4. finalen Basisdateinamen bilden, 5. Dubletten-Suffix im Zielordner bestimmen, 6. Zielkopie erzeugen, 7. **einen neuen M6-Versuch** für Enderfolg oder technischen Fehler historisieren, 8. Stammsatz konsistent fortschreiben. - Sicherstellen, dass **kein neuer KI-Aufruf** erfolgt, wenn bereits ein nutzbarer `PROPOSAL_READY`-Versuch vorliegt. - Sicherstellen, dass ein Dokument mit Status `PROPOSAL_READY` im M6-Lauf **nicht** fälschlich übersprungen wird, sondern in die M6-Finalisierung geht. - Folgende Regeln explizit umsetzen: - `SUCCESS` → kein erneuter fachlicher Durchlauf, stattdessen `SKIPPED_ALREADY_PROCESSED` - `FAILED_FINAL` → kein erneuter fachlicher Durchlauf, stattdessen `SKIPPED_FINAL_FAILURE` - gültige Zielkopie plus konsistente Persistenz → `SUCCESS` - technischer Fehler bei Proposal-Quelllesung, inkonsistentem Proposal-Zustand, Zielpfadbildung, Dublettenauflösung, Zielkopie oder M6-Persistenz → `FAILED_RETRYABLE`, **Transientfehlerzähler +1** - Sicherstellen, dass der finale Zieldateiname und der Zielpfad bei echtem Enderfolg konsistent persistiert werden. - Sicherstellen, dass bei erfolgreicher Zielkopie, aber scheiternder Persistenz **kein** `SUCCESS` entsteht. - Für den Fall einer nachgelagerten Persistenzstörung nach bereits erzeugter Zielkopie einen **best-effort Rückbau** des neu erzeugten Zielartefakts vorsehen, ohne M7-Retry-Verhalten vorwegzunehmen. - Sicherstellen, dass dokumentbezogene M6-Fehler den Batch-Lauf für andere Dokumente kontrolliert weiterlaufen lassen. - JavaDoc für M6-Laufreihenfolge, Proposal-Quelle, echte Enderfolgssemantik, neue M6-Historisierung, Skip-Regeln und Fehlerfortschreibung ergänzen. ### Explizit nicht Teil - technischer Sofort-Wiederholversuch der Zielkopie - Logging-Feinschliff des Endstands - M7-spezifische Retry-Ausarbeitung - Reporting oder Auswertung ### Fertig wenn - der Batch-Lauf geeignete Dokumente bis zur korrekt benannten Zielkopie verarbeiten kann, - bestehende `PROPOSAL_READY`-Dokumente in M6 korrekt finalisiert werden, - inkonsistente Proposal-Zustände kontrolliert als technische Dokumentfehler behandelt werden, - `SUCCESS` nur nach echter Zielkopie plus konsistenter Persistenz gesetzt wird, - M6-Enderfolg und M6-Fehler als **zusätzliche** Historieneinträge entstehen, - technische M6-Fehler sauber als retryable fortgeschrieben werden, - weiterhin keine M7+-Funktionalität enthalten ist. --- ## AP-007 Bootstrap- und CLI-Anpassungen für Zielordner-Konfiguration, M6-Schemaevolution und vollständige Verdrahtung durchführen ### Voraussetzung AP-001 bis AP-006 sind abgeschlossen. ### Ziel Der Programmeinstieg ist sauber an den M6-Lauf angepasst; Zielordner-Konfiguration, M6-Schemaevolution und alle neuen M6-Bausteine sind verdrahtet und harte Startfehler führen weiterhin kontrolliert zu Exit-Code 1. ### Muss umgesetzt werden - Bootstrap-Verdrahtung auf die neuen M6-Ports, Adapter und Persistenzbausteine erweitern. - M6-relevante Konfiguration ergänzen bzw. verdrahten, insbesondere für: - `target.folder` - Startvalidierung so ergänzen, dass mindestens geprüft wird: - Zielordner ist vorhanden oder technisch anlegbar, - Zielordner ist als Verzeichnis nutzbar, - Zielordner ist für den M6-Schreibpfad technisch verwendbar, - M6-relevante Persistenzkonfiguration bleibt nutzbar. - Die bestehende M5-Schemainitialisierung sauber mit der M6-Schemaevolution kombinieren. - Sicherstellen, dass harte Start-, Verdrahtungs-, Konfigurations- oder Initialisierungsfehler weiterhin zu **Exit-Code 1** führen. - Sicherstellen, dass dokumentbezogene M6-Fehler **nicht** als Startfehler fehlmodelliert werden. - JavaDoc und `package-info` für aktualisierte Verdrahtung, Konfiguration, Zielordner-Validierung und Modulgrenzen ergänzen. ### Explizit nicht Teil - Logging-Feinschliff des Endstands - M7-Retry-Mechanik - spätere Betriebsoptimierungen ### Fertig wenn - das Programm im M6-Stand vollständig startbar ist, - alle M6-Bausteine korrekt verdrahtet sind, - die M6-Startvalidierung greift, - harte Startfehler weiterhin kontrolliert zu Exit-Code 1 führen, - der Build fehlerfrei bleibt. --- ## AP-008 Tests für Dateinamensbildung, Dublettenbehandlung, Zielkopie, Schemaevolution, Proposal-Konsistenz, Statussemantik und M6-Ablauf vervollständigen ### Voraussetzung AP-001 bis AP-007 sind abgeschlossen. ### Ziel Der vollständige M6-Zielzustand wird automatisiert abgesichert und als konsistenter Übergabestand nachgewiesen. ### Muss umgesetzt werden - Unit-Tests für die technische Dateinamensbildung implementieren, insbesondere für: - korrektes Zielformat `YYYY-MM-DD - Titel.pdf`, - fachliche Titelregel „keine Sonderzeichen außer Leerzeichen“ im M6-Kontext, - Windows-Zeichenbereinigung, - unveränderte 20-Zeichen-Regel des Basistitels, - unveränderte Wirkung des Dubletten-Suffixes außerhalb des Basistitels. - Tests für die Dublettenauflösung im Zielordner implementieren, insbesondere für: - kein vorhandener Konflikt → Basename wird verwendet, - vorhandener Konflikt → `(1)`, `(2)`, …, - Suffix wird unmittelbar vor `.pdf` gesetzt. - Adapter-Tests für die Zielkopie ergänzen, insbesondere für: - erfolgreiche Zielerzeugung über temporäre Datei plus finalen Move/Rename, - Quelldatei bleibt unverändert, - technischer Kopierfehler, - technischer Rename-/Move-Fehler, - best-effort Cleanup nach technischem Fehler. - Repository- und Schema-Tests gegen SQLite ergänzen, insbesondere für: - Evolution eines M5-Schemas auf M6, - Persistenz und Auslesen von Zielpfad und Zieldateiname im Dokument-Stammsatz, - Persistenz und Auslesen des finalen Zieldateinamens in der Versuchshistorie, - gezieltes Laden des neuesten `PROPOSAL_READY`-Versuchs, - zusätzliche M6-Historisierung ohne Überschreiben des Proposal-Versuchs. - Integrationstests für den M6-Ablauf ergänzen, insbesondere: - gültiger M6-Happy-Path endet in `SUCCESS`, **nicht** in `PROPOSAL_READY`, - vorhandenes `PROPOSAL_READY` wird ohne erneuten KI-Aufruf finalisiert, - bestehendes `SUCCESS` wird im Wiederholungslauf historisiert übersprungen, - bestehendes `FAILED_FINAL` wird im Wiederholungslauf historisiert übersprungen, - technischer M6-Zielkopierfehler führt zu retryablem technischem Fehler und erhöht den Transientfehlerzähler, - erfolgreicher Zielschreibpfad mit scheiternder Persistenz führt **nicht** zu `SUCCESS`, - bei M3- oder M5-Vorfehlern erfolgt keine unzulässige M6-Finalisierung, - Status `PROPOSAL_READY`, aber **kein** lesbarer führender Proposal-Versuch führt zu dokumentbezogenem technischem Fehler, - lesbarer Proposal-Versuch mit inkonsistentem Titel- oder Datumswert führt zu dokumentbezogenem technischem Fehler, - es entsteht weiterhin **keine** M7-Sofort-Wiederholung. - Tests für Bootstrap- und Startverhalten ergänzen, insbesondere: - ungültige M6-Konfiguration führt zu Exit-Code 1, - nicht nutzbarer Zielordner führt zu Exit-Code 1, - M6-Schemaevolution wird beim Start wirksam, - dokumentbezogene M6-Fehler führen **nicht** zu Exit-Code 1. - Den M6-Stand abschließend auf Konsistenz, Architekturtreue und Nicht-Vorgriff auf M7+ prüfen. ### Explizit nicht Teil - Tests für M7-Sofort-Wiederholversuch - Tests für finalen Logging-Feinschliff - Tests für spätere Betriebsoptimierungen ### Fertig wenn - die Test-Suite für den M6-Umfang grün ist, - die wichtigsten M6-Randfälle einschließlich Proposal-Inkonsistenzen automatisiert abgesichert sind, - der definierte M6-Zielzustand vollständig erreicht ist, - ein fehlerfreier, übergabefähiger Stand vorliegt. --- ## Abschlussbewertung Die Arbeitspakete decken den vollständigen M6-Zielumfang aus den verbindlichen Spezifikationen ab und schließen die Brücke von **M5 `PROPOSAL_READY`** zum echten Produktiv-Enderfolg **M6 `SUCCESS`** sauber: - technische Dateinamensbildung im Format `YYYY-MM-DD - Titel.pdf` - explizite Trennung zwischen fachlicher Titelregel und technischer Windows-Kompatibilität - Dublettenbehandlung im Zielordner mit `(1)`, `(2)`, … - Zielpfadplanung und physische Zielkopie - Persistenzerweiterung um Zielpfad und finalen Zieldateinamen - Nutzung des neuesten `PROPOSAL_READY`-Versuchs als führende Quelle - saubere Statussemantik `PROPOSAL_READY` → `SUCCESS` - zusätzliche M6-Historisierung ohne Überschreiben der M5-Proposal-Historie - technische Fehlerfortschreibung für Proposal-Quell-, Zielkopier- und Persistenzfehler - Tests für Dateinamen, Dubletten, Zielkopie, Proposal-Konsistenz, Schemaevolution und End-to-End-M6-Ablauf Gleichzeitig bleiben die Grenzen zu M1–M5 sowie zu M7+ gewahrt. Insbesondere werden **kein** Sofort-Wiederholversuch der Zielkopie, **kein** finaler Logging-Feinschliff und **keine** weitergehende Betriebsrobustheit des Endstands vorweggenommen.