scripte/archivdms
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FDN-01: repository & projektgerüst

Browse Source 
Git-Repository für bestehenden archivdms-Code initialisiert, Branch-/Commit-Konvention (feature/<ticket>-<slug>-Branches, Ticket-Prefix in Commit-Nachricht) etabliert.
This commit is contained in:
patrick
2026-08-11 21:27:53 +02:00
parent 40ed80da71
commit 9a24ea29e1
274 changed files with 53708 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/agent-memory/archivdms-architect/project_ollama_integration_plan.md
+22
View File
@@ -0,0 +1,22 @@
---
name: project-ollama-integration-plan
description: Plan für lokale Ollama-Anbindung (Metadaten-Vorschläge + OCR-Textkorrektur) in archivdms, Stand 2026-07-16
metadata:
type: project
---
Plan verabschiedet für Ollama-Integration (kein Code, nur Architektur), Ziel: lokales LLM für (1) Metadaten-Vorschläge als dritter Provider neben heuristic/anthropic, (2) nachträgliche OCR-Textkorrektur.
Kernentscheidungen:
- Modell: `qwen2.5:1.5b-instruct-q4_K_M` (~1-1.2GB RAM), Eskalation auf 3B nur falls Qualität nicht reicht. Server hat nur 4GB RAM/4 Kerne/keine GPU.
- systemd-Hardening: MemoryMax=2200M, CPUQuota=250%, OOMScoreAdjust=500, bindet nur an 127.0.0.1:11434.
- OCR-Korrektur läuft NICHT automatisch im Upload-Pipeline (Ressourcenrisiko), sondern über manuellen Endpoint `POST /api/documents/{id}/correct-ocr-text`, analog zu bestehendem `/reprocess`-Muster.
- GoBD: Original-OCR-Text (`ocr_text`) wird nie überschrieben, Korrektur landet in neuem Feld `ocr_text_corrected`, Audit-Log-Pflicht pro Korrekturlauf.
- Provider-Fehlerverhalten: bei Ollama nicht erreichbar → Fehler an Frontend, KEIN stiller Fallback auf heuristic (Nachvollziehbarkeit, welcher Provider geantwortet hat).
- Config-Pattern: `llm.ollama.enabled/base_url/model/timeout_seconds` in config.yml, no-op wenn disabled — exakt wie `index.manticore_dsn`-Pattern.
- Pro-Tenant-Schalter bewusst NICHT gebaut (Tag 1) — Ollama läuft als ein Prozess pro Server, kein echtes Isolationsmodell dahinter, wäre nur Schein-Kontrolle. Erst bei echter Mandantentrennung mit unterschiedlichen Compliance-Anforderungen nachrüsten.
- Reihenfolge: 1) Ollama-Server-Setup (devops-deploy), 2) Metadaten-Provider (backend-dev), 3) OCR-Korrektur-Endpoint (baut auf Client aus Schritt 2 auf, plus Migration für ocr_text_corrected-Spalte).
**Why:** User hat sich bewusst für kleines lokales Modell trotz 4GB-RAM-Warnung entschieden (GoBD/Datenschutz — Belege dürfen Server nicht verlassen), Provider-Abstraktion (`metadata_suggestions.provider`-Spalte) existierte schon konzeptionell aus früherer Session, nur `heuristic` war je gebaut.
**How to apply:** Wenn Umsetzung (backend-dev/devops-deploy) ansteht, diesen Plan als Grundlage nehmen, nicht neu verhandeln, außer der User ändert explizit etwas. Verwandt: [[project_archivdms_status]], [[project_nil_slice_json_pattern]].