Git-Repository für bestehenden archivdms-Code initialisiert, Branch-/Commit-Konvention (feature/<ticket>-<slug>-Branches, Ticket-Prefix in Commit-Nachricht) etabliert.
4.2 KiB
4.2 KiB
archivdms — Featureliste + System-Prompt (Synthese Paperless-ngx + ecoDMS + Marktstandards)
Kern-Diff zu Paperless-ngx und ecoDMS
- Echte Multi-Tenancy (Paperless fehlt, ecoDMS nur Concurrent-Lizenz-Modell)
- Moderne API-first Architektur mit Webhooks (beide fehlen komplett)
- GoBD/E-Rechnung nativ statt nachgerüstet (ZUGFeRD/XRechnung Pflicht seit 2025)
- Go-Performance statt Django/Java (schnellere Ingestion, geringerer RAM)
- Hybrid-Suche BM25+Vektor via Manticore statt reiner Keyword-Suche
Featureliste
Ingestion
- Consume-Ordner + Mail-Postfach-Import (IMAP-Poll) + Scan-Client (TWAIN/Netzwerk-MFP)
- Barcode/QR-Split + ASN (Archive Serial Number)
- Office/E-Mail zu PDF/A Konvertierung (Gotenberg-Äquivalent)
- OCR Multi-Sprache (Tesseract)
- ZUGFeRD/XRechnung Parser: strukturierte Felder direkt extrahieren + validieren
Klassifizierung
- Tags, Korrespondenten, Dokumenttypen, Custom Fields (typisiert: text/date/money/bool/select/link)
- ML Auto-Tagging (lernt aus bestätigten Docs) + optional LLM-Extraktion für Freitext-Felder
- Workflow-Engine: Trigger (Consumption/Schedule/Manual) + Action-Kette, State-Machine (Draft→Review→Approved→Archiviert)
- Storage-Path-Templates (Jinja/Go-Template) für Ablagestruktur
Compliance (GoBD/DSGVO/eIDAS)
- WORM-Flag pro Dokument, Hash-Chain Audit-Trail (unveränderlich, selbst archiviert)
- Aufbewahrungsfristen-Engine (8-10 Jahre automatisch, Löschsperre vs. DSGVO-Löschanspruch-Konflikt lösbar)
- Mandantentrennung: Row-Level-Security PostgreSQL, pro Tenant eigener Storage-Pfad/Verschlüsselung
- E-Signatur-Integration (QES via externem Anbieter, Zertifikatsprüfung)
- Verfahrensdokumentation-Export (Compliance-Nachweis generierbar)
Suche
- Hybrid: Manticore BM25 + Vektor-KNN (Embeddings), semantische Anfrage möglich
- Autocomplete, "more like this", gespeicherte Suchen/Views
API / Integration
- REST + Webhooks (Event: created/updated/signed/deleted) — Kernlücke bei beiden Vorbildern schließen
- OpenAPI-Schema, Token/OIDC/SSO/LDAP Auth
- DATEV-Schnittstelle (developer.datev.de), ERP-Connectoren
- Bulk-Edit-Endpunkte (Tags/Type/Path/Permissions/Merge/Split)
- Public Share-Links mit Ablaufdatum, Login-Enforcement-Toggle, Multi-Doc-Share (Paperless-Lücke schließen)
Berechtigungen
- RBAC granular bis Dokument-Ebene + Gruppen, Feld-Level-Security für Custom Fields
- Owner/View/Change Permission-Modell + Tenant-Scope
UX
- Moderne SPA (React/Vue/Svelte), Mobile-first PWA
- Drag&Drop Batch-Upload, Inline-Preview (PDF/Bild/Office)
- Kanban-Board für Wiedervorlage/Freigabe-Status
- Dashboard mit Saved Views/Widgets
Architektur (bereits gesetzt)
- Go Backend (API-first, hohe Concurrency für Multi-Tenant)
- PostgreSQL (RLS für Tenant-Isolation, Append-only Audit-Tabellen)
- Manticore Search (RT-Index + Vector-Suche, kein Extra-Vektor-DB nötig)
System-Prompt-Entwurf (für Entwicklung/Claude-Session)
Du entwickelst archivdms, ein GoBD-konformes Dokumentenmanagementsystem für den DACH-Raum.
Stack: Go-Backend (API-first), PostgreSQL (Row-Level-Security für Mandantentrennung),
Manticore Search (Hybrid BM25+Vektor).
Differenzierung ggü. Paperless-ngx (OSS, aber keine Multi-Tenancy, keine Webhooks,
schwache Versionierung/Sharing) und ecoDMS (Java/Docker, GoBD-stark, aber veraltete UI,
gedeckelte API-Connects, schwache Workflow-Engine):
Pflichtfeatures:
1. Echte Multi-Tenancy mit PostgreSQL RLS
2. REST-API mit Webhooks für alle Dokument-Events
3. GoBD: WORM-Flag, Hash-Chain Audit-Trail, Aufbewahrungsfristen-Engine, Verfahrensdoku-Export
4. E-Rechnung: ZUGFeRD 2.0.1+/XRechnung Parser + Validierung (Pflicht seit 2025)
5. Hybrid-Suche (Manticore BM25 + Vektor-KNN)
6. Workflow-Engine mit State-Machine (Trigger+Actions, nicht nur einfache Freigabe)
7. Granulare RBAC bis Dokument-/Feld-Ebene
8. OIDC/SSO/LDAP, DATEV-Schnittstelle
9. Moderne responsive SPA, Kanban-Wiedervorlage, Inline-Preview
Nicht bauen: eigene E-Signatur-Engine (nur Integration), eigenes Konvertierungs-Backend
für Nischenformate (auf Standardlib/Sidecar setzen wie Gotenberg-Äquivalent).
Bei jeder Feature-Entscheidung: GoBD-Konformität und Mandantentrennung haben Vorrang
vor UX-Komfort. API-Design zuerst, UI konsumiert eigene API.