docs(PROJ-35): Status auf Deployed + Bekannte Pitfalls dokumentiert

- 132 + 131 deployed
- hashMailID-Bit-Mask-Fix dokumentiert (negative IDs Problem)
- OCR-Tempo-Constraint (CPU-bound) erklärt
- Boot-Resume-Loop als bekannter, unkritischer Bug vermerkt

features/INDEX.md

@@ -51,7 +51,7 @@
 | PROJ-33 | IMAP-Modus: Gemeinsames Archiv vs. Persönlicher Posteingang | Deployed | [PROJ-33](PROJ-33-imap-modus-shared-personal.md) | 2026-03-31 |
 | PROJ-34 | Retention-Policy + Löschsperre (GoBD-Compliance) | Deployed | [PROJ-34](PROJ-34-retention-policy.md) | 2026-03-31 |
 
-| PROJ-35 | OCR & Anhang-Volltext-Indexierung | In Progress | [PROJ-35](PROJ-35-ocr-anhang-volltext.md) | 2026-04-04 |
+| PROJ-35 | OCR & Anhang-Volltext-Indexierung | Deployed | [PROJ-35](PROJ-35-ocr-anhang-volltext.md) | 2026-04-04 |
 | PROJ-36 | gzip-Kompression + storage_objects-Tabelle | Deployed | [PROJ-36](PROJ-36-compression-storage-objects.md) | 2026-04-05 |
 | PROJ-37 | Attachment-Deduplication (Hash-basiert) | Deployed | [PROJ-37](PROJ-37-attachment-deduplication.md) | 2026-04-05 |
 | PROJ-38 | Mail-Threading (In-Reply-To / References) | Deployed | [PROJ-38](PROJ-38-mail-threading.md) | 2026-04-05 |

features/PROJ-35-ocr-anhang-volltext.md

@@ -1,8 +1,9 @@
 # PROJ-35: OCR & Anhang-Volltext-Indexierung
 
-## Status: In Progress
+## Status: Deployed
 **Created:** 2026-04-04
 **Last Updated:** 2026-05-08
+**Deployed:** 2026-05-08 (192.168.1.131 + 192.168.1.132)
 
 ## Dependencies
 - Requires: PROJ-5 (Speicherung & Indexierung) — Mailparser + Manticore-Index
@@ -187,35 +188,51 @@ _Vollständig oben beschrieben_
 ## Bekannte Pitfalls
 
 1. **systemd-Tempdir-Restriktion** (Commit `6d835ae`): Beim ersten Run wurden 19.043 Mails fälschlich auf `failed` markiert, weil `os.MkdirTemp("")` in einer Unit-internen Sandbox lag. Fix: `SetTempDir(<storage_dir>/ocr-tmp)`.
-2. **`hashMailID` muss konsistent zu IndexSync sein**: `UpdateAttachmentText` muss exakt dasselbe Bit-Muster nutzen wie `IndexSync`, sonst werden neue Rows angelegt statt überschrieben. Der int64-Cast wird vom MySQL-Treiber sauber serialisiert.
+2. **`hashMailID` darf nicht negativ sein** (Commits `7ba677e` + `d71d20d`): Manticore RT erlaubt nur positive int64-IDs. Initial-Implementierung nutzte uint64 → Treiber meldete „number out of range". Erster Fix-Versuch mit `int64(h.Sum64())` produzierte negative Werte für die obere uint64-Hälfte → Manticore wies INSERT/REPLACE ab („Negative document ids are not allowed"). Finaler Fix: Bit-Mask `0x7FFFFFFFFFFFFFFF` zwingt das Top-Bit auf 0, Result garantiert in `[0, 2^63-1]`.
 3. **Sehr große PDFs (>50 MiB)** werden über `MaxAttachmentSize` übersprungen → Status `skipped`, Mail bleibt per Metadaten auffindbar.
 4. **Passwort-geschützte PDFs**: `pdftotext` liefert `Incorrect password` → `ErrEncrypted` → Status `skipped`.
