# M4 - Arbeitspakete ## Geltungsbereich Dieses Dokument beschreibt ausschließlich die Arbeitspakete für den definierten Meilenstein **M4 – Fingerprint, SQLite-Persistenz und Idempotenz**. Die Meilensteine **M1**, **M2** und **M3** 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 **M5+**. - Kein Umbau bestehender M1–M3-Strukturen ohne direkten M4-Bezug. - Neue Typen, Ports und Adapter so schneiden, dass sie aus einem einzelnen Arbeitspaket heraus **klar benennbar, testbar und reviewbar** sind. ## Explizit nicht Bestandteil von M4 - KI-Anbindung - Prompt-Laden oder Prompt-Verarbeitung - Validierung von KI-Antworten - Dateinamensbildung - Zielkopie in den Zielordner - Windows-Zeichenbereinigung für Zieldateinamen - physische Dublettenbehandlung im Zielordner - M5+-Persistenzfelder wie Modellname, Prompt-Identifikator, KI-Rohantwort, KI-Reasoning, Datumsquelle, finaler Titel oder finaler Zieldateiname - vollständige laufübergreifende Retry-Logik späterer Meilensteine für KI- und Zielkopie-Fehler - Logging-Feinschliff des Endstands ## Verbindliche M4-Regeln für **alle** Arbeitspakete ### 1. Identifikation - Die Identifikation eines Dokuments erfolgt in M4 **ausschließlich über den SHA-256-Fingerprint des Dateiinhalts**. - Dateiname und Pfad dienen **nicht** als Identifikator. - Gleicher Inhalt unter anderem Dateinamen oder anderem Pfad ist **dasselbe Dokument**. - Geänderter Inhalt ist **ein neuer fachlicher Vorgang**. ### 2. Persistenzmodell M4 führt die Persistenz verbindlich in **zwei Ebenen**: 1. **Dokument-Stammsatz** pro Fingerprint 2. **Versuchshistorie** mit einem Datensatz pro historisiertem dokumentbezogenem Verarbeitungsversuch ### 3. Minimale Pflichtdaten im Dokument-Stammsatz für M4 Im Dokument-Stammsatz müssen in M4 mindestens speicherbar sein: - interne ID - Fingerprint - letzter bekannter Quellpfad - letzter bekannter Quelldateiname - aktueller Gesamtstatus - Anzahl bisheriger Inhaltsfehler - Anzahl bisheriger transienter Fehler - letzter Fehlerzeitpunkt - letzter Erfolgzeitpunkt - Erstellungszeitpunkt - Änderungszeitpunkt **Nicht** Bestandteil von M4-Stammsatzfeldern sind Zielpfad, Zieldateiname oder KI-bezogene Felder. ### 4. Minimale Pflichtdaten der Versuchshistorie für M4 Für jeden in M4 zu historisierenden Versuch müssen mindestens speicherbar sein: - Versuchs-ID - Fingerprint-Referenz - Lauf-ID - Versuchsnummer - Startzeitpunkt - Endzeitpunkt - Ergebnisstatus - Fehlerklasse - Fehlermeldung bzw. Begründung - Retryable-Flag ### 5. Statusmodell für M4 Für M4 müssen folgende Statuswerte fachlich klar verwendbar sein: - `SUCCESS` - `FAILED_RETRYABLE` - `FAILED_FINAL` - `SKIPPED_ALREADY_PROCESSED` - `SKIPPED_FINAL_FAILURE` Ein technischer Zwischenstatus `PROCESSING` ist zusätzlich zulässig, aber für M4 nicht verpflichtend. ### 6. Verbindliche M4-Minimalregeln für Status und Zähler Für M4 gelten **genau** diese Minimalregeln: - Bereits erfolgreich verarbeitete Dokumente werden in späteren Läufen übersprungen. - Bereits final fehlgeschlagene Dokumente werden in späteren Läufen übersprungen. - Ein **deterministischer Inhaltsfehler aus M3** - beim **ersten** historisierten Auftreten führt zu `FAILED_RETRYABLE`, erhöht den **Inhaltsfehlerzähler** auf 1 und setzt `retryable = true`, - beim **zweiten** historisierten Auftreten in einem späteren Lauf führt zu `FAILED_FINAL`, erhöht den **Inhaltsfehlerzähler** auf 2 und setzt `retryable = false`. - In M4 sind die deterministischen Inhaltsfehler ausschließlich die bereits aus M3 bekannten Fälle: - kein brauchbarer Text - Seitenlimit überschritten - Dokumentbezogene **technische** Fehler nach erfolgreicher Fingerprint-Ermittlung bleiben in M4 `FAILED_RETRYABLE`, erhöhen den **Transientfehlerzähler** und setzen `retryable = true`. - Skip-Ereignisse ändern **keinen** Fehlerzähler. ### 7. Historisierung in M4 - Jeder **identifizierte** dokumentbezogene Verarbeitungsversuch wird separat historisiert. - Die Versuchsnummer beginnt pro Fingerprint bei **1** und steigt pro historisiertem Versuch monoton um **1**. - Auch Skip-Fälle werden historisiert: - `SKIPPED_ALREADY_PROCESSED` - `SKIPPED_FINAL_FAILURE` - Ein in M4 historisierter Versuch setzt einen **erfolgreich ermittelten Fingerprint** voraus. - Technische Fehler **vor** erfolgreicher Fingerprint-Ermittlung sind in M4 **keine** SQLite-historisierten Versuche; sie werden nur kontrolliert als dokumentbezogene Laufereignisse behandelt. ### 8. Reihenfolge pro Dokument in M4 Die Verarbeitung eines einzelnen Kandidaten erfolgt in M4 verbindlich in dieser Reihenfolge: 1. Fingerprint berechnen 2. Dokument-Stammsatz laden 3. bei `SUCCESS` Skip-Entscheidung treffen und Skip-Versuch historisieren 4. bei `FAILED_FINAL` Skip-Entscheidung treffen und Skip-Versuch historisieren 5. sonst bestehenden M3-Ablauf ausführen 6. M3-Ergebnis in M4-Status, Zähler und Retryable-Flag überführen 7. Versuch historisieren 8. Dokument-Stammsatz fortschreiben ### 9. Konsistenz pro identifiziertem Dokument - Für jeden identifizierten dokumentbezogenen Versuch müssen **Versuchshistorie und Stammsatz konsistent** fortgeschrieben werden. - Teilaktualisierungen zwischen Historie und Stammsatz sind zu vermeiden. - Wenn die Persistenz eines dokumentbezogenen Versuchs technisch scheitert, darf **kein inkonsistenter Teilzustand** zurückbleiben. ### 10. Schema-Initialisierung - Die Initialisierung des SQLite-Schemas erfolgt in M4 **beim Programmstart**, bevor der Batch-Lauf mit der Dokumentverarbeitung beginnt. - Eine nur implizite oder ausschließlich lazy Initialisierung während des laufenden Dokumentdurchsatzes ist **nicht** Ziel von M4. --- ## AP-001 M4-Kernobjekte, Statussemantik und Port-Verträge präzisieren ### Voraussetzung Keine. Dieses Arbeitspaket ist der M4-Startpunkt. ### Ziel Die M4-relevanten Typen, Statusbedeutungen und Port-Verträge werden eindeutig eingeführt, damit spätere Arbeitspakete ohne Interpretationsspielraum implementiert werden können. ### Muss umgesetzt werden - Neue M4-relevante Kernobjekte bzw. Application-nahe Typen anlegen, insbesondere für: - Dokument-Fingerprint - Dokument-Stammsatz - Verarbeitungsversuch - Fehlerzählerstände - dokumentbezogene Persistenzentscheidung bzw. Lookup-Ergebnis - technische Fehlerklassifikation für dokumentbezogene M4-Verarbeitung - Statusmodell so vervollständigen oder schärfen, dass die verbindlichen M4-Statuswerte fachlich eindeutig abbildbar sind. - Eindeutige Semantik für folgende Fälle im Typmodell bzw. in JavaDoc festlegen: - unbekanntes Dokument - bekanntes, noch nicht terminales Dokument - bereits erfolgreiches Dokument - bereits final fehlgeschlagenes Dokument - historisierbarer dokumentbezogener Versuch - nicht historisierbarer Vor-Fingerprint-Fehler - Outbound-Ports definieren für: - Erzeugung eines Fingerprints für genau einen Verarbeitungskandidaten - Lesen und Schreiben des Dokument-Stammsatzes - Schreiben und Lesen der Versuchshistorie - technische Initialisierung des SQLite-Schemas - Port-Verträge so schneiden, dass **weder `Path`/`File` noch JDBC-/SQLite-Typen** in Domain oder Application durchsickern. - Port-Rückgaben so modellieren, dass spätere Arbeitspakete ohne zusätzliche Annahmen unterscheiden können: - Dokument unbekannt - Dokument bekannt und aktiv weiter zu verarbeiten - Dokument terminal erfolgreich - Dokument terminal final fehlgeschlagen - technischer Persistenzfehler - JavaDoc und `package-info` für: - Statusbedeutungen - Zählersemantik - Historisierungsgrenzen - Architekturgrenzen ergänzen. ### Explizit nicht Teil - SHA-256-Implementierung - SQLite-Implementierung - konkrete SQL-Tabellen - Batch-Integration - Repository-Code ### Fertig wenn - die M4-relevanten Typen und Port-Verträge vorhanden sind, - die M4-Statussemantik eindeutig dokumentiert ist, - Historisierung vs. Vor-Fingerprint-Fehler klar abgegrenzt ist, - Domain und Application frei von Infrastrukturtypen bleiben, - der Build weiterhin fehlerfrei ist. --- ## AP-002 SHA-256-Fingerprint-Adapter für Verarbeitungskandidaten implementieren ### Voraussetzung AP-001 ist abgeschlossen. ### Ziel Für jeden Verarbeitungskandidaten kann ein stabiler, deterministischer SHA-256-Fingerprint erzeugt werden; technische Probleme werden kontrolliert in den Port-Vertrag überführt. ### Muss umgesetzt werden - Fingerprint-Port technisch im Adapter-Out implementieren. - SHA-256-basierte Fingerprint-Erzeugung für genau einen Verarbeitungskandidaten umsetzen. - Sicherstellen, dass der Fingerprint ausschließlich aus dem **Dateiinhalt** abgeleitet wird. - Kontrolliertes technisches Fehlerverhalten für mindestens folgende Fälle abbilden: - Datei nicht lesbar - Datei zwischen Kandidatenermittlung und Fingerprint-Erzeugung nicht mehr vorhanden - sonstige technische IO-Probleme - Sicherstellen, dass Dateisystem- und Hashing-Details ausschließlich im Adapter-Out verbleiben. - JavaDoc für Determinismus, Fehlerverhalten und M4-Grenze ergänzen, dass Vor-Fingerprint-Fehler **nicht** als SQLite-historisierte Versuche gelten. ### Explizit nicht Teil - SQLite-Persistenz - Batch-Orchestrierung - Versuchshistorie - Skip-Logik - Zählerfortschreibung ### Fertig wenn - für denselben Dateiinhalt stabil derselbe SHA-256-Fingerprint erzeugt wird, - Fingerprint und Fehler kontrolliert über den Port geliefert werden, - keine Hashing- oder Dateisystemdetails in Domain oder Application durchsickern, - der Build weiterhin fehlerfrei ist. --- ## AP-003 SQLite-Schema, Start-Initialisierung und Persistenzbasis im Adapter-Out einführen ### Voraussetzung AP-001 und AP-002 sind abgeschlossen. ### Ziel Die SQLite-basierte Persistenzgrundlage für M4 wird technisch sauber eingeführt und beim Programmstart kontrolliert initialisiert. ### Muss umgesetzt werden - SQLite-Dateizugriff im Adapter-Out technisch einführen. - Technischen Initialisierungsbaustein für SQLite-Schema anlegen und über den dafür vorgesehenen Port anbinden. - M4-Schema explizit in **zwei Ebenen** anlegen: - Dokument-Stammsatz - Versuchshistorie - Tabellen, Primärschlüssel, Fremdschlüssel, Unique-Regeln und sinnvolle Indizes für den M4-Stand definieren. - Dokument-Stammsatz so anlegen, dass die in diesem Dokument festgelegten M4-Pflichtfelder speicherbar sind. - Versuchshistorie so anlegen, dass die in diesem Dokument festgelegten M4-Pflichtfelder speicherbar sind. - Sicherstellen, dass: - Versuchsnummer pro Fingerprint eindeutig ist, - Skip-Versuche speicherbar sind, - keine M5+-Spalten angelegt werden. - Die Schema-Initialisierung so vorbereiten, dass sie **beim Programmstart** explizit aufgerufen werden kann. - JavaDoc für Schema-Zweck, Zwei-Ebenen-Modell und Initialisierungszeitpunkt ergänzen. ### Explizit nicht Teil - Repository-Fachlogik - Use-Case-Integration - Statusübergänge im Batch-Lauf - KI-bezogene Persistenzfelder - Zielpfad- oder Dateinamenspersistenz ### Fertig wenn - die SQLite-Datei und das M4-Schema technisch anlegbar sind, - beide Persistenzebenen den M4-Pflichtumfang abbilden, - die Start-Initialisierung technisch vorbereitet ist, - keine M5+-Felder im Schema enthalten sind, - der Stand fehlerfrei buildbar bleibt. --- ## AP-004 Repository für Dokument-Stammsatz mit vollständigem M4-Minimalumfang implementieren ### Voraussetzung AP-003 ist abgeschlossen. ### Ziel Der Dokument-Stammsatz kann pro Fingerprint zuverlässig gelesen, angelegt und fortgeschrieben werden, ohne fachliche Entscheidungslogik in den Adapter-Out zu verlagern. ### Muss umgesetzt werden - Repository-Adapter für den Dokument-Stammsatz implementieren. - Folgende technischen Fähigkeiten bereitstellen: - Suche eines Stammsatzes über Fingerprint - Neuanlage eines Stammsatzes für bisher unbekannte Dokumente - Fortschreibung von: - letztem bekanntem Quellpfad - letztem bekanntem Quelldateinamen - Gesamtstatus - Inhaltsfehlerzähler - Transientfehlerzähler - letztem Fehlerzeitpunkt - letztem Erfolgzeitpunkt - Änderungszeitpunkt - Sicherstellen, dass die Repository-Operationen **keine** fachlichen Entscheidungen über Retry-Regeln oder Skip-Logik treffen. - Mapping zwischen Application-Typen und SQLite-Struktur explizit und nachvollziehbar halten. - Upsert-/Neuanlageverhalten für den M4-Einzelprozess reproduzierbar modellieren. - JavaDoc für Verantwortlichkeit und Mapping ergänzen. ### Explizit nicht Teil - Versuchshistorie - Batch-Skip-Logik - Versuchsnummernvergabe - konkrete Statusentscheidungen im Use-Case - KI- oder Zielkopie-bezogene Persistenz ### Fertig wenn - der Dokument-Stammsatz pro Fingerprint zuverlässig gelesen und geschrieben werden kann, - alle M4-Pflichtfelder des Stammsatzes technisch fortschreibbar sind, - fachliche Entscheidungen nicht in das Repository abgerutscht sind, - der Build weiterhin fehlerfrei ist. --- ## AP-005 Repository für Versuchshistorie mit monotoner Versuchsnummer implementieren ### Voraussetzung AP-003 ist abgeschlossen. ### Ziel Jeder historisierbare dokumentbezogene M4-Versuch kann separat und nachvollziehbar persistiert werden. ### Muss umgesetzt werden - Repository-Adapter für die Versuchshistorie implementieren. - Schreiben genau eines Versuchseintrags pro historisiertem dokumentbezogenem M4-Versuch umsetzen. - Lesefähigkeiten bereitstellen, soweit sie für M4-Use-Case und Tests benötigt werden. - Versuchsnummern pro Fingerprint reproduzierbar ableiten oder fortschreiben. - Sicherstellen, dass die Versuchsnummer: - bei **1** beginnt, - pro Fingerprint monoton steigt, - auch bei Skip-Versuchen mitgezählt wird. - M4-relevante Historisierungsdaten persistieren: - Fingerprint-Referenz - Lauf-ID - Versuchsnummer - Startzeitpunkt - Endzeitpunkt - Ergebnisstatus - Fehlerklasse - Fehlermeldung bzw. Begründung - Retryable-Flag - Sicherstellen, dass nur **identifizierte** Dokumente historisiert werden. - JavaDoc für Historisierungszweck, Versuchsnummernlogik und M4-Grenzen ergänzen. ### Explizit nicht Teil - Dokument-Stammsatz - fachliche Zählerlogik - Batch-Orchestrierung - KI-Rohantwort, Modellname oder Prompt-Identifikator - Zielname, Zielpfad oder Zielkopie ### Fertig wenn - pro historisiertem dokumentbezogenem Verarbeitungsvorgang ein separater Versuchseintrag gespeichert werden kann, - die Versuchsnummern pro Fingerprint reproduzierbar und monoton sind, - Skip-Versuche historisierbar sind, - Vor-Fingerprint-Fehler nicht fälschlich historisiert werden, - der Stand fehlerfrei buildbar bleibt. --- ## AP-006 M4-Entscheidungslogik und Batch-Integration für Idempotenz, Zähler und konsistente Persistenz umsetzen ### Voraussetzung AP-001 bis AP-005 sind abgeschlossen. ### Ziel Der bestehende M3-Verarbeitungslauf wird zu einem echten M4-Lauf erweitert, der Dokumente über Fingerprint wiedererkennt, Status und Zähler korrekt fortschreibt, Skip-Fälle historisiert und dabei keinen inkonsistenten Persistenzzustand hinterlässt. ### Muss umgesetzt werden - Den bestehenden Batch-Use-Case so erweitern, dass pro Verarbeitungskandidat verbindlich diese Reihenfolge gilt: 1. Fingerprint erzeugen 2. Dokument-Stammsatz laden 3. terminale Fälle entscheiden 4. gegebenenfalls bestehenden M3-Ablauf ausführen 5. Ergebnis in M4-Status, Zähler und Retryable-Flag überführen 6. Versuch historisieren 7. Dokument-Stammsatz fortschreiben - Folgende M4-Regeln explizit umsetzen: - vorhandener Gesamtstatus `SUCCESS` → Dokument wird nicht erneut fachlich verarbeitet, sondern mit `SKIPPED_ALREADY_PROCESSED` historisiert - vorhandener Gesamtstatus `FAILED_FINAL` → Dokument wird nicht erneut fachlich verarbeitet, sondern mit `SKIPPED_FINAL_FAILURE` historisiert - unbekanntes oder noch nicht terminales Dokument wird regulär weiterverarbeitet - M3-Ergebnisse exakt wie folgt in M4 überführen: - M3 erfolgreich abgeschlossen → `SUCCESS`, keine Fehlerzähler erhöhen, `retryable = false` - M3-Inhaltsfehler „kein brauchbarer Text“ oder „Seitenlimit überschritten“ beim ersten historisierten Auftreten → `FAILED_RETRYABLE`, Inhaltsfehlerzähler +1, `retryable = true` - derselbe Dokumenttyp eines bereits identifizierten Dokuments mit erneutem deterministischen Inhaltsfehler in einem späteren Lauf → `FAILED_FINAL`, Inhaltsfehlerzähler +1, `retryable = false` - dokumentbezogener technischer Fehler nach erfolgreicher Fingerprint-Ermittlung → `FAILED_RETRYABLE`, Transientfehlerzähler +1, `retryable = true` - Skip-Fälle so behandeln, dass: - ein eigener Versuchseintrag geschrieben wird, - kein Fehlerzähler verändert wird, - der Gesamtstatus des Stammsatzes terminal bestehen bleibt. - Vor-Fingerprint-Fehler ausdrücklich **nicht** als SQLite-Versuch historisieren. - Für identifizierte Dokumente sicherstellen, dass **Historie und Stammsatz konsistent** fortgeschrieben werden und keine inkonsistenten Teilzustände entstehen. - Falls eine dokumentbezogene Persistenzoperation technisch scheitert: - darf kein teilaktualisierter Zustand zurückbleiben, - bleibt der Batch-Lauf für andere Dokumente kontrolliert weiter lauffähig, - wird kein M5+-Verhalten vorweggenommen. - JavaDoc für Idempotenz, Zählerfortschreibung, Skip-Semantik und Persistenzkonsistenz ergänzen. ### Explizit nicht Teil - KI-Aufruf - Dateinamensbildung - Zielkopie - M5+-Retry-Regeln für KI- oder Zielkopiefehler - M5+-Persistenzfelder - spätere Reporting- oder Auswertungslogik ### Fertig wenn - der Batch-Lauf identische Inhalte über Fingerprint wiedererkennt, - `SUCCESS`- und `FAILED_FINAL`-Dokumente in späteren Läufen historisiert übersprungen werden, - die Minimalregel „erster deterministischer Inhaltsfehler retryable, zweiter final“ explizit umgesetzt ist, - technische dokumentbezogene Fehler nach Fingerprint als retryable behandelt werden, - Historie und Stammsatz pro identifiziertem Dokument konsistent fortgeschrieben werden, - weiterhin keine M5+-Funktionalität enthalten ist. --- ## AP-007 Bootstrap- und CLI-Anpassungen für SQLite-Konfiguration, Start-Initialisierung und M4-Verdrahtung durchführen ### Voraussetzung AP-001 bis AP-006 sind abgeschlossen. ### Ziel Der Programmeinstieg ist sauber an den M4-Lauf angepasst; die Persistenz wird beim Start initialisiert und die neuen M4-Bausteine sind vollständig verdrahtet. ### Muss umgesetzt werden - Bootstrap-Verdrahtung auf die neuen M4-Ports, Adapter und Persistenzbausteine erweitern. - M4-relevante Konfiguration ergänzen bzw. verdrahten, insbesondere für: - `sqlite.file` - Startvalidierung so ergänzen, dass mindestens geprüft wird: - SQLite-Dateipfad ist vorhanden oder technisch anlegbar - Persistenzkonfiguration ist nutzbar - Technische Schema-Initialisierung **beim Programmstart** ausführen, bevor der eigentliche Dokumentlauf beginnt. - CLI-/Batch-Startpfad auf den realen M4-Ablauf ausrichten. - Sicherstellen, dass harte Start-, Verdrahtungs- oder Initialisierungsfehler weiterhin zu **Exit-Code 1** führen. - Sicherstellen, dass dokumentbezogene Fehler im späteren Lauf **nicht** als Startfehler fehlmodelliert werden. - M1–M3-Grundverhalten erhalten und sauber mit den M4-Bausteinen kombinieren. - JavaDoc und `package-info` für aktualisierte Verdrahtung, Konfiguration und Modulgrenzen ergänzen. ### Explizit nicht Teil - neue Exit-Code-Semantik späterer Meilensteine - KI-Verdrahtung - Zielordner- oder Dateinamensverdrahtung - Logging-Feinschliff ### Fertig wenn - das Programm im M4-Stand vollständig startbar ist, - das SQLite-Schema beim Start kontrolliert initialisiert wird, - die neuen Adapter korrekt verdrahtet sind, - harte Persistenz-Startfehler kontrolliert zu Exit-Code 1 führen, - der Build fehlerfrei bleibt. --- ## AP-008 Tests für Fingerprint, SQLite-Repositories, M4-Statusfortschreibung, Historie und Skip-Logik vervollständigen ### Voraussetzung AP-001 bis AP-007 sind abgeschlossen. ### Ziel Der vollständige M4-Zielzustand wird automatisiert abgesichert und als konsistenter Übergabestand nachgewiesen. ### Muss umgesetzt werden - Unit-Tests für die SHA-256-Fingerprint-Erzeugung implementieren. - Repository-Tests gegen SQLite implementieren, insbesondere für: - Schema-Initialisierung - Anlegen und Lesen eines Dokument-Stammsatzes - Fortschreiben aller M4-Pflichtfelder des Stammsatzes - Anlegen und Lesen von Versuchshistorie - stabile Versuchsnummern pro Fingerprint - Tests für M4-Statusfortschreibung und Zähler ergänzen, insbesondere: - unbekanntes Dokument mit erfolgreichem M4-Ende wird als `SUCCESS` persistiert - erster deterministischer Inhaltsfehler führt zu `FAILED_RETRYABLE` - zweiter deterministischer Inhaltsfehler in einem späteren Lauf führt zu `FAILED_FINAL` - technischer dokumentbezogener Fehler nach erfolgreicher Fingerprint-Ermittlung erhöht den Transientfehlerzähler und bleibt `FAILED_RETRYABLE` - Skip-Fälle verändern keine Fehlerzähler - Tests für Idempotenz- und Skip-Logik ergänzen, insbesondere: - bereits erfolgreiches Dokument wird historisiert übersprungen - final fehlgeschlagenes Dokument wird historisiert übersprungen - gleicher Inhalt unter anderem Dateinamen wird über denselben Fingerprint erkannt - Tests ergänzen, die belegen: - pro identifiziertem dokumentbezogenem Verarbeitungsvorgang entsteht genau **ein** Historieneintrag - Skip-Ereignisse werden historisiert - Vor-Fingerprint-Fehler nicht in SQLite-Historie auftauchen - Tests für Bootstrap- und Startverhalten ergänzen, insbesondere: - Schema-Initialisierung beim Start - harter Persistenz-Startfehler führt zu Exit-Code 1 - Den M4-Stand abschließend auf Konsistenz, Architekturtreue und Nicht-Vorgriff auf M5+ prüfen. ### Explizit nicht Teil - Tests für KI, Prompt-Laden oder KI-JSON - Tests für Zielkopie oder Dateinamensbildung - Tests für M5+-Persistenzfelder - Tests für vollständige Retry-Logik späterer Meilensteine ### Fertig wenn - die Test-Suite für den M4-Umfang grün ist, - die wichtigsten M4-Randfälle automatisiert abgesichert sind, - der definierte M4-Zielzustand vollständig erreicht ist, - ein fehlerfreier, übergabefähiger Stand vorliegt. --- ## Abschlussbewertung Die Arbeitspakete decken den vollständigen M4-Zielumfang aus den verbindlichen Spezifikationen ab: - Fingerprint über SHA-256 - SQLite-Persistenz in zwei Ebenen - Dokument-Stammsatz mit M4-Minimalumfang - Versuchshistorie pro identifiziertem dokumentbezogenem Versuch - Idempotenz über Fingerprint - Skip-Regeln für bereits erfolgreiche und final fehlgeschlagene Dokumente - explizite Minimalregel für deterministische Inhaltsfehler in M4 - Tests für Fingerprint, Persistenz, Statusfortschreibung, Historie und Skip-Logik Gleichzeitig bleiben die Grenzen zu M1–M3 sowie zu M5+ gewahrt. Insbesondere werden **keine** KI-Funktionalitäten, **keine** Dateinamensbildung und **keine** Zielkopie vorweggenommen.