1
0

CLAUDE.md für M7 angepasst

This commit is contained in:
2026-04-07 14:24:19 +02:00
parent 7e4193a173
commit ffd91c766d

129
CLAUDE.md
View File

@@ -85,26 +85,27 @@ Wenn Dokumente fehlen, unklar sind oder sich widersprechen, nicht raten und kein
## Aktiver Implementierungsstand
M1 bis M5 sind vollständig abgeschlossen. Der aktive Stand ergänzt den vollständigen
Erfolgspfad: korrekt benannte Zielkopie erzeugen und Enderfolg konsistent persistieren.
M1 bis M6 sind vollständig abgeschlossen. Der aktive Stand schließt die betriebliche
Lücke zwischen dem M6-Erfolgspfad und dem final robusten Endstand.
### Baseline aus M5
- Externer Prompt-Bezug über konfigurierbare Prompt-Datei
- OpenAI-kompatibler HTTP-Adapter vollständig verdrahtet
- Validierte KI-Antwort mit `date`, `title`, `reasoning`
- Persistierter Benennungsvorschlag mit Status `PROPOSAL_READY`
- Versuchshistorie mit KI-Nachvollziehbarkeit (Modell, Prompt-ID, Zeichenzahl, Rohantwort, Reasoning, Datum, Datumsquelle)
- Idempotente Migration M4 → M5
### Ziel des aktiven Stands
### Baseline aus M6
- Technische Dateinamensbildung im Format `YYYY-MM-DD - Titel.pdf`
- Dublettenbehandlung im Zielordner: `(1)`, `(2)`, …
- Physische Zielkopie via temporäre Datei und finalem Move/Rename
- Schemaevolution auf den aktiven Stand (Zielpfad, Zieldateiname)
- Schemaevolution M5 → M6 (Zielpfad, Zieldateiname in Stammsatz und Versuchshistorie)
- Statustransition `PROPOSAL_READY``SUCCESS`
- Zusätzliche Historisierung für Enderfolg und technische Fehler (Proposal-Versuch bleibt erhalten)
- Zusätzliche Historisierung für Enderfolg und technische Fehler
- Startvalidierung für Zielordner-Konfiguration (`target.folder`)
### Ziel des aktiven Stands
- Vollständige laufübergreifende Retry-Logik für deterministische Inhaltsfehler und transiente technische Fehler
- Technischer Sofort-Wiederholversuch ausschließlich für Zielkopierfehler (genau ein zusätzlicher Versuch im selben Lauf)
- Finalisierung ausgeschöpfter Retry-Rahmen zu `FAILED_FINAL`
- Vollständige Skip-Semantik: `SUCCESS` und `FAILED_FINAL` werden historisiert übersprungen
- Logging-Mindestumfang des Endstands vollständig angebunden
- Sensibilitätsregel für KI-Inhalte im Logging
- Vervollständigte Startvalidierung und finale Exit-Code-Semantik
## Statussemantik
| Status | Bedeutung |
@@ -131,45 +132,103 @@ Erfolgspfad: korrekt benannte Zielkopie erzeugen und Enderfolg konsistent persis
- Proposal-Versuch mit fachlich unbrauchbarem Titel oder Datum = inkonsistenter Persistenzzustand = dokumentbezogener technischer Fehler.
- Inkonsistente Proposal-Zustände werden **nicht stillschweigend geheilt**, sondern als technische Dokumentfehler behandelt.
## Retry-Semantik (aktiver Stand)
### Deterministische Inhaltsfehler
Deterministische Inhaltsfehler sind insbesondere:
- kein brauchbarer Text
- Seitenlimit überschritten
- fachlich unbrauchbarer oder generischer Titel
- vorhandenes, aber unbrauchbares KI-Datum
Regel:
- **erster** historisierter deterministischer Inhaltsfehler → `FAILED_RETRYABLE`
- **zweiter** historisierter deterministischer Inhaltsfehler → `FAILED_FINAL`
### Transiente technische Fehler
- Transiente Fehler laufen über den Transientfehlerzähler im Dokument-Stammsatz.
- Sie bleiben retryable bis der konfigurierte Grenzwert `max.retries.transient` erreicht ist.
- Der Fehlversuch, der den Grenzwert **erreicht**, finalisiert den Dokumentstatus zu `FAILED_FINAL`.
- `max.retries.transient` = **Integer >= 1**; der Wert `0` ist ungültige Startkonfiguration.
- Beispiel: `max.retries.transient = 1` → erster transiente Fehlversuch finalisiert sofort.
### Technischer Sofort-Wiederholversuch
- **Genau ein** zusätzlicher technischer Schreibversuch innerhalb desselben Dokumentlaufs.
- **Ausschließlich** für Fehler beim physischen Zielkopierpfad.
- Kein erneuter KI-Aufruf, keine erneute Fachableitung.
- Zählt **nicht** zum laufübergreifenden Transientfehlerzähler.
- Liefert genau ein dokumentbezogenes Ergebnis für Persistenz und Statusfortschreibung.
### Skip-Semantik
- `SUCCESS` → in späteren Läufen `SKIPPED_ALREADY_PROCESSED` historisieren, keine Zähleränderung.
- `FAILED_FINAL` → in späteren Läufen `SKIPPED_FINAL_FAILURE` historisieren, keine Zähleränderung.
- `FAILED_RETRYABLE`, `READY_FOR_AI`, `PROPOSAL_READY` → verarbeitbar.
## Logging-Mindestumfang (aktiver Stand)
Folgende Informationen müssen nachvollziehbar geloggt werden:
- Laufstart mit Lauf-ID
- Laufende
- erkannte Quelldatei
- Überspringen bereits erfolgreicher Dateien
- Überspringen final fehlgeschlagener Dateien
- erzeugter Zielname
- Retry-Entscheidung
- Fehler mit Klassifikation
### Korrelationsregel
- Vor erfolgreicher Fingerprint-Ermittlung: Korrelation über Lauf-ID und Kandidatenbezug.
- Nach erfolgreicher Fingerprint-Ermittlung: dokumentbezogene Logs enthalten den Fingerprint oder eine eindeutig ableitbare Referenz.
- Keine neue Persistenz-Wahrheit oder zusätzliche Tracking-Ebene.
### Sensibilitätsregel für KI-Inhalte
- Vollständige KI-Rohantwort: standardmäßig **nicht** ins Log, bleibt in SQLite.
- Vollständiges KI-`reasoning`: standardmäßig **nicht** ins Log, bleibt in SQLite.
- Freischaltung nur über expliziten booleschen Konfigurationswert.
- Default: sicher / nicht loggen.
## Verarbeitungsreihenfolge pro Dokument (aktiver Stand)
1. Fingerprint berechnen
2. Dokument-Stammsatz laden
3. Terminale Skip-Fälle entscheiden (`SUCCESS``SKIPPED_ALREADY_PROCESSED`, `FAILED_FINAL``SKIPPED_FINAL_FAILURE`)
4. Falls nötig: M5-Pfad bis `PROPOSAL_READY` durchlaufen
4. Falls nötig: Pfad bis `PROPOSAL_READY` durchlaufen (inkl. KI-Aufruf)
5. Führenden `PROPOSAL_READY`-Versuch laden
6. Finalen Basis-Dateinamen bilden
7. Dubletten-Suffix im Zielordner bestimmen
8. Zielkopie schreiben (temporäre Datei + finaler Move/Rename)
9. Neuen Versuch für Enderfolg oder technischen Fehler historisieren
10. Dokument-Stammsatz konsistent fortschreiben
8. Zielkopie schreiben (temporäre Datei + finaler Move/Rename; bei Fehler: genau ein Sofort-Wiederholversuch)
9. Retry-Entscheidung ableiten
10. Neuen Versuch historisieren, Stammsatz konsistent fortschreiben
## Zielkopie-Semantik
- Kopie zunächst in temporäre Zieldatei im Zielkontext
- Finaler Move/Rename auf den geplanten Zieldateinamen
- Quelldatei bleibt **immer unverändert**
- Kein Sofort-Wiederholversuch im selben Lauf
- Bei Persistenzfehler nach erfolgreicher Zielkopie: kein `SUCCESS` setzen, best-effort Rückbau der Zielkopie vorsehen, Ergebnis bleibt dokumentbezogener technischer Fehler
- Bei technischem Schreibfehler: genau ein Sofort-Wiederholversuch (nur Zielkopierpfad)
- Bei Persistenzfehler nach erfolgreicher Zielkopie: kein `SUCCESS` setzen, best-effort Rückbau der Zielkopie, Ergebnis bleibt dokumentbezogener technischer Fehler
## Fehlersemantik (aktiver Stand)
Technische Fehler bei Proposal-Quelllesung, Zielpfadbildung, Dublettenauflösung,
Zielkopie oder aktiver Persistenz nach Fingerprint-Ermittlung:
- → dokumentbezogener technischer Fehler
- `FAILED_RETRYABLE`, Transientfehlerzähler +1
- → kein Abbruch des Batch-Laufs für andere Dokumente
- → keine neue finale Fehlerkategorie
- Technische Fehler `FAILED_RETRYABLE`, Transientfehlerzähler +1
- Bei Erreichen von `max.retries.transient``FAILED_FINAL`
- Kein Abbruch des Batch-Laufs für andere Dokumente
- Keine neue finale Fehlerkategorie
- Vor-Fingerprint-Fehler werden **nicht** als SQLite-Versuch historisiert
## Persistenzerweiterung (aktiver Stand)
## Persistenz (aktiver Stand)
**Dokument-Stammsatz** erhält zusätzlich:
- letzten Zielpfad
- letzten Zieldateinamen
Zwei-Ebenen-Modell bleibt unverändert keine dritte Wahrheitsquelle.
**Versuchshistorie** erhält zusätzlich:
**Dokument-Stammsatz** enthält u.a.:
- letzten Zielpfad, letzten Zieldateinamen
- Inhaltsfehler- und Transientfehlerzähler
- Gesamtstatus
**Versuchshistorie** enthält u.a.:
- finalen Zieldateinamen
- Fehlerklasse, Fehlermeldung, Retryable-Flag
**Invariante:** Der führende `PROPOSAL_READY`-Versuch wird nicht überschrieben.
Enderfolg und technische Fehler des aktiven Stands werden als **zusätzliche neue Versuche** historisiert.
Jeder Lauf erzeugt einen **zusätzlichen** neuen Versuchseintrag.
## Naming-Regel (verbindlich für alle Arbeitspakete)
In Implementierungen, Kommentaren und JavaDoc dürfen **keine** Meilenstein- oder
@@ -236,10 +295,11 @@ Verbindlich zweckmäßige Parameter:
- `api.baseUrl` KI-Basis-URL
- `api.model` Modellname
- `api.timeoutSeconds` Timeout
- `max.retries.transient` maximale transiente Wiederholversuche
- `max.retries.transient` max. historisierte transiente Fehlversuche pro Fingerprint (**Integer >= 1**, `0` ist ungültig)
- `max.pages` Seitenlimit
- `max.text.characters` maximale Zeichenzahl für KI-Eingabe
- `prompt.template.file` externe Prompt-Datei
- `log.ai.sensitive` sensible KI-Logausgabe freischalten (Boolean, Default: `false`)
- `runtime.lock.file` Lock-Datei (optional)
- `log.directory` Log-Verzeichnis (optional)
- `api.key` API-Key (Umgebungsvariable hat Vorrang)
@@ -254,6 +314,7 @@ Verbindlich zweckmäßige Parameter:
- keine Architekturbrüche
- keine neuen Bibliotheken oder Frameworks ohne klare Notwendigkeit und Begründung
- keine stillen Änderungen an Provider-Bindung oder Architekturprinzipien
- kein Sofort-Wiederholversuch der Zielkopie im selben Lauf
- kein Logging-Feinschliff des Endstands
- kein Sofort-Wiederholversuch außerhalb des Zielkopierpfads
- keine Reporting- oder Statistikfunktionen
- keine neue dritte Persistenz-Wahrheitsquelle für Retry-Entscheidungen
- kein M8-Gesamtfeinschliff oder großflächiges Refactoring