+5. **OCR-Tempo ist CPU-gebunden**: Auf 192.168.1.132 (2 GB RAM, 2 vCPU) schafft tesseract bei 2 Worker-Goroutinen ~3–7 OCR-Events/Min — hauptsächlich durch große Smartphone-JPGs (45+ s pro Datei) und mehrseitige PDFs. Ein vollständiger Reprocess von 15.000 Mails dauert dort ~1–2 Tage. Auf stärkeren Servern entsprechend weniger. Mehr Worker-Goroutinen bringen nichts solange CPU bei 100 % steht.
+6. **Boot-Resume-Loop bei großen Backlogs**: Wenn beim Start sehr viele Mails `pending` sind, kann derselbe Batch mehrfach via `GetPendingOCRMails` geholt und re-enqueued werden, weil der Worker den Status erst nach Verarbeitung setzt. Submit ist non-blocking (Drop bei voller Queue), funktional unkritisch — aber DB-Last und Log-Rauschen. Mitigation: kleines `seen`-Set im Boot-Resume oder Status-Vorsetzung auf `processing` beim Submit. Nicht behoben in 0.x — siehe Folgearbeit.
 
 ## QA Test Results
 
-### Test-Server 192.168.1.132 (Stand 2026-05-08)
+### Test-Server 192.168.1.132
+
+Nach Bit-Mask-Fix-Deploy + TRUNCATE + frischem Reindex:
 
 ```
-ocr_status | count
-done       |     92
-failed     |     96
-pending    | 13.603  ← reprocess läuft
-skipped    | 1.227
+reindex: complete  total=15.191  indexed=15.191  errors=0
 ```
 
-- `DESC emails_global` enthält `attachment_text text indexed stored` ✓
-- `archivmail ocr-reprocess --status failed` reaktiviert die `failed`-Marker korrekt
-- Service-Stack (manticore + archivmail + archivmail-web) durchgehend `active`
+OCR-Suche live verifiziert (Beispiel):
+```sql
+SELECT mail_id, attachment_text
+FROM emails_tenant_1
+WHERE MATCH('@attachment_text rechnung')
+LIMIT 3;
+-- 3 Treffer: Cleverbridge-Rechnungen mit IBAN/Beträgen vollständig indexiert
+```
+
+OCR-Reprocess läuft im Hintergrund weiter (~5 Events/Min, ~1–2 Tage Gesamtlaufzeit).
 
 ### Produktions-Server 192.168.1.131
-**Noch nicht deployed.** Anstehend nach Abschluss des 132-Recoverys.
+
+```
+reindex: complete  total=86  indexed=86  errors=0
+ocr worker: started workers=2 queue=1000
+```
+
+- DESC `emails_global` enthält `attachment_text text indexed stored` ✓
+- PostgreSQL `emails.ocr_status` Spalte vorhanden ✓
+- 86 Mails alle `skipped` (kein Anhang) — korrektes Verhalten ✓
+- Service-Stack (`manticore` + `archivmail` + `archivmail-web`) durchgehend `active`
 
 ## Deployment
 
 | Server | Datum | Status |
 |---|---|---|
-| 192.168.1.132 (Test) | 2026-05-08 | Deployed, Recovery läuft (~13.600 Mails im Reprocess) |
-| 192.168.1.131 (Prod) | _ausstehend_ | Wartet auf grünes 132 |
+| 192.168.1.132 (Test) | 2026-05-08 | Deployed — Reindex grün, OCR-Reprocess läuft im Hintergrund (~5/min, mehrere Tage Gesamtlaufzeit) |
+| 192.168.1.131 (Prod) | 2026-05-08 | Deployed — 86 Mails reindexiert, alle ohne Anhang → `skipped` |
 
 ### Pre-Deployment-Schritte (auf Server)