526 lines
28 KiB
Markdown
526 lines
28 KiB
Markdown
# 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.
|