Merge PR #338: dms-kanban: Board nach Gitea main nachliefern
CI / Web-Barrierefreiheitspruefung (axe, Tastatur, Reflow, Textabstaende) (push) Canceled after 0s
CI / Core-Modul (Build/Vet/Test) (push) Canceled after 0s
CI / DMS Security-Test-Gate (AC5, Merge-Gate) (push) Canceled after 0s
CI / Connect Security-Test-Gate (QA-01 AC4, Merge-Gate) (push) Canceled after 0s
CI / DMS-Modul Supply-Chain-Scan (govulncheck) (push) Canceled after 0s
CI / Web (dms-browser) (push) Canceled after 0s
CI / Web (pdf-viewer) (push) Canceled after 0s
CI / Web (shl) (push) Canceled after 0s
CI / DMS-Modul (Lint/Build/Test/Coverage/Artefakt) (push) Canceled after 0s
CI / Web-Barrierefreiheitspruefung (axe, Tastatur, Reflow, Textabstaende) (push) Canceled after 0s
CI / Core-Modul (Build/Vet/Test) (push) Canceled after 0s
CI / DMS Security-Test-Gate (AC5, Merge-Gate) (push) Canceled after 0s
CI / Connect Security-Test-Gate (QA-01 AC4, Merge-Gate) (push) Canceled after 0s
CI / DMS-Modul Supply-Chain-Scan (govulncheck) (push) Canceled after 0s
CI / Web (dms-browser) (push) Canceled after 0s
CI / Web (pdf-viewer) (push) Canceled after 0s
CI / Web (shl) (push) Canceled after 0s
CI / DMS-Modul (Lint/Build/Test/Coverage/Artefakt) (push) Canceled after 0s
This commit is contained in:
patrick committed
commit
8e3c1e4eee
130 files changed
+12257
No files matched your search
@@ -0,0 +1,475 @@
|
||||
# dms-kanban – Dev Log
|
||||
|
||||
## 2026-08-25 23:00 – 23:00 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:25 – 23:26 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** repos
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:27 – 23:28 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:29 – 23:30 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:32 – 23:32 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:33 – 23:35 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:36 – 23:36 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:36 – 23:37 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:37 – 23:37 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:38 – 23:38 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:38 – 23:38 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:39 – 23:40 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:41 – 23:42 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:42 – 23:42 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:49 – 23:51 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:53 – 23:53 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-25 23:54 – 00:00 (6m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 00:46 – 00:47 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** core-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 00:48 – 00:54 (6m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 01:10 – 01:17 (6m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 01:24 – 01:24 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 09:27 – 09:27 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 09:42 – 09:42 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 10:50 – 10:52 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 10:57 – 10:58 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 12:35 – 12:40 (4m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** mail-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 12:41 – 12:41 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 12:43 – 12:43 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 14:27 – 14:30 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 15:08 – 15:11 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 15:17 – 15:17 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 15:17 – 15:18 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 15:18 – 15:18 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 15:19 – 15:20 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 15:27 – 15:28 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 15:29 – 15:30 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-26 15:31 – 15:32 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-08-29 20:27 – 20:27 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-10-15 22:54 – 23:22 (27m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-10-15 23:51 – 23:51 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-10-15 23:53 – 23:53 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-10-15 23:56 – 23:56 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-10-16 00:02 – 00:02 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** dms-kanban
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
@@ -0,0 +1,113 @@
|
||||
# DMS-Kanban – lokal abarbeiten
|
||||
|
||||
81 Arbeitskacheln · 8 Epics · 230 Personentage · 13 Wellen (inkl. Welle 12: Threat-Model-Nachtrag 2026-09-12 — INT-14, INT-15, INT-16, DOC-17, FDN-10, FDN-11, VER-08; Welle 13: DOC-18, ergänzt 2026-09-14, siehe SICHERHEITSKONZEPT.md Abschnitt 14 Finding #9).
|
||||
|
||||
Hinweis: Identität, Rechte, Mandantenverwaltung und Authentifizierung sind ausgelagert in NEXARCH Core (siehe ../core-kanban/) — dieses Board enthält dafür keine eigenen Tickets mehr, nur externe Verweise in der Ausgangslage betroffener Kacheln.
|
||||
|
||||
Hinweis: UI-Shell & Design-System ist ausgelagert in NEXARCH Core (siehe ../core-kanban/, SHL-01) — dieses Board hat dafür kein eigenes Ticket mehr, nur externe Verweise in den betroffenen Oberflächen-Tickets.
|
||||
|
||||
Hinweis: REST-API-Grundgerüst, Rate-Limiting, OpenAPI-Tooling und Webhook-Zustellung sind ausgelagert in NEXARCH Core (siehe ../core-kanban/, API-01/03/04/07) — dieses Board definiert nur noch die modul-eigenen Endpunkte.
|
||||
Hinweis: Aufbewahrung, WORM, Compliance-Berichte und Backup sind ausgelagert in NEXARCH Archive (siehe ../archive-kanban/) — dieses Board enthält dafür keine eigenen Tickets mehr.
|
||||
Hinweis: Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing sind ausgelagert in NEXARCH Workflow (siehe ../workflow-kanban/), Benachrichtigungsversand in NEXARCH Core (siehe ../core-kanban/) — dieses Board enthält dafür keine eigenen Tickets mehr.
|
||||
Hinweis: KI-Funktionen (Klassifizierung, Extraktion, Zusammenfassung, semantische Suche) sind ausgelagert in NEXARCH AI (siehe ../ai-kanban/), optional aktivierbar — dieses Board enthält dafür keine eigenen Tickets mehr.
|
||||
Stand: 2026-08-26
|
||||
|
||||
## Weg 1 – Sofort loslegen (empfohlen)
|
||||
|
||||
`kanban.html` per Doppelklick im Browser öffnen. Kein Server, kein Internet, keine Installation.
|
||||
|
||||
- Kacheln per Drag & Drop zwischen Backlog → Bereit → In Arbeit → Prüfung → Fertig ziehen
|
||||
- Der Stand wird im Browser gespeichert (localStorage) und bleibt nach dem Schließen erhalten
|
||||
- Filter nach Epic, Rolle, Welle, Volltext sowie „Nur startbare“ (alle Vorgänger auf Fertig)
|
||||
- Klick auf eine Kachel öffnet Details inkl. vollem Bau-Prompt und „Prompt kopieren“
|
||||
- „Stand sichern“ exportiert den aktuellen Status als CSV
|
||||
|
||||
Hinweis: Der Stand hängt an Browser und Profil. Für Teamarbeit Weg 2 oder 3 nutzen.
|
||||
|
||||
## Weg 2 – Import in ein vorhandenes Werkzeug
|
||||
|
||||
`board.csv` (UTF-8 mit BOM, Komma-getrennt) importieren:
|
||||
|
||||
| Werkzeug | Weg |
|
||||
| --- | --- |
|
||||
| Trello | Board → Menü → Mehr → CSV importieren (Power-Up) |
|
||||
| Jira | Einstellungen → System → Externes Importieren → CSV, Spalte „Status“ auf den Workflow mappen |
|
||||
| GitHub Projects | Projekt → … → Import, oder per `gh` CLI aus `board.json` |
|
||||
| Notion | Datenbank → … → Merge with CSV |
|
||||
| Linear / Asana / ClickUp | jeweils CSV-Import, Spalten wie oben zuordnen |
|
||||
|
||||
Spalten: Code, Titel, Epic, Rolle, Komplexitaet, Aufwand_PT, Welle, Status, Technik,
|
||||
Beschreibung, Haengt_ab_von, Schaltet_frei, Akzeptanzkriterien, Pruefungen.
|
||||
|
||||
## Weg 3 – Dateibasiert in der Entwicklungsumgebung
|
||||
|
||||
Der Ordner `tickets/` enthält für jede Kachel eine Markdown-Datei (`FDN-01.md` …).
|
||||
Jede Datei ist ein vollständiger Bau-Prompt – Auftrag, Produkt-DNA, Ausgangslage,
|
||||
Akzeptanzkriterien, Prüfungen und Abschlussregeln.
|
||||
|
||||
- **Obsidian**: Ordner als Vault öffnen, Community-Plugin „Kanban“ installieren, Spalten anlegen und die Notizen einsortieren.
|
||||
- **VS Code**: Ordner öffnen, Erweiterung „Todo Tree“ oder „Markdown Kanban“ nutzen.
|
||||
- **Coding-Assistent**: Dateiöffnen, Inhalt kopieren, als Auftrag übergeben. Ein Prompt = eine Kachel = ein Branch.
|
||||
|
||||
## Weg 4 – Eigenes Board im Netzwerk (Team)
|
||||
|
||||
Selbst gehostet, jeweils mit CSV-Import:
|
||||
|
||||
```bash
|
||||
# Focalboard
|
||||
docker run -d -p 8000:8000 --name focalboard mattermost/focalboard
|
||||
|
||||
# Planka
|
||||
docker run -d -p 3010:1337 --name planka ghcr.io/plankanban/planka:latest
|
||||
|
||||
# Vikunja
|
||||
docker run -d -p 3456:3456 --name vikunja vikunja/vikunja
|
||||
```
|
||||
|
||||
Danach `board.csv` importieren.
|
||||
|
||||
## Reihenfolge der Arbeit
|
||||
|
||||
Die Wellen geben an, was parallel laufen darf. Eine Kachel ist startbar,
|
||||
sobald alle Kacheln unter „Hängt ab von“ auf Fertig stehen.
|
||||
|
||||
- **Welle 1** (5 Kacheln): FDN-01, QA-06, UX-01, UX-02, UX-03
|
||||
- **Welle 2** (8 Kacheln): FDN-02, FDN-03, FDN-07, FDN-08, FDN-09, SRC-01, UX-04, UX-05
|
||||
- **Welle 3** (8 Kacheln): DOC-01, DOC-09, FDN-04, MET-01, MET-02, QA-01, QA-11, VER-05
|
||||
- **Welle 4** (18 Kacheln): DOC-02, DOC-03, DOC-04, DOC-06, DOC-07, DOC-10, DOC-11, DOC-14, DOC-15, INT-01, INT-03, INT-08, MET-03, MET-04, QA-02, QA-07, VER-01, VER-06
|
||||
- **Welle 5** (10 Kacheln): DOC-05, DOC-08, DOC-12, INT-09, QA-05, SRC-02, SRC-05, VER-02, VER-03, VER-07
|
||||
- **Welle 6** (8 Kacheln): DOC-13, INT-06, MET-05, QA-03, SRC-03, SRC-06, SRC-07, VER-04
|
||||
- **Welle 7** (6 Kacheln): INT-04, INT-10, QA-08, QA-10, SRC-04, SRC-08
|
||||
- **Welle 8** (4 Kacheln): QA-09, QA-12, SRC-09, SRC-10
|
||||
- **Welle 9** (1 Kacheln): QA-04
|
||||
|
||||
Kritischer Pfad (28 PT): FDN-01 → FDN-02 → DOC-01 → DOC-04 → DOC-05 → VER-04 → QA-08 → QA-12
|
||||
|
||||
## Produkt-DNA
|
||||
|
||||
### Übernehmen
|
||||
- **paperless-ngx**: Kompromisslose Erfassungs-Pipeline: Consume-Ordner, Vorverarbeitung, OCR, durchsuchbares PDF/A – vollautomatisch ohne Nutzerinteraktion.
|
||||
- **paperless-ngx**: Regelwerk für automatische Zuordnung von Korrespondent, Dokumenttyp und Tags direkt beim Import.
|
||||
- **Docspell**: Sprachverarbeitende Extraktion konkreter Werte: Absender, Datum, Betrag, Vertragspartner werden als strukturierte Felder vorgeschlagen.
|
||||
- **Docspell**: Sauberes Mandanten- und Datenmodell sowie ausgereifter Postfach-Abruf inklusive Anhangbehandlung.
|
||||
- **Alfresco**: Vererbende Zugriffskontrolle über die Ablagehierarchie mit expliziten Erlaubnissen und Verboten.
|
||||
- **Alfresco**: Echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.
|
||||
- **Alfresco**: Versionierung mit Ausleihen/Einchecken sowie Aufbewahrungssteuerung inklusive Aufbewahrungssperre.
|
||||
- **ecoDMS**: Revisionssicherheit als Grundhaltung: unveränderliches Protokoll, nachvollziehbare Vernichtung, Vier-Augen-Freigabe.
|
||||
- **ecoDMS**: Praxisnaher Scanner- und Stapelworkflow mit Trennseiten und Klassifizierungsvorlagen.
|
||||
|
||||
### Vermeiden
|
||||
- **Alfresco – Schwergewichtige Plattform mit hohem Ressourcenbedarf, langer Startzeit und aufwendigem Betrieb.**: Schlanker Dienst plus getrennte Worker. Jede Komponente muss auf einem kleinen Server startklar sein.
|
||||
- **Alfresco – Übermächtiges Konfigurationsmodell mit steiler Lernkurve und träger Oberfläche.**: Sinnvolle Voreinstellungen, die ohne Konfiguration funktionieren. Komplexität nur dort, wo sie nachweislich gebraucht wird.
|
||||
- **paperless-ngx – Kaum Governance: keine echte Rechtevererbung, keine Freigabeprozesse, keine Versionen, kein belastbares Protokoll.**: Rechte, Versionierung und Protokoll gehören von Anfang an ins Fundament, nicht als Nachrüstung.
|
||||
- **paperless-ngx – Flache Ablage ohne Hierarchie, dadurch mühsam in Abteilungsstrukturen.**: Hierarchische Ablage und Verschlagwortung parallel anbieten – der Nutzer entscheidet, nicht das System.
|
||||
- **Docspell – Karge Oberfläche und dünne Dokumentation, hohe Einstiegshürde.**: Oberfläche und Hilfetexte sind Teil jeder Kachel, nicht ein späterer Feinschliff.
|
||||
- **ecoDMS – Geschlossenes System mit eigenständigem Desktop-Client und eingeschränkter Schnittstelle.**: Alles was die Oberfläche kann, kann auch die offene Schnittstelle. Die Oberfläche ist nur ein Nutzer der eigenen Programmierschnittstelle.
|
||||
- **ecoDMS – Herstellerbindung durch proprietäre Ablage- und Datenformate.**: Offene Formate, jederzeit vollständiger Export von Dokumenten und Metadaten ohne Werkzeug des Herstellers.
|
||||
|
||||
## Arbeitsregeln
|
||||
|
||||
Je Kachel ein eigener Branch, schrittweise committen, Branch pushen, dann anhalten.
|
||||
Kein Merge und kein Deploy ohne ausdrückliche Freigabe.
|
||||
|
||||
Code-Struktur: Hauptdateien/Entry-Points klein halten, Fachlogik in eigene Module/Dateien auslagern. Vor dem Anlegen einer neuen Funktions-/Modul-Datei prüfen, ob dieselbe Funktionalität nicht schon in einem anderen Modul (auch modulübergreifend, z. B. Core) existiert — keine doppelten Funktionsdateien, ein Modul/Board referenziert das andere extern statt Code zu kopieren (gleiches Prinzip wie bei den Konsolidierungen IAM/Archive/Workflow/AI/API/UI-Shell, siehe nexarch-state.json).
|
||||
@@ -0,0 +1,416 @@
|
||||
Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
|
||||
FDN-01,Repository & Projektgerüst,⚙️ Fundament,DevOps,Einfach,2,1,Fertig,"Monorepo, Go, Next.js/TypeScript, golangci-lint, Prettier","Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.",,FDN-02 FDN-03 FDN-07 FDN-08 FDN-09 SRC-01,"Repo lässt sich mit einem Befehl installieren und starten
|
||||
Lint- und Format-Checks laufen lokal durch
|
||||
Branch- und Commit-Konvention dokumentiert","Frischer Clone baut ohne manuelle Nacharbeit
|
||||
Lint-Fehler brechen den Build ab
|
||||
README-Setupanleitung von zweiter Person nachvollzogen"
|
||||
FDN-02,Datenmodell & Migrationen,⚙️ Fundament,Backend,Mittel,3,2,Fertig,"PostgreSQL, pgx/v5, SQL-Migrationsdateien (kein ORM)","Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.",FDN-01,DOC-01 DOC-09 FDN-04 MET-01 MET-02 QA-02 VER-01 VER-05,"Alle Kern-Entitäten mit Beziehungen und Indizes vorhanden
|
||||
Migration vorwärts und rückwärts ausführbar
|
||||
Seed-Datensatz für Entwicklung vorhanden","Migration auf leerer DB und auf bestehender DB getestet
|
||||
Rollback stellt Vorzustand wieder her
|
||||
Fremdschlüssel-Constraints durch Negativtests belegt"
|
||||
FDN-03,Objekt-Storage-Abstraktion,⚙️ Fundament,Backend,Mittel,3,2,Fertig,"S3-kompatibel, Presigned URLs","Storage-Adapter mit einheitlicher Schnittstelle für Ablegen, Lesen, Löschen und signierte URLs. Lokaler Treiber für Entwicklung, S3 für Produktion.",FDN-01,DOC-01 QA-02 FDN-10,"Ein Interface, zwei austauschbare Treiber
|
||||
Signierte URLs mit konfigurierbarer Gültigkeit
|
||||
Pfadschema innerhalb des Mandanten-Buckets für Dokument/Revision festgelegt (Bucket-Trennung selbst ist Sache von Core TEN-01)
|
||||
Objektgröße wird bei jedem Schreib-/Löschvorgang an den zentralen Speicherverbrauch-Zähler (Core LIC-05) gemeldet","Round-Trip-Test Upload/Download je Treiber
|
||||
Abgelaufene signierte URL wird abgewiesen
|
||||
Verhalten bei fehlendem Objekt liefert klaren Fehler
|
||||
Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe"
|
||||
FDN-04,Job-Queue & Worker-Runtime,⚙️ Fundament,Backend,Mittel,3,3,Fertig,"Postgres-Jobqueue (processing_jobs, FOR UPDATE SKIP LOCKED), In-Prozess-Worker-Goroutinen, kein Redis/AMQP","Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.",FDN-02,DOC-04 DOC-06 DOC-08 INT-03 QA-02 SRC-02 SRC-05 FDN-11,"Jobs werden zuverlässig eingereiht und verarbeitet
|
||||
Fehlgeschlagene Jobs landen nach n Versuchen in der DLQ
|
||||
Job-Status ist abfragbar","Absturz eines Workers führt zu erneuter Zustellung
|
||||
Idempotenz bei Doppelzustellung nachgewiesen
|
||||
DLQ-Eintrag manuell wiederholbar"
|
||||
FDN-07,CI-Pipeline & Testharness,⚙️ Fundament,DevOps,Einfach,2,2,Fertig,"CI-Runner, Unit-/E2E-Testrunner","Automatisierte Pipeline für Lint, Typprüfung, Unit- und E2E-Tests sowie Build-Artefakt. Testdatenbank wird pro Lauf frisch aufgesetzt.",FDN-01,QA-01 QA-02,"Pipeline läuft bei jedem Push
|
||||
Roter Test blockiert den Merge
|
||||
Testabdeckung wird ausgewiesen
|
||||
CI-Pipeline führt Dependency-/Supply-Chain-Scanning aus (govulncheck für Go-Module, npm audit für JS/TS-Pakete), Build schlägt bei kritischen bekannten Schwachstellen fehl.
|
||||
Sicherheitsrelevanter Code (Auth, Tenant-Scoping, Verschlüsselung, Berechtigungsprüfung) hat verpflichtende automatisierte Tests als Merge-Gate — ein Merge ohne diese Tests ist technisch blockiert, nicht nur Konvention.","Absichtlich fehlschlagender Test bricht Pipeline ab
|
||||
Pipeline-Laufzeit unter vereinbartem Grenzwert
|
||||
Artefakt ist reproduzierbar erzeugbar
|
||||
Absichtlich eingeführte bekannte Schwachstelle in einer Testabhängigkeit lässt den Build fehlschlagen.
|
||||
Merge-Versuch eines sicherheitsrelevanten Codepfads ohne Test wird von der Pipeline blockiert."
|
||||
FDN-08,"Logging, Metriken & Fehler-Tracking",⚙️ Fundament,DevOps,Einfach,2,2,Fertig,"Strukturierte Logs, Metrics-Endpoint","Strukturiertes Logging mit Korrelations-ID, technische Metriken und zentrale Fehlererfassung inklusive Alarmierung.",FDN-01,QA-02,"Jede Anfrage besitzt eine Korrelations-ID über alle Schichten
|
||||
Metriken für Latenz, Fehlerrate und Queue-Länge vorhanden
|
||||
Unbehandelte Fehler werden zentral gemeldet","Provozierter Fehler erscheint innerhalb einer Minute im Tracking
|
||||
Logs enthalten keine Passwörter oder Tokens
|
||||
Alarm-Schwelle einmal ausgelöst und quittiert"
|
||||
DOC-01,Upload-API & Chunk-Handling,🗂️ Dokumentenkern,Backend,Komplex,4,3,Fertig,tus.io / Multipart-Upload,"Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.",FDN-02 FDN-03 FDN-09,DOC-02 DOC-03 DOC-04 DOC-07 DOC-14 DOC-15 INT-01 INT-03 INT-06 INT-08 SRC-02 SRC-05 VER-01 INT-11 INT-12 INT-13 DOC-17,"Fortsetzbarer Upload nach Verbindungsabbruch
|
||||
Unerlaubte Dateitypen werden abgewiesen
|
||||
Dokument und Revision werden transaktional angelegt
|
||||
SHA-256 jeder Revision wird auf Klartext berechnet (vor FDN-09-Verschlüsselung) und transaktional mit der Revision in file_revisions.checksum_sha256 persistiert – Voraussetzung für Duplikaterkennung (DOC-02) und spätere Integritätsprüfung (Archive BAK-08)","Upload von 1 GB Datei erfolgreich
|
||||
Abbruch bei 50 % und Fortsetzung ergibt identische Prüfsumme
|
||||
Parallel-Upload von 20 Dateien ohne Datenverlust
|
||||
Nach Upload ist file_revisions.checksum_sha256 befüllt und entspricht der SHA-256 des hochgeladenen Klartexts"
|
||||
DOC-02,Dublettenerkennung,🗂️ Dokumentenkern,Backend,Einfach,2,4,Fertig,"SHA-256, Unique-Index","Prüfsumme jeder Datei berechnen, speichern und bei Upload gegen den Bestand prüfen. Nutzer entscheidet über Verwerfen oder bewusstes Duplikat.",DOC-01,SRC-02 SRC-05,"Prüfsumme wird bei jedem Upload persistiert
|
||||
Treffer wird dem Nutzer mit Verweis auf das Original gemeldet
|
||||
Bewusstes Duplikat ist möglich und wird markiert","Identische Datei zweimal hochgeladen erzeugt Warnung
|
||||
Datei mit einem geänderten Byte gilt nicht als Duplikat
|
||||
Prüfsummenberechnung bei Großdatei bleibt im Zeitbudget"
|
||||
DOC-03,Drag-and-Drop-Upload-Oberfläche,🗂️ Dokumentenkern,Frontend,Mittel,3,4,Fertig,"Dropzone, Fortschrittsanzeige","Upload-Oberfläche mit Ablagebereich, Mehrfachauswahl, Fortschritt je Datei, Abbrechen und verständlichen Fehlermeldungen.",DOC-01,QA-03,"Mehrere Dateien gleichzeitig per Drag-and-Drop
|
||||
Fortschritt und Status je Datei sichtbar
|
||||
Fehlgeschlagene Datei einzeln wiederholbar","Upload per Tastatur und Dateidialog bedienbar
|
||||
Verhalten bei Netzabbruch im Browser geprüft
|
||||
Mobile Ansicht bleibt bedienbar"
|
||||
DOC-04,Vorschau- & Thumbnail-Pipeline,🗂️ Dokumentenkern,Backend,Komplex,5,4,Fertig,"Renderer-Worker, Bildableitungen","Asynchrone Erzeugung von Seiten-Vorschauen und Thumbnails nach dem Upload, mit Cache und Wiederaufbau bei neuer Revision.",DOC-01 FDN-04,DOC-05 QA-10,"Thumbnail steht nach definierter Zeit bereit
|
||||
Vorschau wird gecacht und bei neuer Revision erneuert
|
||||
Fehlerhafte Datei blockiert die Pipeline nicht","Beschädigte PDF-Datei führt zu Fehlerstatus statt Absturz
|
||||
Durchsatztest mit 500 Dokumenten
|
||||
Cache-Invalidierung bei neuer Revision belegt"
|
||||
DOC-05,PDF-Viewer-Komponente,🗂️ Dokumentenkern,Frontend,Komplex,4,5,Fertig,PDF.js im Web-Worker,"Inline-Betrachter mit Seitennavigation, Zoom, Suche im Dokument und Textauswahl – ohne Download-Zwang.",DOC-04,DOC-13 QA-03 VER-04,"PDF wird ohne Download angezeigt
|
||||
Zoom, Blättern und Textsuche funktionieren
|
||||
Große Dokumente werden seitenweise nachgeladen","300-seitiges PDF öffnet im Zeitbudget
|
||||
Viewer per Tastatur bedienbar
|
||||
Speicherverbrauch im Browser bleibt stabil"
|
||||
DOC-06,Office-zu-PDF-Konverter,🗂️ Dokumentenkern,Backend,Komplex,4,4,Fertig,Headless-Konverter im Worker,"Serverseitige Konvertierung von Text-, Tabellen- und Präsentationsformaten in PDF als Vorschau- und Archivderivat.",FDN-04,QA-03 VER-07,"Gängige Office-Formate werden konvertiert
|
||||
Konvertierung läuft isoliert mit Zeitlimit
|
||||
Ergebnis wird als Derivat der Revision abgelegt","Layouttreue an Referenzdokumenten geprüft
|
||||
Zeitlimit bei Endlosdokument greift
|
||||
Konverter-Absturz beeinträchtigt andere Jobs nicht"
|
||||
DOC-07,Download & signierte URLs,🗂️ Dokumentenkern,Backend,Einfach,2,4,Fertig,Presigned URLs,"Download von Original und Derivaten über kurzlebige signierte URLs, inklusive korrektem Dateinamen und Berechtigungsprüfung.",DOC-01,DOC-08,"Download liefert Originaldatei unverändert
|
||||
URL läuft nach kurzer Frist ab
|
||||
Ohne Leseberechtigung kein Download","Prüfsumme vor und nach Download identisch
|
||||
Weitergegebene abgelaufene URL wird abgewiesen
|
||||
Sonderzeichen im Dateinamen korrekt übertragen"
|
||||
DOC-08,Massenexport als ZIP,🗂️ Dokumentenkern,Backend,Mittel,3,5,Fertig,"ZIP-Streaming, Export-Job","Auswahl mehrerer Dokumente als Hintergrund-Job zu einem Archiv bündeln, inklusive optionaler Metadaten-Datei und Download-Benachrichtigung.",DOC-07 FDN-04,QA-03 DOC-18,"Export läuft als Job und blockiert die Oberfläche nicht
|
||||
Archiv enthält Dokumente und Metadaten-Beilage
|
||||
Nur berechtigte Dokumente landen im Archiv","Export von 1000 Dokumenten ohne Speicherüberlauf
|
||||
Archiv in gängigen Entpackern lesbar
|
||||
Berechtigungsfilter durch Negativtest belegt"
|
||||
DOC-09,Ordner- & Kabinettmodell,🗂️ Dokumentenkern,Backend,Mittel,3,3,Fertig,"Baumstruktur, Materialized Path","Hierarchische Ablage mit Verschieben, Umbenennen und effizienten Teilbaum-Abfragen.",FDN-02,DOC-10 DOC-11 DOC-14,"Beliebig tiefe Hierarchie abbildbar
|
||||
Verschieben aktualisiert den gesamten Teilbaum
|
||||
Teilbaum-Abfrage bleibt performant","Zyklus beim Verschieben wird verhindert
|
||||
Abfrage bei 10.000 Ordnern im Zeitbudget
|
||||
Umbenennen bricht keine Verweise"
|
||||
DOC-10,Ordner-Navigation & Dokumentenliste,🗂️ Dokumentenkern,Frontend,Mittel,3,4,Fertig,"Baum-Navigation, virtualisierte Liste","Navigationsbaum, Brotkrumenpfad und virtualisierte Dokumentenliste mit Sortierung, Spaltenwahl und Mehrfachauswahl.",DOC-09,QA-03,"Baum und Liste bleiben synchron
|
||||
Liste bleibt bei vielen Einträgen flüssig
|
||||
Mehrfachauswahl mit Umschalt- und Strg-Taste","Liste mit 10.000 Zeilen scrollt ruckelfrei
|
||||
Navigation vollständig per Tastatur
|
||||
Zustand bleibt beim Zurücknavigieren erhalten"
|
||||
DOC-11,Soft-Delete & Papierkorb-Logik,🗂️ Dokumentenkern,Backend,Einfach,2,4,Fertig,"Soft-Delete, Aufräum-Job",Löschen setzt einen Papierkorb-Status statt physischer Entfernung. Endgültige Bereinigung erfolgt nach konfigurierbarer Frist.,DOC-09,DOC-12,"Gelöschte Objekte verschwinden aus allen normalen Ansichten
|
||||
Wiederherstellung stellt Ablageort und Metadaten wieder her
|
||||
Endgültige Löschung entfernt auch die Dateiobjekte","Gelöschtes Dokument taucht in Suche und Liste nicht mehr auf
|
||||
Wiederherstellung nach Ordnerlöschung getestet
|
||||
Aufräum-Job löscht nur abgelaufene Einträge"
|
||||
DOC-12,Papierkorb-Oberfläche,🗂️ Dokumentenkern,Frontend,Einfach,2,5,Fertig,"Listenansicht, Bestätigungsdialog","Ansicht des Papierkorbs mit Restlaufzeit, Einzel- und Massenwiederherstellung sowie bestätigter endgültiger Löschung.",DOC-11,QA-03,"Restlaufzeit je Eintrag sichtbar
|
||||
Wiederherstellung einzeln und in Auswahl möglich
|
||||
Endgültiges Löschen erfordert ausdrückliche Bestätigung","Versehentliches Löschen ohne Bestätigung nicht möglich
|
||||
Massenwiederherstellung mit 100 Objekten geprüft
|
||||
Leerer Papierkorb zeigt verständlichen Hinweis"
|
||||
SRC-01,Suchindex-Infrastruktur,🔍 Suche & OCR,DevOps,Mittel,3,2,Fertig,Manticore Search (BM25),"Suchdienst bereitstellen, Index-Schema mit deutscher Sprachbehandlung definieren und Betriebsparameter festlegen.",FDN-01,SRC-02,"Suchdienst ist reproduzierbar startbar
|
||||
Index-Schema mit Feldern und Gewichtung dokumentiert
|
||||
Deutsche Stemming- und Stoppwortbehandlung aktiv","Neuaufbau des Index aus dem Bestand möglich
|
||||
Umlaut- und Kompositasuche liefert Treffer
|
||||
Neustart des Dienstes ohne Datenverlust"
|
||||
SRC-02,Indexierungs-Worker & Synchronisierung,🔍 Suche & OCR,Backend,Komplex,4,5,Fertig,"Queue-Worker, Bulk-Indexing","Änderungen an Dokumenten, Metadaten und OCR-Texten laufend in den Suchindex übertragen, inklusive Voll-Reindexierung.",SRC-01 DOC-01 FDN-04 DOC-02,SRC-03,"Neues Dokument ist zeitnah auffindbar
|
||||
Änderung und Löschung werden im Index nachgezogen
|
||||
Voll-Reindexierung ohne Ausfall möglich","Konsistenzabgleich Datenbank gegen Index ergibt keine Abweichung
|
||||
Indexierung von 10.000 Dokumenten im Zeitbudget
|
||||
Ausfall des Suchdienstes führt zu Nachholung statt Datenverlust"
|
||||
SRC-03,Such-API mit Ranking,🔍 Suche & OCR,Backend,Mittel,3,6,Fertig,"Suchabfrage, Relevanz-Tuning","Suchschnittstelle mit Paginierung, Sortierung, Treffer-Ausschnitten und Berücksichtigung der Leseberechtigung.",SRC-02,QA-10 SRC-04 SRC-08,"Ergebnisse enthalten Textausschnitte mit Fundstellen
|
||||
Nur berechtigte Dokumente erscheinen
|
||||
Antwortzeit unter vereinbartem Grenzwert","Referenz-Suchanfragen liefern erwartete Reihenfolge
|
||||
Berechtigungsfilter durch Negativtest belegt
|
||||
Lasttest mit gleichzeitigen Suchanfragen bestanden"
|
||||
SRC-04,Such-Oberfläche mit Hervorhebung,🔍 Suche & OCR,Frontend,Mittel,3,7,Fertig,"Suchfeld, Ergebnisliste","Suchfeld mit Vorschlägen, Ergebnisliste mit hervorgehobenen Fundstellen und Sprung in die Dokumentvorschau.",SRC-03,QA-04 SRC-09,"Fundstellen sind im Ergebnis hervorgehoben
|
||||
Kein Ergebnis liefert hilfreiche Alternativvorschläge
|
||||
Suchzustand ist per URL teilbar","Suche vollständig per Tastatur bedienbar
|
||||
Verhalten bei sehr langem Suchbegriff geprüft
|
||||
Ergebnisliste auf Mobilgerät nutzbar"
|
||||
SRC-05,OCR-Worker,🔍 Suche & OCR,Backend,Komplex,5,5,Fertig,"Tesseract, Bildvorverarbeitung","Texterkennung für Scans und Bilder inklusive Entzerrung, Rauschunterdrückung und Speicherung des Volltexts je Seite.",FDN-04 DOC-01 DOC-02,INT-06 MET-05 SRC-06 SRC-07,"Erkannter Text wird seitenweise gespeichert
|
||||
Bereits durchsuchbare PDFs werden übersprungen
|
||||
Verarbeitung skaliert über mehrere Worker","Erkennungsrate an Referenz-Scanset gemessen und dokumentiert
|
||||
Schiefer Scan wird korrekt entzerrt
|
||||
Sehr großes Dokument läuft nicht in Zeitüberschreitung"
|
||||
SRC-06,PDF/A-Erzeugung mit Textebene,🔍 Suche & OCR,Backend,Mittel,3,6,Fertig,"PDF/A-Konverter, Textlayer",Archivfähiges PDF/A mit unsichtbarer Textebene aus der Texterkennung als zusätzliches Derivat erzeugen.,SRC-05,QA-04,"Erzeugtes PDF ist PDF/A-konform
|
||||
Text ist im Dokument markier- und durchsuchbar
|
||||
Original bleibt unverändert erhalten","Konformitätsprüfung mit Validierungswerkzeug bestanden
|
||||
Textposition deckt sich mit dem Bild
|
||||
Dateigröße bleibt im vereinbarten Rahmen"
|
||||
SRC-07,Spracherkennung & OCR-Qualitätsbewertung,🔍 Suche & OCR,Backend,Einfach,2,6,Fertig,"Spracherkennung, Konfidenzwerte","Dokumentsprache automatisch bestimmen, passendes Sprachmodell wählen und Konfidenzwerte für eine Nachbearbeitungsliste erfassen.",SRC-05,QA-04,"Sprache wird erkannt und am Dokument gespeichert
|
||||
Konfidenzwert je Seite verfügbar
|
||||
Dokumente unter Schwellwert erscheinen in einer Prüfliste","Spracherkennung an gemischtsprachigem Set geprüft
|
||||
Schlechter Scan landet zuverlässig in der Prüfliste
|
||||
Schwellwert ist ohne Neuveröffentlichung konfigurierbar"
|
||||
SRC-08,Facetten- & Filter-API,🔍 Suche & OCR,Backend,Mittel,3,7,Fertig,"Facettierung, Filterausdrücke","Kombinierbare Filter nach Typ, Tag, Datum, Ersteller und benutzerdefinierten Feldern samt Trefferzahlen je Facette.",SRC-03 MET-02,SRC-09 SRC-10,"Mehrere Filter sind gleichzeitig kombinierbar
|
||||
Facetten liefern korrekte Trefferzahlen
|
||||
Datums- und Wertebereiche werden unterstützt","Trefferzahlen gegen Datenbankabfrage abgeglichen
|
||||
Filter auf leerem Ergebnis verhält sich stabil
|
||||
Antwortzeit mit fünf aktiven Filtern gemessen"
|
||||
SRC-09,Filter-Panel in der Suche,🔍 Suche & OCR,Frontend,Mittel,3,8,Fertig,"Facetten-UI, Filter-Chips",Seitliches Filterpanel mit aktiven Filtern als entfernbare Chips und Zurücksetzen-Funktion.,SRC-08 SRC-04,QA-04,"Aktive Filter sind jederzeit sichtbar und einzeln entfernbar
|
||||
Trefferzahl aktualisiert sich unmittelbar
|
||||
Filterzustand steht in der URL","Geteilte URL stellt identischen Filterzustand her
|
||||
Panel auf schmalem Bildschirm bedienbar
|
||||
Zurücksetzen entfernt wirklich alle Filter"
|
||||
SRC-10,Gespeicherte Suchanfragen,🔍 Suche & OCR,Fullstack,Einfach,2,8,Fertig,Persistierte Abfragen,"Suchen benennen, speichern, erneut ausführen und optional mit dem Team teilen.",SRC-08,QA-04,"Suche lässt sich benennen und wiederherstellen
|
||||
Geteilte Suche ist für Berechtigte sichtbar
|
||||
Ergebnis wird beim Aufruf frisch ermittelt","Gespeicherte Suche liefert nach Datenänderung aktuelle Treffer
|
||||
Geteilte Suche zeigt jedem nur erlaubte Dokumente
|
||||
Löschen einer Suche beeinträchtigt andere Nutzer nicht"
|
||||
MET-01,Tag-Modell & Tag-API,🏷️ Metadaten,Backend,Einfach,2,3,Fertig,"Tag-Entität, Zuordnungstabelle","Tags mit Farbe und optionaler Hierarchie, Zuordnung zu Dokumenten sowie Zusammenführen und Umbenennen.",FDN-02,DOC-15 MET-03 MET-05,"Tags sind anlegbar, umbenennbar und zusammenführbar
|
||||
Mehrfachzuordnung je Dokument möglich
|
||||
Löschen eines Tags entfernt nur die Zuordnung","Zusammenführen erhält alle Zuordnungen
|
||||
Doppelte Tag-Namen werden verhindert
|
||||
Massenzuweisung an 500 Dokumente geprüft"
|
||||
MET-02,Benutzerdefinierte Metadatenfelder,🏷️ Metadaten,Backend,Komplex,4,3,Fertig,"Feldschema, Validierung","Frei definierbare Felder mit Datentyp, Pflichtkennzeichen, Standardwert und Validierungsregeln.",FDN-02,MET-03 MET-04 SRC-08,"Feldtypen Text, Zahl, Datum, Auswahl und Ja/Nein verfügbar
|
||||
Validierung greift beim Speichern
|
||||
Felddefinition ist versioniert änderbar","Ungültiger Wert wird mit klarer Meldung abgewiesen
|
||||
Typänderung eines Feldes mit Bestandsdaten getestet
|
||||
Pflichtfeld blockiert unvollständiges Speichern"
|
||||
MET-03,Metadaten- & Tag-Oberfläche,🏷️ Metadaten,Frontend,Mittel,3,4,Fertig,Dynamische Formulare,"Bearbeitungsbereich am Dokument mit dynamisch erzeugtem Formular, Tag-Eingabe mit Autovervollständigung und Massenbearbeitung.",MET-01 MET-02,QA-05,"Formular passt sich der Felddefinition automatisch an
|
||||
Tag-Eingabe schlägt bestehende Tags vor
|
||||
Massenbearbeitung für ausgewählte Dokumente möglich","Ungespeicherte Änderungen lösen Warnung aus
|
||||
Formular per Tastatur vollständig ausfüllbar
|
||||
Massenbearbeitung an 200 Dokumenten geprüft"
|
||||
MET-04,Dokumententypen & Vorlagen,🏷️ Metadaten,Backend,Mittel,3,4,Fertig,"Typdefinition, Feldbindung","Dokumententypen wie Rechnung oder Vertrag mit fest zugeordneten Pflichtfeldern, Standard-Tags und Aufbewahrungsvorgabe.",MET-02,QA-05,"Typ bündelt Felder, Tags und Aufbewahrungsvorgabe
|
||||
Typwechsel überführt vorhandene Werte
|
||||
Typ ist an Ordner vorbelegbar","Typwechsel mit Datenverlustprüfung getestet
|
||||
Pflichtfelder des Typs werden erzwungen
|
||||
Vorbelegung im Ordner greift beim Upload"
|
||||
MET-05,Regelbasierte Auto-Verschlagwortung,🏷️ Metadaten,Backend,Mittel,3,6,Fertig,"Regelwerk, Mustererkennung","Regeln auf Basis von Textmustern, Absender oder Dateiname vergeben automatisch Tags, Typ und Ablageort.",MET-01 SRC-05,INT-04 QA-05,"Regeln sind ohne Eingriff in den Code pflegbar
|
||||
Reihenfolge und Priorität der Regeln sind steuerbar
|
||||
Automatische Zuweisung ist als solche erkennbar","Regelwerk an Testkorpus mit erwarteter Trefferquote geprüft
|
||||
Widersprüchliche Regeln führen zu definiertem Ergebnis
|
||||
Regeländerung wirkt ohne Neustart"
|
||||
VER-01,Versionsmodell & Check-in/Check-out,🔄 Versionierung & Audit,Backend,Komplex,4,4,Fertig,"Revisionen, Sperren","Jede Änderung erzeugt eine neue Revision. Ausleihen sperrt das Dokument für andere, Einchecken gibt es mit Kommentar frei.",DOC-01 FDN-02,VER-02 VER-03 VER-07,"Alle Revisionen bleiben abrufbar
|
||||
Sperre verhindert konkurrierende Änderungen
|
||||
Sperre ist durch Administratoren aufhebbar","Zwei gleichzeitige Ausleihversuche – nur einer gewinnt
|
||||
Verwaiste Sperre wird nach Frist automatisch gelöst
|
||||
Alte Revision ist unverändert abrufbar"
|
||||
VER-02,Versionsansicht & Wiederherstellung,🔄 Versionierung & Audit,Frontend,Mittel,3,5,Fertig,"Versionsliste, Wiederherstellen","Liste aller Revisionen mit Autor, Zeitpunkt und Kommentar sowie Wiederherstellung einer früheren Fassung als neue Revision.",VER-01,QA-08,"Revisionen chronologisch mit Metadaten sichtbar
|
||||
Wiederherstellung erzeugt eine neue Revision statt Überschreiben
|
||||
Jede Revision ist einzeln herunterladbar","Wiederherstellung verändert die Historie nicht
|
||||
Ansicht bei 100 Revisionen bleibt übersichtlich
|
||||
Berechtigung wird je Revision geprüft"
|
||||
VER-03,Änderungshistorie & Diff-Berechnung,🔄 Versionierung & Audit,Backend,Mittel,3,5,Fertig,"Textvergleich, Metadaten-Diff",Unterschiede zwischen zwei Revisionen ermitteln – sowohl im Volltext als auch in Metadaten und Tags.,VER-01,VER-04,"Textunterschiede werden zeilen- oder absatzweise geliefert
|
||||
Metadatenänderungen werden als Vorher-Nachher ausgegeben
|
||||
Berechnung ist auch für große Dokumente möglich","Diff an Referenzpaaren gegen erwartetes Ergebnis geprüft
|
||||
Vergleich zweier identischer Revisionen liefert leeres Ergebnis
|
||||
Laufzeit bei 200-seitigem Dokument gemessen"
|
||||
VER-04,Diff-Ansicht,🔄 Versionierung & Audit,Frontend,Mittel,3,6,Fertig,"Gegenüberstellung, Farbmarkierung","Zwei Revisionen nebeneinander mit farblicher Markierung von Hinzufügungen, Löschungen und Metadatenänderungen.",VER-03 DOC-05,QA-08,"Revisionen sind frei zum Vergleich wählbar
|
||||
Änderungen sind farblich und mit Symbol gekennzeichnet
|
||||
Sprung zur nächsten Änderung möglich","Farbmarkierung ist auch ohne Farbwahrnehmung unterscheidbar
|
||||
Ansicht funktioniert auf schmalem Bildschirm
|
||||
Sehr viele Änderungen bremsen die Ansicht nicht aus"
|
||||
VER-05,Revisionssicherer Audit-Trail,🔄 Versionierung & Audit,Backend,Komplex,4,3,Fertig,"Append-only-Protokoll, Hash-Kette",Unveränderliches Protokoll aller sicherheits- und geschäftsrelevanten Ereignisse mit Verkettung zum Nachweis der Unversehrtheit.,FDN-02,VER-06 VER-08,"Einträge sind ausschließlich anfügbar
|
||||
Jeder Eintrag enthält Akteur, Zeit, Objekt und Aktion
|
||||
Verkettung erlaubt Integritätsprüfung","Manipulationsversuch wird durch Integritätsprüfung erkannt
|
||||
Vollständigkeit gegen Referenzoperationen abgeglichen
|
||||
Protokollschreiben verlangsamt Kernoperationen nicht spürbar"
|
||||
VER-06,Audit-Log-Ansicht & Export,🔄 Versionierung & Audit,Frontend,Einfach,2,4,Fertig,"Filterbare Tabelle, CSV-Export","Durchsuchbare Protokollansicht mit Filtern nach Zeitraum, Akteur, Objekt und Aktion sowie Export für Prüfer.",VER-05,QA-08,"Filter nach Zeitraum, Akteur und Aktion vorhanden
|
||||
Export enthält exakt die gefilterten Einträge
|
||||
Zugriff nur für berechtigte Rollen","Export mit 100.000 Einträgen läuft ohne Abbruch
|
||||
Nicht berechtigter Nutzer erhält keinen Zugriff
|
||||
Exportdatei ist in Tabellenkalkulation korrekt lesbar"
|
||||
VER-07,Digitale Signatur,🔄 Versionierung & Audit,Backend,Komplex,5,5,Fertig,"PAdES, Zertifikate, Zeitstempel","Dokumente digital signieren und vorhandene Signaturen prüfen, inklusive qualifiziertem Zeitstempel.",VER-01 DOC-06,QA-08,"Signatur wird eingebettet und ist extern prüfbar
|
||||
Prüfergebnis wird am Dokument angezeigt
|
||||
Zeitstempel stammt von einer vertrauenswürdigen Quelle","Signatur mit externem Prüfwerkzeug validiert
|
||||
Nachträgliche Änderung invalidiert die Signatur nachweislich
|
||||
Abgelaufenes Zertifikat wird als solches erkannt"
|
||||
INT-01,REST-API v1 & Schnittstellenbeschreibung,🔌 Integration & API,Backend,Komplex,4,4,Fertig,"REST, OpenAPI","Dokument-spezifische API-Endpunkte (Dokument abrufen/anlegen/durchsuchen usw.) auf dem zentralen Core-REST-Grundgerüst definieren und dokumentieren – keine eigene Router-/Versionierungs-Infrastruktur, die liefert Core API-01.",DOC-01,INT-09 QA-10,"Alle dokument-eigenen Endpunkte sind in der Beschreibung dokumentiert
|
||||
Einheitliches Fehlerformat über alle Endpunkte (geerbt vom Core-REST-Grundgerüst)
|
||||
Endpunkte laufen auf der zentralen, versionierten Core-API auf, keine eigene Versionierung","Vertragstests gegen die Beschreibung laufen in der Pipeline
|
||||
Berechtigungen greifen identisch wie in der Oberfläche
|
||||
Beispielaufrufe aus der Dokumentation funktionieren"
|
||||
INT-03,E-Mail-Abruf über IMAP,🔌 Integration & API,Backend,Komplex,4,4,Fertig,"IMAP-Client, Job-Zeitplan","Überwachte Postfächer regelmäßig abrufen, Nachrichten und Anhänge importieren und verarbeitete Nachrichten markieren.",FDN-04 DOC-01,INT-04,"Mehrere Postfächer parallel überwachbar
|
||||
Nachricht und Anhänge werden als Dokumente abgelegt
|
||||
Verarbeitete Nachrichten werden nicht erneut importiert","Verbindungsabbruch führt zu Wiederholung ohne Duplikate
|
||||
Nachricht mit 20 Anhängen korrekt importiert
|
||||
Zugangsdaten liegen ausschließlich verschlüsselt vor"
|
||||
INT-04,E-Mail-Regeln & Anhangverarbeitung,🔌 Integration & API,Backend,Mittel,3,7,Fertig,"Regelwerk, Anhangfilter","Regeln nach Absender, Betreff oder Anhangtyp steuern Ablageort, Typ und Verschlagwortung importierter Nachrichten.",INT-03 MET-05,QA-09,"Regeln greifen auf Absender, Betreff und Anhangtyp zu
|
||||
Signaturbilder und Werbeanhänge sind ausfilterbar
|
||||
Nachricht bleibt als Kontext am Dokument erhalten","Regelwerk an Testpostfach mit erwarteter Zuordnung geprüft
|
||||
Nachricht ohne passende Regel landet im Klärungskorb
|
||||
Filter verwirft keine relevanten Anhänge"
|
||||
INT-06,Scanner-Anbindung über Hot-Folder,🔌 Integration & API,Backend,Komplex,4,6,Fertig,"Überwachter Ordner, Trennseiten","Überwachtes Verzeichnis für Netzwerkscanner mit Stapeltrennung, automatischer Texterkennung und Ablage.",DOC-01 SRC-05,INT-10 QA-09 INT-14,"Neue Dateien werden automatisch übernommen
|
||||
Stapel werden anhand von Trennseiten aufgeteilt
|
||||
Fehlerhafte Dateien landen in einem Fehlerordner","Datei wird erst nach vollständigem Schreiben verarbeitet
|
||||
Stapeltrennung an Referenzstapel geprüft
|
||||
Doppelte Einlieferung erzeugt kein Duplikat"
|
||||
UX-01,Responsive Layout & mobile Navigation,📱 UX & Zugänglichkeit,Frontend,Mittel,3,1,Fertig,"Breakpoints, mobile Muster","Alle Kernansichten für kleine Bildschirme optimieren, mit ausklappbarer Navigation und berührungsfreundlichen Zielen.",,UX-05,"Kernabläufe sind auf dem Telefon vollständig durchführbar
|
||||
Keine horizontale Scrollleiste bei 360 Pixel Breite
|
||||
Bedienelemente sind ausreichend groß","Test auf drei realen Geräteklassen
|
||||
Upload und Suche auf Mobilgerät durchgeführt
|
||||
Querformat geprüft"
|
||||
UX-02,Dunkles Erscheinungsbild & Theming,📱 UX & Zugänglichkeit,Frontend,Einfach,2,1,Fertig,"Theme-Tokens, Systempräferenz",Umschaltbares helles und dunkles Erscheinungsbild mit Speicherung der Wahl und Berücksichtigung der Systemeinstellung.,,UX-05,"Umschaltung wirkt ohne Neuladen
|
||||
Wahl bleibt über Sitzungen erhalten
|
||||
Systemeinstellung wird als Voreinstellung übernommen","Kontrastprüfung in beiden Varianten bestanden
|
||||
Kein Aufblitzen des falschen Erscheinungsbilds beim Laden
|
||||
Diagramme und Vorschauen bleiben lesbar"
|
||||
UX-03,Mehrsprachigkeits-Infrastruktur,📱 UX & Zugänglichkeit,Frontend,Mittel,3,1,Fertig,"i18n-Bibliothek, Sprachdateien","Alle Texte auslagern, Sprachumschaltung sowie lokale Formate für Datum, Zahl und Währung bereitstellen.",,UX-04,"Keine fest verdrahteten Texte mehr in Komponenten
|
||||
Sprachwechsel wirkt ohne Neuladen
|
||||
Datums- und Zahlenformate folgen der Sprache","Automatische Prüfung findet keine unübersetzten Texte
|
||||
Fehlender Schlüssel führt zu sichtbarem Hinweis statt leerem Feld
|
||||
Serverseitig gerenderte Seite zeigt die richtige Sprache"
|
||||
UX-04,Übersetzungen Deutsch und Englisch,📱 UX & Zugänglichkeit,Frontend,Einfach,2,2,Fertig,"Sprachdateien, Terminologieliste",Vollständige Übersetzung der Oberfläche in beide Sprachen inklusive abgestimmter Fachbegriffe.,UX-03,QA-11,"Beide Sprachdateien sind vollständig
|
||||
Fachbegriffe folgen einer abgestimmten Liste
|
||||
Fehlermeldungen sind ebenfalls übersetzt","Abdeckungsprüfung beider Sprachdateien bei 100 Prozent
|
||||
Sichtprüfung auf abgeschnittene Texte in beiden Sprachen
|
||||
Fachliche Gegenlesung dokumentiert"
|
||||
UX-05,Barrierefreiheit nach WCAG 2.1 AA,📱 UX & Zugänglichkeit,Frontend,Komplex,4,2,Fertig,"ARIA, Fokussteuerung","Semantik, Fokusführung, Tastaturbedienung, Beschriftungen und Kontraste über alle Ansichten hinweg herstellen.",UX-01 UX-02,QA-11,"Alle Abläufe ohne Maus bedienbar
|
||||
Sichtbare Fokusmarkierung überall vorhanden
|
||||
Formularfelder besitzen zugeordnete Beschriftungen","Automatisierte Prüfung meldet keine kritischen Verstöße
|
||||
Vollständiger Durchlauf mit Bildschirmleser dokumentiert
|
||||
Fokusfalle in Dialogen geprüft"
|
||||
QA-01,Teststrategie & Testdatenbestand,✅ Prüfungen & Qualitätssicherung,QA,Einfach,2,3,Fertig,"Teststrategie, anonymisierte Testdaten","Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen, anonymisierten Testdatenbestand mit Referenzdokumenten aufbauen.",FDN-07,QA-03 QA-04 QA-05 QA-07 QA-10,"Testpyramide und Abdeckungsziele sind schriftlich festgelegt
|
||||
Referenzkorpus mit Scans, PDFs und Office-Dateien liegt vor
|
||||
Testdaten enthalten keine echten Personendaten
|
||||
Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Testdatenbestand ist per Befehl reproduzierbar
|
||||
Referenzkorpus deckt alle unterstützten Formate ab
|
||||
Strategie im Team abgenommen"
|
||||
QA-02,Prüfgate Fundament,✅ Prüfungen & Qualitätssicherung,QA,Einfach,2,4,Fertig,"Integrationstests, Betriebsprüfung","Abnahme der Grundlage: Datenmodell, Storage, Queue, Auth, Pipeline und Observability greifen zuverlässig ineinander.",FDN-02 FDN-03 FDN-04 FDN-07 FDN-08 FDN-09,QA-12,"Alle Fundament-Tickets erfüllen ihre Prüfungen
|
||||
Ein Durchstich vom Login bis zum abgelegten Objekt funktioniert
|
||||
Keine offenen kritischen Befunde
|
||||
Verschlüsselung at rest (FDN-09) ist wirksam und die Schlüsselverwaltung geprüft","Neuaufsetzen der Umgebung von null erfolgreich
|
||||
Ausfall eines Dienstes führt zu sauberem Fehlerbild
|
||||
Prüfbericht abgelegt und freigegeben"
|
||||
QA-03,Prüfgate Dokumentenkern,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,6,Fertig,"E2E-Tests, Datenintegrität","Vollständige Prüfung des Lebenszyklus: hochladen, ansehen, ablegen, herunterladen, löschen, wiederherstellen.",DOC-03 DOC-05 DOC-06 DOC-08 DOC-10 DOC-12 QA-01 DOC-13 DOC-14 DOC-15,QA-12,"Kompletter Lebenszyklus als automatisierter Test vorhanden
|
||||
Keine Datenveränderung zwischen Upload und Download
|
||||
Alle Ticket-Prüfungen des Epics bestanden","Prüfsummenvergleich über den gesamten Lebenszyklus
|
||||
Abbruchszenarien in jedem Schritt getestet
|
||||
Referenzkorpus vollständig durchlaufen"
|
||||
QA-04,Prüfgate Suche & Texterkennung,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,9,Fertig,Relevanz- und Erkennungsmessung,"Messen und dokumentieren von Erkennungsgüte, Trefferqualität und Konsistenz zwischen Datenbank und Suchindex.",SRC-04 SRC-06 SRC-07 SRC-09 SRC-10 QA-01,QA-12 QA-06,"Erkennungsrate am Referenzkorpus erreicht den Zielwert
|
||||
Relevanz an definierten Suchanfragen erfüllt die Erwartung
|
||||
Index und Datenbank sind nachweislich konsistent","Messprotokoll mit Zielwerten und Ergebnissen abgelegt
|
||||
Voll-Reindexierung ohne Trefferverlust geprüft
|
||||
Berechtigungsfilter in der Suche negativ getestet"
|
||||
QA-05,Prüfgate Metadaten & Klassifizierung,✅ Prüfungen & Qualitätssicherung,QA,Einfach,2,7,Fertig,Datenqualitätstests,"Prüfen von Feldvalidierung, Typwechseln, Massenbearbeitung und Güte der automatischen Zuordnung.",MET-03 MET-04 QA-01 MET-05,QA-12,"Validierungsregeln greifen in allen Eingabewegen
|
||||
Automatische Vorschläge erreichen die Zielgenauigkeit
|
||||
Massenbearbeitung erzeugt keine inkonsistenten Daten","Genauigkeit der Klassifizierung dokumentiert
|
||||
Typwechsel mit Bestandsdaten ohne Verlust
|
||||
Validierung auch über die Schnittstelle wirksam"
|
||||
QA-06,Sicherheits- & Berechtigungsprüfung,✅ Prüfungen & Qualitätssicherung,QA,Komplex,4,10,Fertig,"Penetrationstest, Rollenmatrix",Systematische Prüfung aller Zugriffspfade gegen die Rollenmatrix sowie Test auf gängige Sicherheitslücken.,QA-04 SRC-11,QA-12,"Jede Rolle wurde gegen jeden Endpunkt geprüft
|
||||
Keine unbefugte Rechteausweitung möglich
|
||||
Befunde sind behoben oder bewusst akzeptiert","Zugriff auf fremdes Objekt per ID schlägt fehl
|
||||
Prüfung auf Einschleusung, Sitzungsübernahme und unsichere Weiterleitung
|
||||
Sicherheitsbericht abgelegt und freigegeben"
|
||||
QA-07,Prüfgate Workflow & Benachrichtigung,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,4,Fertig,"Prozesstests, Zeitraffer","Durchspielen aller Prozesspfade inklusive Ablehnung, Vertretung, Eskalation und Fristablauf.",QA-01,QA-12,"Alle Prozesspfade sind mindestens einmal durchlaufen
|
||||
Fristen und Eskalationen lösen korrekt aus
|
||||
Keine Benachrichtigung geht verloren oder wird doppelt versandt","Zeitraffer-Test über simulierte Fristen
|
||||
Parallelentscheidungen erzeugen keinen Fehlzustand
|
||||
Zustellprotokoll gegen erwartete Ereignisse abgeglichen"
|
||||
QA-08,Revisionssicherheits-Prüfung,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,7,Fertig,"Integritätsprüfung, Signaturvalidierung","Nachweis, dass Versionen, Protokoll und Signaturen unveränderlich, vollständig und extern prüfbar sind.",VER-02 VER-04 VER-06 VER-07,QA-12,"Historie ist lückenlos und nicht manipulierbar
|
||||
Signaturen sind mit externen Werkzeugen prüfbar
|
||||
Jede relevante Aktion erscheint im Protokoll","Manipulationsversuch wird erkannt und protokolliert
|
||||
Stichprobe von Aktionen im Protokoll wiedergefunden
|
||||
Prüfbericht für die Revision erstellt"
|
||||
QA-09,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,8,Fertig,"Vertragstests, Testempfänger","Automatisierte Prüfung, dass die Schnittstelle ihrer Beschreibung entspricht und Importwege zuverlässig arbeiten.",INT-04 INT-06 INT-08 INT-09 INT-10 INT-11 INT-12 INT-13,QA-12,"Vertragstests laufen in der Pipeline
|
||||
Import über E-Mail und Hot-Folder verliert keine Dokumente
|
||||
Webhook-Zustellung ist nachweisbar","Abweichung zwischen Beschreibung und Verhalten bricht die Pipeline
|
||||
Dauerlauf-Import über 24 Stunden ohne Verlust
|
||||
Wiederholungsverhalten bei Ausfall belegt"
|
||||
QA-10,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,QA,Komplex,4,7,Backlog,"Lastgenerator, Messprotokoll","Verhalten unter realistischer und überhöhter Last messen: Suche, Upload, Vorschau und Schnittstelle.",SRC-03 DOC-04 INT-01 QA-01,QA-12,"Zielwerte für Antwortzeit und Durchsatz sind definiert und gemessen
|
||||
Engpässe sind identifiziert und dokumentiert
|
||||
System erholt sich nach Lastspitze selbstständig","Dauerlast über mehrere Stunden ohne Speicherwachstum
|
||||
Verhalten bei Überlast ist definiert statt zufällig
|
||||
Messprotokoll mit Zielwertvergleich abgelegt"
|
||||
QA-11,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,3,Fertig,"Prüfwerkzeuge, Bildschirmleser",Unabhängige Prüfung aller Ansichten gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf.,UX-04 UX-05,QA-12,"Keine kritischen Verstöße offen
|
||||
Manueller Bildschirmleser-Durchlauf dokumentiert
|
||||
Restbefunde sind mit Frist eingeplant","Automatisierte Prüfung über alle Hauptseiten
|
||||
Vollständiger Ablauf ohne Maus durchgeführt
|
||||
Auditbericht abgelegt"
|
||||
QA-12,Abnahme- & Compliance-Prüfung,✅ Prüfungen & Qualitätssicherung,QA,Komplex,4,11,Backlog,"Abnahmeprotokoll, Wiederherstellungstest","Gesamtabnahme vor der Freigabe: Aufbewahrung, Löschworkflow, Berichte und nachgewiesene Wiederherstellbarkeit.",QA-08 QA-02 QA-03 QA-04 QA-05 QA-06 QA-07 QA-09 QA-10 QA-11,,"Alle Prüfgates sind bestanden
|
||||
Wiederherstellung wurde real durchgeführt
|
||||
Abnahmeprotokoll ist unterzeichnet","Notfallwiederherstellung auf leerem System nachgewiesen
|
||||
Löschung nur mit Freigabe und Protokoll möglich
|
||||
Offene Restrisiken sind schriftlich benannt"
|
||||
FDN-09,Verschlüsselung at rest & Schlüsselverwaltung,⚙️ Fundament,Backend,Mittel,3,2,Fertig,"AES-256-GCM, Envelope Encryption","Envelope-Encryption-Modul – Datenverschlüsselungsschlüssel (DEK) pro Objekt, verpackt durch einen Hauptschlüssel (KEK), der über Core API-10 (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen wird. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst. Bietet Encrypt/Decrypt-Schnittstelle über Streams, die von der Storage-Abstraktion (FDN-03) beim Ablegen/Lesen genutzt wird.",FDN-01,DOC-01 QA-02,"DEK wird pro Objekt neu erzeugt, nie wiederverwendet
|
||||
KEK wird ausschließlich über Core API-10 bezogen, nie im Code oder in der Datenbank im Klartext gespeichert
|
||||
Schlüsselrotation des KEK ist ohne Neuverschlüsselung aller Objekte möglich (nur DEK-Wrapper wird neu verpackt)","Round-Trip Encrypt/Decrypt liefert identischen Klartext
|
||||
Manipulierter Chiffretext wird bei Decrypt erkannt und abgelehnt (GCM-Auth-Tag)
|
||||
KEK-Rotation getestet, alte Objekte weiterhin lesbar"
|
||||
DOC-13,Akten-/Vorgangsanzeige im Dokumentkontext,🗂️ Dokumentenkern,Frontend,Einfach,2,6,Fertig,"Next.js/React/TS, externe REST-API","In der Dokument-Detailansicht anzeigen, ob das Dokument zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in DMS.",DOC-05,QA-03,"Dokument-Detailansicht zeigt Akte-Zugehörigkeit, Vermerke und offene Wiedervorlagen an, falls vorhanden
|
||||
Kein eigenes Akte-Datenmodell in DMS, ausschließlich Anzeige über die externe API
|
||||
Fehlerfall (Workflow-Board nicht erreichbar) blockiert die Dokumentanzeige selbst nicht, zeigt nur den Akte-Bereich als „vorübergehend nicht verfügbar“","Dokument mit verknüpfter Akte zeigt Akte-Informationen korrekt an
|
||||
Dokument ohne Akte-Verknüpfung zeigt Bereich nicht/leer an, kein Fehler
|
||||
Simulierter Ausfall der Workflow-API blockiert die übrige Dokumentanzeige nicht"
|
||||
INT-08,Watch-Folder-Import (Consume-Ordner),🔌 Integration & API,Backend,Mittel,3,4,Fertig,"Überwachter Ordner, Dateisystem-Events/Polling","Dateisystem-Ordner, der automatisch überwacht wird — jede dort abgelegte Datei wird ohne API-Aufruf importiert. Ergänzt DOC-01 (Upload-API), ersetzt sie nicht.",DOC-01,QA-09 INT-14,"Datei im überwachten Ordner wird automatisch erkannt und importiert, ohne manuellen Trigger
|
||||
Importierte Datei durchläuft denselben Pipeline-Weg wie ein API-Upload (Hash/Dedup/Verschlüsselung/OCR/Index)
|
||||
Fehlerhafte/nicht lesbare Datei landet in einem Fehler-Unterordner statt den Import-Prozess zu blockieren","Testdatei im Ordner abgelegt, erscheint automatisch als Dokument
|
||||
Pipeline-Schritte (Hash, Dedup-Gate, Verschlüsselung) im Test nachweislich durchlaufen
|
||||
Absichtlich beschädigte Datei landet im Fehler-Unterordner, blockiert restlichen Ordner nicht"
|
||||
INT-09,CMIS-kompatible Schnittstelle (optional),🔌 Integration & API,Backend,Komplex,4,5,Fertig,CMIS 1.1 (AtomPub oder Browser-Binding),"CMIS-Standardschnittstelle als optionale zusätzliche API neben der eigenen REST-API — ermöglicht Drittwerkzeugen direkten Zugriff auf DMS-Inhalte, ohne NEXARCH-spezifische Integration schreiben zu müssen.",INT-01,QA-09 INT-15,"CMIS-Basisoperationen (Objekt lesen, Ordner navigieren, Dokument hochladen) funktionieren gegen einen CMIS-Standard-Client
|
||||
CMIS-Zugriff respektiert dieselben Rechte/Mandantengrenzen wie die eigene REST-API
|
||||
Optional aktivierbar, kein Zwangsbestandteil","Test mit einem CMIS-Referenzclient gegen die Schnittstelle
|
||||
Berechtigungsprüfung im Test über CMIS-Pfad identisch zur REST-API
|
||||
Deaktivierung blockiert CMIS-Zugriff vollständig, REST-API bleibt unberührt"
|
||||
INT-10,Scanner-Stapelverarbeitung mit Trennseiten-/Barcode-Erkennung,🔌 Integration & API,Backend,Mittel,3,7,Fertig,"Leerseiten-Erkennung, Barcode-Decoding (z. B. ZBar/ZXing)","Erkennung von Trennseiten (leere Seite oder Barcode-Seite) in einem Multi-Dokument-Scan-Stapel, der über INT-06 (Hot-Folder) eingeht — trennt automatisch in einzelne Dokumente statt eine große Datei anzulegen.",INT-06,QA-09,"Leere Trennseite wird erkannt und trennt den Stapel in einzelne Dokumente
|
||||
Barcode-Trennseite wird erkannt, Barcode-Wert kann optional als Metadatenfeld übernommen werden
|
||||
Stapel ohne Trennseiten wird als ein einzelnes Dokument behandelt, kein Fehlverhalten","Test-Stapel mit Leerseiten-Trennung ergibt korrekte Anzahl Einzeldokumente
|
||||
Test-Stapel mit Barcode-Trennseiten ordnet Barcode-Werte korrekt zu
|
||||
Stapel ohne Trennseiten bleibt ein Dokument"
|
||||
DOC-14,Dokument-Zusammenführen & -Aufteilen,🗂️ Dokumentenkern,Backend,Mittel,3,4,Fertig,"PDF-Seitenmanipulation, Versionshistorie, Transaktionale Dokument-Operationen","Nachträgliches Zusammenführen mehrerer Dokumente zu einem (z.B. fälschlich getrennt gescannt) und Aufteilen eines mehrseitigen Dokuments in mehrere eigenständige Dokumente (z.B. Stapel-Scan ohne Trennseiten-Erkennung, siehe INT-10) – beides als nachträgliche Korrektur nach dem Import, nicht nur zum Importzeitpunkt.",DOC-01 DOC-09,QA-03,"Mehrere Dokumente lassen sich zu einem zusammenführen, Ursprungsdokumente bleiben in der Versionshistorie nachvollziehbar
|
||||
Ein mehrseitiges Dokument lässt sich an beliebigen Seitengrenzen in mehrere eigenständige Dokumente aufteilen, jedes mit eigenen Metadaten
|
||||
Beide Operationen respektieren bestehende Aufbewahrungssperren (Archive-Retention) – eine Kachel mit aktiver Löschsperre kann nicht durch Zusammenführen/Aufteilen umgangen werden","Test: drei Dokumente zusammengeführt, Ursprünge in Historie auffindbar
|
||||
Test: fünfseitiges Dokument an zwei Stellen geteilt, drei korrekte Einzeldokumente entstehen
|
||||
Test: Zusammenführen/Aufteilen eines Dokuments mit aktiver Löschsperre wird abgelehnt oder erfordert Freigabe, nicht stillschweigend erlaubt"
|
||||
DOC-15,Massenbearbeitung von Metadaten,🗂️ Dokumentenkern,Backend,Mittel,3,4,Fertig,"Massenoperation über Dokumentauswahl, transaktionale Verarbeitung","Mehrere ausgewählte Dokumente gleichzeitig mit Tags/Metadatenfeldern/Dokumenttyp bearbeiten (hinzufügen, entfernen, ersetzen) statt Dokument für Dokument – Vorbild paperless-ngx Bulk-Edit.",DOC-01 MET-01,QA-03,"Tag/Metadatenfeld kann über eine Auswahl mehrerer Dokumente gleichzeitig hinzugefügt oder entfernt werden
|
||||
Vorgang ist transaktional nachvollziehbar (Versionshistorie/Audit zeigt die Massenänderung, nicht stillschweigend)
|
||||
Vorgang respektiert bestehende Aufbewahrungssperren – ein gesperrtes Dokument in der Auswahl wird übersprungen mit klarer Rückmeldung, nicht die ganze Operation blockiert oder die Sperre umgangen","Test: Tag auf 10 ausgewählte Dokumente gleichzeitig angewendet, alle korrekt aktualisiert
|
||||
Audit-Log zeigt Massenänderung nachvollziehbar
|
||||
Test mit einem gesperrten Dokument in der Auswahl: dieses wird übersprungen, Rest wird bearbeitet, klare Rückmeldung welches übersprungen wurde"
|
||||
INT-11,Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage,🔌 Integration & API,Backend,Mittel,3,4,Fertig,"HTTP-Client gegen Archive-Modul-Adapter-Schnittstelle, Aufbewahrungsklassen-Mapping","Dokument-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung/Änderung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik im DMS zu bauen.",DOC-01,QA-09 INT-16,"Dokument-Objekttyp inkl. Aufbewahrungsklasse wird beim Start automatisch bei Archive registriert
|
||||
Vor Löschung oder Hard-Overwrite eines Dokuments wird eine Sperr-Abfrage an Archive gestellt
|
||||
Ist das Dokument gesperrt (Legal Hold), wird die Löschung abgelehnt und die Ablehnung im Audit-Log vermerkt
|
||||
Ist Archive nicht erreichbar, wird die Löschung sicherheitshalber verweigert (fail closed), nicht stillschweigend durchgeführt","Registrierung gegen eine echte Archive-Testinstanz durchgeführt, Objekttyp erscheint dort
|
||||
Test: gesperrtes Dokument kann nicht gelöscht werden, Ablehnung ist im Audit-Log sichtbar
|
||||
Test: Archive-Endpunkt absichtlich nicht erreichbar – Löschung wird verweigert, kein Fallback auf ungeprüfte Löschung"
|
||||
INT-12,AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01),🔌 Integration & API,Backend,Mittel,2,4,Fertig,"HTTP-Client gegen AI-Modul-Adapter-Schnittstelle, Feld-Mapping","Dokument-Objekttyp und dessen KI-relevante Felder (Volltext, Metadaten) bei NEXARCH AI registrieren, damit Klassifizierung, Extraktion und semantische Suche für Dokumente optional nutzbar werden, ohne eigene KI-Logik im DMS zu bauen.",DOC-01,QA-09 INT-16,"Dokument-Objekttyp inkl. KI-relevanter Felder wird beim Start automatisch bei AI registriert
|
||||
Registrierung ist optional: ist AI-Modul nicht aktiviert (Core LIC-02), startet das DMS unverändert ohne Fehler
|
||||
Registrierungsfehler blockieren niemals den regulären DMS-Betrieb (fail open bei Registrierung, nicht bei Löschung)","Registrierung gegen eine echte AI-Testinstanz durchgeführt, Objekttyp erscheint dort
|
||||
Test: AI-Modul deaktiviert – DMS startet und läuft unverändert, keine Fehlermeldung im Normalbetrieb
|
||||
Test: AI-Endpunkt nicht erreichbar bei Registrierung – DMS-Start wird dadurch nicht blockiert"
|
||||
INT-13,Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02),🔌 Integration & API,Backend,Mittel,3,4,Fertig,"HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher","Dokument-Objekttyp und Auslöser-Ereignisse (Dokument angelegt, Status geändert, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik im DMS ausgelöst werden können.",DOC-01,QA-09 INT-16,"Dokument-Objekttyp inkl. verfügbarer Auslöser-Ereignisse wird beim Start automatisch bei Workflow registriert
|
||||
Ereignis 'Dokument angelegt' wird beim Anlegen eines Dokuments tatsächlich an Workflow publiziert
|
||||
Fehlschlagende Zustellung eines Ereignisses blockiert nicht die auslösende DMS-Aktion (asynchron, nicht im Request-Pfad)","Registrierung gegen eine echte Workflow-Testinstanz durchgeführt, Objekttyp und Ereignisse erscheinen dort
|
||||
Test: Dokument angelegt – Ereignis kommt nachweislich bei Workflow an
|
||||
Test: Workflow-Endpunkt zum Zustellzeitpunkt nicht erreichbar – Dokumentanlage im DMS bleibt trotzdem erfolgreich, Ereignis wird nachgeliefert oder sichtbar verworfen (nicht stillschweigend verloren)"
|
||||
SRC-11,Feld-Whitelist-Query-Builder für Suchindex-Zugriff,🔍 Suche & OCR,Backend,Einfach,1,3,Fertig,"Statisches Enum/Switch für Feldnamen, getesteter Query-Builder","Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den DMS-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.",SRC-01,QA-06,"Spalten-/Feldnamen für dynamische Query-Teile stammen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau
|
||||
Whitelist ist nicht die einzige Absicherung – der Query-Builder selbst lässt keine anderen Werte durch, auch nicht bei einem Fehler in der Whitelist-Prüfung
|
||||
Entscheidung dokumentiert: DMS-eigene Implementierung, keine geteilte Utility mit dem jeweils anderen Board – konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren","Versuch, ein nicht in der Whitelist enthaltenes Feld anzufragen, wird abgewiesen statt stillschweigend ignoriert
|
||||
Code-Review bestätigt: kein dynamischer Spalten-/Tabellenname wird per String-Zusammenbau erzeugt"
|
||||
DOC-16,RET-05-Client: Aufbewahrungsklasse registrieren & Vernichtungs-Rückruf,🗂️ Dokumentenkern,Backend,Mittel,3,5,Fertig,"HTTP-Client gegen Archive RET-05, Rückruf-Endpunkt, Postgres-Jobqueue (FDN-04) für Requeue","DMS registriert seine Objekttypen (Dokument, Anhang) bei Archive RET-05 mit Aufbewahrungsklasse und Rückruf-Adresse, empfängt Vernichtungs-Rückrufe und behandelt Registrierungsfehler tolerant statt sie zu verschlucken.",DOC-01 FDN-04 RET-09,,"DMS registriert seine Objekttypen (Dokument, Anhang) bei Archive RET-05 mit korrekter Aufbewahrungsklasse und eigener Rückruf-Adresse
|
||||
DMS empfängt den Vernichtungs-Rückruf, führt die Löschung durch und antwortet mit 2xx bei Erfolg
|
||||
Eine fehlgeschlagene Registrierung (Archive nicht erreichbar/Nicht-2xx) führt zu einem Requeue über FDN-04, nicht zu einem Absturz oder stillem Verwerfen","Registrierung real gegen einen Test-RET-05-Endpunkt durchgeführt und verifiziert
|
||||
Vernichtungs-Rückruf gegen einen echten Testfall ausgelöst, DMS-Löschung nachweislich erfolgt, 2xx-Antwort gesendet
|
||||
Simulierter Nicht-2xx-Fehler bei der Registrierung führt nachweislich zu einem Requeue-Eintrag in der Jobqueue, kein Absturz"
|
||||
INT-14,Tenant-Zuordnung & Zugriffsschutz für Hot-Folder/Scanner-Verzeichnisse,🔌 Integration & API,Backend,Mittel,2,12,Fertig,"Dateisystem-Zugriffsrechte, Verzeichnisstruktur je Tenant, Go","INT-06 (Netzwerkscanner-Ordner) und INT-08 (Hot-Folder) importieren Dateien ohne API-Aufruf und damit ohne Anwendungs-Auth-Kontext. Ohne klare Zuordnung, welches Verzeichnis zu welchem Mandanten gehört, und ohne Zugriffsschutz auf Dateisystemebene kann eine falsch konfigurierte Freigabe Dokumente dem falschen Tenant zuordnen oder Dritten Schreibzugriff erlauben. Je Tenant ein eigenes, klar benanntes Verzeichnis mit dediziertem Dateisystem-Benutzer/Gruppenrechten einführen, Import-Routine prüft beim Einlesen explizit die Tenant-Zuordnung des Quellverzeichnisses gegen die Registry (Core TEN-01), bevor ein Dokument angelegt wird.",INT-06 INT-08,,"Jedes Hot-Folder-/Scanner-Verzeichnis ist genau einem Tenant fest zugeordnet, verankert in der Core-Registry
|
||||
Die Import-Routine lehnt einen Import ab und protokolliert dies, wenn die Verzeichnis-Tenant-Zuordnung nicht auflösbar oder inkonsistent ist
|
||||
Dateisystemrechte beschränken Schreibzugriff auf das Verzeichnis auf die vorgesehenen Quellen (Scanner/Sync-Tool), dokumentiert in der Betriebsanleitung","Test: Import aus einem korrekt zugeordneten Verzeichnis legt Dokument beim richtigen Tenant an
|
||||
Test: Import aus einem nicht zugeordneten/fehlkonfigurierten Verzeichnis wird abgelehnt und protokolliert
|
||||
Prüft Dateisystemrechte des Verzeichnisses gegen die Betriebsanleitung"
|
||||
INT-15,CMIS-Schnittstelle: Auth-/Tenant-Scoping-Parität zur REST-API,🔌 Integration & API,Backend,Mittel,2,12,Fertig,"CMIS, gemeinsame Auth-Middleware, Go","INT-09 stellt eine CMIS-Standardschnittstelle für Drittwerkzeuge bereit, ohne festzulegen, ob diese dieselbe Authentifizierung und Tenant-Scoping-Durchsetzung wie die REST-API verwendet. Eine zweite, schwächer geprüfte API-Fläche würde die gesamte Zugriffskontrolle umgehbar machen. CMIS auf dieselbe Auth-Middleware und Tenant-Kontext-Ermittlung wie die REST-API (INT-01) verpflichten – keine eigene, parallele Auth-Implementierung.",INT-09,,"CMIS-Endpunkte verwenden dieselbe Auth-Middleware wie die REST-API, keine eigene Login-/Token-Prüfung
|
||||
Ein über CMIS authentifizierter Aufruf ist auf denselben Tenant beschränkt wie über die REST-API mit denselben Credentials
|
||||
Ein automatisierter Test vergleicht Zugriffsergebnisse für dieselbe Anfrage über REST und CMIS und erwartet identisches Autorisierungsverhalten","Test: Zugriff auf ein fremdes Tenant-Dokument über CMIS wird identisch zur REST-API abgelehnt
|
||||
Test: abgelaufenes/widerrufenes Token wird von CMIS genauso abgelehnt wie von der REST-API (Kopplung an Core IAM-17)
|
||||
Code-Review-Gate: CMIS-Handler dürfen keine eigene Auth-Logik enthalten, nur die gemeinsame Middleware referenzieren"
|
||||
INT-16,Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow),🔌 Integration & API,Backend,Mittel,2,12,Fertig,"Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go","INT-11/12/13 registrieren DMS-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe (z. B. DOC-13 → Workflow VOR-04) dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl DMS selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.",INT-11 INT-12 INT-13,,"Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
|
||||
Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope
|
||||
Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert","Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten
|
||||
Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt
|
||||
Integrationstest über DOC-13 → Workflow VOR-04 mit zwei verschiedenen Tenants, prüft Isolation"
|
||||
DOC-17,Malware-Scan vor Ablage,🗂️ Dokumentenkern,Backend,Mittel,2,12,Fertig,"Virenscanner-Anbindung (z. B. ClamAV), Go, Postgres-Jobqueue","DOC-01 validiert Größe und MIME-Typ beim Upload, prüft aber nicht auf schädliche Inhalte (Viren, aktive Inhalte in Office-Dokumenten/Makros). Virenscan als verpflichtenden Verarbeitungsschritt vor endgültiger Ablage ergänzen – Upload bleibt in Quarantäne-Status, bis der Scan abgeschlossen ist; bei Fund wird das Dokument abgelehnt und der Vorfall protokolliert.",DOC-01,,"Jede hochgeladene Datei durchläuft einen Virenscan, bevor sie als reguläres Dokument sichtbar/abrufbar wird
|
||||
Ein positiver Scan-Fund führt zur Ablehnung des Dokuments und einem Audit-Event, nicht zu stiller Ablage
|
||||
Der Scan-Status ist für den hochladenden Nutzer sichtbar (in Bearbeitung/freigegeben/abgelehnt)","Test mit EICAR-Testdatei: wird zuverlässig erkannt und abgelehnt
|
||||
Test mit sauberer Datei: durchläuft Scan und wird normal verfügbar
|
||||
Lasttest: Scan-Queue verarbeitet mehrere gleichzeitige Uploads ohne Verlust der Reihenfolge/Nachvollziehbarkeit"
|
||||
FDN-10,Signierte URLs: Scope-Bindung & kurze Ablaufzeit,⚙️ Fundament,Backend,Einfach,1,12,Fertig,"Storage-Adapter (S3-kompatibel), signierte URLs, Go","FDN-03 stellt signierte URLs für den Storage-Zugriff bereit, ohne deren Scope und Ablaufzeit explizit festzulegen. Jede signierte URL muss fest an genau ein Objekt gebunden sein (nicht an ein Präfix/Verzeichnis) und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden). Nach Ablauf oder nach Löschung/Versionswechsel des Objekts muss die URL ungültig sein.",FDN-03,,"Eine signierte URL gewährt ausschließlich Zugriff auf genau das Objekt, für das sie ausgestellt wurde
|
||||
Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter
|
||||
Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stilles Fallback auf öffentlichen Zugriff","Test: signierte URL für Objekt A liefert bei Zugriffsversuch auf Objekt B einen Fehler
|
||||
Test: abgelaufene URL wird abgelehnt
|
||||
Test: URL für ein zwischenzeitlich gelöschtes Objekt wird abgelehnt"
|
||||
FDN-11,Ressourcenlimits für asynchrone Verarbeitungsjobs,⚙️ Fundament,Backend,Mittel,2,12,Fertig,"Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)","FDN-04 verarbeitet OCR/Konvertierung/Indexierung/Exporte mit Wiederholungslogik, Backoff und Dead-Letter-Queue, ohne Obergrenzen pro Einzeljob festzulegen. Eine sehr große oder speziell präparierte Datei (z. B. sehr viele Seiten, Zip-Bomb-artige Kompression bei Konvertierung) kann einen Worker dauerhaft blockieren und damit die Verarbeitung für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job abgebrochen, in die Dead-Letter-Queue verschoben und der Nutzer informiert, statt den Worker zu blockieren.",FDN-04,,"Jeder Verarbeitungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl
|
||||
Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers
|
||||
Andere, gleichzeitig laufende Jobs (auch anderer Mandanten) bleiben von einem überschreitenden Job unbeeinflusst","Test mit einer Datei, die absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen
|
||||
Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs
|
||||
Test der Nutzerbenachrichtigung bei abgebrochenem Job"
|
||||
VER-08,Technische Durchsetzung Append-only für das Versionierungs-/Ereignisprotokoll,🔄 Versionierung & Audit,Backend,Einfach,2,12,Fertig,"PostgreSQL (REVOKE/Trigger), Go","VER-05 konzipiert ein unveränderliches, verkettetes Protokoll aller sicherheits- und geschäftsrelevanten Ereignisse, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.",VER-05,,"Die vom DMS-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen
|
||||
Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert
|
||||
Die Verkettung (Unversehrtheitsnachweis) aus VER-05 bleibt vollständig nutzbar","Testet UPDATE/DELETE gegen die Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung
|
||||
Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
|
||||
Regressionstest: Verkettungsprüfung (Unversehrtheitsnachweis) funktioniert nach der Rechteänderung weiterhin"
|
||||
DOC-18,Obergrenze für Gesamtgröße/Anzahl bei Archiv-Bündelung,🗂️ Dokumentenkern,Backend,Einfach,1,13,Fertig,"Postgres-Jobqueue, Ressourcenlimits, Go","DOC-08 bündelt mehrere ausgewählte Dokumente als Hintergrund-Job zu einem Archiv, ohne Obergrenze für Gesamtgröße oder Anzahl der Dokumente je Anfrage. Eine übermäßig große Auswahl kann sonst den Bündelungs-Job unverhältnismäßig lange laufen lassen und Ressourcen auf Kosten anderer Mandanten binden. Harte, konfigurierbare Obergrenze für maximale Gesamtgröße und maximale Dokumentanzahl je Bündelungs-Anfrage einführen – bei Überschreitung wird die Anfrage mit klarer Fehlermeldung abgelehnt, bevor der Job gestartet wird.",DOC-08,,"Eine Bündelungs-Anfrage mit konfigurierbar zu großer Gesamtgröße oder Dokumentanzahl wird vor Jobstart abgelehnt, mit klarer Fehlermeldung an den Nutzer
|
||||
Innerhalb der Obergrenze funktioniert die Bündelung aus DOC-08 unverändert
|
||||
Die Obergrenzen sind konfigurierbar, nicht hart im Code verankert","Test: Anfrage mit Auswahl oberhalb der konfigurierten Obergrenze wird abgelehnt, kein Job wird gestartet
|
||||
Test: Anfrage innerhalb der Obergrenze wird normal verarbeitet
|
||||
Regressionstest bestehender DOC-08-Funktionalität nach Einführung der Prüfung"
|
||||
|
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,50 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>DMS Kanban – lokal</title>
|
||||
<link rel="stylesheet" href="../_shared/kanban.css">
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<div class="row">
|
||||
<h1>DMS Kanban <span class="sub">– lokal, offline, ohne Server</span></h1>
|
||||
<input id="q" placeholder="Suche: Code, Titel, Technik …" style="min-width:220px" />
|
||||
<select id="fEpic"><option value="">Alle Epics</option></select>
|
||||
<select id="fRole"><option value="">Alle Rollen</option></select>
|
||||
<select id="fWave"><option value="">Alle Wellen</option></select>
|
||||
<button id="onlyReady">Nur startbare</button>
|
||||
<button id="exportBtn">Stand sichern</button>
|
||||
<button id="resetBtn">Zurücksetzen</button>
|
||||
</div>
|
||||
<div class="stats" id="stats"></div>
|
||||
</header>
|
||||
<div class="board" id="board"></div>
|
||||
|
||||
<dialog id="dlg">
|
||||
<div class="dlg-head">
|
||||
<div>
|
||||
<div class="code" id="dCode" style="font-family:ui-monospace,Menlo,monospace;font-size:11px;color:var(--muted)"></div>
|
||||
<div id="dTitle" style="font-size:18px;font-weight:600;margin-top:4px"></div>
|
||||
<div id="dMeta" style="margin-top:8px"></div>
|
||||
</div>
|
||||
<div class="row">
|
||||
<button class="primary" id="copyBtn">Prompt kopieren</button>
|
||||
<button id="closeBtn">Schließen</button>
|
||||
</div>
|
||||
</div>
|
||||
<div class="dlg-body">
|
||||
<p id="dDesc" style="font-size:13px;color:#C7D3E5;line-height:1.6;margin-top:0"></p>
|
||||
<h3>Baut auf</h3><div id="dDeps"></div>
|
||||
<h3>Schaltet frei</h3><div id="dNext"></div>
|
||||
<h3>Akzeptanzkriterien</h3><ul id="dAcc"></ul>
|
||||
<h3>Prüfungen vor der Abnahme</h3><ul id="dChk"></ul>
|
||||
<h3>Bau-Prompt</h3><pre id="dPrompt"></pre>
|
||||
</div>
|
||||
</dialog>
|
||||
|
||||
<script id="data" type="application/json">{"erzeugtAm": "2026-08-26", "totalDays": 230, "epics": [{"key": "FDN", "name": "Fundament", "emoji": "⚙️", "color": "#64748B", "description": "Projektgerüst, Datenmodell, Storage, Queue, Auth-Basis, CI und Observability. Alles andere baut hierauf auf."}, {"key": "DOC", "name": "Dokumentenkern", "emoji": "🗂️", "color": "#3B82F6", "description": "Upload, Vorschau, Download, Ablagestruktur und Papierkorb – das funktionale Herz des DMS."}, {"key": "SRC", "name": "Suche & OCR", "emoji": "🔍", "color": "#06B6D4", "description": "Volltextindex, OCR-Pipeline, Facetten und gespeicherte Suchen."}, {"key": "MET", "name": "Metadaten", "emoji": "🏷️", "color": "#10B981", "description": "Tags, benutzerdefinierte Felder, Dokumententypen und automatische Klassifizierung."}, {"key": "VER", "name": "Versionierung & Audit", "emoji": "🔄", "color": "#EC4899", "description": "Versionskontrolle, Historie, revisionssicherer Audit-Trail und Signatur."}, {"key": "INT", "name": "Integration & API", "emoji": "🔌", "color": "#14B8A6", "description": "Öffentliche REST-API, E-Mail-Import, Webhooks und Scanner-Anbindung."}, {"key": "UX", "name": "UX & Zugänglichkeit", "emoji": "📱", "color": "#F97316", "description": "Responsive Ansicht, Theming, Mehrsprachigkeit und Barrierefreiheit."}, {"key": "QA", "name": "Prüfungen & Qualitätssicherung", "emoji": "✅", "color": "#22C55E", "description": "Teststrategie und verbindliche Prüfgates je Ausbaustufe. Ein Gate schließt eine Ausbaustufe ab."}], "waves": [{"welle": 1, "codes": ["FDN-01", "UX-01", "UX-02", "UX-03"]}, {"welle": 2, "codes": ["FDN-02", "FDN-03", "FDN-07", "FDN-08", "FDN-09", "SRC-01", "UX-04", "UX-05"]}, {"welle": 3, "codes": ["DOC-01", "DOC-09", "FDN-04", "MET-01", "MET-02", "QA-01", "QA-11", "VER-05"]}, {"welle": 4, "codes": ["DOC-02", "DOC-03", "DOC-04", "DOC-06", "DOC-07", "DOC-10", "DOC-11", "DOC-14", "DOC-15", "INT-01", "INT-03", "INT-08", "MET-03", "MET-04", "QA-02", "QA-07", "VER-01", "VER-06", "INT-11", "INT-12", "INT-13"]}, {"welle": 5, "codes": ["DOC-05", "DOC-08", "DOC-12", "INT-09", "SRC-02", "SRC-05", "VER-02", "VER-03", "VER-07"]}, {"welle": 6, "codes": ["DOC-13", "INT-06", "MET-05", "QA-03", "SRC-03", "SRC-06", "SRC-07", "VER-04"]}, {"welle": 7, "codes": ["INT-04", "INT-10", "QA-08", "QA-10", "SRC-04", "SRC-08", "QA-05"]}, {"welle": 8, "codes": ["QA-09", "SRC-09", "SRC-10"]}, {"welle": 9, "codes": ["QA-04"]}, {"welle": 10, "codes": ["QA-06"]}, {"welle": 11, "codes": ["QA-12"]}, {"welle": 12, "codes": ["INT-14", "INT-15", "INT-16", "DOC-17", "FDN-10", "FDN-11", "VER-08"]}, {"welle": 13, "codes": ["DOC-18"]}], "kritischerPfad": {"tage": 28, "pfad": ["FDN-01", "FDN-02", "DOC-01", "DOC-04", "DOC-05", "VER-04", "QA-08", "QA-12"]}, "produktDna": {"uebernehmen": [{"produkt": "paperless-ngx", "staerke": "Kompromisslose Erfassungs-Pipeline: Consume-Ordner, Vorverarbeitung, OCR, durchsuchbares PDF/A – vollautomatisch ohne Nutzerinteraktion."}, {"produkt": "paperless-ngx", "staerke": "Regelwerk für automatische Zuordnung von Korrespondent, Dokumenttyp und Tags direkt beim Import."}, {"produkt": "Docspell", "staerke": "Sprachverarbeitende Extraktion konkreter Werte: Absender, Datum, Betrag, Vertragspartner werden als strukturierte Felder vorgeschlagen."}, {"produkt": "Docspell", "staerke": "Sauberes Mandanten- und Datenmodell sowie ausgereifter Postfach-Abruf inklusive Anhangbehandlung."}, {"produkt": "Alfresco", "staerke": "Vererbende Zugriffskontrolle über die Ablagehierarchie mit expliziten Erlaubnissen und Verboten."}, {"produkt": "Alfresco", "staerke": "Echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik."}, {"produkt": "Alfresco", "staerke": "Versionierung mit Ausleihen/Einchecken sowie Aufbewahrungssteuerung inklusive Aufbewahrungssperre."}, {"produkt": "ecoDMS", "staerke": "Revisionssicherheit als Grundhaltung: unveränderliches Protokoll, nachvollziehbare Vernichtung, Vier-Augen-Freigabe."}, {"produkt": "ecoDMS", "staerke": "Praxisnaher Scanner- und Stapelworkflow mit Trennseiten und Klassifizierungsvorlagen."}], "vermeiden": [{"produkt": "Alfresco", "schwaeche": "Schwergewichtige Plattform mit hohem Ressourcenbedarf, langer Startzeit und aufwendigem Betrieb.", "gegenmittel": "Schlanker Dienst plus getrennte Worker. Jede Komponente muss auf einem kleinen Server startklar sein."}, {"produkt": "Alfresco", "schwaeche": "Übermächtiges Konfigurationsmodell mit steiler Lernkurve und träger Oberfläche.", "gegenmittel": "Sinnvolle Voreinstellungen, die ohne Konfiguration funktionieren. Komplexität nur dort, wo sie nachweislich gebraucht wird."}, {"produkt": "paperless-ngx", "schwaeche": "Kaum Governance: keine echte Rechtevererbung, keine Freigabeprozesse, keine Versionen, kein belastbares Protokoll.", "gegenmittel": "Rechte, Versionierung und Protokoll gehören von Anfang an ins Fundament, nicht als Nachrüstung."}, {"produkt": "paperless-ngx", "schLine truncated
|
||||
<script src="../_shared/kanban.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,25 @@
|
||||
# Bekannte Fehler in archivdms — zu vermeiden in NEXARCH DMS
|
||||
|
||||
Ermittelt am 2026-08-25 per Code-Audit von `repos/archivdms`. Dient als Vermeidungs-Checkliste für den kompletten Neubau (siehe `reuse-mapping.md`).
|
||||
|
||||
## Sicherheit / Datenintegrität
|
||||
|
||||
1. **`go.sum` fehlt komplett** (DEVLOG.md:102) — `go test ./...` schlägt in DB-/Crypto-Paketen fehl. → `go.sum` von Anfang an committen, CI-Gate `go mod verify`.
|
||||
2. **Kaum Unit-Tests** für kritische Pakete: nur 2 `_test.go` in ganz `internal/`, 0 für `auth`, `storage` (Tenant-Isolation, Retention/WORM), `ldapstore`, `permissions.go`. → Testpflicht für Auth/Tenant-Scoping/Retention als Merge-Gate.
|
||||
3. **Rechte-Bug**: frische Uploads für Ersteller selbst unsichtbar — ACL (`internal/storage/permissions.go`, `RecomputeVisibility`) vergab Sichtbarkeit nur über Gruppen-Grants (DEVLOG.md:1087). → Expliziter "Ersteller sieht immer sein Dokument"-Pfad von Anfang an im Datenmodell.
|
||||
4. **Superadmin-Sonderfall wiederholt vergessen**: 403 "tenant context required" für Superadmin mehrfach gepatcht (DEVLOG.md:1146, 4144). → Superadmin-ohne-Tenant als First-Class-Zustand im Datenmodell.
|
||||
|
||||
## Robustheit / Fehlerbehandlung
|
||||
|
||||
5. **pgx-Typmismatch bei Intervall-Queries**, 2x derselbe Bug (`processing_jobs.go` Z.314, Z.290) durch `($1 || ' seconds')::interval` statt Cast. → Arithmetischen Cast als verbindliche Konvention.
|
||||
6. **Nil-Slice → JSON `null` statt `[]`**, ≥8x wiederholter Frontend-Crash, jedes Mal einzeln mit `?? []` gepatcht statt an der Wurzel behoben (DEVLOG.md:1078, 1120). → Backend-Konvention: jeder Listen-Handler liefert `make([]T, 0)`, per Lint erzwingen.
|
||||
7. **Silent-Fail durch Logger-Wiring-Fehler** (`cmd_documents_reprocess_all.go`) — Logger nie verdrahtet, CLI-Pfad ohne Debug-Logs (DEVLOG.md:531). → Logger-Injection zentral über DI/Konstruktor-Pflichtfeld.
|
||||
8. **OCR-Bug-Kette durch Code-Duplikation**: 4 Bugs in Koordinaten-Transform (Deskew/EXIF/OSD), Ursache ~35 Zeilen dupliziertes Boilerplate in 5 Funktionen (DEVLOG.md:346-354). → Gemeinsame Koordinatentransform-Utility mit Property-Tests.
|
||||
|
||||
## Betrieb / Skalierung
|
||||
|
||||
9. **In-Memory Rate-Limiter ohne Shared State** (`internal/auth/ratelimit.go`) — bei Mehrinstanz-Deployment pro Instanz getrennt, aushebelbar. → Bei Mehrinstanz-Betrieb Rate-Limit-State extern (Redis/DB) oder Single-Instance-Constraint dokumentieren.
|
||||
10. **Dynamische Tabellennamen via `fmt.Sprintf` in SQL** (`taxonomy.go:281`, `workflows.go:611`, `classification_templates_title.go:102`, `internal/index/manticore.go`) — aktuell durch Whitelist-Funktion abgesichert, aber fragiles Muster. → Geschlossener Enum/Switch-Typ statt Sprintf-in-SQL.
|
||||
|
||||
## Positiv zu übernehmende Muster (kein Fehler)
|
||||
Tenant-Filter (`WHERE ... AND tenant_id = $n`), IDOR-Guards bei Shares, Vier-Augen-Prinzip bei Löschbestätigung mit `FOR UPDATE`-Lock, Timing-safe Passwortvergleich bei Share-Links.
|
||||
@@ -0,0 +1,17 @@
|
||||
# Bekannte Fehler in archivmail — zu vermeiden in NEXARCH (DMS + späteres Mail-Modul)
|
||||
|
||||
Ermittelt am 2026-08-25 per Code-Audit von `repos/archivmail`. Mail-spezifische Punkte (IMAP/SMTP/Mailer) gelten primär für das künftige NEXARCH-Mail-Board; die Muster zu SQL/Tenant-Scoping/Attachment-Handling/Tests betreffen auch NEXARCH DMS direkt.
|
||||
|
||||
1. **Header-Injection**: `internal/mailer/mailer.go:144-146` — From/To/Subject per Stringkonkatenation ohne CRLF-Validierung. → `net/mail`-Writer nutzen oder Headerwerte hart auf CRLF/Steuerzeichen prüfen. (Mail-Board)
|
||||
2. **Login ohne Tenant-Filter**: `internal/userstore/userstore.go:338` — `SELECT ... WHERE email=$1` ohne tenant_id → Cross-Tenant-Verwechslungsrisiko. → E-Mail global unique erzwingen oder Lookup zusätzlich scopen. **(betrifft auch DMS: IAM-01/IAM-02 — jeden Login-Query auf Tenant-Scoping prüfen)**
|
||||
3. **Ungebremstes Anhang-Lesen**: `pkg/mailparser/parser.go:199,214,254,343` — `io.ReadAll` ohne Größenlimit → Speicherbombe. → `io.LimitReader` mit Max-Size, harte Ablehnung. **(betrifft auch DMS: DOC-01 Upload-API — Größenlimit von Anfang an, nicht nachrüsten)**
|
||||
4. **Kaum Tests**: nur 2 von 18 Modulen getestet (`auth`, `imap/folder_state`), `tenantstore`/`imapserver`/`smtpd`/`pop3` ohne Tests. → Pflichttests für Tenant-Scoping/Protokoll-State-Machines vor Merge. **(betrifft auch DMS: QA-01 Teststrategie)**
|
||||
5. **IMAP-Resync-Bug** (`internal/imap/scheduler.go:410`, Kommentar "BUG-1 UIDVALIDITY=0"): nicht-konforme Server brachen Resync. → Defensive Validierung + Fallback-Tests. (Mail-Board)
|
||||
6. **Privilege-Escalation-Lücke gepatcht**: `internal/api/ldap_handlers.go:191` — Rollenzuweisung nachträglich gehärtet. → Rollen-Erlaubnis-Matrix von Anfang an testgestützt. **(betrifft auch DMS: IAM-02/IAM-07 LDAP-Abgleich)**
|
||||
7. **Tenant-Filter als Post-Filter statt in Query**: `internal/api/ediscovery.go:90` — fehleranfällig bei neuen Codepfaden. → Tenant-Scoping ausschließlich in Query-/Repository-Schicht. **(betrifft auch DMS: IAM-03 Policy-Enforcement — zentral, nicht pro Handler)**
|
||||
8. **Attachment-Preview Content-Type-Erkennung über Dateiendung, fragile Guard-Reihenfolge**: `src/components/mail/AttachmentPreviewDialog.tsx:74,199`. → Content-Type serverseitig via Magic-Bytes, State-Machine explizit modellieren. **(betrifft auch DMS: DOC-05 PDF-Viewer)**
|
||||
9. **iframe-PDF-Vorschau als unsicher verworfen**, `PdfCanvasPreview.tsx:7-17` — positiv: Canvas-Rendering statt iframe. → Für NEXARCH DMS-Viewer (DOC-05) von Anfang an Canvas-Rendering, kein iframe/HTML-Rendering von Fremdinhalt.
|
||||
10. **Restore-Datenintegritätsbug** (`cmd_backup.go:206`, "BUG-2, -force restore where destination isn't empty"). → Restore immer in leeres Temp-Verzeichnis + atomarer Swap. **(betrifft auch DMS: REP-06 Sicherung & Wiederherstellung)**
|
||||
11. **Dynamische SQL-Klauseln via Sprintf/Join**: `internal/index/manticore.go:268,323`. → Spalten-/Tabellennamen nur aus statischen Konstanten. **(betrifft auch DMS: SRC-01/SRC-03 Suchindex/Such-API)**
|
||||
12. **Gleiches Muster dupliziert**: `internal/storage/ocr.go:159` (`whereClause = "WHERE " + joinAnd(...)`). → Zentraler getesteter Query-Builder mit Feld-Whitelist. **(betrifft auch DMS: mehrere API-Handler)**
|
||||
13. **Kein zentrales Issue-Tracking** — Bugs nur als `BUG-N`-Kommentare im Code, kein Tracker. → NEXARCH: Bugs/Fixes durchsuchbar tracken, damit wiederkehrende Muster sichtbar werden. (projektweit)
|
||||
@@ -0,0 +1,158 @@
|
||||
# NEXARCH DMS – Entscheidung: kompletter Neubau
|
||||
|
||||
Entscheidung 2026-08-25: NEXARCH DMS wird komplett neu gebaut — KEIN Codeimport aus archivdms/archivmail, auch nicht für Auth/Storage/Tenant/Queue-Grundgerüst. Grund: bekannte Code-Fehler aus archivdms sollen nicht in NEXARCH übernommen werden, nicht eine Ablehnung von Datenmodell oder Konzept an sich.
|
||||
|
||||
archivdms/archivmail dienen ausschließlich als **Konzeptreferenz** (Spalte "Quelle" unten zeigt, wo die alte Lösung technisch nachgesehen werden kann, um Fehler nicht zu wiederholen oder bewährte Prinzipien zu erkennen — nicht zum Kopieren).
|
||||
|
||||
Techstack-Entscheidung bleibt unabhängig davon bestehen (Go-Backend, PostgreSQL/pgx, Manticore Search, Postgres-Jobqueue statt Redis, bcrypt) — das ist eine Technologiewahl, kein Codeimport.
|
||||
|
||||
Alle 86 Tickets daher: **NEU**.
|
||||
|
||||
## ⚙️ Fundament
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| FDN-01 | NEU |archivdms/ (Repo-Layout: cmd/, internal/, src/) (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| FDN-02 | NEU |archivdms/internal/storage/migrations/ (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| FDN-03 | NEU |archivdms/internal/objectstore/local.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| FDN-04 | NEU |archivdms/internal/jobqueue/jobqueue.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| FDN-05 | NEU |archivdms/internal/auth/auth.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| FDN-06 | NEU |archivdms/src/components/shell, ui (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| FDN-07 | NEU |archivdms/.gitea/workflows (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| FDN-08 | NEU |archivdms/internal/api/observability.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
|
||||
## 🗂️ Dokumentenkern
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| DOC-01 | NEU |archivdms/internal/api/document_handlers.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-02 | NEU |archivdms/internal/storage/documents.go (content_hash) (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-03 | NEU |archivdms/src/components/documents (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-04 | NEU |archivdms/internal/thumbnail/thumbnail.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-05 | NEU |archivdms/src/components/documents (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-06 | NEU |archivdms/internal/ocr/convert.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-07 | NEU |archivdms/internal/api/signed_url_handlers.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-08 | NEU |archivdms/internal/api/document_bulk_export_handlers.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-09 | NEU |archivdms/internal/storage/akten.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-10 | NEU |archivdms/src/components/akten (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-11 | NEU |archivdms/internal/storage/trash.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| DOC-12 | NEU |archivdms/src/components/trash (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
|
||||
## 🏷️ Metadaten
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| MET-01 | NEU |archivdms/internal/storage/taxonomy.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| MET-02 | NEU |archivdms/internal/storage/custom_fields.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| MET-03 | NEU |archivdms/src/components/custom-fields, taxonomy (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| MET-04 | NEU |archivdms/internal/storage/classification_templates.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| MET-05 | NEU |archivdms/internal/storage/metadata_suggestions_naivebayes.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
|
||||
## 🔍 Suche & OCR
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| SRC-01 | NEU |archivdms/internal/index/manticore.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| SRC-02 | NEU |archivdms/internal/storage/index_sync.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| SRC-03 | NEU |archivdms/internal/index/index.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| SRC-04 | NEU |archivdms/src/components/search (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| SRC-05 | NEU |archivdms/internal/ocr/ocr.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| SRC-06 | NEU | - | Kein PDF/A-Erzeugung (ocrmypdf) in Altsystemen |
|
||||
| SRC-07 | NEU |archivdms/internal/ocr/ocr.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| SRC-08 | NEU |archivdms/internal/storage/documents.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| SRC-09 | NEU | - | Kein dediziertes Filter-Panel im Frontend |
|
||||
| SRC-10 | NEU |archivdms/internal/storage/saved_views.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
|
||||
## 📱 UX & Zugänglichkeit
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| UX-01 | NEU |archivdms/src/components/shell (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| UX-02 | NEU |archivdms/src/components/theme-provider.tsx (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| UX-03 | NEU | - | Keine i18n-Infrastruktur in Altsystemen |
|
||||
| UX-04 | NEU | - | Keine Übersetzungsdateien vorhanden |
|
||||
| UX-05 | NEU | - | Kein WCAG-Audit/A11y-Grundlage vorhanden |
|
||||
|
||||
## 👥 Identität & Rechte
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| IAM-01 | NEU |archivdms/internal/userstore/userstore.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| IAM-02 | NEU |archivdms/internal/storage/permissions.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| IAM-03 | NEU |archivdms/internal/storage/permissions.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| IAM-04 | NEU |archivdms/src/components/permissions (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| IAM-05 | NEU | - | Kein Gruppen-/Abteilungsmodell in Altsystemen |
|
||||
| IAM-06 | NEU | - | Kein OIDC/SSO in archivdms oder archivmail |
|
||||
| IAM-07 | NEU |archivmail/internal/api/ldap_sync.go, ldap_tenants.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
|
||||
## 🔄 Versionierung & Audit
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| VER-01 | NEU | - | Kein Check-in/Check-out/Versionsmodell vorhanden |
|
||||
| VER-02 | NEU | - | Keine Versionsansicht/Restore-UI vorhanden |
|
||||
| VER-03 | NEU | - | Keine Änderungshistorie/Diff-Berechnung vorhanden |
|
||||
| VER-04 | NEU | - | Keine Diff-Ansicht im Frontend |
|
||||
| VER-05 | NEU |archivdms/internal/audit/audit.go, archivmail/internal/audit/audit.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| VER-06 | NEU |archivmail/internal/api (audit export) (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| VER-07 | NEU | - | Digitale Signatur in keinem Altsystem vorhanden |
|
||||
|
||||
## 📋 Workflow
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| WFL-01 | NEU |archivdms/internal/storage/workflows.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| WFL-02 | NEU |archivdms/src/components (kein workflow-UI Ordner) (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| WFL-03 | NEU |archivdms/src/components/reminders (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| WFL-04 | NEU |archivdms/internal (reminders) (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| WFL-05 | NEU |archivdms/internal/mailer/mailer.go, templates.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| WFL-06 | NEU | - | Keine Benachrichtigungs-Einstellungs-UI |
|
||||
| WFL-07 | NEU |archivdms/internal/storage/workflows.go (matching) (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
|
||||
## 🔌 Integration & API
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| INT-01 | NEU |archivmail/internal/api/v1_handlers.go, openapi.yaml (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| INT-02 | NEU |archivmail/internal/auth/apikey_middleware.go, apikey_handlers.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| INT-03 | NEU |archivmail/internal/imap/ (client, importer, scheduler) (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| INT-04 | NEU |archivmail/internal/api/rules_handlers.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| INT-05 | NEU | - | Keine Webhook-Registry in Altsystemen |
|
||||
| INT-06 | NEU |archivdms/internal/sftpserver, pagesplit, barcode (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
|
||||
## ✅ Prüfungen & Qualitätssicherung
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| QA-01 | NEU |archivdms/.gitea/workflows, features/ (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| QA-02 | NEU |archivdms CI-Setup (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| QA-03 | NEU |archivdms internal/*_test.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| QA-04 | NEU |archivdms/internal/api/observability_test.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| QA-05 | NEU | - | Kein Prüfgate für Klassifizierung vorhanden |
|
||||
| QA-06 | NEU |archivmail/internal/auth/auth_test.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| QA-07 | NEU | - | Kein Workflow/Notification-Prüfgate vorhanden |
|
||||
| QA-08 | NEU |archivdms/internal/audit, archivmail/internal/audit (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| QA-09 | NEU | - | Keine Contract-Tests für Schnittstellen vorhanden |
|
||||
| QA-10 | NEU | - | Kein Last-/Performance-Test-Setup vorhanden |
|
||||
| QA-11 | NEU | - | Kein A11y-Audit-Tooling vorhanden |
|
||||
| QA-12 | NEU | - | Kein Abnahme-/Compliance-Prüfprozess vorhanden |
|
||||
|
||||
## 📊 Reporting & Archiv
|
||||
|
||||
| Code | Verdict | Quelle | Kurznotiz |
|
||||
|---|---|---|---|
|
||||
| REP-01 | NEU |archivdms/internal/storage/dashboard.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| REP-02 | NEU |archivdms Dashboard-Backend, kein UI-Ordner (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| REP-03 | NEU |archivdms/internal/storage/retention_rules.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| REP-04 | NEU |archivdms/internal/storage/trash.go (Vier-Augen) (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| REP-05 | NEU |archivmail/internal/api/dsgvo_handlers.go, storage/dsgvo_requests.go (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
| REP-06 | NEU |archivmail/deploy/cron.d (archivmail backup), reconciliation/ (nur Konzeptreferenz, kein Codeimport) | Neu entworfen |
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
- ÜBERNEHMEN: 40
|
||||
- TEILWEISE: 24
|
||||
- NEU: 22
|
||||
|
||||
@@ -0,0 +1,200 @@
|
||||
# tickets – Dev Log
|
||||
|
||||
## 2026-09-12 21:25 – 21:27 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
Keine Änderungen ermittelbar.
|
||||
|
||||
---
|
||||
## 2026-09-18 13:41 – 13:41 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** code
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- archive-kanban/board.json | 3062 +++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------
|
||||
|
||||
---
|
||||
## 2026-09-20 01:04 – 01:04 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** code-integ
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 01:10 – 01:11 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** banking
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 01:14 – 01:15 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 01:17 – 01:17 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 01:29 – 01:29 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 08:56 – 08:56 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 09:05 – 09:06 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 09:18 – 09:18 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** banking
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 09:27 – 09:27 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-17.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 09:28 – 09:28 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** n8n-setup
|
||||
|
||||
### Commits
|
||||
- defe256 dms-kanban: Ticket FDN-18 (Verdrahtung der Suche in Worker und App) anlegen
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-18.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 09:56 – 09:56 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-18.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 10:00 – 10:00 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-18.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 10:05 – 10:05 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-18.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 19:44 – 19:44 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** nexarch
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-18.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 19:55 – 19:55 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-18.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-20 20:01 – 20:01 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** tickets
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- dms-kanban/tickets/FDN-18.md | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
@@ -0,0 +1,79 @@
|
||||
# DOC-01 – Upload-API & Chunk-Handling
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
|
||||
**Technische Grundlage:** tus.io / Multipart-Upload
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Erfassen muss so anspruchslos sein wie das Ablegen einer Datei im Consume-Ordner von paperless-ngx – zusätzlich fortsetzbar bei Abbruch.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-02` Datenmodell & Migrationen – Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.
|
||||
- `FDN-03` Objekt-Storage-Abstraktion – Storage-Adapter mit einheitlicher Schnittstelle für Ablegen, Lesen, Löschen und signierte URLs. Lokaler Treiber für Entwicklung, S3 für Produktion.
|
||||
- `FDN-09` Verschlüsselung at rest & Schlüsselverwaltung – Envelope-Encryption-Modul mit Encrypt/Decrypt-Schnittstelle über Streams, das von der Storage-Abstraktion beim Ablegen/Lesen genutzt wird.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Fortsetzbarer Upload nach Verbindungsabbruch
|
||||
2. Unerlaubte Dateitypen werden abgewiesen
|
||||
3. Dokument und Revision werden transaktional angelegt
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Upload von 1 GB Datei erfolgreich
|
||||
2. Abbruch bei 50 % und Fortsetzung ergibt identische Prüfsumme
|
||||
3. Parallel-Upload von 20 Dateien ohne Datenverlust
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Ungebremstes Lesen von Anhängen/Uploads**: Ein Vorgängerprojekt las Anhänge ohne Größenlimit vollständig in den Speicher, was eine Speicherbombe ermöglichte. → Von Anfang an mit einem Limit-Reader/Max-Size arbeiten und Uploads über dem Limit hart ablehnen, statt das Limit nachträglich nachzurüsten.
|
||||
- **Reihenfolge beachten**: SHA-256-Hash für Dublettenerkennung (DOC-02) wird auf dem Klartext berechnet, bevor die Verschlüsselung aus FDN-09 angewendet wird – nicht danach.
|
||||
- **Verarbeitungsreihenfolge nach Upload**: Hash-Berechnung & Duplikatsprüfung (DOC-02) zuerst, danach erst Verschlüsselung (FDN-09) für neue/bewusste Duplikate, danach OCR (SRC-05) und Indexierung (SRC-02) – niemals umgekehrt.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-02` Dublettenerkennung
|
||||
- `DOC-03` Drag-and-Drop-Upload-Oberfläche
|
||||
- `DOC-04` Vorschau- & Thumbnail-Pipeline
|
||||
- `DOC-07` Download & signierte URLs
|
||||
- `SRC-02` Indexierungs-Worker & Synchronisierung
|
||||
- `SRC-05` OCR-Worker
|
||||
- `VER-01` Versionsmodell & Check-in/Check-out
|
||||
- `INT-01` REST-API v1 & Schnittstellenbeschreibung
|
||||
- `INT-03` E-Mail-Abruf über IMAP
|
||||
- `INT-06` Scanner-Anbindung über Hot-Folder
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-01: upload-api & chunk-handling`
|
||||
- Branch: `feature/doc-01-upload-api-chunk-handling`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,65 @@
|
||||
# DOC-02 – Dublettenerkennung
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Prüfsumme jeder Datei berechnen, speichern und bei Upload gegen den Bestand prüfen. Nutzer entscheidet über Verwerfen oder bewusstes Duplikat.
|
||||
|
||||
**Technische Grundlage:** SHA-256, Unique-Index
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** paperless-ngx erkennt Dubletten über Prüfsummen. Übernimm das und lasse bewusste Duplikate zu, statt sie stumm zu verwerfen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Prüfsumme wird bei jedem Upload persistiert
|
||||
2. Treffer wird dem Nutzer mit Verweis auf das Original gemeldet
|
||||
3. Bewusstes Duplikat ist möglich und wird markiert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Identische Datei zweimal hochgeladen erzeugt Warnung
|
||||
2. Datei mit einem geänderten Byte gilt nicht als Duplikat
|
||||
3. Prüfsummenberechnung bei Großdatei bleibt im Zeitbudget
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- Hash muss auf dem Klartext berechnet werden, nicht auf dem verschlüsselten Objekt (siehe FDN-09) – sonst erzeugt dieselbe Datei bei jedem Upload einen anderen Hash und Dublettenerkennung versagt vollständig.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-02: dublettenerkennung`
|
||||
- Branch: `feature/doc-02-dublettenerkennung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# DOC-03 – Drag-and-Drop-Upload-Oberfläche
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Frontend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
|
||||
|
||||
## Auftrag
|
||||
Upload-Oberfläche mit Ablagebereich, Mehrfachauswahl, Fortschritt je Datei, Abbrechen und verständlichen Fehlermeldungen.
|
||||
|
||||
**Technische Grundlage:** Dropzone, Fortschrittsanzeige
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Die Ablage-Oberfläche von Docspell ist funktional, aber spröde. Hier entsteht der erste Eindruck – investiere entsprechend.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System (zentral).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Mehrere Dateien gleichzeitig per Drag-and-Drop
|
||||
2. Fortschritt und Status je Datei sichtbar
|
||||
3. Fehlgeschlagene Datei einzeln wiederholbar
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Upload per Tastatur und Dateidialog bedienbar
|
||||
2. Verhalten bei Netzabbruch im Browser geprüft
|
||||
3. Mobile Ansicht bleibt bedienbar
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-03` Prüfgate Dokumentenkern
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-03: drag-and-drop-upload-oberfläche`
|
||||
- Branch: `feature/doc-03-drag-and-drop-upload-oberfläche`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,68 @@
|
||||
# DOC-04 – Vorschau- & Thumbnail-Pipeline
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 5 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Asynchrone Erzeugung von Seiten-Vorschauen und Thumbnails nach dem Upload, mit Cache und Wiederaufbau bei neuer Revision.
|
||||
|
||||
**Technische Grundlage:** Renderer-Worker, Bildableitungen
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Vorschaubilder beim Import erzeugen, wie paperless-ngx es tut. Ein fehlerhaftes Dokument darf die Strecke nie anhalten.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
- `FDN-04` Job-Queue & Worker-Runtime – Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Thumbnail steht nach definierter Zeit bereit
|
||||
2. Vorschau wird gecacht und bei neuer Revision erneuert
|
||||
3. Fehlerhafte Datei blockiert die Pipeline nicht
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Beschädigte PDF-Datei führt zu Fehlerstatus statt Absturz
|
||||
2. Durchsatztest mit 500 Dokumenten
|
||||
3. Cache-Invalidierung bei neuer Revision belegt
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Content-Type-Erkennung über Dateiendung ist fragil**: Ein Vorgängerprojekt erkannte den Content-Type von Vorschau-Dateien über die Dateiendung mit fragiler Guard-Reihenfolge. → Content-Type serverseitig über Magic-Bytes bestimmen und den Vorschau-Zustand als explizite State-Machine modellieren.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-05` PDF-Viewer-Komponente
|
||||
- `QA-10` Last- & Leistungstest
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-04: vorschau- & thumbnail-pipeline`
|
||||
- Branch: `feature/doc-04-vorschau-thumbnail-pipeline`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,69 @@
|
||||
# DOC-05 – PDF-Viewer-Komponente
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Frontend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Frontend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
|
||||
|
||||
## Auftrag
|
||||
Inline-Betrachter mit Seitennavigation, Zoom, Suche im Dokument und Textauswahl – ohne Download-Zwang.
|
||||
|
||||
**Technische Grundlage:** PDF.js im Web-Worker
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Vollwertige Anzeige im Browser. ecoDMS verlangt dafür einen eigenen Arbeitsplatz-Client – genau das entfällt hier.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-04` Vorschau- & Thumbnail-Pipeline – Asynchrone Erzeugung von Seiten-Vorschauen und Thumbnails nach dem Upload, mit Cache und Wiederaufbau bei neuer Revision.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System (zentral).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. PDF wird ohne Download angezeigt
|
||||
2. Zoom, Blättern und Textsuche funktionieren
|
||||
3. Große Dokumente werden seitenweise nachgeladen
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. 300-seitiges PDF öffnet im Zeitbudget
|
||||
2. Viewer per Tastatur bedienbar
|
||||
3. Speicherverbrauch im Browser bleibt stabil
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Content-Type-Erkennung über Dateiendung ist fragil**: Ein Vorgängerprojekt erkannte den Content-Type für die Anhang-/Dokumentvorschau über die Dateiendung mit fragiler Guard-Reihenfolge. → Content-Type serverseitig über Magic-Bytes bestimmen und den Vorschau-Zustand explizit als State-Machine modellieren.
|
||||
- **iframe-Vorschau als unsicher verworfen**: Ein Vorgängerprojekt musste die PDF-Vorschau von iframe auf Canvas-Rendering umstellen, weil iframe Fremdinhalt unkontrolliert rendert. → Für den PDF-Viewer von Anfang an Canvas-Rendering einsetzen, kein iframe/HTML-Rendering von Fremdinhalt.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `VER-04` Diff-Ansicht
|
||||
- `QA-03` Prüfgate Dokumentenkern
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-05: pdf-viewer-komponente`
|
||||
- Branch: `feature/doc-05-pdf-viewer-komponente`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,67 @@
|
||||
# DOC-06 – Office-zu-PDF-Konverter
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Serverseitige Konvertierung von Text-, Tabellen- und Präsentationsformaten in PDF als Vorschau- und Archivderivat.
|
||||
|
||||
**Technische Grundlage:** Headless-Konverter im Worker
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Alfresco löst die Umwandlung über einen eigenen Dienst. Übernimm die Idee, aber isoliert, mit Zeitlimit und ohne Rückwirkung auf andere Aufträge.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-04` Job-Queue & Worker-Runtime – Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Gängige Office-Formate werden konvertiert
|
||||
2. Konvertierung läuft isoliert mit Zeitlimit
|
||||
3. Ergebnis wird als Derivat der Revision abgelegt
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Layouttreue an Referenzdokumenten geprüft
|
||||
2. Zeitlimit bei Endlosdokument greift
|
||||
3. Konverter-Absturz beeinträchtigt andere Jobs nicht
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Bug-Kette durch Code-Duplikation**: Ein Vorgängerprojekt hatte mehrere Bugs in ähnlichen Transformations-/Konvertierungsfunktionen (Koordinaten, Formate), verursacht durch dupliziertes Boilerplate in mehreren Funktionen. → Gemeinsame, gut getestete Utility-Funktion (mit Property-Tests) statt paralleler Implementierungen für Format-/Koordinatentransformationen.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `VER-07` Digitale Signatur
|
||||
- `QA-03` Prüfgate Dokumentenkern
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-06: office-zu-pdf-konverter`
|
||||
- Branch: `feature/doc-06-office-zu-pdf-konverter`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# DOC-07 – Download & signierte URLs
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Download von Original und Derivaten über kurzlebige signierte URLs, inklusive korrektem Dateinamen und Berechtigungsprüfung.
|
||||
|
||||
**Technische Grundlage:** Presigned URLs
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Kurzlebige signierte Verweise statt Weiterleitung über den Anwendungsserver – schlanker als der Alfresco-Weg.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Download liefert Originaldatei unverändert
|
||||
2. URL läuft nach kurzer Frist ab
|
||||
3. Ohne Leseberechtigung kein Download
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Prüfsumme vor und nach Download identisch
|
||||
2. Weitergegebene abgelaufene URL wird abgewiesen
|
||||
3. Sonderzeichen im Dateinamen korrekt übertragen
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-08` Massenexport als ZIP
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-07: download & signierte urls`
|
||||
- Branch: `feature/doc-07-download-signierte-urls`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# DOC-08 – Massenexport als ZIP
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Auswahl mehrerer Dokumente als Hintergrund-Job zu einem Archiv bündeln, inklusive optionaler Metadaten-Datei und Download-Benachrichtigung.
|
||||
|
||||
**Technische Grundlage:** ZIP-Streaming, Export-Job
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Vollständiger Export ohne Herstellerwerkzeug ist die Antwort auf die Herstellerbindung von ecoDMS.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-07` Download & signierte URLs – Download von Original und Derivaten über kurzlebige signierte URLs, inklusive korrektem Dateinamen und Berechtigungsprüfung.
|
||||
- `FDN-04` Job-Queue & Worker-Runtime – Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Export läuft als Job und blockiert die Oberfläche nicht
|
||||
2. Archiv enthält Dokumente und Metadaten-Beilage
|
||||
3. Nur berechtigte Dokumente landen im Archiv
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Export von 1000 Dokumenten ohne Speicherüberlauf
|
||||
2. Archiv in gängigen Entpackern lesbar
|
||||
3. Berechtigungsfilter durch Negativtest belegt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-03` Prüfgate Dokumentenkern
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-08: massenexport als zip`
|
||||
- Branch: `feature/doc-08-massenexport-als-zip`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# DOC-09 – Ordner- & Kabinettmodell
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Hierarchische Ablage mit Verschieben, Umbenennen und effizienten Teilbaum-Abfragen.
|
||||
|
||||
**Technische Grundlage:** Baumstruktur, Materialized Path
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Die Hierarchie, die paperless-ngx fehlt, in der Vererbungslogik von Alfresco – aber ohne dessen Modellierungsaufwand.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-02` Datenmodell & Migrationen – Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Beliebig tiefe Hierarchie abbildbar
|
||||
2. Verschieben aktualisiert den gesamten Teilbaum
|
||||
3. Teilbaum-Abfrage bleibt performant
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Zyklus beim Verschieben wird verhindert
|
||||
2. Abfrage bei 10.000 Ordnern im Zeitbudget
|
||||
3. Umbenennen bricht keine Verweise
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-10` Ordner-Navigation & Dokumentenliste
|
||||
- `DOC-11` Soft-Delete & Papierkorb-Logik
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-09: ordner- & kabinettmodell`
|
||||
- Branch: `feature/doc-09-ordner-kabinettmodell`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# DOC-10 – Ordner-Navigation & Dokumentenliste
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Frontend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
|
||||
|
||||
## Auftrag
|
||||
Navigationsbaum, Brotkrumenpfad und virtualisierte Dokumentenliste mit Sortierung, Spaltenwahl und Mehrfachauswahl.
|
||||
|
||||
**Technische Grundlage:** Baum-Navigation, virtualisierte Liste
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Verschlagwortung und Ordner gleichberechtigt anbieten. Der Nutzer wählt seinen Weg, nicht das System.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-09` Ordner- & Kabinettmodell – Hierarchische Ablage mit Verschieben, Umbenennen und effizienten Teilbaum-Abfragen.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System (zentral).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Baum und Liste bleiben synchron
|
||||
2. Liste bleibt bei vielen Einträgen flüssig
|
||||
3. Mehrfachauswahl mit Umschalt- und Strg-Taste
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Liste mit 10.000 Zeilen scrollt ruckelfrei
|
||||
2. Navigation vollständig per Tastatur
|
||||
3. Zustand bleibt beim Zurücknavigieren erhalten
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-03` Prüfgate Dokumentenkern
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-10: ordner-navigation & dokumentenliste`
|
||||
- Branch: `feature/doc-10-ordner-navigation-dokumentenliste`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# DOC-11 – Soft-Delete & Papierkorb-Logik
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Löschen setzt einen Papierkorb-Status statt physischer Entfernung. Endgültige Bereinigung erfolgt nach konfigurierbarer Frist.
|
||||
|
||||
**Technische Grundlage:** Soft-Delete, Aufräum-Job
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Revisionssichere Systeme löschen nie sofort. Übernimm die Haltung von ecoDMS: Frist, dann Vernichtung mit Protokoll.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-09` Ordner- & Kabinettmodell – Hierarchische Ablage mit Verschieben, Umbenennen und effizienten Teilbaum-Abfragen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Gelöschte Objekte verschwinden aus allen normalen Ansichten
|
||||
2. Wiederherstellung stellt Ablageort und Metadaten wieder her
|
||||
3. Endgültige Löschung entfernt auch die Dateiobjekte
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Gelöschtes Dokument taucht in Suche und Liste nicht mehr auf
|
||||
2. Wiederherstellung nach Ordnerlöschung getestet
|
||||
3. Aufräum-Job löscht nur abgelaufene Einträge
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-12` Papierkorb-Oberfläche
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-11: soft-delete & papierkorb-logik`
|
||||
- Branch: `feature/doc-11-soft-delete-papierkorb-logik`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# DOC-12 – Papierkorb-Oberfläche
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Frontend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
|
||||
|
||||
## Auftrag
|
||||
Ansicht des Papierkorbs mit Restlaufzeit, Einzel- und Massenwiederherstellung sowie bestätigter endgültiger Löschung.
|
||||
|
||||
**Technische Grundlage:** Listenansicht, Bestätigungsdialog
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** Wiederherstellung muss offensichtlich sein. Verlorene Dokumente sind der häufigste Vertrauensverlust in einem Archiv.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-11` Soft-Delete & Papierkorb-Logik – Löschen setzt einen Papierkorb-Status statt physischer Entfernung. Endgültige Bereinigung erfolgt nach konfigurierbarer Frist.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System (zentral).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Restlaufzeit je Eintrag sichtbar
|
||||
2. Wiederherstellung einzeln und in Auswahl möglich
|
||||
3. Endgültiges Löschen erfordert ausdrückliche Bestätigung
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Versehentliches Löschen ohne Bestätigung nicht möglich
|
||||
2. Massenwiederherstellung mit 100 Objekten geprüft
|
||||
3. Leerer Papierkorb zeigt verständlichen Hinweis
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-03` Prüfgate Dokumentenkern
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-12: papierkorb-oberfläche`
|
||||
- Branch: `feature/doc-12-papierkorb-oberfläche`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,65 @@
|
||||
# DOC-13 – Akten-/Vorgangsanzeige im Dokumentkontext
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Frontend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
|
||||
|
||||
## Auftrag
|
||||
In der Dokument-Detailansicht anzeigen, ob das Dokument zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in DMS.
|
||||
|
||||
**Technische Grundlage:** Next.js/React/TS, externe REST-API
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** In der Dokument-Detailansicht anzeigen, ob das Dokument zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in DMS.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-05` PDF-Viewer-Komponente – Inline-Betrachter mit Seitennavigation, Zoom, Suche im Dokument und Textauswahl – ohne Download-Zwang.
|
||||
- Setzt voraus (externes Workflow-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/workflow-kanban/): `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Dokument-Detailansicht zeigt Akte-Zugehörigkeit, Vermerke und offene Wiedervorlagen an, falls vorhanden
|
||||
2. Kein eigenes Akte-Datenmodell in DMS, ausschließlich Anzeige über die externe API
|
||||
3. Fehlerfall (Workflow-Board nicht erreichbar) blockiert die Dokumentanzeige selbst nicht, zeigt nur den Akte-Bereich als „vorübergehend nicht verfügbar“
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Dokument mit verknüpfter Akte zeigt Akte-Informationen korrekt an
|
||||
2. Dokument ohne Akte-Verknüpfung zeigt Bereich nicht/leer an, kein Fehler
|
||||
3. Simulierter Ausfall der Workflow-API blockiert die übrige Dokumentanzeige nicht
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Akte-Datenmodell (Workflow-Board, siehe `VOR-01`)
|
||||
- Vermerke-Erfassung (Workflow-Board, siehe `VOR-02`)
|
||||
- Wiedervorlage-Erfassung (Workflow-Board, siehe `VOR-03`)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-13: akten vorgangsanzeige im dokumentkontext`
|
||||
- Branch: `feature/doc-13-akten-vorgangsanzeige-im-dokumentkontext`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,65 @@
|
||||
# DOC-14 – Dokument-Zusammenführen & -Aufteilen
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Nachträgliches Zusammenführen mehrerer Dokumente zu einem (z.B. fälschlich getrennt gescannt) und Aufteilen eines mehrseitigen Dokuments in mehrere eigenständige Dokumente (z.B. Stapel-Scan ohne Trennseiten-Erkennung, siehe INT-10) – beides als nachträgliche Korrektur nach dem Import, nicht nur zum Importzeitpunkt.
|
||||
|
||||
**Technische Grundlage:** PDF-Seitenmanipulation, Versionshistorie, Transaktionale Dokument-Operationen
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- paperless-ngx: Merge/Split-Werkzeug als praktische Korrekturfunktion im Alltag.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Verlust der Versionshistorie/Audit-Spur beim Zusammenführen/Aufteilen – jede entstehende neue Dokument-Einheit bleibt nachvollziehbar mit ihrem Ursprung verknüpft (Alfresco-Lehre: Nachvollziehbarkeit von Änderungen).
|
||||
|
||||
**Für genau diese Kachel:** Merge/Split müssen so selbstverständlich nutzbar sein wie bei paperless-ngx – aber ohne dessen Schwäche, die Herkunft der neuen Dokument-Einheiten zu verschleiern.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
- `DOC-09` Ordner- & Kabinettmodell – Hierarchische Ablage mit Verschieben, Umbenennen und effizienten Teilbaum-Abfragen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Mehrere Dokumente lassen sich zu einem zusammenführen, Ursprungsdokumente bleiben in der Versionshistorie nachvollziehbar
|
||||
2. Ein mehrseitiges Dokument lässt sich an beliebigen Seitengrenzen in mehrere eigenständige Dokumente aufteilen, jedes mit eigenen Metadaten
|
||||
3. Beide Operationen respektieren bestehende Aufbewahrungssperren (Archive-Retention) – eine Kachel mit aktiver Löschsperre kann nicht durch Zusammenführen/Aufteilen umgangen werden
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: drei Dokumente zusammengeführt, Ursprünge in Historie auffindbar
|
||||
2. Test: fünfseitiges Dokument an zwei Stellen geteilt, drei korrekte Einzeldokumente entstehen
|
||||
3. Test: Zusammenführen/Aufteilen eines Dokuments mit aktiver Löschsperre wird abgelehnt oder erfordert Freigabe, nicht stillschweigend erlaubt
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- Zusammenführen/Aufteilen darf keine Lücke im Audit-Trail erzeugen – jede neue Dokument-Einheit muss auf ihre Ursprungsdokumente zurückführbar bleiben, sonst wird die Revisionssicherheit (Kernprinzip aus ecoDMS-Produkt-DNA) an genau dieser Stelle unterlaufen.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `INT-10` Trennseiten-Erkennung beim Stapel-Scan (Importzeitpunkt)
|
||||
- Archive-Retention/Löschsperren-Logik selbst (Archive-Board)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-14: dokument-zusammenfuehren-aufteilen`
|
||||
- Branch: `feature/doc-14-dokument-zusammenfuehren-aufteilen`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# DOC-15 – Massenbearbeitung von Metadaten
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Mehrere ausgewählte Dokumente gleichzeitig mit Tags/Metadatenfeldern/Dokumenttyp bearbeiten (hinzufügen, entfernen, ersetzen) statt Dokument für Dokument – Vorbild paperless-ngx Bulk-Edit.
|
||||
|
||||
**Technische Grundlage:** Massenoperation über Dokumentauswahl, transaktionale Verarbeitung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
- Hierarchische Ablage mit vererbbaren Eigenschaften – der Bereich, in dem paperless-ngx am deutlichsten fehlt.
|
||||
- Papierkorb mit Frist statt sofortiger Vernichtung, wie es revisionssichere Systeme handhaben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine erzwungene Ordnerdisziplin. Ablage und Verschlagwortung stehen gleichberechtigt nebeneinander.
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
|
||||
**Für genau diese Kachel:** paperless-ngx erlaubt Massenänderung von Tags/Metadaten über mehrere Dokumente gleichzeitig – dieser Bedienkomfort fehlt bisher, es gibt nur Massenexport (DOC-08), keine Massenbearbeitung.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling
|
||||
- `MET-01` Tag-Modell & Tag-API
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Tag/Metadatenfeld kann über eine Auswahl mehrerer Dokumente gleichzeitig hinzugefügt oder entfernt werden
|
||||
2. Vorgang ist transaktional nachvollziehbar (Versionshistorie/Audit zeigt die Massenänderung, nicht stillschweigend)
|
||||
3. Vorgang respektiert bestehende Aufbewahrungssperren – ein gesperrtes Dokument in der Auswahl wird übersprungen mit klarer Rückmeldung, nicht die ganze Operation blockiert oder die Sperre umgangen
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: Tag auf 10 ausgewählte Dokumente gleichzeitig angewendet, alle korrekt aktualisiert
|
||||
2. Audit-Log zeigt Massenänderung nachvollziehbar
|
||||
3. Test mit einem gesperrten Dokument in der Auswahl: dieses wird übersprungen, Rest wird bearbeitet, klare Rückmeldung welches übersprungen wurde
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-03` Prüfgate Dokumentenkern
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-15: massenbearbeitung von metadaten`
|
||||
- Branch: `feature/doc-15-massenbearbeitung-von-metadaten`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,58 @@
|
||||
# DOC-17 – Malware-Scan vor Ablage
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
DOC-01 validiert Größe und MIME-Typ beim Upload, prüft aber nicht auf schädliche Inhalte (Viren, aktive Inhalte in Office-Dokumenten/Makros). Virenscan als verpflichtenden Verarbeitungsschritt vor endgültiger Ablage ergänzen – Upload bleibt in Quarantäne-Status, bis der Scan abgeschlossen ist; bei Fund wird das Dokument abgelehnt und der Vorfall protokolliert.
|
||||
|
||||
**Technische Grundlage:** Virenscanner-Anbindung (z. B. ClamAV), Go, Postgres-Jobqueue
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- paperless-ngx: Verarbeitungspipeline mit klar abgegrenzten, nacheinander laufenden Schritten (hier: Upload → Scan → Freigabe).
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- ecoDMS – in älteren Versionen kein verpflichtender Malware-Scan vor Ablage.: Scan ist ein Pflichtschritt, kein optionales Zusatzfeature.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: DOC-01.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede hochgeladene Datei durchläuft einen Virenscan, bevor sie als reguläres Dokument sichtbar/abrufbar wird
|
||||
2. Ein positiver Scan-Fund führt zur Ablehnung des Dokuments und einem Audit-Event, nicht zu stiller Ablage
|
||||
3. Der Scan-Status ist für den hochladenden Nutzer sichtbar (in Bearbeitung/freigegeben/abgelehnt)
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test mit EICAR-Testdatei: wird zuverlässig erkannt und abgelehnt
|
||||
2. Test mit sauberer Datei: durchläuft Scan und wird normal verfügbar
|
||||
3. Lasttest: Scan-Queue verarbeitet mehrere gleichzeitige Uploads ohne Verlust der Reihenfolge/Nachvollziehbarkeit
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
Threat-Model-Finding (DMS-Board, 2026-09-12): MIME-/Größenvalidierung allein erkennt keine schädlichen Inhalte innerhalb eines gültigen Dateityps (z. B. Makro in einer echten .docx-Datei).
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-01` Upload-API & Chunk-Handling
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-17: malware-scan-vor-ablage`
|
||||
- Branch: `feature/doc-17-malware-scan-vor-ablage`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,58 @@
|
||||
# DOC-18 – Obergrenze für Gesamtgröße/Anzahl bei Archiv-Bündelung
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentage | **Welle:** 13
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
DOC-08 bündelt mehrere ausgewählte Dokumente als Hintergrund-Job zu einem Archiv, ohne Obergrenze für Gesamtgröße oder Anzahl der Dokumente je Anfrage. Eine übermäßig große Auswahl kann sonst den Bündelungs-Job unverhältnismäßig lange laufen lassen und Ressourcen auf Kosten anderer Mandanten binden. Harte, konfigurierbare Obergrenze für maximale Gesamtgröße und maximale Dokumentanzahl je Bündelungs-Anfrage einführen – bei Überschreitung wird die Anfrage mit klarer Fehlermeldung abgelehnt, bevor der Job gestartet wird.
|
||||
|
||||
**Technische Grundlage:** Postgres-Jobqueue, Ressourcenlimits, Go
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Docspell: klare Verarbeitungsgrenzen statt unbegrenzter Best-Effort-Verarbeitung.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- archivdms (bekannte Fehlerklasse ähnlich) – Ressourcenerschöpfung durch unbegrenzte Einzeljobs war in Altsystemen eine wiederkehrende Betriebsstörung.: harte, konfigurierbare Obergrenzen von Anfang an statt nachträglicher Begrenzung nach Vorfall.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: DOC-08.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Eine Bündelungs-Anfrage mit konfigurierbar zu großer Gesamtgröße oder Dokumentanzahl wird vor Jobstart abgelehnt, mit klarer Fehlermeldung an den Nutzer
|
||||
2. Innerhalb der Obergrenze funktioniert die Bündelung aus DOC-08 unverändert
|
||||
3. Die Obergrenzen sind konfigurierbar, nicht hart im Code verankert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: Anfrage mit Auswahl oberhalb der konfigurierten Obergrenze wird abgelehnt, kein Job wird gestartet
|
||||
2. Test: Anfrage innerhalb der Obergrenze wird normal verarbeitet
|
||||
3. Regressionstest bestehender DOC-08-Funktionalität nach Einführung der Prüfung
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
Threat-Model-Finding (DMS-Board, 2026-09-12, Finding #9): unbegrenzte Bündelungs-Anfragen sind ein kleiner, aber realer Denial-of-Service-Vektor gegen den gemeinsamen Job-Worker-Pool.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-08` Massenexport als ZIP
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-18: obergrenze-f-r-gesamtgr-e-anzahl-bei-archiv-b-ndelung`
|
||||
- Branch: `feature/doc-18-obergrenze-f-r-gesamtgr-e-anzahl-bei-archiv-b-ndelung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,60 @@
|
||||
# DOC-19 – TIFF-Vorschau in der Thumbnail-Pipeline
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentag | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
TIFF als unterstütztes Quellformat in der Vorschau-/Thumbnail-Pipeline ergänzen — Netzwerkscanner (INT-06) liefern häufig TIFF-Stapel, dafür fehlt aktuell jede Vorschau.
|
||||
|
||||
**Technische Grundlage:** Bildableitung, wie bei JPEG/PNG/GIF bereits vorhanden
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt.
|
||||
|
||||
**Für genau diese Kachel:** Scan-Stapel vom Netzwerkscanner sind in der Praxis oft TIFF, nicht PDF — ohne diese Kachel bleibt die Vorschau für genau die Dokumente dunkel, die am häufigsten über den Scanner-Weg (INT-06) reinkommen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-04` Vorschau- & Thumbnail-Pipeline – `dms/internal/thumbnail/generate.go` erkennt Content-Type über Magic-Bytes und erzeugt PNG-Thumbnails für PDF (via `pdftoppm`) sowie JPEG/PNG/GIF (via Go-Standardbibliothek `image`). TIFF fällt aktuell in den `default`-Zweig und schlägt als "nicht unterstützter Dateityp" fehl (Job-Status "failed", keine Pipeline-Blockade, aber auch kein Thumbnail).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. TIFF-Dateien (Single- und Multi-Page) erzeugen ein Thumbnail von der ersten Seite
|
||||
2. Bereits unterstützte Formate (PDF/JPEG/PNG/GIF) funktionieren unverändert weiter
|
||||
3. Beschädigte/nicht dekodierbare TIFF-Datei führt zu Fehlerstatus statt Absturz, wie bei den übrigen Formaten
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Echtes Multi-Page-TIFF aus einem realen Scanvorgang (oder gleichwertig erzeugt) liefert korrektes Thumbnail der ersten Seite
|
||||
2. Bestehende Testsuite für PDF/JPEG/PNG/GIF bleibt grün
|
||||
3. Absichtlich beschädigte TIFF-Datei erzeugt Fehlerstatus, kein Prozessabsturz, andere Jobs in der Queue unbeeinträchtigt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-20` Office-Dokumente in der Vorschau anzeigen (separates, unabhängiges Problem — Office-Formate, nicht TIFF)
|
||||
- `INT-06` Scanner-Anbindung selbst (liefert TIFF nur an, diese Kachel verarbeitet es nur in der bestehenden Pipeline weiter)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen (`dms/internal/thumbnail/generate.go`) und halte dich an die dort etablierten Muster (Magic-Bytes-Erkennung, Fehlerbehandlung, kleinste Lösung).
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-19: tiff-vorschau in der thumbnail-pipeline`
|
||||
- Branch: `feature/doc-19-tiff-vorschau-in-der-thumbnail-pipeline`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# DOC-20 – Office-Dokumente in der Vorschau anzeigen
|
||||
|
||||
**Epic:** 🗂️ Dokumentenkern | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Den bereits vorhandenen PDF-Viewer (DOC-05) auch für Office-Dokumente nutzbar machen, indem der Inhalts-Endpunkt bei vorliegendem PDF-Derivat (DOC-06) dieses statt des Originals ausliefert — ohne den Download-Zwang oder Client-Zwang wiedereinzuführen, den das Produkt bewusst vermeidet.
|
||||
|
||||
**Technische Grundlage:** Bestehende Endpunkte `documentapi` (DOC-05) und `pdfconvert` (DOC-06) verknüpfen
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erfassen muss so mühelos sein wie bei paperless-ngx, die Ablage so strukturiert wie bei Alfresco.
|
||||
|
||||
**Übernehmen:**
|
||||
- Automatisierte Erfassungsstrecke: ablegen genügt, das System übernimmt Vorverarbeitung und Ableitungen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Vorschau, die den Download erzwingt oder einen eigenen Client verlangt – der Fehler von ecoDMS.
|
||||
- Das Original darf beim Anzeigen niemals verändert oder ersetzt werden (GoBD-Unveränderbarkeit) — die Anzeige liest ausschließlich das separate Derivat, die Revision bleibt unangetastet.
|
||||
|
||||
**Für genau diese Kachel:** DOC-06 erzeugt das PDF-Derivat bereits, DOC-05 kann PDF bereits anzeigen — beide Ketten sind fertig, aber nirgendwo verbunden. Eine hochgeladene .docx liefert heute den Rohinhalt an PDF.js, das damit nichts anfangen kann.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-05` PDF-Viewer-Komponente – `dms/internal/documentapi`, `GET /documents/{id}/content` liefert aktuell IMMER den entschlüsselten Originalinhalt der aktuellen Revision (Magic-Bytes-Content-Type), unabhängig vom tatsächlichen Format.
|
||||
- `DOC-06` Office-zu-PDF-Konverter – `dms/internal/pdfconvert`, legt das PDF-Derivat in eigener Tabelle `revision_pdf_derivatives` ab (Status pending/processing/ready/failed je Revision), Original bleibt unverändert.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Bei einer Revision mit `ready`-Derivat in `revision_pdf_derivatives` liefert der Inhalts-/Vorschau-Endpunkt das PDF-Derivat, nicht das Original
|
||||
2. Ohne vorhandenes oder noch nicht fertiges Derivat bleibt das bisherige Verhalten (Original-Content ausliefern) unverändert erhalten — kein Bruch für bereits unterstützte Formate wie PDF-Originale selbst
|
||||
3. Der PDF-Viewer (DOC-05, `web/pdf-viewer`) zeigt eine hochgeladene .docx/.xlsx/.pptx nach abgeschlossener Konvertierung ohne weitere Änderung am Frontend an
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: .docx hochgeladen, nach Abschluss der Konvertierung liefert der Endpunkt PDF-Bytes (Magic-Bytes-Check `%PDF`), nicht die ursprünglichen .docx-Bytes
|
||||
2. Test: PDF-Original hochgeladen (kein Derivat nötig) liefert weiterhin exakt das Original, byteidentisch
|
||||
3. Test: Derivat-Status `failed` oder `pending` liefert sinnvolles Fallback-/Fehlerverhalten, kein stiller Ausfall
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-19` TIFF-Vorschau in der Thumbnail-Pipeline (separates, unabhängiges Problem)
|
||||
- Änderungen an `web/pdf-viewer` selbst, falls über reines Zeigen des gelieferten PDFs hinaus nötig (z. B. Hinweistext "aus Office-Datei konvertiert") — Frontend-Hinweistexte sind eine eigene, kleinere Folgekachel, falls gewünscht
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen (`dms/internal/documentapi/handler.go`, `dms/internal/pdfconvert/pdfconvert.go`) und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-20: office-dokumente in der vorschau anzeigen`
|
||||
- Branch: `feature/doc-20-office-dokumente-in-der-vorschau-anzeigen`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,59 @@
|
||||
# DOC-21 – Papierkorb: Dokumente und Ordner per API in den Papierkorb verschieben
|
||||
|
||||
**Epic:** 📄 Dokumentenkern | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 13
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Der Gesamtstart (FDN-19, Befund B5) hat gezeigt: `internal/trash` kann Dokumente und Ordner in den Papierkorb verschieben, die HTTP-Schnittstelle kennt aber nur Liste, Wiederherstellen und endgültig Löschen. Der Smoke-Test brauchte dafür ein Hilfswerkzeug. Ein Nutzer kann über die API kein Dokument löschen.
|
||||
|
||||
Einen Endpunkt ergänzen, der eine Auswahl von Dokumenten und Ordnern in den Papierkorb verschiebt, mit denselben Identitäts-, Rechte- und Mandantenregeln wie die übrigen Papierkorb-Endpunkte.
|
||||
|
||||
**Technische Grundlage:** `internal/trash` (`SoftDeleteDocument`, `SoftDeleteFolder`), `internal/trashapi`, `internal/authz`, `internal/openapi`, `internal/apiwiring`, `docs/API.md`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Löschen ist zunächst umkehrbar: Der Papierkorb hält Objekte bis zum Ablauf der Frist, Wiederherstellen stellt Ablageort und Metadaten unverändert wieder her.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein stilles Löschen fremder oder ausgeliehener Dokumente: Wer nicht berechtigt ist, bekommt eine Ablehnung, kein „erfolgreich“.
|
||||
- Keine Löschung ohne Spur: Jede Verschiebung erscheint im Audit-Log, der Suchindex zieht nach.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: DOC-11 (Papierkorb-Logik), DOC-12 (Papierkorb-API), INT-01 (REST-API und Identität), INT-15 (Rechte-Parität), VER-01 (Ausleihe/Sperren), VER-09 (Audit), SRC-02 (Indexierung), FDN-19 (Befund B5).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. `POST /trash` verschiebt eine Auswahl von Dokumenten und Ordnern (mit Unterordnern und enthaltenen Dokumenten) in den Papierkorb, meldet das Ergebnis je ID und ist wiederholbar, ohne doppelte Audit-Einträge zu erzeugen
|
||||
2. Nur berechtigte Nutzer desselben Mandanten können verschieben: fremde Dokumente und Ordner führen zu 403, fehlende Identität zu 401; ein von einem anderen Nutzer ausgeliehenes (gesperrtes) Dokument wird nicht verschoben und mit Grund gemeldet
|
||||
3. Jede Verschiebung schreibt ein Audit-Ereignis, das Dokument verschwindet aus Ordneransicht und Suche und ist über `POST /trash/restore` unverändert wiederherstellbar
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Kompletter Lebenszyklus über die API: Verschieben, Papierkorb-Liste, Suche findet nichts mehr, Wiederherstellen, Suche findet wieder, Audit-Kette gültig
|
||||
2. Negativtests: anderer Nutzer, anderer Mandant, ausgeliehenes Dokument, unbekannte und bereits verschobene ID, leere und ungültige Auswahl
|
||||
3. Vertragsabgleich: OpenAPI-Beschreibung und tatsächliche Routen stimmen überein, CMIS-Parität (Delete-Objekt ist in CMIS nicht angeboten) ist dokumentiert
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Oberfläche für das Verschieben in den Papierkorb (DOC-12 und Folgekacheln)
|
||||
- Endgültiges Löschen, Aufbewahrungsfristen und Legal-Hold (DOC-14, INT-11)
|
||||
- Rechtemodell über die Eigentümerprüfung hinaus (Core RBAC)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-21: papierkorb-api zum verschieben in den papierkorb`
|
||||
- Branch: `feature/doc-21-papierkorb-api-zum-verschieben-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# DOC-22 – Externe Freigabelinks mit Passwort und Ablauf
|
||||
|
||||
**Epic:** 📄 Dokumentenkern | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 4 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Dokumente lassen sich nur an authentifizierte Nutzer des Mandanten ausliefern. Docspell und paperless-ngx bieten Freigabelinks für Externe, ohne dass ein Konto nötig ist. Ein Freigabelink ist die kontrollierte Ausnahme von der Regel „nur mit Konto“ und darf deshalb nur mit Ablauf, Widerruf, Zugriffsbegrenzung und Nachweis im Audit-Log entstehen.
|
||||
|
||||
Freigabelinks für ein einzelnes Dokument (nur lesen) einführen, mit Pflichtablauf, optionalem Passwort, Download-Limit und sofortigem Widerruf.
|
||||
|
||||
**Entscheidung erforderlich:** Produkt- und Datenschutzentscheidung: Externe Freigabe erlaubt Zugriff ohne Konto. Vor der Umsetzung festlegen: wer darf Links erzeugen (Eigentümer, Rolle), maximale Laufzeit, Passwortpflicht ja oder nein, Download-Limit, ob Freigaben mandantenweit abschaltbar sind. Standardvorschlag: nur Eigentümer und Mandantenadministration, Laufzeit höchstens 14 Tage, Passwort empfohlen, Freigabe per Mandanten-Schalter aus.
|
||||
|
||||
**Technische Grundlage:** `internal/sharelink` (neu), `internal/downloadapi`, `internal/storage` (signierte URLs, FDN-10), `internal/audittrail`, `internal/modulecall`, Migration (nächste freie DMS-Nummer), OpenAPI-Tabelle
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Freigaben als bewusst begrenzte Ausnahme: kurze Laufzeit, Widerruf, Nachweis (Vorbild Docspell und paperless-ngx).
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Dauerlinks: der Ablauf ist Pflicht, die Obergrenze per Umgebungsvariable.
|
||||
- Kein Geheimnis in der Datenbank im Klartext: Link-Token nur als Hash, Passwort nur als sicherer Hash, nie in Logs, Audit oder Fehlermeldungen.
|
||||
- Kein Zugriff über die Freigabe hinaus: genau dieses Dokument, nur lesen, keine Auflistung, keine Ordnernavigation.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-10, DOC-07, VER-09, INT-01, INT-16.
|
||||
Bezug: `VERGLEICHSANALYSE-QUELLSYSTEME.md` (Wurzelverzeichnis), Quellen [D1] (Docspell: öffentliche Links mit Passwort) und [P3] (paperless-ngx: Freigabe).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Freigabelinks lassen sich für ein Dokument erzeugen mit Pflichtablauf (Obergrenze konfigurierbar), optionalem Passwort und optionalem Download-Limit und sofort widerrufen; der Token ist hochentropisch und nur als Hash gespeichert
|
||||
2. Der Abruf ohne Konto läuft über einen eigenen, begrenzten Pfad mit Ratenbegrenzung und Sperre bei Fehlversuchen; gelöschte, im Papierkorb liegende, gesperrte oder fremde Dokumente werden nie ausgeliefert, Antworten enthalten keine Interna
|
||||
3. Erzeugung, Abruf, Fehlversuch und Widerruf stehen im Audit-Log ohne Token und Passwort; der Mandant ergibt sich aus der Instanz, nie aus Anfrageparametern
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Sicherheitsfälle: falsches Passwort, abgelaufen, widerrufen, Download-Limit erreicht, manipulierter oder erratener Token, Enumeration, fremder Mandant, Dokument im Papierkorb
|
||||
2. Ratenbegrenzung und Sperre halten unter Last, keine Zeitunterschiede, die Gültigkeit verraten (zeitkonstanter Vergleich)
|
||||
3. Audit-Kette bleibt gültig (`VerifyChain`), Passwort und Token tauchen in keinem Log auf
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Anonyme Upload-URLs und weitere Kanäle (`INT-17`)
|
||||
- Versand der Links per E-Mail und Oberfläche zur Verwaltung (eigenes UX-Ticket)
|
||||
- Freigaben von Ordnern oder mehreren Dokumenten
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-22: externe freigabelinks mit passwort und ablauf`
|
||||
- Branch: `feature/doc-22-externe-freigabelinks-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,60 @@
|
||||
# DOC-23 – RBAC-11-Objektrechte im DMS verdrahten
|
||||
|
||||
**Epic:** 📄 Dokumentenkern | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
RBAC-11 (Core) hat einen eigenständigen Objekt-ACL-Anfragemodus gebaut (`/object-acl/{grant,revoke,break,unbreak,list}`, Vererbung über den vom Aufrufer mitgegebenen Pfad). Das DMS ruft ihn noch nicht auf. Die Ordnerendpunkte prüfen weiterhin nur Mandant und Eigentümer, die Ordnerstruktur bleibt mandantenweit sichtbar (dokumentierte Grenze aus INT-15, die jetzt geschlossen werden kann).
|
||||
|
||||
Ordner- und Dokumentzugriff soll zusätzlich zur bestehenden Modulrecht-Prüfung (RBAC-06/RBAC-10) die Objekt-ACL abfragen, wenn für den Ordner eine ACL existiert. Ordner ohne ACL verhalten sich unverändert wie bisher.
|
||||
|
||||
**Technische Grundlage:** `dms/internal/folderapi`, `dms/internal/authz`, `dms/internal/policyclient`, Core `/object-acl/*` (RBAC-11)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Rechte, die im Katalog stehen, aber nirgends geprüft werden, sind keine Rechte.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fail-closed: Ausfall der Core-Policy-Prüfung verweigert, gibt nie stillschweigend Zugriff frei.
|
||||
- Rückwärtskompatibilität: Bestandsordner ohne ACL bleiben nutzbar wie zuvor.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine eigene, zweite Rechteverwaltung im DMS parallel zu Core-RBAC.
|
||||
- Keine mandantenweite Sichtbarkeit von Ordnerinhalten mehr, sobald eine ACL gesetzt ist.
|
||||
|
||||
## Ausgangslage
|
||||
- `RBAC-11` Objektrechte mit Vererbung für Ordner (Core) – eigenständiger Objekt-ACL-Anfragemodus, vom DMS noch nicht genutzt.
|
||||
- `RBAC-06` Policy-Entscheidungs-Endpunkt, `RBAC-10` Mandant/Modulaktivierung in `/authorize` – bestehendes Aufrufmuster in `dms/internal/policyclient`.
|
||||
- `INT-15` CMIS Auth-/Tenant-Scoping-Parität – dokumentierte Lücke „Ordnerstruktur bleibt mandantenweit sichtbar bis Core-RBAC“, jetzt schließbar.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
1. Ein Ordner mit gesetzter Objekt-ACL zeigt Inhalt und Navigation nur berechtigten Nutzern; Rechteentzug wirkt sofort
|
||||
2. Ein Ordner ohne Objekt-ACL verhält sich unverändert wie vor diesem Ticket
|
||||
3. Ausfall der Core-Policy-Prüfung verweigert den Zugriff (fail closed), niemals stillschweigende Freigabe
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
1. Vererbung auf Unterordner geprüft (ACL auf Elternordner wirkt auf Kinder ohne eigene ACL)
|
||||
2. Mandantentrennung geprüft (ACL eines Mandanten wirkt nie auf einen anderen)
|
||||
3. Endpunkte zum Setzen/Entfernen von Ordnerberechtigungen im DMS real gegen den Core-Objekt-ACL-Endpunkt geprüft
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Oberfläche zur Rechtevergabe (eigenes UX-Ticket)
|
||||
- Objektrechte auf Dokumentenebene unterhalb des Ordners (nur Ordner-Granularität in diesem Ticket)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies `docs/RBAC-11-PRUEFPROTOKOLL.md`, `dms/internal/folderapi`, `dms/internal/authz`, `dms/internal/policyclient` vollständig.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `DOC-23: rbac-11-objektrechte im dms verdrahten`
|
||||
- Branch: `feature/doc-23-rbac-11-objektrechte-im-dms-verdrahten`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,65 @@
|
||||
# FDN-01 – Repository & Projektgerüst
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** DevOps | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 1
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich DevOps und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Betrieb, Automatisierung und Reproduzierbarkeit. Alles als Konfiguration im Repository, nichts von Hand.
|
||||
|
||||
## Auftrag
|
||||
Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.
|
||||
|
||||
**Technische Grundlage:** Monorepo, Go, Next.js/TypeScript, golangci-lint, Prettier
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Fundament, das man an einem Vormittag aufsetzt und das trotzdem Governance trägt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Trennung von Anfrage-Dienst und Hintergrund-Workern wie bei paperless-ngx – lange Aufgaben blockieren nie eine Anfrage.
|
||||
- Sauber modelliertes Kern-Datenmodell mit klaren Beziehungen nach dem Vorbild von Docspell.
|
||||
- Protokoll und Rechte werden im Datenmodell von Beginn an mitgedacht – das fehlt paperless-ngx dauerhaft.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Anwendungsserver mit minutenlanger Startzeit und mehreren Gigabyte Grundverbrauch wie bei Alfresco.
|
||||
- Keine Konfiguration, ohne die das System nicht startet. Voreinstellungen müssen für den Einstieg genügen.
|
||||
|
||||
**Für genau diese Kachel:** Startklar in Minuten – das Gegenteil der Alfresco-Installation. Ein einziger Befehl bringt Dienst, Datenbank und Worker hoch.
|
||||
|
||||
## Ausgangslage
|
||||
Diese Kachel hat keine Vorbedingungen und ist sofort startbar.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Repo lässt sich mit einem Befehl installieren und starten
|
||||
2. Lint- und Format-Checks laufen lokal durch
|
||||
3. Branch- und Commit-Konvention dokumentiert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Frischer Clone baut ohne manuelle Nacharbeit
|
||||
2. Lint-Fehler brechen den Build ab
|
||||
3. README-Setupanleitung von zweiter Person nachvollzogen
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `FDN-02` Datenmodell & Migrationen
|
||||
- `FDN-03` Objekt-Storage-Abstraktion
|
||||
- `FDN-07` CI-Pipeline & Testharness
|
||||
- `FDN-08` Logging, Metriken & Fehler-Tracking
|
||||
- `SRC-01` Suchindex-Infrastruktur
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-01: repository & projektgerüst`
|
||||
- Branch: `feature/fdn-01-repository-projektgerüst`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,75 @@
|
||||
# FDN-02 – Datenmodell & Migrationen
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.
|
||||
|
||||
**Technische Grundlage:** PostgreSQL, pgx/v5, SQL-Migrationsdateien (kein ORM)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Fundament, das man an einem Vormittag aufsetzt und das trotzdem Governance trägt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Trennung von Anfrage-Dienst und Hintergrund-Workern wie bei paperless-ngx – lange Aufgaben blockieren nie eine Anfrage.
|
||||
- Sauber modelliertes Kern-Datenmodell mit klaren Beziehungen nach dem Vorbild von Docspell.
|
||||
- Protokoll und Rechte werden im Datenmodell von Beginn an mitgedacht – das fehlt paperless-ngx dauerhaft.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Anwendungsserver mit minutenlanger Startzeit und mehreren Gigabyte Grundverbrauch wie bei Alfresco.
|
||||
- Keine Konfiguration, ohne die das System nicht startet. Voreinstellungen müssen für den Einstieg genügen.
|
||||
|
||||
**Für genau diese Kachel:** Docspell zeigt, wie ein klares Kernmodell aussieht. Ergänze von Beginn an Revision, Rechtebezug und Protokollanker, die paperless-ngx fehlen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-01` Repository & Projektgerüst – Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle Kern-Entitäten mit Beziehungen und Indizes vorhanden
|
||||
2. Migration vorwärts und rückwärts ausführbar
|
||||
3. Seed-Datensatz für Entwicklung vorhanden
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Migration auf leerer DB und auf bestehender DB getestet
|
||||
2. Rollback stellt Vorzustand wieder her
|
||||
3. Fremdschlüssel-Constraints durch Negativtests belegt
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Fehlende Lock-/Sum-Datei blockiert CI**: Ein Vorgängerprojekt hatte über lange Zeit keine committete Dependency-Lock-Datei, wodurch Tests in DB-/Crypto-Paketen fehlschlugen. → Lock-Datei von Anfang an committen und ein CI-Gate einrichten, das Dependency-Integrität prüft.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `FDN-04` Job-Queue & Worker-Runtime
|
||||
- Core `IAM-01` Benutzer-Datenmodell & CRUD (Auth liegt vollständig in Core)
|
||||
- `DOC-01` Upload-API & Chunk-Handling
|
||||
- `DOC-09` Ordner- & Kabinettmodell
|
||||
- `MET-01` Tag-Modell & Tag-API
|
||||
- `MET-02` Benutzerdefinierte Metadatenfelder
|
||||
- Workflow `ENG-01` Workflow-Engine & Zustandsmodell (liegt im Workflow-Board)
|
||||
- `VER-01` Versionsmodell & Check-in/Check-out
|
||||
- `VER-05` Revisionssicherer Audit-Trail
|
||||
- `QA-02` Prüfgate Fundament
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-02: datenmodell & migrationen`
|
||||
- Branch: `feature/fdn-02-datenmodell-migrationen`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,68 @@
|
||||
# FDN-03 – Objekt-Storage-Abstraktion
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Storage-Adapter mit einheitlicher Schnittstelle für Ablegen, Lesen, Löschen und signierte URLs. Lokaler Treiber für Entwicklung, S3 für Produktion.
|
||||
|
||||
**Technische Grundlage:** S3-kompatibel, Presigned URLs
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Fundament, das man an einem Vormittag aufsetzt und das trotzdem Governance trägt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Trennung von Anfrage-Dienst und Hintergrund-Workern wie bei paperless-ngx – lange Aufgaben blockieren nie eine Anfrage.
|
||||
- Sauber modelliertes Kern-Datenmodell mit klaren Beziehungen nach dem Vorbild von Docspell.
|
||||
- Protokoll und Rechte werden im Datenmodell von Beginn an mitgedacht – das fehlt paperless-ngx dauerhaft.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Anwendungsserver mit minutenlanger Startzeit und mehreren Gigabyte Grundverbrauch wie bei Alfresco.
|
||||
- Keine Konfiguration, ohne die das System nicht startet. Voreinstellungen müssen für den Einstieg genügen.
|
||||
|
||||
**Für genau diese Kachel:** Ablage im offenen Objektformat, jederzeit ohne Herstellerwerkzeug lesbar – bewusst anders als die geschlossene Ablage von ecoDMS.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-01` Repository & Projektgerüst – Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.
|
||||
|
||||
Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `LIC-05` Speicherverbrauch-Metrik je Tenant.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Ein Interface, zwei austauschbare Treiber
|
||||
2. Signierte URLs mit konfigurierbarer Gültigkeit
|
||||
3. Pfadschema innerhalb des Mandanten-Buckets für Dokument/Revision festgelegt (Bucket-Trennung selbst ist Sache von Core TEN-01)
|
||||
4. Objektgröße wird bei jedem Schreib-/Löschvorgang an den zentralen Speicherverbrauch-Zähler (Core LIC-05) gemeldet
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Round-Trip-Test Upload/Download je Treiber
|
||||
2. Abgelaufene signierte URL wird abgewiesen
|
||||
3. Verhalten bei fehlendem Objekt liefert klaren Fehler
|
||||
4. Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-01` Upload-API & Chunk-Handling
|
||||
- `QA-02` Prüfgate Fundament
|
||||
- `FDN-09` Verschlüsselung at rest & Schlüsselverwaltung – die Storage-Ebene nutzt die fertige Encrypt/Decrypt-Schnittstelle aus FDN-09, verschlüsselt aber nicht selbst.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-03: objekt-storage-abstraktion`
|
||||
- Branch: `feature/fdn-03-objekt-storage-abstraktion`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,76 @@
|
||||
# FDN-04 – Job-Queue & Worker-Runtime
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.
|
||||
|
||||
**Technische Grundlage:** Postgres-Jobqueue (processing_jobs, FOR UPDATE SKIP LOCKED), In-Prozess-Worker-Goroutinen, kein Redis/AMQP
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Fundament, das man an einem Vormittag aufsetzt und das trotzdem Governance trägt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Trennung von Anfrage-Dienst und Hintergrund-Workern wie bei paperless-ngx – lange Aufgaben blockieren nie eine Anfrage.
|
||||
- Sauber modelliertes Kern-Datenmodell mit klaren Beziehungen nach dem Vorbild von Docspell.
|
||||
- Protokoll und Rechte werden im Datenmodell von Beginn an mitgedacht – das fehlt paperless-ngx dauerhaft.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Anwendungsserver mit minutenlanger Startzeit und mehreren Gigabyte Grundverbrauch wie bei Alfresco.
|
||||
- Keine Konfiguration, ohne die das System nicht startet. Voreinstellungen müssen für den Einstieg genügen.
|
||||
|
||||
**Für genau diese Kachel:** Die Hintergrundverarbeitung von paperless-ngx ist der Grund für die gute Erfassungsqualität. Baue sie belastbarer: Wiederholung, Rückstellung, Fehlerkorb.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-02` Datenmodell & Migrationen – Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jobs werden zuverlässig eingereiht und verarbeitet
|
||||
2. Fehlgeschlagene Jobs landen nach n Versuchen in der DLQ
|
||||
3. Job-Status ist abfragbar
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Absturz eines Workers führt zu erneuter Zustellung
|
||||
2. Idempotenz bei Doppelzustellung nachgewiesen
|
||||
3. DLQ-Eintrag manuell wiederholbar
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Fehlerhafter Typ-Cast bei Intervall-Queries**: In einem Vorgängerprojekt trat derselbe Fehler zweimal auf, weil Intervall-Werte per String-Konkatenation statt korrektem Cast in SQL-Queries eingebaut wurden. → Arithmetischen Cast (kein String-Concat für Intervalle) als verbindliche Konvention für Job-Queue-Queries festlegen.
|
||||
- **In-Memory Rate-Limiter ohne geteilten Zustand**: Bei Mehrinstanz-Betrieb hatte jede Instanz einen eigenen Rate-Limiter-Zustand, wodurch Limits aushebelbar waren. → Falls der Worker mehrinstanzfähig skaliert werden soll, State (Rate-Limits, Job-Locks) extern (Redis/DB) halten oder Single-Instance-Constraint explizit dokumentieren.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-04` Vorschau- & Thumbnail-Pipeline
|
||||
- `DOC-06` Office-zu-PDF-Konverter
|
||||
- `DOC-08` Massenexport als ZIP
|
||||
- `SRC-02` Indexierungs-Worker & Synchronisierung
|
||||
- `SRC-05` OCR-Worker
|
||||
- `TSK-03` Fristen & Erinnerungen (externes Workflow-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/workflow-kanban/)
|
||||
- `API-07` Webhook-Registry & Zustellung (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/) – Benachrichtigungsversand läuft über Core CFG-02/API-07, nicht über einen eigenen Dienst
|
||||
- `INT-03` E-Mail-Abruf über IMAP
|
||||
- `INT-05` Webhook-Registry & Zustellung
|
||||
- `QA-02` Prüfgate Fundament
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-04: job-queue & worker-runtime`
|
||||
- Branch: `feature/fdn-04-job-queue-worker-runtime`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,72 @@
|
||||
# FDN-07 – CI-Pipeline & Testharness
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** DevOps | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 2
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich DevOps und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Betrieb, Automatisierung und Reproduzierbarkeit. Alles als Konfiguration im Repository, nichts von Hand.
|
||||
|
||||
## Auftrag
|
||||
Automatisierte Pipeline für Lint, Typprüfung, Unit- und E2E-Tests sowie Build-Artefakt. Testdatenbank wird pro Lauf frisch aufgesetzt.
|
||||
|
||||
**Technische Grundlage:** CI-Runner, Unit-/E2E-Testrunner
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Fundament, das man an einem Vormittag aufsetzt und das trotzdem Governance trägt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Trennung von Anfrage-Dienst und Hintergrund-Workern wie bei paperless-ngx – lange Aufgaben blockieren nie eine Anfrage.
|
||||
- Sauber modelliertes Kern-Datenmodell mit klaren Beziehungen nach dem Vorbild von Docspell.
|
||||
- Protokoll und Rechte werden im Datenmodell von Beginn an mitgedacht – das fehlt paperless-ngx dauerhaft.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Anwendungsserver mit minutenlanger Startzeit und mehreren Gigabyte Grundverbrauch wie bei Alfresco.
|
||||
- Keine Konfiguration, ohne die das System nicht startet. Voreinstellungen müssen für den Einstieg genügen.
|
||||
|
||||
**Für genau diese Kachel:** Ohne automatisierte Prüfstrecke ist Revisionssicherheit eine Behauptung.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-01` Repository & Projektgerüst – Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Pipeline läuft bei jedem Push
|
||||
2. Roter Test blockiert den Merge
|
||||
3. Testabdeckung wird ausgewiesen
|
||||
4. CI-Pipeline führt Dependency-/Supply-Chain-Scanning aus (govulncheck für Go-Module, npm audit für JS/TS-Pakete), Build schlägt bei kritischen bekannten Schwachstellen fehl.
|
||||
5. Sicherheitsrelevanter Code (Auth, Tenant-Scoping, Verschlüsselung, Berechtigungsprüfung) hat verpflichtende automatisierte Tests als Merge-Gate — ein Merge ohne diese Tests ist technisch blockiert, nicht nur Konvention.
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Absichtlich fehlschlagender Test bricht Pipeline ab
|
||||
2. Pipeline-Laufzeit unter vereinbartem Grenzwert
|
||||
3. Artefakt ist reproduzierbar erzeugbar
|
||||
4. Absichtlich eingeführte bekannte Schwachstelle in einer Testabhängigkeit lässt den Build fehlschlagen.
|
||||
5. Merge-Versuch eines sicherheitsrelevanten Codepfads ohne Test wird von der Pipeline blockiert.
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Kaum Unit-Tests für kritische Pakete**: In Vorgängerprojekten fehlten Tests für Auth, Storage/Tenant-Isolation und Protokoll-State-Machines fast vollständig, trotz hoher Kritikalität dieser Bereiche. → Testpflicht für Auth/Tenant-Scoping/Retention als Merge-Gate in der CI-Pipeline verankern, nicht optional lassen.
|
||||
- archivdms/archivmail hatten faktisch keine Tests für Auth/Tenant-Isolation (siehe known-issues-archivdms.md #2, known-issues-archivmail.md #4) — das darf sich nicht wiederholen, deshalb technisches Merge-Gate statt Test-Empfehlung.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-01` Teststrategie & Testdatenbestand
|
||||
- `QA-02` Prüfgate Fundament
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-07: ci-pipeline & testharness`
|
||||
- Branch: `feature/fdn-07-ci-pipeline-testharness`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,66 @@
|
||||
# FDN-08 – Logging, Metriken & Fehler-Tracking
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** DevOps | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 2
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich DevOps und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Betrieb, Automatisierung und Reproduzierbarkeit. Alles als Konfiguration im Repository, nichts von Hand.
|
||||
|
||||
## Auftrag
|
||||
Strukturiertes Logging mit Korrelations-ID, technische Metriken und zentrale Fehlererfassung inklusive Alarmierung.
|
||||
|
||||
**Technische Grundlage:** Strukturierte Logs, Metrics-Endpoint
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Fundament, das man an einem Vormittag aufsetzt und das trotzdem Governance trägt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Trennung von Anfrage-Dienst und Hintergrund-Workern wie bei paperless-ngx – lange Aufgaben blockieren nie eine Anfrage.
|
||||
- Sauber modelliertes Kern-Datenmodell mit klaren Beziehungen nach dem Vorbild von Docspell.
|
||||
- Protokoll und Rechte werden im Datenmodell von Beginn an mitgedacht – das fehlt paperless-ngx dauerhaft.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Anwendungsserver mit minutenlanger Startzeit und mehreren Gigabyte Grundverbrauch wie bei Alfresco.
|
||||
- Keine Konfiguration, ohne die das System nicht startet. Voreinstellungen müssen für den Einstieg genügen.
|
||||
|
||||
**Für genau diese Kachel:** Alfresco ist im Betrieb schwer zu durchschauen. Mache jede Anfrage über alle Schichten hinweg nachvollziehbar.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-01` Repository & Projektgerüst – Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede Anfrage besitzt eine Korrelations-ID über alle Schichten
|
||||
2. Metriken für Latenz, Fehlerrate und Queue-Länge vorhanden
|
||||
3. Unbehandelte Fehler werden zentral gemeldet
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Provozierter Fehler erscheint innerhalb einer Minute im Tracking
|
||||
2. Logs enthalten keine Passwörter oder Tokens
|
||||
3. Alarm-Schwelle einmal ausgelöst und quittiert
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Silent-Fail durch Logger-Wiring-Fehler**: In einem Vorgängerprojekt war der Logger in einem CLI-Pfad nie korrekt verdrahtet, wodurch Debug-Logs stillschweigend fehlten. → Logger-Injection zentral über Dependency Injection als Konstruktor-Pflichtfeld erzwingen, damit ein fehlender Logger beim Build/Start auffällt statt zur Laufzeit stumm zu bleiben.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-02` Prüfgate Fundament
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-08: logging, metriken & fehler-tracking`
|
||||
- Branch: `feature/fdn-08-logging-metriken-fehler-tracking`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,70 @@
|
||||
# FDN-09 – Verschlüsselung at rest & Schlüsselverwaltung
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Envelope-Encryption-Modul – Datenverschlüsselungsschlüssel (DEK) pro Objekt, verpackt durch einen Hauptschlüssel (KEK), der über Core `API-10` (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen wird. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst. Bietet Encrypt/Decrypt-Schnittstelle über Streams, die von der Storage-Abstraktion (FDN-03) beim Ablegen/Lesen genutzt wird.
|
||||
|
||||
**Technische Grundlage:** AES-256-GCM, Envelope Encryption
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Fundament, das man an einem Vormittag aufsetzt und das trotzdem Governance trägt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Trennung von Anfrage-Dienst und Hintergrund-Workern wie bei paperless-ngx – lange Aufgaben blockieren nie eine Anfrage.
|
||||
- Sauber modelliertes Kern-Datenmodell mit klaren Beziehungen nach dem Vorbild von Docspell.
|
||||
- Protokoll und Rechte werden im Datenmodell von Beginn an mitgedacht – das fehlt paperless-ngx dauerhaft.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Anwendungsserver mit minutenlanger Startzeit und mehreren Gigabyte Grundverbrauch wie bei Alfresco.
|
||||
- Keine Konfiguration, ohne die das System nicht startet. Voreinstellungen müssen für den Einstieg genügen.
|
||||
|
||||
**Für genau diese Kachel:** Verschlüsselung darf kein Werkzeug des Herstellers erfordern und muss offenes, dokumentiertes Verfahren nutzen – bewusst anders als geschlossene Verschlüsselung von ecoDMS.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-01` Repository & Projektgerüst – Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.
|
||||
|
||||
Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-10` Master-Key-Verwaltung & -Rotation (KMS-Anbindung).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. DEK wird pro Objekt neu erzeugt, nie wiederverwendet
|
||||
2. KEK wird ausschließlich über Core `API-10` bezogen, nie im Code oder in der Datenbank im Klartext gespeichert
|
||||
3. Schlüsselrotation des KEK ist ohne Neuverschlüsselung aller Objekte möglich (nur DEK-Wrapper wird neu verpackt)
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Round-Trip Encrypt/Decrypt liefert identischen Klartext
|
||||
2. Manipulierter Chiffretext wird bei Decrypt erkannt und abgelehnt (GCM-Auth-Tag)
|
||||
3. KEK-Rotation getestet, alte Objekte weiterhin lesbar
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- Hash-Berechnung für Dublettenerkennung (DOC-02) MUSS auf dem Klartext erfolgen, bevor diese Verschlüsselung angewendet wird. Bei nichtdeterministischer Verschlüsselung (zufälliger IV/Nonce) erzeugt dieselbe Datei sonst bei jedem Upload einen anderen Chiffretext und Duplikate werden nie erkannt. Reihenfolge im Upload-Pfad (DOC-01): Datei empfangen → SHA-256 auf Klartext → verschlüsseln (dieses Ticket) → Chiffretext ablegen.
|
||||
- Master-Key-Verwaltung wurde ursprünglich unabhängig in DMS und Mail geplant — Duplikat im sicherheitskritischsten Bereich. Der Master-Key kommt jetzt zentral aus Core API-10, nur die Objekt-Verschlüsselung selbst bleibt hier.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `FDN-03` Objekt-Storage-Abstraktion
|
||||
- `DOC-01` Upload-API & Chunk-Handling
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-09: verschlüsselung at rest & schlüsselverwaltung`
|
||||
- Branch: `feature/fdn-09-verschluesselung-at-rest-schluesselverwaltung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,58 @@
|
||||
# FDN-10 – Signierte URLs: Scope-Bindung & kurze Ablaufzeit
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
FDN-03 stellt signierte URLs für den Storage-Zugriff bereit, ohne deren Scope und Ablaufzeit explizit festzulegen. Jede signierte URL muss fest an genau ein Objekt gebunden sein (nicht an ein Präfix/Verzeichnis) und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden). Nach Ablauf oder nach Löschung/Versionswechsel des Objekts muss die URL ungültig sein.
|
||||
|
||||
**Technische Grundlage:** Storage-Adapter (S3-kompatibel), signierte URLs, Go
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- paperless-ngx/Alfresco: zeitlich begrenzte, objektgebundene Zugriffs-Tokens statt dauerhafter Links.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Alfresco – in älteren Konfigurationen teils lang gültige Download-Links ohne erzwungene kurze TTL.: Ablaufzeit ist ein hartes, kurzes Limit, keine Empfehlung.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-03.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Eine signierte URL gewährt ausschließlich Zugriff auf genau das Objekt, für das sie ausgestellt wurde
|
||||
2. Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter
|
||||
3. Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stilles Fallback auf öffentlichen Zugriff
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: signierte URL für Objekt A liefert bei Zugriffsversuch auf Objekt B einen Fehler
|
||||
2. Test: abgelaufene URL wird abgelehnt
|
||||
3. Test: URL für ein zwischenzeitlich gelöschtes Objekt wird abgelehnt
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
Threat-Model-Finding (DMS-Board, 2026-09-12): ohne explizite Scope-/TTL-Vorgabe könnten signierte URLs versehentlich zu breit (Präfix statt Objekt) oder zu lange gültig ausgestellt werden.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `FDN-03` Objekt-Storage-Abstraktion
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-10: signierte-urls-scope-bindung-kurze-ablaufzeit`
|
||||
- Branch: `feature/fdn-10-signierte-urls-scope-bindung-kurze-ablaufzeit`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,58 @@
|
||||
# FDN-11 – Ressourcenlimits für asynchrone Verarbeitungsjobs
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
FDN-04 verarbeitet OCR/Konvertierung/Indexierung/Exporte mit Wiederholungslogik, Backoff und Dead-Letter-Queue, ohne Obergrenzen pro Einzeljob festzulegen. Eine sehr große oder speziell präparierte Datei (z. B. sehr viele Seiten, Zip-Bomb-artige Kompression bei Konvertierung) kann einen Worker dauerhaft blockieren und damit die Verarbeitung für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job abgebrochen, in die Dead-Letter-Queue verschoben und der Nutzer informiert, statt den Worker zu blockieren.
|
||||
|
||||
**Technische Grundlage:** Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Docspell: klare Verarbeitungsgrenzen statt unbegrenzter Best-Effort-Verarbeitung.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- archivdms (bekannter Fehlerklasse ähnlich) – Ressourcenerschöpfung durch unbegrenzte Einzeljobs war in Altsystemen eine wiederkehrende Betriebsstörung.: harte, konfigurierbare Obergrenzen je Job von Anfang an statt nachträglicher Begrenzung nach Vorfall.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-04.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jeder Verarbeitungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl
|
||||
2. Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers
|
||||
3. Andere, gleichzeitig laufende Jobs (auch anderer Mandanten) bleiben von einem überschreitenden Job unbeeinflusst
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test mit einer Datei, die absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen
|
||||
2. Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs
|
||||
3. Test der Nutzerbenachrichtigung bei abgebrochenem Job
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
Threat-Model-Finding (DMS-Board, 2026-09-12): unbegrenzte Einzeljob-Verarbeitung ist ein Denial-of-Service-Vektor gegen den gemeinsamen Worker-Pool, auch ohne böswillige Absicht (einfach eine sehr große legitime Datei genügt).
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `FDN-04` Job-Queue & Worker-Runtime
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-11: ressourcenlimits-f-r-asynchrone-verarbeitungsjobs`
|
||||
- Branch: `feature/fdn-11-ressourcenlimits-f-r-asynchrone-verarbeitungsjobs`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,57 @@
|
||||
# FDN-12 – Port-Register & Kollisionsprüfung für Standard-Ports
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Klein | **Aufwand:** 1 Personentag | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
In Betriebsstufe 1 (`PROXMOX-DEPLOYMENT.md`) laufen alle Module auf einem LXC. Die Standard-Ports der Binaries kollidieren bereits: DMS-App `:8090` gegen `archive/cmd/scrub-metrics` `:8090`, DMS-Worker-Metriken `:8091` gegen `archive/cmd/restoretest-metrics` `:8091`. Ein Port-Register mit festem Bereich je Modul und eine automatische Prüfung einführen, die doppelt vergebene oder außerhalb des Modulbereichs liegende Standard-Ports in `cmd/**/main.go` erkennt. DMS-Defaults in den DMS-Bereich verschieben.
|
||||
|
||||
**Technische Grundlage:** Textregister (`deploy/ports.tsv`), Shell-Prüfskript, Aufruf in der CI-Pipeline (FDN-07)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Ein Binary pro Modul, ein systemd-Service pro Binary (`PROXMOX-DEPLOYMENT.md` Abschnitt 1): Module müssen ohne Konfigurationsänderung nebeneinander starten.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kollisionen, die erst beim Deployment auf dem Produktivsystem auffallen: Prüfung im Build statt beim Start des zweiten Dienstes.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-01, FDN-08. Die CI-Anbindung setzt FDN-07 voraus.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Das Port-Register weist jedem Modul einen Portbereich zu; DMS liegt in 8100–8199
|
||||
2. Die Prüfung schlägt fehl bei doppelt vergebenem Standard-Port und bei einem Port außerhalb des Modulbereichs
|
||||
3. Die DMS-Defaults (App, Worker-Metriken) liegen im DMS-Bereich und sind in `dms/README.md` dokumentiert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Prüfskript gegen einen echten Baum aus Archive- und DMS-Quellen vor der Änderung: meldet die zwei bekannten Kollisionen
|
||||
2. Prüfskript nach der Änderung: fehlerfrei
|
||||
3. Test mit synthetischem Baum: Duplikat und Bereichsverletzung werden erkannt, sauberer Baum besteht
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Getrennte Datenbank/Schema je Modul und modulspezifischer Name der Migrationstabelle (`schema_migrations`)
|
||||
- Routenpräfix je Modul hinter dem gemeinsamen nginx
|
||||
- Preflight im Installationsskript (freie Ports, Dienstnamen)
|
||||
- Anpassung der Archive-Defaults (eigenes Board)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-12: port-register und kollisionspruefung`
|
||||
- Branch: `feature/fdn-12-port-register-und-kollisionspruefung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,55 @@
|
||||
# FDN-13 – Datenbank-/Schema-Trennung & eigene Migrationstabelle je Modul
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Klein | **Aufwand:** 1 Personentag | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
In Betriebsstufe 1 teilen sich alle Module einen PostgreSQL-Cluster. `internal/migrate` legt die Tabelle `schema_migrations` unqualifiziert an; liegen zwei Module in derselben Datenbank/demselben Schema, überschreiben sie gegenseitig ihren Migrationsfortschritt. Migrationstabelle modulspezifisch benennen (`dms_schema_migrations`), bestehende Installationen ohne Datenverlust umstellen und die Zuordnung Datenbank/Schema je Modul in `PROXMOX-DEPLOYMENT.md` verbindlich festlegen.
|
||||
|
||||
**Technische Grundlage:** Go-Migrationsrunner (FDN-02), PostgreSQL-Schemas
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Ein Binary pro Modul, unabhängig deploybar (`PROXMOX-DEPLOYMENT.md` Abschnitt 7): jedes Modul verwaltet seinen eigenen Migrationsstand.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Namensräume, die erst beim gemeinsamen Deployment kollidieren.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-02, FDN-12.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Der Migrationsrunner des DMS nutzt eine modulspezifisch benannte Tabelle
|
||||
2. Eine bestehende `schema_migrations`-Tabelle mit DMS-Versionen wird verlustfrei übernommen (Umbenennung, keine erneute Ausführung)
|
||||
3. Zwei Module in derselben Datenbank behindern sich nicht gegenseitig beim Migrieren
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: Migration gegen leere Datenbank legt `dms_schema_migrations` an
|
||||
2. Test: Upgrade von Bestand mit `schema_migrations` führt keine Migration doppelt aus
|
||||
3. Test: zweiter Runner mit anderem Tabellennamen in derselben Datenbank migriert unabhängig
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Routenpräfix je Modul
|
||||
- Anpassung anderer Module (eigene Boards)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-13: datenbank-schema-trennung-je-modul`
|
||||
- Branch: `feature/fdn-13-datenbank-schema-trennung-je-modul`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,55 @@
|
||||
# FDN-14 – Routenpräfix je Modul hinter dem gemeinsamen Reverse Proxy
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Klein | **Aufwand:** 1 Personentag | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Das DMS registriert HTTP-Pfade auf Root-Ebene (`/search`, `/documents/{id}/content`, `/healthz`). Hinter einem gemeinsamen nginx (Betriebsstufe 1) kollidieren diese, sobald ein anderes Modul denselben Pfad nutzt. Alle DMS-Routen unter einem einheitlichen Präfix `/api/dms/v1` bereitstellen (konfigurierbar), `/healthz` bleibt zusätzlich ohne Präfix erreichbar, nginx-Beispielkonfiguration in `PROXMOX-DEPLOYMENT.md` ergänzen.
|
||||
|
||||
**Technische Grundlage:** net/http ServeMux, Reverse-Proxy-Konfiguration
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle: stabile, versionierte Pfade.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Pfadkollisionen zwischen Modulen hinter einem Proxy.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-02, FDN-12.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle fachlichen DMS-Routen sind unter dem konfigurierbaren Präfix erreichbar
|
||||
2. Ohne Präfix sind sie nicht mehr erreichbar (außer `/healthz`)
|
||||
3. Die Präfixe aller Module sind im Port-/Routenregister ohne Überschneidung eingetragen
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: Routen unter Präfix antworten, Root-Pfade liefern 404
|
||||
2. Test: Präfix über Umgebungsvariable ändert alle Routen konsistent
|
||||
3. Prüfskript: doppelte Präfixe im Register werden erkannt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Modul-zu-Modul-Authentifizierung (Core API-09)
|
||||
- Anpassung anderer Module (eigene Boards)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-14: routenpraefix-je-modul`
|
||||
- Branch: `feature/fdn-14-routenpraefix-je-modul`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,55 @@
|
||||
# FDN-15 – Preflight-Prüfung im Installationsskript
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Klein | **Aufwand:** 1 Personentag | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Das Installationsskript (Betriebsstufe 1, `PROXMOX-DEPLOYMENT.md` Abschnitt 2) soll vor dem Einspielen prüfen, ob die Standard-Ports frei sind, ob die systemd-Unit-Namen (`nexarch-dms.service`, `nexarch-dms-worker.service`) bereits belegt sind und ob die Ziel-Datenbank bzw. das Schema erreichbar ist und keinen fremden Migrationsstand enthält. Bei Konflikt: Abbruch vor jeder Änderung mit klarer Meldung.
|
||||
|
||||
**Technische Grundlage:** Bash-Installationsskript, `deploy/ports.tsv` (FDN-12), systemd
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Das bewährte `install.sh`-Muster aus archivdms: natives Setup, kein Docker.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Halb installierte Systeme durch Abbruch mitten im Ablauf; Kollisionen, die erst beim Start des zweiten Dienstes sichtbar werden.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-02, FDN-12.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Preflight läuft vor jeder Änderung am System
|
||||
2. Belegter Port, vorhandene Unit oder fremder Migrationsstand führt zum Abbruch ohne Änderung
|
||||
3. Ein freies System besteht den Preflight
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: Port mit Testlistener belegt, Preflight bricht ab und nennt Port und Modul
|
||||
2. Test: vorhandene Unit-Datei erkannt
|
||||
3. Test: freies System besteht
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Vollständiges Installationsskript für alle Module (eigene Kachel)
|
||||
- systemd-Unit-Dateien selbst
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-15: preflight-im-installationsskript`
|
||||
- Branch: `feature/fdn-15-preflight-im-installationsskript`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,54 @@
|
||||
# FDN-16 – Test-Isolation je Schema für Integrationstests
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Die Integrationstests des DMS teilen sich Tabellen im Schema `public` der Test-Datenbank: Inline-DDL (`CREATE TABLE IF NOT EXISTS`) verschiedener Pakete kollidiert, veraltete Tabellen aus früheren Läufen verfälschen Ergebnisse, Rollback-Tests entfernen fremde Tabellen. Folge: `trash`, `trashapi`, `export`, `audittrail`, `documenttype`, `malwarescan` schlugen unabhängig vom Code fehl, echte Fehler blieben verdeckt. Jeder Test bekommt ein eigenes, frisches Schema (`search_path`), das danach entfernt wird.
|
||||
|
||||
**Technische Grundlage:** PostgreSQL-Schemas, `internal/testdb`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Ein Prüfergebnis ist nur belastbar, wenn es reproduzierbar ist und nicht vom Zustand vorheriger Läufe abhängt.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Geteilter Zustand zwischen Tests und Paketen; Tests, die nur grün sind, weil eine andere Suite Tabellen angelegt hat.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-02, QA-01, QA-08.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle DB-Integrationstests laufen in einem eigenen Schema und hinterlassen keine Tabellen oder Schemas
|
||||
2. Alle Pakete laufen gleichzeitig (`go test ./...`) und wiederholt ohne Kollision
|
||||
3. Ein vom Test-Datenbankbenutzer nicht ausführbarer Rollentest wird ausdrücklich übersprungen (mit Begründung), nicht als Fehler gewertet
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Alle Pakete parallel und mit `-p 1` auf dem Testhost
|
||||
2. Danach keine `dmstest_*`-Schemas in der Test-Datenbank
|
||||
3. Bisher verdeckte Fehler sind benannt und behoben oder dokumentiert
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Der Migrationstest (`internal/migrate`) ist in `FDN-13` umgestellt
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-16: test-isolation-je-schema`
|
||||
- Branch: `feature/test-schema-isolation`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,58 @@
|
||||
# FDN-17 – Worker-Verdrahtung aller Jobtypen
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Die Fachpakete liefern Handler für asynchrone Jobs (Vorschau `thumbnail.generate`, PDF-Konvertierung `pdfconvert.generate`, Virenscan `malwarescan.scan`, Massenexport `export.zip`, Texterkennung `ocr.plan`/`ocr.pages`), aber `cmd/worker` verarbeitet bisher nur die Requeue-Jobs für die RET-05-Registrierung. Alle anderen Jobs bleiben ewig `pending`; mit Virenscan bedeutet das sogar: hochgeladene Dokumente bleiben dauerhaft unsichtbar (fail-safe). Auch der Upload-Dienst im Consume-Ordner (`cmd/app`) reiht keinen dieser Jobs ein.
|
||||
|
||||
Den Worker so verdrahten, dass er alle verfügbaren Jobtypen über die Job-Queue (FDN-04) abarbeitet, mit konfigurierbarer Parallelität, und den Upload-Dienst im App-Prozess mit den passenden Einreihern versehen. Jobtypen, deren Werkzeug oder Konfiguration fehlt (kein `soffice`, kein `clamd`, kein `tesseract`), werden nicht abgeholt und das ausdrücklich gemeldet, nicht still ignoriert.
|
||||
|
||||
**Technische Grundlage:** `internal/jobqueue` (FDN-04), Umgebungsvariablen (`NEXARCH_DMS_WORKER_*`), externe Werkzeuge über `exec.LookPath`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- paperless-ngx: Verarbeitung getrennt vom Anfragedienst, mehrere Worker parallel.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Jobs, die eingereiht, aber nie verarbeitet werden, ohne dass es jemand merkt.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-04, DOC-04, DOC-06, DOC-08, DOC-17, SRC-05.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Der Worker verarbeitet alle verfügbaren Jobtypen über einen Dispatcher; ein unbekannter Jobtyp schlägt sichtbar fehl statt still zu verschwinden
|
||||
2. Ein Jobtyp ohne Werkzeug/Konfiguration wird nicht abgeholt und beim Start mit Grund gemeldet
|
||||
3. Parallelität ist konfigurierbar; mehrere Worker verarbeiten dieselbe Queue ohne Doppelverarbeitung
|
||||
4. Der Upload-Dienst im App-Prozess reiht Vorschau, Virenscan, Texterkennung und Konvertierung ein
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Ende-zu-Ende: Upload → alle Jobtypen laufen bis zum Endzustand (Vorschau bereit, Scan sauber, Text erkannt, Export bereit)
|
||||
2. Test: fehlendes Werkzeug/Konfiguration → Jobtyp nicht abgeholt, Meldung vorhanden
|
||||
3. Test: unbekannter Jobtyp landet nach den Versuchen in der Dead-Letter-Queue
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `SRC-02` Indexierungs-Worker (eigener Handler, folgt derselben Registrierung)
|
||||
- Ressourcenlimits je Job (`FDN-11`)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-17: worker-verdrahtung-aller-jobtypen`
|
||||
- Branch: `feature/fdn-17-worker-verdrahtung-aller-jobtypen`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,57 @@
|
||||
# FDN-18 – Verdrahtung der Suche in Worker und App
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Die Suche ist als Bibliothek fertig (Indexierungs-Handler `searchindex.sync`, Such-API, gespeicherte Suchen, OCR-Qualitäts-API), aber nirgends verdrahtet: der Worker holt `searchindex.sync` nicht ab, der Upload-Dienst reiht keine Indexierung ein, der Volltext der Texterkennung erreicht den Index nicht, und `cmd/app` bindet weder `/search` noch `/saved-searches` noch `/ocr` ein. Ein hochgeladenes Dokument ist damit im laufenden System nie auffindbar.
|
||||
|
||||
Den Indexierungs-Handler im Worker registrieren (mit dem OCR-Text als Volltext), die Indexierung nach Upload und nach abgeschlossener Texterkennung einreihen und die Such-Routen unter dem DMS-Routenpräfix im App-Prozess einbinden. Ohne Manticore-Konfiguration bleibt alles sauber deaktiviert und wird gemeldet.
|
||||
|
||||
**Technische Grundlage:** `internal/workerruntime` (FDN-17), `internal/searchsync`, `internal/searchapi`, `internal/savedsearchapi`, `internal/ocrapi`, Umgebungsvariablen (`NEXARCH_DMS_WORKER_MANTICORE_ADDR`, `NEXARCH_DMS_APP_MANTICORE_ADDR`)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- paperless-ngx: Index wird asynchron und selbständig nachgeführt.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein stiller Auseinanderlauf von Datenbank und Suchindex: Ist die Indexierung nicht verdrahtet, wird das beim Start gemeldet.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-17, FDN-14, SRC-02, SRC-03, SRC-05, SRC-10, QA-04.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Der Worker holt `searchindex.sync` ab, wenn Manticore konfiguriert ist, und indexiert den Volltext der Texterkennung; ohne Konfiguration wird der Jobtyp nicht abgeholt und mit Grund gemeldet
|
||||
2. Der Upload-Dienst reiht die Indexierung ein, und nach abgeschlossener Texterkennung wird das Dokument erneut indexiert
|
||||
3. `cmd/app` bindet `/search`, `/saved-searches` und `/ocr` unter dem DMS-Routenpräfix ein; ohne Manticore-/Datenbankkonfiguration bleiben sie deaktiviert und es gibt eine Warnung
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Ende-zu-Ende: Upload → Worker → Texterkennung → Suchindex → `GET /search` findet das Dokument über einen Begriff aus dem erkannten Text
|
||||
2. Test: fehlende Konfiguration → Jobtyp nicht abgeholt, Meldung vorhanden; Routen nicht eingebunden, Warnung vorhanden
|
||||
3. Such-Oberfläche im Browser gegen das echte Backend statt gegen einen Stub
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Verdrahtung von Papierkorb, Massenbearbeitung und weiteren `*api`-Paketen in `cmd/app`
|
||||
- Rechtemodell über Core (bleibt der vorläufige Besitzerfilter)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-18: verdrahtung der suche in worker und app`
|
||||
- Branch: `feature/fdn-18-verdrahtung-suche-im-worker-und-app`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,59 @@
|
||||
# FDN-19 – Gesamtsystem-Start und Smoke-Test
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 13
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Alle Kacheln sind einzeln in frischen Klonen mit Testschemas geprüft, das System lief aber nie als Ganzes: Anwendung, Worker, Suchindex, Validator-Sidecar und Datenbank zusammen, mit echten Migrationen und echter Konfiguration. Ob Verdrahtung, Konfiguration und Zusammenspiel in einem laufenden System tragen, ist unbekannt.
|
||||
|
||||
Das komplette DMS auf einem Testhost mit eigener Datenbank starten und mit einem Ende-zu-Ende-Smoke-Test durchspielen (Upload, Texterkennung, Suche, E-Rechnung, Download, Papierkorb, Löschschutz, Audit, Mandantentrennung), den Ressourcenbedarf im Betrieb messen, den Wiederanlauf prüfen und den Testaufbau spurlos zurückbauen.
|
||||
|
||||
**Technische Grundlage:** `cmd/app`, `cmd/worker`, `cmd/migrate`, Manticore, KoSIT-Sidecar (MET-07), `docs/BETRIEB-UMGEBUNGSVARIABLEN.md`, `deploy/ports.tsv`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Ein Gesamtsystem gilt erst als fertig, wenn ein reproduzierbarer Lauf es zeigt, nicht wenn die Einzelteile grün sind.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Testaufbau, der bestehende Dienste oder Datenbanken des Hosts berührt oder Restspuren hinterlässt.
|
||||
- Keine echten Betriebsschlüssel oder Kundendaten im Test: Schlüssel und Daten sind synthetisch.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-17, FDN-18, INT-01, INT-11, INT-16, MET-06, MET-07, QA-02, SRC-05, SRC-10.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Anwendung, Worker, Suchindex und Validator laufen zusammen gegen eine frisch migrierte, eigene Datenbank; der Smoke-Test durchläuft den Dokumentenlebenszyklus vollständig und reproduzierbar per Skript
|
||||
2. Der Smoke-Test belegt Mandanten- und Rechtetrennung, den fail-closed-Löschschutz ohne Archive-Anbindung und eine gültige Audit-Kette
|
||||
3. Der Aufbau lässt sich vollständig zurückbauen; der Ausgangszustand des Hosts ist danach belegt wiederhergestellt
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Ressourcenmessung im Betrieb (CPU, Speicher je Prozess und gesamt, Last vor und nach) gegen den Zielwert des Hosts, ohne Speichermangel-Abbrüche
|
||||
2. Neustart und Wiederanlauf: App und Worker während laufender Jobs beenden, Jobs laufen nach dem Neustart weiter, es entstehen keine doppelten Dokumente
|
||||
3. Rückbau ohne Restspuren: Prozesse, Dateien, Datenbank, Rolle, Suchindex-Tabellen; Dienst- und Portlisten vor und nach dem Test stimmen überein
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Anbindung an das echte Core (JWKS, Rollen, `dms.*`-Rechte) und Archive (Sperrabfrage): der Test nutzt einen lokalen Stellvertreter
|
||||
- Produktivbetrieb, Deploy auf Produktivhosts, Packaging
|
||||
- Behebung von Befunden außerhalb des Gesamtstarts (nur als Befund ausweisen)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-19: gesamtsystem-start und smoke-test`
|
||||
- Branch: `feature/fdn-19-gesamtsystem-start-smoke-test`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,58 @@
|
||||
# FDN-20 – Konfigurierbare Job-Sperrfrist und Herzschlag
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 13
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Die Sperrfrist der Job-Warteschlange ist in `cmd/worker` fest auf fünf Minuten verdrahtet. Nach hartem Abbruch von Worker oder Host laufen gehaltene Jobs deshalb erst nach knapp 300 Sekunden weiter (Befund B7 aus FDN-19). Eine kürzere Frist ist ohne Herzschlag nicht sicher, weil ein langer Job (Texterkennung, Konvertierung) dann nach Ablauf der Frist ein zweites Mal ausgeführt würde.
|
||||
|
||||
Die Sperrfrist per Umgebungsvariable konfigurierbar machen (mit geprüften Grenzen und sicherem Standard) und laufende Jobs ihre Sperre in regelmäßigen Abständen verlängern lassen. Verliert ein Worker seine Sperre, bricht er den Job ab und schreibt kein Ergebnis mehr.
|
||||
|
||||
**Technische Grundlage:** `internal/jobqueue` (Queue, Worker), `cmd/worker`, `docs/BETRIEB-UMGEBUNGSVARIABLEN.md`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Ein abgestürzter Worker verzögert Verarbeitung nur kurz und ohne Datenverlust, ein langer Job wird nicht doppelt ausgeführt.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein stilles Doppelverarbeiten: Ein Worker, der seine Sperre verloren hat, darf den Job weder abschließen noch als fehlgeschlagen markieren.
|
||||
- Keine unsichere Konfiguration: Werte außerhalb des zulässigen Bereichs verhindern den Start, statt stillschweigend ersetzt zu werden.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-04, FDN-11, FDN-17, FDN-19.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Die Sperrfrist ist per Umgebungsvariable einstellbar; der Standard bleibt fünf Minuten, ungültige oder außerhalb des Bereichs liegende Werte verhindern den Start mit klarer Meldung
|
||||
2. Laufende Jobs verlängern ihre Sperre regelmäßig; ein Job, der länger als die Sperrfrist läuft, wird nicht von einem zweiten Worker abgeholt
|
||||
3. Ein Worker, der seine Sperre verloren hat, bricht den Job ab und verändert dessen Zustand nicht mehr
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Doppelausführung: Ein Job, der ein Mehrfaches der Sperrfrist läuft, wird von genau einem Worker ausgeführt; es entsteht kein doppeltes Ergebnis
|
||||
2. Wiederanlauf nach hartem Abbruch mit kurzer Sperrfrist: Der gehaltene Job läuft nach Ablauf der (kurzen) Frist weiter, ohne Datenverlust
|
||||
3. Negativfälle: ungültige, negative, zu kleine und zu große Werte werden abgewiesen
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Änderungen an Jobtypen, Handlern oder Retry-/Backoff-Logik
|
||||
- Sperrverwaltung außerhalb der Job-Warteschlange (z. B. Dokumentensperren)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-20: konfigurierbare job-sperrfrist und herzschlag`
|
||||
- Branch: `feature/fdn-20-job-sperrfrist-herzschlag-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,54 @@
|
||||
# FDN-21 – Suchindex-Name je Instanz
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentag | **Welle:** 13
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Der Suchindex-Name `dms_documents` ist fest im Code verdrahtet (Befund B9 aus FDN-19). Mehrere DMS-Instanzen auf demselben Manticore, wie es Modell C (eine Instanz je Mandant) vorsieht, würden sich gegenseitig überschreiben, und ein Entwicklungsbetrieb teilt sich den Namen mit Tests.
|
||||
|
||||
Den Namen je Instanz konfigurierbar machen, durch alle Verwender durchreichen und belegen, dass zwei Instanzen auf demselben Manticore einander nicht beeinflussen.
|
||||
|
||||
**Technische Grundlage:** `internal/searchindex` (`schema.go`, `query.go`, `facets.go`), `searchapi`, `searchsync`, `savedsearch`, `workerruntime`, `apiwiring`, `cmd/app`, `cmd/worker`, `docs/BETRIEB-UMGEBUNGSVARIABLEN.md`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Bewusst vermeiden:**
|
||||
- Kein stilles Auseinanderlaufen oder Überschreiben von Indexen verschiedener Mandanten. Ein falsch geschriebener oder unzulässiger Name ist ein Startfehler, kein stiller Ersatzname.
|
||||
- Keine Änderung des Verhaltens bestehender Installationen ohne Vorwarnung: der Standardname bleibt `dms_documents`.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: SRC-01, SRC-02, SRC-03, SRC-08, SRC-10, FDN-18, FDN-19.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Der Indexname ist per Umgebungsvariable je Instanz einstellbar (Standard `dms_documents`) und wird in App, Worker, Suche, gespeicherten Suchen und Konsistenzprüfung einheitlich verwendet
|
||||
2. Ungültige Namen (Zeichen außerhalb `[a-z][a-z0-9_]{0,62}`, leer, Manticore-Schlüsselwörter) werden beim Start abgelehnt
|
||||
3. Zwei Instanzen mit verschiedenen Namen auf demselben Manticore sehen, ändern und löschen nur ihre eigenen Dokumente
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Zwei Instanzen parallel gegen dasselbe Manticore: Indexieren, Suchen, Neuindexierung und Löschen der einen Instanz lassen die andere unverändert
|
||||
2. Bestehende Installation ohne gesetzte Variable liest weiterhin `dms_documents`
|
||||
3. Eingeschleuste Namen (`x; DROP TABLE y`, Leerzeichen, Groß-/Kleinschreibung, zu lang) erreichen nie eine Manticore-Anfrage
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Automatische Vergabe von Namen aus dem Mandanten (der Betrieb setzt den Namen)
|
||||
- Umzug oder Umbenennung bestehender Indexe
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-21: suchindex-name je instanz`
|
||||
- Branch: `feature/fdn-21-suchindex-name-je-instanz-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,56 @@
|
||||
# FDN-22 – Verschlüsselung der Textkopien (DSGVO)
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 13
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Dateien liegen verschlüsselt im Objekt-Speicher (FDN-09, Envelope-Verfahren mit Mandanten-KEK), ihr Klartext aber zusätzlich unverschlüsselt in der Datenbank: als OCR-Text je Seite (`revision_ocr_pages.text`, SRC-05), als extrahierter Klartext (`revision_text_index.text`, SRC-13) und als Suchtext der E-Rechnung (`revision_einvoice.search_text`, MET-06). Wer die Datenbank liest oder sichert, bekommt damit den Inhalt aller Dokumente. Für Kunden mit personenbezogenen Daten und besonderen Kategorien (Art. 9 DSGVO) ist das nicht hinnehmbar.
|
||||
|
||||
Die drei Textspeicher verschlüsselt ablegen, Bestandsdaten überführen und belegen, dass ohne Schlüssel kein Klartext zurückfällt. Der Suchindex (Manticore) enthält notwendig durchsuchbare Begriffe und kann nicht verschlüsselt werden: Restrisiko und Betriebsvorgabe festhalten.
|
||||
|
||||
**Technische Grundlage:** `internal/crypto`, neues Paket `internal/textcrypt`, `internal/ocr`, `internal/plaintext`, `internal/einvoice`, `internal/workerruntime`, Migration `0031`, `docs/BETRIEB-UMGEBUNGSVARIABLEN.md`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Bewusst vermeiden:**
|
||||
- Kein stiller Rückfall auf Klartext: fehlt der Schlüssel oder ist er falsch, schlägt der Zugriff fehl.
|
||||
- Kein Datenverlust bei der Überführung von Bestandsdaten und keine Entschlüsselung in der Datenbank (nur im Speicher des Dienstes).
|
||||
- Kein Vermischen von Mandanten: ein Text ist an seine Revision und Seite gebunden (Additional Data) und mit dem Mandanten-KEK verpackt.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-09, SRC-05, SRC-07, SRC-13, MET-06.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. OCR-Text, Klartext-Extrakt und E-Rechnungs-Suchtext werden nur verschlüsselt gespeichert (AES-256-GCM, DEK je Revision mit dem Mandanten-KEK verpackt, Bindung an Revision und Seite); die Klartextspalten bleiben leer
|
||||
2. Suche, Regelauswertung, Sprachbestimmung und E-Rechnungs-Indexierung liefern unverändert dieselben Ergebnisse; fehlender oder falscher Schlüssel und ein fremder Mandanten-KEK führen zu einem Fehler, nie zu Klartext
|
||||
3. Bestehende Klartextzeilen lassen sich ohne Datenverlust nachverschlüsseln, der Stand ist abfragbar; endgültiges Löschen entfernt Text und Indexeintrag
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Rohabfrage der drei Tabellen nach einem Lauf enthält kein Klartextwort, weder in Textspalten noch im Byte-Inhalt der Chiffretexte
|
||||
2. Falscher Schlüssel, fehlender Schlüsselbezug und Chiffretext einer anderen Revision oder Seite werden abgelehnt
|
||||
3. Bestandsdaten: Klartext vorher, verschlüsselt nachher, Suche vorher und nachher gleich; zweiter Lauf ändert nichts
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Verschlüsselung des Manticore-Index (Restrisiko, siehe Protokoll)
|
||||
- Verschlüsselung der Metadatenfelder und der Fehlerliste (`findings`)
|
||||
- Schlüsselrotation der Textschlüssel (der KEK-Wechsel läuft über das Umverpacken des DEK wie bei FDN-09)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-22: verschlüsselung der textkopien`
|
||||
- Branch: `feature/fdn-22-verschluesselung-textkopien-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,61 @@
|
||||
# FDN-23 – Periodischer Integritätsjob für Objektprüfsummen
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 13
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Das DMS speichert je Revision den SHA-256 des Klartexts (`file_revisions.checksum_sha256`) und das Objekt verschlüsselt im Storage (FDN-03, FDN-09). Ob beides dauerhaft zusammenpasst, prüft heute nur der Download beim Lesen. Ein beschädigtes, fehlendes oder nicht mehr entschlüsselbares Objekt fällt erst auf, wenn jemand es öffnet (Vergleichsanalyse: paperless-ngx besitzt dafür einen „Sanity-Checker“).
|
||||
|
||||
Einen periodischen Job im Worker ergänzen, der Revisionen stichprobenweise oder vollständig prüft: Objekt vorhanden, entschlüsselbar, Größe und SHA-256 des entschlüsselten Klartexts stimmen mit der Datenbank überein. Das Ergebnis wird je Revision und je Lauf abgelegt, eine Abweichung erzeugt ein Audit-Ereignis.
|
||||
|
||||
**Technische Grundlage:** `internal/jobqueue`, `internal/workerruntime`, `internal/storage`, `internal/crypto`, `internal/audittrail`, `cmd/worker`, `docs/BETRIEB-UMGEBUNGSVARIABLEN.md`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Regelmäßige Integritätsprüfung wie der Sanity-Checker von paperless-ngx, aber mit prüfbarem Ergebnis je Revision.
|
||||
- Nachgewiesene Wiederherstellbarkeit setzt voraus, dass Beschädigung früh sichtbar wird, nicht erst beim Zugriff.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Verwechslung von Infrastrukturfehlern mit Integritätsverletzungen: Ein nicht erreichbarer Speicher oder KEK-Dienst ist `error`, keine Aussage über das Objekt.
|
||||
- Keine Dauerlast: Prüfung ist begrenzt (Stichprobe, Zeitfenster, Pausen) und setzt nach Abbruch dort fort, wo sie aufgehört hat.
|
||||
- Keine falschen Alarme bei gelöschten oder im Papierkorb liegenden Dokumenten.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-03, FDN-04, FDN-09, FDN-11, FDN-17, FDN-20, VER-09, DOC-01.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Der Job prüft je Revision Vorhandensein, Entschlüsselbarkeit, Größe und SHA-256 und legt das Ergebnis mit den getrennten Zuständen `ok`, `mismatch`, `missing`, `unreadable` und `error` je Revision und je Lauf ab
|
||||
2. Eine Abweichung (`mismatch`, `missing`, `unreadable`) erzeugt genau ein Audit-Ereignis je Statuswechsel, die Hash-Kette bleibt gültig; Speicher- oder Schlüsseldienstfehler (`error`) werden nicht als Integritätsverletzung gemeldet
|
||||
3. Der Lauf ist über Umgebungsvariablen steuerbar (Intervall, Stichprobengröße oder Vollprüfung, Zeitfenster, Pausen, Zeitlimit je Revision), begrenzt in Dauer und Last und setzt nach Abbruch fort; gelöschte und im Papierkorb liegende Dokumente werden nicht als Fehler gemeldet
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Absichtlich beschädigtes Objekt (`mismatch` bzw. `unreadable`), fehlendes Objekt (`missing`) und falscher Schlüssel (`unreadable`) werden erkannt; unversehrte Objekte bleiben `ok`
|
||||
2. Abbruch mitten im Lauf und Neustart: Die Prüfung setzt fort, keine Revision wird ausgelassen oder doppelt gemeldet
|
||||
3. Mandantentrennung: Ergebnisse und Audit-Ereignisse eines Mandanten sind nur in dessen Datenbank sichtbar; ein fremder Schlüssel ergibt `unreadable`, nie `ok`
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Reparatur oder Wiederherstellung beschädigter Objekte (Archive-Backup)
|
||||
- Oberfläche oder API zur Anzeige der Ergebnisse
|
||||
- Prüfung von Derivaten (Vorschau, PDF/A, OCR-Text) und Suchindex (siehe SRC-02, SRC-11)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-23: periodischer integritätsjob für objektprüfsummen`
|
||||
- Branch: `feature/fdn-23-integritaetsjob-objektpruefsummen-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,60 @@
|
||||
# FDN-24 – Pfadbereinigung bei Export und Wiederherstellung, Zeitlimit für pdftoppm
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentag | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Zip-Eintragsnamen des Exports entstehen ungeprüft aus dem Dokumenttitel (`../`, absolute Pfade, Steuerzeichen), das Entpacken von Sicherungen im Archive prüft Tar-Pfade nicht (Tar-Slip), und `pdftoppm` läuft ohne Zeitlimit (Befunde F-12, F-13). Titel werden zu sicheren Dateinamen bereinigt, Tar-Einträge außerhalb des Zielverzeichnisses als beschädigt abgewiesen, und `pdftoppm` läuft mit Kontext und Zeitlimit.
|
||||
|
||||
**Technische Grundlage:** `dms/internal/export` (`sanitizeEntryName`), `archive/internal/backup` (`safeExtractPath`, `extractFileMode`), `dms/internal/thumbnail` (`RenderTimeout`, `CommandContext`)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Dateiname aus Nutzereingaben ist nie ein Pfad.
|
||||
|
||||
**Übernehmen:**
|
||||
- Exportformat (ZIP mit `manifest.csv`) und Dublettenzähler bleiben.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Entpacken außerhalb des Zielverzeichnisses, keine setuid-Bits aus Archiven.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `QA-15` Sicherheitsprüfung Gesamtprojekt – Befundbericht `docs/SICHERHEITSPRUEFUNG-GESAMTPROJEKT.md`, hier: F-12 (mittel), F-13 (mittel, Teil Zeitlimit).
|
||||
- `DOC-15` Export, `DOC-04` Vorschau, `FDN-11` Ressourcenlimits.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Zip-Eintragsnamen enthalten nur den letzten Namensbestandteil ohne Steuerzeichen und Windows-Sonderzeichen, nie `.` oder `..`, höchstens 200 Bytes bei erhaltener Endung
|
||||
2. Tar-Einträge mit `..`, absolutem Pfad oder NUL werden als beschädigt abgewiesen; Dateirechte übernehmen nur Berechtigungsbits ohne Schreibrecht für Gruppe und andere
|
||||
3. `pdftoppm` wird nach 60 s (konfigurierbar) beendet, auch bei Abbruch des Auftrags-Kontexts; die Fehlermeldung ist gekürzt
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Tests mit Pfadangriffen (`../`, `..\\`, absolute Pfade, NUL, lange und mehrbyte-Namen) und mit einem hängenden Ersatzprogramm
|
||||
2. Bestehende Export-, Thumbnail- und Backup-Tests grün
|
||||
3. `soffice`-Sandbox und Prozess-Isolation bleiben offen (OPS-Ticket)
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Sandbox für externe Prozesse (Systemd-Direktiven, bubblewrap)
|
||||
- Formel-Einschleusung in `manifest.csv` (CSV-Injection)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Status: umgesetzt in Branch `feature/qa-15-phase2b-sicherheitsbehebung` (PR gegen `integration/gesamtprojekt`), Protokoll `docs/QA-15-PHASE2B-PRUEFPROTOKOLL.md`
|
||||
- Commit-Nachricht: `FDN-24: pfadbereinigung bei export und wiederherstellung, zeitlimit fuer pdftoppm`
|
||||
- Branch: `feature/qa-15-phase2b-sicherheitsbehebung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# FDN-26 – Skalierungs-Benchmark für große Dokumentbestände
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Alle bisherigen Performance-Zielwerte (Suche <500ms, Facetten <50ms, RBAC-11-Vererbung <50ms) wurden gegen kleine synthetische Testkorpora gemessen. Ob sie bei einem großen Dokumentbestand noch halten, ist unbelegt (Vergleichsanalyse Runde 2: fehlende Skalierungs-Benchmarks als Lücke gegenüber teils vorhandenen Referenzwerten der Quellsysteme).
|
||||
|
||||
Einen wiederholbaren Lastgenerator bauen, der eine große synthetische Dokumentmenge über den echten Upload-Pfad erzeugt, danach Suchlatenz, Facetten-/Filter-Antwortzeit, Ordnernavigation, Job-Queue-Durchsatz, Datenbank-/Indexgröße und Migrationsdauer messen und gegen die bestehenden Zielwerte prüfen.
|
||||
|
||||
**Technische Grundlage:** `internal/testcorpus`, `internal/upload`, `internal/searchindex`, `internal/searchapi`, `internal/folderapi`, `internal/jobqueue`, `cmd/migrate`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Eine Zielzahl ohne Messung bei realistischer Größe ist eine Behauptung, kein Nachweis.
|
||||
|
||||
**Übernehmen:**
|
||||
- Erzeugung über den echten Pfad (Upload-API), nicht per Direkt-SQL, damit OCR-Anbindung, Suchindex und Metadaten-Pipeline mitlaufen.
|
||||
- Wiederholbarkeit: derselbe Lastgenerator lässt sich für künftige Regressionsmessungen erneut ausführen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Optimierung an Zielwerten vorbei: fällt eine Messung durch, wird das als Befund mit Vorschlag dokumentiert, nicht stillschweigend die Zielzahl angehoben.
|
||||
- Kein Dauerbestand: nach dem Lauf werden alle erzeugten Daten vollständig entfernt.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-04, FDN-21, DOC-01, SRC-08, RBAC-11 (Anbindung im DMS, siehe DOC-23).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Ein Werkzeug erzeugt eine synthetische Dokumentmenge über den echten Upload-Pfad und lässt sich mit einer wählbaren Zielgröße wiederholt ausführen
|
||||
2. Suchlatenz (p50/p95/p99), Facetten-/Filter-Antwortzeit und Ordnernavigation sind bei der Zielmenge gemessen und mit den bestehenden Zielwerten aus QA-13, SRC-08 und RBAC-11 verglichen
|
||||
3. Job-Queue-Durchsatz, Datenbank-/Indexgröße und Migrationsdauer auf befüllter Datenbank sind gemessen und im Protokoll mit Zahlen festgehalten
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Lastgenerator läuft wiederholt ohne manuelle Eingriffe und meldet Fortschritt
|
||||
2. Alle Messwerte sind reale Zahlen aus dem Lauf, keine Schätzungen; Abweichungen von bestehenden Zielwerten sind als Befund mit Optimierungsvorschlag dokumentiert
|
||||
3. Nach Abschluss sind alle erzeugten Testdaten, Schemas und Indexeinträge vollständig entfernt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Optimierung gefundener Engpässe (außer trivialer Indexfixes)
|
||||
- Dauerhaftes Last-/Monitoring-Dashboard
|
||||
- Lasttest gegen mehrere gleichzeitige Mandanten
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test bzw. reproduzierbaren Messlauf.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-26: skalierungs-benchmark für große dokumentbestände`
|
||||
- Branch: `feature/fdn-25-skalierungs-benchmark-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,60 @@
|
||||
# FDN-27 – Backup- und Wiederherstellungsnachweis
|
||||
|
||||
**Epic:** ⚙️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 15
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Der Gesamtsystem-Smoke-Test (FDN-19) belegt nur den Wiederanlauf laufender Dienste, kein eigenständiges Backup-Werkzeug und keinen echten Restore-Nachweis. Die Vergleichsanalyse (Runde 2) benennt das als Lücke: „Backup/Restore-Nachweis für DMS-Daten unvollständig dokumentiert“.
|
||||
|
||||
Ein Werkzeug bauen, das einen konsistenten Snapshot aus Postgres-Daten und verschlüsselten Storage-Objekten erzeugt, und ein Gegenstück, das diesen Snapshot in eine leere Zielumgebung einspielt und den Suchindex daraus neu aufbaut (Manticore selbst wird nicht gesichert, da er aus Postgres/Storage rekonstruierbar ist). Ein echter Restore auf einen zweiten, unabhängigen Stand weist nach, dass Dokumentzahl, Prüfsummen und Suche nach der Wiederherstellung übereinstimmen.
|
||||
|
||||
**Technische Grundlage:** `internal/storage`, `internal/crypto`, `internal/integrity`, `internal/searchsync`, `internal/searchindex`, `dms/cmd/migrate`, `docs/BETRIEB-UMGEBUNGSVARIABLEN.md`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Nachgewiesene Wiederherstellbarkeit ist Freigabevoraussetzung (siehe QA-Leitsatz), nicht nur behauptet.
|
||||
- Verschlüsselte Objekte bleiben im Backup verschlüsselt, Restore braucht denselben KEK-Zugang wie das Original.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Duplizieren der Konsistenzprüfung aus FDN-23 (Objektintegrität) oder SRC-02/SRC-11 (Index-Konsistenz) – das Werkzeug nutzt sie nach dem Restore, statt sie neu zu bauen.
|
||||
- Kein Sichern des Suchindex selbst – er ist aus Postgres und Storage vollständig rekonstruierbar.
|
||||
- Keine geschätzten Zeitwerte – RTO/RPO werden real gemessen, nicht angenommen.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: FDN-03, FDN-09, FDN-21, FDN-23, SRC-02, SRC-11.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Ein Backup-Werkzeug erzeugt aus einer laufenden Instanz einen konsistenten Snapshot: Postgres-Daten, verschlüsselte Storage-Objekte mit Prüfsummen-Manifest; der Suchindex wird nicht mitgesichert
|
||||
2. Ein Restore-Werkzeug spielt den Snapshot in eine leere Zieldatenbank und ein leeres Zielverzeichnis ein und baut den Suchindex vollständig neu auf
|
||||
3. Nach einem echten Restore auf einen zweiten, unabhängigen Stand stimmen Dokumentzahl, Objektprüfsummen (FDN-23-Integritätsjob liefert `ok`) und Suchtreffer mit dem Original überein; RTO und RPO sind für die Testmenge real gemessen, nicht geschätzt
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Backup und Restore auf einem zweiten, komplett unabhängigen Datenbank-/Storage-/Index-Stand real durchgeführt, nicht simuliert
|
||||
2. Restore mit falschem oder fehlendem KEK-Zugang schlägt kontrolliert fehl, liefert keinen unvollständigen oder unverschlüsselten Teilzustand
|
||||
3. Gemessene Dauer für Backup und Restore bei der Testmenge dokumentiert (RTO/RPO)
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Automatisierte, wiederkehrende Backup-Zeitplanung im Betrieb (Betriebsentscheidung, siehe DEPLOYMENT-131-CHECKLISTE.md)
|
||||
- Oberfläche zur Steuerung von Backup/Restore
|
||||
- Sicherung/Wiederherstellung von Core-, Archive- oder Mail-Daten (eigene Module, eigene Tickets)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-27: backup- und wiederherstellungsnachweis`
|
||||
- Branch: `feature/fdn-27-backup-wiederherstellungsnachweis-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
@@ -0,0 +1,44 @@
|
||||
# FDN-28 – Rückstau/Drosselung vor dem Datenbank-Verbindungspool (Nachtrag zu QA-10)
|
||||
|
||||
**Epic:** 🏗️ Fundament | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API).
|
||||
|
||||
## Auftrag
|
||||
QA-10 (Last-/Leistungstest) hat bei 150 gleichzeitigen Anfragen einen echten Engpass gefunden: der Postgres-Verbindungspool läuft mit `too many clients already` (SQLSTATE 53300) über — sowohl HTTP-Anfragen als auch Hintergrundjobs (Malware-Scan, Such-Synchronisierung) scheitern dabei mit rohen Verbindungsfehlern statt einer definierten `503`-Antwort. Es fehlt eine Rückstau-/Zulassungssteuerung zwischen HTTP-Handlern und dem DB-Pool.
|
||||
|
||||
**Technische Grundlage:** Begrenzung gleichzeitiger Anfragen (z. B. Semaphor/Worker-Pool vor dem DB-Zugriff), definierte `503`-Antwort mit `Retry-After` bei Überlast, unverändertes Verhalten unterhalb der Grenze.
|
||||
|
||||
## Ausgangslage
|
||||
`dms/docs/QA-10-PRUEFPROTOKOLL.md` (Befund im Überlast-Abschnitt), `dms/internal/apiwiring` (HTTP-Verdrahtung), bestehender Postgres-Pool (`pgxpool`).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
1. Bei Überschreiten einer konfigurierbaren Zulassungsgrenze antwortet die API mit `503` und `Retry-After` statt eines rohen Verbindungsfehlers
|
||||
2. Hintergrundjobs (Malware-Scan, Such-Synchronisierung) laufen bei Überlast verzögert statt mit Verbindungsfehlern zu scheitern
|
||||
3. Verhalten unterhalb der Zulassungsgrenze bleibt unverändert (keine Regression bei normaler Last)
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
1. Simulierte Überlast (analog QA-10s Überlast-Phase): keine rohen Verbindungsfehler mehr, definierte `503`-Antworten mit `Retry-After`
|
||||
2. Hintergrundjobs unter derselben Überlast: verzögerte Verarbeitung statt Fehlschlag, kein Datenverlust
|
||||
3. Bestehende QA-10-Prüfungen (realistische Last, Erholung, Dauerlast) laufen unverändert grün
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Grundlegende Postgres-Pool-Größenänderung (nur Zulassungssteuerung davor)
|
||||
- Horizontale Skalierung/mehrere Instanzen
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst `dms/docs/QA-10-PRUEFPROTOKOLL.md` für den genauen Befund.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `FDN-28: rueckstau drosselung vor db-verbindungspool`
|
||||
- Branch: `feature/fdn-28-rueckstau-drosselung-db-verbindungspool`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,66 @@
|
||||
# INT-01 – REST-API v1 & Schnittstellenbeschreibung
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Dokument-spezifische API-Endpunkte (Dokument abrufen/anlegen/durchsuchen usw.) auf dem zentralen Core-REST-Grundgerüst definieren und dokumentieren – keine eigene Router-/Versionierungs-Infrastruktur, die liefert Core API-01.
|
||||
|
||||
**Technische Grundlage:** REST, OpenAPI
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Postfach-Abruf mit Regelwerk und sauberer Anhangbehandlung nach dem Vorbild von Docspell.
|
||||
- Überwachter Ordner als universelle Einlieferung, wie ihn paperless-ngx populär gemacht hat.
|
||||
- Stapelverarbeitung mit Trennseiten für Netzwerkscanner, wie sie ecoDMS praxistauglich löst.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Schnittstelle, die weniger kann als die Oberfläche. Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle.
|
||||
- Kein eigener Arbeitsplatz-Client als Voraussetzung für Kernfunktionen.
|
||||
|
||||
**Für genau diese Kachel:** Die Schnittstelle ist das Produkt. Die eigene Oberfläche darf keinen einzigen internen Sonderweg nutzen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `RBAC-02` Policy-Enforcement-Schicht (zentral).
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-01` REST-API-Grundgerüst & Versionierung.
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle dokument-eigenen Endpunkte sind in der Beschreibung dokumentiert
|
||||
2. Einheitliches Fehlerformat über alle Endpunkte (geerbt vom Core-REST-Grundgerüst)
|
||||
3. Endpunkte laufen auf der zentralen, versionierten Core-API auf, keine eigene Versionierung
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Vertragstests gegen die Beschreibung laufen in der Pipeline
|
||||
2. Berechtigungen greifen identisch wie in der Oberfläche
|
||||
3. Beispielaufrufe aus der Dokumentation funktionieren
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Setzt voraus (externes Core-Board): `API-03` Zentrales Rate-Limiting & API-Gateway-Schicht
|
||||
- Setzt voraus (externes Core-Board): `API-07` Zentrale Webhook-Registry & Zustellung
|
||||
- `QA-10` Last- & Leistungstest
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-01: rest-api v1 & schnittstellenbeschreibung`
|
||||
- Branch: `feature/int-01-rest-api-v1-schnittstellenbeschreibung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# INT-03 – E-Mail-Abruf über IMAP
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Überwachte Postfächer regelmäßig abrufen, Nachrichten und Anhänge importieren und verarbeitete Nachrichten markieren.
|
||||
|
||||
**Technische Grundlage:** IMAP-Client, Job-Zeitplan
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Postfach-Abruf mit Regelwerk und sauberer Anhangbehandlung nach dem Vorbild von Docspell.
|
||||
- Überwachter Ordner als universelle Einlieferung, wie ihn paperless-ngx populär gemacht hat.
|
||||
- Stapelverarbeitung mit Trennseiten für Netzwerkscanner, wie sie ecoDMS praxistauglich löst.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Schnittstelle, die weniger kann als die Oberfläche. Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle.
|
||||
- Kein eigener Arbeitsplatz-Client als Voraussetzung für Kernfunktionen.
|
||||
|
||||
**Für genau diese Kachel:** Der Postfach-Abruf von Docspell ist ausgereift. Übernimm besonders die Behandlung von Nachricht und Anhängen als zusammengehörige Einheit.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-04` Job-Queue & Worker-Runtime – Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Mehrere Postfächer parallel überwachbar
|
||||
2. Nachricht und Anhänge werden als Dokumente abgelegt
|
||||
3. Verarbeitete Nachrichten werden nicht erneut importiert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Verbindungsabbruch führt zu Wiederholung ohne Duplikate
|
||||
2. Nachricht mit 20 Anhängen korrekt importiert
|
||||
3. Zugangsdaten liegen ausschließlich verschlüsselt vor
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `INT-04` E-Mail-Regeln & Anhangverarbeitung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-03: e-mail-abruf über imap`
|
||||
- Branch: `feature/int-03-e-mail-abruf-über-imap`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# INT-04 – E-Mail-Regeln & Anhangverarbeitung
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 7
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Regeln nach Absender, Betreff oder Anhangtyp steuern Ablageort, Typ und Verschlagwortung importierter Nachrichten.
|
||||
|
||||
**Technische Grundlage:** Regelwerk, Anhangfilter
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Postfach-Abruf mit Regelwerk und sauberer Anhangbehandlung nach dem Vorbild von Docspell.
|
||||
- Überwachter Ordner als universelle Einlieferung, wie ihn paperless-ngx populär gemacht hat.
|
||||
- Stapelverarbeitung mit Trennseiten für Netzwerkscanner, wie sie ecoDMS praxistauglich löst.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Schnittstelle, die weniger kann als die Oberfläche. Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle.
|
||||
- Kein eigener Arbeitsplatz-Client als Voraussetzung für Kernfunktionen.
|
||||
|
||||
**Für genau diese Kachel:** Signaturbilder und Werbeanhänge müssen ausfilterbar sein, sonst verstopft der Import das Archiv.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `INT-03` E-Mail-Abruf über IMAP – Überwachte Postfächer regelmäßig abrufen, Nachrichten und Anhänge importieren und verarbeitete Nachrichten markieren.
|
||||
- `MET-05` Regelbasierte Auto-Verschlagwortung – Regeln auf Basis von Textmustern, Absender oder Dateiname vergeben automatisch Tags, Typ und Ablageort.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Regeln greifen auf Absender, Betreff und Anhangtyp zu
|
||||
2. Signaturbilder und Werbeanhänge sind ausfilterbar
|
||||
3. Nachricht bleibt als Kontext am Dokument erhalten
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Regelwerk an Testpostfach mit erwarteter Zuordnung geprüft
|
||||
2. Nachricht ohne passende Regel landet im Klärungskorb
|
||||
3. Filter verwirft keine relevanten Anhänge
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-09` Schnittstellen-Vertragstests
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-04: e-mail-regeln & anhangverarbeitung`
|
||||
- Branch: `feature/int-04-e-mail-regeln-anhangverarbeitung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# INT-06 – Scanner-Anbindung über Hot-Folder
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Überwachtes Verzeichnis für Netzwerkscanner mit Stapeltrennung, automatischer Texterkennung und Ablage.
|
||||
|
||||
**Technische Grundlage:** Überwachter Ordner, Trennseiten
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Postfach-Abruf mit Regelwerk und sauberer Anhangbehandlung nach dem Vorbild von Docspell.
|
||||
- Überwachter Ordner als universelle Einlieferung, wie ihn paperless-ngx populär gemacht hat.
|
||||
- Stapelverarbeitung mit Trennseiten für Netzwerkscanner, wie sie ecoDMS praxistauglich löst.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Schnittstelle, die weniger kann als die Oberfläche. Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle.
|
||||
- Kein eigener Arbeitsplatz-Client als Voraussetzung für Kernfunktionen.
|
||||
|
||||
**Für genau diese Kachel:** Der Stapelworkflow von ecoDMS ist praxiserprobt: Trennseiten teilen den Stapel in Einzeldokumente.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
- `SRC-05` OCR-Worker – Texterkennung für Scans und Bilder inklusive Entzerrung, Rauschunterdrückung und Speicherung des Volltexts je Seite.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Neue Dateien werden automatisch übernommen
|
||||
2. Stapel werden anhand von Trennseiten aufgeteilt
|
||||
3. Fehlerhafte Dateien landen in einem Fehlerordner
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Datei wird erst nach vollständigem Schreiben verarbeitet
|
||||
2. Stapeltrennung an Referenzstapel geprüft
|
||||
3. Doppelte Einlieferung erzeugt kein Duplikat
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-09` Schnittstellen-Vertragstests
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-06: scanner-anbindung über hot-folder`
|
||||
- Branch: `feature/int-06-scanner-anbindung-über-hot-folder`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,66 @@
|
||||
# INT-08 – Watch-Folder-Import (Consume-Ordner)
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Dateisystem-Ordner, der automatisch überwacht wird — jede dort abgelegte Datei wird ohne API-Aufruf importiert. Ergänzt DOC-01 (Upload-API), ersetzt sie nicht — für Nutzer, die Dateien nicht über die Oberfläche hochladen, sondern per Netzwerkfreigabe/Sync-Tool ablegen.
|
||||
|
||||
**Technische Grundlage:** Überwachter Ordner, Dateisystem-Events/Polling
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Postfach-Abruf mit Regelwerk und sauberer Anhangbehandlung nach dem Vorbild von Docspell.
|
||||
- Überwachter Ordner als universelle Einlieferung, wie ihn paperless-ngx populär gemacht hat.
|
||||
- Stapelverarbeitung mit Trennseiten für Netzwerkscanner, wie sie ecoDMS praxistauglich löst.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Schnittstelle, die weniger kann als die Oberfläche. Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle.
|
||||
- Kein eigener Arbeitsplatz-Client als Voraussetzung für Kernfunktionen.
|
||||
|
||||
**Für genau diese Kachel:** paperless-ngx' "kompromisslose Erfassungs-Pipeline … vollautomatisch ohne Nutzerinteraktion" — hier konkret als Consume-Ordner umgesetzt, der ohne API-Aufruf importiert.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision. Der Watch-Folder-Import mündet in denselben Pipeline-Weg, den DOC-01 für API-Uploads etabliert hat.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Datei im überwachten Ordner wird automatisch erkannt und importiert, ohne manuellen Trigger
|
||||
2. Importierte Datei durchläuft denselben Pipeline-Weg wie ein API-Upload (Hash/Dedup/Verschlüsselung/OCR/Index)
|
||||
3. Fehlerhafte/nicht lesbare Datei landet in einem Fehler-Unterordner statt den Import-Prozess zu blockieren
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Testdatei im Ordner abgelegt, erscheint automatisch als Dokument
|
||||
2. Pipeline-Schritte (Hash, Dedup-Gate, Verschlüsselung) im Test nachweislich durchlaufen
|
||||
3. Absichtlich beschädigte Datei landet im Fehler-Unterordner, blockiert restlichen Ordner nicht
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `DOC-02` Dublettenerkennung
|
||||
- `SRC-05` OCR-Worker
|
||||
- `SRC-02` Indexierungs-Worker & Synchronisierung
|
||||
- `INT-06` Scanner-Anbindung über Hot-Folder
|
||||
- `INT-10` Scanner-Stapelverarbeitung mit Trennseiten-/Barcode-Erkennung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-08: watch-folder-import (consume-ordner)`
|
||||
- Branch: `feature/int-08-watch-folder-import-consume-ordner`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# INT-09 – CMIS-kompatible Schnittstelle (optional)
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
CMIS-Standardschnittstelle (Content Management Interoperability Services) als optionale zusätzliche API neben der eigenen REST-API — ermöglicht Drittwerkzeugen (ECM-Migrationstools, manche Office-Plugins), die CMIS sprechen, direkten Zugriff auf DMS-Inhalte, ohne NEXARCH-spezifische Integration schreiben zu müssen.
|
||||
|
||||
**Technische Grundlage:** CMIS 1.1 (AtomPub oder Browser-Binding)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Postfach-Abruf mit Regelwerk und sauberer Anhangbehandlung nach dem Vorbild von Docspell.
|
||||
- Überwachter Ordner als universelle Einlieferung, wie ihn paperless-ngx populär gemacht hat.
|
||||
- Stapelverarbeitung mit Trennseiten für Netzwerkscanner, wie sie ecoDMS praxistauglich löst.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Schnittstelle, die weniger kann als die Oberfläche. Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle.
|
||||
- Kein eigener Arbeitsplatz-Client als Voraussetzung für Kernfunktionen.
|
||||
|
||||
**Für genau diese Kachel:** Alfresco beherrscht CMIS als Standard — NEXARCH übernimmt das Prinzip offener Interoperabilität (ecoDMS-Lehre "was die Oberfläche kann, kann auch die offene Schnittstelle"), ohne Alfresco's Gesamtgewicht zu übernehmen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `INT-01` REST-API v1 & Schnittstellenbeschreibung – Öffentliche REST-API mit vollständiger OpenAPI-Beschreibung. Die CMIS-Schicht spiegelt die dort etablierten Rechte- und Mandantenprüfungen, statt sie neu zu erfinden.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. CMIS-Basisoperationen (Objekt lesen, Ordner navigieren, Dokument hochladen) funktionieren gegen einen CMIS-Standard-Client
|
||||
2. CMIS-Zugriff respektiert dieselben Rechte/Mandantengrenzen wie die eigene REST-API
|
||||
3. Optional aktivierbar, kein Zwangsbestandteil
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test mit einem CMIS-Referenzclient gegen die Schnittstelle
|
||||
2. Berechtigungsprüfung im Test über CMIS-Pfad identisch zur REST-API
|
||||
3. Deaktivierung blockiert CMIS-Zugriff vollständig, REST-API bleibt unberührt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-09` Schnittstellen-Vertragstests
|
||||
- `QA-06` Sicherheits- & Berechtigungsprüfung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-09: cmis-kompatible schnittstelle (optional)`
|
||||
- Branch: `feature/int-09-cmis-kompatible-schnittstelle-optional`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# INT-10 – Scanner-Stapelverarbeitung mit Trennseiten-/Barcode-Erkennung
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 7
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Erkennung von Trennseiten (leere Seite oder Barcode-Seite) in einem Multi-Dokument-Scan-Stapel, der über INT-06 (Hot-Folder) eingeht — trennt automatisch in einzelne Dokumente statt eine große Datei anzulegen.
|
||||
|
||||
**Technische Grundlage:** Leerseiten-Erkennung, Barcode-Decoding (z. B. ZBar/ZXing)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Postfach-Abruf mit Regelwerk und sauberer Anhangbehandlung nach dem Vorbild von Docspell.
|
||||
- Überwachter Ordner als universelle Einlieferung, wie ihn paperless-ngx populär gemacht hat.
|
||||
- Stapelverarbeitung mit Trennseiten für Netzwerkscanner, wie sie ecoDMS praxistauglich löst.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Schnittstelle, die weniger kann als die Oberfläche. Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle.
|
||||
- Kein eigener Arbeitsplatz-Client als Voraussetzung für Kernfunktionen.
|
||||
|
||||
**Für genau diese Kachel:** Der Stapelworkflow von ecoDMS ist praxiserprobt: Trennseiten teilen den Stapel in Einzeldokumente — hier erweitert um Barcode-Trennseiten mit optionaler Metadatenübernahme.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `INT-06` Scanner-Anbindung über Hot-Folder – Überwachtes Verzeichnis für Netzwerkscanner mit Stapeltrennung, automatischer Texterkennung und Ablage. Die dort bereits vorhandene einfache Stapeltrennung wird um Trennseiten- und Barcode-Erkennung erweitert.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Leere Trennseite wird erkannt und trennt den Stapel in einzelne Dokumente
|
||||
2. Barcode-Trennseite wird erkannt, Barcode-Wert kann optional als Metadatenfeld übernommen werden
|
||||
3. Stapel ohne Trennseiten wird als ein einzelnes Dokument behandelt, kein Fehlverhalten
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test-Stapel mit Leerseiten-Trennung ergibt korrekte Anzahl Einzeldokumente
|
||||
2. Test-Stapel mit Barcode-Trennseiten ordnet Barcode-Werte korrekt zu
|
||||
3. Stapel ohne Trennseiten bleibt ein Dokument
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-09` Schnittstellen-Vertragstests
|
||||
- `SRC-05` OCR-Worker
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-10: scanner-stapelverarbeitung mit trennseiten-/barcode-erkennung`
|
||||
- Branch: `feature/int-10-scanner-stapelverarbeitung-trennseiten-barcode-erkennung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# INT-11 – Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Dokument-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung/Änderung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik im DMS zu bauen.
|
||||
|
||||
**Technische Grundlage:** HTTP-Client gegen Archive-Modul-Adapter-Schnittstelle, Aufbewahrungsklassen-Mapping
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Zentrale Aufbewahrungslogik einmal in Archive, nicht doppelt im DMS – vermeidet widersprüchliche Löschregeln.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine eigene Retention-/Legal-Hold-Logik im DMS. Das führt zu Divergenz zwischen den Modulen.
|
||||
|
||||
**Für genau diese Kachel:** Ohne diese Anbindung würde das DMS Dokumente löschen können, die Archive eigentlich sperrt – das wäre eine stille Compliance-Lücke.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
|
||||
Setzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/):
|
||||
- `RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen) – Schnittstelle, über die DMS und Mail ihre Objekttypen (Dokument, Mail, Anhang) und die zugehörige Aufbewahrungsklasse bei Archive registrieren, statt eigene Retention-Logik zu bauen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Dokument-Objekttyp inkl. Aufbewahrungsklasse wird beim Start automatisch bei Archive registriert
|
||||
2. Vor Löschung oder Hard-Overwrite eines Dokuments wird eine Sperr-Abfrage an Archive gestellt
|
||||
3. Ist das Dokument gesperrt (Legal Hold), wird die Löschung abgelehnt und die Ablehnung im Audit-Log vermerkt
|
||||
4. Ist Archive nicht erreichbar, wird die Löschung sicherheitshalber verweigert (fail closed), nicht stillschweigend durchgeführt
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Registrierung gegen eine echte Archive-Testinstanz durchgeführt, Objekttyp erscheint dort
|
||||
2. Test: gesperrtes Dokument kann nicht gelöscht werden, Ablehnung ist im Audit-Log sichtbar
|
||||
3. Test: Archive-Endpunkt absichtlich nicht erreichbar – Löschung wird verweigert, kein Fallback auf ungeprüfte Löschung
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- (keine direkt abhängigen Kacheln bekannt)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-11: archive anbindung objekttyp registrierung retention abfrage`
|
||||
- Branch: `feature/int-11-archive-anbindung-objekttyp-registrierung-retention-abfrage`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# INT-12 – AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Dokument-Objekttyp und dessen KI-relevante Felder (Volltext, Metadaten) bei NEXARCH AI registrieren, damit Klassifizierung, Extraktion und semantische Suche für Dokumente optional nutzbar werden, ohne eigene KI-Logik im DMS zu bauen.
|
||||
|
||||
**Technische Grundlage:** HTTP-Client gegen AI-Modul-Adapter-Schnittstelle, Feld-Mapping
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- KI bleibt optional zuschaltbar über Core LIC-02 – kein Zwang, keine harte Kopplung.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine eigene Klassifizierungs- oder Extraktionslogik im DMS. Das dupliziert AI-Funktionalität.
|
||||
|
||||
**Für genau diese Kachel:** Ohne diese Registrierung bliebe AI GOV-01 ohne Gegenstelle im DMS – die KI-Funktionen (CLS/EXT/SEM) hätten keine Dokumente zum Verarbeiten.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
|
||||
Setzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/ai-kanban/):
|
||||
- `GOV-01` Modul-Adapter-Schnittstelle (DMS/Mail registrieren KI-fähige Objekttypen) – Schnittstelle, über die DMS und Mail KI-fähige Objekttypen (Dokument, E-Mail, Thread) und deren Felder registrieren, statt eigene KI-Logik zu bauen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Dokument-Objekttyp inkl. KI-relevanter Felder wird beim Start automatisch bei AI registriert
|
||||
2. Registrierung ist optional: ist AI-Modul nicht aktiviert (Core LIC-02), startet das DMS unverändert ohne Fehler
|
||||
3. Registrierungsfehler blockieren niemals den regulären DMS-Betrieb (fail open bei Registrierung, nicht bei Löschung)
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Registrierung gegen eine echte AI-Testinstanz durchgeführt, Objekttyp erscheint dort
|
||||
2. Test: AI-Modul deaktiviert – DMS startet und läuft unverändert, keine Fehlermeldung im Normalbetrieb
|
||||
3. Test: AI-Endpunkt nicht erreichbar bei Registrierung – DMS-Start wird dadurch nicht blockiert
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- (keine direkt abhängigen Kacheln bekannt)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-12: ai anbindung objekttyp registrierung kopplung ai gov 01`
|
||||
- Branch: `feature/int-12-ai-anbindung-objekttyp-registrierung-kopplung-ai-gov-01`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# INT-13 – Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Dokument-Objekttyp und Auslöser-Ereignisse (Dokument angelegt, Status geändert, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik im DMS ausgelöst werden können.
|
||||
|
||||
**Technische Grundlage:** HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Schnittstelle ist das Produkt. Genau das Gegenteil des geschlossenen Ansatzes von ecoDMS.
|
||||
|
||||
**Übernehmen:**
|
||||
- Ereignis-Publikation asynchron und best-effort mit sichtbarem Fehlerzustand, analog zum Core-Webhook-Muster (Postgres-Jobqueue statt Redis).
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine eigene Genehmigungs- oder Aufgabenlogik im DMS. Das dupliziert Workflow-Funktionalität.
|
||||
|
||||
**Für genau diese Kachel:** Ohne diese Anbindung bliebe Workflow ENG-02 ohne Gegenstelle im DMS – Freigabeprozesse (z. B. Vier-Augen-Freigabe vor Löschung) könnten nicht am Dokumentenlebenszyklus andocken.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
|
||||
Setzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/workflow-kanban/):
|
||||
- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Dokument-Objekttyp inkl. verfügbarer Auslöser-Ereignisse wird beim Start automatisch bei Workflow registriert
|
||||
2. Ereignis 'Dokument angelegt' wird beim Anlegen eines Dokuments tatsächlich an Workflow publiziert
|
||||
3. Fehlschlagende Zustellung eines Ereignisses blockiert nicht die auslösende DMS-Aktion (asynchron, nicht im Request-Pfad)
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Registrierung gegen eine echte Workflow-Testinstanz durchgeführt, Objekttyp und Ereignisse erscheinen dort
|
||||
2. Test: Dokument angelegt – Ereignis kommt nachweislich bei Workflow an
|
||||
3. Test: Workflow-Endpunkt zum Zustellzeitpunkt nicht erreichbar – Dokumentanlage im DMS bleibt trotzdem erfolgreich, Ereignis wird nachgeliefert oder sichtbar verworfen (nicht stillschweigend verloren)
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- (keine direkt abhängigen Kacheln bekannt)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-13: workflow anbindung objekttyp auslöser registrierung kopplung workflow eng 02`
|
||||
- Branch: `feature/int-13-workflow-anbindung-objekttyp-auslöser-registrierung-kopplung-workflow-eng-02`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,59 @@
|
||||
# INT-14 – Tenant-Zuordnung & Zugriffsschutz für Hot-Folder/Scanner-Verzeichnisse
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
INT-06 (Netzwerkscanner-Ordner) und INT-08 (Hot-Folder) importieren Dateien ohne API-Aufruf und damit ohne Anwendungs-Auth-Kontext. Ohne klare Zuordnung, welches Verzeichnis zu welchem Mandanten gehört, und ohne Zugriffsschutz auf Dateisystemebene kann eine falsch konfigurierte Freigabe Dokumente dem falschen Tenant zuordnen oder Dritten Schreibzugriff erlauben. Je Tenant ein eigenes, klar benanntes Verzeichnis mit dediziertem Dateisystem-Benutzer/Gruppenrechten einführen, Import-Routine prüft beim Einlesen explizit die Tenant-Zuordnung des Quellverzeichnisses gegen die Registry (Core TEN-01), bevor ein Dokument angelegt wird.
|
||||
|
||||
**Technische Grundlage:** Dateisystem-Zugriffsrechte, Verzeichnisstruktur je Tenant, Go
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Docspell: klare Trennung von Eingangsordnern mit expliziter Zuordnung statt impliziter Konvention.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- ecoDMS – geteilte Scan-Ordner ohne harte Mandantentrennung in älteren Setups.: ein Verzeichnis gehört technisch erzwungen genau einem Tenant, keine gemeinsame Ablage mehrerer Mandanten im selben Pfad.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: INT-06, INT-08.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jedes Hot-Folder-/Scanner-Verzeichnis ist genau einem Tenant fest zugeordnet, verankert in der Core-Registry
|
||||
2. Die Import-Routine lehnt einen Import ab und protokolliert dies, wenn die Verzeichnis-Tenant-Zuordnung nicht auflösbar oder inkonsistent ist
|
||||
3. Dateisystemrechte beschränken Schreibzugriff auf das Verzeichnis auf die vorgesehenen Quellen (Scanner/Sync-Tool), dokumentiert in der Betriebsanleitung
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: Import aus einem korrekt zugeordneten Verzeichnis legt Dokument beim richtigen Tenant an
|
||||
2. Test: Import aus einem nicht zugeordneten/fehlkonfigurierten Verzeichnis wird abgelehnt und protokolliert
|
||||
3. Prüft Dateisystemrechte des Verzeichnisses gegen die Betriebsanleitung
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
Threat-Model-Finding (DMS-Board, 2026-09-12): dateisystembasierte Importe ohne Auth-Kontext sind ein Einfallstor für Tenant-Fehlzuordnung, das durch Modell C (physische DB-Trennung) allein nicht abgedeckt wird, weil der Fehler bereits vor dem ersten Datenbankzugriff entsteht.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `INT-06` Scanner-Anbindung über Hot-Folder
|
||||
- `INT-08` Watch-Folder-Import (Consume-Ordner)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-14: tenant-zuordnung-zugriffsschutz-f-r-hot-folder-scanner-verzeichnisse`
|
||||
- Branch: `feature/int-14-tenant-zuordnung-zugriffsschutz-f-r-hot-folder-scanner-verzeichnisse`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,59 @@
|
||||
# INT-15 – CMIS-Schnittstelle: Auth-/Tenant-Scoping-Parität zur REST-API
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
INT-09 stellt eine CMIS-Standardschnittstelle für Drittwerkzeuge bereit, ohne festzulegen, ob diese dieselbe Authentifizierung und Tenant-Scoping-Durchsetzung wie die REST-API verwendet. Eine zweite, schwächer geprüfte API-Fläche würde die gesamte Zugriffskontrolle umgehbar machen. CMIS auf dieselbe Auth-Middleware und Tenant-Kontext-Ermittlung wie die REST-API (INT-01) verpflichten – keine eigene, parallele Auth-Implementierung.
|
||||
|
||||
**Technische Grundlage:** CMIS, gemeinsame Auth-Middleware, Go
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Alfresco: CMIS als zusätzliches Protokoll über derselben Zugriffskontrollschicht, nicht als eigener Sicherheitsperimeter.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keycloak – historisch mehrere Auth-Pfade (Admin-API, Account-Console, Protokoll-Endpunkte) mit inkonsistenter Prüfung.: genau eine Auth-/Tenant-Scoping-Implementierung für alle Protokoll-Fassaden (REST, CMIS).
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: INT-09.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. CMIS-Endpunkte verwenden dieselbe Auth-Middleware wie die REST-API, keine eigene Login-/Token-Prüfung
|
||||
2. Ein über CMIS authentifizierter Aufruf ist auf denselben Tenant beschränkt wie über die REST-API mit denselben Credentials
|
||||
3. Ein automatisierter Test vergleicht Zugriffsergebnisse für dieselbe Anfrage über REST und CMIS und erwartet identisches Autorisierungsverhalten
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: Zugriff auf ein fremdes Tenant-Dokument über CMIS wird identisch zur REST-API abgelehnt
|
||||
2. Test: abgelaufenes/widerrufenes Token wird von CMIS genauso abgelehnt wie von der REST-API (Kopplung an Core IAM-17)
|
||||
3. Code-Review-Gate: CMIS-Handler dürfen keine eigene Auth-Logik enthalten, nur die gemeinsame Middleware referenzieren
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
Threat-Model-Finding (DMS-Board, 2026-09-12): eine zusätzliche Protokoll-Fassade ohne geteilte Auth-Schicht ist ein klassischer Bypass-Vektor für ansonsten korrekt durchgesetzte Zugriffskontrollen.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `INT-09` CMIS-kompatible Schnittstelle (optional)
|
||||
- `INT-01` REST-API v1 & Schnittstellenbeschreibung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-15: cmis-schnittstelle-auth-tenant-scoping-parit-t-zur-rest-api`
|
||||
- Branch: `feature/int-15-cmis-schnittstelle-auth-tenant-scoping-parit-t-zur-rest-api`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,60 @@
|
||||
# INT-16 – Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow)
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
INT-11/12/13 registrieren DMS-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe (z. B. DOC-13 → Workflow VOR-04) dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl DMS selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.
|
||||
|
||||
**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Zitadel: Service-Accounts agieren im Namen eines Kontexts, nie mit implizit eigenen, umfassenderen Rechten.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keycloak – Service-Client-Aufrufe teilen sich in manchen Integrationen denselben weiten Scope wie der Admin-Client.: Service-Credential trägt nur die Rechte, um im Namen eines übergebenen Tenant-Kontexts zu handeln, nie tenant-übergreifend von sich aus.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: INT-11, INT-12, INT-13.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
|
||||
2. Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope
|
||||
3. Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten
|
||||
2. Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt
|
||||
3. Integrationstest über DOC-13 → Workflow VOR-04 mit zwei verschiedenen Tenants, prüft Isolation
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
Threat-Model-Finding (DMS-Board, 2026-09-12): physische Tenant-Trennung (Core Modell C) schützt nur innerhalb eines Moduls — ein Rückkanal über Service-Credentials ohne durchgereichten Nutzer-Tenant-Kontext kann diese Isolation modulübergreifend aufweichen.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `INT-11` Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage
|
||||
- `INT-12` AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)
|
||||
- `INT-13` Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-16: nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`
|
||||
- Branch: `feature/int-16-nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,16 @@
|
||||
# INT-17 – Entscheidung (2026-09-22)
|
||||
|
||||
Nutzerentscheidung zur Frage aus INT-17 ("welcher Kanal zuerst, ob überhaupt, welches Schutzniveau"):
|
||||
|
||||
- **Anonyme Upload-URLs:** abgelehnt. Kein Kanal, der Uploads ohne Konto und ohne Zuordnung zu einer Person erlaubt.
|
||||
- **SMTP-Gateway:** gewünscht, aber Umsetzung derzeit zurückgestellt ("keine jetzt"). Vorgemerkt als Folgekanal.
|
||||
- **Mobile Erfassung (mobilfreundliche Weboberfläche):** gewünscht, aber Umsetzung derzeit zurückgestellt ("keine jetzt"). Vorgemerkt als Folgekanal.
|
||||
|
||||
**Konsequenz für dieses Ticket:** Es wird kein Kanal jetzt implementiert. INT-17 bleibt offen und wird in zwei Nachfolgetickets aufgeteilt, sobald die Umsetzung freigegeben wird:
|
||||
|
||||
- `INT-18` – SMTP-Gateway (Weiterleitung an feste Adresse je Mandant/Postfach, Absenderprüfung, Größenlimit, Malware-Scan-Pflicht wie beim IMAP-Pfad INT-03, Ratenbegrenzung)
|
||||
- `INT-19` – Mobile Erfassung (mobilfreundliche Weboberfläche, angemeldete Nutzer, kein anonymer Zugriff; Kamera-Aufnahme im Browser, kein separates App-Paket)
|
||||
|
||||
Beide Folgetickets brauchen vor der Umsetzung noch: Schutzniveau (Ratenbegrenzung, Größenlimits), genaue Zuordnung zu Mandant/Postfach, und beim SMTP-Gateway die Absenderauthentifizierung (SPF/DKIM-Prüfung oder Zulassungsliste).
|
||||
|
||||
**Nächster Schritt:** Wenn einer der beiden Kanäle freigegeben wird, wird das jeweilige Ticket (`INT-18`/`INT-19`) im Format der bestehenden INT-Tickets ausformuliert und umgesetzt.
|
||||
@@ -0,0 +1,62 @@
|
||||
# INT-17 – Externe Erfassungskanäle: anonyme Upload-URLs, SMTP-Gateway, Mobile Erfassung
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Fullstack | **Komplexität:** Komplex | **Aufwand:** 5 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Fullstack und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Schnittstelle und Oberfläche aus einem Guss: Fachlogik serverseitig, Oberfläche ausschließlich über die öffentliche Schnittstelle.
|
||||
|
||||
## Auftrag
|
||||
Dokumente kommen bisher über angemeldete Nutzer, Watch-Folder (INT-08, INT-06) und IMAP-Abruf (INT-03) ins System. Docspell bietet zusätzlich anonyme Upload-URLs, ein SMTP-Gateway und eine mobilfreundliche Erfassung. Jeder dieser Kanäle öffnet eine Angriffsfläche ohne Konto und braucht ein eigenes Bedrohungsmodell.
|
||||
|
||||
Zuerst entscheiden, welcher Kanal in welcher Reihenfolge gebaut wird, dann den freigegebenen ersten Kanal umsetzen. Die übrigen Kanäle bleiben ausgeschlossen und bekommen je ein eigenes Ticket.
|
||||
|
||||
**Entscheidung erforderlich:** Produkt- und Sicherheitsentscheidung vor der Umsetzung: welcher der drei Kanäle (anonyme Upload-URLs, SMTP-Gateway, Mobile Erfassung als mobilfreundliche Weboberfläche) zuerst kommt, ob überhaupt, und mit welchem Schutzniveau (Passwort, Ablauf, Ratenbegrenzung). Ohne Freigabe bleibt nur das Entscheidungsdokument.
|
||||
|
||||
**Technische Grundlage:** `internal/upload`, `internal/malwarescan`, `internal/importdir`, `internal/apiwiring`, OpenAPI-Tabelle, Migration (nächste freie DMS-Nummer), `docs/INT-17-ENTSCHEIDUNG.md`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Erfassung von außen, aber begrenzt: Größe, Typ, Rate und Mandantenbindung wie bei DOC-01.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Kanal ohne Bedrohungsmodell und ausdrückliche Freigabe.
|
||||
- Keine ungescannte Ablage: jede Datei durchläuft Typprüfung und Malware-Scan, bevor sie sichtbar wird.
|
||||
- Keine Mandantenwahl durch den Absender: der Mandant ergibt sich aus der Bindung des Kanals.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: DOC-01, INT-03, INT-06, INT-08, INT-14, INT-16, DOC-22.
|
||||
Bezug: `VERGLEICHSANALYSE-QUELLSYSTEME.md` (Wurzelverzeichnis), Quelle [D1] (Docspell: anonyme Upload-URLs, SMTP-Gateway, mobilfreundliche Oberfläche).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Ein Entscheidungsdokument liegt vor: je Kanal Nutzen, Bedrohungsmodell (Missbrauch, Massen-Upload, Typumgehung, Replay, Enumeration), Aufwand und Abhängigkeiten, mit ausdrücklicher Freigabe eines ersten Kanals durch die verantwortliche Person
|
||||
2. Der freigegebene Kanal ist umgesetzt: Mandantenbindung, Größen- und Typlimits, Malware-Scan vor Ablage, Ratenbegrenzung, Audit-Eintrag je Eingang, Abschaltung per Umgebungsvariable (Standard aus)
|
||||
3. Nicht freigegebene Kanäle haben keinen aktiven Codepfad und keine Route; das ist per Test belegt
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Missbrauchsfälle gegen den freigegebenen Kanal: Massen-Upload, Typumgehung (MIME und Endung), überlanger Name, Pfadtricks, wiederholte Eingänge, fremder Mandant
|
||||
2. Malware-Pfad: ein Testmuster wird abgewiesen und nie sichtbar; Ausfall des Scanners führt zur Ablehnung
|
||||
3. Abschaltung und Standardzustand: ohne Schalter sind Route und Codepfad nicht vorhanden; Audit-Kette bleibt gültig
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Die beiden nicht freigegebenen Kanäle (je eigenes Ticket)
|
||||
- Native Mobil-Apps und App-Store-Auslieferung
|
||||
- Freigabelinks zum Herunterladen (`DOC-22`)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-17: externe erfassungskanäle`
|
||||
- Branch: `feature/int-17-externe-erfassungskanaele-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,61 @@
|
||||
# INT-18 – SMTP-Gateway (Weiterleitung an feste Adresse je Mandant/Postfach)
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Fullstack | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Fullstack und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Schnittstelle und Oberfläche aus einem Guss: Fachlogik serverseitig, Oberfläche ausschließlich über die öffentliche Schnittstelle.
|
||||
|
||||
## Auftrag
|
||||
Aus `INT-17-ENTSCHEIDUNG.md`: SMTP-Gateway wurde als Kanal freigegeben, zurückgestellt bis zur expliziten Freigabe. Diese liegt jetzt vor. Ein SMTP-Eingang nimmt E-Mails an einer festen, mandanten-/postfachgebundenen Adresse entgegen und übergibt Anhänge/Nachricht an die bestehende Upload-Pipeline — analog zum bestehenden IMAP-Abruf (INT-03), aber als eingehender SMTP-Dienst statt aktivem Abruf.
|
||||
|
||||
**Technische Grundlage:** SMTP-Server-Bibliothek (Go), Absenderauthentifizierung (SPF/DKIM-Prüfung oder Zulassungsliste, siehe Prüfungen), bestehende DOC-01-Upload-API und Malware-Scan-Pipeline (DOC-17), Ratenbegrenzung wie bei INT-17/DOC-01.
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Feste Zuordnung Mandant/Postfach zu einer Empfangsadresse — wie bei INT-03s IMAP-Postfachbindung, kein Mandant durch Absenderwahl.
|
||||
- Größen-/Typ-/Ratenbegrenzung, Malware-Scan-Pflicht wie bei jedem anderen Eingangskanal dieser Session (DOC-01, INT-17, INT-19).
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein offenes Relais: nur eingehende Zustellung an registrierte, mandantengebundene Adressen, kein Weiterversand.
|
||||
- Kein Vertrauen in den Absender ohne Prüfung: SPF/DKIM oder Zulassungsliste, sonst Ablehnung.
|
||||
- Keine ungescannte Ablage: jeder Anhang durchläuft Typprüfung und Malware-Scan wie jeder andere Upload.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: DOC-01, DOC-17, INT-03 (Postfachbindungs-Muster), INT-17-ENTSCHEIDUNG, INT-19 (Kill-Switch-Muster).
|
||||
Bezug: `dms-kanban/tickets/INT-17-ENTSCHEIDUNG.md` (Freigabe-Historie).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. SMTP-Dienst nimmt E-Mails an registrierten, mandanten-/postfachgebundenen Adressen entgegen; unbekannte Zieladresse wird abgelehnt (kein offenes Relais)
|
||||
2. Absenderauthentifizierung (SPF/DKIM-Prüfung oder Zulassungsliste) vor Annahme; ungeprüfter/fehlgeschlagener Absender wird abgelehnt
|
||||
3. Anhänge laufen über die bestehende DOC-01-Pipeline (Größen-/Typlimit, Malware-Scan vor Sichtbarkeit, Audit-Eintrag je Eingang)
|
||||
4. Ratenbegrenzung je Absender/Zieladresse; Abschaltbar per Umgebungsvariable (Standard aus), ohne Schalter kein aktiver Codepfad/Port
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Missbrauchsfälle: unbekannte Zieladresse, fehlgeschlagene SPF/DKIM-Prüfung, überlanger/zu großer Anhang, falscher Dateityp, wiederholte Zustellung, Rate-Limit-Überschreitung
|
||||
2. Malware-Pfad: ein Testmuster wird abgewiesen und nie sichtbar; Ausfall des Scanners führt zur Ablehnung
|
||||
3. Kein offenes Relais: Zustellversuch an eine nicht-registrierte Adresse wird abgelehnt, keine Weiterleitung möglich
|
||||
4. Abschaltung und Standardzustand: ohne Schalter ist der Dienst/Port nicht aktiv
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Ausgehender Mailversand (das ist Mail-Board, nicht dieses Ticket)
|
||||
- Anonyme Upload-URLs (in INT-17-ENTSCHEIDUNG.md abgelehnt)
|
||||
- Mobile Erfassung (siehe INT-19/INT-21)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst INT-03 (Postfachbindungs-Muster) und die bestehende DOC-01-Upload-API/Malware-Pipeline, halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-18: smtp gateway weiterleitung an feste adresse`
|
||||
- Branch: `feature/int-18-smtp-gateway-weiterleitung-an-feste-adresse-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# INT-19 – Mobile Erfassung (mobilfreundliche Weboberfläche)
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Fullstack | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Fullstack und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Schnittstelle und Oberfläche aus einem Guss: Fachlogik serverseitig, Oberfläche ausschließlich über die öffentliche Schnittstelle.
|
||||
|
||||
## Auftrag
|
||||
Aus `INT-17-ENTSCHEIDUNG.md`: Mobile Erfassung wurde als zweiter Kanal freigegeben (nach dem Watch-Folder/IMAP-Bestand), zurückgestellt bis zur expliziten Freigabe. Diese liegt jetzt vor. Nutzer sollen Dokumente/Kassenbelege direkt vom Smartphone aus per Kamera aufnehmen und einreichen können, ohne ein separates App-Paket zu benötigen — eine mobilfreundliche Weboberfläche, angemeldete Nutzer, kein anonymer Zugriff.
|
||||
|
||||
**Technische Grundlage:** Next.js/React/TypeScript, `@nexarch/shl`-Design-System, Browser-Kamera-API (`getUserMedia`/`<input capture>`), bestehende DOC-01-Upload-API (`internal/upload`/`internal/uploadapi`) — kein neuer Backend-Upload-Pfad, dieselbe Pipeline (Duplikaterkennung, Verschlüsselung, Malware-Scan, OCR).
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Erfassung von außen, aber begrenzt: Größe, Typ, Rate und Mandantenbindung wie bei DOC-01/INT-17.
|
||||
- Mobilfreundliche Bedienung wie bei modernen Scan-Apps, aber ohne eigenes App-Paket — die Weboberfläche selbst ist die Kamera-Erfassung.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein anonymer Zugriff: nur angemeldete Nutzer, kein Kanal ohne Konto.
|
||||
- Kein separates App-Paket, keine native Auslieferung über App-Stores (siehe INT-21 für die spätere, eigenständig zu entscheidende native Variante).
|
||||
- Keine ungescannte Ablage: jede Aufnahme durchläuft dieselbe Typprüfung und denselben Malware-Scan wie jeder andere Upload, bevor sie sichtbar wird.
|
||||
- Kein Mandant durch Nutzerwahl: der Mandant ergibt sich aus der angemeldeten Sitzung, nicht aus einer Eingabe im Formular.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: DOC-01, DOC-02, DOC-17, FDN-09, SRC-05, INT-14, INT-16, INT-17-ENTSCHEIDUNG.
|
||||
Bezug: `dms-kanban/tickets/INT-17-ENTSCHEIDUNG.md` (Freigabe-Historie), `dms/internal/upload`/`dms/internal/uploadapi` (bestehende Upload-API, wird 1:1 wiederverwendet, kein neuer Backend-Endpunkt außer einem Abschalt-Schalter falls noch nicht vorhanden).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Mobilfreundliche Weboberfläche mit Kamera-Aufnahme (Live-Vorschau, erneut aufnehmen möglich, mehrere Seiten vor dem Absenden sammelbar), nur für angemeldete Nutzer erreichbar
|
||||
2. Aufnahme läuft über die bestehende DOC-01-Upload-API (kein eigener Upload-Pfad); Mandant und Nutzer ergeben sich aus der Sitzung, nicht aus Formulareingaben
|
||||
3. Größen- und Typlimits wie bei DOC-01 greifen unverändert; Malware-Scan läuft vor jeder Sichtbarkeit; jeder Eingang erzeugt einen Audit-Eintrag
|
||||
4. Abschaltbar per Umgebungsvariable (Standard aus); ohne Freigabe ist weder Route noch Codepfad aktiv
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Missbrauchsfälle: überlange/zu große Aufnahme, falscher Dateityp, wiederholte Einreichung, Versuch ohne Anmeldung
|
||||
2. Malware-Pfad: ein Testmuster wird abgewiesen und nie sichtbar; Ausfall des Scanners führt zur Ablehnung, nicht zur stillen Freigabe
|
||||
3. Abschaltung und Standardzustand: ohne Schalter sind Route und Codepfad nicht vorhanden
|
||||
4. Echter Barrierefreiheits-Check (pa11y, WCAG 2.1 AA) gegen die laufende Oberfläche
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Native Apps und App-Store-Auslieferung (siehe INT-21)
|
||||
- Anonyme Upload-URLs (in INT-17-ENTSCHEIDUNG.md abgelehnt)
|
||||
- SMTP-Gateway (siehe INT-18, Mail-Board)
|
||||
- Eigene Kassenbeleg-spezifische Erkennung/Sonderauswertung (bestehende OCR/Metadaten-Pipeline reicht für diese Kachel)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen (`dms/internal/upload`, `dms/internal/uploadapi`) und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-19: mobile erfassung mobilfreundliche weboberflaeche`
|
||||
- Branch: `feature/int-19-mobile-erfassung-mobilfreundliche-weboberflaeche`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,64 @@
|
||||
# INT-20 – Trigger-/Automatisierungssystem nach Upload
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Schwächen bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
`VERGLEICHSANALYSE-RUNDE-2.md` zeigt: paperless-ngx hat ein Workflow-System, das nach Ereignissen (Erstellung, Aktualisierung) Aktionen auslöst (Webhook, E-Mail, Tag/Typ setzen). NEXARCH hat bisher nur Metadaten-Auto-Regeln (MET-05) ohne Aktionen nach außen. Trigger-Definitionen lösen bei einem Ereignis (Upload abgeschlossen, Texterkennung fertig, E-Rechnung geprüft) eine Aktion aus: Webhook, Tag setzen, Dokumententyp setzen.
|
||||
|
||||
**Technische Grundlage:** `internal/trigger`, `internal/triggerapi`, Hooks in `internal/upload` (Complete), `internal/ocr` (OnText), `internal/einvoice` (OnConformanceChecked), `internal/apiwiring`, OpenAPI-Tabelle, Migration (nächste freie DMS-Nummer)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Trigger-Fehler darf nie die Verarbeitung des Dokuments selbst blockieren.
|
||||
|
||||
**Übernehmen:**
|
||||
- Ereignisbasierte Aktionen wie bei paperless-ngx, aber auf den bereits vorhandenen Verarbeitungsstufen des DMS aufgesetzt statt einer eigenen Engine.
|
||||
- Webhook-Signatur (HMAC) und SSRF-Schutz wie bei den bestehenden ausgehenden Aufrufen des Systems (F-08/F-22-Muster).
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine eigene Templating-Sprache, kein Trigger-Editor mit beliebigem Code.
|
||||
- Kein Trigger-Fehler, der einen abgeschlossenen Upload rückwirkend scheitern lässt.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MET-05` Regelbasierte Auto-Verschlagwortung – Muster für Bedingungen (Dateiname/Regex) und Aktionen (Tag/Typ setzen), das dieses Ticket für Trigger-Bedingungen übernimmt.
|
||||
- `SRC-05` OCR-Worker – liefert das Ereignis „Texterkennung fertig“ (OnText-Hook).
|
||||
- `MET-07` Konformitätsvalidierung E-Rechnung – liefert das Ereignis „E-Rechnung geprüft“ (Konformitätsprüfung abgeschlossen).
|
||||
- `FDN-22` Verschlüsselung der Textkopien – Envelope-Muster (Tenant-KEK), das dieses Ticket für das Webhook-Geheimnis übernimmt.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
1. Trigger feuert bei passendem Ereignis und passender Bedingung, nicht bei unpassenden
|
||||
2. Ein Fehler in einer Aktion (z. B. nicht erreichbarer Webhook) blockiert die Verarbeitung des Dokuments nicht und wird protokolliert
|
||||
3. Trigger-Verwaltung ist nur für berechtigte Nutzer möglich, das Webhook-Geheimnis wird nie im Klartext ausgeliefert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Webhook-SSRF-Negativfälle (Loopback, private Netze, Link-Local) werden abgelehnt
|
||||
2. Fehlgeschlagene Aktion blockiert weder den Upload noch die übrigen Trigger für dasselbe Dokument
|
||||
3. Unberechtigter Zugriff auf die Trigger-Verwaltung wird abgelehnt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Ereignisse „Tag hinzugefügt“ und „Typ geändert“ (eigene Schreibpfade in tagapi/documentapi, nicht Teil dieser Kachel)
|
||||
- E-Mail-Benachrichtigung als Aktion (im DMS existiert kein E-Mail-Versandweg)
|
||||
- Ordner verschieben als Aktion, Templating der Webhook-Nutzlast
|
||||
- Oberfläche zur Trigger-Verwaltung (siehe UX-11-Familie)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-20: trigger-/automatisierungssystem nach upload`
|
||||
- Branch: `feature/int-20-trigger-automatisierung-nach-upload-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,71 @@
|
||||
# INT-21 – Native Android-Erfassungs-App
|
||||
|
||||
**Epic:** 🔌 Integration & API | **Rolle:** Mobile/Fullstack | **Komplexität:** Komplex | **Aufwand:** 6 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Mobile/Fullstack und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert.
|
||||
Fachlogik serverseitig, App ausschließlich über die öffentliche Schnittstelle.
|
||||
|
||||
## Auftrag
|
||||
Ergänzend zu INT-19 (mobilfreundliche Weboberfläche, Erstkanal) eine native Android-App zur Dokumenten-/Kassenbeleg-Erfassung, für Nutzer, die lieber eine installierte App als eine Website nutzen. Ausdrücklich **Ergänzung, nicht Ersatz** von INT-19 — die Web-Lösung bleibt bestehen.
|
||||
|
||||
**Technische Grundlage:** Kotlin, Android SDK auf Build-Host 192.168.1.236 (`/opt/android-sdk`: `build-tools`, `cmake`, `cmdline-tools`/`sdkmanager`, `ndk`, `platforms`, `platform-tools` — bestätigt vorhanden). CameraX für Kamera-Aufnahme. Room (lokale SQLite-Datenbank) für die Offline-Warteschlange. Bestehende DOC-01-Upload-API als einziger Server-Endpunkt (kein neuer Backend-Code nötig, es sei denn ein Token-Ausgabe-Endpunkt fehlt noch, siehe Akzeptanzkriterium 1).
|
||||
|
||||
**Wichtig — nichts auf der Entwicklungsmaschine installieren:** jeglicher Android-Build (Gradle, SDK-Zugriffe, Emulator/Gerätetests) läuft ausschließlich auf Host 236, wo das SDK bereits liegt. Die Entwicklungsmaschine bleibt reine Code-Erstellung.
|
||||
|
||||
## Nutzerentscheidungen (2026-09-26, bindend für diese Kachel)
|
||||
- **Auth:** Login mit Benutzername/Passwort in der App, danach ein langlebiges Zugriffstoken vom bestehenden Auth-System (wie andere Modul-Clients es bereits nutzen) — kein QR-Pairing.
|
||||
- **Vertrieb:** internes APK-Hosting, kein Play Store, kein Google-Review-Prozess.
|
||||
- **Offline-Fähigkeit:** ja — Aufnahmen werden bei fehlender Verbindung lokal zwischengespeichert und automatisch nachgereicht, sobald wieder eine Verbindung besteht.
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Dieselbe Erfassungsbegrenzung wie INT-19/DOC-01: Größe, Typ, Rate, Mandantenbindung aus der angemeldeten Sitzung.
|
||||
- Kamera-Erfassung mit Live-Vorschau und erneuter Aufnahme wie bei modernen Scan-Apps (CamScanner-artig), aber ohne serverseitige Sonderlogik — Kantenerkennung/Zuschnitt rein clientseitig, das Backend sieht nur die fertige Bilddatei wie bei jedem anderen Upload.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein anonymer Zugriff, kein Mandant durch Nutzerwahl — wie bei INT-19.
|
||||
- Keine stille Offline-Warteschlange ohne sichtbaren Status: der Nutzer muss jederzeit sehen, welche Aufnahmen noch nicht übertragen wurden.
|
||||
- Kein separater Backend-Uploadpfad — dieselbe DOC-01-API wie die Weboberfläche.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf INT-19 auf (dieselbe Produkt-DNA, dieselbe Upload-API). Baut zusätzlich auf einem Token-Ausgabe-Mechanismus für native Clients auf — prüfen, ob ein solcher bereits existiert (z.B. über die bestehende Modul-Token-/Session-Infrastruktur, `moduleauth`/Account-API); falls nicht, den kleinstmöglichen fehlenden Endpunkt ergänzen (Benutzername/Passwort gegen ein langlebiges Zugriffstoken tauschen), keine neue Auth-Architektur erfinden.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Login mit Benutzername/Passwort in der App liefert ein langlebiges Zugriffstoken; falscher Login wird abgelehnt, kein Zugriff ohne gültiges Token
|
||||
2. Kamera-Aufnahme mit Live-Vorschau, erneuter Aufnahme, Sammeln mehrerer Seiten vor dem Absenden
|
||||
3. Aufnahmen laufen über die bestehende DOC-01-Upload-API; Mandant/Nutzer ergeben sich aus dem Token, nicht aus einer Eingabe
|
||||
4. Fehlende Verbindung: Aufnahme wird lokal zwischengespeichert (Room), Status "wartet auf Übertragung" sichtbar; sobald wieder Verbindung besteht, automatische Nachreichung ohne Nutzeraktion
|
||||
5. Größen-/Typlimits wie bei INT-19/DOC-01 greifen unverändert; abgelehnte Aufnahmen werden dem Nutzer verständlich erklärt (nicht nur ein Fehlercode)
|
||||
6. APK wird als internes Verteilungsartefakt gebaut (kein Play-Store-Bundle-Format-Zwang), Build läuft vollständig auf Host 236
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Login-Fehlerfälle: falsches Passwort, unbekannter Nutzer, abgelaufenes/widerrufenes Token — jeweils korrekt abgewiesen
|
||||
2. Kamera-Erfassung real getestet (Emulator oder Gerät über Host 236), inkl. erneuter Aufnahme und Mehrseiten-Sammlung
|
||||
3. Offline-Szenario real erzwungen (Verbindung getrennt): Aufnahme wird zwischengespeichert, Status sichtbar, nach Wiederverbindung automatische Nachreichung ohne Datenverlust
|
||||
4. Größen-/Typ-Missbrauchsfälle wie bei INT-19 (überlange/zu große Aufnahme, falscher Typ) korrekt abgewiesen
|
||||
5. Echter APK-Build auf Host 236 erfolgreich, Build-Artefakt vorhanden und installierbar (Smoke-Install auf Emulator)
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- iOS-Variante (eigenes, noch nicht angelegtes Ticket)
|
||||
- Play-Store-Vertrieb (bewusst gegen entschieden)
|
||||
- Serverseitige Sonderlogik für Kassenbelege über die bestehende OCR/Metadaten-Pipeline hinaus
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst INT-19 und die bestehende DOC-01-Upload-API (`dms/internal/upload`/`dms/internal/uploadapi`), sowie die bestehende Auth-Infrastruktur (`moduleauth`, Account-API) für das Token-Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche, kein neuer Backend-Uploadpfad.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test (Unit-Tests für die App-Logik, wo sinnvoll auch instrumentierte Tests).
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Konfiguration/Build-Variablen.
|
||||
7. Jeglicher Android-Build/-Test läuft auf Host 236, nichts auf der Entwicklungsmaschine installieren.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `INT-21: native android erfassungs app`
|
||||
- Branch: `feature/int-21-native-android-erfassungs-app`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,67 @@
|
||||
# MET-01 – Tag-Modell & Tag-API
|
||||
|
||||
**Epic:** 🏷️ Metadaten | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Tags mit Farbe und optionaler Hierarchie, Zuordnung zu Dokumenten sowie Zusammenführen und Umbenennen.
|
||||
|
||||
**Technische Grundlage:** Tag-Entität, Zuordnungstabelle
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Extraktionsqualität von Docspell mit dem verständlichen Ordnungsmodell von paperless-ngx.
|
||||
|
||||
**Übernehmen:**
|
||||
- Konkrete Werte werden vorgeschlagen, nicht nur Kategorien – Datum, Betrag, Vertragspartner wie bei Docspell.
|
||||
- Verständliches Grundmodell aus Korrespondent, Dokumenttyp und Tags, das ohne Schulung begreifbar ist.
|
||||
- Klassifizierungsvorlagen je Dokumentart nach dem Vorbild von ecoDMS.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine automatische Übernahme ohne Bestätigung. Vorschläge werden mit Sicherheitsgrad angezeigt und freigegeben.
|
||||
- Kein starres Feldschema, das nur durch Codeänderung erweiterbar ist.
|
||||
|
||||
**Für genau diese Kachel:** Das Verschlagwortungsmodell von paperless-ngx ist verständlich und wirksam. Ergänze Zusammenführen und Umbenennen, was dort umständlich ist.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-02` Datenmodell & Migrationen – Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Tags sind anlegbar, umbenennbar und zusammenführbar
|
||||
2. Mehrfachzuordnung je Dokument möglich
|
||||
3. Löschen eines Tags entfernt nur die Zuordnung
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Zusammenführen erhält alle Zuordnungen
|
||||
2. Doppelte Tag-Namen werden verhindert
|
||||
3. Massenzuweisung an 500 Dokumente geprüft
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Nil-Slice wird als JSON `null` statt `[]` serialisiert**: Ein Vorgängerprojekt musste diesen Fehler in Listen-Endpunkten wiederholt einzeln im Frontend patchen, statt ihn an der Wurzel zu beheben. → Backend-Konvention: jeder Listen-Handler (z. B. Tag-Listen) liefert grundsätzlich eine leere Liste statt nil, idealerweise per Lint erzwungen.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `MET-03` Metadaten- & Tag-Oberfläche
|
||||
- `MET-05` Regelbasierte Auto-Verschlagwortung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `MET-01: tag-modell & tag-api`
|
||||
- Branch: `feature/met-01-tag-modell-tag-api`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,64 @@
|
||||
# MET-02 – Benutzerdefinierte Metadatenfelder
|
||||
|
||||
**Epic:** 🏷️ Metadaten | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Frei definierbare Felder mit Datentyp, Pflichtkennzeichen, Standardwert und Validierungsregeln.
|
||||
|
||||
**Technische Grundlage:** Feldschema, Validierung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Extraktionsqualität von Docspell mit dem verständlichen Ordnungsmodell von paperless-ngx.
|
||||
|
||||
**Übernehmen:**
|
||||
- Konkrete Werte werden vorgeschlagen, nicht nur Kategorien – Datum, Betrag, Vertragspartner wie bei Docspell.
|
||||
- Verständliches Grundmodell aus Korrespondent, Dokumenttyp und Tags, das ohne Schulung begreifbar ist.
|
||||
- Klassifizierungsvorlagen je Dokumentart nach dem Vorbild von ecoDMS.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine automatische Übernahme ohne Bestätigung. Vorschläge werden mit Sicherheitsgrad angezeigt und freigegeben.
|
||||
- Kein starres Feldschema, das nur durch Codeänderung erweiterbar ist.
|
||||
|
||||
**Für genau diese Kachel:** Alfresco erlaubt eigene Inhaltsmodelle, aber nur mit Modelldateien und Neustart. Erlaube Felddefinition zur Laufzeit über die Oberfläche.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-02` Datenmodell & Migrationen – Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Feldtypen Text, Zahl, Datum, Auswahl und Ja/Nein verfügbar
|
||||
2. Validierung greift beim Speichern
|
||||
3. Felddefinition ist versioniert änderbar
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Ungültiger Wert wird mit klarer Meldung abgewiesen
|
||||
2. Typänderung eines Feldes mit Bestandsdaten getestet
|
||||
3. Pflichtfeld blockiert unvollständiges Speichern
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `SRC-08` Facetten- & Filter-API
|
||||
- `MET-03` Metadaten- & Tag-Oberfläche
|
||||
- `MET-04` Dokumententypen & Vorlagen
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `MET-02: benutzerdefinierte metadatenfelder`
|
||||
- Branch: `feature/met-02-benutzerdefinierte-metadatenfelder`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,64 @@
|
||||
# MET-03 – Metadaten- & Tag-Oberfläche
|
||||
|
||||
**Epic:** 🏷️ Metadaten | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Frontend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
|
||||
|
||||
## Auftrag
|
||||
Bearbeitungsbereich am Dokument mit dynamisch erzeugtem Formular, Tag-Eingabe mit Autovervollständigung und Massenbearbeitung.
|
||||
|
||||
**Technische Grundlage:** Dynamische Formulare
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Extraktionsqualität von Docspell mit dem verständlichen Ordnungsmodell von paperless-ngx.
|
||||
|
||||
**Übernehmen:**
|
||||
- Konkrete Werte werden vorgeschlagen, nicht nur Kategorien – Datum, Betrag, Vertragspartner wie bei Docspell.
|
||||
- Verständliches Grundmodell aus Korrespondent, Dokumenttyp und Tags, das ohne Schulung begreifbar ist.
|
||||
- Klassifizierungsvorlagen je Dokumentart nach dem Vorbild von ecoDMS.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine automatische Übernahme ohne Bestätigung. Vorschläge werden mit Sicherheitsgrad angezeigt und freigegeben.
|
||||
- Kein starres Feldschema, das nur durch Codeänderung erweiterbar ist.
|
||||
|
||||
**Für genau diese Kachel:** Docspell zeigt viele Felder, führt aber nicht. Baue ein Formular, das der Dokumentart folgt und nur Relevantes zeigt.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MET-01` Tag-Modell & Tag-API – Tags mit Farbe und optionaler Hierarchie, Zuordnung zu Dokumenten sowie Zusammenführen und Umbenennen.
|
||||
- `MET-02` Benutzerdefinierte Metadatenfelder – Frei definierbare Felder mit Datentyp, Pflichtkennzeichen, Standardwert und Validierungsregeln.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System (zentral).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Formular passt sich der Felddefinition automatisch an
|
||||
2. Tag-Eingabe schlägt bestehende Tags vor
|
||||
3. Massenbearbeitung für ausgewählte Dokumente möglich
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Ungespeicherte Änderungen lösen Warnung aus
|
||||
2. Formular per Tastatur vollständig ausfüllbar
|
||||
3. Massenbearbeitung an 200 Dokumenten geprüft
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-05` Prüfgate Metadaten & Klassifizierung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `MET-03: metadaten- & tag-oberfläche`
|
||||
- Branch: `feature/met-03-metadaten-tag-oberfläche`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# MET-04 – Dokumententypen & Vorlagen
|
||||
|
||||
**Epic:** 🏷️ Metadaten | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Dokumententypen wie Rechnung oder Vertrag mit fest zugeordneten Pflichtfeldern, Standard-Tags und Aufbewahrungsvorgabe.
|
||||
|
||||
**Technische Grundlage:** Typdefinition, Feldbindung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Extraktionsqualität von Docspell mit dem verständlichen Ordnungsmodell von paperless-ngx.
|
||||
|
||||
**Übernehmen:**
|
||||
- Konkrete Werte werden vorgeschlagen, nicht nur Kategorien – Datum, Betrag, Vertragspartner wie bei Docspell.
|
||||
- Verständliches Grundmodell aus Korrespondent, Dokumenttyp und Tags, das ohne Schulung begreifbar ist.
|
||||
- Klassifizierungsvorlagen je Dokumentart nach dem Vorbild von ecoDMS.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine automatische Übernahme ohne Bestätigung. Vorschläge werden mit Sicherheitsgrad angezeigt und freigegeben.
|
||||
- Kein starres Feldschema, das nur durch Codeänderung erweiterbar ist.
|
||||
|
||||
**Für genau diese Kachel:** Klassifizierungsvorlagen sind die praktischste Idee von ecoDMS: Dokumentart bündelt Pflichtfelder, Verschlagwortung und Aufbewahrung.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MET-02` Benutzerdefinierte Metadatenfelder – Frei definierbare Felder mit Datentyp, Pflichtkennzeichen, Standardwert und Validierungsregeln.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Typ bündelt Felder, Tags und Aufbewahrungsvorgabe
|
||||
2. Typwechsel überführt vorhandene Werte
|
||||
3. Typ ist an Ordner vorbelegbar
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Typwechsel mit Datenverlustprüfung getestet
|
||||
2. Pflichtfelder des Typs werden erzwungen
|
||||
3. Vorbelegung im Ordner greift beim Upload
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-05` Prüfgate Metadaten & Klassifizierung
|
||||
- KI-gestützte Klassifizierung (externes AI-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/ai-kanban/): `CLS-01` Dokumentklassifizierung, `CLS-03` Automatische Verschlagwortung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `MET-04: dokumententypen & vorlagen`
|
||||
- Branch: `feature/met-04-dokumententypen-vorlagen`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,65 @@
|
||||
# MET-05 – Regelbasierte Auto-Verschlagwortung
|
||||
|
||||
**Epic:** 🏷️ Metadaten | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Regeln auf Basis von Textmustern, Absender oder Dateiname vergeben automatisch Tags, Typ und Ablageort.
|
||||
|
||||
**Technische Grundlage:** Regelwerk, Mustererkennung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Die Extraktionsqualität von Docspell mit dem verständlichen Ordnungsmodell von paperless-ngx.
|
||||
|
||||
**Übernehmen:**
|
||||
- Konkrete Werte werden vorgeschlagen, nicht nur Kategorien – Datum, Betrag, Vertragspartner wie bei Docspell.
|
||||
- Verständliches Grundmodell aus Korrespondent, Dokumenttyp und Tags, das ohne Schulung begreifbar ist.
|
||||
- Klassifizierungsvorlagen je Dokumentart nach dem Vorbild von ecoDMS.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine automatische Übernahme ohne Bestätigung. Vorschläge werden mit Sicherheitsgrad angezeigt und freigegeben.
|
||||
- Kein starres Feldschema, das nur durch Codeänderung erweiterbar ist.
|
||||
|
||||
**Für genau diese Kachel:** Das Regelwerk von paperless-ngx erledigt einen Großteil der Arbeit lange vor jedem Sprachmodell. Baue es zuerst.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MET-01` Tag-Modell & Tag-API – Tags mit Farbe und optionaler Hierarchie, Zuordnung zu Dokumenten sowie Zusammenführen und Umbenennen.
|
||||
- `SRC-05` OCR-Worker – Texterkennung für Scans und Bilder inklusive Entzerrung, Rauschunterdrückung und Speicherung des Volltexts je Seite.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Regeln sind ohne Eingriff in den Code pflegbar
|
||||
2. Reihenfolge und Priorität der Regeln sind steuerbar
|
||||
3. Automatische Zuweisung ist als solche erkennbar
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Regelwerk an Testkorpus mit erwarteter Trefferquote geprüft
|
||||
2. Widersprüchliche Regeln führen zu definiertem Ergebnis
|
||||
3. Regeländerung wirkt ohne Neustart
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `WFL-07` Regelbasiertes Dokumenten-Routing
|
||||
- `INT-04` E-Mail-Regeln & Anhangverarbeitung
|
||||
- KI-gestützte Klassifizierung (externes AI-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/ai-kanban/): `CLS-01` Dokumentklassifizierung, `CLS-03` Automatische Verschlagwortung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `MET-05: regelbasierte auto-verschlagwortung`
|
||||
- Branch: `feature/met-05-regelbasierte-auto-verschlagwortung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,60 @@
|
||||
# MET-06 – Metadaten aus E-Rechnungen (Lesen)
|
||||
|
||||
**Epic:** 🏷️ Metadaten | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
E-Rechnungen (XRechnung als reines XML in den Syntaxen UBL und UN/CEFACT CII, ZUGFeRD/Factur-X als eingebettetes XML in einem PDF/A-3) werden beim Eingang erkannt, ihre Kerndaten ausgelesen und als Metadatenfelder am Dokument abgelegt, damit Suche, Filter und Regeln damit arbeiten. Das DMS liest E-Rechnungen ausschließlich; es stellt keine aus.
|
||||
|
||||
Kerndaten: Rechnungsnummer, Rechnungsdatum, Fälligkeit, Aussteller und Empfänger (Name), Betrag netto und brutto, Steuerbetrag, Währung, IBAN, Leitweg-ID. Zusätzlich entsteht ein Prüfergebnis mit Fehlerliste (Struktur, Pflichtfelder, Summenprüfung). Original und Revision bleiben unverändert.
|
||||
|
||||
**Technische Grundlage:** `internal/workerruntime` (Jobtyp), `internal/metadatafield`, `internal/searchsync` (Attribute für Filter), `internal/audittrail`, `pdfcpu` für die Anhangsextraktion, `encoding/xml`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Docspell/paperless-ngx: Strukturierte Belegdaten fließen ohne Handarbeit in Metadaten und Suche.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine stillen Falschwerte: Eine fehlerhafte oder unvollständige E-Rechnung wird mit Fehlerliste gemeldet, ausgelesene Werte werden nie geraten.
|
||||
- Kein XML-Parser mit Entity-Expansion oder externen Entitäten: Eingaben sind unvertrauenswürdig.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertiggestellten Kacheln auf: MET-02, MET-05, FDN-04, FDN-17, SRC-02, SRC-08, VER-09, DOC-01.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. XRechnung (UBL Invoice/CreditNote, CII) und ZUGFeRD/Factur-X werden erkannt; bei PDF wird das eingebettete XML extrahiert
|
||||
2. Die Kerndaten werden ausgelesen und als Metadatenfelder abgelegt und sind über Suche und Filter verfügbar
|
||||
3. Ein Prüfergebnis mit Fehlerliste (Struktur, Pflichtfelder, Summenprüfung) wird je Revision gespeichert; das Original bleibt byteweise unverändert; das Auslesen wird im Audit-Log festgehalten
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Referenzsatz synthetischer E-Rechnungen (UBL, CII, ZUGFeRD-PDF, fehlerhafte Varianten): alle Kerndaten stimmen mit den Erwartungswerten überein
|
||||
2. Angriffseingaben (DTD/Entity-Expansion, externe Entität, übergroße Datei, kaputtes XML) werden abgewiesen und erzeugen ein Prüfergebnis statt eines Absturzes
|
||||
3. Ende-zu-Ende: Upload → Worker → Metadatenfelder → Suche/Filter findet die Rechnung über die Rechnungsnummer
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Erzeugen oder Ausstellen von E-Rechnungen
|
||||
- Vollvalidierung gegen die offiziellen XSD- und Schematron-Regelwerke (benötigt zusätzliches Werkzeug)
|
||||
- Buchhaltungs- oder Zahlungsanbindung, Oberfläche zur Anzeige der Rechnungsdaten
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
7. Ausschließlich synthetische Rechnungen als Testdaten, keine echten Belege.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `MET-06: metadaten aus e-rechnungen`
|
||||
- Branch: `feature/met-06-metadaten-aus-e-rechnungen`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,75 @@
|
||||
# MET-07 – Konformitätsvalidierung E-Rechnung
|
||||
|
||||
**Epic:** 🏷️ Metadaten & Klassifizierung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 9
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist eine belastbare, versionierte Konformitätsaussage, die nie mehr behauptet, als geprüft wurde.
|
||||
|
||||
## Auftrag
|
||||
Eingelesene E-Rechnungen (MET-06) gegen das offizielle Regelwerk (XSD und Schematron, EN 16931 und XRechnung) prüfen und das Ergebnis je Revision ablegen.
|
||||
|
||||
**Technische Grundlage:** optionaler KoSIT-Validator als Sidecar (Daemon, nur lokal erreichbar), Konfiguration per Umgebungsvariable.
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Ergebnis „gültig“ ist nur so viel wert wie die Prüfung dahinter.
|
||||
|
||||
**Übernehmen:**
|
||||
- Ampel-Ergebnis wie bei ecoDMS (gültig, manuell prüfen, defekt), ergänzt um Regelwerk-Version und Prüfzeitpunkt.
|
||||
- Referenzprüfung mit dem KoSIT-Validator, dem Referenzwerkzeug für XRechnung.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein „gültig“ ohne Prüfung: Ausfall oder Abwesenheit des Validators ergibt „nicht geprüft“.
|
||||
- Keine Vermischung von „intern stimmig“ (MET-06), „technisch gültig“ (XSD und Schematron) und steuerlicher Richtigkeit (nicht Gegenstand).
|
||||
- Keine Änderung am Original: Das XML bleibt unverändert und führend (Aufbewahrung, GoBD).
|
||||
|
||||
## Ausgangslage
|
||||
- `MET-06` Metadaten aus E-Rechnungen – Erkennung, Auslesen, interne Plausibilität, Ergebnis je Revision (`revision_einvoice`).
|
||||
- `FDN-04` Job-Queue und Worker-Runtime, `FDN-18` Verdrahtungsmuster mit optionalem externen Dienst (Adresse per Env, leer = aus).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
1. Ergebnis je Revision enthält Status (`conformant`, `warnings`, `non_conformant`, `not_checked`), Regelwerk-Version, Validator-Version, Prüfzeitpunkt und Hash des Berichts
|
||||
2. Fehlender oder ausgefallener Validator ergibt `not_checked`, nie `conformant`; das Einlesen nach MET-06 bleibt davon unberührt
|
||||
3. Regelwerk-Update ermöglicht Neuprüfung bestehender Revisionen, ohne das Original zu verändern
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Referenzsatz aus gültigen und ungültigen synthetischen Rechnungen (UBL, CII, ZUGFeRD-Profile, Rechnung und Gutschrift) liefert je den erwarteten Status
|
||||
2. Validator gestoppt, blockiert und mit Fehler antwortend: jeweils `not_checked`, kein Absturz, Wiederanlauf ohne Neustart
|
||||
3. Validator nur über Loopback oder internes Netz erreichbar, kein Kundendatenabfluss, Betrieb lokal
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Ausstellen von E-Rechnungen
|
||||
- Steuerrechtliche oder GoBD-Bewertung
|
||||
- Oberfläche und API für das Ergebnis (INT-01)
|
||||
- Ersatz des Validators durch eine Go-Implementierung (erst nach Differenztest gegen den KoSIT-Validator)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst MET-06 (`internal/einvoice`) und das Sidecar-Muster aus FDN-18; nutze das Ergebnis-Datenmodell weiter.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Nichts auf Host 131 oder der Entwicklungsmaschine installieren; den Validator als Sidecar-Image im `deploy/`-Paket beschreiben und den Lauf gegen eine dafür bereitgestellte Instanz durchführen, fehlt sie, Prüfungen als offen ausweisen.
|
||||
5. Nur synthetische Rechnungen, keine echten Belege.
|
||||
6. Keine Zugangsdaten oder Adressen im Code, ausschließlich Umgebungsvariablen.
|
||||
|
||||
## Prüfplan (Qualitätssicherung)
|
||||
|
||||
| Bereich | Fälle | Erwartung |
|
||||
|---|---|---|
|
||||
| Formate | UBL Invoice, UBL CreditNote, CII, ZUGFeRD (alle Profile), Factur-X, XRechnung | Status je Format wie im Referenzsatz |
|
||||
| Positiv | Offizielle Beispiele des Regelwerk-Pakets plus eigene synthetische Rechnungen | `conformant` |
|
||||
| Negativ | Fehlende Pflichtfelder, falsche Summen, ungültige Codelisten, falsche Steuerkategorie, kaputtes XML | `non_conformant` mit Regel-ID im Bericht |
|
||||
| Grenzfälle | Nur Warnungen des Regelwerks, Regelwerk mit geänderter Fehlerstufe | `warnings`, Stufe stimmt mit Bericht überein |
|
||||
| Ausfall | Validator aus, Timeout, HTTP 422 (Verarbeitungsfehler), Antwort mit unbekanntem Format | `not_checked`, Grund im Ergebnis |
|
||||
| Versionsdrift | Regelwerk-Bundle austauschen, Neuprüfung anstoßen | Neues Ergebnis mit neuer Version, altes bleibt nachvollziehbar |
|
||||
| Sicherheit | XXE, Entity-Expansion, übergroße Datei, PDF mit manipuliertem Anhang, Daemon von außen erreichbar | Abweisung bzw. nicht erreichbar, Validator-Version ohne bekannte URI-Auflösungslücke (mindestens v1.6.3) |
|
||||
| Revisionssicherheit | Hash des Original-XML vor und nach Validierung und Neuprüfung | Identisch |
|
||||
| Nachvollziehbarkeit | Audit-Ereignis je Validierung, `VerifyChain` | Kette intakt |
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `MET-07: konformitätsvalidierung e-rechnung`
|
||||
- Branch: `feature/met-07-konformitaetsvalidierung-e-rechnung-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# MET-08 – Factur-X- und ZUGFeRD-Szenarien im Validator-Regelwerk
|
||||
|
||||
**Epic:** 🏷️ Metadaten & Klassifizierung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Das Regelwerk-Paket des KoSIT-Validators enthält kein Szenario für die ZUGFeRD-Profile BASIC, BASIC WL, EXTENDED und MINIMUM und für die XRechnung-Kennung 2.3. Diese Rechnungen enden deshalb als `not_checked` (Befund QA-13). Der Ausweichzustand ist korrekt, aber für Betreiber, die ZUGFeRD empfangen, unbefriedigend.
|
||||
|
||||
Die Validator-Konfiguration um die offiziellen Factur-X-/ZUGFeRD-Szenarien erweitern, sodass diese Profile geprüft werden statt `not_checked` zu bleiben.
|
||||
|
||||
**Technische Grundlage:** `deploy/kosit/`, Validator-Konfiguration unter `/opt/nexarch-kosit` (Host), `internal/einvoice`, `scripts/`, `docs/MET-08-PRUEFPROTOKOLL.md`
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Bewusst vermeiden:**
|
||||
- Keine selbstgebauten Regeln: nur offizielle Schemas und Schematron-Artefakte aus Primärquelle, mit Version und Prüfsumme.
|
||||
- Kein stilles Umschalten: ein Regelwerkwechsel löst die Neuprüfung aus (QA-13), das Ergebnis nennt die Version.
|
||||
- Keine Abschwächung von `not_checked`: was kein Szenario hat, bleibt `not_checked`.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: MET-06, MET-07, QA-13.
|
||||
Bezug: `VERGLEICHSANALYSE-QUELLSYSTEME.md` (Wurzelverzeichnis), Abschnitt „Wo NEXARCH schlechter oder unfertig ist“ (ZUGFeRD-Profile ohne Szenario bleiben `not_checked`).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Die Validator-Konfiguration enthält Szenarien für die Factur-X- und ZUGFeRD-Profile (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED) und die XRechnung-Kennung 2.3, mit dokumentierter Quelle, Version und Prüfsumme der Artefakte
|
||||
2. Der Referenzsatz aller Profile liefert je `conformant` oder `non_conformant` mit Regelwerk-Kennung statt `not_checked`; Profile ohne offizielles Artefakt bleiben `not_checked` und sind aufgelistet
|
||||
3. Der Regelwerkwechsel löst die Neuprüfung bestehender Revisionen aus; die Einrichtung ist in `deploy/kosit/README.md` beschrieben und rückbaubar
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Referenzsatz je Profil, positiv und negativ (synthetisch, mutiert), Ergebnis wie erwartet
|
||||
2. Ausfall und Blockade des Validators führen weiterhin zu `not_checked`, nie zu `conformant`
|
||||
3. Neuprüfung nach Konfigurationswechsel ohne Datenverlust, das alte Ergebnis bleibt nachvollziehbar
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Ausstellen von E-Rechnungen
|
||||
- Änderungen am KoSIT-Validator selbst
|
||||
- Neue Metadatenfelder (MET-06)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `MET-08: factur-x- und zugferd-szenarien im validator-regelwerk`
|
||||
- Branch: `feature/met-08-facturx-zugferd-szenarien-validator-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
|
||||
---
|
||||
|
||||
## Status (2026-09-22)
|
||||
|
||||
**Nicht umgesetzt.** Recherche ergab kein offizielles, mit dem KoSIT-Validator kompatibles und prüfsummenfähiges Regelwerk-Paket für die geforderten Profile. Details, Rechercheweg und Freigabefrage: `dms/docs/MET-08-PRUEFPROTOKOLL.md` (Branch `feature/met-08-facturx-zugferd-szenarien-validator-dms`, Commit `60bac77`, gepusht ohne PR, da keine Codeänderung).
|
||||
@@ -0,0 +1,70 @@
|
||||
# QA-01 – Teststrategie & Testdatenbestand
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen, anonymisierten Testdatenbestand mit Referenzdokumenten aufbauen.
|
||||
|
||||
**Technische Grundlage:** Teststrategie, anonymisierte Testdaten
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Ein Referenzkorpus aus echten Belegarten ist die Voraussetzung dafür, Erkennungsgüte überhaupt messen zu können.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-07` CI-Pipeline & Testharness – Automatisierte Pipeline für Lint, Typprüfung, Unit- und E2E-Tests sowie Build-Artefakt. Testdatenbank wird pro Lauf frisch aufgesetzt.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Testpyramide und Abdeckungsziele sind schriftlich festgelegt
|
||||
2. Referenzkorpus mit Scans, PDFs und Office-Dateien liegt vor
|
||||
3. Testdaten enthalten keine echten Personendaten
|
||||
|
||||
4. Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Testdatenbestand ist per Befehl reproduzierbar
|
||||
2. Referenzkorpus deckt alle unterstützten Formate ab
|
||||
3. Strategie im Team abgenommen
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Kaum Tests trotz hoher Kritikalität**: In Vorgängerprojekten waren große Teile von Auth, Tenant-Scoping und Protokoll-State-Machines ungetestet, obwohl gerade dort Fehler am teuersten sind. → Testpflicht-Grundsatz für die Teststrategie: Auth/Tenant-Scoping/Retention/State-Machines erhalten verbindliche Pflichttests vor Merge, nicht optional nachgereicht.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-03` Prüfgate Dokumentenkern
|
||||
- `QA-04` Prüfgate Suche & Texterkennung
|
||||
- `QA-05` Prüfgate Metadaten & Klassifizierung
|
||||
- `QA-07` Prüfgate Workflow & Benachrichtigung
|
||||
- `QA-10` Last- & Leistungstest
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-01: teststrategie & testdatenbestand`
|
||||
- Branch: `feature/qa-01-teststrategie-testdatenbestand`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,68 @@
|
||||
# QA-02 – Prüfgate Fundament
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Abnahme der Grundlage: Datenmodell, Storage, Queue, Auth, Pipeline und Observability greifen zuverlässig ineinander.
|
||||
|
||||
**Technische Grundlage:** Integrationstests, Betriebsprüfung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Fundament abnehmen, bevor Fachlichkeit daraufgesetzt wird. Nachträgliche Korrekturen am Fundament sind die teuersten.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `IAM-02` Login/Session/JWT-Grundgerüst.
|
||||
- `FDN-02` Datenmodell & Migrationen – Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.
|
||||
- `FDN-03` Objekt-Storage-Abstraktion – Storage-Adapter mit einheitlicher Schnittstelle für Ablegen, Lesen, Löschen und signierte URLs. Lokaler Treiber für Entwicklung, S3 für Produktion.
|
||||
- `FDN-04` Job-Queue & Worker-Runtime – Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System (zentral).
|
||||
- `FDN-07` CI-Pipeline & Testharness – Automatisierte Pipeline für Lint, Typprüfung, Unit- und E2E-Tests sowie Build-Artefakt. Testdatenbank wird pro Lauf frisch aufgesetzt.
|
||||
- `FDN-08` Logging, Metriken & Fehler-Tracking – Strukturiertes Logging mit Korrelations-ID, technische Metriken und zentrale Fehlererfassung inklusive Alarmierung.
|
||||
- `FDN-09` Verschlüsselung at rest & Schlüsselverwaltung – Envelope-Encryption-Modul – Datenverschlüsselungsschlüssel (DEK) pro Objekt, verpackt durch einen Hauptschlüssel (KEK), der über Core API-10 (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen wird. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst. Bietet Encrypt/Decrypt-Schnittstelle über Streams, die von der Storage-Abstraktion (FDN-03) beim Ablegen/Lesen genutzt wird.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle Fundament-Tickets erfüllen ihre Prüfungen
|
||||
2. Ein Durchstich vom Login bis zum abgelegten Objekt funktioniert
|
||||
3. Keine offenen kritischen Befunde
|
||||
4. Verschlüsselung at rest (FDN-09) ist wirksam und die Schlüsselverwaltung geprüft
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Neuaufsetzen der Umgebung von null erfolgreich
|
||||
2. Ausfall eines Dienstes führt zu sauberem Fehlerbild
|
||||
3. Prüfbericht abgelegt und freigegeben
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-02: prüfgate fundament`
|
||||
- Branch: `feature/qa-02-prüfgate-fundament`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,69 @@
|
||||
# QA-03 – Prüfgate Dokumentenkern
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Vollständige Prüfung des Lebenszyklus: hochladen, ansehen, ablegen, herunterladen, löschen, wiederherstellen.
|
||||
|
||||
**Technische Grundlage:** E2E-Tests, Datenintegrität
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Der gesamte Lebenszyklus als durchgehender Test. Die Prüfsumme muss von der Erfassung bis zum Export identisch bleiben.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOC-03` Drag-and-Drop-Upload-Oberfläche – Upload-Oberfläche mit Ablagebereich, Mehrfachauswahl, Fortschritt je Datei, Abbrechen und verständlichen Fehlermeldungen.
|
||||
- `DOC-05` PDF-Viewer-Komponente – Inline-Betrachter mit Seitennavigation, Zoom, Suche im Dokument und Textauswahl – ohne Download-Zwang.
|
||||
- `DOC-06` Office-zu-PDF-Konverter – Serverseitige Konvertierung von Text-, Tabellen- und Präsentationsformaten in PDF als Vorschau- und Archivderivat.
|
||||
- `DOC-08` Massenexport als ZIP – Auswahl mehrerer Dokumente als Hintergrund-Job zu einem Archiv bündeln, inklusive optionaler Metadaten-Datei und Download-Benachrichtigung.
|
||||
- `DOC-10` Ordner-Navigation & Dokumentenliste – Navigationsbaum, Brotkrumenpfad und virtualisierte Dokumentenliste mit Sortierung, Spaltenwahl und Mehrfachauswahl.
|
||||
- `DOC-12` Papierkorb-Oberfläche – Ansicht des Papierkorbs mit Restlaufzeit, Einzel- und Massenwiederherstellung sowie bestätigter endgültiger Löschung.
|
||||
- `QA-01` Teststrategie & Testdatenbestand – Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen, anonymisierten Testdatenbestand mit Referenzdokumenten aufbauen.
|
||||
- `DOC-13` Akten-/Vorgangsanzeige im Dokumentkontext – In der Dokument-Detailansicht anzeigen, ob das Dokument zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in DMS.
|
||||
- `DOC-14` Dokument-Zusammenführen & -Aufteilen – Nachträgliches Zusammenführen mehrerer Dokumente zu einem (z.B. fälschlich getrennt gescannt) und Aufteilen eines mehrseitigen Dokuments in mehrere eigenständige Dokumente (z.B. Stapel-Scan ohne Trennseiten-Erkennung, siehe INT-10) – beides als nachträgliche Korrektur nach dem Import, nicht nur zum Importzeitpunkt.
|
||||
- `DOC-15` Massenbearbeitung von Metadaten – Mehrere ausgewählte Dokumente gleichzeitig mit Tags/Metadatenfeldern/Dokumenttyp bearbeiten (hinzufügen, entfernen, ersetzen) statt Dokument für Dokument – Vorbild paperless-ngx Bulk-Edit.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Kompletter Lebenszyklus als automatisierter Test vorhanden
|
||||
2. Keine Datenveränderung zwischen Upload und Download
|
||||
3. Alle Ticket-Prüfungen des Epics bestanden
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Prüfsummenvergleich über den gesamten Lebenszyklus
|
||||
2. Abbruchszenarien in jedem Schritt getestet
|
||||
3. Referenzkorpus vollständig durchlaufen
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-03: prüfgate dokumentenkern`
|
||||
- Branch: `feature/qa-03-prüfgate-dokumentenkern`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,65 @@
|
||||
# QA-04 – Prüfgate Suche & Texterkennung
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 9
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Messen und dokumentieren von Erkennungsgüte, Trefferqualität und Konsistenz zwischen Datenbank und Suchindex.
|
||||
|
||||
**Technische Grundlage:** Relevanz- und Erkennungsmessung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Erkennungsgüte gegen den Referenzkorpus messen und den Wert festhalten – ohne Zahl gibt es keine Verbesserung.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `SRC-04` Such-Oberfläche mit Hervorhebung – Suchfeld mit Vorschlägen, Ergebnisliste mit hervorgehobenen Fundstellen und Sprung in die Dokumentvorschau.
|
||||
- `SRC-06` PDF/A-Erzeugung mit Textebene – Archivfähiges PDF/A mit unsichtbarer Textebene aus der Texterkennung als zusätzliches Derivat erzeugen.
|
||||
- `SRC-07` Spracherkennung & OCR-Qualitätsbewertung – Dokumentsprache automatisch bestimmen, passendes Sprachmodell wählen und Konfidenzwerte für eine Nachbearbeitungsliste erfassen.
|
||||
- `SRC-09` Filter-Panel in der Suche – Seitliches Filterpanel mit aktiven Filtern als entfernbare Chips und Zurücksetzen-Funktion.
|
||||
- `SRC-10` Gespeicherte Suchanfragen – Suchen benennen, speichern, erneut ausführen und optional mit dem Team teilen.
|
||||
- `QA-01` Teststrategie & Testdatenbestand – Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen, anonymisierten Testdatenbestand mit Referenzdokumenten aufbauen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Erkennungsrate am Referenzkorpus erreicht den Zielwert
|
||||
2. Relevanz an definierten Suchanfragen erfüllt die Erwartung
|
||||
3. Index und Datenbank sind nachweislich konsistent
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Messprotokoll mit Zielwerten und Ergebnissen abgelegt
|
||||
2. Voll-Reindexierung ohne Trefferverlust geprüft
|
||||
3. Berechtigungsfilter in der Suche negativ getestet
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-04: prüfgate suche & texterkennung`
|
||||
- Branch: `feature/qa-04-prüfgate-suche-texterkennung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,64 @@
|
||||
# QA-05 – Prüfgate Metadaten & Klassifizierung
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 7
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Prüfen von Feldvalidierung, Typwechseln, Massenbearbeitung und Güte der automatischen Zuordnung.
|
||||
|
||||
**Technische Grundlage:** Datenqualitätstests
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Genauigkeit der automatischen Zuordnung an gekennzeichneten Beispielen belegen, nicht behaupten.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MET-03` Metadaten- & Tag-Oberfläche – Bearbeitungsbereich am Dokument mit dynamisch erzeugtem Formular, Tag-Eingabe mit Autovervollständigung und Massenbearbeitung.
|
||||
- `MET-04` Dokumententypen & Vorlagen – Dokumententypen wie Rechnung oder Vertrag mit fest zugeordneten Pflichtfeldern, Standard-Tags und Aufbewahrungsvorgabe.
|
||||
- `QA-01` Teststrategie & Testdatenbestand – Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen, anonymisierten Testdatenbestand mit Referenzdokumenten aufbauen.
|
||||
- Setzt voraus (externes AI-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/ai-kanban/): `CLS-01` Dokumentklassifizierung, `CLS-03` Automatische Verschlagwortung.
|
||||
- `MET-05` Regelbasierte Auto-Verschlagwortung – Regeln auf Basis von Textmustern, Absender oder Dateiname vergeben automatisch Tags, Typ und Ablageort.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Validierungsregeln greifen in allen Eingabewegen
|
||||
2. Automatische Vorschläge erreichen die Zielgenauigkeit
|
||||
3. Massenbearbeitung erzeugt keine inkonsistenten Daten
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Genauigkeit der Klassifizierung dokumentiert
|
||||
2. Typwechsel mit Bestandsdaten ohne Verlust
|
||||
3. Validierung auch über die Schnittstelle wirksam
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-05: prüfgate metadaten & klassifizierung`
|
||||
- Branch: `feature/qa-05-prüfgate-metadaten-klassifizierung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,70 @@
|
||||
# QA-06 – Sicherheits- & Berechtigungsprüfung
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 10
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Systematische Prüfung aller Zugriffspfade gegen die Rollenmatrix sowie Test auf gängige Sicherheitslücken.
|
||||
|
||||
**Technische Grundlage:** Penetrationstest, Rollenmatrix
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Jede Rolle gegen jeden Endpunkt prüfen. Berechtigungslücken zeigen sich fast immer in Suche, Export oder Schnittstelle.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `IAM-05` LDAP/Active-Directory-Anbindung.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `RBAC-05` Rechte-Administrationsoberfläche.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `IAM-06` SSO-Anmeldung über OIDC.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `IAM-09` API-Token & Service-Accounts, `API-03` Rate-Limiting – API-Token-Verwaltung und Ratenbegrenzung liegen zentral in Core, nicht im DMS.
|
||||
- `QA-04` Prüfgate Suche & Texterkennung – Messen und dokumentieren von Erkennungsgüte, Trefferqualität und Konsistenz zwischen Datenbank und Suchindex.
|
||||
- `SRC-11` Feld-Whitelist-Query-Builder für Suchindex-Zugriff – Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den DMS-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede Rolle wurde gegen jeden Endpunkt geprüft
|
||||
2. Keine unbefugte Rechteausweitung möglich
|
||||
3. Befunde sind behoben oder bewusst akzeptiert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Zugriff auf fremdes Objekt per ID schlägt fehl
|
||||
2. Prüfung auf Einschleusung, Sitzungsübernahme und unsichere Weiterleitung
|
||||
3. Sicherheitsbericht abgelegt und freigegeben
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **In-Memory Rate-Limiter ohne geteilten Zustand**: Ein Vorgängerprojekt hatte bei Mehrinstanz-Betrieb pro Instanz getrennte Rate-Limits, die dadurch aushebelbar waren. → Bei Sicherheitsprüfungen gezielt testen, ob Rate-Limits/Lockouts auch bei mehreren Instanzen wirksam bleiben (externer State statt In-Memory).
|
||||
- **Bewährte Muster aus Vorgängerprojekten prüfen und übernehmen**: Physische Mandantentrennung (eigene Datenbank pro Tenant, eigener Objekt-Storage-Bucket pro Tenant) statt Query-Filter prüfen — sicherstellen, dass kein Codepfad eine falsche Tenant-Datenbank oder ein falsches Bucket referenzieren kann, IDOR-Guards bei Freigaben/Shares, Vier-Augen-Prinzip bei kritischen Löschbestätigungen mit Datenbank-Lock, sowie timing-safe Vergleich bei Passwort-/Link-Prüfungen. → Diese Muster als feste Prüfpunkte in die Sicherheits-/Berechtigungsprüfung aufnehmen.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-06: sicherheits- & berechtigungsprüfung`
|
||||
- Branch: `feature/qa-06-sicherheits-berechtigungsprüfung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# QA-07 – Prüfgate Workflow & Benachrichtigung
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Durchspielen aller Prozesspfade inklusive Ablehnung, Vertretung, Eskalation und Fristablauf.
|
||||
|
||||
**Technische Grundlage:** Prozesstests, Zeitraffer
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Alle Prozesspfade durchspielen, einschließlich Ablehnung, Vertretung und Fristablauf im Zeitraffer.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `QA-01` Teststrategie & Testdatenbestand – Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen, anonymisierten Testdatenbestand mit Referenzdokumenten aufbauen.
|
||||
Setzt voraus (externes Workflow-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/workflow-kanban/): `RTE-02` Routing-Engine-Ausführung, `TSK-03` Erinnerungen & Eskalationsregeln, `APR-01` Freigabe-Postfach & Genehmigungsansicht.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `CFG-04` Benachrichtigungs-Einstellungen-Oberfläche.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle Prozesspfade sind mindestens einmal durchlaufen
|
||||
2. Fristen und Eskalationen lösen korrekt aus
|
||||
3. Keine Benachrichtigung geht verloren oder wird doppelt versandt
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Zeitraffer-Test über simulierte Fristen
|
||||
2. Parallelentscheidungen erzeugen keinen Fehlzustand
|
||||
3. Zustellprotokoll gegen erwartete Ereignisse abgeglichen
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-07: prüfgate workflow & benachrichtigung`
|
||||
- Branch: `feature/qa-07-prüfgate-workflow-benachrichtigung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,64 @@
|
||||
# QA-08 – Revisionssicherheits-Prüfung
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 7
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Nachweis, dass Versionen, Protokoll und Signaturen unveränderlich, vollständig und extern prüfbar sind.
|
||||
|
||||
**Technische Grundlage:** Integritätsprüfung, Signaturvalidierung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Manipulationsversuch am Protokoll muss erkannt werden. Das ist der eigentliche Nachweis der Revisionssicherheit.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `VER-02` Versionsansicht & Wiederherstellung – Liste aller Revisionen mit Autor, Zeitpunkt und Kommentar sowie Wiederherstellung einer früheren Fassung als neue Revision.
|
||||
- `VER-04` Diff-Ansicht – Zwei Revisionen nebeneinander mit farblicher Markierung von Hinzufügungen, Löschungen und Metadatenänderungen.
|
||||
- `VER-06` Audit-Log-Ansicht & Export – Durchsuchbare Protokollansicht mit Filtern nach Zeitraum, Akteur, Objekt und Aktion sowie Export für Prüfer.
|
||||
- `VER-07` Digitale Signatur – Dokumente digital signieren und vorhandene Signaturen prüfen, inklusive qualifiziertem Zeitstempel.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Historie ist lückenlos und nicht manipulierbar
|
||||
2. Signaturen sind mit externen Werkzeugen prüfbar
|
||||
3. Jede relevante Aktion erscheint im Protokoll
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Manipulationsversuch wird erkannt und protokolliert
|
||||
2. Stichprobe von Aktionen im Protokoll wiedergefunden
|
||||
3. Prüfbericht für die Revision erstellt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `QA-12` Abnahme- & Compliance-Prüfung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-08: revisionssicherheits-prüfung`
|
||||
- Branch: `feature/qa-08-revisionssicherheits-prüfung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,69 @@
|
||||
# QA-09 – Schnittstellen-Vertragstests
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 8
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Automatisierte Prüfung, dass die Schnittstelle ihrer Beschreibung entspricht und Importwege zuverlässig arbeiten.
|
||||
|
||||
**Technische Grundlage:** Vertragstests, Testempfänger
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Die Schnittstelle gegen ihre eigene Beschreibung prüfen. Abweichung bricht die Prüfstrecke.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `IAM-09` API-Token & Service-Accounts, `API-03` Rate-Limiting.
|
||||
- `INT-04` E-Mail-Regeln & Anhangverarbeitung – Regeln nach Absender, Betreff oder Anhangtyp steuern Ablageort, Typ und Verschlagwortung importierter Nachrichten.
|
||||
- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-07` Webhook-Registry & Zustellung – Externe Systeme abonnieren Ereignisse und erhalten signierte Aufrufe mit Wiederholung bei Fehlern.
|
||||
- `INT-06` Scanner-Anbindung über Hot-Folder – Überwachtes Verzeichnis für Netzwerkscanner mit Stapeltrennung, automatischer Texterkennung und Ablage.
|
||||
- `INT-08` Watch-Folder-Import (Consume-Ordner) – Dateisystem-Ordner, der automatisch überwacht wird — jede dort abgelegte Datei wird ohne API-Aufruf importiert. Ergänzt DOC-01 (Upload-API), ersetzt sie nicht.
|
||||
- `INT-09` CMIS-kompatible Schnittstelle (optional) – CMIS-Standardschnittstelle als optionale zusätzliche API neben der eigenen REST-API — ermöglicht Drittwerkzeugen direkten Zugriff auf DMS-Inhalte, ohne NEXARCH-spezifische Integration schreiben zu müssen.
|
||||
- `INT-10` Scanner-Stapelverarbeitung mit Trennseiten-/Barcode-Erkennung – Erkennung von Trennseiten (leere Seite oder Barcode-Seite) in einem Multi-Dokument-Scan-Stapel, der über INT-06 (Hot-Folder) eingeht — trennt automatisch in einzelne Dokumente statt eine große Datei anzulegen.
|
||||
- `INT-11` Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage – Dokument-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung/Änderung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik im DMS zu bauen.
|
||||
- `INT-12` AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01) – Dokument-Objekttyp und dessen KI-relevante Felder (Volltext, Metadaten) bei NEXARCH AI registrieren, damit Klassifizierung, Extraktion und semantische Suche für Dokumente optional nutzbar werden, ohne eigene KI-Logik im DMS zu bauen.
|
||||
- `INT-13` Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02) – Dokument-Objekttyp und Auslöser-Ereignisse (Dokument angelegt, Status geändert, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik im DMS ausgelöst werden können.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Vertragstests laufen in der Pipeline
|
||||
2. Import über E-Mail und Hot-Folder verliert keine Dokumente
|
||||
3. Webhook-Zustellung ist nachweisbar
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Abweichung zwischen Beschreibung und Verhalten bricht die Pipeline
|
||||
2. Dauerlauf-Import über 24 Stunden ohne Verlust
|
||||
3. Wiederholungsverhalten bei Ausfall belegt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-09: schnittstellen-vertragstests`
|
||||
- Branch: `feature/qa-09-schnittstellen-vertragstests`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# QA-10 – Last- & Leistungstest
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 7
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Verhalten unter realistischer und überhöhter Last messen: Suche, Upload, Vorschau und Schnittstelle.
|
||||
|
||||
**Technische Grundlage:** Lastgenerator, Messprotokoll
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Verhalten unter Überlast definieren, statt es dem Zufall zu überlassen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `SRC-03` Such-API mit Ranking – Suchschnittstelle mit Paginierung, Sortierung, Treffer-Ausschnitten und Berücksichtigung der Leseberechtigung.
|
||||
- `DOC-04` Vorschau- & Thumbnail-Pipeline – Asynchrone Erzeugung von Seiten-Vorschauen und Thumbnails nach dem Upload, mit Cache und Wiederaufbau bei neuer Revision.
|
||||
- `INT-01` REST-API v1 & Schnittstellenbeschreibung – Öffentliche Schnittstelle für Dokumente, Suche, Metadaten und Workflows mit maschinenlesbarer Beschreibung und Versionierung.
|
||||
- `QA-01` Teststrategie & Testdatenbestand – Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen, anonymisierten Testdatenbestand mit Referenzdokumenten aufbauen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Zielwerte für Antwortzeit und Durchsatz sind definiert und gemessen
|
||||
2. Engpässe sind identifiziert und dokumentiert
|
||||
3. System erholt sich nach Lastspitze selbstständig
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Dauerlast über mehrere Stunden ohne Speicherwachstum
|
||||
2. Verhalten bei Überlast ist definiert statt zufällig
|
||||
3. Messprotokoll mit Zielwertvergleich abgelegt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-10: last- & leistungstest`
|
||||
- Branch: `feature/qa-10-last-leistungstest`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,61 @@
|
||||
# QA-11 – Barrierefreiheits-Audit
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Unabhängige Prüfung aller Ansichten gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf.
|
||||
|
||||
**Technische Grundlage:** Prüfwerkzeuge, Bildschirmleser
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Unabhängige Prüfung mit Werkzeug und manuellem Durchlauf. Automatik allein findet etwa die Hälfte der Verstöße.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `UX-04` Übersetzungen Deutsch und Englisch – Vollständige Übersetzung der Oberfläche in beide Sprachen inklusive abgestimmter Fachbegriffe.
|
||||
- `UX-05` Barrierefreiheit nach WCAG 2.1 AA – Semantik, Fokusführung, Tastaturbedienung, Beschriftungen und Kontraste über alle Ansichten hinweg herstellen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Keine kritischen Verstöße offen
|
||||
2. Manueller Bildschirmleser-Durchlauf dokumentiert
|
||||
3. Restbefunde sind mit Frist eingeplant
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Automatisierte Prüfung über alle Hauptseiten
|
||||
2. Vollständiger Ablauf ohne Maus durchgeführt
|
||||
3. Auditbericht abgelegt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-11: barrierefreiheits-audit`
|
||||
- Branch: `feature/qa-11-barrierefreiheits-audit`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,70 @@
|
||||
# QA-12 – Abnahme- & Compliance-Prüfung
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 11
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Gesamtabnahme vor der Freigabe: Aufbewahrung, Löschworkflow, Berichte und nachgewiesene Wiederherstellbarkeit.
|
||||
|
||||
**Technische Grundlage:** Abnahmeprotokoll, Wiederherstellungstest
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus aus echten Belegarten, an dem Erkennungsgüte und Trefferqualität wiederholbar gemessen werden.
|
||||
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung, wie es revisionssichere Archive verlangen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
|
||||
- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterdokumenten.
|
||||
|
||||
**Für genau diese Kachel:** Gesamtabnahme mit real durchgeführter Wiederherstellung. Erst danach ist das System freigabefähig.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- Setzt voraus (externes Archive-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/): `RET-03` Löschworkflow & Aufbewahrungssperre, `CMP-02` DSGVO-/Datenschutz-Berichte, `BAK-03` Restore-Verfahren.
|
||||
- `QA-08` Revisionssicherheits-Prüfung – Nachweis, dass Versionen, Protokoll und Signaturen unveränderlich, vollständig und extern prüfbar sind.
|
||||
- `QA-02` Prüfgate Fundament – Abnahme der Grundlage: Datenmodell, Storage, Queue, Auth, Pipeline und Observability greifen zuverlässig ineinander.
|
||||
- `QA-03` Prüfgate Dokumentenkern – Vollständige Prüfung des Lebenszyklus: hochladen, ansehen, ablegen, herunterladen, löschen, wiederherstellen.
|
||||
- `QA-04` Prüfgate Suche & Texterkennung – Messen und dokumentieren von Erkennungsgüte, Trefferqualität und Konsistenz zwischen Datenbank und Suchindex.
|
||||
- `QA-05` Prüfgate Metadaten & Klassifizierung – Prüfen von Feldvalidierung, Typwechseln, Massenbearbeitung und Güte der automatischen Zuordnung.
|
||||
- `QA-06` Sicherheits- & Berechtigungsprüfung – Systematische Prüfung aller Zugriffspfade gegen die Rollenmatrix sowie Test auf gängige Sicherheitslücken.
|
||||
- `QA-07` Prüfgate Workflow & Benachrichtigung – Durchspielen aller Prozesspfade inklusive Ablehnung, Vertretung, Eskalation und Fristablauf.
|
||||
- `QA-09` Schnittstellen-Vertragstests – Automatisierte Prüfung, dass die Schnittstelle ihrer Beschreibung entspricht und Importwege zuverlässig arbeiten.
|
||||
- `QA-10` Last- & Leistungstest – Verhalten unter realistischer und überhöhter Last messen: Suche, Upload, Vorschau und Schnittstelle.
|
||||
- `QA-11` Barrierefreiheits-Audit – Unabhängige Prüfung aller Ansichten gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle Prüfgates sind bestanden
|
||||
2. Wiederherstellung wurde real durchgeführt
|
||||
3. Abnahmeprotokoll ist unterzeichnet
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Notfallwiederherstellung auf leerem System nachgewiesen
|
||||
2. Löschung nur mit Freigabe und Protokoll möglich
|
||||
3. Offene Restrisiken sind schriftlich benannt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-12: abnahme- & compliance-prüfung`
|
||||
- Branch: `feature/qa-12-abnahme-compliance-prüfung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,63 @@
|
||||
# QA-13 – Prüfgate E-Rechnung
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 9
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Messen und dokumentieren, dass Lesen (MET-06) und Konformitätsprüfung (MET-07) von E-Rechnungen über alle Formate, Ausfallfälle, Regelwerk-Wechsel und Angriffseingaben korrekt und revisionssicher arbeiten.
|
||||
|
||||
**Technische Grundlage:** KoSIT-Validator-Sidecar, synthetische Rechnungen, Ergebnis je Revision
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Ein Ergebnis „konform“ ist nur so viel wert wie die Prüfung dahinter.
|
||||
|
||||
**Übernehmen:**
|
||||
- Fester Referenzsatz aus offiziellen Beispielen und daraus erzeugten Varianten, wiederholbar gemessen.
|
||||
- Ergebnis mit Regelwerk- und Validator-Version, sodass ein Wechsel nachvollziehbar bleibt.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein „konform“, wenn nicht geprüft wurde oder der Bericht Fehlermeldungen enthält.
|
||||
- Keine Vermischung von „intern stimmig“, „technisch gültig“ und steuerlicher Richtigkeit.
|
||||
|
||||
**Für genau diese Kachel:** Lücken der Matrix aus MET-07 (Gutschriften, ZUGFeRD-Profile, Regelwerk-Drift, Sicherheit gegen den echten Validator) real schließen.
|
||||
|
||||
## Ausgangslage
|
||||
- `MET-06` Metadaten aus E-Rechnungen – Lesen und interne Plausibilitätsprüfung.
|
||||
- `MET-07` Konformitätsvalidierung E-Rechnung – KoSIT-Sidecar, Ergebnis je Revision, Neuprüfung.
|
||||
- `QA-04` Prüfgate Suche und Texterkennung – Suche und Berechtigung.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle Formate (UBL Invoice und CreditNote, CII, ZUGFeRD-Profile, Factur-X, XRechnung) liefern den erwarteten Status; nicht abgedeckte Profile sind `not_checked`, nie `conformant`
|
||||
2. Ein Regelwerk-Wechsel wird ohne Betreiber-Angabe erkannt und löst die Neuprüfung aus
|
||||
3. Original, Audit-Kette und Berechtigung bleiben über Lesen, Validieren und Neuprüfen unverändert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Formatmatrix gegen den echten Validator mit Zielwert je Fall
|
||||
2. Ausfallfälle (Timeout, abgebrochener Bericht, Weiterleitung, 422, 5xx, Fremdformat) und Angriffseingaben (XXE, externe Ressourcen, übergroße Dokumente, manipulierter PDF-Anhang) gegen den echten Validator
|
||||
3. Trennung der Stufen intern stimmig, technisch gültig und konform an Gegenbeispielen
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Steuerrechtliche oder GoBD-Bewertung
|
||||
- Oberfläche und API für das Ergebnis (`INT-01`)
|
||||
- Ausstellen von E-Rechnungen
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst `internal/einvoice` und das MET-07-Protokoll; halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Gefundene Lücken je Fehler bis zu fünf Iterationen beheben, danach stoppen und berichten.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Nur synthetische Rechnungen, keine echten Belege.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-13: prüfgate e-rechnung`
|
||||
- Branch: `feature/qa-13-pruefgate-e-rechnung-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,62 @@
|
||||
# QA-16 – Erkennungsgüte an anonymisierten echten Belegen
|
||||
|
||||
**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 4 Personentage | **Welle:** 14
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich QA und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Zielwert, Messwert und Bewertung.
|
||||
|
||||
## Auftrag
|
||||
Die Erkennungsgüte (SRC-05, SRC-07) ist bisher nur an synthetischen Seiten gemessen (QA-04: 9 Seiten, Zeichengenauigkeit 1,0000, ein Pipeline-Nachweis, keine Praxisgüte). Die Vergleichsanalyse führt das als Reifelücke: echte Scans mit Rauschen, Schräglage, Stempeln und Handschrift verhalten sich anders. Ohne Zahl an echten Belegen gibt es keine belastbare Aussage und keine begründeten Schwellwerte für die Nachbearbeitungsliste.
|
||||
|
||||
Einen kleinen Referenzkorpus aus anonymisierten echten Belegen aufbauen, die Erkennungsgüte je Belegart messen und die Schwellwerte daran begründen. Die Auswertung an echten Belegen läuft ausschließlich auf lokalen Servern (Ollama-/Tesseract-Umgebung des Betreibers), nicht über externe Dienste und nicht in Claude-Sitzungen (Projektregel im `CLAUDE.md`).
|
||||
|
||||
**Entscheidung erforderlich:** Wer liefert die Belege, welche Anonymisierung gilt (Schwärzen, Ersetzen, Rasterung), wer erteilt die DSGVO-Freigabe (Art. 9 beachten), wie viele Belege je Art, und welche Zielwerte gelten je Belegart. Auswertung nur lokal (Ollama-/Tesseract-Umgebung des Betreibers).
|
||||
|
||||
**Technische Grundlage:** `internal/ocr`, `internal/ocr/langdetect`, `internal/testcorpus`, `docs/QA-16-PRUEFPROTOKOLL.md`, lokale Auswertungsumgebung des Betreibers
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
**Übernehmen:**
|
||||
- Fester Referenzkorpus, an dem Erkennungsgüte wiederholbar gemessen wird (Produkt-DNA QA-04).
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine echten Kunden- oder Mandantendaten in Repo, Prompts, Testfixtures, Screenshots oder Protokollen: nur Kennzahlen, nie Inhalte.
|
||||
- Keine Anonymisierung ohne Nachweis: Rückführbarkeit auf Personen muss ausgeschlossen und dokumentiert sein.
|
||||
- Keine Aussage „Erkennungsgüte erreicht“ ohne Zahl und Belegart.
|
||||
|
||||
## Ausgangslage
|
||||
Setzt auf folgenden bereits fertigen Kacheln auf: SRC-05, SRC-07, QA-01, QA-04.
|
||||
Bezug: `VERGLEICHSANALYSE-QUELLSYSTEME.md` (Wurzelverzeichnis), Abschnitt „Wo NEXARCH schlechter oder unfertig ist“ (Reife, Erkennungsgüte an echten Scans nicht gemessen).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Ein Referenzkorpus aus anonymisierten echten Belegen liegt ausschließlich lokal beim Betreiber (nicht im Repo), mit dokumentierter Anonymisierung und schriftlicher Freigabe; das Protokoll enthält nur Kennzahlen
|
||||
2. Zeichen- und Wortgenauigkeit sowie Konfidenzverteilung sind je Belegart (z. B. Rechnung, Vertrag, Kontoauszug, Handschriftnotiz) gegen vorab festgelegte Zielwerte gemessen, Zielwert und Messwert stehen im Protokoll
|
||||
3. Die Schwellwerte der Nachbearbeitungsliste (SRC-07) sind an den Messwerten begründet bestätigt oder angepasst; Unterschreitungen führen zu benannten Folgetickets
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Nachweis der Anonymisierung und der Freigabe liegt vor, bevor ein Beleg in den Korpus kommt
|
||||
2. Die Auswertung lief nachweislich nur auf lokalen Servern, es gab keine Übertragung an externe Dienste und keinen Zugriff aus Claude-Sitzungen
|
||||
3. Wiederholbarkeit: ein zweiter Lauf auf demselben Korpus liefert gleiche Kennzahlen (Toleranz vorab festlegen)
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
- Wechsel der OCR-Engine oder Training eigener Modelle
|
||||
- Verbesserungsmaßnahmen bei Unterschreitung der Zielwerte (eigene Tickets)
|
||||
- Aufnahme echter Belege ins Repository oder in Testfixtures
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `QA-16: erkennungsgüte an anonymisierten echten belegen`
|
||||
- Branch: `feature/qa-16-erkennungsguete-echte-belege-dms`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,66 @@
|
||||
# SRC-01 – Suchindex-Infrastruktur
|
||||
|
||||
**Epic:** 🔍 Suche & OCR | **Rolle:** DevOps | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich DevOps und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Betrieb, Automatisierung und Reproduzierbarkeit. Alles als Konfiguration im Repository, nichts von Hand.
|
||||
|
||||
## Auftrag
|
||||
Suchdienst bereitstellen, Index-Schema mit deutscher Sprachbehandlung definieren und Betriebsparameter festlegen.
|
||||
|
||||
**Technische Grundlage:** Manticore Search (BM25)
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erkennungsgüte auf dem Niveau von paperless-ngx, Trefferqualität ohne Suchsyntax-Studium.
|
||||
|
||||
**Übernehmen:**
|
||||
- Bildvorverarbeitung vor der Texterkennung: Entzerren, Zuschneiden, Rauschunterdrückung – der Kern der guten Erkennungsrate von paperless-ngx.
|
||||
- Bereits durchsuchbare Dokumente werden erkannt und nicht erneut verarbeitet.
|
||||
- Archivfähiges Dokument mit unsichtbarer Textebene als eigenes Derivat, Original bleibt unangetastet.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Suche, die nur mit Abfragesprache brauchbare Treffer liefert. Facetten und Filter statt Syntax.
|
||||
- Kein stiller Auseinanderlauf von Datenbank und Suchindex – Konsistenz ist prüfbar und wiederherstellbar.
|
||||
|
||||
**Für genau diese Kachel:** paperless-ngx kommt mit einem eingebetteten Index weit, stößt aber bei Menge an Grenzen. Wähle von Anfang an einen eigenständigen Suchdienst.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `FDN-01` Repository & Projektgerüst – Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Suchdienst ist reproduzierbar startbar
|
||||
2. Index-Schema mit Feldern und Gewichtung dokumentiert
|
||||
3. Deutsche Stemming- und Stoppwortbehandlung aktiv
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Neuaufbau des Index aus dem Bestand möglich
|
||||
2. Umlaut- und Kompositasuche liefert Treffer
|
||||
3. Neustart des Dienstes ohne Datenverlust
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Dynamische Tabellen-/Spaltennamen via String-Formatierung in SQL**: Zwei Vorgängerprojekte bauten Tabellen-/Spaltennamen per Sprintf/Join direkt in SQL-Strings ein — nur durch nachträgliche Whitelist-Prüfung abgesichert, aber ein fragiles Muster. → Für den Suchindex einen geschlossenen Enum/Switch-Typ oder zentralen Query-Builder mit Feld-Whitelist statt Sprintf-in-SQL verwenden.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `SRC-02` Indexierungs-Worker & Synchronisierung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `SRC-01: suchindex-infrastruktur`
|
||||
- Branch: `feature/src-01-suchindex-infrastruktur`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,69 @@
|
||||
# SRC-02 – Indexierungs-Worker & Synchronisierung
|
||||
|
||||
**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Änderungen an Dokumenten, Metadaten und OCR-Texten laufend in den Suchindex übertragen, inklusive Voll-Reindexierung.
|
||||
|
||||
**Technische Grundlage:** Queue-Worker, Bulk-Indexing
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erkennungsgüte auf dem Niveau von paperless-ngx, Trefferqualität ohne Suchsyntax-Studium.
|
||||
|
||||
**Übernehmen:**
|
||||
- Bildvorverarbeitung vor der Texterkennung: Entzerren, Zuschneiden, Rauschunterdrückung – der Kern der guten Erkennungsrate von paperless-ngx.
|
||||
- Bereits durchsuchbare Dokumente werden erkannt und nicht erneut verarbeitet.
|
||||
- Archivfähiges Dokument mit unsichtbarer Textebene als eigenes Derivat, Original bleibt unangetastet.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Suche, die nur mit Abfragesprache brauchbare Treffer liefert. Facetten und Filter statt Syntax.
|
||||
- Kein stiller Auseinanderlauf von Datenbank und Suchindex – Konsistenz ist prüfbar und wiederherstellbar.
|
||||
|
||||
**Für genau diese Kachel:** Der stille Auseinanderlauf von Datenbank und Index ist ein klassischer Fehler. Mache Konsistenz messbar und den Neuaufbau jederzeit möglich.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `SRC-01` Suchindex-Infrastruktur – Suchdienst bereitstellen, Index-Schema mit deutscher Sprachbehandlung definieren und Betriebsparameter festlegen.
|
||||
- `DOC-01` Upload-API & Chunk-Handling – Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.
|
||||
- `DOC-02` Dublettenerkennung – Prüfung auf bereits vorhandene Dokumente über Hash-Vergleich vor jeder weiteren Verarbeitung.
|
||||
- `FDN-04` Job-Queue & Worker-Runtime – Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Neues Dokument ist zeitnah auffindbar
|
||||
2. Änderung und Löschung werden im Index nachgezogen
|
||||
3. Voll-Reindexierung ohne Ausfall möglich
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Konsistenzabgleich Datenbank gegen Index ergibt keine Abweichung
|
||||
2. Indexierung von 10.000 Dokumenten im Zeitbudget
|
||||
3. Ausfall des Suchdienstes führt zu Nachholung statt Datenverlust
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Reihenfolge beachten**: Indexierung darf erst nach abgeschlossener Duplikatsprüfung (DOC-02) starten. Bei bestätigtem, nicht bewusst gewünschtem Duplikat wird nicht indexiert – sonst entstehen doppelte/inkonsistente Sucheinträge und unnötige Rechenlast.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `SRC-03` Such-API mit Ranking
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `SRC-02: indexierungs-worker & synchronisierung`
|
||||
- Branch: `feature/src-02-indexierungs-worker-synchronisierung`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
@@ -0,0 +1,68 @@
|
||||
# SRC-03 – Such-API mit Ranking
|
||||
|
||||
**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust ein Dokumentenmanagement-System, das die Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereint und deren bekannte Schwächen vermeidet.
|
||||
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
|
||||
|
||||
## Auftrag
|
||||
Suchschnittstelle mit Paginierung, Sortierung, Treffer-Ausschnitten und Berücksichtigung der Leseberechtigung.
|
||||
|
||||
**Technische Grundlage:** Suchabfrage, Relevanz-Tuning
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Erkennungsgüte auf dem Niveau von paperless-ngx, Trefferqualität ohne Suchsyntax-Studium.
|
||||
|
||||
**Übernehmen:**
|
||||
- Bildvorverarbeitung vor der Texterkennung: Entzerren, Zuschneiden, Rauschunterdrückung – der Kern der guten Erkennungsrate von paperless-ngx.
|
||||
- Bereits durchsuchbare Dokumente werden erkannt und nicht erneut verarbeitet.
|
||||
- Archivfähiges Dokument mit unsichtbarer Textebene als eigenes Derivat, Original bleibt unangetastet.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Suche, die nur mit Abfragesprache brauchbare Treffer liefert. Facetten und Filter statt Syntax.
|
||||
- Kein stiller Auseinanderlauf von Datenbank und Suchindex – Konsistenz ist prüfbar und wiederherstellbar.
|
||||
|
||||
**Für genau diese Kachel:** Alfresco filtert Treffer nach Berechtigung – unverzichtbar. paperless-ngx kann das nicht sauber und darf hier kein Vorbild sein.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `SRC-02` Indexierungs-Worker & Synchronisierung – Änderungen an Dokumenten, Metadaten und OCR-Texten laufend in den Suchindex übertragen, inklusive Voll-Reindexierung.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Ergebnisse enthalten Textausschnitte mit Fundstellen
|
||||
2. Nur berechtigte Dokumente erscheinen
|
||||
3. Antwortzeit unter vereinbartem Grenzwert
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Referenz-Suchanfragen liefern erwartete Reihenfolge
|
||||
2. Berechtigungsfilter durch Negativtest belegt
|
||||
3. Lasttest mit gleichzeitigen Suchanfragen bestanden
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
|
||||
- **Dynamische SQL-Klauseln via Sprintf/Join**: Zwei Vorgängerprojekte bauten Sortier-/Filter-Klauseln der Such-API per String-Konkatenation, teils dupliziert an mehreren Stellen. → Zentralen, getesteten Query-Builder mit Feld-Whitelist verwenden; Spalten-/Tabellennamen nur aus statischen Konstanten, nicht per Sprintf.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- `SRC-04` Such-Oberfläche mit Hervorhebung
|
||||
- `SRC-08` Facetten- & Filter-API
|
||||
- `QA-10` Last- & Leistungstest
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
|
||||
## Abschluss
|
||||
- Commit-Nachricht: `SRC-03: such-api mit ranking`
|
||||
- Branch: `feature/src-03-such-api-mit-ranking`
|
||||
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
|
||||
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
|
||||
Loaded 100 of 130 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user