Spracherkennung für OCR-Texte und Qualitätsbewertung (Konfidenzwert), um
schlechte OCR-Ergebnisse kenntlich zu machen. Letztes Ticket vor QA-03.
- ocr/language.go: RecognizeWithLanguageAndConfidence erkennt ein Bild
einzeln je Kandidatensprache (deu/eng) im Tesseract-TSV-Modus — die
Sprache mit höherem Konfidenzwert gewinnt, derselbe Lauf liefert den
Konfidenzwert direkt mit.
- search: neue Felder ocr_language/ocr_confidence (Migrationen 0006/0007,
gleiches ALTER-Muster wie SRC-05), in Document/Result gespiegelt.
Client.AttachmentsBelowConfidence filtert gezielt auf niedrige
Konfidenz, schließt Dokumente ohne OCR-Anhang aus.
- Regressionsbug gefunden und behoben: reindex.go (SRC-09) kannte die
neuen OCR-Spalten nicht, Reindex wäre mit "unknown column"
fehlgeschlagen.
Prüfungen (alle real durchgeführt, siehe mail/docs/SRC-10-PRUEFPROTOKOLL.md):
1. TestRecognizeWithLanguageAndConfidence_MultilingualCorpus: deutsches
und englisches Testbild real korrekt als deu/eng erkannt.
2. TestRecognizeWithLanguageAndConfidence_DegradedImageLowersConfidence:
künstliche Verschlechterung senkt Konfidenz real von 91,76 auf 28,21.
3. TestAttachmentsBelowConfidence_QueryReturnsExpectedResults: Abfrage
unterhalb Schwelle liefert real genau die erwarteten 2 von 4 Treffern.
Kein Umbau: Search/Facets/SearchWithFilters/Index/Delete-Verhalten sonst
unverändert, dedup/indexworker/storage/crypto/encstorage/savedsearch
unverändert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
Werkzeug für vollständigen Suchindex-Neuaufbau: neue Tabelle anlegen,
Dokumente aus der lebenden Tabelle kopieren, Trefferzahlen verifizieren,
erst dann per Manticore RENAME atomar umschalten.
- reindex.go: Reindexer.Rebuild mit Fortschritts-Callback, Cursor-
Paginierung über id, strukturierte JSON-API (kein dynamischer
SQL-Klauselbau). Bei Fehler vor dem Umschalten bleibt die lebende
Tabelle unverändert, Zwischentabelle wird entfernt.
- Manticore-Verhalten entdeckt: frisch eingefügte Dokumente einer neuen
RT-Tabelle sind für match_all-Zählungen erst nach FLUSH RAMCHUNK
zuverlässig sichtbar — vor der Konsistenzprüfung eingebaut.
- Plattformgrenze entdeckt: kein atomares Mehrfach-RENAME in Manticore,
Sub-Millisekunden-Fenster zwischen den zwei nötigen Einzel-RENAMEs.
Client.Search bekam einen begrenzten Retry auf "unknown local table".
- Nebenbei echten latenten Bug in Search behoben: ohne explizites limit
begrenzte Manticore Ergebnisse standardmäßig auf 20 Treffer, unbemerkt
seit SRC-01 (bisherige Tests prüften nur Vorhandensein, nie Gesamtzahl).
Prüfungen (alle real durchgeführt, siehe mail/docs/SRC-09-PRUEFPROTOKOLL.md):
1. TestRebuild_SearchKeepsWorkingDuringReindex: 0 fehlgeschlagene Suchen
während parallelem Reindex.
2. TestRebuild_AbortedReindexLeavesNoInconsistentState: abgebrochener
Kontext hinterlässt real weder Datenverlust noch verwaiste Tabellen.
3. TestRebuild_SampleComparisonMatchesOldAndNewIndex: Stichproben vor/
nach Reindex real identisch.
Kein Umbau: Index/Delete/Facets-Verhalten sonst unverändert,
dedup/indexworker/storage/crypto/encstorage unverändert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
