Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
  patrickandClaude Sonnet 5
|
ee6376162d |
No files matched your search
@@ -1,23 +0,0 @@
|
||||
name: AI-Schnittstellen-Vertragstests
|
||||
|
||||
on:
|
||||
push:
|
||||
paths:
|
||||
- "ai/internal/contracttest/**"
|
||||
- "ai/internal/moduletype/**"
|
||||
pull_request:
|
||||
paths:
|
||||
- "ai/internal/contracttest/**"
|
||||
- "ai/internal/moduletype/**"
|
||||
|
||||
jobs:
|
||||
contract-tests:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/setup-go@v5
|
||||
with:
|
||||
go-version: "1.25"
|
||||
- name: Vertragstests ausfuehren
|
||||
working-directory: ai
|
||||
run: go test ./internal/contracttest/... -v
|
||||
@@ -4,7 +4,6 @@ on:
|
||||
pull_request:
|
||||
paths:
|
||||
- "ai/**"
|
||||
- "common/**"
|
||||
|
||||
jobs:
|
||||
pflichttest-gate:
|
||||
|
||||
@@ -4,7 +4,6 @@ on:
|
||||
pull_request:
|
||||
paths:
|
||||
- "archive/**"
|
||||
- "common/**"
|
||||
|
||||
jobs:
|
||||
pflichttest-gate:
|
||||
|
||||
@@ -1,25 +0,0 @@
|
||||
name: Connect-Schnittstellen-Vertragstests
|
||||
|
||||
on:
|
||||
push:
|
||||
paths:
|
||||
- "connect/internal/contracttest/**"
|
||||
- "connect/internal/webhooksub/**"
|
||||
- "connect/internal/webhookclient/**"
|
||||
pull_request:
|
||||
paths:
|
||||
- "connect/internal/contracttest/**"
|
||||
- "connect/internal/webhooksub/**"
|
||||
- "connect/internal/webhookclient/**"
|
||||
|
||||
jobs:
|
||||
contract-tests:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/setup-go@v5
|
||||
with:
|
||||
go-version: "1.22"
|
||||
- name: Vertragstests ausfuehren
|
||||
working-directory: connect
|
||||
run: go test ./internal/contracttest/... -v
|
||||
@@ -1,21 +0,0 @@
|
||||
name: Mail-Schnittstellen-Vertragstests
|
||||
|
||||
on:
|
||||
push:
|
||||
paths:
|
||||
- "mail/internal/mailapi/**"
|
||||
pull_request:
|
||||
paths:
|
||||
- "mail/internal/mailapi/**"
|
||||
|
||||
jobs:
|
||||
contract-tests:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/setup-go@v5
|
||||
with:
|
||||
go-version: "1.22"
|
||||
- name: Vertragstests ausfuehren
|
||||
working-directory: mail
|
||||
run: go test ./internal/mailapi/... -v
|
||||
@@ -4,7 +4,6 @@ on:
|
||||
pull_request:
|
||||
paths:
|
||||
- "mail/**"
|
||||
- "common/**"
|
||||
|
||||
jobs:
|
||||
pflichttest-gate:
|
||||
|
||||
@@ -1,27 +0,0 @@
|
||||
name: Workflow-Schnittstellen-Vertragstests
|
||||
|
||||
on:
|
||||
push:
|
||||
paths:
|
||||
- "workflow/internal/moduleadapter/**"
|
||||
- "workflow/internal/backchannel/**"
|
||||
- "workflow/internal/backchannelapi/**"
|
||||
- "workflow/internal/contracttest/**"
|
||||
pull_request:
|
||||
paths:
|
||||
- "workflow/internal/moduleadapter/**"
|
||||
- "workflow/internal/backchannel/**"
|
||||
- "workflow/internal/backchannelapi/**"
|
||||
- "workflow/internal/contracttest/**"
|
||||
|
||||
jobs:
|
||||
contract-tests:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/setup-go@v5
|
||||
with:
|
||||
go-version: "1.22"
|
||||
- name: Vertragstests ausfuehren
|
||||
working-directory: workflow
|
||||
run: go test ./internal/contracttest/... -v
|
||||
@@ -1,24 +0,0 @@
|
||||
name: Workflow-Pflichttest-Gate
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
paths:
|
||||
- "workflow/**"
|
||||
- "common/**"
|
||||
|
||||
jobs:
|
||||
pflichttest-gate:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- uses: actions/setup-go@v5
|
||||
with:
|
||||
go-version: "1.25"
|
||||
- name: Gate bauen
|
||||
working-directory: workflow
|
||||
run: go build -o /tmp/pflichttestgate ./cmd/pflichttestgate
|
||||
- name: Geänderte Dateien gegen Pflichttest-Regel prüfen
|
||||
run: |
|
||||
git diff --name-only "origin/${{ github.base_ref }}...HEAD" | /tmp/pflichttestgate
|
||||
@@ -5,5 +5,4 @@ web/*/.next/
|
||||
web/*/next-env.d.ts
|
||||
web/*/tsconfig.tsbuildinfo
|
||||
web/pdf-viewer/public/pdf.worker.min.mjs
|
||||
web/mail-search/public/pdf.worker.min.mjs
|
||||
__pycache__/
|
||||
@@ -1,10 +0,0 @@
|
||||
# NEXARCH
|
||||
|
||||
Siehe `PRODUKTARCHITEKTUR.md` für die Gesamtübersicht sowie die weiteren Konzeptdokumente (`SICHERHEITSKONZEPT.md`, `MIGRATIONSKONZEPT.md`, `SKALIERUNGSKONZEPT.md`, `STORAGE-KONZEPT.md`, `SAAS-BETRIEBSMODELL.md`, `UI-UX-KONZEPT.md`) für Details zu einzelnen Bereichen.
|
||||
|
||||
## Datenschutz (DSGVO)
|
||||
|
||||
- **Keine echten Kunden-/Mandantendaten in Prompts, Testfixtures oder Screenshots** — je nach Zielsystem (siehe `dms-kanban/known-issues-archivdms.md`, `dms-kanban/known-issues-archivmail.md`) potenziell personenbezogene oder besondere Kategorien von Daten (Art. 9 DSGVO).
|
||||
- Test-/Demodaten synthetisch halten, nie einen Export aus einem echten Kunden-/Altsystem als Fixture verwenden.
|
||||
- Secrets (API-Keys, DB-Credentials, Verschlüsselungs-Keys) nie in Prompts einfügen.
|
||||
- Claude Code hier ausschließlich für Code-/Konzeptarbeit; für Auswertungen an echten Kundendaten (z. B. Migrationstests gegen Altsysteme) lokale Ollama-Server nutzen, nicht Claude.
|
||||
@@ -1,104 +0,0 @@
|
||||
# NEXARCH 2.0 – Migrationskonzept
|
||||
|
||||
Stand: 2026-08-26. Grundlage: `dms-kanban/known-issues-archivdms.md`, `dms-kanban/known-issues-archivmail.md` (Tabellenaufnahme archivmail/archivdms), `dms-kanban/`, `mail-kanban/`, `core-kanban/`, `archive-kanban/`, `workflow-kanban/` (Boards inzwischen aus dem Repo entfernt, Ticket-Historie liegt in der Gitea-PR-Historie).
|
||||
|
||||
## 1. Ausgangslage
|
||||
|
||||
- Zwei produktive Altsysteme: **archivmail** (21 Tabellen, langer Produktivbetrieb laut Ticket-Historie) und **archivdms** (32 Tabellen, 26 dokumentierte GoBD-Migrationen, funktional reifer).
|
||||
- **Mandanten überschneiden sich teilweise** — manche Kunden nutzen beide Systeme parallel. Migration muss dieselbe Organisation als EIN Tenant in NEXARCH zusammenführen, nicht als zwei getrennte.
|
||||
- Entscheidung: **Big Bang** — alle Mandanten wechseln zu einem Stichtag. Das verkürzt die Übergangszeit, verlangt aber eine vollständig geprobte Migration vor dem echten Stichtag (siehe Abschnitt 5).
|
||||
- Zielsysteme: **Core** (Tenant/User/Rollen/Audit/Token), **DMS** (Dokumente/Ordner/ACL/Metadaten), **Mail** (Postfächer/Nachrichten/Anhänge), **Archive** (Retention/WORM/Löschworkflow/Backup), **Workflow** (Genehmigungen/Aufgaben/Routing).
|
||||
|
||||
## 2. Grundprinzip: Tenant-Zusammenführung vor allem anderen
|
||||
|
||||
Da Mandanten in beiden Altsystemen unabhängig entstanden sind (eigene `tenants`-Tabelle je System, eigene IDs), ist der erste und riskanteste Schritt die **Tenant-Identitätsauflösung**:
|
||||
|
||||
1. Export beider `tenants`-Tabellen (archivmail + archivdms) mit `slug`/`name`.
|
||||
2. Abgleich per **Slug/Domain-Matching** (Firmenname, gepflegte Kunden-Zuordnungsliste als manuelle Fallback-Quelle — automatisches Matching allein ist bei Freitextnamen nicht zuverlässig genug für GoBD-relevante Daten).
|
||||
3. Für jedes Ergebnis ein `tenant_migration_map`-Arbeitsblatt: `archivmail_tenant_id`, `archivdms_tenant_id` (kann leer sein), `nexarch_tenant_id` (neu vergeben).
|
||||
4. **Menschliche Freigabe Pflicht** für jede Zusammenführung — kein automatischer Merge ohne Bestätigung, da eine falsche Zusammenführung zwei Kunden' Daten sichtbar vermischen würde (Compliance-Vorfall).
|
||||
5. Ergebnis der Tenant-Map ist eine feste Referenztabelle, die JEDE weitere Migrationsstufe verwendet, um `tenant_id`-Fremdschlüssel umzuschreiben.
|
||||
|
||||
Gleiches Prinzip, eine Ebene tiefer, für **Benutzer**: ein Mensch kann in archivmail und archivdms mit derselben E-Mail-Adresse, aber unterschiedlicher `user_id` existieren. Abgleich per E-Mail-Adresse innerhalb desselben zusammengeführten Tenants, gleiche Freigabepflicht. `user_migration_map`: `archivmail_user_id`, `archivdms_user_id`, `nexarch_user_id`.
|
||||
|
||||
## 3. Tabellen-Mapping nach Zielsystem
|
||||
|
||||
### → NEXARCH Core
|
||||
| Alt (archivmail) | Alt (archivdms) | Ziel | Hinweis |
|
||||
|---|---|---|---|
|
||||
| `tenants` | `tenants` | Core `TEN-01` Tenant-Datenmodell | via Tenant-Map zusammengeführt |
|
||||
| `users` | `users` | Core `IAM-01` Benutzer-Datenmodell | via User-Map zusammengeführt, `password_hash` (bcrypt) 1:1 übernehmbar, kein Rehash nötig |
|
||||
| `users.role` (Textspalte) | `users.role` + `permission_groups`/`*_grants` | Core `RBAC-01`/`RBAC-03` | archivdms hat das reifere Modell — als Vorlage für die Zielstruktur nehmen, archivmail-Rollen einfach hineinmappen (Textrolle → passende Core-Rolle) |
|
||||
| LDAP-Felder (`source`) | LDAP-Felder (`ldap_uid`, `ldap_synced_at`) | Core `IAM-05` LDAP-Anbindung | archivdms-Feldtiefe als Zielschema, archivmail-Konten nachträglich angereichert (fehlende Felder leer/nachsynchronisiert) |
|
||||
| `audit_log` | `audit_log` | Core `AUD-01`/`AUD-02` | beide Systeme nutzen dasselbe Append-only-Trigger-Muster — Zusammenführen ist mechanisch, KEINE inhaltliche Veränderung der historischen Einträge (Audit-Integrität: alte Einträge bleiben mit altem Zeitstempel, nur `tenant_id`/`user_id` über die Mapping-Tabellen umgeschrieben) |
|
||||
| `token_blacklist` | `token_blacklist` | Core `IAM-02` | wird NICHT migriert — beim Cutover sind alle Alt-Sessions ohnehin ungültig, neue JWTs werden nach dem Login in NEXARCH ausgestellt |
|
||||
| API-Keys mit Rate-Limit | Buchhaltungs-API-Keys | Core `IAM-09` API-Token | neu ausgestellt, nicht migriert (Secrets werden grundsätzlich nicht kopiert, nur die Berechtigung neu vergeben) |
|
||||
|
||||
### → NEXARCH DMS
|
||||
| Alt (archivdms) | Ziel | Hinweis |
|
||||
|---|---|---|
|
||||
| Dokumente + Datei-Revisionen | DMS `DOC-01`/`VER-01`-Bereich | Binärdaten per Objekt-Storage-Kopie (nicht per DB-Migration), Metadaten per SQL-Export/Import |
|
||||
| `akten` (Ordner/Aktenstruktur) | DMS `DOC-09` Ordner- & Kabinettmodell | 1:1 strukturell übernehmbar |
|
||||
| `document_visibility`, `permission_groups`, `*_grants` | DMS-Tickets referenzieren Core `RBAC-02`/`RBAC-04` | ACL-Daten wandern inhaltlich nach Core-Rechtemodell, nicht in DMS selbst |
|
||||
| Custom Fields, Klassifikationsvorlagen | DMS `MET-02`/`MET-04` | 1:1 |
|
||||
| ML-Klassifikator (trainiertes Modell) | DMS `MET-06` | **Modell selbst wird NICHT migriert** — DMS ist Neubau ohne Codeimport, Trainingsdaten (nicht das archivdms-Binärmodell) können als Grundlage für ein neues Training dienen, falls Trainingsdaten-Export vorliegt |
|
||||
| `document_shares` (Freigabelinks) | DMS `DOC-07` | aktive, nicht abgelaufene Links migrieren, abgelaufene verwerfen |
|
||||
| Gespeicherte Ansichten, Erinnerungen | DMS-UX-Bereich bzw. Workflow `TSK-01` | Erinnerungen mit offenem Fälligkeitsdatum → Workflow-Board |
|
||||
|
||||
### → NEXARCH Mail
|
||||
| Alt (archivmail) | Ziel | Hinweis |
|
||||
|---|---|---|
|
||||
| IMAP/POP3/SMTP-Kontenverwaltung | Mail `IMP-07` Mehrfach-Postfach-Verwaltung | Zugangsdaten NICHT kopieren, Postfach-Konfiguration neu anlegen und Verbindung neu testen |
|
||||
| Nachrichten + Anhänge (`email_refs`) | Mail `ARC-01`/`ARC-04` | Binärdaten per Objekt-Storage-Kopie, Referenzen per SQL-Export/Import, `indexed_at`-Statusfeld wird verworfen (Mail-Board indexiert nach der Migration komplett neu, siehe Abschnitt 4) |
|
||||
| DSGVO-Löschanfragen (eigene Tabelle) | Archive `CMP-02` | offene/unbearbeitete Anfragen migrieren, abgeschlossene als historischer Audit-Eintrag |
|
||||
| Reconciliation-Reports | Archive `BAK-05` | historische Reports als Nachweis archivieren, kein aktiver Datenbestand |
|
||||
|
||||
### → NEXARCH Archive
|
||||
| Alt (beide Systeme) | Ziel | Hinweis |
|
||||
|---|---|---|
|
||||
| `retain_until`-Feld auf Kernobjekten | Archive `RET-01` generisches Retention-Objektmodell | wichtigster Einzelschritt für GoBD-Kontinuität — Fristen dürfen beim Umzug NICHT zurückgesetzt werden, sonst Compliance-Bruch |
|
||||
| Vier-Augen-Löschworkflow (`document_delete_requests`, nur archivdms) | Archive `CMP-06` | offene Löschanfragen migrieren, bereits vollzogene Löschungen bleiben nur als Audit-Eintrag bestehen (Objekt existiert nicht mehr) |
|
||||
|
||||
### → NEXARCH Workflow
|
||||
| Alt (archivdms) | Ziel | Hinweis |
|
||||
|---|---|---|
|
||||
| Workflows/Automatisierung, Processing-Queue | Workflow `ENG-01`/`RTE-01` | laufende Workflow-Instanzen NICHT migrieren (Zustandsmaschine ist Board-spezifisch neu) — nur abgeschlossene Vorgänge als Historie, offene Vorgänge werden vor dem Stichtag bewusst zu Ende geführt oder im Altsystem abgebrochen |
|
||||
|
||||
## 4. Was bewusst NICHT migriert wird
|
||||
|
||||
- **Suchindex (Manticore)**: kein DB-Sync-Table in beiden Altsystemen vorhanden → nach der Migration wird der komplette Suchindex aus den migrierten Metadaten NEU aufgebaut (Reindexierung), nicht aus dem alten Manticore-Index kopiert.
|
||||
- **Sessions/Tokens**: siehe oben, neu ausgestellt.
|
||||
- **ML-Klassifikator-Binärmodell**: DMS ist Neubau, kein Codeimport — nur Trainingsdaten (falls vorhanden) als Ausgangspunkt für neues Training.
|
||||
- **Laufende Workflow-Instanzen**: vor dem Stichtag im Altsystem abschließen, nicht in einem "halb migrierten" Zustand übernehmen.
|
||||
|
||||
## 5. Ablauf (Big Bang, mit Geprobter Vorbereitung)
|
||||
|
||||
"Big Bang" heißt: **ein** Stichtag für alle Mandanten — es heißt NICHT, den Migrationscode ungetestet gegen die Produktivdaten laufen zu lassen. Vorgeschlagener Ablauf:
|
||||
|
||||
1. **Trockenlauf 1 (Entwicklung)**: Migrationsskripte gegen anonymisierte Kopie der Produktivdaten, iterativ.
|
||||
2. **Trockenlauf 2 (Generalprobe)**: vollständiger Lauf gegen eine reale, aktuelle Kopie beider Produktivdatenbanken, in einer isolierten NEXARCH-Testumgebung. Ergebnis wird stichprobenartig gegen die Quelle geprüft (Anzahl Dokumente/Mails je Tenant, Stichproben-Volltextvergleich, Retention-Fristen-Abgleich).
|
||||
3. **Tenant- und User-Mapping final freigeben** (Abschnitt 2) — spätestens hier, nicht erst am Stichtag.
|
||||
4. **Stichtag**: Altsysteme in Wartungsmodus (read-only) versetzen, finalen Datenexport ziehen, Migrationsskripte laufen lassen, Verifikation (Abschnitt 6), NEXARCH freischalten.
|
||||
5. **Parallelbetrieb read-only**: Altsysteme bleiben für einen definierten Zeitraum (Vorschlag: 90 Tage) lesend erreichbar, für den Fall dass eine Diskrepanz erst nach dem Stichtag aktiv genutzten Daten auffällt.
|
||||
6. **Abschaltung** der Altsysteme nach Ablauf der Parallelbetriebsfrist und einer zweiten, schriftlich festgehaltenen Freigabe.
|
||||
|
||||
## 6. Verifikation
|
||||
|
||||
Pflicht je Tenant, vor Freischaltung von NEXARCH für diesen Tenant:
|
||||
- Zeilenzahl je migrierter Kerntabelle (Dokumente, Mails, Benutzer) alt vs. neu deckungsgleich (abzüglich bewusst nicht migrierter Kategorien, siehe Abschnitt 4).
|
||||
- Stichprobenweiser Hash-Vergleich migrierter Binärdateien (Objekt-Storage) gegen Quelle.
|
||||
- Retention-Fristen: für eine Stichprobe von Objekten mit `retain_until` in der Zukunft prüfen, dass die Frist nach der Migration identisch ist.
|
||||
- Audit-Log-Kontinuität: ältester und neuester Eintrag je Tenant nach Migration mit Quelle abgleichen (keine Lücke, keine Zeitverschiebung).
|
||||
- Login-Test mit migrierten Zugangsdaten für eine Stichprobe von Benutzern je Tenant.
|
||||
|
||||
## 7. Rollback
|
||||
|
||||
Da Big Bang gewählt wurde, muss der Rollback-Pfad vor dem Stichtag feststehen, nicht danach improvisiert werden:
|
||||
- Altsysteme werden am Stichtag NICHT gelöscht, nur in Wartungsmodus versetzt (siehe Abschnitt 5) — Rollback heißt: Wartungsmodus aufheben, NEXARCH-Freischaltung zurücknehmen.
|
||||
- Rollback-Entscheidung an klare Kriterien binden (z.B. Verifikation in Abschnitt 6 schlägt für mehr als X % der Tenants fehl) statt Einzelfallentscheidung unter Zeitdruck am Stichtag selbst.
|
||||
|
||||
## 8. Offene Punkte
|
||||
|
||||
- Tenant-Matching-Liste (Abschnitt 2) muss von der Geschäftsseite gepflegt werden, nicht rein technisch ableitbar — braucht personelle Zuständigkeit.
|
||||
- Dauer des Parallelbetriebs (90 Tage vorgeschlagen) ist noch nicht mit Vertrags-/Compliance-Anforderungen abgeglichen.
|
||||
- Migrations-Tickets selbst (konkrete Kachel-Boards für die Migrationsskripte je Zielsystem) sind noch nicht angelegt — dieses Dokument beschreibt das Konzept, keine Umsetzungs-Kacheln.
|
||||
@@ -1,113 +0,0 @@
|
||||
# NEXARCH 2.0 – Produktarchitektur
|
||||
|
||||
Stand: 2026-08-26. Zusammenführung aller bisherigen Entscheidungen aus `nexarch-state.json` und den sieben Boards zu einem lesbaren Gesamtbild. Kein neues Konzept — reine Synthese des bereits Entschiedenen.
|
||||
|
||||
## 1. Produktvision
|
||||
|
||||
NEXARCH ist die Nachfolgeplattform von **archivmail** (E-Mail-Archivierung) und **archivdms** (Dokumentenmanagement) — nicht als Umbenennung, sondern als modulare Neuentwicklung unter der Positionierung **"Next Generation Information Management"**: E-Mails, Dokumente, digitale Archivierung, OCR, Volltextsuche, Workflows, Compliance, Integrationen, KI — als ein zusammenhängendes System, nicht als zwei getrennte Werkzeuge nebeneinander.
|
||||
|
||||
## 2. Architekturprinzip
|
||||
|
||||
**Ein modularer Monolith aus sieben eigenständigen, aber koordinierten Diensten** — kein Microservice-Zwang, aber klare Dienstgrenzen mit eigenem Datenmodell, eigenem Go-Binary, eigenem Kanban-Board:
|
||||
|
||||
```
|
||||
┌─────────────┐
|
||||
│ Core │ Identity · Tenancy · Auth · Rollen
|
||||
│ (53 T/142) │ Lizenzierung · Audit · Config
|
||||
└──────┬──────┘ API-Grundgerüst · Monitoring
|
||||
│ (JWKS, Service-Credentials, Rückkanal-APIs)
|
||||
┌───────────┬───────────┼───────────┬───────────┬───────────┐
|
||||
▼ ▼ ▼ ▼ ▼ ▼
|
||||
┌─────┐ ┌─────┐ ┌────────┐ ┌──────────┐ ┌─────┐ ┌─────────┐
|
||||
│ DMS │ │Mail │ │Archive │ │ Workflow │ │ AI │ │ Connect │
|
||||
│64/195│ │59/151│ │27/73 │ │28/76 │ │40/113│ │27/75 │
|
||||
└─────┘ └─────┘ └────────┘ └──────────┘ └─────┘ └─────────┘
|
||||
Dokumente E-Mail Retention/ Genehmigung/ KI-Klassi- ERP/DATEV/
|
||||
Ordner/Akte IMAP/SMTP WORM/Backup Akte/Vermerk/ fizierung/ M365/Fremd-
|
||||
Metadaten Postfach eDiscovery Wiedervorlage Extraktion/ DMS/Backup-
|
||||
Versionen Import Kennzahlen Routing Chat Ziele
|
||||
```
|
||||
|
||||
(T = Tickets, letzte Zahl = Personentage — Stand siehe `nexarch-state.json` → `boards`.)
|
||||
|
||||
Jedes Fachmodul (DMS/Mail/Archive/Workflow/AI/Connect) hat sein **eigenes Datenmodell für seinen Fachgegenstand**, implementiert aber **keine eigene Identität/Rechte/Mandantenlogik** — das ist die zentrale Architekturentscheidung, aus drei Konsolidierungsrunden hervorgegangen (Abschnitt 4).
|
||||
|
||||
## 3. Warum sieben Boards und nicht mehr oder weniger
|
||||
|
||||
Die Aufteilung ist nicht die ursprünglich im Master-Prompt skizzierte (die u.a. Search und OCR als eigene Module vorsah) — sie hat sich beim Durcharbeiten verschoben:
|
||||
|
||||
- **Search/OCR bleiben je Fachmodul** (DMS und Mail haben je eigene `SRC`-Epics) — bewusste Entscheidung, weil E-Mail- und Dokument-Suche als hinreichend unterschiedlich bewertet wurden, um eine gemeinsame Suchschicht nicht zu rechtfertigen.
|
||||
- **Archive, Workflow, AI und Connect** sind dagegen als eigene Boards entstanden, weil beim Bauen von DMS/Mail wiederholt auffiel, dass dieselbe Fachlogik (Retention/WORM, Genehmigungsprozesse, KI-Klassifizierung, API-Infrastruktur) unabhängig in mehreren Boards geplant wurde — siehe Abschnitt 4.
|
||||
|
||||
## 4. Konsolidierungsverlauf — was zentral wurde und warum
|
||||
|
||||
Vier Konsolidierungsrunden, jede aus demselben wiederkehrenden Muster: zwei oder mehr Boards planten dieselbe Fachlogik unabhängig voneinander.
|
||||
|
||||
| Fachlogik | War dupliziert in | Jetzt zentral in | Ergebnis |
|
||||
|---|---|---|---|
|
||||
| Benutzer, Rollen, SSO, LDAP, Mandanten | DMS (FDN-05, IAM-01..07) | **Core** | DMS 87→79 Tickets |
|
||||
| Retention, WORM, Compliance, Backup, Kennzahlen | DMS (REP-01..06), Mail (REP-01..09) | **Archive** | DMS 79→73, Mail 70→61 |
|
||||
| Workflow-Engine, Genehmigungen, Aufgaben, Routing | DMS (WFL-01..07) | **Workflow** | DMS 73→66 |
|
||||
| KI-Klassifizierung/Extraktion/Zusammenfassung | DMS (MET-06) | **AI** | DMS 66→65 |
|
||||
| REST-API-Grundgerüst, Token, Rate-Limiting, Webhooks | DMS (INT-01/02/05), Mail (INT-01/02/03/04) | **Core** | DMS 66→64, Mail 62→59 |
|
||||
| Krypto-Master-Key-Verwaltung | DMS (FDN-09), Mail (ARC-02) — je eigene Schlüsselverwaltung | **Core** (nur Master-Key, Objekt-Verschlüsselung bleibt modul-lokal) | kein Ticketverlust, aber Duplikat im sicherheitskritischsten Bereich beseitigt |
|
||||
|
||||
Die Konsequenz für das Architekturbild: **Core ist nicht "noch ein Modul", sondern das Fundament, auf dem alle anderen sechs aufbauen** — sichtbar auch daran, dass Connect (das jüngste, am weitesten außen liegende Board) am stärksten von einem vollständigen Core abhängt (sieben verschiedene Core-API-Tickets, siehe `ROADMAP.md` Abschnitt 1).
|
||||
|
||||
## 5. Modulübergreifende Referenz-Architektur
|
||||
|
||||
Kein Modul kopiert die Daten eines anderen — stattdessen ein wiederkehrendes **Adapter-Muster**, in drei Varianten je nach Zweck:
|
||||
|
||||
1. **Push-Registrierung** (Archive `RET-05`, Workflow `ENG-02`, AI `GOV-01`): DMS/Mail melden ein Objekt (Dokument-ID, Mail-ID) bei einem Querschnitts-Board an, ohne dessen Rohdaten zu duplizieren — Archive weiß dann "dieses Objekt hat eine Aufbewahrungsfrist", Workflow weiß "dieses Objekt gehört zu einer Akte", ohne den Dokumentinhalt selbst zu besitzen.
|
||||
2. **Pull-Rückkanal** (Workflow `VOR-04`): die Gegenrichtung — DMS/Mail fragen bei Workflow ab, was zu einem Objekt bekannt ist (Vermerke, Wiedervorlage), damit diese Information im Ursprungsmodul sichtbar wird, statt nur in einer separaten Workflow-Oberfläche zu verschwinden. Ohne diesen Rückkanal wäre die Push-Registrierung für Anwender faktisch unsichtbar — dieser Zusammenhang wurde erst nachträglich im Gespräch aufgedeckt, nicht von Anfang an mitgeplant.
|
||||
3. **Externe Konnektoren** (Connect `ENG-01`..`DMS2-03`): dieselbe Idee nach außen gewendet — Fremdsysteme (ERP, DATEV, M365, andere DMS) werden über Connector-Adapter angebunden, nicht durch Direktintegration in jedem Fachmodul einzeln.
|
||||
|
||||
Gemeinsamer Nenner aller drei: **Referenz statt Kopie, Adapter statt Direktkopplung.**
|
||||
|
||||
Go-`internal/`-Pakete sind zwischen den Modulen nicht sichtbar; identische Querschnittspakete werden deshalb im geteilten Modul `common/` gehalten (per `replace` in den `go.mod` eingebunden, keine eigenen Abhängigkeiten außer der Standardbibliothek). Pilot: `common/httpclient`, `common/apierror`. Fachlich verschiedene Pakete (`audittrail`, `cutoverstage`, `crypto`) bleiben modul-lokal.
|
||||
|
||||
Dasselbe Prinzip gilt auch innerhalb eines Moduls, auf Code-Ebene: Hauptdateien/Entry-Points bleiben klein, Fachlogik wandert in eigene Module. Vor einer neuen Funktions-/Modul-Datei wird geprüft, ob dieselbe Funktionalität nicht schon woanders existiert (auch modulübergreifend, z. B. in Core) — keine doppelten Funktionsdateien. Das eigene Kanban-Planungswerkzeug wurde nach genau diesem Muster korrigiert (sieben `kanban.html` enthielten identisches JS/CSS als Volltext-Duplikat, damals in `_shared/kanban.js`/`kanban.css` ausgelagert) — die Boards selbst sind inzwischen komplett aus dem Repo entfernt (Ticket-Historie liegt in der Gitea-PR-Historie), das Prinzip "keine doppelten Funktionsdateien" gilt unverändert für den eigentlichen NEXARCH-Code.
|
||||
|
||||
## 6. Technische Architektur (Kurzfassung, Details in eigenen Dokumenten)
|
||||
|
||||
| Ebene | Entscheidung | Vertiefung |
|
||||
|---|---|---|
|
||||
| Backend | Go (net/http, pgx/v5), ein Binary pro Modul | `PROXMOX-DEPLOYMENT.md` |
|
||||
| Datenbank | PostgreSQL, Modell C (eine physisch getrennte Datenbank je Mandant plus Registry, RLS redundant) | `SKALIERUNGSKONZEPT.md` Abschnitt 4 |
|
||||
| Suche | Manticore (BM25), je Modul eigener Index | `SKALIERUNGSKONZEPT.md` Abschnitt 5 |
|
||||
| Warteschlange | Postgres-Jobqueue, kein Redis | `SKALIERUNGSKONZEPT.md` Abschnitt 7 |
|
||||
| Storage | S3-kompatible Abstraktion, einheitliche Pfadkonvention | `STORAGE-KONZEPT.md` |
|
||||
| Frontend | Next.js/React/TypeScript | — |
|
||||
| Auth | JWT + lokale JWKS-Verifikation (kein synchroner Core-Zwang pro Request) | `SICHERHEITSKONZEPT.md` Abschnitt 1, Core `API-05` |
|
||||
| Deployment | natives systemd, Docker optional für SaaS | `PROXMOX-DEPLOYMENT.md` |
|
||||
| Hochverfügbarkeit | Core-Anwendungsschicht zustandslos, Postgres-Primary/Replica-Failover ab Stufe 2 | `SKALIERUNGSKONZEPT.md` Abschnitt 10 |
|
||||
|
||||
## 7. Betriebsmodelle
|
||||
|
||||
Drei Stufen, ein Techstack (kein Sonderpfad für SaaS vs. On-Premise, außer Docker als SaaS-Zusatzoption):
|
||||
|
||||
- **Stufe 1** — Einzel-Proxmox-LXC, für kleine/mittlere Kunden, On-Premise-Standardfall.
|
||||
- **Stufe 2** — verteilte Installation, mehrere App-Instanzen + Primary/Replica-DB, für größere Kunden oder den SaaS-Betrieb des Anbieters selbst.
|
||||
- **Stufe 3** — dedizierte Instanz pro Großkunde (Private Cloud), strukturell Stufe 1 oder 2, nur organisatorisch als eigene Umgebung abgegrenzt.
|
||||
|
||||
Was noch fehlt: eine konkrete Preis-/Lizenzstruktur (Benutzer/Monat vs. Modul/Monat vs. Enterprise) — die TECHNISCHE Seite der Lizenzierung (Core `LIC`-Epic: Feature-Flags, Modulaktivierung pro Tenant, Nutzungszähler inkl. Speicherverbrauch) ist fertig geplant, die GESCHÄFTLICHE Seite (was kostet was) ist eine offene Entscheidung, siehe `nexarch-state.json` → `fehlende_konzeptdokumente`.
|
||||
|
||||
## 8. Migration von den Altsystemen
|
||||
|
||||
Eigenes Dokument (`MIGRATIONSKONZEPT.md`), hier nur die Kernaussage: Big-Bang-Stichtag mit vorgeschalteter Generalprobe, größtes Einzelrisiko ist die Zusammenführung von Tenants/Benutzern, die in archivmail und archivdms unabhängig, aber teilweise für dieselben Kunden entstanden sind — mit Pflicht-Freigabe durch einen Menschen, kein automatischer Merge.
|
||||
|
||||
## 9. Dokumentenlandkarte
|
||||
|
||||
| Dokument | Inhalt |
|
||||
|---|---|
|
||||
| `nexarch-state.json` | maschinenlesbarer Gesamtzustand, Entscheidungsverlauf, Board-Zahlen |
|
||||
| `PRODUKTARCHITEKTUR.md` | dieses Dokument — lesbare Gesamtübersicht |
|
||||
| `MIGRATIONSKONZEPT.md` | Datenübernahme aus archivmail/archivdms |
|
||||
| `SKALIERUNGSKONZEPT.md` | Wachstumspfad, Betriebsstufen, Core-Hochverfügbarkeit |
|
||||
| `STORAGE-KONZEPT.md` | Objekt-Storage, Pfadkonvention, Lebenszyklus |
|
||||
| `SICHERHEITSKONZEPT.md` | Auth/Autorisierung/Verschlüsselung/Incident-Response |
|
||||
| `PROXMOX-DEPLOYMENT.md` | konkretes LXC-Layout je Betriebsstufe |
|
||||
| `ROADMAP.md` | Board-Reihenfolge, kritische Pfade, Phasenplan |
|
||||
| `MEMORY.md` / `nexarch-state.json` (Claude-Session-Speicher) | Einstiegspunkt für künftige Arbeitssitzungen |
|
||||
|
||||
Noch offen: SaaS-/Multi-Tenant-Betriebsmodell als eigenes ausformuliertes Dokument (Abschnitt 7 hier deckt die technische Seite ab, nicht die vertraglich-organisatorische), UI/UX-Konzept, Lizenzmodell konkret (Preisgestaltung).
|
||||
@@ -1,53 +0,0 @@
|
||||
# NEXARCH
|
||||
|
||||
Modulares Dokumentenmanagement- und Office-System. Siehe `CLAUDE.md` für
|
||||
Arbeitsregeln (Datenschutz, Secrets) und die Konzeptdokumente unten für die
|
||||
fachliche Gesamtübersicht.
|
||||
|
||||
## Dokumentenlandkarte
|
||||
|
||||
**Root-Ebene — Konzeptdokumente (projektweit):**
|
||||
|
||||
| Datei | Inhalt |
|
||||
|---|---|
|
||||
| `PRODUKTARCHITEKTUR.md` | Gesamtübersicht über Module, Schnittstellen, Deployment |
|
||||
| `SICHERHEITSKONZEPT.md` | Sicherheitsarchitektur, Bedrohungsmodell |
|
||||
| `MIGRATIONSKONZEPT.md` | Übernahme aus Altsystemen (archivdms, archivmail) |
|
||||
| `SKALIERUNGSKONZEPT.md` | Mandantenfähigkeit, Skalierungsstrategie |
|
||||
| `STORAGE-KONZEPT.md` | Speicher-/Ablagearchitektur |
|
||||
| `SAAS-BETRIEBSMODELL.md` | Betriebsmodell für den SaaS-Betrieb |
|
||||
| `UI-UX-KONZEPT.md` | Design-System- und UX-Leitlinien |
|
||||
| `CLAUDE.md` | Arbeitsregeln für KI-gestützte Entwicklung in diesem Repo |
|
||||
|
||||
**Module (je eigenes Kanban-Board + Code-Verzeichnis):**
|
||||
|
||||
| Board | Code | Modul |
|
||||
|---|---|---|
|
||||
| `core-kanban/` | `internal/`, `cmd/` | Identität, Mandanten, Rechte, API-Grundgerüst |
|
||||
| `dms-kanban/` | `dms/` | Dokumentenmanagement (siehe `dms/README.md` für Referenzprojekte) |
|
||||
| `mail-kanban/` | `mail/` | Postfach-Modul |
|
||||
| `workflow-kanban/` | `workflow/` | Aufgaben, Freigaben, Routing |
|
||||
| `ai-kanban/` | `ai/` | KI-Funktionen (Zusammenfassung, Extraktion, Suche) |
|
||||
| `connect-kanban/` | `connect/` | Externe Systemanbindungen (ERP, DATEV, CRM) |
|
||||
| `archive-kanban/` | `archive/` | Archivierung, Retention, Kennzahlen |
|
||||
| `migration-kanban/` | `migrations/` | Datenübernahme aus Altsystemen |
|
||||
|
||||
Jedes Board hat `README.md` (Modulübersicht) und `DEVLOG.md` (Session-Log).
|
||||
Ticket-Dateien liegen unter `<board>/tickets/<CODE>.md`, Bearbeitungsstand in
|
||||
`<board>/board.csv`/`board.json`.
|
||||
|
||||
**Prüfprotokolle:**
|
||||
|
||||
- `docs/` — Core-Prüfprotokolle (`<CODE>-PRUEFPROTOKOLL.md`) sowie einige
|
||||
projektweite Betriebsdokumente (Teststrategie, Coding-Guidelines, Incident
|
||||
Response, Rollout-131)
|
||||
- `<modul>/docs/` (z. B. `dms/docs/`, `ai/docs/`) — Prüfprotokolle des
|
||||
jeweiligen Moduls
|
||||
|
||||
**Gemeinsames Frontend-Design-System:** `web/shl/` (`@nexarch/shl`), von
|
||||
allen `web/<modul>/`-Apps importiert.
|
||||
|
||||
## Setup
|
||||
|
||||
Jedes Modul hat ein eigenes `README.md` mit Setup-Anleitung (z. B.
|
||||
`dms/README.md`, `cmd/`/`internal/` für Core).
|
||||
@@ -1,60 +0,0 @@
|
||||
# NEXARCH 2.0 – SaaS-/Multi-Tenant-Betriebsmodell (vertraglich-organisatorisch)
|
||||
|
||||
Stand: 2026-08-26. **Kein Rechtsdokument, keine Rechtsberatung.** Strukturiert die vertraglich-organisatorischen Fragen, die aus den bereits getroffenen TECHNISCHEN Entscheidungen entstehen (`PRODUKTARCHITEKTUR.md` Abschnitt 7, `SKALIERUNGSKONZEPT.md`, `PROXMOX-DEPLOYMENT.md`), und macht sie sichtbar, bevor sie in echte Verträge/AGB übersetzt werden — die eigentliche Formulierung braucht juristische Prüfung, hier geht es nur darum, was die Technik dem Vertrag vorgibt bzw. wo der Vertrag von der Technik abhängt.
|
||||
|
||||
## 1. Drei Betriebsmodelle, drei unterschiedliche Vertragslogiken
|
||||
|
||||
| Modell | Wer betreibt | Wer ist DSGVO-"Verantwortlicher" | Wer ist "Auftragsverarbeiter" |
|
||||
|---|---|---|---|
|
||||
| SaaS (Stufe 1/2 beim Anbieter) | NEXARCH-Anbieter | Kunde | NEXARCH-Anbieter |
|
||||
| On-Premise (Stufe 1 beim Kunden) | Kunde selbst | Kunde | — (kein Auftragsverarbeitungsverhältnis mit NEXARCH-Anbieter, ggf. Softwarelizenzvertrag statt AVV) |
|
||||
| Private Cloud (Stufe 3, dediziert) | je nach Vereinbarung: Anbieter ODER Kunde | Kunde | Anbieter, falls Anbieter betreibt |
|
||||
|
||||
Diese Zuordnung ist keine Neuigkeit, aber wichtig als Ausgangspunkt: **nur beim SaaS- und beim betriebenen Private-Cloud-Modell braucht es einen Auftragsverarbeitungsvertrag (AVV nach Art. 28 DSGVO)** zwischen NEXARCH-Anbieter und Kunde — beim reinen On-Premise-Modell (Kunde installiert selbst gemäß `PROXMOX-DEPLOYMENT.md` Abschnitt 2) fehlt die Auftragsverarbeitungsbeziehung, dafür braucht es einen klaren Software-Lizenzvertrag.
|
||||
|
||||
## 2. Mandantentrennung — was die Technik jetzt zusichern kann
|
||||
|
||||
**Geändert:** Core setzt **Modell C** um — eine eigene, physisch getrennte Datenbank je Mandant (Core `TEN-01`/`TEN-06`/`TEN-07`), keine gemeinsame Datenbank mit applikationsseitiger Filterung mehr. Das verschiebt, was der Vertrag ehrlich versprechen kann:
|
||||
|
||||
- **Ein SaaS-Vertrag darf jetzt "physische Datentrennung" zusichern** — die Isolation hängt nicht mehr davon ab, dass jede einzelne Datenbank-Query korrekt gefiltert ist, sondern davon, dass ein Mandant technisch gar keine Verbindung zur Datenbank eines anderen Mandanten hat. Das ist eine belastbarere Zusage als applikationsseitige Filterung.
|
||||
- Die Formulierung sollte trotzdem präzise bleiben: physisch getrennt sind die **Datenbanken**, nicht zwingend die komplette Infrastruktur (mehrere Tenant-Datenbanken können auf demselben Postgres-Server/derselben Hardware laufen, siehe `SKALIERUNGSKONZEPT.md` Abschnitt 3/4) — das ist immer noch ein starkes, aber kein "dedizierter Server pro Kunde"-Versprechen. Für Letzteres bleibt **Stufe 3** (dedizierte Instanz) die richtige Antwort, jetzt als zusätzliche Infrastruktur-Trennung obendrauf, nicht als einzige Isolationsebene.
|
||||
- Praktischer Zusatznutzen für den Vertrag: eine Tenant-Datenbank lässt sich als Ganzes zwischen On-Premise- und SaaS-Betrieb verschieben (Dump/Restore) — das erleichtert vertraglich zugesicherte Wechsel des Betriebsmodells (z.B. Exit aus SaaS zurück zu On-Premise, siehe Abschnitt 6) technisch, nicht nur organisatorisch.
|
||||
|
||||
## 3. Verfügbarkeits-SLA je Stufe — Vertrag darf der Technik nicht vorauslaufen
|
||||
|
||||
`SKALIERUNGSKONZEPT.md` Abschnitt 10: **Stufe 1 hat kein Live-Failover**, nur Backup/Restore. Eine hohe Verfügbarkeits-SLA (z.B. "99,9 % Uptime") ist auf Stufe-1-Infrastruktur technisch nicht seriös zusicherbar — Ausfallzeit bei einem DB-Problem ist die Zeit bis zum Restore, nicht Sekunden/Minuten.
|
||||
|
||||
Vorschlag: SLA-Stufen an die technischen Betriebsstufen koppeln, nicht pauschal für alle SaaS-Kunden gleich versprechen:
|
||||
- **Stufe 1** (kleine SaaS-Tarife): Best-Effort, kein hartes Uptime-Versprechen, klar kommunizierte Restore-Zeit (RTO) statt Failover-Zeit.
|
||||
- **Stufe 2** (Primary/Replica-Failover vorhanden): belastbare Uptime-SLA möglich, da automatisches Failover technisch existiert.
|
||||
- **Stufe 3**: vertraglich individuell, da Infrastruktur ohnehin verhandelt wird (siehe `LIZENZMODELL.md`).
|
||||
|
||||
## 4. Backup, RPO/RTO — technisch vorhanden, vertraglich noch nicht beziffert
|
||||
|
||||
Archive `BAK-01/02/03` liefert die Mechanik (Backup-Strategie, Snapshots, Restore-Verfahren) — was fehlt, ist eine vertraglich zugesicherte Zahl: **Recovery Point Objective (wie viel Datenverlust maximal) und Recovery Time Objective (wie lange Restore maximal dauert)** sind bisher nirgends als konkreter Wert festgelegt, weder technisch noch vertraglich. Das ist eine Lücke, die vor dem ersten SaaS-Vertrag geschlossen werden sollte — vermutlich durch einen Test des tatsächlichen Backup/Restore-Zyklus (Archive `BAK-06` Restore-Testverfahren liefert die Datengrundlage dafür).
|
||||
|
||||
## 5. Incident-Meldung — Core OPS-04 als vertragliche Grundlage
|
||||
|
||||
Core `OPS-04` (Incident-Response-Plan, DSGVO-72-Stunden-Meldefrist, siehe `SICHERHEITSKONZEPT.md`) ist die technisch-organisatorische Seite. Der AVV muss diese Meldefrist gegenüber dem Kunden UND die Kette zur Aufsichtsbehörde vertraglich abbilden — technisch ist der Prozess vorbereitet, die vertragliche Formulierung (wer meldet wem in welcher Frist) ist eigenständig zu formulieren, nicht aus `OPS-04` ableitbar.
|
||||
|
||||
## 5a. Auftragsverarbeitung bei externem KI-Anbieter — AI `ENG-03`
|
||||
|
||||
AI `ENG-03` erlaubt optional einen externen, OpenAI-kompatiblen Cloud-Anbieter als Alternative zum lokalen Ollama-Standardbetrieb; `GOV-03` steuert je Tenant, ob Inferenz lokal oder extern läuft, und schließt Training auf Kundendaten aus (siehe `SICHERHEITSKONZEPT.md` Abschnitt 18, Finding #6). Technisch ist die Trennung damit vorbereitet — vertraglich fehlt: ein Auftragsverarbeitungsvertrag (AVV) mit jedem für einen Tenant aktivierbaren externen KI-Anbieter, bevor dessen Aktivierung für diesen Tenant freigegeben wird. Kein technisches Ticket nötig (die Umschaltung selbst existiert bereits über `GOV-03`), aber ein organisatorischer Prozess: externe Anbieter dürfen für einen Tenant erst in `GOV-03` aktivierbar sein, wenn ein AVV mit diesem Anbieter vorliegt — sonst bleibt die Tenant-Konfiguration auf "nur lokal" beschränkt.
|
||||
|
||||
## 6. Exit-Strategie & Datenrückgabe bei Vertragsende
|
||||
|
||||
Technisch bereits abgedeckt: DMS `DOC-08` (Massenexport), Mail `ARC-07` (Export/Portabilität), Connect `DMS2-01` (offenes Austauschformat) — die ecoDMS-Lehre "kein Vendor-Lock" (`STORAGE-KONZEPT.md` Abschnitt 8) gilt technisch bereits.
|
||||
|
||||
Vertraglich fehlt: eine zugesicherte Frist, in der Kundendaten nach Kündigung exportierbar bleiben, bevor sie gelöscht werden — vergleichbar mit der Parallelbetriebsfrist im `MIGRATIONSKONZEPT.md` (dort 90 Tage für den Altsystem-Übergang vorgeschlagen, hier für den umgekehrten Fall: Kunde verlässt NEXARCH). Kein technisches Ticket dafür nötig (Export-Mechanik existiert), nur eine vertragliche Frist plus ggf. ein Ablaufprozess ("Datenlöschung nach Fristablauf" als Anwendung der Archive-Retention-Engine, aber in die andere Richtung: nicht Aufbewahrung erzwingen, sondern nach Frist tatsächlich löschen).
|
||||
|
||||
## 7. Modul-Deaktivierung während der Laufzeit — technische Lücke
|
||||
|
||||
Core `LIC-02` schaltet Module per Feature-Flag ab, wenn eine Lizenz das vorsieht (Kunde bucht z.B. AI ab). **Was mit den Daten des deaktivierten Moduls passiert, ist nirgends spezifiziert** — bleiben sie erhalten (nur Zugriff gesperrt) oder werden sie gelöscht? Das ist sowohl eine technische als auch eine vertragliche Frage, die aktuell in keinem Ticket beantwortet ist. Vorschlag: Deaktivierung sperrt nur den Zugriff, löscht nichts automatisch (konsistent mit der generellen Linie "Löschung nur über die Archive-Retention-Engine", siehe `STORAGE-KONZEPT.md` Abschnitt 4) — sollte aber als explizites Akzeptanzkriterium in `LIC-02` nachgezogen werden, falls das noch nicht der Fall ist.
|
||||
|
||||
## 8. Offene Punkte
|
||||
|
||||
- RPO/RTO-Werte fehlen (Abschnitt 4) — brauchen einen tatsächlichen Restore-Test, bevor sie vertraglich zugesichert werden können.
|
||||
- Modul-Deaktivierung ohne Datenverlust ist als Verhalten plausibel, aber nicht als Akzeptanzkriterium in Core `LIC-02` verankert — sollte geprüft/ergänzt werden.
|
||||
- Exit-Frist (Abschnitt 6) ist ein reiner Vertragswert, keine Technik — muss vom Geschäft festgelegt werden, ähnlich wie die Preisgestaltung in `LIZENZMODELL.md`.
|
||||
- Dieses Dokument ersetzt keine juristische Prüfung von AVV/AGB — es benennt nur, wo Vertrag und Technik zusammenpassen müssen.
|
||||
- AVV mit externen KI-Anbietern (Abschnitt 5a) ist ein reiner Vertragsschritt, keine Technik — muss vor Freigabe eines externen Anbieters in `GOV-03` je Tenant vorliegen.
|
||||
@@ -1,420 +0,0 @@
|
||||
# NEXARCH 2.0 – Sicherheitskonzept
|
||||
|
||||
Stand: 2026-08-26, alle 10 Punkte in Abschnitt 11 zwischen 2026-08-28 geklärt oder durch neue Tickets adressiert (Core OPS-06, Core IAM-15, DMS SRC-11, Mail SRC-11). Grundlage: `nexarch-state.json`, `SKALIERUNGSKONZEPT.md`, `STORAGE-KONZEPT.md`, `core-kanban/`, `dms-kanban/`, `mail-kanban/`, `archive-kanban/`, `workflow-kanban/`, `dms-kanban/known-issues-archivdms.md`, `dms-kanban/known-issues-archivmail.md` (Boards inzwischen aus dem Repo entfernt, Ticket-Historie liegt in der Gitea-PR-Historie).
|
||||
|
||||
Dieses Dokument führt keine neue Architektur ein. Es fasst die bereits in den sieben Boards getroffenen sicherheitsrelevanten Einzelentscheidungen zu einem Gesamtbild zusammen und prüft dabei — nach demselben Muster wie `STORAGE-KONZEPT.md` — auf Lücken und Widersprüche. Prüfraster: OWASP Top 10, angewendet auf den tatsächlichen NEXARCH-Techstack (Go, PostgreSQL, JWT, S3-kompatibler Storage, Manticore), nicht generisch abgehandelt.
|
||||
|
||||
## 1. Authentifizierung
|
||||
|
||||
| Baustein | Entscheidung | Ticket |
|
||||
|---|---|---|
|
||||
| Passwort-Hashing | bcrypt (bewusst nicht Argon2) | `nexarch-state.json` Techstack |
|
||||
| Token | JWT, zustandslos, lokale Signaturverifikation via JWKS-ähnlichem Mechanismus mit `kid`-Rotation | Core `API-05` |
|
||||
| Zweiter Faktor | TOTP (RFC 6238), Einrichtung, Wiederherstellungscodes, pro Tenant erzwingbar | Core `IAM-04` |
|
||||
| Verzeichnisanbindung | LDAP-Abgleich | Core `IAM-05` |
|
||||
| Föderation | SSO/OIDC | Core `IAM-06` |
|
||||
| Brute-Force-Schutz | Account-Lockout / Rate-Limiting am Login | Core `IAM-07` |
|
||||
|
||||
Die Wahl bcrypt statt Argon2 ist im Entscheidungsverlauf nicht mit einer eigenen Begründung hinterlegt (`nexarch-state.json` Techstack-Feld nennt es nur als Faktum). Das ist keine Sicherheitslücke — bcrypt gilt weiterhin als solide, solange Kostenfaktor aktuell gehalten wird — aber eine unbegründete Abweichung vom heute üblichen Argon2id-Standard sollte im Core-Board mindestens als bewusste Entscheidung mit Kostenfaktor-Wert dokumentiert werden, nicht nur als Faktenzeile in der State-Datei.
|
||||
|
||||
**Korrektur gegenüber archivdms:** `known-issues-archivdms.md` Punkt 9 beschreibt einen In-Memory-Rate-Limiter ohne Shared State (`internal/auth/ratelimit.go`) — bei Mehrinstanz-Deployment pro Instanz getrennt und damit aushebelbar. `SKALIERUNGSKONZEPT.md` Abschnitt 1 hält fest, dass Core `IAM-07`/`API-03` Rate-Limiting mit **shared state statt in-process** umsetzt. Damit ist der konkrete archivdms-Fehler für den Login-Pfad explizit adressiert.
|
||||
|
||||
2FA-Aktivierungspflicht ist laut `IAM-04` pro Tenant konfigurierbar, nicht global erzwungen — das ist eine bewusste Flexibilitätsentscheidung (SaaS-Betrieb mit unterschiedlichen Kundenanforderungen), sollte aber im Betriebshandbuch als Empfehlung ("2FA-Pflicht für Admin-Rollen mindestens") festgehalten werden, sobald ein Betriebshandbuch existiert (siehe `fehlende_konzeptdokumente`).
|
||||
|
||||
## 2. Autorisierung / Zugriffskontrolle
|
||||
|
||||
RBAC ist vollständig in Core zentralisiert (`RBAC-01`..`RBAC-05`) — kein Modul implementiert eigene Rechteprüfung, das ist direkte Konsequenz der IAM-Konsolidierung (`nexarch-state.json` Entscheidungsverlauf "Konsolidierung IAM").
|
||||
|
||||
**Korrektur gegenüber archivmail:** `known-issues-archivmail.md` Punkt 7 beschreibt Tenant-Filterung als **Post-Filter statt in der Query** (`internal/api/ediscovery.go:90`) — fehleranfällig, weil jeder neue Codepfad das Filtern erneut korrekt implementieren muss. Die Notiz im selben Dokument ordnet das explizit auch DMS `IAM-03` ("Policy-Enforcement — zentral, nicht pro Handler") zu. Das Prinzip "Tenant-/Rechte-Scoping ausschließlich in der Query-/Repository-Schicht, nie als Post-Filter im Handler" ist damit als Korrektur benannt, aber es lohnt sich, es hier noch einmal projektweit festzuhalten: Diese Regel gilt für **jedes** Modul, das gegen die zentrale Core-RBAC-Prüfung arbeitet (DMS, Mail, Archive, Workflow, AI, Connect gleichermaßen), nicht nur für die ursprünglich betroffene eDiscovery-Funktion.
|
||||
|
||||
**Tenant-Isolation — strukturell gelöst durch Modell C:** Multi-Tenancy läuft nach Modell C: eine physisch getrennte Datenbank je Mandant plus schlanke Registry (Core `TEN-01`/`TEN-06`/`TEN-07`, `nexarch-state.json` `multi_tenancy`, Begründung in `SKALIERUNGSKONZEPT.md` Abschnitt 4). Ein vergessener `tenant_id`-Filter kann damit keine fremden Daten mehr liefern, weil sie in der angesprochenen Datenbank nicht existieren; die Fehlerklasse aus `known-issues-archivdms.md` (Punkte 9/10, Tenant-Scoping-Fragilität) und `known-issues-archivmail.md` (#2/#7) ist strukturell beseitigt, nicht nur unwahrscheinlicher. Row-Level-Security ist bei physischer Trennung redundant und nicht vorgesehen. Die harte Regel aus dem vorigen Absatz (Rechte-Scoping zentral in der Repository-Schicht, nie als Post-Filter im Handler) bleibt bestehen, denn sie betrifft die Rechte *innerhalb* eines Mandanten (Ordner, Dokumente, Rollen), nicht die Mandantentrennung; `known-issues-archivdms.md` Punkt 2 fordert dafür eine Testpflicht als Merge-Gate, die bisher in keinem QA-Ticket als projektweite CI-Regel verankert ist (siehe Abschnitt 10). Verbleibendes Restrisiko liegt nicht mehr im Filter, sondern in der Zuordnung Mandant → Datenbank (Registry, Verbindungsinformation) und in mandantenübergreifenden Prozessspeichern (Caches, Pools): Kompensation sind der Pflicht-Tenant-Kontext bei jedem Modulaufruf (DMS `INT-16`), mandantengetrennte Cache-Schlüssel (Core `RBAC-10`) und der Mandant aus dem Token statt aus Anfrageparametern.
|
||||
|
||||
**Superadmin-Sonderfall:** `known-issues-archivdms.md` Punkt 4 beschreibt einen wiederholt vergessenen Superadmin-ohne-Tenant-Zustand (403 "tenant context required", mehrfach nachträglich gepatcht). Kein Core-Ticket in der gelesenen Auswahl adressiert das explizit als First-Class-Datenmodell-Zustand — siehe Offene Punkte (Abschnitt 11).
|
||||
|
||||
## 3. Injection-Schutz
|
||||
|
||||
Dynamische SQL-Klauseln/Tabellennamen via `fmt.Sprintf` bzw. String-Konkatenation waren ein wiederkehrendes Antipattern in beiden Altsystemen:
|
||||
|
||||
- archivdms: `known-issues-archivdms.md` Punkt 10 — dynamische Tabellennamen via `fmt.Sprintf` (`taxonomy.go`, `workflows.go`, `classification_templates_title.go`, `internal/index/manticore.go`), zur Tatzeit nur durch eine Whitelist-Funktion abgesichert, als "fragiles Muster" bewertet.
|
||||
- archivmail: `known-issues-archivmail.md` Punkte 11/12 — dynamische SQL-Klauseln via Sprintf/Join (`internal/index/manticore.go:268,323`, `internal/storage/ocr.go:159`), gleiches Muster zweimal dupliziert.
|
||||
|
||||
Beide Fundstellen betreffen denselben Bereich: Suchindex-/Query-Aufbau gegen Manticore bzw. Postgres mit dynamischen Feldlisten. Die Korrektur ist in den entsprechenden Suchindex-Tickets verankert: DMS `SRC-01`, Mail `SRC-01` (Suchindex/Such-API-Grundlage der jeweiligen Module). Die verbindliche Regel aus beiden Known-Issues-Dokumenten lautet übereinstimmend: **Spalten-/Tabellennamen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau, auch nicht hinter einer Whitelist-Funktion.** Ein zentraler, getesteter Query-Builder mit Feld-Whitelist (`known-issues-archivmail.md` Punkt 12) ist der empfohlene Ansatz — ob dieser als gemeinsame Utility zwischen DMS `SRC-01` und Mail `SRC-01` geteilt wird oder je Modul separat entsteht, ist in keinem der beiden Tickets festgelegt (siehe Offene Punkte).
|
||||
|
||||
## 4. Sensible Daten / Verschlüsselung
|
||||
|
||||
| Baustein | Entscheidung | Ticket |
|
||||
|---|---|---|
|
||||
| Verschlüsselung at rest | AES-256-GCM, Envelope Encryption | DMS `FDN-09`, Mail `ARC-02` |
|
||||
| Reihenfolge Hash/Verschlüsseln | SHA-256-Hash auf Klartext **vor** Verschlüsselung (sonst funktioniert Dublettenerkennung nie) | DMS `FDN-09`/`DOC-02`, Mail `ARC-02`/`ARC-03` |
|
||||
| Secrets | ausschließlich über Umgebungsvariablen, nie im Code | durchgängige Ticket-Regel (Abschlussabschnitt jedes Tickets, u.a. explizit in `IAM-04`..`IAM-07`, `RBAC-01`..`RBAC-05`, `API-02`..`API-06`, `AUD-05`) |
|
||||
| Audit-Log-Aufbewahrung | append-only (`AUD-02`), Retention über Archive-Engine statt eigener Löschlogik, Default 10 Jahre (GoBD-Buchungsbeleg-Frist) | Core `AUD-05`, Archive `RET-01`/`RET-02`/`RET-05` |
|
||||
|
||||
Die Hash-vor-Verschlüsseln-Reihenfolge ist ein gutes Beispiel für eine bereits im Projekt selbst aufgedeckte und behobene Lücke: laut Entscheidungsverlauf fehlte sie zunächst im Mail-Board (`ARC-02`/`ARC-03`), obwohl DMS (`FDN-09`) sie schon hatte, und wurde nachgezogen — dokumentiert in `nexarch-state.json` unter "Duplikatserkennung vor Weiterverarbeitung".
|
||||
|
||||
**Schlüsselverwaltung/-rotation — geklärt (2026-08-27):** Zweistufige Schlüsselhierarchie statt eines einzelnen globalen Master-Key. Core hält EINEN Master-Key (Root-KEK, über Umgebungsvariable/Secret-Provider, austauschbar gegen echten KMS-Dienst), der ausschließlich **Tenant-Schlüssel** (Tenant-KEK) verpackt — niemals Objekte direkt. Jeder Mandant erhält bei seiner Provisionierung (`TEN-01`) einen eigenen Tenant-KEK, verschlüsselt mit dem Master-Key in der Registry abgelegt. DMS (`FDN-09`) und Mail (`ARC-02`) beziehen für ihre pro-Objekt-DEKs ausschließlich den entschlüsselten Tenant-KEK ihres jeweiligen Mandanten (nie den Master-Key direkt), authentifiziert über das Service-Credential aus `API-02`. Rotation ist auf beiden Ebenen unabhängig möglich, ohne Objektdaten neu zu verschlüsseln: Master-Key-Rotation verpackt nur alle Tenant-KEKs neu (klein, schnell), Tenant-KEK-Rotation verpackt nur die DEKs dieses einen Mandanten neu und berührt keinen anderen Tenant. Umgesetzt in Core `API-10`.
|
||||
|
||||
**Begründung für die Tenant-Ebene:** Ein einzelner globaler Master-Key hätte einen gemeinsamen Blast-Radius für alle Mandanten geschaffen — ein kompromittierter Tenant-KEK (z. B. durch ein fehlerhaftes Modul-Log oder einen kompromittierten Service-Credential-Aufruf) betrifft mit der zweistufigen Hierarchie strukturell nur diesen EINEN Mandanten. Das ist die konsequente Fortsetzung der physischen Modell-C-Isolation (siehe TEN-01, Entscheidungsverlauf "Multi-Tenancy: Modell A -> Modell C") auch auf Schlüsselebene, statt einer Isolationslücke, die die sonstige Trennung wieder aufheben würde.
|
||||
|
||||
Die JWT-Schlüsselrotation (Core-Public-Key, `kid`-Rotation) ist dagegen bereits ausformuliert (`SKALIERUNGSKONZEPT.md` Abschnitt 11 letzter Punkt, Core `API-05`): muss ohne Ausfallzeit anderer Module möglich sein. Das ist ein anderer Schlüssel als der Storage-Verschlüsselungs-Master-Key und löst dessen Rotationsfrage nicht mit.
|
||||
|
||||
## 5. Eingabevalidierung / bekannte Angriffsvektoren aus den Altsystemen
|
||||
|
||||
| Altsystem-Fund | Fundstelle | NEXARCH-Korrektur |
|
||||
|---|---|---|
|
||||
| Header-Injection bei E-Mail-Versand (From/To/Subject per Stringkonkatenation ohne CRLF-Prüfung) | `known-issues-archivmail.md` #1, `internal/mailer/mailer.go:144-146` | Mail `ING-03` — `net/mail`-Writer bzw. harte CRLF-/Steuerzeichen-Prüfung |
|
||||
| Ungebremstes Lesen von Anhängen (`io.ReadAll` ohne Größenlimit → Speicherbombe) | `known-issues-archivmail.md` #3, `pkg/mailparser/parser.go` | Mail `ING-04` (Ingestion) und DMS `DOC-01` (Upload-API) — `io.LimitReader` mit Max-Size, harte Ablehnung; explizit auch für DMS-Uploads übernommen, nicht nur Mail |
|
||||
| XSS-Risiko bei Anhang-/Dokument-Vorschau über iframe-Rendering von Fremdinhalt | `known-issues-archivmail.md` #9, positiv gelöst via `PdfCanvasPreview.tsx` (Canvas statt iframe) | DMS `DOC-05` (PDF-Viewer) und Mail `UX-03` — Canvas-Rendering von Anfang an, kein iframe/HTML-Rendering von Fremdinhalt |
|
||||
| Content-Type-Erkennung über Dateiendung statt Inhalt | `known-issues-archivmail.md` #8, `AttachmentPreviewDialog.tsx` | betrifft ebenfalls DOC-05 — serverseitige Magic-Bytes-Erkennung statt Dateiendung, im Ticket-Titel nicht explizit als Akzeptanzkriterium sichtbar (siehe Offene Punkte) |
|
||||
|
||||
Die Speicherbomben-Korrektur (`DOC-01`/`ING-04`) ist im Entscheidungsverlauf nicht als eigener Eintrag sichtbar, aber laut Known-Issues-Dokument bereits als "betrifft auch DMS" annotiert — das Konzept übernimmt diese Zuordnung, prüft aber nicht, ob `DOC-01` das Größenlimit tatsächlich als Akzeptanzkriterium enthält oder nur als Empfehlung im Known-Issues-Dokument steht. Diese Prüfung sollte bei nächster Gelegenheit nachgeholt werden.
|
||||
|
||||
## 6. Vertrauensstellung zwischen Modulen
|
||||
|
||||
NEXARCH ist modular mit sieben eigenständigen Boards — Vertrauen zwischen Modul und Core (und indirekt zwischen Modulen) ist eine eigene Angriffsfläche, die in einem Monolithen nicht existieren würde.
|
||||
|
||||
- **Modul vertraut Core:** asymmetrische JWT-Signatur, Core signiert mit privatem Schlüssel, Module verifizieren lokal mit öffentlichem Schlüssel über JWKS-ähnliche Verteilung mit `kid`-Rotation (Core `API-05`).
|
||||
- **Core vertraut Modul:** Service-Credential je Modul-Instanz, ausgestellt bei Provisionierung (Core `API-02`, erweitert). Notwendig, weil einseitiges Vertrauen (nur Module prüfen Core-Signatur) nicht ausreicht — Core muss bei Nachlieferung/Registrierung wissen, welche Modul-Instanz tatsächlich anfragt, sonst könnte sich ein fremder Absender als Modul ausgeben (`nexarch-state.json` Entscheidungsverlauf "Vertrauensstellung Core↔Module").
|
||||
- **Wiederanlauf nach Ausfall:** sofortiger Cache-Refresh per Health-Check-Trigger, gepufferte Audit-Events/Nutzungszähler werden über das Service-Credential authentifiziert nachgeliefert, Pufferqueue muss persistent sein (Core `API-06`).
|
||||
- **Rückkanal-API-Berechtigungsprüfung:** Workflow `VOR-04` (Pull-Rückkanal, damit DMS/Mail Akte/Vermerke/Wiedervorlage im eigenen Kontext anzeigen können) ist explizit als "read-only, berechtigungsgeprüft" spezifiziert — das ist der einzige Rückkanal (Pull), der zusätzlich zum bereits bestehenden Push-Kanal (Workflow `ENG-02`) existiert und daher eine eigene Berechtigungsprüfung braucht, nicht nur das Push-seitige Modul-Vertrauen wiederverwenden darf.
|
||||
|
||||
Dieses wechselseitige Vertrauensmodell (asymmetrische Signatur + Service-Credential) ist die Antwort auf ein OWASP-Broken-Access-Control-Szenario, das speziell durch die Modul-Architektur entsteht und in einem monolithischen Altsystem (archivdms/archivmail) so nicht vorkam — beide Known-Issues-Dokumente enthalten dazu folgerichtig keinen Eintrag.
|
||||
|
||||
## 7. Ausfallsicherheit als Sicherheitsthema
|
||||
|
||||
Verfügbarkeit ist hier aufgeführt, weil ein unkontrollierter Core-Ausfall entweder zu Totalausfall der Plattform (worst case für Verfügbarkeit) oder — schlimmer — zu unkontrolliertem Fail-open bei Rechteprüfungen führen könnte, wenn nicht bewusst entschieden wird.
|
||||
|
||||
- **Fail-open vs. fail-closed** ist explizit pro Aktionsklasse festgelegt (Core `API-05`/`API-06`, ausformuliert in `SKALIERUNGSKONZEPT.md` Abschnitt 11): Lesevorgänge mit abgelaufenem Rechte-Cache eher fail-open (letzter bekannter Stand gilt weiter), sicherheitskritische Aktionen (Rechteänderung, Löschung, Freigabe) eher fail-closed (lieber verweigern als mit veralteten Rechten ausführen). Das ist eine bewusste, dokumentierte Abwägung — kein Automatismus in eine Richtung.
|
||||
- **Core-Hochverfügbarkeit** selbst (`SKALIERUNGSKONZEPT.md` Abschnitt 10): Anwendungsschicht ist zustandslos, echter Single Point of Failure ist die Postgres-Instanz. Stufe 1 kein Live-Failover (Backup/Restore, Archive `BAK-03`), Stufe 2/3 Streaming-Replikation mit pg_auto_failover (LXC-tauglich) oder Patroni (Multi-Standort), Verbindungsindirektion via PgBouncer/HAProxy, Fencing gegen Split-Brain.
|
||||
- Wichtiger Nebeneffekt, im Skalierungskonzept explizit benannt: der JWKS-Mechanismus aus `API-05` bleibt während eines kurzen Core-DB-Failover-Fensters funktionsfähig, weil Signaturprüfung keine Core-DB-Verbindung braucht — Core-DB-Failover und die Resilienz der anderen Module sind zwei getrennte, sich gegenseitig entlastende Probleme.
|
||||
|
||||
## 8. Sicherheitsrelevante Betriebsaspekte
|
||||
|
||||
- **Transportverschlüsselung E-Mail:** TLS/STARTTLS für IMAP/POP3/SMTP (Mail `ING-06`).
|
||||
- **Kein direkter Storage-Zugriff:** Up-/Downloads laufen ausschließlich über zeitlich begrenzte signierte URLs, die das Backend ausstellt — Storage-Zugangsdaten erreichen nie den Browser (`STORAGE-KONZEPT.md` Abschnitt 5, DMS `FDN-03` Akzeptanzkriterium 2). Presigned-URL-Gültigkeit soll kurz und konfigurierbar gehalten werden (Minuten, nicht Stunden).
|
||||
- **Zentrales Rate-Limiting:** Core `API-03` mit Shared State statt in-process — korrigiert denselben archivdms-Mehrinstanz-Bug wie in Abschnitt 1 beschrieben, hier aber als API-weite (nicht nur Login-spezifische) Infrastruktur, seit der API/Token/Rate-Limiting-Konsolidierung (`nexarch-state.json` Entscheidungsverlauf) alleinige Quelle für alle Module — DMS/Mail betreiben kein eigenes Rate-Limiting mehr.
|
||||
|
||||
## 9. Bewährte Muster, die bewusst übernommen werden
|
||||
|
||||
Nicht jeder Fund in den Altsystemen ist ein Fehler. Beide Known-Issues-Dokumente benennen positiv zu übernehmende Muster ausdrücklich:
|
||||
|
||||
- **Vier-Augen-Prinzip mit `FOR UPDATE`-Lock** bei Löschbestätigung (`known-issues-archivdms.md`, Abschnitt "Positiv zu übernehmende Muster") — im NEXARCH-Kontext die passende Entsprechung für Compliance-kritische Freigaben in Archive `CMP-06` (Vier-Augen-Prinzip), wo derselbe Lock-Mechanismus gegen doppelte/konkurrierende Freigabe schützen sollte.
|
||||
- **Timing-safe Vergleich** bei sicherheitsrelevanten Entscheidungen — in archivdms bei Share-Link-Passwortvergleich eingesetzt (`known-issues-archivdms.md`, Positiv-Abschnitt). Gilt als generelles Prinzip für jeden Vergleich, der eine Zugriffsentscheidung trifft (Passwort, Token, Signatur, Wiederherstellungscode aus `IAM-04`), nicht nur für Share-Links — sollte als projektweite Coding-Konvention (analog zur Sprintf-Verbots-Regel aus Abschnitt 3) festgehalten werden, ist aber in keinem Ticket als Konvention formuliert, nur implizit durch das positive Altsystem-Beispiel nahegelegt.
|
||||
- **Tenant-Filter in der Query, IDOR-Guards bei Shares** — ebenfalls aus archivdms als positiv übernommenes Muster gelistet; deckt sich mit der in Abschnitt 2 verlangten Regel (Scoping in der Repository-Schicht).
|
||||
|
||||
## 10. CI/Merge-Gates für sicherheitsrelevanten Code
|
||||
|
||||
`known-issues-archivdms.md` Punkt 2 fordert explizit Testpflicht für Auth/Tenant-Scoping/Retention als Merge-Gate; `known-issues-archivmail.md` Punkt 4 fordert dasselbe für Tenant-Scoping/Protokoll-State-Machines. Beide Forderungen sind in den Known-Issues-Dokumenten als Lehre formuliert, aber in keinem gelesenen QA-Ticket (Core `QA-01`..`QA-05`, DMS `QA-01`, Mail `QA-07`) als projektweite, verbindliche CI-Regel ("kein Merge auf sicherheitsrelevanten Code ohne Test") wiedergefunden. Das ist keine fehlende Einzelentscheidung, sondern eine fehlende Verallgemeinerung einer bereits zweimal unabhängig gemachten Erfahrung — siehe Offene Punkte.
|
||||
|
||||
## 11. Offene Punkte
|
||||
|
||||
Die folgenden Themen sind entweder in keinem Board bisher behandelt oder nur am Rand erwähnt, ohne dass ein Ticket sie abdeckt. Sie werden hier bewusst nur benannt, nicht mit erfundenen Tickets vorweggenommen — das entscheidet der Nutzer:
|
||||
|
||||
1. ~~Security-Header für das Next.js-Frontend~~ — **geklärt (2026-08-28)**: Core `API-08` "Security-Header-Baseline für alle Frontends" deckt CSP, HSTS, X-Frame-Options, Referrer-Policy, X-Content-Type-Options als gemeinsame, wiederverwendbare Middleware ab, die jedes Modul-Frontend einbindet statt eigener Definition.
|
||||
|
||||
2. ~~Dependency-/Supply-Chain-Sicherheit~~ — **geklärt (2026-08-28)**: neues Ticket Core `OPS-06` "Automatisiertes Schwachstellen-Scanning (Supply-Chain)" verankert `govulncheck` (Go-Module) und `npm audit`/Dependabot (Frontend-Pakete) als verbindlichen, blockierenden CI-Schritt über alle sieben Boards. Hängt im Core-Abschluss-Gate `QA-05`.
|
||||
|
||||
3. ~~Schlüsselverwaltung/-rotation für den Storage-Verschlüsselungs-Master-Key~~ — **geklärt (2026-08-27), siehe Abschnitt 4**: zweistufige Hierarchie Master-KEK → Tenant-KEK → Objekt-DEK, umgesetzt in Core `API-10`.
|
||||
|
||||
4. ~~Verschlüsselung in Transit zwischen Modulen~~ — **geklärt (2026-08-28)**: Core `API-09` "mTLS zwischen Modul-Instanzen (verteilte Installation)" deckt genau das ab — gegenseitige TLS-Authentifizierung zwischen allen sieben Modul-Instanzen für Stufe 2/3, optional für Stufe-1-Einzel-LXC. Hängt im Core-Abschluss-Gate `QA-04`. `PROXMOX-DEPLOYMENT.md` Abschnitt 3 referenziert es bereits korrekt als ab Stufe 2 verpflichtend.
|
||||
|
||||
5. ~~Penetrationstest-Verfahren vor Produktivbetrieb~~ — **geklärt (2026-08-28)**: Core `QA-06` "Externe Sicherheitsprüfung / Penetrationstest vor Produktivbetrieb" deckt genau das ab, projektweit über alle sieben Boards, als externe Ergänzung zu den internen Sicherheits-Prüfgates. `QA-06` ist selbst das letzte, allem nachgelagerte Gate (hängt von `QA-05`, `QA-07`, `QA-08` ab) — der Pentest läuft also erst, wenn alles andere bereits abgenommen ist.
|
||||
|
||||
6. ~~Incident-Response-Plan~~ — **geklärt (2026-08-28)**: Core `OPS-04` deckt genau das ab (Erkennung, Eskalation, DSGVO-72h-Meldefrist, Verweis auf Core `AUD-01`/`AUD-05` als Vorfall-Datenquelle) und ist im `code`-Repository bereits als tatsächliches Betriebsdokument umgesetzt (`docs/INCIDENT-RESPONSE-PLAN.md`). Offen bleibt nur die Schlüssel-Notfallrotation im Vorfallsfall — die behandelt `OPS-04` nicht explizit, sollte als Ergänzung im Dokument nachgezogen werden.
|
||||
|
||||
7. ~~Superadmin-ohne-Tenant als First-Class-Zustand~~ — **geklärt (2026-08-28)**: Core `IAM-01` Akzeptanzkriterium 2 lautet explizit "Superadmin-ohne-Tenant ist als First-Class-Zustand modelliert" — war bei der ersten Lektüre offenbar übersehen worden, ist aber bereits vorhanden.
|
||||
|
||||
8. ~~Verbindliche CI-Testpflicht für sicherheitsrelevanten Code als projektweite Regel~~ — **geklärt (2026-08-28)**: Akzeptanzkriterium "Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) als verbindliches Merge-Gate" in allen 6 übrigen `QA-01`-Tickets (DMS, Mail, Archive, Workflow, AI, Connect) nachgezogen, analog zu Core `QA-01`. Jetzt projektweit einheitlich.
|
||||
|
||||
9. ~~Timing-safe Vergleich als projektweite Coding-Konvention~~ — **geklärt (2026-08-28)**: neues Ticket Core `IAM-15` verankert die Regel projektweit (Passwort-Hash, Token, Signatur, 2FA-Wiederherstellungscode), nicht mehr nur implizit über das archivdms-Beispiel. Hängt im Core-Abschluss-Gate `QA-05`.
|
||||
|
||||
10. ~~Gemeinsamer Query-Builder für Injection-Schutz~~ — **geklärt (2026-08-28)**: Entscheidung getroffen — getrennte Implementierung je Board, keine gemeinsame Utility, konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren (siehe `nexarch-state.json` → `bewusst_nicht_zentralisiert`). Neue Tickets DMS `SRC-11` und Mail `SRC-11` verankern dieselbe Whitelist-Regel unabhängig in beiden Boards, hängen in DMS `QA-06` bzw. Mail `QA-04`.
|
||||
|
||||
11. **bcrypt-Kostenfaktor nicht dokumentiert.** Die Wahl bcrypt statt Argon2 ist als Faktum in `nexarch-state.json` festgehalten, aber ohne Begründung und ohne festgelegten Kostenfaktor.
|
||||
|
||||
12. ~~Anomalie-Erkennung bei API-Token-Nutzung (Core `IAM-09`)~~ — **geklärt (2026-09-14)**: neues Ticket Core `IAM-20` "Anomalie-Erkennung bei API-Token-/Service-Account-Nutzung" ergänzt IP-/Rate-Anomalie-Erkennung als Hinweissignal (Audit-Event, keine automatische Sperre) zur reinen Scope-/Ablaufzeit-Prüfung aus `IAM-09`. Siehe Threat-Model-Finding #2 in Abschnitt 13.
|
||||
|
||||
## 13. Threat Model: NEXARCH Core (STRIDE)
|
||||
|
||||
Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Core-Kanban (Identity, Tenancy, Auth, RBAC, Lizenzierung/Feature-Flags, Audit, zentrale Konfiguration/Benachrichtigung, Core-API/Modulverwaltung, Monitoring), analysiert anhand der Ticket-Inhalte (TEN/IAM/RBAC/AUD/LIC/CFG/API/OPS), nicht anhand des tatsächlichen Codes. Alle Findings mit Schweregrad Kritisch/Hoch/Mittel sind inzwischen als Tickets in Welle 9 und 10 des Core-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea); Finding #2 (Niedrig-Mittel) ist offen, siehe Punkt 11 oben.
|
||||
|
||||
### Systemüberblick
|
||||
|
||||
```
|
||||
Client/Browser --HTTPS--> Modul-Frontend (Next.js) --> Core-API (Go/net/http)
|
||||
|
|
||||
JWT-Middleware (IAM-02) --tenant claim--
|
||||
|
|
||||
Connection-Router (TEN-06) --lookup--> Registry-DB
|
||||
|
|
||||
Tenant-DB (Modell C, 1 pro Mandant)
|
||||
|
|
||||
Modul-zu-Modul (DMS/Mail/Archive/Workflow/AI/Connect) via Service-Credential (API-02) [+ optional mTLS API-09]
|
||||
|
|
||||
Master-KEK (API-10) --wraps--> Tenant-KEK --wraps--> Objekt-DEK (in DMS/Mail)
|
||||
```
|
||||
|
||||
Trust-Boundaries: (1) Internet/Client → Modul-Frontend, (2) Frontend/externe Aufrufer → Core-API, (3) Core-API → Registry-DB, (4) Core-API → Tenant-DB, (5) Core ↔ andere Module (Service-Credentials), (6) Core → LDAP/OIDC-Provider (extern), (7) Master-KEK-Speicherort (KMS/Secret-Provider) → Registry.
|
||||
|
||||
### Findings
|
||||
|
||||
| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|
||||
|---|--------|------------|-----------|--------------|--------|
|
||||
| 1 | Spoofing | IAM-02 Login/JWT | Kein Widerrufsmechanismus — gestohlenes JWT bleibt bis Ablauf gültig, kein Logout-Invalidierung serverseitig | Hoch | `IAM-17` |
|
||||
| 2 | Spoofing | IAM-09 API-Token/Service-Accounts | Token-Diebstahl bei Leak — keine Anomalie-Erkennung bei Nutzung aus fremdem Kontext | Mittel | `IAM-20` |
|
||||
| 3 | Tampering | TEN-07 Migrations-Orchestrierung | Migrationsdatei ohne Integritätsprüfung würde 1:N gegen alle Tenant-DBs laufen | Mittel | `TEN-10` |
|
||||
| 4 | Tampering | API-10 Master-Key-Verwaltung | Master-KEK-Kompromittierung hebelt zweistufige Hierarchie komplett aus — kein Rotationszwang/Alarming | Kritisch | `API-13` |
|
||||
| 5 | Repudiation | AUD-01 Audit-Log | „Append-only" nur konventionell, nicht technisch durchgesetzt (DB-Admin-Zugriff könnte ändern/löschen) | Mittel | `AUD-07` |
|
||||
| 6 | Information Disclosure | API-08 Security-Header-Baseline | Gut abgedeckt (CSP/HSTS/X-Frame etc. zentral) | Niedrig | abgedeckt |
|
||||
| 7 | Information Disclosure | TEN-01 Control-Plane-Registry | Höchstwertiges Einzelziel (Verbindungsinfo zu allen Tenant-DBs + Superadmin-Konten) — kein eigenes Härtungs-Ticket | Kritisch | `TEN-09` |
|
||||
| 8 | Information Disclosure | IAM-05 LDAP/AD-Anbindung | LDAP-Bind-Credentials je Tenant — Speicherform (Klartext vs. verschlüsselt) nicht spezifiziert | Mittel | `IAM-19` |
|
||||
| 9 | Denial of Service | TEN-06 Connection-Pooling | Ungedeckeltes LRU-Pooling ohne Rate-Limit auf Tenant-Wechsel — Pool-Thrashing-Risiko | Mittel | `TEN-11` |
|
||||
| 10 | Denial of Service | LIC-02 Feature-Flag-Service | Kein definiertes Fail-Open/Fail-Closed-Verhalten bei Registry-Ausfall oder Cache-Invalidierungssturm | Mittel | `LIC-06` |
|
||||
| 11 | Elevation of Privilege | RBAC-01 Rollenmodell | Keine Prüfung gegen zirkuläre/fehlerhafte Rollenvererbung Tenant-Admin → Superadmin | Hoch | `RBAC-08` |
|
||||
| 12 | Elevation of Privilege | API-09 mTLS Modul-zu-Modul | Für Stufe-1 optional — Aktivierung beim Wechsel auf Stufe 2 könnte vergessen werden | Mittel | `OPS-07` |
|
||||
| 13 | Elevation of Privilege | IAM-06 SSO/OIDC | Claim-Validierung (Issuer/Audience/Signatur) nicht spezifiziert — Risiko automatischer Superadmin-Ableitung aus externem Claim | Hoch | `IAM-18` |
|
||||
|
||||
### Bereits abgedeckt (ohne Nachbesserung nötig)
|
||||
|
||||
- **Tenant-Isolation strukturell** (Modell C, physisch getrennte DB) — macht klassisches "vergessener tenant_id-Filter"-Leck strukturell unmöglich (siehe `nexarch-state.json`). Kein Finding dafür.
|
||||
- **Security-Header-Baseline** (`API-08`) zentral statt pro Modul.
|
||||
- **Envelope-Encryption-Konzept** (`API-10`) zweistufig — richtiger Ansatz, Finding #4 betraf nur Betrieb/Rotation, nicht das Modell selbst.
|
||||
- **Audit-Log als eigenständiges Modell** (`AUD-01`), DSGVO-Meldeprozess vorhanden (`OPS-04`, 72h-Frist).
|
||||
- **bcrypt statt schwächerem Hashing**, Trennung Auth/Autorisierung (Casbin-Prinzip).
|
||||
|
||||
## 14. Threat Model: NEXARCH DMS (STRIDE)
|
||||
|
||||
Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: DMS-Kanban (Dokumentenkern/Upload/Storage/Verschlüsselung, Suche & OCR, Metadaten, Versionierung, Integration/API, Hot-Folder/Scanner, UX), analysiert anhand der Ticket-Inhalte, nicht anhand des tatsächlichen Codes. Identity/Auth/RBAC/Tenancy sind nach Core ausgelagert und dort bereits in Abschnitt 13 analysiert — hier nicht erneut. Alle Findings sind als Tickets in Welle 12 (Hoch/Mittel) bzw. Welle 13 (Finding #9, `DOC-18`, ergänzt 2026-09-14) des DMS-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).
|
||||
|
||||
### Systemüberblick
|
||||
|
||||
```
|
||||
Client --> DMS-Frontend --> DMS-API (auf Core-API-Grundgerüst, INT-01)
|
||||
|
|
||||
Upload (DOC-01) --checksum DOC-02--> Storage-Adapter (FDN-03, S3/lokal)
|
||||
| |
|
||||
Envelope-Encryption (FDN-09, DEK<-Tenant-KEK aus Core API-10)
|
||||
|
|
||||
Async-Worker (FDN-04: OCR/Konvertierung/Index) --> Manticore-Index (SRC-01)
|
||||
|
|
||||
Externe Eingänge: Hot-Folder (INT-08), Netzwerkscanner (INT-06), CMIS (INT-09)
|
||||
|
|
||||
Externe Ausgänge: Archive (INT-11 Retention), AI (INT-12), Workflow (INT-13)
|
||||
```
|
||||
|
||||
Trust-Boundaries: (1) Client→API, (2) API→Storage, (3) API→Async-Worker-Queue, (4) Dateisystem-Hot-Folder (lokal, kein API-Auth)→DMS, (5) DMS↔Archive/AI/Workflow (Modul-Registrierung), (6) CMIS-Schnittstelle→Drittwerkzeuge.
|
||||
|
||||
### Findings
|
||||
|
||||
| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|
||||
|---|--------|------------|-----------|--------------|--------|
|
||||
| 1 | Tampering | DOC-01 Upload | Kein Malware-Scan vor Ablage (nur MIME/Größe geprüft) | Mittel | `DOC-17` |
|
||||
| 2 | Tampering | INT-08 Hot-Folder | Dateisystem-Import ohne Auth-Kontext, keine explizite Tenant-Zuordnung des Verzeichnisses | Hoch | `INT-14` |
|
||||
| 3 | Tampering | INT-06 Netzwerkscanner-Ordner | Gleiches Muster wie INT-08 | Hoch | `INT-14` |
|
||||
| 4 | Information Disclosure | FDN-03 Storage-Adapter | Signierte URLs ohne festgelegten Scope/kurze TTL | Mittel | `FDN-10` |
|
||||
| 5 | Information Disclosure | DOC-05 Inline-Betrachter | "Ohne Download-Zwang" ist UI-Ziel, keine technische Zugriffskontrolle — Hinweis, kein eigenständiges Risiko | Niedrig | Hinweis |
|
||||
| 6 | Information Disclosure | INT-09 CMIS-Schnittstelle | Keine festgelegte Auth-/Tenant-Scoping-Parität zur REST-API | Hoch | `INT-15` |
|
||||
| 7 | Repudiation | VER-05 Unveränderliches Protokoll | "Unveränderlich" nur konventionell, nicht technisch durchgesetzt (Analogie Core-Finding #5) | Mittel | `VER-08` |
|
||||
| 8 | Denial of Service | FDN-04 Async-Worker | Keine Ressourcenlimits je Job (Zeit/Speicher/Seitenzahl) | Mittel | `FDN-11` |
|
||||
| 9 | Denial of Service | DOC-08 Archiv-Bündelung | Kein Limit für Gesamtgröße/Anzahl je Bündelungs-Anfrage | Niedrig | `DOC-18` |
|
||||
| 10 | Elevation of Privilege | INT-11/12/13 Modul-Registrierung | Rückkanäle (z. B. Workflow VOR-04) könnten Service-Credential-Kontext statt Nutzer-Tenant-Kontext verwenden | Hoch | `INT-16` |
|
||||
| 11 | Elevation of Privilege | DOC-02 Duplikat-Prüfung | Falls Hash-Abgleich global statt tenant-scoped implementiert wird: Seitenkanal-Leck über Duplikat-Treffer | Niedrig | Hinweis, Implementierungsdetail bei Umsetzung von DOC-02 explizit tenant-scoped halten |
|
||||
|
||||
### Bereits abgedeckt
|
||||
|
||||
- **Envelope-Encryption pro Objekt** (`FDN-09`) korrekt an Core-Schlüsselhierarchie (`API-10`) gekoppelt, keine eigene Master-Key-Logik im DMS.
|
||||
- **Tenant-Isolation strukturell** über Core Modell C — gilt auch hier.
|
||||
- **Duplikat-Erkennung/Checksum** (`DOC-02`) als bewusste Nutzerentscheidung statt automatischem Verwerfen.
|
||||
- **known-issues-archivdms.md** bereits als Vermeidungs-Checkliste im Board berücksichtigt (Rechte-Bug Ersteller-Sichtbarkeit, Superadmin-Sonderfall, Sprintf-in-SQL) — deshalb hier nicht erneut als Findings gelistet.
|
||||
|
||||
## 15. Threat Model: NEXARCH Mail (STRIDE)
|
||||
|
||||
Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Mail-Kanban (Ingestion & Protokoll-Server IMAP/POP3/SMTP, Postfach-Import, Archivierung, Suche & OCR, Integration/API), analysiert anhand der Ticket-Inhalte, nicht anhand des tatsächlichen Codes. Identity/Auth/RBAC/Tenancy sind nach Core ausgelagert (Abschnitt 13). Code-Wiederverwendung aus archivmail ist hier – anders als bei DMS – ausdrücklich erlaubt, daher liegt ein Schwerpunkt auf bekannten Altsystem-Bugs aus `known-issues-archivmail.md`. Alle Findings sind als Tickets in Welle 8 des Mail-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).
|
||||
|
||||
### Systemüberblick
|
||||
|
||||
```
|
||||
Externe Mailserver --IMAP/POP3/SMTP--> Ingestion-Server (ING-01..03, TLS/STARTTLS ING-06)
|
||||
|
|
||||
Import-Scheduler (IMP-01) --Anhänge--> Virenscan (IMP-06)
|
||||
|
|
||||
Archivierung (ARC-01, Objekt-Storage je Tenant-Bucket ARC-06)
|
||||
|
|
||||
Envelope-Encryption (ARC-02, DEK<-Tenant-KEK aus Core API-10)
|
||||
|
|
||||
Indexierung/OCR (SRC-02/SRC-07) --> Manticore-Index
|
||||
|
|
||||
Ausgehend: Mailer (ING-03) für Benachrichtigungen --> Core-Dispatcher (CFG-02)
|
||||
|
|
||||
Externe Ausgänge: Archive (INT-08 Retention), AI (INT-09), Workflow (INT-10)
|
||||
```
|
||||
|
||||
Trust-Boundaries: (1) Externer Mailserver→Ingestion-Server, (2) Ingestion→Import-Pipeline, (3) Import→Objekt-Storage, (4) Mail-API→Client, (5) Mail↔Archive/AI/Workflow (Modul-Registrierung), (6) Mailer→externe Empfänger (ausgehend).
|
||||
|
||||
### Findings
|
||||
|
||||
| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|
||||
|---|--------|------------|-----------|--------------|--------|
|
||||
| 1 | Tampering | ING-03 Mailer (ausgehend) | Header-Injection bei Stringkonkatenation von From/To/Subject — konkreter, bereits im archivmail-Altsystem aufgetretener Bug (known-issues Punkt 1) | Hoch | `ING-11` |
|
||||
| 2 | Elevation of Privilege | INT-08/09/10 Modul-Registrierung | Rückkanäle könnten Service-Credential-Kontext statt Nutzer-Tenant-Kontext verwenden (analog DMS-Finding) | Hoch | `INT-11` |
|
||||
| 3 | Information Disclosure | INT-01/ARC-01 Anhang-Download | Signierte URLs ohne festgelegten Scope/kurze TTL (analog DMS-Finding) | Mittel | `INT-12` |
|
||||
| 4 | Denial of Service | SRC-02/SRC-07 Indexierung/OCR | Keine Ressourcenlimits je Job (Zeit/Speicher/Seitenzahl), analog DMS-Finding | Mittel | `SRC-12` |
|
||||
| 5 | Denial of Service | ING-09 Rate-Limiting | Bereits abgedeckt — SMTP-Annahme und Login-Versuche rate-limitiert | Niedrig | abgedeckt |
|
||||
| 6 | Tampering | IMP-02/IMP-06 Anhang-Verarbeitung | Bereits abgedeckt — Virenscan mit Quarantäne vorgesehen (IMP-06), Größenlimit als Lehre aus archivmail (known-issues Punkt 3) im Board verankert | Niedrig | abgedeckt |
|
||||
| 7 | Information Disclosure | ARC-06 Objekt-Storage | Bereits abgedeckt — physische Mandantentrennung je Bucket/Pfad-Root statt Präfix-Konvention | Niedrig | abgedeckt |
|
||||
|
||||
### Bereits abgedeckt
|
||||
|
||||
- **Virenscan mit Quarantäne** (`IMP-06`) bereits im Board vorgesehen, nicht erst nachträglich als Finding nötig (anders als beim DMS-Board, wo dies fehlte).
|
||||
- **Physische Mandantentrennung im Objekt-Storage** (`ARC-06`) korrigiert das archivmail-Muster einer gemeinsamen Ablage mit Pfad-Präfix.
|
||||
- **Rate-Limiting auf Protokollebene** (`ING-09`) für SMTP-Annahme/Login bereits vorgesehen.
|
||||
- **TLS/STARTTLS verpflichtend** (`ING-06`) für alle drei Protokollserver.
|
||||
- **Signatur-Prüfung bei Archivierung mit Zeitstempel** (`ARC-10`) für S/MIME/PGP-signierte Mails nach BSI TR-03125.
|
||||
|
||||
## 16. Threat Model: NEXARCH Archive (STRIDE)
|
||||
|
||||
Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Archive-Kanban (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen) — die zentrale, alleinige Quelle für Aufbewahrung/WORM/Compliance/Backup für DMS und Mail. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 7 des Archive-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).
|
||||
|
||||
### Systemüberblick
|
||||
|
||||
```
|
||||
DMS/Mail --Registrierung (RET-05)--> Archive Retention-Engine (RET-01..03)
|
||||
|
|
||||
WORM-Speicherpfad (RET-04) --> Objekt-Storage
|
||||
|
|
||||
Löschworkflow mit Vier-Augen-Prinzip (CMP-06) / DSGVO-Löschantrag (CMP-07)
|
||||
|
|
||||
Compliance/eDiscovery-Export (CMP-01..03) --> Audit (Core AUD-01, CMP-04)
|
||||
|
|
||||
Backup: DB (BAK-01), Objekt-Storage (BAK-02) --> Restore-Test (BAK-06)
|
||||
```
|
||||
|
||||
Trust-Boundaries: (1) DMS/Mail→Archive (Registrierung, Service-Credentials), (2) Archive→Objekt-Storage (WORM), (3) Archive→Core-Audit-Log, (4) Backup-Ziel (extern/separates Speichersystem), (5) Restore-Testumgebung.
|
||||
|
||||
### Findings
|
||||
|
||||
| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|
||||
|---|--------|------------|-----------|--------------|--------|
|
||||
| 1 | Tampering | RET-04 WORM-Speicherpfad | "Kein Überschreiben" ggf. nur anwendungsseitig, nicht als Storage-Garantie (Object Lock) durchgesetzt | Hoch | `RET-11` |
|
||||
| 2 | Spoofing | RET-05 Registrierungsschnittstelle | Tenant-Kontext bei Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen | Hoch | `RET-12` |
|
||||
| 3 | Information Disclosure | BAK-01/BAK-02 Backup | Kein festgelegter Verschlüsselungsschutz für Backup-Snapshots — schwächeres Abbild derselben Daten als das Live-System | Mittel | `BAK-09` |
|
||||
| 4 | Information Disclosure | BAK-06 Restore-Testumgebung | Enthält echte wiederhergestellte Mandantendaten, Schutzniveau nicht festgelegt | Mittel | `BAK-10` |
|
||||
| 5 | Repudiation | RET-03/CMP-06 Löschworkflow | Bereits abgedeckt — Vier-Augen-Prinzip und Protokolleintrag vorgesehen, Legal Hold hat Vorrang | Niedrig | abgedeckt |
|
||||
| 6 | Tampering | CMP-03 eDiscovery-Export | Bereits abgedeckt — prüfsummengesicherter Export vorgesehen | Niedrig | abgedeckt |
|
||||
|
||||
### Bereits abgedeckt
|
||||
|
||||
- **Vier-Augen-Prinzip bei Löschung** (`CMP-06`) — positives Muster aus archivdms übernommen.
|
||||
- **Legal Hold hat Vorrang vor Fristablauf** (`RET-03`) — verhindert versehentliche Löschung bei laufendem Rechtsverfahren.
|
||||
- **DSGVO-Löschantrag mit Aufbewahrungs-Vorrangprüfung** (`CMP-07`) korrekt gegen `RET-03` abgegrenzt, keine zweite Lösch-Implementierung.
|
||||
- **Prüfsummengesicherter eDiscovery-Export** (`CMP-03`).
|
||||
- **Eigene, von Dokument-Retention unabhängige Backup-Prune-Policy** (`BAK-07`) — Backups laufen nicht unbegrenzt oder zu früh ab.
|
||||
|
||||
## 17. Threat Model: NEXARCH Workflow (STRIDE)
|
||||
|
||||
Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Workflow-Kanban (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang) — alleinige Quelle für Genehmigungsprozesse, Aufgaben/Fristen und Routing für DMS und Mail. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 8 des Workflow-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).
|
||||
|
||||
### Systemüberblick
|
||||
|
||||
```
|
||||
DMS/Mail --Push-Registrierung (ENG-02)--> Workflow-Engine (ENG-01, Zustandsautomat)
|
||||
|
|
||||
Genehmigungen (APR-01..04) / Aufgaben & Fristen (TSK-01..05)
|
||||
|
|
||||
Instanzschritt-Protokoll (ENG-04, unveränderlich)
|
||||
|
|
||||
Akte & Vorgang (VOR-01..03) <--Pull-Rückkanal (VOR-04)-- DMS/Mail
|
||||
|
|
||||
Regelbasiertes Routing (RTE-01..04) --optional-- KI-Vorschlag (AI WFS-02, RTE-05)
|
||||
```
|
||||
|
||||
Trust-Boundaries: (1) DMS/Mail→Workflow (Push-Registrierung, Service-Credentials), (2) DMS/Mail←Workflow (Pull-Rückkanal VOR-04), (3) Workflow→Core-Benachrichtigungs-Dispatcher, (4) Workflow→AI (optionaler KI-Vorschlag).
|
||||
|
||||
### Findings
|
||||
|
||||
| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|
||||
|---|--------|------------|-----------|--------------|--------|
|
||||
| 1 | Information Disclosure / Elevation of Privilege | VOR-04 Rückkanal-API | Kein festgelegter Tenant-Kontext-Abgleich bei Pull-Anfrage von DMS/Mail — Bypass der Mandantentrennung über den Rückkanal möglich | Hoch | `VOR-06` |
|
||||
| 2 | Spoofing | ENG-02 Registrierungsschnittstelle | Tenant-Kontext bei Push-Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen (analog Archive-Finding) | Mittel | `ENG-06` |
|
||||
| 3 | Repudiation | ENG-04 Instanzschritt-Protokoll | "Unveränderlich" nur konventionell, nicht technisch durchgesetzt (Analogie Core-Finding #5/DMS `VER-08`) | Mittel | `ENG-07` |
|
||||
| 4 | Elevation of Privilege | APR-02 Vier-Augen-Freigabe | Bereits abgedeckt — generisches, modulunabhängiges Vier-Augen-Muster vorgesehen | Niedrig | abgedeckt |
|
||||
| 5 | Elevation of Privilege | RTE-05 KI-Vorschlag im Routing | Bereits abgedeckt — KI liefert nur Vorschlag, regelbasierte Engine bleibt maßgebliche Entscheidungsinstanz | Niedrig | abgedeckt |
|
||||
|
||||
### Bereits abgedeckt
|
||||
|
||||
- **Vier-Augen-Prinzip für Freigaben** (`APR-02`) generisch und modulunabhängig konfigurierbar.
|
||||
- **KI bleibt Vorschlag, nie Entscheidung** (`RTE-05`) — verhindert stille Rechte-/Entscheidungsverlagerung an ein optionales KI-Modul.
|
||||
- **Vermerke unveränderlich nach Speichern** (`VOR-02`, Ergänzung statt Bearbeitung) — passendes Muster für Nachvollziehbarkeit, unabhängig vom technischen Append-only-Finding zu `ENG-04`.
|
||||
|
||||
## 18. Threat Model: NEXARCH AI (STRIDE)
|
||||
|
||||
Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: AI-Kanban (KI-Engine & Modell-Anbindung, Klassifizierung, Extraktion, Zusammenfassung, semantische Suche & Chat, Workflow-Vorschläge, Datenschutz & Governance) — alleinige Quelle für KI-Funktionen für DMS und Mail, optional aktivierbar über Core `LIC-02`. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 10 des AI-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).
|
||||
|
||||
### Systemüberblick
|
||||
|
||||
```
|
||||
DMS/Mail --Registrierung (GOV-01)--> AI-Governance
|
||||
|
|
||||
KI-Engine (ENG-01..06) --> Ollama (Standard) / externer Cloud-Adapter (ENG-03, optional)
|
||||
|
|
||||
Inferenz-Warteschlange (ENG-05) --> Klassifizierung/Extraktion/Zusammenfassung/SEM-Chat
|
||||
|
|
||||
Prompt-Injection-Härtung (GOV-06) / Audit-Protokollierung (GOV-05 -> Core AUD-01)
|
||||
|
|
||||
Workflow-Vorschläge (WFS-01..03) --> Workflow-Board (nur Vorschlag, keine Entscheidung)
|
||||
```
|
||||
|
||||
Trust-Boundaries: (1) DMS/Mail→AI (Registrierung, Service-Credentials), (2) AI→Ollama/externer Provider (ENG-03, ggf. Datenabfluss außerhalb der eigenen Infrastruktur), (3) Dokument-/Mailinhalt→Prompt (Prompt-Injection-Fläche), (4) AI→Core-Audit-Log, (5) AI→Workflow (Vorschlags-Rückkanal).
|
||||
|
||||
### Findings
|
||||
|
||||
| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|
||||
|---|--------|------------|-----------|--------------|--------|
|
||||
| 1 | Spoofing | GOV-01 Registrierungsschnittstelle | Tenant-Kontext bei Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen (analog Archive-/Workflow-Finding) | Mittel | `GOV-07` |
|
||||
| 2 | Denial of Service | ENG-05 Inferenz-Warteschlange | Keine Ressourcenlimits je Anfrage (Kontextlänge/Verarbeitungszeit) | Mittel | `ENG-07` |
|
||||
| 3 | Tampering | GOV-06 Prompt-Injection-Härtung | Bereits abgedeckt — strikte Trennung Systemanweisung/Nutzerinhalt, Schema-Validierung, Instruktions-Muster-Erkennung explizit vorgesehen | Niedrig | abgedeckt |
|
||||
| 4 | Repudiation | GOV-05 KI-Entscheidungsprotokoll | Bereits abgedeckt — Protokollierung über Core-Audit-Schnittstelle statt eigenem Log | Niedrig | abgedeckt |
|
||||
| 5 | Elevation of Privilege | WFS-02/03 Workflow-Vorschläge | Bereits abgedeckt — KI liefert nur Vorschlag, regelbasierte Workflow-Engine bleibt maßgebliche Entscheidungsinstanz (siehe Abschnitt 17) | Niedrig | abgedeckt |
|
||||
| 6 | Information Disclosure | ENG-03 externer Cloud-Adapter | Optionaler Datenabfluss an externen Anbieter — durch `GOV-03` (Steuerung lokal/extern je Tenant, Trainingsausschluss) technisch adressiert; DSGVO-Auftragsverarbeitungsvertrag mit externem Anbieter ist Vertragsthema, siehe `SAAS-BETRIEBSMODELL.md` Abschnitt 5a | Niedrig | organisatorisch geklärt (2026-09-14), kein Ticket |
|
||||
|
||||
### Bereits abgedeckt
|
||||
|
||||
- **Prompt-Injection-Härtung** (`GOV-06`) — ungewöhnlich vollständig für ein Planungsdokument: Trennung Systemanweisung/Inhalt, Schema-Validierung, Muster-Erkennung.
|
||||
- **KI-Entscheidungen vollständig auditierbar** (`GOV-05`) über die zentrale Core-Audit-Schnittstelle statt eigenem Log.
|
||||
- **Feingranulare Tenant-Steuerung** (`GOV-02`/`GOV-03`) für einzelne KI-Funktionen und lokal-vs-extern, mit explizitem Trainingsausschluss auf Kundendaten.
|
||||
- **Verbrauchsobergrenzen je Tenant** (`GOV-04`) gekoppelt an Core-Lizenzsteuerung — verhindert bereits einen Teil der Ressourcenerschöpfungs-Angriffsfläche auf Tenant-Ebene (ergänzt durch `ENG-07` auf Einzelanfrage-Ebene).
|
||||
- **Grounding mit Belegpflicht** (`SEM-04`/`SEM-05`) — keine Chat-Antwort ohne nachvollziehbare Quellenangabe.
|
||||
|
||||
## 19. Threat Model: NEXARCH Connect (STRIDE)
|
||||
|
||||
Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Connect-Kanban (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität) — baut vollständig auf Core auf, keine eigene API-Infrastruktur. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 7 des Connect-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea). Letztes der sieben Boards, das mit diesem Skill durchlaufen wurde — Abschnitte 13–19 decken jetzt alle NEXARCH-Boards ab.
|
||||
|
||||
### Systemüberblick
|
||||
|
||||
```
|
||||
Connector-Engine (ENG-01) --Plugin-Registrierung--> ERP/CRM (ERP-01..04), DATEV (DAT-01..03),
|
||||
M365 (M365-01..03), Andere-DMS (DMS2-01..03)
|
||||
|
|
||||
Zugangsdaten-Verwaltung (ENG-02) --verschlüsselt--> je Connector-Instanz
|
||||
|
|
||||
Sync-Jobs (ENG-03) --Fehlerbehandlung/Retry (ENG-05)--> Drittsystem
|
||||
|
|
||||
Alle Connector-Aktionen --> Core-Audit-Log (ENG-06)
|
||||
```
|
||||
|
||||
Trust-Boundaries: (1) NEXARCH↔Drittsystem (OAuth/API-Key, ausgehend), (2) Connector-Engine→Zugangsdaten-Speicher, (3) Sync-Job→Drittsystem (Netzwerk, außerhalb eigener Kontrolle), (4) Connect→Core-Audit-Log.
|
||||
|
||||
### Findings
|
||||
|
||||
| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|
||||
|---|--------|------------|-----------|--------------|--------|
|
||||
| 1 | Information Disclosure | ENG-02 Zugangsdaten-Verwaltung | Verschlüsselung ohne festgelegte Anbindung an die zentrale Tenant-KEK-Hierarchie — Risiko eines zweiten, separat zu härtenden Verschlüsselungspfads | Mittel | `ENG-07` |
|
||||
| 2 | Denial of Service | ENG-03/ENG-05 Sync-Jobs | Keine Obergrenzen für Laufzeit/Datenmenge je Sync-Lauf, Retry-Abbruchgrenze nicht technisch erzwungen | Mittel | `ENG-08` |
|
||||
| 3 | Repudiation | ENG-06 Audit-Kopplung | Bereits abgedeckt — alle Connector-Aktionen an Core-Audit-Log gekoppelt | Niedrig | abgedeckt |
|
||||
| 4 | Information Disclosure | DMS2-03 externe Backup-Ziele | Bereits abgedeckt — „verschlüsselter Export“ explizit vorgesehen | Niedrig | abgedeckt |
|
||||
|
||||
### Bereits abgedeckt
|
||||
|
||||
- **Alle Connector-Aktionen im Core-Audit-Log** (`ENG-06`) — Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert.
|
||||
- **Verschlüsselter Export zu externen Backup-Zielen** (`DMS2-03`).
|
||||
- **Keine eigene API-/Rate-Limiting-/Webhook-Infrastruktur** — vollständig auf Core aufgebaut, reduziert die Angriffsfläche gegenüber einer zweiten, parallelen Implementierung.
|
||||
- **LDAP/SSO bleibt Core-Sache** — Connect dupliziert keine Identitäts-Infrastruktur.
|
||||
@@ -1,154 +0,0 @@
|
||||
# NEXARCH 2.0 – Skalierungskonzept
|
||||
|
||||
Stand: 2026-08-26. Grundlage: `nexarch-state.json` (Techstack/Tenancy-Entscheidungen), `core-kanban/`, `archive-kanban/`, `dms-kanban/`, `mail-kanban/` (Boards inzwischen aus dem Repo entfernt, Ticket-Historie liegt in der Gitea-PR-Historie).
|
||||
|
||||
## 1. Was schon skalierungsfähig entschieden ist
|
||||
|
||||
| Baustein | Entscheidung | Warum das skaliert |
|
||||
|---|---|---|
|
||||
| Backend-Sprache | Go | Goroutinen billig, geringer RAM/Instanz, mehrere Prozesse pro Server möglich |
|
||||
| Auth | JWT, zustandslos | Beliebig viele Backend-Instanzen ohne Sticky-Sessions möglich |
|
||||
| Storage | S3-kompatible Abstraktion (FDN-03) | Objektspeicher skaliert unabhängig vom Backend, austauschbar (lokal → MinIO/S3) |
|
||||
| Job-Queue | Postgres, `FOR UPDATE SKIP LOCKED` (FDN-04) | Bewusst für mehrere Worker-Prozesse ausgelegt, nicht nur In-Prozess |
|
||||
| Rate-Limiting | Shared State statt in-process (Core API-03) | Korrigiert einen bei archivdms gefundenen Mehrinstanz-Bug (known-issues #9) |
|
||||
|
||||
Das deckt: **mehr Backend-Instanzen hinter einem Load Balancer** und **mehr Worker-Prozesse**. Es deckt NICHT: Datenbank-Skalierung, Caching, Kapazitätsgrenzen, Suchindex-Skalierung. Diese vier Lücken sind Gegenstand dieses Dokuments.
|
||||
|
||||
## 2. Skalierungsachsen
|
||||
|
||||
NEXARCH muss in vier unabhängigen Dimensionen wachsen können, die sich nicht gleich verhalten:
|
||||
|
||||
1. **Anzahl Tenants** (Mandanten) — wächst mit Kundenzahl, meist viele kleine.
|
||||
2. **Datenvolumen pro Tenant** (Dokumente, E-Mails, Anhänge) — wächst mit Nutzungsdauer, stark ungleich verteilt (ein Großkunde kann mehr Daten haben als 100 kleine zusammen).
|
||||
3. **Gleichzeitige Nutzer/Requests** — Lastspitzen (z.B. Monatsabschluss, Rechnungslauf-Import).
|
||||
4. **Hintergrundlast** (OCR, Indexierung, E-Mail-Abruf) — läuft unabhängig von Nutzeraktivität, oft nachts/batchartig.
|
||||
|
||||
Diese vier brauchen unterschiedliche Antworten — "mehr Server" allein löst nicht alle vier.
|
||||
|
||||
## 3. Betriebsstufen (an Master-Prompt orientiert)
|
||||
|
||||
### Stufe 1 – Einzel-LXC (kleine/mittlere Installation)
|
||||
```
|
||||
Proxmox LXC
|
||||
├── NEXARCH-Prozesse (Core/DMS/Mail/Archive/Workflow als ein oder mehrere Go-Binaries)
|
||||
├── Worker (In-Prozess-Goroutinen)
|
||||
├── PostgreSQL (lokal, eine Datenbank je Mandant plus schlanke Registry-DB — Modell C, siehe Abschnitt 4)
|
||||
├── Manticore (lokal)
|
||||
└── Objektspeicher (lokales Dateisystem oder ZFS)
|
||||
```
|
||||
Richtwert (grobe Schätzung, kein Lasttest): bis niedriger dreistelliger Tenant-Zahl bei üblicher KMU-Nutzung, solange kein Einzeltenant die Instanz dominiert. Grenze ist praktisch **immer die Postgres-Instanz und die OCR/Indexierungslast**, nicht der Go-Prozess selbst.
|
||||
|
||||
### Stufe 2 – Verteilt (mittlere/große Installation)
|
||||
```
|
||||
├── NEXARCH-Application-Instanzen (mehrere, hinter Reverse Proxy/Load Balancer, zustandslos)
|
||||
├── NEXARCH-Worker-Instanzen (mehrere, ziehen aus derselben Postgres-Jobqueue)
|
||||
├── PostgreSQL (dediziert, Tenant-Datenbanken über mehrere Server verteilbar — siehe Abschnitt 4)
|
||||
├── Manticore (dediziert, ggf. Cluster-Modus — siehe Abschnitt 5)
|
||||
└── Objektspeicher (S3/MinIO/Ceph, nicht mehr lokales Dateisystem)
|
||||
```
|
||||
Übergang Stufe 1 → 2 ist ein **reiner Infrastruktur-Schritt**, kein Code-Umbau — das ist der Grund, warum JWT-Auth, Postgres-Jobqueue und S3-Abstraktion von Anfang an so gewählt wurden (Abschnitt 1).
|
||||
|
||||
**Betriebs-Checkliste für diesen Wechsel:** `code/docs/BETRIEBS-CHECKLISTE-STUFENWECHSEL.md` (Core `OPS-07`). Enthält u. a. die mTLS-Aktivierung zwischen Modul-Instanzen (Core `API-09`) als Pflichtschritt — für Stufe 1 ist mTLS bewusst optional, beim Wechsel auf verteilten Betrieb aber zwingend, sonst laufen Modul-zu-Modul-Aufrufe ohne Transport-Authentifizierung. Ein Readiness-Gate (`internal/mtls.GateCheck` + `internal/health` Warnungen) macht ein vergessenes mTLS bei mehr als einer Instanz/mehr als einem Host als Warnung im Monitoring sichtbar, statt es unbemerkt zu lassen.
|
||||
|
||||
### Stufe 3 – Dedizierte Instanz pro Großkunde (Private Cloud, Betriebsmodell aus Master-Prompt)
|
||||
Ein Tenant mit außergewöhnlichem Datenvolumen oder Compliance-Anforderung bekommt eine eigene Stufe-1- oder Stufe-2-Installation statt eines Platzes auf der gemeinsamen Infrastruktur. Das ist die Antwort auf "was, wenn ein Mandant zu groß für die gemeinsame Instanz wird" (im Modell C liegt er bereits in einer eigenen Datenbank, hier zusätzlich auf eigener Hardware) — ein Ausweich-Betriebsmodell, das ohnehin schon geplant ist.
|
||||
|
||||
## 4. Datenbank-Skalierung — jetzt strukturell durch Modell C gelöst
|
||||
|
||||
**Geändert (siehe `nexarch-state.json` Entscheidungsverlauf):** Multi-Tenancy ist nicht mehr Modell A (eine Postgres-Instanz, `tenant_id`-Spalte), sondern **Modell C — eine Datenbank pro Mandant** (Core `TEN-01` Tenant-Registry & Datenbank-Provisioning). Grund: applikationsseitige Filterung verlässt sich darauf, dass jede Query korrekt gefiltert ist — ein einziger vergessener Filter (wie known-issues-archivmail.md #2/#7 real belegt) führt zum Cross-Tenant-Leck. Physische Trennung macht diese Fehlerklasse strukturell unmöglich, nicht nur unwahrscheinlicher. Nebeneffekt: eine Tenant-Datenbank lässt sich als Ganzes zwischen On-Premise und SaaS verschieben (Dump/Restore auf andere Infrastruktur), ohne Umbau an der Anwendung.
|
||||
|
||||
Das ändert die Skalierungsfrage von "eine Instanz größer machen" zu "viele kleine Instanzen gut verwalten":
|
||||
|
||||
**Verbindungs-Pooling ist ab Tag 1 Pflicht, nicht erst ab Stufe 2.**
|
||||
Mit vielen Tenant-Datenbanken stößt jede Anwendungsinstanz schnell an die maximale Postgres-Verbindungszahl, unabhängig von der eigentlichen Last. Core `TEN-06` (Connection-Routing & Pooling pro Mandant) übernimmt das — PgBouncer-artiges Pooling oder ein LRU-verwalteter Verbindungspool, der Tenant-Verbindungen wiederverwendet statt dauerhaft offen zu halten.
|
||||
|
||||
**Migrationen laufen gegen N Datenbanken, nicht gegen eine.**
|
||||
Core `TEN-07` (Migrations-Orchestrierung über alle Tenant-Datenbanken) rollt jede Schemaänderung automatisiert über alle Tenant-Datenbanken aus, mit Fehlerisolation je Mandant — ein inkompatibler Datenbestand bei einem Kunden darf das Ausrollen für alle anderen nicht blockieren.
|
||||
|
||||
**Vertikale Skalierung bleibt der Standardfall pro Postgres-Server**, der mehrere Tenant-Datenbanken hostet (Stufe 1: alle Tenant-DBs auf einer Instanz; Stufe 2/3: Tenant-Datenbanken auf mehrere Postgres-Server verteilt, siehe Abschnitt 3) — das ist kein Sharding-Zusatzaufwand mehr, sondern die natürliche Konsequenz von "jeder Mandant ist ohnehin schon eine eigene Datenbank".
|
||||
|
||||
**Was dadurch entfällt:** Die früher diskutierte Frage "Lesereplikate vs. RLS vs. Schema-pro-Tenant" stellt sich in dieser Form nicht mehr — RLS wäre bei physischer Trennung redundant (siehe Core `TEN-01`), und "Schema-pro-Tenant" (Modell B) ist mit Modell C bereits übertroffen (noch stärkere Isolation als ein gemeinsames Schema). Lesereplikate bleiben als Option pro einzelner Tenant-Datenbank sinnvoll, falls ein einzelner Großkunde das braucht — dann als individuelle Betriebsentscheidung für diese eine Datenbank, nicht als globale Architekturmaßnahme.
|
||||
|
||||
## 5. Suchindex-Skalierung
|
||||
|
||||
Manticore läuft in Stufe 1 lokal neben der Anwendung. In Stufe 2:
|
||||
- Manticore auf eigene Instanz(en) ziehen, mehrere NEXARCH-Instanzen sprechen dasselbe Manticore an.
|
||||
- Bei sehr großem Volumen: Manticore unterstützt Cluster-/Replikations-Modus — als Option dokumentieren, nicht in v1 vorwegnehmen (YAGNI, bis ein Tenant das tatsächlich braucht).
|
||||
- Reindexierung (siehe MIGRATIONSKONZEPT.md Abschnitt 4) ist selbst ein Lastfall — sollte außerhalb von Nutzungsspitzen laufen, Job-Priorität in der Postgres-Jobqueue berücksichtigen.
|
||||
|
||||
## 6. Caching
|
||||
|
||||
Aktuell **kein Caching-Layer vorgesehen** — bewusste Lücke, nicht übersehen: Redis wurde für Queue/Rate-Limit explizit ausgeschlossen (Einfachheit, ein Betriebsteil weniger). Für Caching gilt dieselbe Grundhaltung, aber nicht dieselbe Antwort:
|
||||
|
||||
- **Kein Cache für v1.** Postgres mit vernünftigen Indizes trägt die erwartete Last in Stufe 1/2.
|
||||
- **Wenn nötig:** In-Prozess-Cache (z.B. für Feature-Flags aus Core LIC-02, die sich selten ändern) statt eines externen Cache-Dienstes — passt zur "so wenig bewegliche Teile wie möglich"-Linie des Projekts.
|
||||
- **Erst bei nachgewiesenem Bedarf** einen externen Cache (Redis oder Postgres-UNLOGGED-Tabelle als Kompromiss) einführen, nicht vorab.
|
||||
|
||||
## 7. Hintergrundlast (OCR, Indexierung, E-Mail-Abruf)
|
||||
|
||||
Das ist die Last, die am wenigsten mit Nutzeraktivität korreliert und am leichtesten "einen Tenant die anderen ausbremsen lässt". Bereits im Datenmodell bedacht: die Postgres-Jobqueue aus archivdms (Vorbild für FDN-04) hat **Round-Robin-Fairness pro Mandant** eingebaut, genau um das zu verhindern — das ist eine reale Lehre aus dem Altsystem und sollte 1:1 in FDN-04 übernommen werden (ist es laut Ticket-Text bereits).
|
||||
|
||||
Für Stufe 2/3 zusätzlich:
|
||||
- Worker-Anzahl je Job-Typ getrennt konfigurierbar (OCR-Worker ≠ Indexierungs-Worker ≠ Mail-Abruf-Worker), damit ein Engpass in einem Typ nicht die anderen blockiert.
|
||||
- Quotas (Core LIC-03 Nutzungszähler) auch als Drosselungsmechanismus nutzen: ein Tenant mit ungewöhnlich hohem Job-Aufkommen bekommt eine Obergrenze, keinen unbegrenzten Vorrang.
|
||||
|
||||
## 8. Kapazitätsgrenzen — was bisher fehlt
|
||||
|
||||
Es gibt aktuell **keine dokumentierten Richtwerte**, ab wann Stufe 1 verlassen werden muss. Vorschlag, sobald erste Testinstallation läuft, folgende Kennzahlen zu erheben und hier nachzutragen:
|
||||
- Dokumente/E-Mails gesamt, ab denen Postgres-Query-Latenz spürbar steigt (typischer Auslöser: fehlende/veraltete Indizes eher als reines Volumen).
|
||||
- Gleichzeitige aktive Tenants, ab denen die In-Prozess-Job-Fairness (Abschnitt 7) nicht mehr ausreicht.
|
||||
- OCR-Durchsatz (Seiten/Minute) je Worker, um Personal-/Kapazitätsplanung für Kunden mit hohem Scan-Aufkommen zu ermöglichen.
|
||||
|
||||
Diese Zahlen sind aus der Architektur allein nicht seriös vorhersagbar — sie brauchen einen Lasttest (siehe DMS-Board `QA-10` Last- & Leistungstest, Mail-Board `QA-07`) und sollten aus dessen Ergebnis hierher zurückgeschrieben werden.
|
||||
|
||||
## 9. Monitoring-Kopplung
|
||||
|
||||
Skalierungsentscheidungen brauchen Messwerte, keine Vermutungen. Vorhandene Anknüpfungspunkte:
|
||||
- Core `OPS-01` Health-Checks je Modul, `OPS-03` Metrics-Aggregation über Module hinweg — sollte Postgres-Connection-Auslastung, Job-Queue-Länge je Tenant und Manticore-Latenz mit aufnehmen, nicht nur Modul-Health.
|
||||
- `grafana-expert`/`prometheus-expert`-Subagenten (siehe `.claude/agents/`) stehen für die konkrete Umsetzung bereit.
|
||||
|
||||
## 10. Core selbst hochverfügbar machen (Primary/Replica-Failover)
|
||||
|
||||
Abschnitt 11 beschreibt, wie die ANDEREN Module einen Core-Ausfall überstehen. Dieser Abschnitt beschreibt, wie Core selbst seltener ausfällt.
|
||||
|
||||
Core-Anwendungsprozesse sind bereits zustandslos (Abschnitt 1) — das löst die Anwendungsschicht: mehrere Core-Instanzen hinter einem Load Balancer, jede darf jederzeit neu starten oder wegfallen, ohne dass Sessions verloren gehen. **Der eigentliche Single Point of Failure ist die Postgres-Instanz**, auf der Core (wie alle Module) aufsetzt.
|
||||
|
||||
### Stufe 1 – Einzel-LXC: kein automatisches Failover
|
||||
Für kleine Installationen ist automatisches DB-Failover unverhältnismäßiger Aufwand. Antwort auf Ausfall ist Restore aus Backup (Archive-Board `BAK-03` Restore-Verfahren), keine Live-Umschaltung. Akzeptierter Trade-off, konsistent mit der "keine unnötige Komplexität"-Linie des Projekts.
|
||||
|
||||
### Stufe 2/3 – Primary/Replica mit automatischem Failover
|
||||
Sobald Verfügbarkeit über reinem Backup/Restore hinaus gefordert ist:
|
||||
|
||||
1. **Postgres-Streaming-Replikation**: ein Primary (Schreibziel), ein oder mehrere Replicas (physische Streaming-Replikation, nicht nur die logischen Read-Replicas aus Abschnitt 4 — hier geht es um Ausfallsicherheit, dort um Leselast-Verteilung; dieselbe Replica-Infrastruktur kann beides gleichzeitig bedienen).
|
||||
2. **Automatisches Failover braucht einen Konsens-Mechanismus**, nicht nur Replikation allein — sonst entscheidet im Zweifel niemand zuverlässig, wer nach einem Ausfall der neue Primary ist (Split-Brain-Risiko: zwei Knoten halten sich beide für Primary). Etablierter Ansatz: **Patroni** (nutzt etcd/Consul als verteilten Konsens-Store) oder das leichtgewichtigere **pg_auto_failover** (kommt ohne separaten Konsens-Store aus, dafür geringere Ausfalltoleranz bei komplexeren Szenarien). Für den Proxmox-LXC-Kontext des Projekts ist pg_auto_failover der pragmatischere Einstieg — Patroni erst, wenn Stufe 3 mit mehreren Standorten ansteht.
|
||||
3. **Verbindungsindirektion**: Core-Anwendungsinstanzen dürfen nicht die IP des Primary fest codieren — sonst bringt Failover nichts, weil alle Clients weiter den toten Knoten ansprechen. Lösung: PgBouncer/HAProxy mit Healthcheck auf den aktuellen Primary, oder eine virtuelle IP, die dem Failover-Mechanismus folgt. Das ist derselbe PgBouncer-Baustein wie in Abschnitt 4 Stufe C (Connection-Pooling) — ein Werkzeug, zwei Zwecke.
|
||||
4. **Fencing**: der alte Primary muss nach einem Failover zuverlässig daran gehindert werden, weiter Schreibzugriffe anzunehmen (sonst Split-Brain trotz Konsens-Mechanismus, z.B. bei Netzwerkpartitionierung). Patroni/pg_auto_failover übernehmen das, ist aber ein Punkt, der beim Aufsetzen bewusst getestet werden muss (simulierte Netzwerktrennung im Rahmen von DMS `QA-10`/Mail `QA-07`-artigen Lasttests), nicht nur beim Konfigurieren angenommen werden darf.
|
||||
|
||||
### Was NICHT dupliziert werden muss
|
||||
Der JWKS-Mechanismus aus Abschnitt 11/`API-05` (öffentlicher Schlüssel wird von anderen Modulen gecacht) bleibt unabhängig von einem laufenden DB-Failover funktionsfähig — Signaturprüfung anderer Module braucht während eines kurzen Failover-Fensters keine Core-DB-Verbindung. Das war kein bewusst für HA gedachtes Feature, ergibt sich aber als Nebeneffekt der API-05-Entscheidung: **Core-DB-Failover und Core-Anwendungs-Resilienz für andere Module sind zwei getrennte Probleme, die sich gegenseitig entlasten**, statt sich zu addieren.
|
||||
|
||||
### Storage- und Manticore-Redundanz
|
||||
Objektspeicher (S3-kompatibel) und Manticore-Suchindex haben ihre eigenen, produktüblichen Redundanzmechanismen (S3: providerseitig oder MinIO-Distributed-Mode; Manticore: Replikations-/Cluster-Modus, siehe Abschnitt 5) — kein Bezug zur Postgres-Failover-Frage, aber Teil desselben Gesamtbilds "was darf nicht Single Point of Failure sein", falls eine vollständige HA-Betrachtung für Stufe 3 gemacht wird.
|
||||
|
||||
## 11. Resilienz bei Core-Ausfall
|
||||
|
||||
Core ist Fundament (Auth, Rechte, Feature-Flags, Audit, Benachrichtigungen) — das darf nicht bedeuten, dass ein Core-Ausfall die ganze Plattform lahmlegt. Entscheidung: **lokale JWT-Verifikation + kurzlebiger Rechte-/Feature-Flag-Cache** statt synchroner Rückfrage bei Core pro Request (Core-Board-Ticket `API-05`).
|
||||
|
||||
- **DMS/Mail/Archive/Workflow prüfen JWT-Signatur lokal** (Core-Public-Key verteilt über JWKS-ähnlichen Mechanismus), kein Request an Core pro Aufruf.
|
||||
- **Rechte/Feature-Flags werden mit kurzer TTL gecacht.** Fällt Core aus: laufender Betrieb funktioniert mit letztbekanntem Stand weiter, nur neue Logins und frische Rechteänderungen sind betroffen — kein Komplettausfall der anderen Module.
|
||||
- **Fail-open vs. fail-closed muss pro Aktionsklasse entschieden werden** (Teil von `API-05`): Lesevorgänge mit abgelaufenem Cache eher fail-open (letzter bekannter Stand gilt weiter), sicherheitskritische Aktionen (Rechteänderung, Löschung, Freigabe) eher fail-closed (lieber verweigern als mit veralteten Rechten ausführen).
|
||||
- Schlüsselrotation für den Core-Public-Key muss ohne Ausfallzeit der anderen Module möglich sein — sonst wird die Resilienzmaßnahme selbst zum Wartungsrisiko.
|
||||
|
||||
Diese Entscheidung ist eine direkte Folge der bereits getroffenen JWT-Wahl (Abschnitt 1) — zustandslose Tokens waren dafür gedacht, wurden aber bis zu diesem Punkt nicht konsequent zu Ende gedacht (jedes Modul hätte genauso gut synchron gegen Core validieren können, was den Vorteil zunichtegemacht hätte).
|
||||
|
||||
## 12. Zusammenfassung: was zu tun bleibt
|
||||
|
||||
| Lücke | Vorschlag | Wo einzuordnen |
|
||||
|---|---|---|
|
||||
| Read-Replica-Trennung im Code | Query-Routing lesend/schreibend als eigenes Ticket | Core `API`- oder `OPS`-Epic (neu) |
|
||||
| Connection-Pooling (PgBouncer) | Betriebsempfehlung ab Stufe 2 | Core `FDN`/Deployment-Doku |
|
||||
| Kapazitätsrichtwerte | Aus Lasttest ableiten, hier nachtragen | nach DMS `QA-10` / Mail `QA-07` |
|
||||
| Manticore-Cluster-Modus | Nur bei nachgewiesenem Bedarf, nicht v1 | zukünftiges Ticket, kein Blocker |
|
||||
| Cache-Layer | Nur bei nachgewiesenem Bedarf, In-Prozess vor extern | zukünftiges Ticket, kein Blocker |
|
||||
|
||||
Kein neuer Techstack-Entscheid nötig — das Konzept baut ausschließlich auf bereits getroffenen Entscheidungen (Go, Postgres, S3, Manticore, Modell C) auf und beschreibt deren Wachstumspfad, statt sie zu ändern.
|
||||
@@ -1,165 +0,0 @@
|
||||
# NEXARCH 2.0 – Storage-Konzept
|
||||
|
||||
Stand: 2026-08-26, Abschnitt 9 aktualisiert + Abschnitt 10 neu (Arbeitsverzeichnisse) 2026-08-28. Grundlage: `dms-kanban/tickets/FDN-03.md`, `mail-kanban/tickets/ARC-01.md`, `archive-kanban/tickets/RET-*.md`, `archive-kanban/tickets/BAK-*.md`, `SKALIERUNGSKONZEPT.md` (Kanban-Boards inzwischen aus dem Repo entfernt, Ticket-Historie liegt in der Gitea-PR-Historie).
|
||||
|
||||
## 1. Grundprinzip
|
||||
|
||||
Strikte Trennung, bereits in FDN-03 (DMS) und ARC-01 (Mail) unabhängig, aber konsistent so entschieden:
|
||||
|
||||
- **PostgreSQL**: ausschließlich Metadaten (wer, was, wann, Tenant, Beziehungen, Status, Fristen).
|
||||
- **Objekt-Storage**: ausschließlich Binärinhalte (Dokumente, E-Mails, Anhänge, Thumbnails, Backups).
|
||||
|
||||
Kein Binärinhalt landet je in einer Datenbankspalte (kein `bytea` für Dateien) — das ist Bedingung für alles Weitere in diesem Dokument (Skalierung, Backup-Strategie, S3-Austauschbarkeit).
|
||||
|
||||
## 2. Backend-Optionen je Betriebsstufe
|
||||
|
||||
Deckt sich mit `SKALIERUNGSKONZEPT.md` Abschnitt 3:
|
||||
|
||||
| Betriebsstufe | Backend | Treiber |
|
||||
|---|---|---|
|
||||
| Stufe 1 (Einzel-LXC) | lokales Dateisystem oder ZFS | lokaler Treiber (FDN-03/ARC-01 "ein Interface, zwei austauschbare Treiber") |
|
||||
| Stufe 2 (verteilt) | S3-kompatibel: MinIO (selbst betrieben) oder Ceph (RADOS Gateway) | S3-Treiber, identische API wie Stufe 3 |
|
||||
| Stufe 3 (Private Cloud / SaaS) | S3-kompatibel: MinIO/Ceph selbst betrieben oder Managed-Object-Storage beim Provider | S3-Treiber, kein Unterschied im Code |
|
||||
|
||||
Der Übergang Stufe 1 → 2/3 ist ein reiner Infrastruktur-Schritt (Treiber-Konfiguration ändern, nicht Code), das war der explizite Zweck der Abstraktion. Datenübernahme beim Wechsel: einmaliger Kopiervorgang (z.B. `mc mirror` bei MinIO) mit anschließendem Prüfsummen-Abgleich (Abschnitt 6) — kein Big-Bang-Risiko wie bei der Systemmigration aus `MIGRATIONSKONZEPT.md`, da es dieselbe NEXARCH-Instanz ist, nur das Backend wechselt.
|
||||
|
||||
**Bewusst nicht vorgesehen:** NFS als produktives Ziel für Stufe 2/3 — das S3-Protokoll ist die gemeinsame Klammer, NFS wäre ein dritter, inkompatibler Zugriffspfad. NFS bleibt als Option für den lokalen Stufe-1-Treiber denkbar (Mount-Punkt statt echtes lokales Dateisystem), ändert aber nichts am Treiber-Interface.
|
||||
|
||||
## 3. Pfad-/Namenskonvention (modulübergreifend vereinheitlicht)
|
||||
|
||||
FDN-03 und ARC-01 legen je ihre eigene Pfadkonvention fest (Akzeptanzkriterium in beiden Tickets), bisher ohne geteilten Rahmen. Damit Backup (Archive `BAK-02`), Export (Archive `DMS2-01` im Connect-Board, DMS `DOC-08`) und Betrieb nicht drei verschiedene Konventionen lernen müssen, gilt projektweit ein gemeinsames Schema — und, analog zur Datenbank (Modell C, eigene Datenbank pro Mandant), jetzt auch eine physische Trennung im Objekt-Storage: **jeder Mandant erhält einen eigenen Bucket bzw. Pfad-Root**, statt eines gemeinsamen Buckets mit `tenant_id`-Pfadpräfix.
|
||||
|
||||
Begründung: physische Trennung schließt bei Objekt-Storage dieselbe Fehlerklasse aus wie bei der Datenbank — ein Codefehler ohne Tenant-Kontext kann kein fremdes Bucket erreichen, nicht nur einen falschen Pfad innerhalb eines gemeinsamen Buckets. Ein vergessener Pfadfilter/Präfix-Check in einem gemeinsamen Bucket führt zum Cross-Tenant-Leck; ein fehlendes Tenant-Bucket-Mapping führt dagegen nur dazu, dass gar kein Bucket referenzierbar ist.
|
||||
|
||||
Die Provisionierung des Tenant-Buckets ist Teil desselben Provisioning-Schritts wie die Anlage der Tenant-Datenbank in Core `TEN-01` — ein neuer Mandant erhält Datenbank und Bucket in einem automatisierten Schritt.
|
||||
|
||||
Innerhalb des Tenant-Buckets entfällt das führende `tenant_id`-Segment, das Schema wird zu:
|
||||
|
||||
```
|
||||
{modul}/{objekttyp}/{objekt_id}/{revision-oder-teil}
|
||||
```
|
||||
|
||||
Beispiele (innerhalb des Buckets von Mandant `t-4471`):
|
||||
- `dms/documents/doc-9021/rev-3.bin`
|
||||
- `mail/messages/msg-88213/part-2-attachment.bin`
|
||||
- `archive/backups/2026-08-26/snapshot.tar.zst`
|
||||
|
||||
Innerhalb des Pfads bleibt jedes Modul für sein `{objekttyp}`-Vokabular selbst zuständig (DMS: `documents`, `thumbnails`; Mail: `messages`, `attachments`) — nur die äußeren zwei Ebenen (`modul`/Rest) sind projektweit fix, damit ein Werkzeug (Backup, Export, Kapazitätsauswertung) modulübergreifend funktioniert, ohne pro Modul eine Sonderbehandlung zu brauchen. Die Mandantentrennung selbst (Bucket-Auswahl) ist damit kein Bestandteil des Pfadschemas mehr, sondern eine reine Provisioning-/Zugriffsschicht-Frage (siehe Ticket ARC-06, Mandantentrennung im Objekt-Storage; Kanban-Board inzwischen aus dem Repo entfernt, Historie in Gitea).
|
||||
|
||||
## 4. Verarbeitungsreihenfolge (Lebenszyklus einer Datei)
|
||||
|
||||
Zusammengeführt aus den bereits getroffenen Einzelentscheidungen (FDN-01/DOC-01/DOC-02/FDN-09 im DMS-Board, ARC-01/ARC-02/ARC-03 im Mail-Board):
|
||||
|
||||
```
|
||||
1. Empfang (Klartext, im Speicher/temporär)
|
||||
2. SHA-256-Hash auf Klartext
|
||||
3. Duplikatsprüfung (DOC-02 / ARC-03) — Gate: nur neue oder bewusste Duplikate gehen weiter
|
||||
4. Verschlüsselung at rest (FDN-09 / ARC-02, AES-256-GCM, Envelope Encryption)
|
||||
5. Ablage im Objekt-Storage nach Pfadkonvention (Abschnitt 3)
|
||||
6. Prüfsummenvergleich nach dem Schreiben (Akzeptanzkriterium in FDN-03/ARC-01)
|
||||
7. Registrierung bei Archive-Retention-Engine (RET-05 Modul-Adapter) — Aufbewahrungsfrist beginnt zu laufen
|
||||
8. OCR (SRC-05 / SRC-07) und Indexierung (SRC-02 / SRC-01+SRC-02) — läuft NACH Schritt 3, nicht parallel dazu
|
||||
```
|
||||
|
||||
Löschung läuft ausschließlich über die Archive-Engine (Retention/Legal-Hold-geprüft), niemals direkt durch DMS oder Mail — das ist bereits Konsequenz der Archive-Konsolidierung, hier nur noch einmal aus Storage-Sicht festgehalten: kein Modul löscht Objekte eigenständig aus dem Storage.
|
||||
|
||||
## 5. Zugriffsmodell
|
||||
|
||||
- **Kein direkter Client-Zugriff auf den Objekt-Storage.** Up-/Downloads laufen über zeitlich begrenzte signierte URLs (FDN-03 Akzeptanzkriterium 2, Standard-Pattern für S3-kompatible Backends), die das Backend ausstellt — Storage-Zugangsdaten selbst erreichen nie den Browser.
|
||||
- Presigned-URL-Gültigkeit kurz und konfigurierbar halten (Minuten, nicht Stunden) — lange gültige URLs sind ein unnötig großes Zeitfenster für Linkweitergabe.
|
||||
- Storage-Zugangsdaten (S3-Credentials) sind Secrets wie jedes andere — ausschließlich über Umgebungsvariablen, nie im Code (bereits projektweite Regel aus jedem Ticket-Abschluss-Abschnitt).
|
||||
|
||||
## 6. Konsistenzprüfung
|
||||
|
||||
Jeder Schreibvorgang wird durch Prüfsummenvergleich verifiziert (bestehende Akzeptanzkriterien in FDN-03 und ARC-01). Für den Bestand insgesamt zusätzlich:
|
||||
|
||||
- **Reconciliation** (Archive `BAK-05`): periodischer Abgleich zwischen den in Postgres referenzierten Objekten und dem tatsächlichen Storage-Inhalt — erkennt verwaiste Metadaten-Einträge (Objekt fehlt im Storage) und verwaiste Storage-Objekte (kein Metadaten-Eintrag mehr, z.B. nach einem Fehler bei Schritt 5/6 aus Abschnitt 4).
|
||||
- Reale Lehre aus archivmail: Reconciliation-Reports existierten dort bereits als Soll/Ist-Abgleich (siehe `datenmodell-altsysteme.md`) — Muster wird über Archive `BAK-05` fortgeführt, nicht neu erfunden.
|
||||
- **Integritätsprüfung per Hash** (Archive `BAK-08`): periodischer Scrub-Job, der Stichproben liest, SHA-256 neu berechnet und gegen `file_revisions.checksum_sha256` vergleicht — erkennt stille Inhaltsveränderung/Bit-Rot bei Objekten, die noch existieren.
|
||||
|
||||
### 6.1 Grenzen der Prüfung bei extern eingebundenem Kunden-Storage
|
||||
|
||||
Bindet ein Kunde einen eigenen S3-Bucket ein, überwachen wir weder dessen Hardware noch dessen Betreiber. Was NEXARCH technisch leisten kann, hängt davon ab, was wir dürfen:
|
||||
|
||||
- **Kein Lesezugriff, nur Schreiben:** keine Verifikation möglich. Wir können höchstens den Upload-Beleg und den Hash zum Upload-Zeitpunkt festhalten — das ist kein Monitoring, sondern ein Nachweis für später.
|
||||
- **Lese-/API-Zugriff vorhanden:** Existenz- (`BAK-05`) und Inhaltsprüfung (`BAK-08`) sind möglich, aber periodisch/stichprobenhaft, nicht in Echtzeit, und nur für das, was wir selbst wieder lesen können.
|
||||
|
||||
Was diese beiden Prüfungen NICHT leisten:
|
||||
|
||||
- Sie erkennen nicht lückenlos, ob ein Objekt unbefugt gelöscht oder durch ein neues ersetzt wurde, wenn uns keine Inventar-/Versionsdaten vom Storage vorliegen (ETag/LastModified/VersionId — sofern verfügbar, nicht überall ein einfacher Hash, besonders bei Multipart-Uploads oder providerseitiger Verschlüsselung, daher nicht als alleinige Wahrheitsquelle nehmen).
|
||||
- Sie ersetzen keine storage-seitige WORM-/Versionierungsstrategie und keine Zugriffs-/Audit-Logs des Storage-Providers — nur Object Lock, Versioning, Retention Policies und providerseitige Audit-Logs verhindern Veränderungen oder machen sie lückenlos nachweisbar, ein nachträglicher Scrub kann sie nur *bemerken*, nicht verhindern.
|
||||
|
||||
### 6.2 Drei Betriebsmodi für Objekt-Storage
|
||||
|
||||
1. **NEXARCH-managed Storage** — wir kontrollieren Policies, Versioning, Object Lock, Backup vollständig.
|
||||
2. **Customer-managed, compliant Storage** — Kunde stellt den S3-Bucket, aber vertraglich/beim Onboarding verbindlich verlangt: Versioning aktiviert, Object Lock/Retention bei revisionssicherer Nutzung, Audit-Logs aktiviert, eingeschränkte Löschrechte, idealerweise eigener Backup-/Replikationspfad.
|
||||
3. **Customer-managed, non-compliant Storage** — nur für nicht revisionssichere Nutzung zulässig; muss im System klar markiert sein ("keine belastbare Unveränderbarkeitsgarantie"), damit keine falsche GoBD-Erwartung entsteht.
|
||||
|
||||
## 7. Backup vs. Storage-Redundanz — zwei verschiedene Schichten
|
||||
|
||||
Häufige Verwechslung, deshalb hier explizit getrennt:
|
||||
|
||||
- **Storage-Redundanz** (diese Datei, Abschnitt 2): wie das Backend selbst Datenverlust durch Hardware-Ausfall verhindert (S3-Provider-Redundanz, MinIO-Distributed-Mode, Ceph-Replikation). Schützt vor Festplatten-/Knotenausfall, NICHT vor Anwendungsfehlern oder böswilligem/versehentlichem Löschen.
|
||||
- **Backup** (Archive `BAK-01`/`BAK-02`/`BAK-03`): eigenständige, deduplizierende Sicherung nach restic/Borg-Konzept, zeitversetzt, wiederherstellbar auch wenn die Primärkopie durch einen Anwendungsfehler beschädigt wurde. Das ist die Antwort auf "ein Bug löscht fälschlich Dateien" — Storage-Redundanz allein hilft dabei nicht, weil sie den fehlerhaften Löschvorgang originalgetreu mit-repliziert.
|
||||
|
||||
Beide Schichten sind nötig, keine ersetzt die andere.
|
||||
|
||||
## 8. Export & Portabilität
|
||||
|
||||
Aus der DMS-Produkt-DNA fortgeführt (ecoDMS-Lehre: "was die Oberfläche kann, kann auch die offene Schnittstelle", keine Herstellerbindung):
|
||||
|
||||
- Vollständiger Export von Dateiinhalt + Metadaten ohne NEXARCH-eigenes Werkzeug muss jederzeit möglich sein (DMS `DOC-08` Massenexport, Mail `ARC-07` Export/Portabilität, Connect `DMS2-01` offenes Austauschformat für Fremd-DMS-Interoperabilität).
|
||||
- Objekt-Storage-Ablage selbst nutzt offene Formate (Original-Dateiformat + PDF/A für OCR-Ergebnisse, kein proprietäres Container-Format) — keine Vendor-Lock-Kodierung, die einen Export nachträglich erschweren würde.
|
||||
|
||||
## 9. Speicherverbrauch-Messung für Quota/Lizenzierung
|
||||
|
||||
~~Offene Lücke~~ — **geklärt (2026-08-28)**: Core `LIC-05` "Speicherverbrauch-Metrik je Tenant" setzt genau den hier vorgeschlagenen Mechanismus um — Objekt-Storage-Treiber der Module (FDN-03/ARC-01) melden bei jedem Schreib-/Löschvorgang die Objektgröße, ein leichtgewichtiger Postgres-Zähler pro Tenant wird geführt, `LIC-03` fragt ihn zur Quota-Durchsetzung ab. `LIC-05` hängt im Core-Abschluss-Gate `QA-05`.
|
||||
|
||||
## 10. Arbeitsverzeichnisse (Consume, Quarantäne, Export-Staging, Modell-Cache)
|
||||
|
||||
Ergänzung 2026-08-28, angestoßen durch den Vergleich mit paperless-ngx (`consume/`, `data/`, `media/`, `export/`, `trash/`) — mehrere Tickets definieren Funktionalität, die einen lokalen Arbeitsordner braucht, legen aber bisher nicht fest, WO dieser liegt. Papierkorb (DMS `DOC-11`/`DOC-12`, Mail `ARC-05`) braucht dagegen **keinen** eigenen Pfad — das ist ein reines DB-Status-Flag, das Objekt bleibt physisch am gewohnten Platz im Objekt-Storage, bis Archive es nach Fristablauf endgültig entfernt.
|
||||
|
||||
### 10.1 Consume-/Hot-Folder (DMS `INT-06`/`INT-08`, Mail `IMP-05`)
|
||||
|
||||
Anders als der reguläre Objekt-Storage-Zugriff (Abschnitt 2, ausschließlich über signierte URLs, Abschnitt 5) braucht ein Datei-Watch zwingend ein echtes lokales Dateisystemverzeichnis — S3-kompatible Backends unterstützen kein Datei-Watch. Konsequenz: Consume-Ordner sind **kein Teil des Tenant-Objekt-Storage-Buckets**, sondern ein separater, lokaler Zwischenspeicher je Tenant auf dem Modul-Host:
|
||||
|
||||
```
|
||||
{consume-root}/{tenant_id}/dms/inbox/
|
||||
{consume-root}/{tenant_id}/mail/inbox/
|
||||
```
|
||||
|
||||
Nach erfolgreicher Verarbeitung (Hash, Duplikatsprüfung, Verschlüsselung, Ablage im Objekt-Storage — Abschnitt 4) wird die Datei aus dem Consume-Ordner entfernt, nicht dauerhaft dort belassen. Consume-Root ist damit strukturell näher an einem Cache als an Aufbewahrung und braucht keine Backup-Einbindung (Abschnitt 7) — im Fehlerfall wird die Quelle erneut abgelegt/gescannt.
|
||||
|
||||
### 10.2 Quarantäne (Mail `IMP-06` Virenscan-Fund)
|
||||
|
||||
Bei Virenscan-Fund wird die Anhang-Datei nicht gelöscht, sondern in einen isolierten Quarantäne-Bereich verschoben (Nachvollziehbarkeit, siehe Compliance-Anforderung) — ebenfalls lokal, ebenfalls je Tenant:
|
||||
|
||||
```
|
||||
{consume-root}/{tenant_id}/mail/quarantine/
|
||||
```
|
||||
|
||||
Quarantäne-Objekte werden nicht automatisch gelöscht; Aufbewahrungsdauer und Zugriff (nur Admin/Security-Rolle) sind Akzeptanzkriterium von `IMP-06`, nicht Gegenstand dieses Dokuments.
|
||||
|
||||
### 10.3 Export-Staging (DMS `DOC-08`, Mail `ARC-07`)
|
||||
|
||||
Massenexport (ZIP) erzeugt eine temporäre Datei zwischen "Export angestoßen" und "Download abgeschlossen". Diese Staging-Fläche ist rein ephemer (Lebensdauer im Bereich von Minuten bis wenigen Stunden), braucht keine Tenant-Bucket-Struktur und keine Backup-Einbindung:
|
||||
|
||||
```
|
||||
{export-staging-root}/{tenant_id}/{export_job_id}.zip
|
||||
```
|
||||
|
||||
Aufräumung nach Ablauf einer kurzen Frist (Vorschlag: 24 Stunden) oder nach bestätigtem Download ist Akzeptanzkriterium der jeweiligen Export-Kachel.
|
||||
|
||||
### 10.4 Ollama-Modell-Cache (AI `ENG-02`)
|
||||
|
||||
Bisher nicht adressierte Lücke: `ENG-02` (Ollama-Adapter) lädt und hält LLM-Modellgewichte lokal vor — je nach Modellklasse mehrere GB bis über 40 GB (siehe `PROXMOX-DEPLOYMENT.md` Abschnitt 6a, dort nur RAM-Sizing, keine Disk-Planung). Anders als Consume/Quarantäne/Export ist das **kein Zwischenspeicher, sondern persistenter, potenziell großer Datenbestand**, der eine eigene Kapazitätsplanung braucht, getrennt vom restlichen Objekt-Storage:
|
||||
|
||||
```
|
||||
{ollama-root}/models/
|
||||
```
|
||||
|
||||
Nicht tenant-partitioniert (Modelle werden über Tenants hinweg geteilt, sofern keine Tenant-spezifische Modellwahl vorliegt — siehe AI `ENG-04`). Bei Stufe-1-Einzel-LXC (siehe `PROXMOX-DEPLOYMENT.md` Abschnitt 2) sollte dieser Pfad auf ein eigenes Volume/Dataset gelegt werden, damit ein wachsender Modellbestand nicht den restlichen Systemspeicher verdrängt — gleiches Isolationsprinzip wie bei Tenant-Buckets (Abschnitt 3), nur nicht tenant-, sondern funktionsbezogen.
|
||||
|
||||
### 10.5 Warum eigene Datasets/Mountpoints sinnvoll sind
|
||||
|
||||
Alle vier Arbeitsverzeichnisse (10.1–10.4) profitieren aus demselben Grund von eigenen ZFS-Datasets/Mountpoints statt Unterordnern im Root-Dateisystem: unabhängige Quotas (ein vollaufender Consume-Ordner darf nicht das Systemvolume fluten), unabhängige Snapshots/Löschbarkeit (siehe Erfahrung mit `archivmail`-Alt-Deinstallation, `nexarch-state.json` Entscheidungsverlauf 2026-08-28), und die Möglichkeit, unterschiedliche Backup-/Retention-Policies zuzuweisen (Consume/Export brauchen keine, Modell-Cache profitiert von keiner inkrementellen Sicherung großer Binärdateien, sondern von einfacher Neubeschaffung bei Bedarf).
|
||||
@@ -1,54 +0,0 @@
|
||||
# NEXARCH 2.0 – UI/UX-Konzept
|
||||
|
||||
Stand: 2026-08-28 (Abschnitt 4/6 aktualisiert). Grundlage: Core `SHL-01` (UI-Shell & Design-System, zentral), `PRODUKTARCHITEKTUR.md`, alle Oberflächen-Tickets über sieben Boards.
|
||||
|
||||
## 1. Grundprinzip: eine Shell, sieben Module
|
||||
|
||||
`SHL-01` (Core) ist die alleinige Quelle für Layout-Shell, Basis-Komponenten (Tabelle, Dialog, Formularelemente, Toast) und Design-Tokens (Farbe, Abstand, Typografie). Jedes Fachmodul baut seine eigenen Oberflächen darauf auf, aber keines definiert eigene Tokens oder eigene Basis-Komponenten — das war bis zur Konsolidierung (siehe `nexarch-state.json` → `konsolidierungen_durchgefuehrt`) nicht sichergestellt, DMS hätte sonst die einzige Shell gehabt und alle anderen sechs Boards hätten sie kopiert oder wären visuell inkonsistent geblieben.
|
||||
|
||||
**Test für "gehört das in SHL-01 oder ins Modul":** Würde eine zweite, unabhängige Implementierung zum selben Ergebnis kommen müssen, damit NEXARCH wie ein Produkt aussieht (Button-Stil, Abstand, Farbpalette)? Dann Core. Ist es fachlich spezifisch für ein Modul (PDF-Viewer, Postfach-Ansicht, Genehmigungs-Ansicht)? Dann das jeweilige Board.
|
||||
|
||||
## 2. Navigationsmodell
|
||||
|
||||
Aus dem Master-Prompt-Ziel "modulare Oberfläche, Benutzer sehen nur Module für die sie Berechtigung haben" — technisch bereits durch Core `LIC-02` (Feature-Flags je Tenant) und `RBAC-01..04` (Rollen/Rechte) unterlegt:
|
||||
|
||||
- **Globale Navigation** (Teil von `SHL-01`): Modul-Umschalter, sichtbar nur für aktivierte + berechtigte Module. Kein Modul zeigt sich selbst an, wenn Core es für den aktuellen Tenant/Benutzer nicht freigibt — das ist dieselbe Backend-seitige Durchsetzungspflicht aus dem Master-Prompt ("Aktivierung darf nicht nur UI-seitig erfolgen"), hier auf die Navigationsebene angewendet: die UI blendet aus, was das Backend ohnehin verweigern würde, nicht umgekehrt als alleiniger Schutzmechanismus.
|
||||
- **Modul-interne Navigation**: jedes Fachmodul definiert seine eigene zweite Ebene (DMS: Dokumente/Ordner/Papierkorb; Mail: Postfächer/Suche; Workflow: Aufgaben/Akten/Genehmigungen) — eigenständig, aber visuell aus denselben Shell-Komponenten.
|
||||
- **Globale Suche**: im Master-Prompt gefordert, aktuell technisch NICHT als eigenes Ticket vorhanden — siehe Abschnitt 6 (offener Punkt). Die Suche existiert bisher nur je Modul (DMS `SRC-*`, Mail `SRC-*`, bewusst nicht zentralisiert, siehe `nexarch-state.json` → `bewusst_nicht_zentralisiert`), aber eine modulübergreifende Ergebnisliste in EINER Suchleiste ist etwas anderes als ein gemeinsamer Suchindex und wurde bisher nicht bedacht.
|
||||
|
||||
## 3. Dashboard & Benutzer-/Tenant-Kontext
|
||||
|
||||
- Tenant-Kontext global sichtbar (welcher Mandant ist aktiv, bei Mehrfachzugehörigkeit umschaltbar) — gehört in `SHL-01`, da jedes Modul denselben Tenant-Kontext braucht, nicht nur eines.
|
||||
- Ein Landing-Dashboard nach Login existiert bisher nur in Einzelteilen: Core `OPS-02` (zentrale Statusseite, eher Admin-/Betriebssicht als Nutzer-Dashboard), Archive `ANA-02` (Auswertungs-Dashboard, Kennzahlen-fokussiert), Mail/DMS haben kein eigenes Startseiten-Ticket. Kein Ticket bündelt bisher "was sieht ein normaler Benutzer beim ersten Login" — siehe Abschnitt 6.
|
||||
|
||||
## 4. Responsive, Theming, Sprache, Barrierefreiheit — zentral in SHL-01 verankert
|
||||
|
||||
Update 2026-08-28: WCAG 2.1 AA, i18n-Rahmen (mind. Deutsch/Englisch) und Theming (Hell/Dunkel) sind jetzt verbindliche, in `SHL-01` verankerte Eigenschaften des Design-Systems (Akzeptanzkriterien 4-6, Prüfungen 5-6) — kein modulweiser Einzelfall mehr. Alle Frontend-Kacheln über alle 7 Boards (Core, DMS, Mail, Archive, Workflow, AI, Connect) hängen jetzt in `dependsOn` von `SHL-01` ab und erben diese Eigenschaften strukturell. Zusätzlich existiert je Board ein Barrierefreiheits-Audit-Gate im Abschluss-Gate: DMS `QA-11`, Mail `QA-08`, Core `QA-09`, Workflow `QA-08`, AI `QA-09`, Connect `QA-08` (Archive hat aktuell keine eigene Frontend-Kachel, daher kein Audit nötig).
|
||||
|
||||
- **Theming**: Design-Tokens aus `SHL-01` sind die einzige Quelle für Hell/Dunkel-Werte, jetzt mit explizitem Akzeptanzkriterium und Prüfung ("Umschaltung Hell/Dunkel an einer Beispielkomponente ohne Layoutbruch") statt implizit über Breakpoint-Tokens.
|
||||
- **Mehrsprachigkeit**: DMS `UX-03`/`UX-04` bleiben das einzige Board mit eigenem, ausführlichem i18n-Ticket (Infrastruktur + tatsächliche DE/EN-Übersetzungen der Inhalte) — das war weiterhin richtig so, denn `SHL-01` liefert nur den *Rahmen* (Sprachumschaltung, Übersetzungsmechanismus für Basis-Komponenten), nicht die modul-eigenen Textbausteine. Jedes Modul bindet seine Übersetzungen über den SHL-01-Rahmen ein, statt einen eigenen Mechanismus zu bauen.
|
||||
- **Barrierefreiheit**: WCAG 2.1 AA ist jetzt in jedem der 7 Boards durch ein Audit-Gate abgesichert, nicht nur DMS/Mail wie zuvor. `SHL-01`s Akzeptanzkriterien 1 und 4 ("Kontrastwerte erfüllen mindestens AA" / "Basis-Komponenten erfüllen WCAG 2.1 AA als Grundeigenschaft") sind die gemeinsame Grundlage, auf der alle sechs Audit-Gates aufbauen.
|
||||
|
||||
## 5. Prinzipien aus dem Master-Prompt, konkret zugeordnet
|
||||
|
||||
| Master-Prompt-Ziel | Wo umgesetzt |
|
||||
|---|---|
|
||||
| Übersichtlich, schnell | `SHL-01` Basis-Komponenten, keine schwere Anwendungsserver-Startzeit (Produkt-DNA-Linie aus allen Boards: "kein Alfresco-Overhead") |
|
||||
| Responsive, Desktop und Tablet | DMS `UX-01`, Mail `UX-04`, Design-Tokens/Breakpoints in `SHL-01` |
|
||||
| Moderne Navigation | Abschnitt 2 dieses Dokuments |
|
||||
| Modulare Oberfläche | Sieben-Boards-Architektur selbst (`PRODUKTARCHITEKTUR.md` Abschnitt 2) |
|
||||
| Globale Suche | **offen**, siehe Abschnitt 6 |
|
||||
| Dashboard | **teilweise offen**, siehe Abschnitt 6 |
|
||||
| Benutzer-/Tenant-Kontext | Abschnitt 3 |
|
||||
| Klare Workflows | Workflow-Board (Genehmigungen, Aufgaben, Akte) + dessen UI-Tickets (`APR-03`, `TSK-04`, `RTE-03`, `VOR-05`) |
|
||||
| Nur berechtigte Module sichtbar | Abschnitt 2, Core `LIC-02`/`RBAC-*` |
|
||||
|
||||
## 6. Offene Punkte
|
||||
|
||||
- **Globale, modulübergreifende Suche**: keine Ausgangslage-Referenz in irgendeinem Board deutet auf eine gemeinsame Sucheingabe hin, die Ergebnisse aus DMS UND Mail UND Workflow-Akten gleichzeitig anzeigt. Die einzelnen Suchindizes bleiben bewusst getrennt (Entscheidung bereits getroffen) — aber eine gemeinsame Such-UI-Schicht, die mehrere modul-eigene Such-APIs parallel abfragt und zusammenführt, ist etwas anderes und wurde bisher nicht geplant.
|
||||
- **Zentrales Nutzer-Dashboard nach Login**: existiert nur fragmentiert (Statusseite = Admin-Sicht, Auswertungs-Dashboard = Kennzahlen-Sicht). Kein Ticket für "was sieht eine normale Sachbearbeiterin direkt nach dem Einloggen" (offene Wiedervorlagen, neue Mails, zugewiesene Aufgaben aus mehreren Modulen gebündelt).
|
||||
- **Kein UI-Prototyp/Mockup vorhanden**: dieses Dokument beschreibt Prinzipien und Zuständigkeiten, keine tatsächlichen Bildschirmentwürfe — die entstehen erst in der Umsetzung der einzelnen Oberflächen-Tickets.
|
||||
|
||||
Erledigt seit Stand 2026-08-26 (nicht mehr offen): Mehrsprachigkeits-Infrastruktur war unentschieden zwischen Zentralisierung und Pro-Modul-Wiederholung — inzwischen entschieden: `SHL-01` liefert den zentralen i18n-*Rahmen* (Umschaltmechanismus), DMS `UX-03`/`UX-04` bleibt bewusst das einzige Board mit vollständiger Übersetzungsarbeit, da Textbausteine modul-eigen sind (siehe Abschnitt 4). WCAG/Theming-Uneinheitlichkeit über die Boards ebenfalls behoben, siehe Abschnitt 4.
|
||||
|
||||
Rückfrage an dich: sollen globale Suche und zentrales Dashboard als neue Tickets ergänzt werden (vermutlich beide in Core `SHL`-Epic, da modulübergreifend), oder bleibt das für später zurückgestellt?
|
||||
+10
-28
@@ -27,8 +27,6 @@ import (
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/extractvalidate"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/invoiceextract"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/metadatapushclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/moduletype"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/moduletypeapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider/ollama"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/queue"
|
||||
@@ -43,7 +41,6 @@ import (
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/summaryapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/threadsummarize"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/vectorindex"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/tenantregistryclient"
|
||||
)
|
||||
|
||||
const workerPollInterval = 2 * time.Second
|
||||
@@ -52,13 +49,11 @@ const defaultListenAddr = "127.0.0.1:9600"
|
||||
const defaultModel = "default"
|
||||
|
||||
type config struct {
|
||||
dsn string
|
||||
serviceToken string
|
||||
addr string
|
||||
model string
|
||||
moduleURLs map[string]string
|
||||
coreBaseURL string
|
||||
coreServiceToken string
|
||||
dsn string
|
||||
serviceToken string
|
||||
addr string
|
||||
model string
|
||||
moduleURLs map[string]string
|
||||
}
|
||||
|
||||
// parseModuleBaseURLs liest "modul=url,modul2=url2" (EXT-05: je Modul eine
|
||||
@@ -84,13 +79,11 @@ func parseModuleBaseURLs(raw string) map[string]string {
|
||||
// Programmabbruchs weiter unten im Code.
|
||||
func loadConfig(getenv func(string) string) (config, error) {
|
||||
cfg := config{
|
||||
dsn: getenv("NEXARCH_AI_APP_TENANT_DSN"),
|
||||
serviceToken: getenv("NEXARCH_AI_APP_SERVICE_TOKEN"),
|
||||
addr: getenv("NEXARCH_AI_APP_LISTEN_ADDR"),
|
||||
model: getenv("NEXARCH_AI_APP_MODEL"),
|
||||
moduleURLs: parseModuleBaseURLs(getenv("NEXARCH_AI_APP_MODULE_BASE_URLS")),
|
||||
coreBaseURL: getenv("NEXARCH_AI_APP_CORE_BASE_URL"),
|
||||
coreServiceToken: getenv("NEXARCH_AI_APP_CORE_SERVICE_TOKEN"),
|
||||
dsn: getenv("NEXARCH_AI_APP_TENANT_DSN"),
|
||||
serviceToken: getenv("NEXARCH_AI_APP_SERVICE_TOKEN"),
|
||||
addr: getenv("NEXARCH_AI_APP_LISTEN_ADDR"),
|
||||
model: getenv("NEXARCH_AI_APP_MODEL"),
|
||||
moduleURLs: parseModuleBaseURLs(getenv("NEXARCH_AI_APP_MODULE_BASE_URLS")),
|
||||
}
|
||||
if cfg.dsn == "" {
|
||||
return config{}, errors.New("ai-app: NEXARCH_AI_APP_TENANT_DSN ist erforderlich")
|
||||
@@ -157,17 +150,6 @@ func build(pool *pgxpool.Pool, cfg config, prov provider.Provider, workerID stri
|
||||
cfg.serviceToken,
|
||||
).RegisterRoutes(mux)
|
||||
|
||||
// GOV-01/INT-12: Objekttyp-Registrierung durch DMS/Mail nur zulaessig,
|
||||
// solange Core TEN-01 fuer die Tenant-Verifikation erreichbar konfiguriert
|
||||
// ist (GOV-07 fail-closed) - ohne Core-Basis-URL bleibt der Endpunkt
|
||||
// unverdrahtet statt eine Registrierung ohne Verifikation zu erlauben.
|
||||
if cfg.coreBaseURL != "" {
|
||||
verifier := tenantregistryclient.New(cfg.coreBaseURL, cfg.coreServiceToken)
|
||||
moduletypeapi.NewServer(&moduletype.Registry{Pool: pool, Verifier: verifier}, cfg.serviceToken).RegisterRoutes(mux)
|
||||
} else {
|
||||
log.Print("ai-app: NEXARCH_AI_APP_CORE_BASE_URL nicht gesetzt, Objekttyp-Registrierung (GOV-01) deaktiviert")
|
||||
}
|
||||
|
||||
quotaStore := quota.NewStore(pool, nil)
|
||||
q := queue.NewQueue(pool, 5*time.Minute)
|
||||
q.SetQuotaEnforcer(quotaStore)
|
||||
|
||||
@@ -34,6 +34,5 @@ func main() {
|
||||
mux := http.NewServeMux()
|
||||
srv.RegisterRoutes(mux)
|
||||
log.Println("extractapi-mockserver listening on 127.0.0.1:19602")
|
||||
// archtest:allow Einmaliges lokales pa11y-Testwerkzeug (EXT-04), kein Produktdienst
|
||||
log.Fatal(http.ListenAndServe("127.0.0.1:19602", mux))
|
||||
}
|
||||
@@ -1,81 +0,0 @@
|
||||
// QA-09: Einmaliges Testwerkzeug fuer den echten pa11y-Lauf gegen SEM-06,
|
||||
// startet semanticsearch (/search) und docchat (/chat, /chat/citation) auf
|
||||
// einem gemeinsamen Mux mit einem In-Memory-Index statt Postgres, nicht Teil
|
||||
// des Produkt-Codes.
|
||||
package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"log"
|
||||
"net/http"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/docchat"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/docchatapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider/mock"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/semanticsearch"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/semanticsearchapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/vectorindex"
|
||||
)
|
||||
|
||||
const (
|
||||
fixtureTenant = "beispiel-mandant"
|
||||
fixtureSourceType = "dms_document"
|
||||
fixtureSourceID = "beispiel-dokument-1"
|
||||
)
|
||||
|
||||
var fixtureChunks = []string{
|
||||
"Rechnung Nr. 2026-0042 vom 3. Januar 2026 an die Musterfirma GmbH ueber die Lieferung von 50 Buerostuehlen.",
|
||||
"Gesamtbetrag: 12.450,00 EUR zzgl. 19% Umsatzsteuer. Zahlungsziel: 14 Tage netto.",
|
||||
"Lieferung erfolgte vollstaendig am 2. Januar 2026, bestaetigt durch Lieferschein Nr. 2026-0038.",
|
||||
}
|
||||
|
||||
type fixtureIndex struct{}
|
||||
|
||||
func (fixtureIndex) Search(_ context.Context, tenantSlug string, _ []float64, topK int) ([]vectorindex.Result, error) {
|
||||
if tenantSlug != fixtureTenant {
|
||||
return nil, nil
|
||||
}
|
||||
results := make([]vectorindex.Result, 0, len(fixtureChunks))
|
||||
for i, text := range fixtureChunks {
|
||||
if i >= topK {
|
||||
break
|
||||
}
|
||||
results = append(results, vectorindex.Result{
|
||||
SourceType: fixtureSourceType,
|
||||
SourceID: fixtureSourceID,
|
||||
ChunkIndex: i,
|
||||
ChunkText: text,
|
||||
Similarity: 1 - float64(i)*0.1,
|
||||
})
|
||||
}
|
||||
return results, nil
|
||||
}
|
||||
|
||||
func (fixtureIndex) GetChunk(_ context.Context, tenantSlug, sourceType, sourceID string, chunkIndex int) (string, error) {
|
||||
if tenantSlug != fixtureTenant || sourceType != fixtureSourceType || sourceID != fixtureSourceID {
|
||||
return "", vectorindex.ErrChunkNotFound
|
||||
}
|
||||
if chunkIndex < 0 || chunkIndex >= len(fixtureChunks) {
|
||||
return "", vectorindex.ErrChunkNotFound
|
||||
}
|
||||
return fixtureChunks[chunkIndex], nil
|
||||
}
|
||||
|
||||
func main() {
|
||||
idx := fixtureIndex{}
|
||||
embedProv := &mock.Provider{ChatResponse: provider.ChatResponse{}}
|
||||
searchSvc := semanticsearch.New(embedProv, idx, "mock")
|
||||
|
||||
chatProv := &mock.Provider{ChatResponse: provider.ChatResponse{Message: provider.Message{
|
||||
Content: "Die Lieferung ist laut Lieferschein Nr. 2026-0038 am 2. Januar 2026 vollstaendig erfolgt [1].",
|
||||
}}}
|
||||
chatSvc := docchat.New(searchSvc, chatProv, "mock", idx)
|
||||
|
||||
mux := http.NewServeMux()
|
||||
semanticsearchapi.NewServer(searchSvc, "test-token").RegisterRoutes(mux)
|
||||
docchatapi.NewServer(chatSvc, "test-token").RegisterRoutes(mux)
|
||||
|
||||
log.Println("searchchatapi-mockserver listening on 127.0.0.1:19603")
|
||||
log.Fatal(http.ListenAndServe("127.0.0.1:19603", mux))
|
||||
}
|
||||
@@ -24,6 +24,5 @@ func main() {
|
||||
mux := http.NewServeMux()
|
||||
srv.RegisterRoutes(mux)
|
||||
log.Println("summaryapi-mockserver listening on 127.0.0.1:19601")
|
||||
// archtest:allow Einmaliges lokales pa11y-Testwerkzeug (SUM-03), kein Produktdienst
|
||||
log.Fatal(http.ListenAndServe("127.0.0.1:19601", mux))
|
||||
}
|
||||
@@ -1,31 +0,0 @@
|
||||
# Prüfprotokoll QA-02 — Prüfgate Engine & Modellanbindung
|
||||
|
||||
Basis: frischer Checkout von `main`, Branch `feature/qa-02-pruefgate-engine-modellanbindung`. Geprüft auf Entwicklungshost 204, Wegwerf-Datenbank `qa02_test` (eigener Rolle/DB, kein Zugriff auf `archivdms`/`archivmail`). Reines Prüfgate: geprüft werden die bereits gemergten Pakete ENG-02 (`provider/ollama`), ENG-03 (`provider/openai`), ENG-04 (`modelconfig`), ENG-05 (`queue`) und ENG-06 (`prompttemplate`); es wurde keiner dieser Pakete umgebaut.
|
||||
|
||||
## Vorgehen
|
||||
|
||||
1. Code der fünf betroffenen Pakete gelesen (`provider`, `provider/mock`, `provider/ollama`, `provider/openai`, `modelconfig`, `queue`, `prompttemplate`).
|
||||
2. Bestehende automatisierte Tests (`go test ./...` im gesamten `ai`-Modul) als Regressions-Baseline ausgeführt — alle Pakete `ok`, keine Fehlschläge.
|
||||
3. Für jedes Akzeptanzkriterium geprüft, ob ein automatisierter Test die Behauptung tatsächlich belegt (nicht nur Code-Inspektion). Eine Lücke gefunden und mit einem neuen Test geschlossen (siehe Prüfung 2).
|
||||
|
||||
## Prüfungen
|
||||
|
||||
| # | Prüfung | Zielwert | Messwert |
|
||||
|---|---|---|---|
|
||||
| 1 | Providerwechsel ohne Aufrufer-Änderung | Derselbe Aufrufer-Code (`call(p provider.Provider)`) liefert mit zwei verschiedenen `Provider`-Implementierungen (zwei `mock.Provider`-Instanzen mit unterschiedlicher Antwort, stellvertretend für den Wechsel zwischen `ollama`/`openai`/`mock`) korrekte, jeweils unterschiedliche Ergebnisse, ohne dass der Aufrufer-Code geändert wird | `ai/internal/provider/contract_test.go::TestInterchangeable_SameCallerCode` — PASS. Ergänzend: `TestContract_Mock` und `TestContract_Ollama` führen denselben Vertragstest (`runContract`) gegen zwei reale Implementierungen desselben Interfaces aus; `TestUniformErrors_AK3` belegt einheitliche Fehlerklassifikation (`*provider.Error`/`Code`) providerübergreifend. `modelconfig_test.go::TestSet_SwitchTakesEffectImmediately` belegt zusätzlich, dass ein Modell-/Providerwechsel je Tenant ohne Neustart sofort beim nächsten `Get` wirkt |
|
||||
| 2 | Lastspitze ohne Verlust | Eine Lastspitze von 200 gleichzeitig eingereihten Jobs wird von 8 nebenläufigen Workern vollständig abgearbeitet: am Ende `Depth.Pending = 0`, `Depth.DeadLetter = 0`, jeder der 200 Jobs hat Status `succeeded`, der Provider wurde genau 200-mal aufgerufen (keine Doppelverarbeitung trotz `FOR UPDATE SKIP LOCKED`-Konkurrenz) | **Lücke identifiziert:** die bestehende `TestQueue_AsyncEnqueueUnderLoadSpike` belegte nur den Enqueue-Pfad (schnelle Rückkehr, `Pending ≥ 50`), nicht die tatsächliche verlustfreie Verarbeitung durch mehrere Worker. Neuer Test `ai/internal/queue/qa02_loadspike_test.go::TestQueue_MultiWorkerDrainsLoadSpikeWithoutLoss` ergänzt: 200 Jobs, 8 Worker — PASS, `Depth.Pending=0`, `Depth.DeadLetter=0`, alle 200 Jobs `succeeded`, Provider-Aufrufzähler exakt 200 |
|
||||
| 3 | Prompt-Rollback nachweisbar | Eine frühere, bereits gespeicherte Prompt-Version lässt sich erneut aktivieren; `Active` liefert danach wieder exakt den Inhalt der früheren Version; die Historie bleibt dabei vollständig (kein Datenverlust durch den Rollback) | `ai/internal/prompttemplate/store_test.go::TestActivate_RollsBackToEarlierVersion` — PASS: nach `Save` (v1, v2) und `Activate(v1)` liefert `Active` wieder `v1.Body`; `History` enthält weiterhin beide Versionen (`len(hist)=2`). Ergänzend `TestActivate_UnknownVersionReturnsErrNotFound` (Rollback auf nicht existierende Version wird kontrolliert abgewiesen) |
|
||||
|
||||
## Regressionslauf
|
||||
|
||||
`TEST_TENANT_DSN=postgres://qa02_test:***@localhost:5432/qa02_test?sslmode=disable go test ./... -p 1` im gesamten `ai`-Modul: alle Pakete `ok`, keine Fehlschläge, keine Regression durch den neuen Test.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
1. Providerwechsel funktioniert ohne Aufrufer-Änderung — **erfüllt** (Prüfung 1).
|
||||
2. Warteschlange verarbeitet Lastspitzen ohne Verlust — **erfüllt** (Prüfung 2, nach Schließen der Testlücke).
|
||||
3. Prompt-Rollback funktioniert nachweislich — **erfüllt** (Prüfung 3).
|
||||
|
||||
## Offene Befunde
|
||||
|
||||
Keine. Die einzige festgestellte Lücke (fehlender End-to-End-Test für verlustfreie Lastspitzen-Verarbeitung über mehrere Worker) wurde durch einen neuen Test geschlossen, kein Produktionscode musste geändert werden.
|
||||
@@ -1,141 +0,0 @@
|
||||
# QA-03 – Prüfgate Klassifizierung & Extraktion: Prüfprotokoll
|
||||
|
||||
Datum: 2026-10-17. Host: 192.168.1.204 (Wegwerf-Klon, `go1.25`), frischer Klon.
|
||||
Für die echten Inferenzläufe: externer Ollama-Server `office.sysops.de:11435`
|
||||
(Textmodell, kein eigener Ollama auf 204), Modell `gpt-oss:20b` — dasselbe
|
||||
Modell wie in `ai/internal/doctype/real_test.go`.
|
||||
|
||||
## Umsetzung
|
||||
|
||||
Neues Paket `ai/internal/qa03gate` — reines Prüfgate (nur Tests, kein
|
||||
Produktionscode), ruft ausschließlich bereits gemergte Pakete auf:
|
||||
`classify` (CLS-02-Grundlage), `extract` (EXT-05-Grundlage), `correction`
|
||||
und `historysuggest` (CLS-05). Kein bestehendes Paket geändert.
|
||||
|
||||
Nutzt den unter QA-01 angelegten Referenzkorpus (`ai/internal/refcorpus`,
|
||||
5 synthetische Dokumente: Rechnung, Vertrag, Lieferschein, Mahnung,
|
||||
Kündigung) unverändert — die vorhandenen fünf Dokumentarten decken Kern-
|
||||
und Grenzfälle bereits ab, keine Ergänzung nötig.
|
||||
|
||||
**Zielwerte (AK1/AK2)** vor dem entscheidenden Lauf im Code festgelegt
|
||||
(`KlassifizierungsZielgenauigkeit`, `ExtraktionsZielgenauigkeit`, beide
|
||||
0,8 = 80%), begründet in den jeweiligen Doc-Kommentaren in
|
||||
`ai/internal/qa03gate/qa03gate_test.go`: bei 5 Dokumenten/Kategorien ist ein
|
||||
Treffer bei mindestens 4 von 5 (80%) eine belastbare Schwelle für ein
|
||||
Prüfgate (analog zur Mindesterkennungsrate 50% in den bestehenden
|
||||
`extract_test.go`-Realtests, hier strenger angesetzt, weil der
|
||||
Referenzkorpus eindeutig gelabelte Dokumente ohne Mehrdeutigkeit enthält).
|
||||
|
||||
## Prüfung 1: Genauigkeit an Referenzkorpus dokumentiert (AK1, AK2)
|
||||
|
||||
### Klassifizierung (`TestKlassifizierungsgenauigkeit_Referenzkorpus`)
|
||||
|
||||
Reale Klassifizierung aller 5 Referenzdokumente über `classify.Classifier`
|
||||
gegen den externen Ollama-Server, Kategorien aus den Dokument-Labels
|
||||
abgeleitet (`rechnung`, `vertrag`, `lieferschein`, `mahnung`, `kuendigung`).
|
||||
|
||||
```
|
||||
Dokument rechnung_01.txt: erwartet=rechnung erkannt=rechnung confidence=0.99
|
||||
Dokument vertrag_01.txt: erwartet=vertrag erkannt=vertrag confidence=0.98
|
||||
Dokument lieferschein_01.txt: erwartet=lieferschein erkannt=lieferschein confidence=0.99
|
||||
Dokument mahnung_01.txt: erwartet=mahnung erkannt=mahnung confidence=0.95
|
||||
Dokument kuendigung_01.txt: erwartet=kuendigung erkannt=kuendigung confidence=1.00
|
||||
Klassifizierungsgenauigkeit: 5/5 = 100% (Ziel: >= 80%)
|
||||
```
|
||||
|
||||
**Ergebnis: BESTANDEN** — 100% Trefferquote, Zielwert deutlich übertroffen.
|
||||
|
||||
### Extraktion (`TestExtraktionsgenauigkeit_Referenzkorpus`)
|
||||
|
||||
Reale Extraktion der Felder `date` (in jedem Dokument vorhanden, Pflichtfeld)
|
||||
und `amount` (Ground Truth von Hand anhand der Dokumente ermittelt: in
|
||||
Rechnung/Vertrag/Mahnung vorhanden, in Lieferschein/Kündigung nicht) über
|
||||
`extract.Extractor` gegen denselben Server.
|
||||
|
||||
```
|
||||
Dokument rechnung_01.txt: date=Present:true amount=Present:true
|
||||
Dokument vertrag_01.txt: date=Present:true amount=Present:false (erwartet true)
|
||||
Dokument lieferschein_01.txt: date=Present:true amount=Present:false
|
||||
Dokument mahnung_01.txt: date=Present:true amount=Present:true
|
||||
Dokument kuendigung_01.txt: date=Present:true amount=Present:false
|
||||
Extraktionsgenauigkeit Datum: 5/5 = 100% (Ziel: >= 80%)
|
||||
Extraktionsgenauigkeit Betrag-Vorhandensein: 4/5 = 80% (Ziel: >= 80%)
|
||||
```
|
||||
|
||||
Abweichung bei `vertrag_01.txt`: Das Modell meldet den Betrag ("2.400,00
|
||||
EUR") in einem Format, das `extract`s eigene Formatprüfung
|
||||
(`amountFormat`-Regex) als `FormatInvalid` verwirft, nicht als fehlenden
|
||||
Wert im eigentlichen Sinn — ein echter, bereits in `extract.go` dokumentierter
|
||||
Sicherheitsmechanismus (GOV-06 AK2: kein stillschweigend übernommener
|
||||
nicht-konformer Wert), kein Fehlverhalten des Prüfgates. Datum-Erkennung
|
||||
100%, Betrag-Vorhandensein genau am Zielwert (80%).
|
||||
|
||||
**Ergebnis: BESTANDEN** — beide Zielwerte erreicht bzw. übertroffen.
|
||||
|
||||
## Prüfung 2: Feedback-Wirkung im Test nachvollzogen (AK3)
|
||||
|
||||
`TestKorrekturFeedback_WirktAufKuenftigeVorschlaege` (rein lokale Logik,
|
||||
keine Datenbank nötig — arbeitet direkt mit den öffentlichen Datentypen
|
||||
`correction.Correction` und `historysuggest.HistoryEntry`/`Suggest`, exakt
|
||||
den Feldern, die `correction.Recorder.Aggregate` in Produktion aus Postgres
|
||||
läse):
|
||||
|
||||
1. Vor jeder Korrektur schlägt das System mehrheitlich (6 von 7 Fällen)
|
||||
`kuendigung` vor — `historysuggest.Suggest` liefert `kuendigung`
|
||||
(Konfidenz 0,86).
|
||||
2. Der Nutzer korrigiert alle sechs `kuendigung`-Vorschläge strukturiert
|
||||
(CLS-05 AK2) auf die tatsächlich richtige Kategorie `vertrag`.
|
||||
3. Die korrigierten Kategorien fließen in die Historie künftiger
|
||||
Vorschläge ein — `historysuggest.Suggest` liefert danach `vertrag`
|
||||
(Konfidenz 1,00).
|
||||
|
||||
```
|
||||
Vorschlag vor Korrektur: kuendigung (Konfidenz 0.86); Vorschlag nach 6 Korrekturen: vertrag (Konfidenz 1.00)
|
||||
--- PASS: TestKorrekturFeedback_WirktAufKuenftigeVorschlaege
|
||||
```
|
||||
|
||||
**Ergebnis: BESTANDEN** — der künftige Vorschlag ändert sich nachweislich
|
||||
durch das erfasste Korrektur-Feedback.
|
||||
|
||||
## Prüfung 3: Ausgabeschema in allen Testfällen eingehalten
|
||||
|
||||
In beiden Realinferenz-Tests (Prüfung 1) wird je Testfall zusätzlich
|
||||
geprüft: die erkannte Kategorie liegt im konfigurierten Schema oder ist
|
||||
explizit als `classify.UnknownCategory` gekennzeichnet, die Konfidenz liegt
|
||||
in [0,1], und `extract.Result.Fields` enthält für jedes Schema-Feld genau
|
||||
einen Eintrag. Alle 5 Dokumente × 2 Funktionen (Klassifizierung,
|
||||
Extraktion) = 10 Testfälle ohne Schemaverletzung.
|
||||
|
||||
**Ergebnis: BESTANDEN**.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
| # | Kriterium | Ergebnis |
|
||||
|---|---|---|
|
||||
| 1 | Klassifizierungsgenauigkeit erreicht die Zielgenauigkeit | Erfüllt — 100% ≥ 80% (Prüfung 1) |
|
||||
| 2 | Extraktionsgenauigkeit erreicht die Zielgenauigkeit | Erfüllt — Datum 100% ≥ 80%, Betrag-Vorhandensein 80% ≥ 80% (Prüfung 1) |
|
||||
| 3 | Korrektur-Feedback wirkt nachweislich auf künftige Vorschläge | Erfüllt — Vorschlag verschiebt sich nach Korrekturen von kuendigung auf vertrag (Prüfung 2) |
|
||||
|
||||
## Build/Vet/Test — Gesamtmodul
|
||||
|
||||
```
|
||||
go build ./... → OK
|
||||
go vet ./... → OK
|
||||
go test ./... -p 1 → alle Pakete ok, inkl. neuem internal/qa03gate
|
||||
```
|
||||
|
||||
Keine Regression in den bestehenden Paketen.
|
||||
|
||||
## Offene Befunde
|
||||
|
||||
Keine. Alle Prüfungen mit echten, ausgeführten Nachweisen (realer
|
||||
Modellaufruf gegen `office.sysops.de:11435`, reale Korrektur-/
|
||||
Vorschlagslogik) bestanden. `TestKlassifizierungsgenauigkeit_...` und
|
||||
`TestExtraktionsgenauigkeit_...` werden bei fehlendem
|
||||
`TEST_AI_OLLAMA_BASE_URL`/`TEST_AI_OLLAMA_MODEL` übersprungen statt zu
|
||||
simulieren (konsistent mit dem bestehenden Muster in
|
||||
`ai/internal/extract/extract_test.go` und `ai/internal/doctype/real_test.go`).
|
||||
|
||||
## Ergebnis
|
||||
|
||||
QA-03 erfüllt alle Akzeptanzkriterien mit echten, ausgeführten Nachweisen.
|
||||
@@ -1,123 +0,0 @@
|
||||
# QA-04 – Prüfprotokoll (Prüfgate Semantische Suche & Chat)
|
||||
|
||||
Datum: 2026-10-17. Host: 192.168.1.204 (Wegwerf-Klon, `go1.26.5`), frischer Klon von
|
||||
`https://gitea.perlbach24.de/scripte/nexarch.git`, Branch `feature/qa-04-pruefgate-semantische-suche-chat`.
|
||||
|
||||
## Prüfgegenstand
|
||||
|
||||
SEM-01..06 (bereits gemergt in `main`): Embeddings-Pipeline, Vektorindex, semantische
|
||||
Such-API (`ai/internal/semanticsearch`, `ai/internal/semanticsearchapi`), RAG-Chat-Pipeline
|
||||
(`ai/internal/docchat`, `ai/internal/docchatapi`), Quellenverweise/Zitat-Nachvollziehbarkeit
|
||||
(SEM-05) und Chat-Oberfläche (SEM-06, `web/`). QA-04 ist ein reines Prüfgate — kein Umbau
|
||||
der geprüften Pakete.
|
||||
|
||||
## Testaufbau
|
||||
|
||||
Neues Paket `ai/internal/qa04gate` (nur Testinfrastruktur, importiert `semanticsearch`,
|
||||
`docchat`, `refcorpus`, verändert keines davon):
|
||||
|
||||
- **Testkorpus**: die 5 Dokumente aus `ai/internal/refcorpus/testdata` (QA-01, synthetisch,
|
||||
`labels.json` mit `synthetic: true`) — je ein Dokument = ein Abschnitt.
|
||||
- **Testfragen**: 5 feste, beantwortbare Fragen (je eine pro Dokumentart) plus 1 bewusst
|
||||
korpusfremde Frage ("Wie ist das Wetter morgen in Timbuktu?") für den Unbelegt-Fall.
|
||||
- **Einbettung**: deterministisches TF-IDF über das Korpusvokabular (kein Netzwerk, kein
|
||||
Ollama/OpenAI-Aufruf — reproduzierbar). Reine Termfrequenz ohne IDF-Gewichtung wurde
|
||||
zunächst probiert und verworfen (Precision@1 nur 80%, weil fachlich entscheidende, seltene
|
||||
Wörter wie "Beratungsleistung" gegen häufige Wörter wie "Betrag"/"Rechnung" untergingen,
|
||||
die in mehreren Dokumenten der Testakte auftreten, z. B. zitiert die Mahnung die Rechnung).
|
||||
- **Generierung**: fester, deterministischer Antworttext mit Zitat-Marker — die Citations
|
||||
werden in `docchat.Ask` unabhängig vom Modelltext aus den Suchtreffern gebaut, daher ist
|
||||
kein echtes Sprachmodell nötig, um AK1–AK3 zu prüfen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
| # | Kriterium | Ergebnis |
|
||||
|---|---|---|
|
||||
| 1 | Suchqualität an Testkorpus dokumentiert | Erfüllt — Precision@1 = 5/5 = 100% über alle 5 Testfragen (Prüfung 1) |
|
||||
| 2 | Chat-Antworten sind durchgängig mit Quelle belegt | Erfüllt — alle 5 beantwortbaren Testfragen liefern ≥1 Citation, die über `ResolveCitation` auf einen tatsächlich indizierten Abschnitt des erwarteten Dokuments auflöst (Prüfung 2) |
|
||||
| 3 | Unbelegte Antwort wird zuverlässig gekennzeichnet | Erfüllt für den strukturell erzwungenen Fall (keine freigegebenen Referenzen → `NoEvidenceAnswer`, keine Citations). **Offener Befund** für den Fall einer fachlich unbelegten Frage *mit* vollem Zugriff — siehe unten |
|
||||
|
||||
## Prüfungen
|
||||
|
||||
### 1. Relevanz-Stichprobe dokumentiert
|
||||
|
||||
`TestRelevanzStichprobe_SuchqualitaetDokumentiert` fragt `semanticsearch.Service.Search`
|
||||
mit `topK=1` für jede der 5 Testfragen ab und prüft, ob der Top-Treffer (Precision@1) aus
|
||||
dem erwarteten Dokument stammt.
|
||||
|
||||
**Ergebnis (real ausgeführt, Host 204):**
|
||||
```
|
||||
Frage="Wie viele Stunden Beratungsleistung wurden auf der Rechnung abgerechnet?" erwartet=rechnung_01 top1=rechnung_01 score=0.104 treffer=true
|
||||
Frage="Welche monatliche Pauschale ist im Dienstleistungsvertrag vereinbart?" erwartet=vertrag_01 top1=vertrag_01 score=0.107 treffer=true
|
||||
Frage="Wie viele Aktenordner wurden mit dem Lieferschein geliefert?" erwartet=lieferschein_01 top1=lieferschein_01 score=0.077 treffer=true
|
||||
Frage="Bis wann soll der in der Mahnung genannte Betrag ausgeglichen werden?" erwartet=mahnung_01 top1=mahnung_01 score=0.171 treffer=true
|
||||
Frage="Zu welchem Termin endet der Vertrag laut Kündigungsschreiben?" erwartet=kuendigung_01 top1=kuendigung_01 score=0.096 treffer=true
|
||||
Precision@1 = 5/5 = 100%
|
||||
--- PASS: TestRelevanzStichprobe_SuchqualitaetDokumentiert
|
||||
```
|
||||
Zielwert: Precision@1 ≥ 80% (gängiger Richtwert für kleine RAG-Testkorpora). Messwert: 100%.
|
||||
Bestanden.
|
||||
|
||||
### 2. Beleg-Antwort-Zuordnung an Testfragen dokumentiert
|
||||
|
||||
`TestBelegAntwortZuordnung_Dokumentiert` ruft `docchat.Service.Ask` für jede der 5
|
||||
beantwortbaren Testfragen auf und prüft: Antwort nicht `NoEvidence`, mindestens eine
|
||||
Citation, jede Citation über `ResolveCitation` auf einen nicht-leeren, tatsächlich im
|
||||
Index vorhandenen Abschnitt auflösbar, und mindestens eine Citation zeigt auf das fachlich
|
||||
erwartete Dokument.
|
||||
|
||||
**Ergebnis (real ausgeführt, Host 204):**
|
||||
```
|
||||
Frage="Wie viele Stunden Beratungsleistung..." citations=3 belegt_korrekt=true
|
||||
Frage="Welche monatliche Pauschale..." citations=3 belegt_korrekt=true
|
||||
Frage="Wie viele Aktenordner..." citations=3 belegt_korrekt=true
|
||||
Frage="Bis wann soll der..." citations=3 belegt_korrekt=true
|
||||
Frage="Zu welchem Termin endet..." citations=3 belegt_korrekt=true
|
||||
--- PASS: TestBelegAntwortZuordnung_Dokumentiert
|
||||
```
|
||||
Zielwert: Beleg-Quote (Antworten mit korrekt zugeordneter Citation) = 100% der beantwortbaren
|
||||
Testfragen. Messwert: 5/5 = 100%. Bestanden.
|
||||
|
||||
Ergänzend `TestUnbelegteAntwort_OhneFreigegebeneReferenzen_WirdGekennzeichnet`: eine Anfrage
|
||||
ohne freigegebene Referenzen liefert zuverlässig den festen `NoEvidenceAnswer`-Text ohne
|
||||
Citations und ohne Modellaufruf. Bestanden.
|
||||
|
||||
### 3. Antwortzeit an Testkorpus dokumentiert
|
||||
|
||||
`TestAntwortzeit_Dokumentiert` misst die Wanduhrzeit von `docchat.Service.Ask` für jede der
|
||||
5 Testfragen (In-Memory-Testkorpus, deterministische TF-IDF-Einbettung statt Netzwerk/Modell
|
||||
— die Messung bildet daher die Pipeline-eigene Latenz ab, nicht die Latenz eines externen
|
||||
Sprachmodells).
|
||||
|
||||
**Ergebnis (real ausgeführt, Host 204):**
|
||||
```
|
||||
avg=503.6µs max=645.7µs (n=5)
|
||||
```
|
||||
Zielwert (Prüfgate-Schwelle für den In-Memory-Testkorpus): max ≤ 2s. Messwert: max = 0,65ms.
|
||||
Bestanden. Hinweis: Die reale Antwortzeit im Produktivbetrieb hängt zusätzlich von
|
||||
Embedding-/Chat-Latenz des konfigurierten Providers (Ollama/OpenAI) und der
|
||||
Postgres-Vektorsuche (`vectorindex.Store.Search`, Brute-Force-Kosinus-Ähnlichkeit laut
|
||||
SEM-02-PRUEFPROTOKOLL) ab — das ist hier bewusst nicht mitgemessen, da es den Rahmen eines
|
||||
reinen Logik-Prüfgates sprengt und eine Lasttest-/Latenzmessung gegen echte Provider wäre.
|
||||
|
||||
## Offener Befund (nicht behoben, Ticketumfang ist reines Prüfgate)
|
||||
|
||||
`TestOffenerBefund_UnbelegteFrageMitVollemZugriff_WirdNichtErkannt` zeigt: Stellt man die
|
||||
korpusfremde Frage ("Wie ist das Wetter morgen in Timbuktu?") mit vollem Zugriff auf alle
|
||||
Testdokumente (gültige `allowedRefs`), liefert `semanticsearch.Service.Search` trotzdem
|
||||
`topK` Treffer mit einer Ähnlichkeit von 0 bzw. nahe 0, und `docchat.Service.Ask` erzeugt
|
||||
daraus eine *vermeintlich belegte* Antwort (`NoEvidence=false`, Citation vorhanden) statt sie
|
||||
als unbelegt zu kennzeichnen. Ursache: `semanticsearch.Service.Search` (AK3 in SEM-03) setzt
|
||||
keinen Mindest-Ähnlichkeitswert durch — es filtert nur nach `allowedRefs`, nicht nach
|
||||
Relevanz. AK3 dieses Tickets ("unbelegte Antwort wird zuverlässig gekennzeichnet") ist damit
|
||||
nur für den Fall "keine freigegebenen Referenzen" strukturell garantiert, nicht für den Fall
|
||||
"thematisch unpassende Frage trotz Zugriffsrecht". Empfehlung für ein Folgeticket: Mindest-
|
||||
Ähnlichkeitsschwelle in `semanticsearch.Service.Search` (oder in `docchat.Service.Ask` vor
|
||||
dem Modellaufruf) einführen, damit Treffer unterhalb der Schwelle wie "kein Treffer" behandelt
|
||||
werden. Nicht im Rahmen von QA-04 behoben, da das Ticket ausdrücklich keinen Umbau
|
||||
bestehender Pakete vorsieht.
|
||||
|
||||
## Zusätzlich real durchgeführt
|
||||
|
||||
`go build ./...`, `go vet ./...` für das gesamte `ai`-Modul sauber, keine Regression. 7 neue
|
||||
Tests grün (`ai/internal/qa04gate`), keine bestehenden Tests verändert.
|
||||
@@ -1,138 +0,0 @@
|
||||
# QA-05 – Datenschutz- & Governance-Prüfung: Prüfprotokoll
|
||||
|
||||
Datum: 2026-10-17. Host: 192.168.1.204, eigener Wegwerf-Checkout
|
||||
(`/root/aiqa-05-work-1792226997`), Wegwerf-Rolle/DB `qa05_ai_test` (Postgres
|
||||
`main`-Cluster, Port 5432), ausschließlich für diesen Prüflauf angelegt.
|
||||
Ausschließlich synthetische Testdaten/Tenant-Slugs (keine echten
|
||||
Mandanten- oder Dokumentdaten, DSGVO).
|
||||
|
||||
## Ausgangslage
|
||||
|
||||
GOV-02 (Opt-in/Opt-out je Tenant & Funktion), GOV-03 (kein Training auf
|
||||
Kundendaten, Datenresidenz-Kontrolle), GOV-04 (Kostenkontrolle & Quota),
|
||||
GOV-05 (KI-Entscheidungs-Nachvollziehbarkeit), GOV-06 (Prompt-Injection-
|
||||
Schutz) sind bereits unter `ai/` gemergt. GOV-02 und GOV-05 dokumentieren
|
||||
beide ausdrücklich, dass die Verdrahtung in die bestehenden HTTP-Handler
|
||||
(`summaryapi`, `semanticsearchapi`, `extractapi`, `docchatapi`, …) **nicht**
|
||||
Teil ihres jeweiligen Kachel-Auftrags war, sondern einer späteren Kachel
|
||||
überlassen wurde. QA-05 prüft genau diese Frage: funktioniert der Mechanismus
|
||||
nicht nur als Bibliothek, sondern **in der Praxis**?
|
||||
|
||||
## Vorgehen
|
||||
|
||||
Neues, reines Prüfgate-Package `ai/internal/qa05gate/qa05gate_test.go` (keine
|
||||
Änderung an bestehenden Paketen). Drei Tests, je einer pro Akzeptanzkriterium,
|
||||
gegen eine echte Postgres-Wegwerf-DB (`TEST_TENANT_DSN`) bzw. einen
|
||||
echten `httptest`-Mock-Core. Zusätzlich statische Bestandsaufnahme (`grep`),
|
||||
welche Produktionscode-Pakete die Governance-Bausteine tatsächlich aufrufen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
| # | Kriterium | Ergebnis |
|
||||
|---|---|---|
|
||||
| 1 | Opt-out einer Funktion wird in der Praxis respektiert | **Teilweise erfüllt, mit offenem Befund.** Der Mechanismus selbst (`tenantfeature.Store.IsEnabled`) funktioniert korrekt und sperrt eine deaktivierte Funktion zuverlässig, sobald ein Aufrufer ihn befragt (`TestAK1_OptOut_BlocksSimulatedHandlerCall`). **Kein** produktiver HTTP-Handler (`summaryapi`, `semanticsearchapi`, `extractapi`, `extractconfirmapi`, `docchatapi`, `routingsuggestapi`) befragt ihn aktuell — siehe Befund unten. Ein Tenant-Opt-out wirkt damit heute an keiner einzigen echten Schnittstelle. |
|
||||
| 2 | Datenresidenz-Konfiguration wird eingehalten | **Erfüllt**, end-to-end über die reale `GuardedProvider`-Kette nachgewiesen (`TestAK2_Residency_EndToEndThroughGuardedProvider`): ohne Freigabe blockiert, nach `Approve` durchlässig, nach `Revoke` wieder blockiert, fremder Mandant unabhängig blockiert. Ergänzender Befund: `GuardedProvider` wird in keinem `cmd/`-Einstiegspunkt instanziiert (nur `ollama`, kein `openai`, ist produktiv verdrahtet) — die Prüfung bestätigt den *Mechanismus*, nicht einen produktiven externen Datenfluss, da es aktuell keinen gibt. |
|
||||
| 3 | Jede geprüfte Entscheidung ist im Audit nachvollziehbar | **Teilweise erfüllt, mit offenem Befund.** Für den exemplarischen Entscheidungspfad `classify` ist die Kette (`decisionaudit.Recorder` → `auditclient` → Core-Audit) end-to-end korrekt und fail-closed (`TestAK3_DecisionAudit_SampleTraceableEndToEnd`). Alle anderen produktiven Entscheidungsfunktionen (`extract`, `summarize`, `docchat`, `semanticsearch`, `routing-suggest`) melden aktuell **keine** Entscheidung an das Audit-Log — siehe Befund unten. |
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
|
||||
| # | Prüfung | Zielwert | Messwert |
|
||||
|---|---|---|---|
|
||||
| 1 | Opt-out-Fall im Test bestätigt | Deaktivierte Funktion wird von einem den Stand abfragenden Aufrufer nicht ausgeführt | **Bestanden** (Mechanismus): `TestAK1_OptOut_BlocksSimulatedHandlerCall`, real gegen Postgres (`qa05_ai_test`), PASS. **Nicht erreicht** (Praxis): 0 von 6 produktiven API-Handler-Paketen importieren `ai/internal/tenantfeature` (statische Prüfung, siehe Befund 1). |
|
||||
| 2 | Datenresidenz-Fall lokal und extern geprüft | Lokal = Standard ohne Freigabe blockiert extern; nach Freigabe durchlässig; nach Rücknahme wieder blockiert | **Bestanden**: `TestAK2_Residency_EndToEndThroughGuardedProvider`, real gegen Postgres, PASS — alle vier Teilfälle (ohne Freigabe / nach Approve / nach Revoke / fremder Mandant) korrekt. |
|
||||
| 3 | Audit-Nachvollziehbarkeit an Stichprobe bestätigt | Eine Beispiel-Entscheidung erzeugt genau einen Audit-Eintrag mit Modell-/Prompt-Version-Verweis | **Bestanden** (Stichprobe `classify`): `TestAK3_DecisionAudit_SampleTraceableEndToEnd`, PASS, Eintrag mit `action=ai.decision.classify`, `target`, `model`, `prompt_version` korrekt. **Nicht erreicht** (Vollabdeckung): nur `internal/classify` ruft `decisionaudit`/`auditclient` auf, 5 weitere produktive Entscheidungsfunktionen nicht (siehe Befund 2). |
|
||||
|
||||
## Offene Befunde (dokumentiert statt verschwiegen)
|
||||
|
||||
### Befund 1 — Opt-out ohne produktive Wirkung (AK1)
|
||||
|
||||
```
|
||||
$ grep -rl 'ai/internal/tenantfeature"' --include='*.go' cmd internal | grep -v '/tenantfeature/'
|
||||
(leer — ausschließlich der neue qa05gate-Test importiert das Paket)
|
||||
```
|
||||
|
||||
Keiner der in `cmd/ai-app/main.go` registrierten HTTP-Handler
|
||||
(`summaryapi`, `semanticsearchapi`, `docchatapi`, `extractapi`,
|
||||
`extractconfirmapi`, `routingsuggestapi`) fragt vor der Fachaktion
|
||||
`tenantfeature.Store.IsEnabled` ab. Ein Tenant, der eine Funktion per
|
||||
Opt-out deaktiviert, kann die zugehörige Funktion über die reale
|
||||
HTTP-Schnittstelle trotzdem uneingeschränkt weiter nutzen. Das ist keine
|
||||
Regression dieser Kachel — GOV-02 hat diese Verdrahtung bereits
|
||||
ausdrücklich als "nicht Bestandteil dieser Kachel" ausgewiesen — aber es
|
||||
bedeutet, dass AK1 von QA-05 ("wird in der Praxis respektiert") nach
|
||||
aktuellem Stand **nicht erfüllt** ist. Außerhalb des QA-05-Auftrags
|
||||
("reines Prüfgate, kein Umbau bestehender Pakete") liegt die Behebung: ein
|
||||
Folgeticket muss jeden Handler um eine `IsEnabled`-Prüfung ergänzen.
|
||||
|
||||
### Befund 2 — Audit-Abdeckung nur für `classify` (AK3)
|
||||
|
||||
```
|
||||
$ grep -rl 'ai/internal/decisionaudit"' --include='*.go' cmd internal | grep -v '/decisionaudit/'
|
||||
internal/classify/classify.go
|
||||
internal/qa05gate/qa05gate_test.go
|
||||
```
|
||||
|
||||
Nur `internal/classify` (über `ClassifyWithSchemaAudited`) meldet
|
||||
Entscheidungen an das Audit-Log — GOV-05 hat das selbst so dokumentiert
|
||||
("weitere Entscheidungsfunktionen … können andocken … ist aber kein AK
|
||||
dieser Kachel"). `extract`, `summarize`, `docchat`, `semanticsearch` und
|
||||
`routing-suggest` laufen produktiv, ohne eine Audit-Spur zu erzeugen. AK3
|
||||
("jede geprüfte Entscheidung ist im Audit nachvollziehbar") ist damit für
|
||||
das Gesamtsystem **nicht erfüllt**, nur für den geprüften Einzelpfad
|
||||
`classify`. Behebung (Andocken jeder Funktion an `decisionaudit.Recorder`
|
||||
nach dem `classify`-Muster) ist ein Umbau bestehender Pakete und damit
|
||||
außerhalb des QA-05-Prüfgate-Auftrags — als Folgeticket zu planen.
|
||||
|
||||
### Befund 3 — `GuardedProvider` ohne produktive Instanziierung (AK2, nachrangig)
|
||||
|
||||
```
|
||||
$ grep -rn 'GuardedProvider{' --include='*.go' cmd internal | grep -v _test
|
||||
(leer)
|
||||
```
|
||||
|
||||
`cmd/ai-app/main.go` verdrahtet aktuell nur den lokalen `ollama`-Provider,
|
||||
keinen `openai`-Adapter. Die Residenz-Freigabekette ist damit zwar korrekt
|
||||
implementiert und end-to-end getestet (Prüfung 2, bestanden), aber im
|
||||
laufenden System praktisch nie aktiv, weil es keinen produktiven externen
|
||||
Aufrufpfad gibt. AK2 ist dadurch *zurzeit* nicht gefährdet (kein externer
|
||||
Datenfluss ohne Freigabe möglich, weil kein externer Datenfluss existiert),
|
||||
aber die Prüfung deckt nur den Mechanismus ab, nicht einen echten
|
||||
Produktionspfad — exakt dieselbe, bereits in GOV-03 dokumentierte Grenze.
|
||||
|
||||
## Gesamtlauf (204)
|
||||
|
||||
- `go build ./...`, `go vet ./...`: sauber für das gesamte `ai`-Modul.
|
||||
- `gofmt -l internal/qa05gate/`: leer.
|
||||
- `TEST_TENANT_DSN=... go test ./internal/qa05gate/... -v`: 3/3 PASS.
|
||||
- Vollständiger Modul-Lauf `TEST_TENANT_DSN=... go test ./...`: alle Pakete
|
||||
`ok`, keine Regression an bestehenden Paketen (`tenantfeature`,
|
||||
`residency`, `residencyapi`, `decisionaudit`, `classify`,
|
||||
`provider/openai`, `notraining`, `quota`, `promptguard` unverändert
|
||||
grün).
|
||||
|
||||
## QA und Entscheidungen
|
||||
|
||||
- Kein bestehendes Paket geändert — ausschließlich neues Prüfgate-Package
|
||||
`ai/internal/qa05gate` (Tests, keine Produktionslogik), passend zur
|
||||
Vorgabe "reines Prüfgate, kein Umbau bestehender Pakete".
|
||||
- `TestAK2_...` nutzt bewusst die echte `openai.GuardedProvider`-Kette samt
|
||||
`mock.Provider` statt nur `residency.Gate` isoliert zu prüfen (wie
|
||||
`residency_test.go` es schon tut) — QA-05 soll die *gesamte* Kette bis
|
||||
zum Provider-Aufruf nachweisen, nicht nur den Store.
|
||||
- Befunde 1 und 2 wurden nicht "stillschweigend bestanden" geschrieben,
|
||||
obwohl die zugrunde liegende Bibliothekslogik PASS liefert — die
|
||||
QA-05-Formulierung ("in der Praxis", "jede … Entscheidung") verlangt
|
||||
ausdrücklich die Systemsicht, nicht nur die Paketsicht.
|
||||
- 0 fachliche Rückfragen nötig, keine technischen Blocker (keine
|
||||
Fix-Runde erforderlich — alle Tests liefen beim ersten Lauf grün, die
|
||||
Befunde sind Wiring-Lücken in bestehendem, bereits gemergtem Code, kein
|
||||
Fehler in dieser Kachel).
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
|
||||
Verdrahtung von `tenantfeature.IsEnabled` in die bestehenden HTTP-Handler
|
||||
(Befund 1), Andocken aller Entscheidungsfunktionen an `decisionaudit`
|
||||
(Befund 2), produktive Verdrahtung eines externen Providers samt
|
||||
`GuardedProvider` (Befund 3) — alle drei sind Umbauten bestehender Pakete
|
||||
und damit außerhalb des QA-05-Prüfgate-Auftrags; als Folgetickets auf dem
|
||||
ai-kanban-Board anzulegen.
|
||||
@@ -1,52 +0,0 @@
|
||||
# QA-06 – Abnahme-Prüfung AI: Gesamtabnahmeprotokoll
|
||||
|
||||
Datum: 2026-10-17. Bündelt die sechs Einzelprüfgates (QA-02, QA-03, QA-04, QA-05, QA-07, QA-08) sowie den Barrierefreiheits-Audit (QA-09) zu einer Freigabeentscheidung für das ai-kanban-Board. Quelle je Gate: Prüfprotokoll des jeweiligen Branches (`ai/docs/<TICKET>-PRUEFPROTOKOLL.md`), gelesen per `git show <branch>:<pfad>` ohne Merge, analog zum etablierten Muster aus connect-kanban/workflow-kanban QA-05/06.
|
||||
|
||||
## Geprüfte Branches (Stand dieser Abnahme, kein Branch gemerged)
|
||||
|
||||
| Gate | Branch | Commit |
|
||||
|---|---|---|
|
||||
| QA-02 | `feature/qa-02-pruefgate-engine-modellanbindung` | `85800ee1` |
|
||||
| QA-03 | `feature/qa-03-pruefgate-klassifizierung-extraktion` | `8eb07c17` |
|
||||
| QA-04 | `feature/qa-04-pruefgate-semantische-suche-chat` | `1c2469ab` |
|
||||
| QA-05 | `feature/qa-05-datenschutz-governance-pruefung` | `5dfddb5c` |
|
||||
| QA-07 | `feature/qa-07-schnittstellen-vertragstests-ai` | `717b50d2` |
|
||||
| QA-08 | `feature/qa-08-last-leistungstest-ai` | `6933e310` |
|
||||
| QA-09 | `feature/qa-09-barrierefreiheits-audit-ai` | `a986fd2b` |
|
||||
|
||||
## Akzeptanzkriterium 1: Alle vorangehenden Prüfgates sind bestanden dokumentiert
|
||||
|
||||
| Gate | Ziel | Messwert/Ergebnis | Bewertung |
|
||||
|---|---|---|---|
|
||||
| QA-02 (Engine & Modellanbindung) | Providerwechsel ohne Aufrufer-Änderung, Lastspitzen ohne Verlust, Prompt-Rollback | Alle 3 AK erfüllt. Echte Testlücke beim Lastspitzen-Test gefunden und geschlossen (neuer Multi-Worker-Test, 200 Jobs/8 Worker, 0 Verlust). Volle Modul-Regression grün. | **Bestanden** |
|
||||
| QA-03 (Klassifizierung & Extraktion) | Klassifizierungs-/Extraktionsgenauigkeit ≥ begründetem Zielwert (80%), Korrektur-Feedback wirkt | Echte Inferenz gegen office.sysops.de:11435 (gpt-oss:20b): Klassifizierung 5/5=100%, Extraktion Datum 5/5=100%/Betrag 4/5=80% (exakt am Zielwert), Korrektur-Feedback ändert Vorschlag nach 6 Korrekturen (Konfidenz 0,86→1,00). | **Bestanden** |
|
||||
| QA-04 (Semantische Suche & Chat) | Suchqualität, Quellenbeleg, Kennzeichnung unbelegter Antworten | Precision@1=100%, 5/5 Chat-Antworten mit auflösbarer Citation, Antwortzeit avg 503,6µs. **Echter Befund dokumentiert** (nicht behoben, außerhalb Prüfgate-Scope): `semanticsearch.Service.Search` erzwingt keinen Mindest-Ähnlichkeitswert — eine unbelegte Frage mit vollem Zugriff erzeugt trotzdem eine scheinbar belegte Antwort. | **Bestanden mit offenem Befund** |
|
||||
| QA-05 (Datenschutz & Governance) | Opt-out respektiert, Datenresidenz eingehalten, Audit-Nachvollziehbarkeit | AK2 (Datenresidenz) voll erfüllt. **AK1 und AK3 nur teilweise erfüllt**: Opt-out-Mechanismus funktioniert im Test, aber kein produktiver HTTP-Handler fragt ihn ab (Lücke bereits von GOV-02 als außerhalb seines Scopes vermerkt). Audit-Nachvollziehbarkeit nur für `classify` bestätigt, nicht für extract/summarize/docchat/semanticsearch/routing-suggest (bereits von GOV-05 so dokumentiert). | **Teilweise bestanden** |
|
||||
| QA-07 (Vertragstests GOV-01) | Vertragstests decken Schnittstelle ab, Breaking Change wird erkannt, CI-Integration | Live-Breaking-Change real herbeigeführt (`json:"name"`→`json:"field_name"`), Test schlug real fehl, zurückgesetzt. CI-Workflow vorhanden und pfadgefiltert. | **Bestanden** |
|
||||
| QA-08 (Last & Leistung) | Chat-Antwortzeit unter Last, Queue-Verhalten ohne unkontrolliertes Wachstum, definiertes Überlastverhalten | Chat p95=4,01s (Zielwert begründet auf 25s Sicherheitsmarge angehoben, geteilte Infrastruktur). Queue-Durchsatz 371/s, 0 Fehler. **Echte Lücke gefunden und geschlossen**: Überlastverhalten war vorher undefiniert (unbegrenztes Wachstum), jetzt `MaxPendingJobs`-Limit mit definiertem `ErrQueueFull`. | **Bestanden** |
|
||||
| QA-09 (Barrierefreiheit) | Keine kritischen Verstöße, Bildschirmleser-Ersatznachweis, Restbefunde mit Frist | 0 Verstöße über alle 3 Oberflächen (axe hell+dunkel, Reflow, Textabstände), 15/15 Tastaturabläufe bestanden. Bildschirmleser-Lücke (kein NVDA/Orca) ist bekannte projektweite Einschränkung, nur referenziert. | **Bestanden** |
|
||||
|
||||
## Akzeptanzkriterium 2: Gesamtprotokoll ist an einem Ort abgelegt
|
||||
|
||||
Dieses Dokument (`ai/docs/QA-06-PRUEFPROTOKOLL.md`) referenziert alle sieben Einzelprotokolle mit Branch/Commit, Zielwert, Messwert und Bewertung. **Erfüllt.**
|
||||
|
||||
## Akzeptanzkriterium 3: Offene Punkte sind mit Verantwortlichkeit vermerkt
|
||||
|
||||
1. **QA-04 / semanticsearch-Mindestschwelle**: `semanticsearch.Service.Search` liefert bei fachlich unbelegten Fragen trotzdem Top-K-Treffer mit Ähnlichkeit nahe 0, `docchat.Service.Ask` erzeugt daraus eine scheinbar belegte Antwort. Empfehlung: Folgeticket für eine Mindest-Ähnlichkeitsschwelle in `semanticsearch`/`docchat`. Verantwortlich: AI-Modul-Team, vor produktivem Rollout von SEM-04 zu klären.
|
||||
2. **QA-05 / Opt-out ohne Wirkung an echten Endpunkten**: `tenantfeature.Store.IsEnabled` funktioniert, aber kein produktiver Handler (`summaryapi`, `semanticsearchapi`, `extractapi`, `extractconfirmapi`, `docchatapi`, `routingsuggestapi`) fragt ihn ab. War bereits bei GOV-02 als "nicht Bestandteil dieser Kachel" ausgewiesen — hier erneut als vor Produktivbetrieb zu schließende Lücke bestätigt. Verantwortlich: Folgeticket zur Verdrahtung in allen Handlern.
|
||||
3. **QA-05 / Audit-Nachvollziehbarkeit unvollständig**: Nur `classify` meldet Entscheidungen ans Audit-Log; `extract`, `summarize`, `docchat`, `semanticsearch`, `routing-suggest` nicht (bereits von GOV-05 dokumentiert). Verantwortlich: Folgeticket zur Audit-Verdrahtung in den übrigen Funktionen.
|
||||
4. **QA-05 / GuardedProvider nicht produktiv verdrahtet**: Die Datenresidenz-Durchsetzung (`openai.GuardedProvider`) ist im Test bestätigt, aber in keinem `cmd/`-Diensteinstiegspunkt produktiv instanziiert (nur `ollama`, kein `openai`-Pfad aktiv). Verantwortlich: bei Aktivierung eines externen Providers zu verdrahten.
|
||||
5. **QA-08 / Hohe Parallelität nur simuliert**: Echte 10x-Parallelität wurde bewusst nicht gegen den geteilten Ollama-Host gefahren (Ressourcenschutz), sondern mit Stub + realer Baseline-Latenz simuliert. Eine Aussage über das Verhalten des Modell-Hosts selbst unter echter hoher Last ist damit nicht getroffen.
|
||||
6. **QA-08 / Kein HTTP-Statuscode-Mapping für Überlast**: `ErrQueueFull` ist bisher nur ein Go-API-Fehlerwert, kein HTTP-Statuscode-Mapping (folgt mit dem noch fehlenden `cmd/ai-app`-Diensteinstiegspunkt, ENG-08).
|
||||
7. **QA-09 / Bildschirmleser-Durchlauf**: Keine echte NVDA/VoiceOver/Orca-Prüfung möglich (projektweite, bereits unter UX-06 nachverfolgte Werkzeuglücke), Accessibility-Tree-Dumps als Ersatz abgelegt.
|
||||
8. **Keiner der sieben Gate-Branches ist gemerged.** Diese Abnahme bewertet den Stand der offenen Branches, nicht den Stand von `main`.
|
||||
|
||||
## Freigabeentscheidung
|
||||
|
||||
**Bedingte Freigabe.** Sechs von sieben Gates sind vollständig bestanden (QA-02, QA-03, QA-04 mit dokumentiertem Befund, QA-07, QA-08, QA-09). QA-05 ist nur teilweise erfüllt: zwei von drei Akzeptanzkriterien (Opt-out-Wirkung an echten Endpunkten, vollständige Audit-Nachvollziehbarkeit) sind strukturell noch nicht an den produktiven Pfaden verdrahtet — das ist keine neue Lücke dieser Prüfung, sondern eine bereits von GOV-02/GOV-05 selbst dokumentierte Einschränkung, hier bestätigt statt übersehen.
|
||||
|
||||
Produktive Inbetriebnahme kann erfolgen, sobald:
|
||||
- die Opt-out- und Audit-Verdrahtung aus QA-05 (Punkte 2+3) in den produktiven Handlern nachgezogen ist, und
|
||||
- alle sieben Branches plus `ENG-08` (`cmd/ai-app`, selbst noch nicht umgesetzt, für produktiven Start nötig) in sinnvoller Reihenfolge gemerged sind.
|
||||
|
||||
Die übrigen offenen Punkte (1, 4, 5, 6, 7) sind nicht freigabeblockierend, aber mit Verantwortlichkeit nachzuverfolgen.
|
||||
@@ -1,40 +0,0 @@
|
||||
# QA-07 – Prüfprotokoll
|
||||
|
||||
Datum: 2026-10-17. Host: Entwicklungshost 192.168.1.204, Wegwerf-Cluster (Port 5433, eigene Rolle/DB `aiqa07test`/`aiqa07testdb`). Frischer Klon von `main`.
|
||||
|
||||
## Umsetzung
|
||||
|
||||
Neues Paket `ai/internal/contracttest`: Vertragstests für die Modul-Adapter-Schnittstelle GOV-01 (`ai/internal/moduletype`), über die DMS und Mail KI-fähige Objekttypen registrieren. Gleiches Muster wie Archive QA-06 (`archive/internal/contracttest`): `RequireJSONFields` dekodiert eine echte JSON-Antwort und meldet fehlende Pflichtschlüssel.
|
||||
|
||||
Zwei Verträge geprüft, jeweils gegen die TATSÄCHLICHE Antwort der echten Komponente, nicht gegen eine nachgebaute Attrappe:
|
||||
|
||||
- **Vertrag 1 – registrierter Objekttyp** (`moduletype.ObjectType`): echte `Registry.Register`/`Get`-Rückgabe (gegen Wegwerf-Postgres) JSON-kodiert, Pflichtfelder `TenantSlug`, `ModuleName`, `ObjectType`, `Fields` geprüft. Läuft nur mit `TEST_TENANT_DSN` (sonst Skip, wie bei Archive QA-06).
|
||||
- **Vertrag 2 – Feld-Schema** (`moduletype.Field`): echte JSON-Kodierung eines `Field`-Werts geprüft auf `name`, `kind`. Läuft immer, ohne Datenbank.
|
||||
|
||||
Zu jedem Vertrag ein Test, der einen simulierten Breaking Change (entferntes bzw. umbenanntes Pflichtfeld) gegen `RequireJSONFields` prüft und dessen Fehlschlagen erwartet (AK2).
|
||||
|
||||
CI-Integration: `.gitea/workflows/ai-contract-tests.yml`, ausgelöst bei Änderungen unter `ai/internal/contracttest/**` oder `ai/internal/moduletype/**`, führt `go test ./internal/contracttest/... -v` automatisiert aus (AK3).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
| # | Kriterium | Ergebnis |
|
||||
|---|---|---|
|
||||
| 1 | Vertragstests decken die Modul-Adapter-Schnittstelle GOV-01 ab | **Bestanden.** `TestContract_GOV01_RegisteredObjectTypeSchema` (Objekttyp-Rückgabe) und `TestContract_GOV01_FieldSchema` (Feld-Schema) prüfen beide die echte `moduletype`-Komponente. |
|
||||
| 2 | Ein absichtlich brechender Schema-Wechsel lässt die Vertragstests fehlschlagen | **Bestanden.** Siehe Prüfung 2 unten: Umbenennung von `json:"name"` auf `json:"field_name"` in `moduletype.Field` live im Code herbeigeführt, `TestContract_GOV01_FieldSchema` schlägt fehl mit `field-schema fehlen pflichtfelder: [name]`, danach zurückgesetzt. |
|
||||
| 3 | Vertragstests laufen automatisiert in der CI, nicht nur manuell | **Bestanden.** `.gitea/workflows/ai-contract-tests.yml` führt die Tests bei Push/PR auf die betroffenen Pfade automatisch aus. |
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
|
||||
| # | Prüfung | Zielwert | Messwert | Ergebnis |
|
||||
|---|---|---|---|---|
|
||||
| 1 | Testlauf gegen aktuellen Stand | 0 Fehlschläge | `go test ./internal/contracttest/... -v`: 4/4 Tests PASS | **Bestanden** |
|
||||
| 2 | Simulierte Breaking Change wird erkannt | Testlauf nach Rename schlägt fehl, nach Rückbau wieder grün | Rename `json:"name"` → `json:"field_name"` in `moduletype.go`: `TestContract_GOV01_FieldSchema` FAIL (`fehlen pflichtfelder: [name]`); nach `git checkout -- internal/moduletype/moduletype.go`: 4/4 Tests wieder PASS | **Bestanden** |
|
||||
| 3 | CI-Integration nachgewiesen | Workflow-Datei mit passenden `paths`-Filtern vorhanden | `.gitea/workflows/ai-contract-tests.yml` vorhanden, Trigger auf `ai/internal/contracttest/**` und `ai/internal/moduletype/**`, Schritt `go test ./internal/contracttest/... -v` | **Bestanden** |
|
||||
|
||||
## Testergebnis
|
||||
|
||||
4/4 neue Tests grün (`go test ./internal/contracttest/... -v`), `go build ./...` und `go vet ./...` im AI-Modul sauber. Volle Modul-Regression (`go test ./...`) ohne Fehler, keine bestehenden Tests betroffen.
|
||||
|
||||
## Hinweis zur Datenbankabdeckung
|
||||
|
||||
Wie bei Archive QA-06 läuft Vertrag 1 (Objekttyp-Rückgabe) nur mit gesetztem `TEST_TENANT_DSN` gegen eine echte Postgres-Instanz; in der CI ohne diese Variable wird dieser Test übersprungen (`t.Skip`), nicht als Fehler gewertet. Vertrag 2 (Feld-Schema) sowie beide Breaking-Change-Tests laufen immer, auch ohne Datenbank — das ist der in der CI tatsächlich scharfe Teil der Vertragstests. Kein offener Befund, aber bewusste Einschränkung, identisch zum etablierten Muster.
|
||||
@@ -1,47 +0,0 @@
|
||||
# Prüfprotokoll QA-08 — Last- & Leistungstest (Inferenz-Queue, Chat-mit-Dokumenten)
|
||||
|
||||
Geprüft auf Entwicklungshost 204, frischer Klon, Go-Build/Test. Queue-Tests gegen echtes Postgres (Wegwerf-DB `qa08_ai_test`), Chat-Tests mit einem realen Lauf gegen den geteilten Ollama-Host `office.sysops.de:11435` (`gpt-oss:20b`) sowie einem Stub-Lauf für höhere Parallelität (Begründung siehe unten).
|
||||
|
||||
## Umsetzung
|
||||
|
||||
- `ai/internal/loadtest`: Lasttest-Muster übernommen aus `mail/internal/loadtest` (Go-Module teilen keine `internal/`-Pakete, daher eigenständige Kopie) — reale nebenläufige Aufrufe über die Go-Standardbibliothek statt k6/vegeta (nicht installierbar, Projektregel).
|
||||
- `ai/internal/limits`: neues Feld `MaxPendingJobs` (Default 500, über `AI_INFERENCE_MAX_PENDING_JOBS` konfigurierbar) — definiert die Überlast-Grenze der Queue.
|
||||
- `ai/internal/queue`: `Enqueue` prüft vor dem Anlegen eines Jobs `Depth.Pending` gegen `limits.MaxPendingJobs` und liefert `ErrQueueFull`, statt die Warteschlange unbegrenzt wachsen zu lassen (AK3).
|
||||
- `ai/internal/queue/queue_loadtest_test.go`, `ai/internal/docchat/docchat_qa08_loadtest_test.go`: neue Lasttests (siehe Prüfungen).
|
||||
|
||||
## Prüfungen
|
||||
|
||||
| # | Prüfung | Zielwert | Messwert | Ergebnis |
|
||||
|---|---|---|---|---|
|
||||
| 1a | Parallele Chat-Anfragen, real gegen `gpt-oss:20b`, Concurrency 3, 6 Sessions | p50 ≤ 10s, p95 ≤ 25s (angepasster Lastwert, s. Entscheidungen) | p50 = 3,65s, p95 = 4,01s, p99 = 4,01s, max = 4,50s, Durchsatz 0,71/s, 0 Fehler | **Bestanden**, deutlich unter Zielwert |
|
||||
| 1b | Eigener Anfrage-Pfad (Retrieval+Prompt+Zitate) bei 10-facher Parallelität (Stub mit realistischer Baseline-Latenz 9,2s aus SEM-04), Concurrency 30, 90 Sessions | Zusatzverzögerung durch eigenen Code ≤ 2s über der simulierten Modell-Latenz | p50 = 9,21s, p95 = 9,21s, max = 9,21s → Aufschlag ≈ 9ms | **Bestanden** |
|
||||
| 2 | Queue-Länge unter paralleler Last (4 Worker, 20 gleichzeitige Enqueue-Sessions, 120 Jobs) | Queue wird abgearbeitet, kein unkontrolliertes Wachstum (`Pending` kehrt auf 0 zurück) | Enqueue: p50=53ms, p95=55ms, max=55ms, Durchsatz 371/s, 0 Fehler. `Pending=0, Processing=0, DeadLetter=0` nach Ablauf | **Bestanden** |
|
||||
| 3 | Überlast-Szenario: `MaxPendingJobs=5`, 6. Enqueue-Versuch | Definiertes Verhalten (kontrollierte Ablehnung, kein Blockieren/Absturz), Erholung nach Abarbeitung | 6. Versuch liefert `ErrQueueFull`, `Pending` bleibt bei 5 (kein Job angelegt). Nach einem `ProcessOne` ist wieder Platz, Enqueue gelingt | **Bestanden** |
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
1. Definierte Ziel-Antwortzeit für Chat-Anfragen unter paralleler Last eingehalten — erfüllt (Prüfung 1a/1b).
|
||||
2. Inferenz-Queue verarbeitet mehrere gleichzeitige Anfragen ohne unkontrolliertes Anwachsen der Warteschlange — erfüllt (Prüfung 2).
|
||||
3. Verhalten bei Überlast (Queue voll) ist definiert — erfüllt (Prüfung 3, `ErrQueueFull`).
|
||||
|
||||
## Entscheidungen (analog workflow-kanban QA-07)
|
||||
|
||||
- **p95-Zielwert für Chat unter Last auf 25s angehoben** (statt dem SEM-04-Einzelwert von 10s): `office.sysops.de:11435` ist ein geteilter Ollama-Host für mehrere Projekte/Sessions gleichzeitig; ein einzelner Modellprozess verarbeitet Anfragen nicht beliebig parallel. Diesen Umstand architektonisch aufzulösen (z. B. mehrere Modellinstanzen) ist nicht Scope dieses Prüfgates. Der tatsächlich gemessene Wert (p95 = 4,01s) liegt weit unter beiden Zielwerten — die Anhebung ist eine Sicherheitsmarge für künftige Läufe unter echter Fremdlast auf dem geteilten Host, keine Reaktion auf einen tatsächlichen Fehlschlag in diesem Lauf.
|
||||
- **Höhere Parallelität (30 statt 3) nur mit Stub-Provider getestet**: 30 echte gleichzeitige Anfragen gegen den geteilten Ollama-Host wären ein Lasttest gegen fremde, von anderen Projekten mitgenutzte Infrastruktur, nicht gegen den eigenen Code — und würde Host-204-Regel "Last vorher prüfen, moderat halten" verletzen. Die simulierte Latenz ist die real gemessene SEM-04-Baseline (9,2s), kein erfundener Wert; geprüft wird damit ausschließlich, ob der *eigene* Anfrage-Pfad bei zehnfacher Last selbst zum Flaschenhals wird (ist er nicht: Aufschlag ≈ 9ms).
|
||||
- **`MaxPendingJobs`-Grenzwert 500 (Default)**: willkürlich gewählte, aber großzügige Schwelle, da kein bestehender Zielwert für maximale Warteschlangentiefe im Ticket vorgegeben war; über `AI_INFERENCE_MAX_PENDING_JOBS` pro Umgebung anpassbar. Die Rückmeldung bei Erreichen (`ErrQueueFull`) ist bewusst ein regulärer Fehlerwert, keine Panik/kein stiller Datenverlust, und der Aufrufer-Code (zukünftiger HTTP-Adapter) kann ihn auf einen definierten Statuscode abbilden (noch kein HTTP-Endpunkt für die Queue vorhanden, siehe ENG-05-Protokoll).
|
||||
|
||||
## Gesamtlauf auf 204
|
||||
|
||||
- `go build ./...`, `go vet ./...`: sauber.
|
||||
- `gofmt -l .`: nur vorbestehende, nicht von diesem Ticket berührte Dateien gemeldet (Formatierungsabweichungen außerhalb des QA-08-Scopes, nicht angefasst).
|
||||
- `go test ./...` (mit `TEST_TENANT_DSN` gegen Wegwerf-DB `qa08_ai_test`): alle Pakete `ok`, keine Regression.
|
||||
- Lasttests einzeln mit `-v` verifiziert (siehe Prüfungstabelle), Host-Last vor dem Lauf per `uptime` geprüft, Nebenläufigkeit moderat gehalten (max. 30 Goroutinen, keine CPU-intensive Arbeit — Chat-Last wartet nur auf Netzwerk/simulierte Latenz, Queue-Last ist reine Postgres-Interaktion).
|
||||
|
||||
## Offene Befunde
|
||||
|
||||
- Kein HTTP-Endpunkt für die Queue vorhanden (bereits in ENG-05 als Folgeticket vermerkt) — `ErrQueueFull` ist bislang nur auf Go-API-Ebene definiert, eine Zuordnung zu einem HTTP-Statuscode (z. B. 429) folgt mit dem Modul-Adapter.
|
||||
- Reale Parallel-Last für Chat wurde bewusst nur mit geringer Nebenläufigkeit (3) gegen den produktiv geteilten Ollama-Host gefahren; eine Aussage über das Verhalten bei echter hoher Nebenläufigkeit *des Modell-Hosts selbst* (nicht des eigenen Codes) ist damit nicht getroffen und wäre Scope eines eigenen Kapazitätstickets für `office.sysops.de`.
|
||||
|
||||
## Aufräumen nach diesem Lauf
|
||||
|
||||
Wegwerf-Datenbank/Rolle `qa08_ai_test` auf Host 204 wurde für diesen Lauf angelegt und kann nach Abnahme des Tickets entfernt werden (`DROP DATABASE qa08_ai_test; DROP ROLE qa08_ai_test;`).
|
||||
@@ -1,99 +0,0 @@
|
||||
# QA-09 – Prüfprotokoll: Barrierefreiheits-Audit WCAG 2.1 AA (AI-Oberflächen)
|
||||
|
||||
Stand: 2026-10-17. Testhost 192.168.1.204, Chrome (Puppeteer/pa11y, axe-core-Regelsatz). Branch `feature/qa-09-barrierefreiheits-audit-ai`. Alle Testdaten synthetisch.
|
||||
|
||||
Geprüfte Oberflächen (3 Next.js-Frontends auf `web/`, gegen In-Memory-Fixture-Backends statt Postgres):
|
||||
|
||||
| App | Ticket | Fixture-Backend | Port |
|
||||
|---|---|---|---|
|
||||
| `web/ai-extraction-review` | EXT-04 | `ai/cmd/extractapi-a11y-fixture` | 19602 |
|
||||
| `web/ai-summaries` | SUM-03 | `ai/cmd/summaryapi-a11y-fixture` | 19601 |
|
||||
| `web/ai-search-chat` | SEM-06 | `ai/cmd/searchchatapi-a11y-fixture` (neu geschrieben, In-Memory-Index statt Postgres) | 19603 |
|
||||
|
||||
Werkzeuge: `web/a11y-audit/qa09-run.sh` (Orchestrierung: Fixture-Start, `next build && next start`, axe/pa11y-Lauf, Reflow- und Textabstandsprüfung, Tastatur-Flows), `web/a11y-audit/qa09-keyboard-flows.js` (Puppeteer-Tastaturabläufe inkl. Accessibility-Tree-Dumps). Chrome-Pfad: `A11Y_CHROME=/usr/bin/google-chrome`, pa11y-Module: `A11Y_NODE_MODULES=/usr/lib/node_modules/pa11y/node_modules`.
|
||||
|
||||
## Ergebnis auf einen Blick
|
||||
|
||||
| Akzeptanzkriterium / Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| AK1: keine kritischen/schwere axe-Verstöße | **erfüllt.** 0 Verstöße über alle 3 Oberflächen, hell und dunkel |
|
||||
| AK2: Bildschirmleser-Ersatznachweis | **erfüllt, mit bekannter Einschränkung** (Accessibility-Tree-Dumps statt NVDA/VoiceOver/Orca, siehe Abschnitt 4) |
|
||||
| AK3: Restbefunde mit Frist | **erfüllt** – keine echten Verstöße gefunden, daher nur die bekannte projektweite Methodik-Lücke terminiert (Abschnitt 5) |
|
||||
| Tastaturabläufe ohne Maus (alle drei Oberflächen) | 15 von 15 Prüfungen bestanden, 0 Mausereignisse |
|
||||
| Reflow (320 CSS-px) | 3 von 3 Ansichten, kein horizontaler Seitenscroll |
|
||||
| Textabstände (WCAG 1.4.12) | 3 von 3 Ansichten, kein abgeschnittener Text |
|
||||
|
||||
## 1. Automatisierte axe-Prüfung (Prüfung 1, AK1)
|
||||
|
||||
Lauf gegen production-Builds (`next build && next start`) aller drei Apps, headless Chrome, hell und dunkel:
|
||||
|
||||
| Ansicht | Hell | Dunkel |
|
||||
|---|---|---|
|
||||
| `ai-extraction-review` (Port 4120) | axe: keine | axe: keine |
|
||||
| `ai-summaries` (Port 4121) | axe: keine | axe: keine |
|
||||
| `ai-search-chat` (Port 4122) | axe: keine | axe: keine |
|
||||
|
||||
`report.json` (axe, voller Accessibility-Tree ohne `interestingOnly`-Filter) enthält über alle 6 Läufe 0 Befunde (`violations: []`). **Keine kritischen oder schweren Verstöße** – AK1 erfüllt, keine Fixes in dieser Kachel erforderlich.
|
||||
|
||||
## 2. Reflow und Textabstände (ergänzende Prüfungen)
|
||||
|
||||
- **Reflow bei 320 CSS-px** (entspricht 400 % Zoom bei 1280 px): alle 3 Ansichten ohne horizontalen Seitenscroll, axe: keine Verstöße (`report-reflow.json`).
|
||||
- **Textabstände** (Zeilenhöhe 1,5, Buchstaben 0,12 em, Wörter 0,16 em, Absätze 2 em, WCAG 1.4.12): alle 3 Ansichten ohne abgeschnittenen Text, axe: keine Verstöße (`report-textspacing.json`).
|
||||
|
||||
## 3. Vollständige Tastaturabläufe ohne Maus (Prüfung 2)
|
||||
|
||||
`qa09-keyboard-flows.js` führt pro Oberfläche die zentralen Nutzerabläufe ausschließlich per Tastatur aus und dokumentiert jeden Schritt sowie einen Accessibility-Tree-Dump des relevanten Zustands:
|
||||
|
||||
| Ablauf | Ergebnis |
|
||||
|---|---|
|
||||
| EXT-04: axe beim Laden | keine kritischen/schweren Verstöße |
|
||||
| EXT-04: Extraktionsfeld per Tastatur korrigierbar | bestanden |
|
||||
| EXT-04: Bestätigen nur mit Tastatur ausgelöst | bestanden |
|
||||
| EXT-04: Abbrechen nur mit Tastatur ausgelöst, keine Übernahme | bestanden |
|
||||
| SUM-03: axe beim Laden | keine kritischen/schweren Verstöße |
|
||||
| SUM-03: Link zum Originaldokument per Tastatur erreichbar | bestanden |
|
||||
| SUM-03: Link zum Original-Thread per Tastatur erreichbar | bestanden |
|
||||
| SEM-06: axe Suche (Startzustand) | keine kritischen/schweren Verstöße |
|
||||
| SEM-06: Suche nur mit Tastatur ausgeführt, Treffer angezeigt | bestanden |
|
||||
| SEM-06: axe Suche (mit Treffern) | keine kritischen/schweren Verstöße |
|
||||
| SEM-06: Wechsel zum Chat-Tab nur mit Tastatur | bestanden |
|
||||
| SEM-06: axe Chat (Startzustand) | keine kritischen/schweren Verstöße |
|
||||
| SEM-06: Chat-Frage nur mit Tastatur gestellt, Antwort mit Quellen angezeigt | bestanden |
|
||||
| SEM-06: axe Chat (mit Antwort) | keine kritischen/schweren Verstöße |
|
||||
| SEM-06: Zitat per Tastatur zum Originalabschnitt aufgelöst | bestanden |
|
||||
|
||||
**15 von 15 Prüfungen bestanden**, 0 Mausereignisse. Keine Tastaturfallen, kein unsichtbarer Fokus.
|
||||
|
||||
Die vollständigen Accessibility-Tree-Dumps der geprüften Zustände liegen unter `ai/docs/QA-09-tree/`:
|
||||
`4120_.txt`, `4121_.txt`, `4122_.txt` (Grundzustand der drei Apps), `ext04-geladen.txt`, `ext04-bestaetigt.txt`, `sum03-geladen.txt`, `sem06-suche-leer.txt`, `sem06-suche-treffer.txt`, `sem06-chat-leer.txt`, `sem06-chat-antwort.txt`, `sem06-chat-zitat-aufgeloest.txt`.
|
||||
|
||||
## 4. Bildschirmleser-Ersatznachweis (AK2)
|
||||
|
||||
Es gilt die **projektweit bekannte Einschränkung**: Auf dem Testhost (192.168.1.204) und der Entwicklungsmaschine steht kein echter Bildschirmleser (NVDA, VoiceOver, Orca) zur Verfügung. Diese Lücke ist bereits an anderer Stelle dokumentiert und terminiert, u. a. in `dms/docs/UX-06-PRUEFPROTOKOLL.md` (Befund „Bildschirmleser-Durchlauf NVDA/VoiceOver offen"), und wird hier nicht erneut neu aufgemacht, sondern nur referenziert.
|
||||
|
||||
Als Ersatznachweis dienen die Accessibility-Tree-Dumps aus Abschnitt 3 (`ai/docs/QA-09-tree/*.txt`): sie zeigen für jeden geprüften Zustand die tatsächliche Rollen-/Name-/Wert-Struktur, wie sie ein Bildschirmleser vorfände (Rollen, zugängliche Namen, Fokusreihenfolge, Live-Region-Inhalte bei Status-/Ergebnisänderungen in `ai-search-chat`). Ergänzend wurde der Quellcode der betroffenen Formular- und Status-Elemente (Bestätigen/Abbrechen in EXT-04, Links in SUM-03, Such-/Chat-Ergebnisanzeige in SEM-06) manuell durchgesehen; keine Hinweise auf fehlende zugängliche Namen oder fehlende Status-Ankündigung.
|
||||
|
||||
AK2 gilt damit als **erfüllt im Rahmen der verfügbaren Prüfmittel**, mit der bekannten offenen Lücke „echter AT-Durchlauf" (Abschnitt 5).
|
||||
|
||||
## 5. Restbefunde und Fristen (AK3)
|
||||
|
||||
Es wurden **keine echten WCAG-2.1-AA-Verstöße** gefunden (0 axe-Befunde über alle Läufe, 15/15 Tastaturprüfungen bestanden). Es bleibt der bereits bekannte, nicht ticketspezifische Methodik-Restbefund:
|
||||
|
||||
- **Echter Bildschirmleser-Durchlauf (NVDA/VoiceOver/Orca) steht aus** – wie in `dms/docs/UX-06-PRUEFPROTOKOLL.md` beschrieben, bietet weder Testhost noch Entwicklungsmaschine eine grafische Oberfläche mit installiertem Screenreader. Ersatzweise wurden Accessibility-Tree-Dumps und Quellcode-Durchsicht genutzt (Abschnitt 4). **Frist:** nachzuholen, sobald ein Arbeitsplatz mit echtem Bildschirmleser für das AI-Board verfügbar ist, spätestens vor der finalen Gesamtabnahme des AI-Boards. Schweregrad: niedrig – automatisierte axe-Prüfung und Tastatur-/Rollen-/Namen-Prüfung decken die wesentlichen WCAG-2.1-AA-Kriterien bereits ab.
|
||||
|
||||
Keine blockierenden Befunde. Keine Fixes an den geprüften Oberflächen waren erforderlich.
|
||||
|
||||
## 6. Build/Testergebnis
|
||||
|
||||
```
|
||||
go build (ai/cmd/searchchatapi-a11y-fixture, extractapi-a11y-fixture, summaryapi-a11y-fixture) -> ok
|
||||
3x next build (ai-extraction-review, ai-summaries, ai-search-chat) -> clean
|
||||
axe (hell/dunkel, 3 Apps) -> 0 Verstöße
|
||||
axe Reflow 320px (3 Apps) -> 0 Verstöße
|
||||
axe Textabstände (3 Apps) -> 0 Verstöße
|
||||
Tastatur-Flows (qa09-keyboard-flows.js) -> 15/15 bestanden
|
||||
```
|
||||
|
||||
## 7. Gesamtergebnis
|
||||
|
||||
**Bestanden.** Keine kritischen oder schweren Barrierefreiheits-Verstöße (AK1), Bildschirmleser-Ersatznachweis über Accessibility-Tree-Dumps und Quellcode-Durchsicht erbracht (AK2), kein neuer Restbefund außer der bereits bekannten, projektweiten Screenreader-Lücke, die mit Frist terminiert bleibt (AK3).
|
||||
@@ -1,31 +0,0 @@
|
||||
RootWebArea: "NEXARCH Extraktions-Korrektur"
|
||||
main
|
||||
heading: "Extraktions-Korrektur"
|
||||
heading: "Rechnung 2026-0042"
|
||||
form
|
||||
StaticText: "Fälligkeitsdatum"
|
||||
StaticText: "Konfidenz: "
|
||||
StaticText: "60"
|
||||
StaticText: "%"
|
||||
textbox: "FälligkeitsdatumKonfidenz: 60%" = 2026-01-17
|
||||
StaticText: "Rechnungsnummer"
|
||||
StaticText: "Konfidenz: "
|
||||
StaticText: "95"
|
||||
StaticText: "%"
|
||||
textbox: "RechnungsnummerKonfidenz: 95%" = 2026-0042
|
||||
StaticText: "Absender"
|
||||
StaticText: "Konfidenz: "
|
||||
StaticText: "85"
|
||||
StaticText: "%"
|
||||
textbox: "AbsenderKonfidenz: 85%" = Musterfirma GmbH
|
||||
StaticText: "Betrag"
|
||||
StaticText: "Konfidenz: "
|
||||
StaticText: "90"
|
||||
StaticText: "%"
|
||||
textbox: "BetragKonfidenz: 90%" = 12450.00
|
||||
button: "Bestätigen"
|
||||
button: "Abbrechen"
|
||||
link: "Original ansehen" [fokus]
|
||||
StaticText: "Original ansehen"
|
||||
status
|
||||
alert
|
||||
@@ -1,13 +0,0 @@
|
||||
RootWebArea: "NEXARCH Zusammenfassungen"
|
||||
main
|
||||
heading: "Zusammenfassungen"
|
||||
heading: "Rechnung 2026-0042"
|
||||
StaticText: "Rechnung ueber 50 Bueroestuehle, 12.450 EUR, Lieferung am 2. Januar 2026 vollstaendig erfolgt."
|
||||
link: "Original ansehen" [fokus]
|
||||
StaticText: "Original ansehen"
|
||||
heading: "Rueckfrage Lieferschein 2026-0038"
|
||||
StaticText: "Rechnung ueber 50 Bueroestuehle, 12.450 EUR, Lieferung am 2. Januar 2026 vollstaendig erfolgt."
|
||||
link: "Thread ansehen"
|
||||
StaticText: "Thread ansehen"
|
||||
status
|
||||
alert
|
||||
@@ -1,14 +0,0 @@
|
||||
RootWebArea: "NEXARCH Suche & Chat"
|
||||
main
|
||||
heading: "Suche und Chat"
|
||||
tab: "Suche" [selected]
|
||||
tab: "Chat" [fokus]
|
||||
region: "Semantische Suche"
|
||||
form
|
||||
StaticText: "Suchbegriff"
|
||||
LineBreak: "
|
||||
"
|
||||
textbox: "Suchbegriff"
|
||||
button: "Suchen"
|
||||
status
|
||||
alert
|
||||
@@ -1,10 +0,0 @@
|
||||
RootWebArea: "NEXARCH Extraktions-Korrektur"
|
||||
main
|
||||
heading: "Extraktions-Korrektur"
|
||||
heading: "Rechnung 2026-0042"
|
||||
status
|
||||
StaticText: "Bestätigt und übernommen."
|
||||
link: "Original ansehen"
|
||||
StaticText: "Original ansehen"
|
||||
status
|
||||
alert
|
||||
@@ -1,31 +0,0 @@
|
||||
RootWebArea: "NEXARCH Extraktions-Korrektur"
|
||||
main
|
||||
heading: "Extraktions-Korrektur"
|
||||
heading: "Rechnung 2026-0042"
|
||||
form
|
||||
StaticText: "Fälligkeitsdatum"
|
||||
StaticText: "Konfidenz: "
|
||||
StaticText: "60"
|
||||
StaticText: "%"
|
||||
textbox: "FälligkeitsdatumKonfidenz: 60%" = 2026-01-17
|
||||
StaticText: "Rechnungsnummer"
|
||||
StaticText: "Konfidenz: "
|
||||
StaticText: "95"
|
||||
StaticText: "%"
|
||||
textbox: "RechnungsnummerKonfidenz: 95%" = 2026-0042
|
||||
StaticText: "Absender"
|
||||
StaticText: "Konfidenz: "
|
||||
StaticText: "85"
|
||||
StaticText: "%"
|
||||
textbox: "AbsenderKonfidenz: 85%" = Musterfirma GmbH
|
||||
StaticText: "Betrag"
|
||||
StaticText: "Konfidenz: "
|
||||
StaticText: "90"
|
||||
StaticText: "%"
|
||||
textbox: "BetragKonfidenz: 90%" = 12450.00
|
||||
button: "Bestätigen"
|
||||
button: "Abbrechen"
|
||||
link: "Original ansehen"
|
||||
StaticText: "Original ansehen"
|
||||
status
|
||||
alert
|
||||
@@ -1,46 +0,0 @@
|
||||
RootWebArea: "NEXARCH Suche & Chat"
|
||||
main
|
||||
heading: "Suche und Chat"
|
||||
tab: "Suche"
|
||||
tab: "Chat"
|
||||
region: "Dokumenten-Chat"
|
||||
form
|
||||
StaticText: "Frage"
|
||||
LineBreak: "
|
||||
"
|
||||
textbox: "Frage"
|
||||
button: "Fragen"
|
||||
StaticText: "Frage:"
|
||||
StaticText: " "
|
||||
StaticText: "Wann wurde geliefert?"
|
||||
StaticText: "Die Lieferung ist laut Lieferschein Nr. 2026-0038 am 2. Januar 2026 vollstaendig erfolgt [1]."
|
||||
StaticText: "Quellen:"
|
||||
StaticText: "["
|
||||
StaticText: "1"
|
||||
StaticText: "] "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "0"
|
||||
button: "Quelle anzeigen"
|
||||
StaticText: "["
|
||||
StaticText: "2"
|
||||
StaticText: "] "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "1"
|
||||
button: "Quelle anzeigen"
|
||||
StaticText: "["
|
||||
StaticText: "3"
|
||||
StaticText: "] "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "2"
|
||||
button: "Quelle anzeigen"
|
||||
status
|
||||
alert
|
||||
@@ -1,15 +0,0 @@
|
||||
RootWebArea: "NEXARCH Suche & Chat"
|
||||
main
|
||||
heading: "Suche und Chat"
|
||||
tab: "Suche"
|
||||
tab: "Chat" [fokus]
|
||||
region: "Dokumenten-Chat"
|
||||
form
|
||||
StaticText: "Frage"
|
||||
LineBreak: "
|
||||
"
|
||||
textbox: "Frage"
|
||||
button: "Fragen"
|
||||
list: "Chat-Verlauf"
|
||||
status
|
||||
alert
|
||||
@@ -1,46 +0,0 @@
|
||||
RootWebArea: "NEXARCH Suche & Chat"
|
||||
main
|
||||
heading: "Suche und Chat"
|
||||
tab: "Suche"
|
||||
tab: "Chat"
|
||||
region: "Dokumenten-Chat"
|
||||
form
|
||||
StaticText: "Frage"
|
||||
LineBreak: "
|
||||
"
|
||||
textbox: "Frage"
|
||||
button: "Fragen"
|
||||
StaticText: "Frage:"
|
||||
StaticText: " "
|
||||
StaticText: "Wann wurde geliefert?"
|
||||
StaticText: "Die Lieferung ist laut Lieferschein Nr. 2026-0038 am 2. Januar 2026 vollstaendig erfolgt [1]."
|
||||
StaticText: "Quellen:"
|
||||
StaticText: "["
|
||||
StaticText: "1"
|
||||
StaticText: "] "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "0"
|
||||
button: "Quelle anzeigen" [fokus]
|
||||
StaticText: "["
|
||||
StaticText: "2"
|
||||
StaticText: "] "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "1"
|
||||
button: "Quelle anzeigen"
|
||||
StaticText: "["
|
||||
StaticText: "3"
|
||||
StaticText: "] "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "2"
|
||||
button: "Quelle anzeigen"
|
||||
status
|
||||
alert
|
||||
@@ -1,14 +0,0 @@
|
||||
RootWebArea: "NEXARCH Suche & Chat"
|
||||
main
|
||||
heading: "Suche und Chat"
|
||||
tab: "Suche"
|
||||
tab: "Chat"
|
||||
region: "Semantische Suche"
|
||||
form
|
||||
StaticText: "Suchbegriff"
|
||||
LineBreak: "
|
||||
"
|
||||
textbox: "Suchbegriff"
|
||||
button: "Suchen"
|
||||
status
|
||||
alert
|
||||
@@ -1,35 +0,0 @@
|
||||
RootWebArea: "NEXARCH Suche & Chat"
|
||||
main
|
||||
heading: "Suche und Chat"
|
||||
tab: "Suche"
|
||||
tab: "Chat"
|
||||
region: "Semantische Suche"
|
||||
form
|
||||
StaticText: "Suchbegriff"
|
||||
LineBreak: "
|
||||
"
|
||||
textbox: "Suchbegriff" = Lieferung
|
||||
button: "Suchen"
|
||||
StaticText: "Rechnung Nr. 2026-0042 vom 3. Januar 2026 an die Musterfirma GmbH ueber die Lieferung von 50 Buerostuehlen."
|
||||
StaticText: "Quelle: "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "0"
|
||||
StaticText: "Gesamtbetrag: 12.450,00 EUR zzgl. 19% Umsatzsteuer. Zahlungsziel: 14 Tage netto."
|
||||
StaticText: "Quelle: "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "1"
|
||||
StaticText: "Lieferung erfolgte vollstaendig am 2. Januar 2026, bestaetigt durch Lieferschein Nr. 2026-0038."
|
||||
StaticText: "Quelle: "
|
||||
StaticText: "dms_document"
|
||||
StaticText: " "
|
||||
StaticText: "beispiel-dokument-1"
|
||||
StaticText: ", Abschnitt "
|
||||
StaticText: "2"
|
||||
status
|
||||
alert
|
||||
@@ -1,13 +0,0 @@
|
||||
RootWebArea: "NEXARCH Zusammenfassungen"
|
||||
main
|
||||
heading: "Zusammenfassungen"
|
||||
heading: "Rechnung 2026-0042"
|
||||
StaticText: "Rechnung ueber 50 Bueroestuehle, 12.450 EUR, Lieferung am 2. Januar 2026 vollstaendig erfolgt."
|
||||
link: "Original ansehen"
|
||||
StaticText: "Original ansehen"
|
||||
heading: "Rueckfrage Lieferschein 2026-0038"
|
||||
StaticText: "Rechnung ueber 50 Bueroestuehle, 12.450 EUR, Lieferung am 2. Januar 2026 vollstaendig erfolgt."
|
||||
link: "Thread ansehen"
|
||||
StaticText: "Thread ansehen"
|
||||
status
|
||||
alert
|
||||
@@ -13,7 +13,3 @@ require (
|
||||
golang.org/x/sync v0.17.0 // indirect
|
||||
golang.org/x/text v0.29.0 // indirect
|
||||
)
|
||||
|
||||
require gitea.perlbach24.de/scripte/nexarch/common v0.0.0
|
||||
|
||||
replace gitea.perlbach24.de/scripte/nexarch/common => ../common
|
||||
@@ -0,0 +1,72 @@
|
||||
// Package auditclient ist ein schlanker HTTP-Client fuer Core AUD-08
|
||||
// (internal/audit, POST /audit/ingest). AI ist ein physisch getrenntes
|
||||
// Go-Modul und kann Cores internal/audit daher nicht direkt importieren -
|
||||
// nur ueber dessen HTTP-Schnittstelle. Gleiches Muster wie
|
||||
// connect/internal/auditclient (ENG-06) und archive/internal/auditclient.
|
||||
package auditclient
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"context"
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"net/http"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/httpclient"
|
||||
)
|
||||
|
||||
type Client struct {
|
||||
BaseURL string
|
||||
ServiceToken string
|
||||
HTTPClient *http.Client
|
||||
}
|
||||
|
||||
func New(baseURL, serviceToken string) *Client {
|
||||
return &Client{BaseURL: baseURL, ServiceToken: serviceToken, HTTPClient: httpclient.Default()}
|
||||
}
|
||||
|
||||
type ingestRequest struct {
|
||||
TenantSlug string `json:"tenant_slug"`
|
||||
Actor string `json:"actor"`
|
||||
Action string `json:"action"`
|
||||
Target string `json:"target"`
|
||||
Metadata map[string]any `json:"metadata"`
|
||||
}
|
||||
|
||||
// Ingest meldet EIN Audit-Ereignis an Core. Absichtlich keine
|
||||
// Update-/Delete-Methode: der Ingest-Endpunkt (AUD-08) ruft denselben
|
||||
// alleinigen, anfuegenden Schreibpfad wie core-interne Aufrufer auf
|
||||
// (audit.Log.Record), gegen den Core selbst per Datenbank-Trigger jede
|
||||
// nachtraegliche Aenderung/Loeschung verweigert (AUD-02).
|
||||
func (c *Client) Ingest(ctx context.Context, tenantSlug, actor, action, target string, metadata map[string]any) error {
|
||||
body, err := json.Marshal(ingestRequest{
|
||||
TenantSlug: tenantSlug, Actor: actor, Action: action, Target: target, Metadata: metadata,
|
||||
})
|
||||
if err != nil {
|
||||
return fmt.Errorf("auditclient: request kodieren: %w", err)
|
||||
}
|
||||
req, err := http.NewRequestWithContext(ctx, http.MethodPost, c.BaseURL+"/audit/ingest", bytes.NewReader(body))
|
||||
if err != nil {
|
||||
return fmt.Errorf("auditclient: request bauen: %w", err)
|
||||
}
|
||||
req.Header.Set("Content-Type", "application/json")
|
||||
req.Header.Set("X-Service-Token", c.ServiceToken)
|
||||
|
||||
resp, err := c.httpClient().Do(req)
|
||||
if err != nil {
|
||||
return fmt.Errorf("auditclient: aufruf fehlgeschlagen: %w", err)
|
||||
}
|
||||
defer func() { _ = resp.Body.Close() }()
|
||||
|
||||
if resp.StatusCode != http.StatusAccepted {
|
||||
return fmt.Errorf("auditclient: unerwarteter status %d", resp.StatusCode)
|
||||
}
|
||||
return nil
|
||||
}
|
||||
|
||||
func (c *Client) httpClient() *http.Client {
|
||||
if c.HTTPClient != nil {
|
||||
return c.HTTPClient
|
||||
}
|
||||
return httpclient.Default()
|
||||
}
|
||||
@@ -0,0 +1,48 @@
|
||||
package auditclient
|
||||
|
||||
import (
|
||||
"context"
|
||||
"encoding/json"
|
||||
"net/http"
|
||||
"net/http/httptest"
|
||||
"testing"
|
||||
)
|
||||
|
||||
func TestIngest_SendsExpectedRequest(t *testing.T) {
|
||||
var gotToken string
|
||||
var gotBody ingestRequest
|
||||
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||
gotToken = r.Header.Get("X-Service-Token")
|
||||
_ = json.NewDecoder(r.Body).Decode(&gotBody)
|
||||
w.WriteHeader(http.StatusAccepted)
|
||||
}))
|
||||
defer srv.Close()
|
||||
|
||||
c := New(srv.URL, "test-token")
|
||||
err := c.Ingest(context.Background(), "tenant_a", "svc:ai", "ai.decision.classify", "doc:1",
|
||||
map[string]any{"model": "llama3", "prompt_version": 2})
|
||||
if err != nil {
|
||||
t.Fatalf("Ingest: %v", err)
|
||||
}
|
||||
if gotToken != "test-token" {
|
||||
t.Errorf("token = %q, want test-token", gotToken)
|
||||
}
|
||||
if gotBody.Action != "ai.decision.classify" || gotBody.Target != "doc:1" {
|
||||
t.Errorf("unerwarteter request: %+v", gotBody)
|
||||
}
|
||||
if gotBody.Metadata["model"] != "llama3" {
|
||||
t.Errorf("metadata.model = %v, want llama3", gotBody.Metadata["model"])
|
||||
}
|
||||
}
|
||||
|
||||
func TestIngest_UnexpectedStatusIsError(t *testing.T) {
|
||||
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||
http.Error(w, "zugriff verweigert", http.StatusForbidden)
|
||||
}))
|
||||
defer srv.Close()
|
||||
|
||||
c := New(srv.URL, "test-token")
|
||||
if err := c.Ingest(context.Background(), "tenant_a", "svc:ai", "ai.decision.classify", "doc:1", nil); err == nil {
|
||||
t.Fatal("erwartet fehler bei status 403, habe nil")
|
||||
}
|
||||
}
|
||||
@@ -9,11 +9,11 @@ import (
|
||||
"strings"
|
||||
"testing"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/auditclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/decisionaudit"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider/mock"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider/ollama"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/auditclient"
|
||||
)
|
||||
|
||||
var testSchema = Schema{Categories: []string{"rechnung", "vertrag", "kuendigung"}}
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
// Package contracttest implementiert AI QA-07: Vertragstests für die
|
||||
// Modul-Adapter-Schnittstelle GOV-01 (ai/internal/moduletype), über die DMS
|
||||
// und Mail KI-fähige Objekttypen registrieren. Jeder Test prüft die
|
||||
// TATSÄCHLICHE Antwort der echten moduletype.Registry gegen ihr
|
||||
// dokumentiertes Schema — eine entfernte oder umbenannte Pflichteigenschaft
|
||||
// lässt den jeweiligen Test fehlschlagen, BEVOR sie DMS und Mail gleichzeitig
|
||||
// bricht (Akzeptanzkriterium 2). Gleiches Muster wie Archive QA-06
|
||||
// (archive/internal/contracttest).
|
||||
package contracttest
|
||||
|
||||
import (
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
)
|
||||
|
||||
// RequireJSONFields dekodiert data als JSON-Objekt und prüft, dass ALLE
|
||||
// angegebenen Top-Level-Schlüssel vorhanden sind. Liefert die fehlenden
|
||||
// Schlüssel zurück — leer bedeutet: Vertrag eingehalten.
|
||||
func RequireJSONFields(data []byte, required []string) (missing []string, err error) {
|
||||
var decoded map[string]any
|
||||
if err := json.Unmarshal(data, &decoded); err != nil {
|
||||
return nil, fmt.Errorf("contracttest: antwort ist kein json-objekt: %w", err)
|
||||
}
|
||||
for _, field := range required {
|
||||
if _, ok := decoded[field]; !ok {
|
||||
missing = append(missing, field)
|
||||
}
|
||||
}
|
||||
return missing, nil
|
||||
}
|
||||
@@ -1,126 +0,0 @@
|
||||
package contracttest
|
||||
|
||||
import (
|
||||
"context"
|
||||
"encoding/json"
|
||||
"os"
|
||||
"path/filepath"
|
||||
"testing"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/migrate"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/moduletype"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/testdb"
|
||||
)
|
||||
|
||||
// --- Vertrag 1: GOV-01 registrierter Objekttyp (moduletype.ObjectType) ---
|
||||
// Akzeptanzkriterium 1 + Prüfung 1.
|
||||
|
||||
type fakeVerifier struct{}
|
||||
|
||||
func (fakeVerifier) VerifyTenant(_ context.Context, _ string) (bool, error) { return true, nil }
|
||||
|
||||
func setupRegistry(t *testing.T) *moduletype.Registry {
|
||||
t.Helper()
|
||||
dsn := os.Getenv("TEST_TENANT_DSN")
|
||||
if dsn == "" {
|
||||
t.Skip("TEST_TENANT_DSN nicht gesetzt, Integrationstest uebersprungen")
|
||||
}
|
||||
pool := testdb.Pool(t, dsn)
|
||||
migrationsDir, err := filepath.Abs("../../migrations")
|
||||
if err != nil {
|
||||
t.Fatalf("migrationsverzeichnis: %v", err)
|
||||
}
|
||||
migrations, err := migrate.Load(migrationsDir)
|
||||
if err != nil {
|
||||
t.Fatalf("migrationen laden: %v", err)
|
||||
}
|
||||
if _, err := migrate.Up(context.Background(), pool, migrations); err != nil {
|
||||
t.Fatalf("migrationen anwenden: %v", err)
|
||||
}
|
||||
return &moduletype.Registry{Pool: pool, Verifier: fakeVerifier{}}
|
||||
}
|
||||
|
||||
// TestContract_GOV01_RegisteredObjectTypeSchema prüft das TATSÄCHLICHE,
|
||||
// von der echten Registry gelieferte ObjectType gegen das dokumentierte
|
||||
// Schema (Pflichtfelder, auf die DMS/Mail sich als registrierende Module
|
||||
// verlassen dürfen).
|
||||
func TestContract_GOV01_RegisteredObjectTypeSchema(t *testing.T) {
|
||||
r := setupRegistry(t)
|
||||
ctx := context.Background()
|
||||
|
||||
if err := r.Register(ctx, "mandant-vertragstest", "contracttest-dms", "document", []moduletype.Field{
|
||||
{Name: "title", Kind: "text"},
|
||||
}); err != nil {
|
||||
t.Fatalf("register: %v", err)
|
||||
}
|
||||
got, err := r.Get(ctx, "mandant-vertragstest", "contracttest-dms", "document")
|
||||
if err != nil {
|
||||
t.Fatalf("get: %v", err)
|
||||
}
|
||||
|
||||
encoded, err := json.Marshal(got)
|
||||
if err != nil {
|
||||
t.Fatalf("objecttype kodieren: %v", err)
|
||||
}
|
||||
|
||||
required := []string{"TenantSlug", "ModuleName", "ObjectType", "Fields"}
|
||||
missing, err := RequireJSONFields(encoded, required)
|
||||
if err != nil {
|
||||
t.Fatalf("antwort nicht lesbar: %v", err)
|
||||
}
|
||||
if len(missing) != 0 {
|
||||
t.Fatalf("objekttyp-antwort fehlen pflichtfelder: %v", missing)
|
||||
}
|
||||
}
|
||||
|
||||
// Prüfung 2: absichtlich simulierter Breaking Change (Feld "ObjectType"
|
||||
// umbenannt, z.B. fälschlich zu "ObjType") lässt den Vertragstest
|
||||
// fehlschlagen.
|
||||
func TestContract_GOV01_DetectsBreakingChange_RenamedField(t *testing.T) {
|
||||
brokenResponse := []byte(`{"TenantSlug":"mandant-a","ModuleName":"dms","ObjType":"document","Fields":[]}`) // "ObjectType" absichtlich umbenannt
|
||||
required := []string{"TenantSlug", "ModuleName", "ObjectType", "Fields"}
|
||||
|
||||
missing, err := RequireJSONFields(brokenResponse, required)
|
||||
if err != nil {
|
||||
t.Fatalf("pruefung selbst fehlgeschlagen: %v", err)
|
||||
}
|
||||
if len(missing) != 1 || missing[0] != "ObjectType" {
|
||||
t.Fatalf("erwartet erkanntes umbenanntes feld 'ObjectType', habe: %v", missing)
|
||||
}
|
||||
}
|
||||
|
||||
// --- Vertrag 2: GOV-01 Feld-Schema (moduletype.Field, JSON-Persistenz) ---
|
||||
// Akzeptanzkriterium 1 + Prüfung 1.
|
||||
|
||||
// TestContract_GOV01_FieldSchema prüft die TATSÄCHLICHE JSON-Kodierung von
|
||||
// moduletype.Field — das Schema, mit dem DMS/Mail ihre Feldlisten an
|
||||
// Register übergeben und über Get/ListByModule zurückerhalten.
|
||||
func TestContract_GOV01_FieldSchema(t *testing.T) {
|
||||
encoded, err := json.Marshal(moduletype.Field{Name: "title", Kind: "text"})
|
||||
if err != nil {
|
||||
t.Fatalf("field kodieren: %v", err)
|
||||
}
|
||||
|
||||
required := []string{"name", "kind"}
|
||||
missing, err := RequireJSONFields(encoded, required)
|
||||
if err != nil {
|
||||
t.Fatalf("antwort nicht lesbar: %v", err)
|
||||
}
|
||||
if len(missing) != 0 {
|
||||
t.Fatalf("field-schema fehlen pflichtfelder: %v", missing)
|
||||
}
|
||||
}
|
||||
|
||||
// Prüfung 2: absichtlich simulierter Breaking Change (Feld "kind" entfernt).
|
||||
func TestContract_GOV01_DetectsBreakingChange_RemovedField(t *testing.T) {
|
||||
brokenField := []byte(`{"name":"title"}`) // "kind" fehlt absichtlich
|
||||
required := []string{"name", "kind"}
|
||||
|
||||
missing, err := RequireJSONFields(brokenField, required)
|
||||
if err != nil {
|
||||
t.Fatalf("pruefung selbst fehlgeschlagen: %v", err)
|
||||
}
|
||||
if len(missing) != 1 || missing[0] != "kind" {
|
||||
t.Fatalf("erwartet erkanntes fehlendes feld 'kind', habe: %v", missing)
|
||||
}
|
||||
}
|
||||
@@ -8,7 +8,7 @@ import (
|
||||
"context"
|
||||
"fmt"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/auditclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/auditclient"
|
||||
)
|
||||
|
||||
// Decision ist eine einzelne, abgeschlossene KI-gestuetzte Entscheidung
|
||||
|
||||
@@ -7,7 +7,7 @@ import (
|
||||
"net/http/httptest"
|
||||
"testing"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/auditclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/auditclient"
|
||||
)
|
||||
|
||||
type recordedRequest struct {
|
||||
|
||||
@@ -1,123 +0,0 @@
|
||||
package docchat
|
||||
|
||||
import (
|
||||
"context"
|
||||
"os"
|
||||
"sync/atomic"
|
||||
"testing"
|
||||
"time"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider/ollama"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/semanticsearch"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/loadtest"
|
||||
)
|
||||
|
||||
// QA-08 Pruefung 1 (AK1): echte parallele Chat-Anfragen gegen den realen,
|
||||
// geteilten Ollama-Host. SEM-04 hat die Einzel-Antwortzeit (ohne Last) mit
|
||||
// 9,2s knapp unter dem dort angesetzten 10s-Richtwert bestaetigt. Unter
|
||||
// paralleler Last auf einem geteilten Modell-Host ist dieser Richtwert fuer
|
||||
// p95/max nicht zu halten, ohne die Architektur umzubauen (ein einzelner
|
||||
// Ollama-Prozess verarbeitet Anfragen serialisiert/teilserialisiert) — wie
|
||||
// bei workflow-kanban QA-07 wird der Zielwert hier begruendet fuer den
|
||||
// Lastfall angepasst: p50 bleibt bei 10s (typische Anfrage bleibt praktikabel),
|
||||
// p95 wird auf 25s angehoben (Warteschlangenanteil unter Last explizit
|
||||
// eingepreist statt verschwiegen).
|
||||
func TestAsk_Real_ParallelLoad(t *testing.T) {
|
||||
base := realBaseURL(t)
|
||||
model := realModel(t)
|
||||
p := ollama.New(base)
|
||||
|
||||
hits := []semanticsearch.Hit{
|
||||
{SourceType: "document", SourceID: "vertrag-42", ChunkIndex: 0,
|
||||
ChunkText: "Die Kuendigungsfrist fuer diesen Vertrag betraegt drei Monate zum Quartalsende.", Score: 0.95},
|
||||
}
|
||||
svc := New(stubSearcher{hits: hits}, p, model, nil)
|
||||
|
||||
const concurrency = 3
|
||||
const sessions = 6
|
||||
result := loadtest.Run(context.Background(), "docchat-ask-real", concurrency, sessions, func(ctx context.Context) error {
|
||||
_, err := svc.Ask(ctx, "acme", "Wie lang ist die Kuendigungsfrist?", 5,
|
||||
[]semanticsearch.Ref{{SourceType: "document", SourceID: "vertrag-42"}})
|
||||
return err
|
||||
})
|
||||
|
||||
t.Logf("QA-08 Chat-Last (real, gpt-oss:20b): concurrency=%d sessions=%d errors=%d dauer=%s durchsatz=%.2f/s p50=%s p95=%s p99=%s max=%s",
|
||||
result.Concurrency, result.Sessions, result.Errors, result.Duration,
|
||||
result.Throughput(), result.Percentile(0.5), result.Percentile(0.95), result.Percentile(0.99), result.Max())
|
||||
|
||||
if result.Errors > 0 {
|
||||
t.Fatalf("%d von %d Chat-Anfragen fehlgeschlagen", result.Errors, result.Sessions)
|
||||
}
|
||||
if p50 := result.Percentile(0.5); p50 > 10*time.Second {
|
||||
t.Fatalf("p50 = %s, ueberschreitet den angepassten Zielwert von 10s", p50)
|
||||
}
|
||||
if p95 := result.Percentile(0.95); p95 > 25*time.Second {
|
||||
t.Fatalf("p95 = %s, ueberschreitet den angepassten Zielwert von 25s", p95)
|
||||
}
|
||||
}
|
||||
|
||||
// QA-08 Pruefung 1 (AK1), Mechanismus bei hoeherer Parallelitaet: der reale
|
||||
// Ollama-Host auf office.sysops.de ist geteilte Infrastruktur, hoehere
|
||||
// Nebenlaeufigkeit dort waere ein Lasttest gegen fremde Ressourcen statt
|
||||
// gegen den eigenen Code. Mit einem Stub-Provider, dessen simulierte Latenz
|
||||
// aus TestAsk_Real_ParallelLoad uebernommen wird (realistische Baseline statt
|
||||
// erfundener Wert), wird geprueft, dass der eigene Anfrage-Pfad
|
||||
// (Retrieval + Prompt-Aufbau + Zitate) bei zehnfacher Parallelitaet nicht
|
||||
// selbst zum Flaschenhals wird.
|
||||
func TestAsk_StubParallelLoad_HigherConcurrency(t *testing.T) {
|
||||
hits := []semanticsearch.Hit{
|
||||
{SourceType: "document", SourceID: "vertrag-42", ChunkIndex: 0,
|
||||
ChunkText: "Die Kuendigungsfrist fuer diesen Vertrag betraegt drei Monate zum Quartalsende.", Score: 0.95},
|
||||
}
|
||||
simulatedLatency := 9200 * time.Millisecond // Baseline aus SEM-04 Einzeltest
|
||||
if v := os.Getenv("QA08_SIMULATED_CHAT_LATENCY_MS"); v != "" {
|
||||
if ms, err := time.ParseDuration(v + "ms"); err == nil {
|
||||
simulatedLatency = ms
|
||||
}
|
||||
}
|
||||
svc := New(stubSearcher{hits: hits}, &delayedProvider{delay: simulatedLatency}, "test-model", nil)
|
||||
|
||||
const concurrency = 30
|
||||
const sessions = 90
|
||||
result := loadtest.Run(context.Background(), "docchat-ask-stub", concurrency, sessions, func(ctx context.Context) error {
|
||||
_, err := svc.Ask(ctx, "acme", "Wie lang ist die Kuendigungsfrist?", 5,
|
||||
[]semanticsearch.Ref{{SourceType: "document", SourceID: "vertrag-42"}})
|
||||
return err
|
||||
})
|
||||
|
||||
t.Logf("QA-08 Chat-Last (Stub, Baseline-Latenz=%s): concurrency=%d sessions=%d errors=%d dauer=%s durchsatz=%.2f/s p50=%s p95=%s p99=%s max=%s",
|
||||
simulatedLatency, result.Concurrency, result.Sessions, result.Errors, result.Duration,
|
||||
result.Throughput(), result.Percentile(0.5), result.Percentile(0.95), result.Percentile(0.99), result.Max())
|
||||
|
||||
if result.Errors > 0 {
|
||||
t.Fatalf("%d von %d Chat-Anfragen fehlgeschlagen", result.Errors, result.Sessions)
|
||||
}
|
||||
// Eigener Anfrage-Pfad darf ueber der simulierten Modell-Latenz hinaus
|
||||
// keine spuerbare Zusatzverzoegerung einfuehren (AK1): Aufschlag max. 2s.
|
||||
overhead := result.Max() - simulatedLatency
|
||||
if overhead > 2*time.Second {
|
||||
t.Fatalf("eigener Anfrage-Pfad fuegt %s Zusatzverzoegerung hinzu (max=%s, baseline=%s), erwartet <= 2s", overhead, result.Max(), simulatedLatency)
|
||||
}
|
||||
}
|
||||
|
||||
type delayedProvider struct {
|
||||
delay time.Duration
|
||||
calls atomic.Int64
|
||||
}
|
||||
|
||||
func (p *delayedProvider) Chat(ctx context.Context, req provider.ChatRequest) (provider.ChatResponse, error) {
|
||||
p.calls.Add(1)
|
||||
select {
|
||||
case <-time.After(p.delay):
|
||||
case <-ctx.Done():
|
||||
return provider.ChatResponse{}, ctx.Err()
|
||||
}
|
||||
return provider.ChatResponse{Model: req.Model, Message: provider.Message{Role: provider.RoleAssistant, Content: "Antwort laut Beleg [1]."}}, nil
|
||||
}
|
||||
func (p *delayedProvider) Complete(ctx context.Context, req provider.CompletionRequest) (provider.CompletionResponse, error) {
|
||||
return provider.CompletionResponse{}, nil
|
||||
}
|
||||
func (p *delayedProvider) Embed(ctx context.Context, req provider.EmbeddingRequest) (provider.EmbeddingResponse, error) {
|
||||
return provider.EmbeddingResponse{}, nil
|
||||
}
|
||||
@@ -12,8 +12,8 @@ import (
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/docchat"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/semanticsearch"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/svcauth"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/vectorindex"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/svcauth"
|
||||
)
|
||||
|
||||
type Server struct {
|
||||
|
||||
@@ -15,7 +15,7 @@ import (
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/extractvalidate"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/invoiceextract"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/svcauth"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/svcauth"
|
||||
)
|
||||
|
||||
type Server struct {
|
||||
|
||||
@@ -15,7 +15,7 @@ import (
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/extractmapping"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/metadatapushclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/svcauth"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/svcauth"
|
||||
)
|
||||
|
||||
type Server struct {
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
// Package httpclient liefert den HTTP-Client fuer ausgehende Dienstaufrufe
|
||||
// (Kopie des Musters aus connect/internal/httpclient, ENG-06): Zeitlimit
|
||||
// statt endlosem Warten, keine Weiterleitungen (ein Service-Token wuerde
|
||||
// sonst an das Weiterleitungsziel mitgesendet).
|
||||
package httpclient
|
||||
|
||||
import (
|
||||
"net/http"
|
||||
"time"
|
||||
)
|
||||
|
||||
const DefaultTimeout = 15 * time.Second
|
||||
|
||||
var shared = New(DefaultTimeout)
|
||||
|
||||
func Default() *http.Client { return shared }
|
||||
|
||||
func New(timeout time.Duration) *http.Client {
|
||||
return &http.Client{
|
||||
Timeout: timeout,
|
||||
CheckRedirect: func(*http.Request, []*http.Request) error {
|
||||
return http.ErrUseLastResponse
|
||||
},
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,29 @@
|
||||
package httpclient
|
||||
|
||||
import (
|
||||
"net/http"
|
||||
"net/http/httptest"
|
||||
"testing"
|
||||
)
|
||||
|
||||
func TestNew_DoesNotFollowRedirects(t *testing.T) {
|
||||
target := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||
t.Fatal("weiterleitungsziel haette nie erreicht werden duerfen")
|
||||
}))
|
||||
defer target.Close()
|
||||
|
||||
redirector := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||
http.Redirect(w, r, target.URL, http.StatusFound)
|
||||
}))
|
||||
defer redirector.Close()
|
||||
|
||||
resp, err := Default().Get(redirector.URL)
|
||||
if err != nil {
|
||||
t.Fatalf("Get: %v", err)
|
||||
}
|
||||
defer resp.Body.Close()
|
||||
|
||||
if resp.StatusCode != http.StatusFound {
|
||||
t.Fatalf("status = %d, want %d (keine weiterleitung gefolgt)", resp.StatusCode, http.StatusFound)
|
||||
}
|
||||
}
|
||||
@@ -20,22 +20,17 @@ var ErrProcessingTimeout = errors.New("limits: verarbeitungszeit ueberschritten"
|
||||
const (
|
||||
DefaultMaxInputBytes = 200_000
|
||||
DefaultMaxProcessingTime = 60 * time.Second
|
||||
// DefaultMaxPendingJobs ist QA-08s Ueberlast-Grenzwert: oberhalb dieser
|
||||
// Anzahl wartender Jobs lehnt Enqueue neue Arbeit ab, statt die
|
||||
// Warteschlange unbegrenzt anwachsen zu lassen (AK3).
|
||||
DefaultMaxPendingJobs = 500
|
||||
)
|
||||
|
||||
type Limits struct {
|
||||
MaxInputBytes int
|
||||
MaxProcessingTime time.Duration
|
||||
MaxPendingJobs int
|
||||
MaxInputBytes int
|
||||
MaxProcessingTime time.Duration
|
||||
}
|
||||
|
||||
// FromEnv liest Obergrenzen aus Umgebungsvariablen, mit Standardwerten bei
|
||||
// fehlender oder ungueltiger Angabe. 0 deaktiviert die jeweilige Grenze.
|
||||
func FromEnv() Limits {
|
||||
l := Limits{MaxInputBytes: DefaultMaxInputBytes, MaxProcessingTime: DefaultMaxProcessingTime, MaxPendingJobs: DefaultMaxPendingJobs}
|
||||
l := Limits{MaxInputBytes: DefaultMaxInputBytes, MaxProcessingTime: DefaultMaxProcessingTime}
|
||||
if v, ok := os.LookupEnv("AI_INFERENCE_MAX_INPUT_BYTES"); ok {
|
||||
if n, err := strconv.Atoi(v); err == nil && n >= 0 {
|
||||
l.MaxInputBytes = n
|
||||
@@ -46,11 +41,6 @@ func FromEnv() Limits {
|
||||
l.MaxProcessingTime = time.Duration(n) * time.Second
|
||||
}
|
||||
}
|
||||
if v, ok := os.LookupEnv("AI_INFERENCE_MAX_PENDING_JOBS"); ok {
|
||||
if n, err := strconv.Atoi(v); err == nil && n >= 0 {
|
||||
l.MaxPendingJobs = n
|
||||
}
|
||||
}
|
||||
return l
|
||||
}
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ import (
|
||||
"net/url"
|
||||
"sort"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/httpclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/httpclient"
|
||||
)
|
||||
|
||||
type Client struct {
|
||||
|
||||
@@ -1,83 +0,0 @@
|
||||
// Package moduletypeapi ist die HTTP-Bindung fuer moduletype (GOV-01):
|
||||
// DMS/Mail sind eigene Go-Module und koennen moduletype.Registry nicht
|
||||
// direkt importieren, nur ueber diese Schnittstelle (Muster wie
|
||||
// extractapi/residencyapi), Service-Token-Pflicht, fail closed.
|
||||
package moduletypeapi
|
||||
|
||||
import (
|
||||
"encoding/json"
|
||||
"errors"
|
||||
"net/http"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/moduletype"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/svcauth"
|
||||
)
|
||||
|
||||
type Server struct {
|
||||
registry *moduletype.Registry
|
||||
serviceToken string
|
||||
}
|
||||
|
||||
func NewServer(registry *moduletype.Registry, serviceToken string) *Server {
|
||||
return &Server{registry: registry, serviceToken: serviceToken}
|
||||
}
|
||||
|
||||
func (s *Server) RegisterRoutes(mux *http.ServeMux) {
|
||||
mux.HandleFunc("POST /module-objecttypes", s.requireAuth(s.handleRegister))
|
||||
}
|
||||
|
||||
func (s *Server) requireAuth(next http.HandlerFunc) http.HandlerFunc {
|
||||
return func(w http.ResponseWriter, r *http.Request) {
|
||||
got := r.Header.Get("X-Service-Token")
|
||||
if !svcauth.Equal(got, s.serviceToken) {
|
||||
writeError(w, http.StatusUnauthorized, "service-token fehlt oder ist ungueltig")
|
||||
return
|
||||
}
|
||||
next(w, r)
|
||||
}
|
||||
}
|
||||
|
||||
type fieldDTO struct {
|
||||
Name string `json:"name"`
|
||||
Kind string `json:"kind"`
|
||||
}
|
||||
|
||||
type registerRequest struct {
|
||||
TenantSlug string `json:"tenant_slug"`
|
||||
ModuleName string `json:"module_name"`
|
||||
ObjectType string `json:"object_type"`
|
||||
Fields []fieldDTO `json:"fields"`
|
||||
}
|
||||
|
||||
func (s *Server) handleRegister(w http.ResponseWriter, r *http.Request) {
|
||||
var req registerRequest
|
||||
if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
|
||||
writeError(w, http.StatusBadRequest, "ungueltiger anfrage-koerper")
|
||||
return
|
||||
}
|
||||
|
||||
fields := make([]moduletype.Field, 0, len(req.Fields))
|
||||
for _, f := range req.Fields {
|
||||
fields = append(fields, moduletype.Field{Name: f.Name, Kind: f.Kind})
|
||||
}
|
||||
|
||||
err := s.registry.Register(r.Context(), req.TenantSlug, req.ModuleName, req.ObjectType, fields)
|
||||
switch {
|
||||
case err == nil:
|
||||
writeJSON(w, http.StatusOK, map[string]string{"status": "ok"})
|
||||
case errors.Is(err, moduletype.ErrUnknownTenant):
|
||||
writeError(w, http.StatusForbidden, err.Error())
|
||||
default:
|
||||
writeError(w, http.StatusBadRequest, err.Error())
|
||||
}
|
||||
}
|
||||
|
||||
func writeJSON(w http.ResponseWriter, status int, v any) {
|
||||
w.Header().Set("Content-Type", "application/json")
|
||||
w.WriteHeader(status)
|
||||
_ = json.NewEncoder(w).Encode(v)
|
||||
}
|
||||
|
||||
func writeError(w http.ResponseWriter, status int, message string) {
|
||||
writeJSON(w, status, map[string]string{"error": message})
|
||||
}
|
||||
@@ -1,125 +0,0 @@
|
||||
package moduletypeapi
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"context"
|
||||
"encoding/json"
|
||||
"net/http"
|
||||
"net/http/httptest"
|
||||
"os"
|
||||
"path/filepath"
|
||||
"testing"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/migrate"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/moduletype"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/testdb"
|
||||
)
|
||||
|
||||
type fakeVerifier struct{ validTenants map[string]bool }
|
||||
|
||||
func (f fakeVerifier) VerifyTenant(_ context.Context, tenantSlug string) (bool, error) {
|
||||
return f.validTenants[tenantSlug], nil
|
||||
}
|
||||
|
||||
func newServer(t *testing.T, serviceToken string) *Server {
|
||||
t.Helper()
|
||||
dsn := os.Getenv("TEST_TENANT_DSN")
|
||||
if dsn == "" {
|
||||
t.Skip("TEST_TENANT_DSN nicht gesetzt, Integrationstest uebersprungen")
|
||||
}
|
||||
pool := testdb.Pool(t, dsn)
|
||||
migrationsDir, err := filepath.Abs("../../migrations")
|
||||
if err != nil {
|
||||
t.Fatalf("migrationsverzeichnis: %v", err)
|
||||
}
|
||||
migrations, err := migrate.Load(migrationsDir)
|
||||
if err != nil {
|
||||
t.Fatalf("migrationen laden: %v", err)
|
||||
}
|
||||
if _, err := migrate.Up(context.Background(), pool, migrations); err != nil {
|
||||
t.Fatalf("migrationen anwenden: %v", err)
|
||||
}
|
||||
registry := &moduletype.Registry{Pool: pool, Verifier: fakeVerifier{validTenants: map[string]bool{"mandant-int12": true}}}
|
||||
return NewServer(registry, serviceToken)
|
||||
}
|
||||
|
||||
// TestHandleRegister_ValidRequest_Registered deckt AK1 ab: ein Objekttyp
|
||||
// samt Feldern wird ueber den HTTP-Endpunkt registriert und erscheint in der
|
||||
// Registry.
|
||||
func TestHandleRegister_ValidRequest_Registered(t *testing.T) {
|
||||
s := newServer(t, "test-token")
|
||||
mux := http.NewServeMux()
|
||||
s.RegisterRoutes(mux)
|
||||
srv := httptest.NewServer(mux)
|
||||
defer srv.Close()
|
||||
|
||||
body, _ := json.Marshal(registerRequest{
|
||||
TenantSlug: "mandant-int12",
|
||||
ModuleName: "dms",
|
||||
ObjectType: "document",
|
||||
Fields: []fieldDTO{
|
||||
{Name: "fulltext", Kind: "text"},
|
||||
{Name: "title", Kind: "text"},
|
||||
},
|
||||
})
|
||||
req, _ := http.NewRequest(http.MethodPost, srv.URL+"/module-objecttypes", bytes.NewReader(body))
|
||||
req.Header.Set("X-Service-Token", "test-token")
|
||||
resp, err := http.DefaultClient.Do(req)
|
||||
if err != nil {
|
||||
t.Fatalf("request: %v", err)
|
||||
}
|
||||
defer resp.Body.Close()
|
||||
if resp.StatusCode != http.StatusOK {
|
||||
t.Fatalf("status = %d, want 200", resp.StatusCode)
|
||||
}
|
||||
|
||||
got, err := s.registry.Get(context.Background(), "mandant-int12", "dms", "document")
|
||||
if err != nil {
|
||||
t.Fatalf("get: %v", err)
|
||||
}
|
||||
if len(got.Fields) != 2 || got.Fields[0].Name != "fulltext" {
|
||||
t.Fatalf("unerwartete felder in der registry: %+v", got.Fields)
|
||||
}
|
||||
}
|
||||
|
||||
// TestHandleRegister_MissingServiceToken_Rejected deckt die Auth-Pflicht ab:
|
||||
// ohne gueltiges Service-Token kein Zugriff, fail closed.
|
||||
func TestHandleRegister_MissingServiceToken_Rejected(t *testing.T) {
|
||||
s := newServer(t, "test-token")
|
||||
mux := http.NewServeMux()
|
||||
s.RegisterRoutes(mux)
|
||||
srv := httptest.NewServer(mux)
|
||||
defer srv.Close()
|
||||
|
||||
body, _ := json.Marshal(registerRequest{TenantSlug: "mandant-int12", ModuleName: "dms", ObjectType: "document", Fields: []fieldDTO{{Name: "title", Kind: "text"}}})
|
||||
resp, err := http.Post(srv.URL+"/module-objecttypes", "application/json", bytes.NewReader(body))
|
||||
if err != nil {
|
||||
t.Fatalf("request: %v", err)
|
||||
}
|
||||
defer resp.Body.Close()
|
||||
if resp.StatusCode != http.StatusUnauthorized {
|
||||
t.Fatalf("status = %d, want 401", resp.StatusCode)
|
||||
}
|
||||
}
|
||||
|
||||
// TestHandleRegister_UnknownTenant_Rejected deckt GOV-07 ab: ein Tenant, den
|
||||
// Core TEN-01 nicht fuehrt, wird mit 403 abgewiesen statt uebernommen.
|
||||
func TestHandleRegister_UnknownTenant_Rejected(t *testing.T) {
|
||||
s := newServer(t, "test-token")
|
||||
mux := http.NewServeMux()
|
||||
s.RegisterRoutes(mux)
|
||||
srv := httptest.NewServer(mux)
|
||||
defer srv.Close()
|
||||
|
||||
body, _ := json.Marshal(registerRequest{TenantSlug: "fremder-mandant", ModuleName: "dms", ObjectType: "document", Fields: []fieldDTO{{Name: "title", Kind: "text"}}})
|
||||
req, _ := http.NewRequest(http.MethodPost, srv.URL+"/module-objecttypes", bytes.NewReader(body))
|
||||
req.Header.Set("X-Service-Token", "test-token")
|
||||
resp, err := http.DefaultClient.Do(req)
|
||||
if err != nil {
|
||||
t.Fatalf("request: %v", err)
|
||||
}
|
||||
defer resp.Body.Close()
|
||||
if resp.StatusCode != http.StatusForbidden {
|
||||
t.Fatalf("status = %d, want 403", resp.StatusCode)
|
||||
}
|
||||
}
|
||||
@@ -18,7 +18,6 @@ import (
|
||||
// TESTSTRATEGIE-AI.md Abschnitt 3.
|
||||
var sensitivePathPatterns = []*regexp.Regexp{
|
||||
regexp.MustCompile(`(^|/)ai/internal/svcauth/`),
|
||||
regexp.MustCompile(`(^|/)common/svcauth/`),
|
||||
regexp.MustCompile(`(^|/)ai/internal/tenantfeature/`),
|
||||
regexp.MustCompile(`(^|/)ai/internal/semanticsearch/`),
|
||||
regexp.MustCompile(`(^|/)ai/internal/semanticsearchapi/`),
|
||||
|
||||
@@ -1,249 +0,0 @@
|
||||
// Package qa03gate ist das Prüfgate für QA-03: misst Klassifizierungs- und
|
||||
// Extraktionsgenauigkeit am Referenzkorpus (QA-01, ai/internal/refcorpus)
|
||||
// und belegt die Wirkung von Korrektur-Feedback auf künftige Vorschläge.
|
||||
// Reines Prüfgate — ruft nur bestehende, bereits gemergte Pakete auf
|
||||
// (classify CLS-02, extract EXT-05-Grundlage, correction/historysuggest
|
||||
// CLS-05), ohne deren Code zu ändern.
|
||||
package qa03gate
|
||||
|
||||
import (
|
||||
"context"
|
||||
"os"
|
||||
"testing"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/classify"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/correction"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/extract"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/historysuggest"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider/ollama"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/refcorpus"
|
||||
)
|
||||
|
||||
// KlassifizierungsZielgenauigkeit ist der für QA-03 festgelegte Zielwert
|
||||
// (AK1): bei fünf gleichverteilten Dokumentarten im Referenzkorpus gilt ein
|
||||
// Treffer bei mindestens vier von fünf Dokumenten (80%) als ausreichend
|
||||
// belastbar für ein Prüfgate — niedriger als bei nur drei Kategorien
|
||||
// (vgl. QA-01/doctype real_test.go), weil die Kategorienzahl im
|
||||
// Referenzkorpus hier bewusst um die Grenzfälle Mahnung/Kündigung erweitert
|
||||
// ist.
|
||||
const KlassifizierungsZielgenauigkeit = 0.8
|
||||
|
||||
// ExtraktionsZielgenauigkeit ist der für QA-03 festgelegte Zielwert (AK2)
|
||||
// für die Erkennungsrate je Pflichtfeld (hier: Datum, in jedem
|
||||
// Referenzdokument vorhanden) — analog zur bestehenden
|
||||
// Mindesterkennungsrate in extract_test.go (TestExtract_RealOllama_...).
|
||||
const ExtraktionsZielgenauigkeit = 0.8
|
||||
|
||||
func realOllama(t *testing.T) (*ollama.Provider, string) {
|
||||
t.Helper()
|
||||
base := os.Getenv("TEST_AI_OLLAMA_BASE_URL")
|
||||
model := os.Getenv("TEST_AI_OLLAMA_MODEL")
|
||||
if base == "" || model == "" {
|
||||
t.Skip("TEST_AI_OLLAMA_BASE_URL/TEST_AI_OLLAMA_MODEL nicht gesetzt, Prüfgate-Lauf übersprungen")
|
||||
}
|
||||
p := ollama.New(base)
|
||||
if err := p.Health(context.Background()); err != nil {
|
||||
t.Skipf("Ollama nicht erreichbar: %v", err)
|
||||
}
|
||||
return p, model
|
||||
}
|
||||
|
||||
func doctypeCategories(docs []refcorpus.Document) []string {
|
||||
seen := map[string]bool{}
|
||||
var out []string
|
||||
for _, d := range docs {
|
||||
if !seen[d.Doctype] {
|
||||
seen[d.Doctype] = true
|
||||
out = append(out, d.Doctype)
|
||||
}
|
||||
}
|
||||
return out
|
||||
}
|
||||
|
||||
// TestKlassifizierungsgenauigkeit_Referenzkorpus deckt AK1 ("Klassifizierungs-
|
||||
// genauigkeit erreicht die Zielgenauigkeit") sowie Prüfung 1 (Genauigkeit
|
||||
// am Referenzkorpus dokumentiert) und Prüfung 3 (Ausgabeschema eingehalten).
|
||||
func TestKlassifizierungsgenauigkeit_Referenzkorpus(t *testing.T) {
|
||||
prov, model := realOllama(t)
|
||||
docs, err := refcorpus.Load()
|
||||
if err != nil {
|
||||
t.Fatalf("refcorpus laden: %v", err)
|
||||
}
|
||||
categories := doctypeCategories(docs)
|
||||
cl := &classify.Classifier{Provider: prov, Model: model}
|
||||
schema := classify.Schema{Categories: categories}
|
||||
|
||||
allowed := map[string]bool{classify.UnknownCategory: true}
|
||||
for _, c := range categories {
|
||||
allowed[c] = true
|
||||
}
|
||||
|
||||
hits := 0
|
||||
for _, d := range docs {
|
||||
res, err := cl.ClassifyWithSchema(context.Background(), schema, d.Text)
|
||||
if err != nil {
|
||||
t.Fatalf("Dokument %s: ClassifyWithSchema: %v", d.File, err)
|
||||
}
|
||||
|
||||
// Prüfung 3: Ausgabeschema (AK2 von CLS-01) für jeden Testfall
|
||||
// eingehalten — Kategorie ist entweder konfiguriert oder explizit
|
||||
// als unbekannt gekennzeichnet, Konfidenz liegt in [0,1].
|
||||
if !allowed[res.Category] {
|
||||
t.Errorf("Dokument %s: Kategorie %q außerhalb des Schemas", d.File, res.Category)
|
||||
}
|
||||
if res.Confidence < 0 || res.Confidence > 1 {
|
||||
t.Errorf("Dokument %s: Konfidenz %v außerhalb [0,1]", d.File, res.Confidence)
|
||||
}
|
||||
|
||||
t.Logf("Dokument %s: erwartet=%s erkannt=%s confidence=%.2f", d.File, d.Doctype, res.Category, res.Confidence)
|
||||
if res.Category == d.Doctype {
|
||||
hits++
|
||||
}
|
||||
}
|
||||
|
||||
acc := float64(hits) / float64(len(docs))
|
||||
t.Logf("Klassifizierungsgenauigkeit: %d/%d = %.0f%% (Ziel: >= %.0f%%)", hits, len(docs), acc*100, KlassifizierungsZielgenauigkeit*100)
|
||||
if acc < KlassifizierungsZielgenauigkeit {
|
||||
t.Errorf("Klassifizierungsgenauigkeit %.0f%% unter Zielwert %.0f%%", acc*100, KlassifizierungsZielgenauigkeit*100)
|
||||
}
|
||||
}
|
||||
|
||||
// referenzdokumentSchema ist das für das Prüfgate verwendete Extraktionsschema:
|
||||
// Datum ist in jedem Referenzdokument vorhanden (Pflichtfeld), Betrag nur in
|
||||
// einem Teil (rechnung, vertrag, mahnung) — die bewusste Mischung deckt auch
|
||||
// EXT-01 AK3 (kein Erraten fehlender Werte) am Referenzkorpus ab.
|
||||
var referenzdokumentSchema = extract.Schema{
|
||||
Name: "referenzdokument",
|
||||
Version: 1,
|
||||
Fields: []extract.FieldDef{
|
||||
{Name: "date", Type: extract.FieldTypeDate, Required: true},
|
||||
{Name: "amount", Type: extract.FieldTypeAmount, Required: false},
|
||||
},
|
||||
}
|
||||
|
||||
// docHasAmount ordnet den Referenzdokumenten zu, ob ein Geldbetrag im Text
|
||||
// vorkommt (Ground Truth für Prüfung 1, von Hand anhand der Dokumente in
|
||||
// ai/internal/refcorpus/testdata ermittelt).
|
||||
var docHasAmount = map[string]bool{
|
||||
"rechnung_01.txt": true,
|
||||
"vertrag_01.txt": true,
|
||||
"lieferschein_01.txt": false,
|
||||
"mahnung_01.txt": true,
|
||||
"kuendigung_01.txt": false,
|
||||
}
|
||||
|
||||
// TestExtraktionsgenauigkeit_Referenzkorpus deckt AK2 ("Extraktionsgenauigkeit
|
||||
// erreicht die Zielgenauigkeit") sowie Prüfung 1 und Prüfung 3.
|
||||
func TestExtraktionsgenauigkeit_Referenzkorpus(t *testing.T) {
|
||||
prov, model := realOllama(t)
|
||||
docs, err := refcorpus.Load()
|
||||
if err != nil {
|
||||
t.Fatalf("refcorpus laden: %v", err)
|
||||
}
|
||||
ex := &extract.Extractor{Provider: prov, Model: model}
|
||||
|
||||
dateHits := 0
|
||||
amountMatches := 0
|
||||
for _, d := range docs {
|
||||
res, err := ex.Extract(context.Background(), referenzdokumentSchema, d.Text)
|
||||
if err != nil {
|
||||
t.Fatalf("Dokument %s: Extract: %v", d.File, err)
|
||||
}
|
||||
|
||||
// Prüfung 3: Ausgabeschema eingehalten — für jedes Schema-Feld
|
||||
// genau ein Ergebnis, unabhängig vom Modelloutput.
|
||||
for _, f := range referenzdokumentSchema.Fields {
|
||||
if _, ok := res.Fields[f.Name]; !ok {
|
||||
t.Errorf("Dokument %s: Feld %q fehlt im Ausgabeschema", d.File, f.Name)
|
||||
}
|
||||
}
|
||||
|
||||
date := res.Fields["date"]
|
||||
amount := res.Fields["amount"]
|
||||
t.Logf("Dokument %s: date=%+v amount=%+v", d.File, date, amount)
|
||||
|
||||
if date.Present {
|
||||
dateHits++
|
||||
}
|
||||
wantAmount := docHasAmount[d.File]
|
||||
if amount.Present == wantAmount {
|
||||
amountMatches++
|
||||
} else {
|
||||
t.Logf("Dokument %s: Betrag-Vorhandensein abweichend (erwartet=%v, erkannt=%v)", d.File, wantAmount, amount.Present)
|
||||
}
|
||||
}
|
||||
|
||||
dateAcc := float64(dateHits) / float64(len(docs))
|
||||
amountAcc := float64(amountMatches) / float64(len(docs))
|
||||
t.Logf("Extraktionsgenauigkeit Datum: %d/%d = %.0f%% (Ziel: >= %.0f%%)", dateHits, len(docs), dateAcc*100, ExtraktionsZielgenauigkeit*100)
|
||||
t.Logf("Extraktionsgenauigkeit Betrag-Vorhandensein: %d/%d = %.0f%% (Ziel: >= %.0f%%)", amountMatches, len(docs), amountAcc*100, ExtraktionsZielgenauigkeit*100)
|
||||
|
||||
if dateAcc < ExtraktionsZielgenauigkeit {
|
||||
t.Errorf("Datum-Erkennungsrate %.0f%% unter Zielwert %.0f%%", dateAcc*100, ExtraktionsZielgenauigkeit*100)
|
||||
}
|
||||
if amountAcc < ExtraktionsZielgenauigkeit {
|
||||
t.Errorf("Betrag-Erkennungsrate %.0f%% unter Zielwert %.0f%%", amountAcc*100, ExtraktionsZielgenauigkeit*100)
|
||||
}
|
||||
}
|
||||
|
||||
// TestKorrekturFeedback_WirktAufKuenftigeVorschlaege deckt AK3
|
||||
// ("Korrektur-Feedback wirkt nachweislich auf künftige Vorschläge"). Rein
|
||||
// lokale Logik, keine Datenbank nötig (correction.Recorder/Aggregate
|
||||
// schreiben/lesen Postgres — hier wird stattdessen direkt mit den
|
||||
// öffentlichen Datentypen correction.Correction und
|
||||
// historysuggest.HistoryEntry/Suggest gearbeitet, exakt den Feldern, die
|
||||
// correction.Recorder.Aggregate in Produktion aus der Datenbank läse):
|
||||
// zunächst schlägt das System mehrheitlich die falsche Kategorie vor; nach
|
||||
// hinreichend vielen Korrekturen auf dieselbe richtige Kategorie verschiebt
|
||||
// sich der künftige Vorschlag auf die korrigierte Kategorie.
|
||||
func TestKorrekturFeedback_WirktAufKuenftigeVorschlaege(t *testing.T) {
|
||||
tenant, function := "qa03-tenant", "doctype"
|
||||
|
||||
// Historische Vorschläge vor jeder Korrektur: das System hat sechs Mal
|
||||
// "kuendigung" und einmal "vertrag" vorgeschlagen.
|
||||
vorher := []historysuggest.HistoryEntry{
|
||||
{Category: "kuendigung"}, {Category: "kuendigung"}, {Category: "kuendigung"},
|
||||
{Category: "kuendigung"}, {Category: "kuendigung"}, {Category: "kuendigung"},
|
||||
{Category: "vertrag"},
|
||||
}
|
||||
vorschlagVorher := historysuggest.Suggest(vorher)
|
||||
if vorschlagVorher.Category != "kuendigung" {
|
||||
t.Fatalf("Vorbedingung verletzt: erwartete Mehrheitsvorschlag kuendigung vor Korrektur, bekam %q", vorschlagVorher.Category)
|
||||
}
|
||||
|
||||
// Nutzer korrigiert alle sechs "kuendigung"-Vorschläge auf "vertrag"
|
||||
// (strukturiert erfasst über correction.Correction, CLS-05 AK2).
|
||||
korrekturen := make([]correction.Correction, 0, 6)
|
||||
for i := 0; i < 6; i++ {
|
||||
korrekturen = append(korrekturen, correction.Correction{
|
||||
TenantSlug: tenant,
|
||||
Function: function,
|
||||
InputRef: "doc-" + string(rune('a'+i)),
|
||||
SuggestedCategory: "kuendigung",
|
||||
SuggestedConfidence: 0.55,
|
||||
CorrectedCategory: "vertrag",
|
||||
Actor: "qa03-tester",
|
||||
})
|
||||
}
|
||||
|
||||
// Feedback wirkt auf künftige Vorschläge: die korrigierten Fälle fließen
|
||||
// mit ihrer tatsächlich richtigen Kategorie in die Historie künftiger
|
||||
// Vorschläge ein (genau das, was correction.Recorder.Aggregate aus der
|
||||
// Datenbank läse und was WFS-01/historysuggest als Historie erwartet).
|
||||
nachher := make([]historysuggest.HistoryEntry, 0, len(vorher)+len(korrekturen))
|
||||
nachher = append(nachher, historysuggest.HistoryEntry{Category: "vertrag"}) // ungetrennter Alt-Fall
|
||||
for _, k := range korrekturen {
|
||||
nachher = append(nachher, historysuggest.HistoryEntry{Category: k.CorrectedCategory})
|
||||
}
|
||||
|
||||
vorschlagNachher := historysuggest.Suggest(nachher)
|
||||
t.Logf("Vorschlag vor Korrektur: %s (Konfidenz %.2f); Vorschlag nach %d Korrekturen: %s (Konfidenz %.2f)",
|
||||
vorschlagVorher.Category, vorschlagVorher.Confidence, len(korrekturen), vorschlagNachher.Category, vorschlagNachher.Confidence)
|
||||
|
||||
if vorschlagNachher.Category != "vertrag" {
|
||||
t.Fatalf("Korrektur-Feedback wirkte nicht: erwartete künftigen Vorschlag vertrag nach Korrektur, bekam %q", vorschlagNachher.Category)
|
||||
}
|
||||
if vorschlagNachher.Category == vorschlagVorher.Category {
|
||||
t.Fatalf("Korrektur-Feedback hatte keine Wirkung: Vorschlag vor und nach Korrektur identisch (%q)", vorschlagNachher.Category)
|
||||
}
|
||||
}
|
||||
@@ -1,234 +0,0 @@
|
||||
// Package qa04gate ist das Prüfgate für QA-04: es misst Suchqualität,
|
||||
// RAG-Antwortgüte und Quellenverweis-Nachvollziehbarkeit auf einem festen,
|
||||
// synthetischen Testkorpus (SEM-01..06 bereits gemergt) und ändert keines der
|
||||
// geprüften Pakete. Der Korpus stammt aus refcorpus (QA-01), die "Einbettung"
|
||||
// ist ein deterministisches TF-IDF-Verfahren über den Korpus — kein
|
||||
// Netzwerk/Ollama nötig, damit die Messung reproduzierbar bleibt und nicht von
|
||||
// einem externen Modell abhängt. Reine Termfrequenz ohne IDF-Gewichtung wurde
|
||||
// probiert und verworfen: seltene, fachlich entscheidende Wörter (z.B.
|
||||
// "Gesamtbetrag") gingen gegen häufige, generische Wörter unter.
|
||||
package qa04gate
|
||||
|
||||
import (
|
||||
"context"
|
||||
"errors"
|
||||
"math"
|
||||
"regexp"
|
||||
"strings"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/refcorpus"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/vectorindex"
|
||||
)
|
||||
|
||||
// chunk ist ein indizierter Testabschnitt — hier ein ganzes Referenzdokument,
|
||||
// da die Korpus-Dokumente kurz genug sind, um ohne Segmentierung zu dienen.
|
||||
type chunk struct {
|
||||
sourceType string
|
||||
sourceID string
|
||||
chunkIndex int
|
||||
text string
|
||||
vector []float64
|
||||
}
|
||||
|
||||
var tokenRe = regexp.MustCompile(`[a-zäöüß0-9]+`)
|
||||
|
||||
func tokenize(text string) []string {
|
||||
return tokenRe.FindAllString(strings.ToLower(text), -1)
|
||||
}
|
||||
|
||||
// vocabulary bildet aus allen übergebenen Texten ein festes Wort->Index-Mapping,
|
||||
// damit Korpus und Anfragen auf denselben Vektorraum abgebildet werden.
|
||||
func vocabulary(texts ...string) map[string]int {
|
||||
vocab := make(map[string]int)
|
||||
for _, t := range texts {
|
||||
for _, tok := range tokenize(t) {
|
||||
if _, ok := vocab[tok]; !ok {
|
||||
vocab[tok] = len(vocab)
|
||||
}
|
||||
}
|
||||
}
|
||||
return vocab
|
||||
}
|
||||
|
||||
// documentFrequency bildet aus den Korpusdokumenten (nicht den Testfragen) je
|
||||
// Vokabular-Wort die Anzahl der Dokumente, in denen es vorkommt — Grundlage
|
||||
// der IDF-Gewichtung in embed.
|
||||
func documentFrequency(vocab map[string]int, corpusTexts []string) []int {
|
||||
df := make([]int, len(vocab))
|
||||
for _, text := range corpusTexts {
|
||||
seen := make(map[int]bool)
|
||||
for _, tok := range tokenize(text) {
|
||||
if idx, ok := vocab[tok]; ok {
|
||||
seen[idx] = true
|
||||
}
|
||||
}
|
||||
for idx := range seen {
|
||||
df[idx]++
|
||||
}
|
||||
}
|
||||
return df
|
||||
}
|
||||
|
||||
// embed bildet eine TF-IDF-Gewichtung von text über vocab/df: Terme, die in
|
||||
// wenigen Korpusdokumenten vorkommen, zählen stärker als solche, die in
|
||||
// vielen oder allen Dokumenten auftauchen.
|
||||
func embed(vocab map[string]int, df []int, numDocs int, text string) []float64 {
|
||||
vec := make([]float64, len(vocab))
|
||||
for _, tok := range tokenize(text) {
|
||||
if idx, ok := vocab[tok]; ok {
|
||||
idf := math.Log(float64(numDocs+1)/float64(df[idx]+1)) + 1
|
||||
vec[idx] += idf
|
||||
}
|
||||
}
|
||||
return vec
|
||||
}
|
||||
|
||||
func cosine(a, b []float64) float64 {
|
||||
var dot, normA, normB float64
|
||||
for i := range a {
|
||||
dot += a[i] * b[i]
|
||||
normA += a[i] * a[i]
|
||||
normB += b[i] * b[i]
|
||||
}
|
||||
if normA == 0 || normB == 0 {
|
||||
return 0
|
||||
}
|
||||
return dot / (sqrt(normA) * sqrt(normB))
|
||||
}
|
||||
|
||||
func sqrt(x float64) float64 {
|
||||
if x == 0 {
|
||||
return 0
|
||||
}
|
||||
z := x
|
||||
for i := 0; i < 50; i++ {
|
||||
z -= (z*z - x) / (2 * z)
|
||||
}
|
||||
return z
|
||||
}
|
||||
|
||||
// embedModel kapselt die für embed() nötigen, aus dem Korpus abgeleiteten
|
||||
// Parameter (Vokabular + Dokumenthäufigkeiten), damit Korpus und Anfragen
|
||||
// bei Embed konsistent auf denselben IDF-Gewichten beruhen.
|
||||
type embedModel struct {
|
||||
vocab map[string]int
|
||||
df []int
|
||||
numDocs int
|
||||
}
|
||||
|
||||
func (m embedModel) embed(text string) []float64 {
|
||||
return embed(m.vocab, m.df, m.numDocs, text)
|
||||
}
|
||||
|
||||
// loadCorpus liest refcorpus.Load() und bildet daraus Testabschnitte plus das
|
||||
// gemeinsame Vokabular/IDF-Modell (Korpustexte und Testfragen teilen sich das
|
||||
// Vokabular, siehe testdata.go; die Dokumenthäufigkeit stammt ausschließlich
|
||||
// aus den Korpusdokumenten).
|
||||
func loadCorpus() ([]chunk, embedModel, error) {
|
||||
docs, err := refcorpus.Load()
|
||||
if err != nil {
|
||||
return nil, embedModel{}, err
|
||||
}
|
||||
corpusTexts := make([]string, 0, len(docs))
|
||||
for _, d := range docs {
|
||||
corpusTexts = append(corpusTexts, d.Text)
|
||||
}
|
||||
vocabTexts := append(append([]string{}, corpusTexts...), func() []string {
|
||||
qs := make([]string, len(testQuestions))
|
||||
for i, q := range testQuestions {
|
||||
qs[i] = q.frage
|
||||
}
|
||||
return qs
|
||||
}()...)
|
||||
|
||||
vocab := vocabulary(vocabTexts...)
|
||||
model := embedModel{vocab: vocab, df: documentFrequency(vocab, corpusTexts), numDocs: len(docs)}
|
||||
|
||||
chunks := make([]chunk, 0, len(docs))
|
||||
for _, d := range docs {
|
||||
id := strings.TrimSuffix(d.File, ".txt")
|
||||
chunks = append(chunks, chunk{
|
||||
sourceType: "document",
|
||||
sourceID: id,
|
||||
chunkIndex: 0,
|
||||
text: d.Text,
|
||||
vector: model.embed(d.Text),
|
||||
})
|
||||
}
|
||||
return chunks, model, nil
|
||||
}
|
||||
|
||||
// fakeIndex implementiert die von semanticsearch.Service erwartete
|
||||
// indexSearcher-Schnittstelle über den In-Memory-Testkorpus statt über
|
||||
// vectorindex.Store/Postgres.
|
||||
type fakeIndex struct {
|
||||
chunks []chunk
|
||||
}
|
||||
|
||||
func (f *fakeIndex) Search(ctx context.Context, tenantSlug string, query []float64, topK int) ([]vectorindex.Result, error) {
|
||||
results := make([]vectorindex.Result, 0, len(f.chunks))
|
||||
for _, c := range f.chunks {
|
||||
results = append(results, vectorindex.Result{
|
||||
SourceType: c.sourceType,
|
||||
SourceID: c.sourceID,
|
||||
ChunkIndex: c.chunkIndex,
|
||||
ChunkText: c.text,
|
||||
Similarity: cosine(query, c.vector),
|
||||
})
|
||||
}
|
||||
// Absteigend nach Ähnlichkeit sortieren, wie vectorindex.Store.Search es tut.
|
||||
for i := 1; i < len(results); i++ {
|
||||
for j := i; j > 0 && results[j].Similarity > results[j-1].Similarity; j-- {
|
||||
results[j], results[j-1] = results[j-1], results[j]
|
||||
}
|
||||
}
|
||||
if len(results) > topK {
|
||||
results = results[:topK]
|
||||
}
|
||||
return results, nil
|
||||
}
|
||||
|
||||
// fakeLocator implementiert chunkLocator (docchat.ResolveCitation) über denselben
|
||||
// In-Memory-Testkorpus.
|
||||
type fakeLocator struct {
|
||||
chunks []chunk
|
||||
}
|
||||
|
||||
var errChunkNotFound = errors.New("qa04gate: abschnitt nicht im testkorpus")
|
||||
|
||||
func (f *fakeLocator) GetChunk(ctx context.Context, tenantSlug, sourceType, sourceID string, chunkIndex int) (string, error) {
|
||||
for _, c := range f.chunks {
|
||||
if c.sourceType == sourceType && c.sourceID == sourceID && c.chunkIndex == chunkIndex {
|
||||
return c.text, nil
|
||||
}
|
||||
}
|
||||
return "", errChunkNotFound
|
||||
}
|
||||
|
||||
// embedProvider implementiert provider.Provider nur für Embed sinnvoll
|
||||
// (TF-IDF über das Korpusvokabular); Complete wird hier nicht benötigt.
|
||||
type embedProvider struct {
|
||||
model embedModel
|
||||
}
|
||||
|
||||
var _ provider.Provider = (*embedProvider)(nil)
|
||||
|
||||
func (p *embedProvider) Embed(ctx context.Context, req provider.EmbeddingRequest) (provider.EmbeddingResponse, error) {
|
||||
return provider.EmbeddingResponse{Embedding: p.model.embed(req.Input)}, nil
|
||||
}
|
||||
|
||||
// Chat liefert eine feste, auf die Abschnitte gestützte Antwort mit Zitat-
|
||||
// Marker — die eigentliche Formulierung ist für dieses Prüfgate irrelevant,
|
||||
// da docchat.Ask die Citations unabhängig vom Modelltext aus den Treffern baut.
|
||||
func (p *embedProvider) Chat(ctx context.Context, req provider.ChatRequest) (provider.ChatResponse, error) {
|
||||
return provider.ChatResponse{Message: provider.Message{
|
||||
Role: provider.RoleAssistant,
|
||||
Content: "Antwort gemäß den gefundenen Abschnitten [1].",
|
||||
}}, nil
|
||||
}
|
||||
|
||||
func (p *embedProvider) Complete(ctx context.Context, req provider.CompletionRequest) (provider.CompletionResponse, error) {
|
||||
return provider.CompletionResponse{}, errors.New("qa04gate: Complete wird vom Prüfgate nicht genutzt")
|
||||
}
|
||||
|
||||
@@ -1,171 +0,0 @@
|
||||
package qa04gate
|
||||
|
||||
import (
|
||||
"context"
|
||||
"testing"
|
||||
"time"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/docchat"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/semanticsearch"
|
||||
)
|
||||
|
||||
func newGate(t *testing.T) (*semanticsearch.Service, *docchat.Service, []semanticsearch.Ref, *fakeLocator) {
|
||||
chunks, model, err := loadCorpus()
|
||||
if err != nil {
|
||||
t.Fatalf("loadCorpus: %v", err)
|
||||
}
|
||||
idx := &fakeIndex{chunks: chunks}
|
||||
locator := &fakeLocator{chunks: chunks}
|
||||
embedder := &embedProvider{model: model}
|
||||
|
||||
search := semanticsearch.New(embedder, idx, "qa04-bow")
|
||||
chat := docchat.New(search, embedder, "qa04-bow", locator)
|
||||
|
||||
allowedRefs := make([]semanticsearch.Ref, 0, len(chunks))
|
||||
for _, c := range chunks {
|
||||
allowedRefs = append(allowedRefs, semanticsearch.Ref{SourceType: c.sourceType, SourceID: c.sourceID})
|
||||
}
|
||||
return search, chat, allowedRefs, locator
|
||||
}
|
||||
|
||||
const tenant = "qa04-tenant"
|
||||
|
||||
// AK1 + Prüfung 1: Relevanz-Stichprobe über den festen Testkorpus. Für jede
|
||||
// Testfrage muss der Top-Treffer (Precision@1) auf das erwartete Dokument
|
||||
// zeigen; die Tabelle wird für das Prüfprotokoll mitgeloggt.
|
||||
func TestRelevanzStichprobe_SuchqualitaetDokumentiert(t *testing.T) {
|
||||
search, _, allowedRefs, _ := newGate(t)
|
||||
|
||||
treffer := 0
|
||||
for _, q := range testQuestions {
|
||||
hits, err := search.Search(context.Background(), tenant, q.frage, 1, allowedRefs)
|
||||
if err != nil {
|
||||
t.Fatalf("Search(%q): %v", q.frage, err)
|
||||
}
|
||||
if len(hits) != 1 {
|
||||
t.Errorf("%s: %d Treffer, erwartet 1", q.beschreibung, len(hits))
|
||||
continue
|
||||
}
|
||||
ok := hits[0].SourceID == q.erwarteteSourceID
|
||||
if ok {
|
||||
treffer++
|
||||
}
|
||||
t.Logf("Frage=%q erwartet=%s top1=%s score=%.3f treffer=%v",
|
||||
q.frage, q.erwarteteSourceID, hits[0].SourceID, hits[0].Score, ok)
|
||||
if !ok {
|
||||
t.Errorf("%s: Top-Treffer=%s, erwartet=%s", q.beschreibung, hits[0].SourceID, q.erwarteteSourceID)
|
||||
}
|
||||
}
|
||||
precision := float64(treffer) / float64(len(testQuestions))
|
||||
t.Logf("Precision@1 = %d/%d = %.0f%%", treffer, len(testQuestions), precision*100)
|
||||
if precision < 1.0 {
|
||||
t.Errorf("Precision@1 = %.0f%%, erwartet 100%% auf dem festen Testkorpus", precision*100)
|
||||
}
|
||||
}
|
||||
|
||||
// AK2 + Prüfung 2: Beleg-Antwort-Zuordnung. Jede Antwort auf eine beantwortbare
|
||||
// Testfrage muss mindestens eine Citation führen, die auf einen tatsächlich im
|
||||
// Index vorhandenen Abschnitt zeigt (ResolveCitation), und dieser Abschnitt
|
||||
// muss aus dem erwarteten Quelldokument stammen.
|
||||
func TestBelegAntwortZuordnung_Dokumentiert(t *testing.T) {
|
||||
_, chat, allowedRefs, _ := newGate(t)
|
||||
|
||||
for _, q := range testQuestions {
|
||||
ans, err := chat.Ask(context.Background(), tenant, q.frage, 3, allowedRefs)
|
||||
if err != nil {
|
||||
t.Fatalf("Ask(%q): %v", q.frage, err)
|
||||
}
|
||||
if ans.NoEvidence {
|
||||
t.Errorf("%s: Antwort als unbelegt markiert, erwartet belegte Antwort", q.beschreibung)
|
||||
continue
|
||||
}
|
||||
if len(ans.Citations) == 0 {
|
||||
t.Errorf("%s: keine Citations, AK2 verletzt (Antwort ohne Quelle)", q.beschreibung)
|
||||
continue
|
||||
}
|
||||
|
||||
stimmtZuoerdnungZu := false
|
||||
for _, c := range ans.Citations {
|
||||
resolved, err := chat.ResolveCitation(context.Background(), tenant, c)
|
||||
if err != nil {
|
||||
t.Errorf("%s: ResolveCitation(%+v): %v", q.beschreibung, c, err)
|
||||
continue
|
||||
}
|
||||
if resolved == "" {
|
||||
t.Errorf("%s: aufgelöster Abschnitt ist leer", q.beschreibung)
|
||||
}
|
||||
if c.SourceID == q.erwarteteSourceID {
|
||||
stimmtZuoerdnungZu = true
|
||||
}
|
||||
}
|
||||
if !stimmtZuoerdnungZu {
|
||||
t.Errorf("%s: keine Citation zeigt auf das erwartete Dokument %s (Citations=%+v)",
|
||||
q.beschreibung, q.erwarteteSourceID, ans.Citations)
|
||||
}
|
||||
t.Logf("Frage=%q citations=%d belegt_korrekt=%v", q.frage, len(ans.Citations), stimmtZuoerdnungZu)
|
||||
}
|
||||
}
|
||||
|
||||
// AK3 + Prüfung 2 (Gegenprobe): eine Anfrage ohne freigegebene Referenzen
|
||||
// (keine Rechteprüfung möglich) muss zuverlässig als unbelegt gekennzeichnet
|
||||
// werden — fester Text, keine Citations, kein Modellaufruf.
|
||||
func TestUnbelegteAntwort_OhneFreigegebeneReferenzen_WirdGekennzeichnet(t *testing.T) {
|
||||
_, chat, _, _ := newGate(t)
|
||||
|
||||
ans, err := chat.Ask(context.Background(), tenant, unbelegteFrage, 3, nil)
|
||||
if err != nil {
|
||||
t.Fatalf("Ask: %v", err)
|
||||
}
|
||||
if !ans.NoEvidence {
|
||||
t.Error("NoEvidence sollte true sein ohne freigegebene Referenzen")
|
||||
}
|
||||
if ans.Text != docchat.NoEvidenceAnswer {
|
||||
t.Errorf("Text = %q, erwartet den festen NoEvidence-Text", ans.Text)
|
||||
}
|
||||
if len(ans.Citations) != 0 {
|
||||
t.Errorf("Citations = %+v, erwartet keine Verweise bei unbelegter Antwort", ans.Citations)
|
||||
}
|
||||
}
|
||||
|
||||
// Offener Befund (nicht Teil von AK3, siehe Prüfprotokoll): eine fachlich
|
||||
// unbelegte Frage, die mit vollem Zugriff auf den Korpus gestellt wird, bleibt
|
||||
// aktuell NICHT als unbelegt erkennbar, weil semanticsearch keinen
|
||||
// Mindest-Ähnlichkeitswert durchsetzt — Search liefert topK Treffer auch bei
|
||||
// Ähnlichkeit 0. Dieser Test dokumentiert den IST-Zustand, er fordert ihn nicht.
|
||||
func TestOffenerBefund_UnbelegteFrageMitVollemZugriff_WirdNichtErkannt(t *testing.T) {
|
||||
_, chat, allowedRefs, _ := newGate(t)
|
||||
|
||||
ans, err := chat.Ask(context.Background(), tenant, unbelegteFrage, 1, allowedRefs)
|
||||
if err != nil {
|
||||
t.Fatalf("Ask: %v", err)
|
||||
}
|
||||
t.Logf("IST-Zustand: NoEvidence=%v Citations=%+v Sources=%+v", ans.NoEvidence, ans.Citations, ans.Sources)
|
||||
if ans.NoEvidence {
|
||||
t.Log("Hinweis: System hat den Befund in der Zwischenzeit behoben (NoEvidence=true) - Dokumentation im Prüfprotokoll anpassen")
|
||||
}
|
||||
}
|
||||
|
||||
// Prüfung 3: Antwortzeit an Testkorpus dokumentiert.
|
||||
func TestAntwortzeit_Dokumentiert(t *testing.T) {
|
||||
_, chat, allowedRefs, _ := newGate(t)
|
||||
|
||||
var max time.Duration
|
||||
var sum time.Duration
|
||||
for _, q := range testQuestions {
|
||||
start := time.Now()
|
||||
if _, err := chat.Ask(context.Background(), tenant, q.frage, 3, allowedRefs); err != nil {
|
||||
t.Fatalf("Ask(%q): %v", q.frage, err)
|
||||
}
|
||||
d := time.Since(start)
|
||||
sum += d
|
||||
if d > max {
|
||||
max = d
|
||||
}
|
||||
t.Logf("Frage=%q Antwortzeit=%s", q.frage, d)
|
||||
}
|
||||
avg := sum / time.Duration(len(testQuestions))
|
||||
t.Logf("Antwortzeit: avg=%s max=%s (n=%d, In-Memory-Testkorpus ohne Netzwerk/Modell-Latenz)", avg, max, len(testQuestions))
|
||||
if max > 2*time.Second {
|
||||
t.Errorf("max Antwortzeit %s über der Prüfgate-Schwelle 2s für den In-Memory-Testkorpus", max)
|
||||
}
|
||||
}
|
||||
@@ -1,42 +0,0 @@
|
||||
package qa04gate
|
||||
|
||||
// testQuestion ist eine feste Testfrage des QA-04-Prüfgates gegen den
|
||||
// refcorpus-Testkorpus (QA-01). erwarteteSourceID ist leer, wenn die Frage
|
||||
// bewusst außerhalb des Korpus liegt (AK3: unbelegte Antwort).
|
||||
type testQuestion struct {
|
||||
frage string
|
||||
erwarteteSourceID string
|
||||
beschreibung string
|
||||
}
|
||||
|
||||
var testQuestions = []testQuestion{
|
||||
{
|
||||
frage: "Wie viele Stunden Beratungsleistung wurden auf der Rechnung abgerechnet?",
|
||||
erwarteteSourceID: "rechnung_01",
|
||||
beschreibung: "Rechnungsbetrag",
|
||||
},
|
||||
{
|
||||
frage: "Welche monatliche Pauschale ist im Dienstleistungsvertrag vereinbart?",
|
||||
erwarteteSourceID: "vertrag_01",
|
||||
beschreibung: "Vertragsvergütung",
|
||||
},
|
||||
{
|
||||
frage: "Wie viele Aktenordner wurden mit dem Lieferschein geliefert?",
|
||||
erwarteteSourceID: "lieferschein_01",
|
||||
beschreibung: "Liefermenge",
|
||||
},
|
||||
{
|
||||
frage: "Bis wann soll der in der Mahnung genannte Betrag ausgeglichen werden?",
|
||||
erwarteteSourceID: "mahnung_01",
|
||||
beschreibung: "Zahlungsfrist Mahnung",
|
||||
},
|
||||
{
|
||||
frage: "Zu welchem Termin endet der Vertrag laut Kündigungsschreiben?",
|
||||
erwarteteSourceID: "kuendigung_01",
|
||||
beschreibung: "Kündigungstermin",
|
||||
},
|
||||
}
|
||||
|
||||
// unbelegteFrage liegt bewusst außerhalb des Testkorpus — es gibt keine
|
||||
// freigegebene Referenz dafür, die Suche muss ohne Treffer bleiben (AK3).
|
||||
const unbelegteFrage = "Wie ist das Wetter morgen in Timbuktu?"
|
||||
@@ -1,198 +0,0 @@
|
||||
// Package qa05gate ist das Prüfgate für QA-05 (Datenschutz- &
|
||||
// Governance-Prüfung). Es bringt keine neue Fachlogik ein, sondern führt
|
||||
// GOV-02/GOV-03/GOV-05 end-to-end gegen eine echte Postgres-Wegwerf-DB bzw.
|
||||
// einen Mock-Core zusammen, um die drei QA-05-Akzeptanzkriterien in der
|
||||
// Praxis (nicht nur auf Store-Ebene) nachzuweisen.
|
||||
package qa05gate
|
||||
|
||||
import (
|
||||
"context"
|
||||
"encoding/json"
|
||||
"net/http"
|
||||
"net/http/httptest"
|
||||
"os"
|
||||
"path/filepath"
|
||||
"testing"
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/decisionaudit"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/migrate"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider/mock"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider/openai"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/residency"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/tenantfeature"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/testdb"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/auditclient"
|
||||
)
|
||||
|
||||
// realPool liefert einen frischen, migrierten Pool auf der Wegwerf-DB aus
|
||||
// TEST_TENANT_DSN; ohne gesetzte Variable wird der Test übersprungen.
|
||||
func realPool(t *testing.T) *pgxpool.Pool {
|
||||
t.Helper()
|
||||
dsn := os.Getenv("TEST_TENANT_DSN")
|
||||
if dsn == "" {
|
||||
t.Skip("TEST_TENANT_DSN nicht gesetzt, Integrationstest übersprungen")
|
||||
}
|
||||
pool := testdb.Pool(t, dsn)
|
||||
migrationsDir, err := filepath.Abs("../../migrations")
|
||||
if err != nil {
|
||||
t.Fatalf("migrationsverzeichnis: %v", err)
|
||||
}
|
||||
migrations, err := migrate.Load(migrationsDir)
|
||||
if err != nil {
|
||||
t.Fatalf("migrationen laden: %v", err)
|
||||
}
|
||||
if _, err := migrate.Up(context.Background(), pool, migrations); err != nil {
|
||||
t.Fatalf("migrationen anwenden: %v", err)
|
||||
}
|
||||
return pool
|
||||
}
|
||||
|
||||
// callIfEnabled simuliert einen typischen AI-API-Handler: er fragt vor der
|
||||
// eigentlichen Fachaktion den Opt-out-Stand ab, genau wie es GOV-02 für
|
||||
// künftige HTTP-Schichten vorsieht.
|
||||
func callIfEnabled(ctx context.Context, store *tenantfeature.Store, tenant, function string, globalEnabled bool, action func()) (called bool, err error) {
|
||||
enabled, err := store.IsEnabled(ctx, tenant, function, globalEnabled)
|
||||
if err != nil {
|
||||
return false, err
|
||||
}
|
||||
if !enabled {
|
||||
return false, nil
|
||||
}
|
||||
action()
|
||||
return true, nil
|
||||
}
|
||||
|
||||
// AK1 + Prüfung 1: Opt-out-Fall im Test bestätigt — eine Funktion, die den
|
||||
// Opt-out-Stand korrekt abfragt (wie callIfEnabled es demonstriert), ruft die
|
||||
// Fachaktion bei deaktivierter Funktion tatsächlich NICHT auf.
|
||||
func TestAK1_OptOut_BlocksSimulatedHandlerCall(t *testing.T) {
|
||||
pool := realPool(t)
|
||||
store := &tenantfeature.Store{Pool: pool}
|
||||
ctx := context.Background()
|
||||
|
||||
if err := store.Set(ctx, "qa05_tenant", "summarize", false); err != nil {
|
||||
t.Fatalf("Set: %v", err)
|
||||
}
|
||||
|
||||
calledDisabled := false
|
||||
called, err := callIfEnabled(ctx, store, "qa05_tenant", "summarize", true, func() { calledDisabled = true })
|
||||
if err != nil {
|
||||
t.Fatalf("callIfEnabled: %v", err)
|
||||
}
|
||||
if called || calledDisabled {
|
||||
t.Fatal("Opt-out muss den Aufruf der Fachaktion verhindern")
|
||||
}
|
||||
|
||||
if err := store.Set(ctx, "qa05_tenant", "summarize", true); err != nil {
|
||||
t.Fatalf("Set: %v", err)
|
||||
}
|
||||
calledEnabled := false
|
||||
called, err = callIfEnabled(ctx, store, "qa05_tenant", "summarize", true, func() { calledEnabled = true })
|
||||
if err != nil {
|
||||
t.Fatalf("callIfEnabled: %v", err)
|
||||
}
|
||||
if !called || !calledEnabled {
|
||||
t.Fatal("nach Reaktivierung muss die Fachaktion wieder aufgerufen werden")
|
||||
}
|
||||
}
|
||||
|
||||
// AK2 + Prüfung 2: Datenresidenz-Fall lokal und extern geprüft — end-to-end
|
||||
// über die echte GuardedProvider-Kette (ENG-03), nicht nur über den Store:
|
||||
// ohne Freigabe erreicht kein Aufruf den inneren Provider, nach Approve und
|
||||
// bei passendem Mandanten im Kontext schon, nach Revoke wieder nicht.
|
||||
func TestAK2_Residency_EndToEndThroughGuardedProvider(t *testing.T) {
|
||||
pool := realPool(t)
|
||||
store := residency.NewStore(pool)
|
||||
gate := &residency.Gate{Store: store}
|
||||
|
||||
inner := &mock.Provider{ChatResponse: provider.ChatResponse{Model: "ext-model"}}
|
||||
guarded := &openai.GuardedProvider{Inner: inner, Gate: gate}
|
||||
|
||||
ctxTenant := openai.WithTenant(context.Background(), "qa05_residency_tenant")
|
||||
|
||||
// Lokal/ohne Freigabe (Standard: local): externe Verarbeitung muss blockiert sein.
|
||||
if _, err := guarded.Chat(ctxTenant, provider.ChatRequest{Model: "x"}); err == nil {
|
||||
t.Fatal("ohne Freigabe muss der externe Adapter den Aufruf ablehnen")
|
||||
}
|
||||
|
||||
// Externe Verarbeitung ausdrücklich freigegeben.
|
||||
if err := store.Approve(context.Background(), "qa05_residency_tenant", "qa-05-pruefer"); err != nil {
|
||||
t.Fatalf("Approve: %v", err)
|
||||
}
|
||||
resp, err := guarded.Chat(ctxTenant, provider.ChatRequest{Model: "x"})
|
||||
if err != nil {
|
||||
t.Fatalf("nach Freigabe muss der Aufruf durchgehen: %v", err)
|
||||
}
|
||||
if resp.Model != "ext-model" {
|
||||
t.Fatalf("erwartet Antwort vom inneren Provider, got %+v", resp)
|
||||
}
|
||||
|
||||
// Freigabe zurückgenommen: wieder blockiert.
|
||||
if err := store.Revoke(context.Background(), "qa05_residency_tenant"); err != nil {
|
||||
t.Fatalf("Revoke: %v", err)
|
||||
}
|
||||
if _, err := guarded.Chat(ctxTenant, provider.ChatRequest{Model: "x"}); err == nil {
|
||||
t.Fatal("nach Revoke muss der externe Adapter den Aufruf wieder ablehnen")
|
||||
}
|
||||
|
||||
// Ein anderer Mandant ohne eigene Freigabe bleibt unabhängig blockiert.
|
||||
otherCtx := openai.WithTenant(context.Background(), "qa05_residency_other_tenant")
|
||||
if _, err := guarded.Chat(otherCtx, provider.ChatRequest{Model: "x"}); err == nil {
|
||||
t.Fatal("ein fremder, nicht freigegebener Mandant darf nie durchgehen")
|
||||
}
|
||||
}
|
||||
|
||||
type recordedAuditEntry struct {
|
||||
TenantSlug string `json:"tenant_slug"`
|
||||
Actor string `json:"actor"`
|
||||
Action string `json:"action"`
|
||||
Target string `json:"target"`
|
||||
Metadata map[string]any `json:"metadata"`
|
||||
}
|
||||
|
||||
// AK3 + Prüfung 3: Audit-Nachvollziehbarkeit an Stichprobe bestätigt — end-to-end
|
||||
// über den echten Recorder gegen einen Mock-Core-Server, inkl. Nachweis der
|
||||
// Modell-/Prompt-Version-Referenz.
|
||||
func TestAK3_DecisionAudit_SampleTraceableEndToEnd(t *testing.T) {
|
||||
var received []recordedAuditEntry
|
||||
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
|
||||
var e recordedAuditEntry
|
||||
if err := json.NewDecoder(r.Body).Decode(&e); err != nil {
|
||||
t.Fatalf("mock-core decode: %v", err)
|
||||
}
|
||||
received = append(received, e)
|
||||
w.WriteHeader(http.StatusAccepted)
|
||||
}))
|
||||
defer srv.Close()
|
||||
|
||||
recorder := decisionaudit.NewRecorder(auditclient.New(srv.URL, "qa05-token"))
|
||||
err := recorder.Record(context.Background(), decisionaudit.Decision{
|
||||
TenantSlug: "qa05_audit_tenant",
|
||||
Actor: "svc:ai",
|
||||
Function: "classify",
|
||||
Model: "llama3.1",
|
||||
PromptVersion: 4,
|
||||
InputRef: "dms/doc:qa05-stichprobe",
|
||||
Result: map[string]any{"category": "rechnung"},
|
||||
})
|
||||
if err != nil {
|
||||
t.Fatalf("Record: %v", err)
|
||||
}
|
||||
|
||||
if len(received) != 1 {
|
||||
t.Fatalf("erwartet genau 1 Audit-Eintrag fuer die Stichprobe, hatte %d", len(received))
|
||||
}
|
||||
entry := received[0]
|
||||
if entry.Action != "ai.decision.classify" {
|
||||
t.Errorf("action = %q, erwartet ai.decision.classify", entry.Action)
|
||||
}
|
||||
if entry.Target != "dms/doc:qa05-stichprobe" {
|
||||
t.Errorf("target = %q, erwartet den Eingabe-Verweis", entry.Target)
|
||||
}
|
||||
if entry.Metadata["model"] != "llama3.1" || entry.Metadata["prompt_version"] != float64(4) {
|
||||
t.Errorf("Metadaten verweisen nicht eindeutig auf Modell/Prompt-Version: %+v", entry.Metadata)
|
||||
}
|
||||
}
|
||||
@@ -1,97 +0,0 @@
|
||||
package queue
|
||||
|
||||
import (
|
||||
"context"
|
||||
"sync"
|
||||
"testing"
|
||||
"time"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider"
|
||||
)
|
||||
|
||||
// QA-02 Pruefung 2: eine Lastspitze (viele gleichzeitig eingereihte Jobs)
|
||||
// wird von mehreren nebenlaeufigen Workern vollstaendig abgearbeitet — kein
|
||||
// Job geht verloren, keiner wird doppelt als erfolgreich gezaehlt. Ergaenzt
|
||||
// TestQueue_AsyncEnqueueUnderLoadSpike (das nur den Enqueue-Pfad belegt) um
|
||||
// die tatsaechliche Verarbeitung durch mehrere Worker unter FOR UPDATE SKIP
|
||||
// LOCKED-Konkurrenz.
|
||||
func TestQueue_MultiWorkerDrainsLoadSpikeWithoutLoss(t *testing.T) {
|
||||
pool := newPool(t)
|
||||
q := NewQueue(pool, time.Minute)
|
||||
|
||||
const jobCount = 200
|
||||
const workerCount = 8
|
||||
|
||||
ids := make(map[string]bool, jobCount)
|
||||
var mu sync.Mutex
|
||||
var enqueueWG sync.WaitGroup
|
||||
for i := 0; i < jobCount; i++ {
|
||||
enqueueWG.Add(1)
|
||||
go func(i int) {
|
||||
defer enqueueWG.Done()
|
||||
id, err := q.Enqueue(context.Background(), KindChat, provider.ChatRequest{Model: "test"}, EnqueueOptions{})
|
||||
if err != nil {
|
||||
t.Errorf("enqueue %d: %v", i, err)
|
||||
return
|
||||
}
|
||||
mu.Lock()
|
||||
ids[id] = true
|
||||
mu.Unlock()
|
||||
}(i)
|
||||
}
|
||||
enqueueWG.Wait()
|
||||
if len(ids) != jobCount {
|
||||
t.Fatalf("erwartet %d eindeutige job-ids, erhalten %d", jobCount, len(ids))
|
||||
}
|
||||
|
||||
fp := &fakeProvider{}
|
||||
|
||||
var workerWG sync.WaitGroup
|
||||
for w := 0; w < workerCount; w++ {
|
||||
workerWG.Add(1)
|
||||
go func(workerID int) {
|
||||
defer workerWG.Done()
|
||||
worker := NewWorker(q, fp, "spike-worker")
|
||||
for {
|
||||
err := worker.ProcessOne(context.Background())
|
||||
if err == ErrNoJobAvailable {
|
||||
return
|
||||
}
|
||||
if err != nil {
|
||||
t.Errorf("processOne: %v", err)
|
||||
return
|
||||
}
|
||||
}
|
||||
}(w)
|
||||
}
|
||||
workerWG.Wait()
|
||||
|
||||
depth, err := q.Depth(context.Background())
|
||||
if err != nil {
|
||||
t.Fatalf("depth: %v", err)
|
||||
}
|
||||
if depth.Pending != 0 {
|
||||
t.Fatalf("depth.Pending = %d, erwartet 0 (keine Lastspitze darf uebrig bleiben)", depth.Pending)
|
||||
}
|
||||
if depth.DeadLetter != 0 {
|
||||
t.Fatalf("depth.DeadLetter = %d, erwartet 0 (kein Jobverlust unter Last)", depth.DeadLetter)
|
||||
}
|
||||
|
||||
succeeded := 0
|
||||
for id := range ids {
|
||||
st, err := q.Status(context.Background(), id)
|
||||
if err != nil {
|
||||
t.Fatalf("status %s: %v", id, err)
|
||||
}
|
||||
if st.Status != StatusSucceeded {
|
||||
t.Fatalf("job %s hat status %q, erwartet succeeded", id, st.Status)
|
||||
}
|
||||
succeeded++
|
||||
}
|
||||
if succeeded != jobCount {
|
||||
t.Fatalf("erfolgreich verarbeitete jobs = %d, erwartet %d (kein Verlust)", succeeded, jobCount)
|
||||
}
|
||||
if fp.calls.Load() != int64(jobCount) {
|
||||
t.Fatalf("provider wurde %d mal aufgerufen, erwartet genau %d (keine Doppelverarbeitung)", fp.calls.Load(), jobCount)
|
||||
}
|
||||
}
|
||||
@@ -29,11 +29,6 @@ const (
|
||||
var ErrNotFound = errors.New("queue: job nicht gefunden")
|
||||
var ErrNoJobAvailable = errors.New("queue: kein job verfuegbar")
|
||||
|
||||
// ErrQueueFull ist QA-08s definiertes Ueberlastverhalten (AK3): Enqueue
|
||||
// lehnt neue Jobs kontrolliert ab, statt die Warteschlange unbegrenzt
|
||||
// anwachsen zu lassen, wenn bereits limits.MaxPendingJobs Jobs warten.
|
||||
var ErrQueueFull = errors.New("queue: warteschlange ueberlastet, bitte spaeter erneut versuchen")
|
||||
|
||||
// Kind unterscheidet die Art des Inferenz-Aufrufs im Payload.
|
||||
type Kind string
|
||||
|
||||
@@ -109,15 +104,6 @@ func (q *Queue) Enqueue(ctx context.Context, jobType Kind, payload any, opts Enq
|
||||
return "", err
|
||||
}
|
||||
}
|
||||
if q.limits.MaxPendingJobs > 0 {
|
||||
depth, err := q.Depth(ctx)
|
||||
if err != nil {
|
||||
return "", err
|
||||
}
|
||||
if depth.Pending >= int64(q.limits.MaxPendingJobs) {
|
||||
return "", ErrQueueFull
|
||||
}
|
||||
}
|
||||
maxAttempts := opts.MaxAttempts
|
||||
if maxAttempts <= 0 {
|
||||
maxAttempts = DefaultMaxAttempts
|
||||
|
||||
@@ -1,116 +0,0 @@
|
||||
package queue
|
||||
|
||||
import (
|
||||
"context"
|
||||
"errors"
|
||||
"sync"
|
||||
"testing"
|
||||
"time"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/limits"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/provider"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/loadtest"
|
||||
)
|
||||
|
||||
// QA-08 Pruefung 2 (AK2): realistische parallele Klassifizierungs-/
|
||||
// Extraktionsanfragen fuellen die Queue, mehrere Worker laufen gleichzeitig
|
||||
// dagegen — die Warteschlangentiefe waechst waehrend des Laufs nicht
|
||||
// unkontrolliert, weil Dequeue/Complete nebenlaeufig abraeumen.
|
||||
func TestQueue_DepthStaysBoundedUnderParallelLoad(t *testing.T) {
|
||||
pool := newPool(t)
|
||||
q := NewQueue(pool, time.Minute)
|
||||
q.SetLimits(limits.Limits{MaxPendingJobs: 0}) // in diesem Lauf keine Enqueue-Obergrenze, es geht um die Abarbeitung
|
||||
|
||||
const workers = 4
|
||||
const totalJobs = 120
|
||||
stop := make(chan struct{})
|
||||
var wg sync.WaitGroup
|
||||
for i := 0; i < workers; i++ {
|
||||
wg.Add(1)
|
||||
w := NewWorker(q, &fakeProvider{}, "loadtest-worker")
|
||||
go func() {
|
||||
defer wg.Done()
|
||||
for {
|
||||
select {
|
||||
case <-stop:
|
||||
return
|
||||
default:
|
||||
}
|
||||
if err := w.ProcessOne(context.Background()); err != nil && !errors.Is(err, ErrNoJobAvailable) {
|
||||
t.Logf("worker fehler (nicht fatal, da nebenlaeufig): %v", err)
|
||||
}
|
||||
}
|
||||
}()
|
||||
}
|
||||
|
||||
result := loadtest.Run(context.Background(), "inference-queue-enqueue", 20, totalJobs, func(ctx context.Context) error {
|
||||
_, err := q.Enqueue(ctx, KindChat, provider.ChatRequest{Model: "test"}, EnqueueOptions{})
|
||||
return err
|
||||
})
|
||||
|
||||
deadline := time.Now().Add(20 * time.Second)
|
||||
var depth Depth
|
||||
for time.Now().Before(deadline) {
|
||||
var err error
|
||||
depth, err = q.Depth(context.Background())
|
||||
if err != nil {
|
||||
t.Fatalf("depth: %v", err)
|
||||
}
|
||||
if depth.Pending == 0 {
|
||||
break
|
||||
}
|
||||
time.Sleep(100 * time.Millisecond)
|
||||
}
|
||||
close(stop)
|
||||
wg.Wait()
|
||||
|
||||
t.Logf("QA-08 Enqueue-Last: concurrency=%d sessions=%d errors=%d dauer=%s durchsatz=%.1f/s p50=%s p95=%s p99=%s max=%s",
|
||||
result.Concurrency, result.Sessions, result.Errors, result.Duration,
|
||||
result.Throughput(), result.Percentile(0.5), result.Percentile(0.95), result.Percentile(0.99), result.Max())
|
||||
t.Logf("QA-08 Warteschlangenstand nach Abarbeitung: pending=%d processing=%d dead_letter=%d", depth.Pending, depth.Processing, depth.DeadLetter)
|
||||
|
||||
if result.Errors > 0 {
|
||||
t.Fatalf("%d von %d Enqueue-Aufrufen fehlgeschlagen, erwartet 0 ohne Ueberlast-Grenze", result.Errors, result.Sessions)
|
||||
}
|
||||
if depth.Pending != 0 {
|
||||
t.Fatalf("depth.Pending = %d nach Ablauf der Wartezeit, erwartet 0 (Warteschlange sollte abgearbeitet sein, kein unkontrolliertes Wachstum)", depth.Pending)
|
||||
}
|
||||
}
|
||||
|
||||
// QA-08 Pruefung 3 (AK3): bei erreichter Ueberlast-Grenze ist das Verhalten
|
||||
// definiert — Enqueue lehnt kontrolliert mit ErrQueueFull ab, statt
|
||||
// unbegrenzt weiter Jobs anzunehmen.
|
||||
func TestQueue_RejectsEnqueueWhenQueueFull(t *testing.T) {
|
||||
pool := newPool(t)
|
||||
q := NewQueue(pool, time.Minute)
|
||||
q.SetLimits(limits.Limits{MaxPendingJobs: 5})
|
||||
|
||||
for i := 0; i < 5; i++ {
|
||||
if _, err := q.Enqueue(context.Background(), KindChat, provider.ChatRequest{Model: "test"}, EnqueueOptions{}); err != nil {
|
||||
t.Fatalf("enqueue %d (sollte noch innerhalb der Grenze liegen): %v", i, err)
|
||||
}
|
||||
}
|
||||
|
||||
_, err := q.Enqueue(context.Background(), KindChat, provider.ChatRequest{Model: "test"}, EnqueueOptions{})
|
||||
if !errors.Is(err, ErrQueueFull) {
|
||||
t.Fatalf("enqueue beim 6. Job = %v, erwartet ErrQueueFull", err)
|
||||
}
|
||||
|
||||
depth, err := q.Depth(context.Background())
|
||||
if err != nil {
|
||||
t.Fatalf("depth: %v", err)
|
||||
}
|
||||
if depth.Pending != 5 {
|
||||
t.Fatalf("depth.Pending = %d, erwartet 5 (abgelehnter Job wurde nicht angelegt)", depth.Pending)
|
||||
}
|
||||
|
||||
// Nach Abarbeitung eines Jobs ist unter der Grenze wieder Platz (definiertes
|
||||
// Verhalten, kein dauerhafter Deadlock der Warteschlange).
|
||||
w := NewWorker(q, &fakeProvider{}, "worker-1")
|
||||
if err := w.ProcessOne(context.Background()); err != nil {
|
||||
t.Fatalf("processone: %v", err)
|
||||
}
|
||||
if _, err := q.Enqueue(context.Background(), KindChat, provider.ChatRequest{Model: "test"}, EnqueueOptions{}); err != nil {
|
||||
t.Fatalf("enqueue nach freigewordenem platz: %v", err)
|
||||
}
|
||||
}
|
||||
@@ -9,7 +9,7 @@ import (
|
||||
"net/http"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/residency"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/svcauth"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/svcauth"
|
||||
)
|
||||
|
||||
type Server struct {
|
||||
|
||||
@@ -13,7 +13,7 @@ import (
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/historysuggest"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/routingfeedback"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/svcauth"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/svcauth"
|
||||
)
|
||||
|
||||
type Server struct {
|
||||
|
||||
@@ -10,7 +10,7 @@ import (
|
||||
"net/http"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/semanticsearch"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/svcauth"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/svcauth"
|
||||
)
|
||||
|
||||
type Server struct {
|
||||
|
||||
@@ -10,8 +10,8 @@ import (
|
||||
"net/http"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/summarize"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/svcauth"
|
||||
"gitea.perlbach24.de/scripte/nexarch/ai/internal/threadsummarize"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/svcauth"
|
||||
)
|
||||
|
||||
type Server struct {
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
// Package svcauth vergleicht Service-Token in konstanter Zeit (eigene Kopie
|
||||
// je Modul, siehe workflow/internal/svcauth — Go-Module teilen keine
|
||||
// internal/-Pakete über Modulgrenzen; Lehre aus RET-14/F-08: Schutz beim
|
||||
// ersten Entwurf einbauen statt nachzuruesten).
|
||||
package svcauth
|
||||
|
||||
import (
|
||||
"crypto/sha256"
|
||||
"crypto/subtle"
|
||||
)
|
||||
|
||||
// Equal vergleicht die SHA-256-Werte beider Eingaben in konstanter Zeit.
|
||||
// Ein leeres erwartetes Token stimmt nie.
|
||||
func Equal(got, want string) bool {
|
||||
if want == "" {
|
||||
return false
|
||||
}
|
||||
g, w := sha256.Sum256([]byte(got)), sha256.Sum256([]byte(want))
|
||||
return subtle.ConstantTimeCompare(g[:], w[:]) == 1
|
||||
}
|
||||
File renamed without changes.
File renamed without changes.
@@ -12,9 +12,9 @@ import (
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/complianceapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/httpharden"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/rbacclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/retentionapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/httpharden"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
||||
@@ -10,10 +10,10 @@ import (
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/httpharden"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/kennzahlenapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/rbacclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/retentionapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/httpharden"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
||||
@@ -13,10 +13,10 @@ import (
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/httpharden"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/legalholdapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/moduleadapter"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/tenantregistryclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/httpharden"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
||||
@@ -10,8 +10,8 @@ import (
|
||||
"net/http"
|
||||
"os"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/httpharden"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/restoretest"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/httpharden"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
||||
@@ -13,9 +13,9 @@ import (
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/httpharden"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/rbacclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/retentionapi"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/httpharden"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
||||
@@ -14,8 +14,8 @@ import (
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/httpharden"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/scrub"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/httpharden"
|
||||
)
|
||||
|
||||
func main() {
|
||||
|
||||
@@ -1,100 +0,0 @@
|
||||
# QA-02 – Prüfprotokoll: Prüfgate Retention & WORM
|
||||
|
||||
Stand: 2026-10-16, Testhost 192.168.1.204 (echte `TEST_TENANT_DSN`-PostgreSQL-Testdatenbank, kein
|
||||
Mocking). Voraussetzung RET-03 (Löschworkflow & Legal Hold) und RET-04 (WORM-Speicher-Garantie) –
|
||||
beide Fertig, siehe `RET-03-PRUEFPROTOKOLL.md`/`RET-04-PRUEFPROTOKOLL.md`. Dieses Gate wiederholt
|
||||
deren Pflichtprüfungen unter Prüfgate-Bedingungen und bindet sie zusätzlich an den in QA-01
|
||||
definierten Referenzdatensatz (`internal/referenceset`).
|
||||
|
||||
## Umsetzung dieses Gates
|
||||
|
||||
- `archive/internal/deletionworkflow/deletionworkflow_test.go`: neuer Test
|
||||
`TestPruefgate02_LegalHoldResistsDeletionForReferenceSetObjects` – durchläuft alle drei
|
||||
`referenceset.RetentionObjects()` (`dms_document`/`steuerlich_10j`,
|
||||
`mail_message`/`handelsrechtlich_6j`, `audit_event`/`sofort_loeschbar`), setzt je Objekt eine
|
||||
Aufbewahrungssperre, prüft, dass `ReleaseExpired` das gesperrte, fällige Referenzobjekt NICHT
|
||||
freigibt, und dass `Destroy` mit `ErrOnLegalHold` scheitert.
|
||||
- `archive/internal/wormstore/wormstore_test.go`: neuer Test
|
||||
`TestPruefgate02_OverwriteAndTamperDetectionForReferenceSetPayloads` – schreibt je
|
||||
Größenklasse (`SizeSmall`/`SizeMedium`/`SizeLarge`) die deterministischen
|
||||
`referenceset.WormPayload`-Nutzdaten, vergleicht die Prüfsumme mit
|
||||
`referenceset.WormPayloadChecksum`, prüft den Überschreibversuch über die Go-API
|
||||
(`ErrAlreadyExists`) und den direkten Schreibzugriff am Dateisystem.
|
||||
- Kein Produktivcode in `deletionworkflow`/`wormstore` geändert – nur Testdateien, RET-03/RET-04
|
||||
bleiben unverändert (Pflichttestgate aus `TESTSTRATEGIE-ARCHIVE.md` Abschnitt 3 bleibt erfüllt).
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
|
||||
| # | Prüfung | Zielwert | Messwert | Bewertung |
|
||||
|---|---|---|---|---|
|
||||
| 1 | Löschversuch an gesperrtem Objekt schlägt fehl (RET-03, Referenzdatensatz) | `Destroy` liefert `ErrOnLegalHold` für jedes der drei Referenzobjekte, Status bleibt unverändert, `ReleaseExpired` gibt das gesperrte Objekt trotz Fälligkeit nicht frei | `go test ./internal/deletionworkflow/... -v -count=1` gegen echte `TEST_TENANT_DSN`-DB, 2026-10-16: **7/7 PASS**, davon `TestDestroy_ObjectWithActiveHoldResistsDeletion` (Alt-Fixture) und `TestPruefgate02_LegalHoldResistsDeletionForReferenceSetObjects` (Referenzdatensatz, alle 3 Objekttypen) beide grün; zusätzlich `TestDestructionLog_IsItselfLogged`/`TestDestructionLog_IsImmutable`-Familie unverändert grün | **bestanden** |
|
||||
| 2 | Überschreibversuch am WORM-Speicher schlägt fehl (RET-04, Referenzdatensatz) | Zweiter `Put` auf denselben Schlüssel liefert `ErrAlreadyExists`; direkter Schreibzugriff am Dateisystem scheitert; Prüfsumme der gelesenen Daten entspricht `referenceset.WormPayloadChecksum` | **Teilweise bestanden, Teilergebnis offen** – siehe Restrisiko 1. Automatisierter Store-Testlauf (`TEST_WORMSTORE_LOCK_DIR` auf ZFS-Wurzel des Testhosts) übersprang 7 Tests (inkl. des neuen `TestPruefgate02_OverwriteAndTamperDetectionForReferenceSetPayloads`) real mit der Meldung "chattr +i wird ... nicht durchgesetzt" – reproduziert exakt den in `RET-11-PRUEFPROTOKOLL.md` für Host 131 dokumentierten Befund, jetzt auch für Host 204 bestätigt. Als Ersatznachweis für die ursprüngliche RET-04-Garantie (chmod 0400, ohne chattr) wurde **manuell** als echter Betriebsnutzer geprüft: Verzeichnis `nexarch:nexarch`-Eigentümer (realistische Produktionslage), Datei von `nexarch` geschrieben und anschließend `chmod 0400` gesetzt; `sudo -u nexarch` Schreibversuch auf die Datei → **„Permission denied", Exit 1**, Inhalt unverändert. Reflection-Test `TestStore_OnlyDestroyCanRemoveObjects` (kein Lösch-Pfad außer `Destroy`) lief real und **PASS** | **teilweise bestanden** (Schreibschutz real nachgewiesen, Storage-Object-Lock-Ebene auf diesem Host nicht prüfbar) |
|
||||
| 3 | Offene Restrisiken sind schriftlich benannt | Vollständige, ehrliche Liste | 3 Punkte identifiziert und dokumentiert (unten) | **bestanden** |
|
||||
|
||||
## Build/Test-Ergebnis (192.168.1.204)
|
||||
|
||||
```
|
||||
cd archive && go build ./... -> clean
|
||||
cd archive && go vet ./... -> clean
|
||||
golangci-lint -> auf Host 204 nicht installiert (anders als 131 in frueheren
|
||||
Protokollen; keine Installation vorgenommen, siehe Vorgabe
|
||||
"keine Toolchain-Installationen auf 204"); go vet als
|
||||
verfuegbare statische Pruefstufe genutzt
|
||||
go test ./internal/deletionworkflow/... -v -count=1
|
||||
-> 7/7 PASS (TEST_TENANT_DSN, echte Postgres-Testdatenbank)
|
||||
go test ./internal/wormstore/... -v -count=1
|
||||
-> 1 PASS (TestStore_OnlyDestroyCanRemoveObjects), 7 SKIP (chattr +i auf
|
||||
ZFS/unprivilegiertem LXC-Host strukturell nicht durchsetzbar)
|
||||
```
|
||||
|
||||
Manueller Zusatznachweis (nicht Teil der Go-Testsuite, siehe Prüfung 2): Verzeichnis-/Datei-Setup
|
||||
und `sudo -u nexarch`-Schreibversuch, durchgeführt 2026-10-16 ca. 12:11 UTC, Testartefakte danach
|
||||
entfernt (`/tmp/qa02-worm-manual2`).
|
||||
|
||||
## Offene Restrisiken (Akzeptanzkriterium/Pflichtprüfung 3)
|
||||
|
||||
1. **Storage-Object-Lock (RET-11, `chattr +i`) auf keinem bekannten Host dieses Projekts real
|
||||
nachweisbar – potenziell auch in Produktion nicht funktionsfähig.** `wormstore.Store.Put` ist
|
||||
seit RET-11 fail-closed: schlägt das Setzen von `chattr +i` fehl, wird die bereits geschriebene
|
||||
Datei wieder entfernt und `Put` insgesamt mit Fehler beendet. Sowohl Host 131
|
||||
(`RET-11-PRUEFPROTOKOLL.md`) als auch – in diesem Gate neu bestätigt – Host 204 sind
|
||||
unprivilegierte Proxmox-LXC-Container auf ZFS-Root, auf denen `chattr +i` strukturell mit
|
||||
`EPERM` scheitert. `docs/STORAGE-KONZEPT.md` Abschnitt 10 benennt "Stufe 1 (Einzel-LXC)" mit
|
||||
"lokales Dateisystem oder ZFS" ausdrücklich als Ziel-Produktionsarchitektur – also exakt dieselbe
|
||||
Kombination, an der `chattr +i` auf beiden bisher geprüften Hosts scheitert. **Ungeklärt, ob
|
||||
`wormstore.Store.Put` in der aktuellen, dokumentierten Zielarchitektur überhaupt jemals
|
||||
erfolgreich schreiben kann.** Das ist kein neuer Befund dieses Gates (RET-11 selbst stufte seine
|
||||
Prüfungen 1/2 bereits als "offen" ein), aber die erneute Bestätigung auf einem zweiten,
|
||||
unabhängigen Host erhöht das Gewicht dieses Risikos von "Testumgebungs-Lücke" zu
|
||||
"möglicherweise produktionsrelevant". **Empfehlung:** eigenes Folgeticket, das (a) `Put` entweder
|
||||
mit einem privilegierten Container/VM mit ext4/xfs/btrfs-Backing real verifiziert, oder (b) einen
|
||||
Fallback-Modus für Hosts ohne `CAP_LINUX_IMMUTABLE`-Durchsetzung definiert, statt stillschweigend
|
||||
jeden Schreibvorgang scheitern zu lassen.
|
||||
2. **Referenzdatensatz-Bindung deckt nur RET-03/RET-04 ab, nicht RET-06/RET-07.** Die
|
||||
Ausgangslage dieses Tickets nennt RET-06 (Fristen-Konfigurationsoberfläche) und RET-07
|
||||
(Fristablauf-Benachrichtigungen) als bereits fertiggestellt, QA-02s Akzeptanzkriterien verlangen
|
||||
aber ausdrücklich nur den Nachweis für RET-03/RET-04 – dieses Gate prüft RET-06/RET-07 bewusst
|
||||
nicht erneut (kein Scope-Drift). Ein eigenes Prüfgate für RET-06/RET-07 existiert nach aktuellem
|
||||
Stand nicht.
|
||||
3. **`golangci-lint` auf Host 204 nicht verfügbar.** Frühere Archive-Prüfprotokolle (RET-03, RET-04,
|
||||
RET-11) liefen auf Host 131 inklusive `golangci-lint run ./...`. Auf 204 steht das Werkzeug nicht
|
||||
zur Verfügung und wurde gemäß Vorgabe (keine Toolchain-Installation auf 204) nicht nachinstalliert
|
||||
– `go build`/`go vet` liefen stattdessen clean, ersetzen aber nicht den vollen Lint-Umfang.
|
||||
|
||||
## Gesamtergebnis
|
||||
|
||||
**Teilweise bestanden.** RET-03 (Löschworkflow & Legal Hold) ist vollständig und real gegen den
|
||||
Referenzdatensatz nachgewiesen (Prüfung 1: bestanden). RET-04 (WORM-Speicher) ist in seinem
|
||||
ursprünglichen, eigenen Geltungsbereich (Anwendungs-API ohne Lösch-Pfad, Schreibschutz gegen den
|
||||
realen Betriebsnutzer `nexarch`) real bestätigt, die seit RET-11 zusätzliche
|
||||
Storage-Object-Lock-Ebene bleibt auf diesem Host technisch nicht prüfbar (Prüfung 2: teilweise
|
||||
bestanden). Drei Restrisiken benannt, keines davon ist ein neu eingeführter Fehler dieses Gates –
|
||||
Restrisiko 1 verdient wegen der Übereinstimmung mit der dokumentierten Zielarchitektur
|
||||
(`STORAGE-KONZEPT.md`) besondere Priorität vor einer produktiven Freigabe der WORM-Funktion.
|
||||
|
||||
## Unterschriften
|
||||
|
||||
- **Umsetzung:** Claude (Agent), 2026-10-16 — alle Prüfungen durchgeführt, Protokoll erstellt.
|
||||
- **Gegenzeichnung:** aussteht (wie bei früheren QA-Gates wird das Gegenlesen im Pull Request
|
||||
nachgetragen, sobald eine zweite Person verfügbar ist; blockiert nicht das technische
|
||||
Inkrafttreten dieses Protokolls).
|
||||
@@ -1,215 +0,0 @@
|
||||
# QA-03 – Prüfprotokoll: Prüfgate Compliance & eDiscovery
|
||||
|
||||
Stand: 2026-10-16. Testhost 192.168.1.204, echte PostgreSQL-Testdatenbank (`TEST_TENANT_DSN`
|
||||
aus `/etc/nexarch-dev/tenant-dev.env`, `TEST_ADMIN_DSN` aus `/etc/nexarch-dev/core-dev.env`).
|
||||
Alle Testdaten synthetisch (Referenzdatensatz aus `archive/internal/referenceset`, QA-01
|
||||
Abschnitt 4) — keine echten Kunden-/Mandantendaten.
|
||||
|
||||
Voraussetzung: CMP-03 (eDiscovery-Suche & Export), CMP-06 (Vier-Augen-Freigabe) — beide bereits
|
||||
Fertig. Dieses Ticket dupliziert ihre Funktionalität nicht, sondern bildet das Freigabe-Gate: die
|
||||
bestehenden Prüfungen werden erneut, real und nachweisbar gegen die aktuelle Codebasis
|
||||
durchgeführt, ergänzt um zwei gezielte Prüfungen gegen den offiziellen Referenzdatensatz bzw.
|
||||
mit ausdrücklich benannten, unabhängigen Testrollen.
|
||||
|
||||
## Prüfung 1 (Akzeptanzkriterium 1 / Pflichtprüfung 1): Export-Prüfsummen stimmen bei wiederholtem Testlauf erneut überein
|
||||
|
||||
Neuer Test `TestExport_QA03_ReproducibleAgainstReferenceDataset`
|
||||
(`archive/internal/ediscovery/ediscovery_test.go`): baut aus
|
||||
`referenceset.RetentionObjects()` (die drei kanonischen Objekttypen `dms_document`,
|
||||
`mail_message`, `audit_event` des Referenzdatensatzes) fiktive Module mit deterministischem
|
||||
Inhalt (`referenceset.WormPayload(SizeSmall)`) und führt `ediscovery.Export()` zweimal
|
||||
unabhängig voneinander über denselben Referenzdatensatz aus.
|
||||
|
||||
| Prüfgröße | Zielwert | Messwert | Bewertung |
|
||||
|---|---|---|---|
|
||||
| Anzahl Prüfsummen je Exportlauf | 3 (ein Objekt je Referenzdatensatz-Objekttyp) | 3 | bestanden |
|
||||
| Übereinstimmung der Prüfsummen zwischen Lauf 1 und Lauf 2 | identisch (`reflect.DeepEqual`) | identisch | bestanden |
|
||||
| Testergebnis | PASS | PASS (`go test ./internal/ediscovery/... -run TestExport_QA03_ReproducibleAgainstReferenceDataset -v`) | bestanden |
|
||||
|
||||
Zusätzlich erneut durchgeführt und grün: die bestehenden CMP-03-Prüfungen
|
||||
`TestSearch_CombinesHitsFromMultipleModules`, `TestSearch_OneFailingModuleDoesNotSwallowOtherHits`,
|
||||
`TestExport_ChecksumsMatchAfterUnzip` — alle PASS, keine Regression.
|
||||
|
||||
## Prüfung 2 (Akzeptanzkriterium 2 / Pflichtprüfung 2): Vier-Augen-Freigabe mit zwei unabhängigen Testrollen erneut nachgewiesen
|
||||
|
||||
Neuer Test `TestConfirmAndExecute_QA03_TwoIndependentTestRoles`
|
||||
(`archive/internal/deletionapproval/deletionapproval_test.go`) gegen die echte
|
||||
PostgreSQL-Testdatenbank (`TEST_TENANT_DSN`), mit zwei ausdrücklich benannten, unabhängigen
|
||||
Testrollen (`testrolle_sachbearbeiterin_a@qa03.example` fordert an,
|
||||
`testrolle_pruefer_b@qa03.example` bestätigt):
|
||||
|
||||
| Prüfgröße | Zielwert | Messwert | Bewertung |
|
||||
|---|---|---|---|
|
||||
| Freigabe durch unabhängige zweite Testrolle (B) auf Anforderung von Testrolle A | Löschung wird ausgeführt, Objektstatus `deleted` | Löschung real ausgeführt, Status `deleted` | bestanden |
|
||||
| Freigabeversuch durch dieselbe Testrolle (A bestätigt eigene Anforderung), ohne zweite Bestätigung | `ErrSamePerson`, Objektstatus bleibt `expired` (keine Löschung) | `ErrSamePerson`, Status real unverändert `expired` | bestanden |
|
||||
| Testergebnis | PASS | PASS (`go test ./internal/deletionapproval/... -run TestConfirmAndExecute_QA03_TwoIndependentTestRoles -v`) | bestanden |
|
||||
|
||||
Zusätzlich erneut durchgeführt und grün, gegen dieselbe echte Testdatenbank: die bestehenden
|
||||
CMP-06-Pflichtprüfungen `TestConfirmAndExecute_ParallelConfirmationsExecuteOnlyOnce` (echte
|
||||
Nebenläufigkeit, zwei Goroutinen, genau eine Ausführung), `TestConfirmAndExecute_SamePersonRejected`,
|
||||
`TestTimingSafeTokenMatch_ConstantTime`, `TestConfirmAndExecute_ExpiredTokenRejected` — alle PASS,
|
||||
keine Regression.
|
||||
|
||||
## Prüfung 3 (Akzeptanzkriterium 3 / Pflichtprüfung 3): Protokoll abgelegt, offene Restrisiken benannt
|
||||
|
||||
Dieses Dokument ist das geforderte Protokoll mit Zielwert, Messwert und Bewertung je Prüfung
|
||||
(Tabellen oben). Offene Restrisiken, durch QA-03 nicht geschlossen:
|
||||
|
||||
- **eDiscovery-Adapter real nur fiktiv**: `ediscovery.ModuleAdapter` wird in Produktion über
|
||||
HTTP an echte DMS-/Mail-Endpunkte gebunden (analog `rbacclient`/`kekclient`); dieses Gate prüft
|
||||
weiterhin nur die Aggregations-/Exportlogik gegen fiktive Testmodule, keine echte
|
||||
Ende-zu-Ende-Suche gegen laufende DMS-/Mail-Instanzen. Das ist ausdrücklich Gegenstand von
|
||||
QA-05 (Abnahme- & Compliance-Prüfung Archive), nicht dieser Kachel.
|
||||
- **Rollenberechtigung der Bestätigung ungeprüft**: `deletionapproval.ConfirmAndExecute` prüft nur,
|
||||
dass `confirmed_by != requested_by` — nicht, dass die bestätigende Person tatsächlich eine
|
||||
RBAC-Berechtigung zur Löschfreigabe besitzt. Diese Durchsetzung liegt (falls vorhanden) in einer
|
||||
höheren API-Schicht außerhalb dieses Pakets und ist nicht Bestandteil dieses Gates.
|
||||
- **CMP-01/CMP-04/CMP-05/CMP-07 nicht erneut geprüft**: QA-03 ist laut Ticket exakt auf
|
||||
eDiscovery-Export (CMP-03) und Vier-Augen-Freigabe (CMP-06) begrenzt. GoBD-Verfahrensdokumentation,
|
||||
Audit-Trail-Kopplung, Compliance-Oberfläche und DSGVO-Löschantrag-Workflow sind Voraussetzung,
|
||||
werden hier aber nicht erneut geprüft — das ist Gegenstand von QA-05.
|
||||
|
||||
## Build-/Testergebnis (192.168.1.204)
|
||||
|
||||
```
|
||||
go build ./... -> clean
|
||||
go vet ./... -> clean
|
||||
go test ./... -p 1 -> alle Archive-Pakete bestanden (TEST_TENANT_DSN/TEST_ADMIN_DSN gesetzt)
|
||||
```
|
||||
|
||||
golangci-lint ist auf Host 204 nicht installiert (Vorgabe: keine Toolchain-Installationen auf
|
||||
diesem Host) — Build/Vet/Test sind die verfügbaren automatisierten Prüfungen.
|
||||
|
||||
## Gesamtergebnis
|
||||
|
||||
**Bestanden.** Beide Akzeptanzkriterien und alle drei Pflichtprüfungen real erneut durchgeführt
|
||||
und nachgewiesen: eDiscovery-Export gegen den offiziellen Referenzdatensatz mit zwei unabhängigen,
|
||||
übereinstimmenden Exportläufen; Vier-Augen-Freigabe mit zwei ausdrücklich benannten, unabhängigen
|
||||
Testrollen (Erfolgsfall und erneut scheiternder Alleingang); Protokoll mit Zielwert/Messwert/
|
||||
Bewertung abgelegt, offene Restrisiken schriftlich benannt. Freigabe der Compliance-Funktionen aus
|
||||
Sicht dieses Gates erteilt — Gesamtabnahme bleibt QA-05 vorbehalten.
|
||||
|
||||
## Nachtrag CMP-08 (Stand 2026-10-16): Ende-zu-Ende-Nachweis des Adapters gegen echte DMS-/Mail-Testinstanzen
|
||||
|
||||
Schließt den oben in Abschnitt "Restrisiken" benannten Punkt **"eDiscovery-Adapter real nur
|
||||
fiktiv"**. Neue Produktivkomponente `archive/internal/ediscoveryhttp` (analog
|
||||
`kekclient`/`rbacclient`): `DMSAdapter` und `MailAdapter` implementieren
|
||||
`ediscovery.ModuleAdapter` über echtes HTTP gegen die realen REST-Endpunkte von DMS
|
||||
(`dms/internal/searchapi` `GET /search`, `dms/internal/documentapi` `GET
|
||||
/documents/{id}/content`) bzw. Mail (`mail/internal/mailapi` `GET /api/v1/mail/messages`,
|
||||
`GET /api/v1/mail/messages/{id}`, mit Modul-Token `aud=mail`).
|
||||
|
||||
### Echte Testinstanzen (Host 192.168.1.204)
|
||||
|
||||
- **DMS**: echter `dms/internal/searchwiring` + neu ergänzter `dms/internal/documentapi` auf
|
||||
einem frisch migrierten Schema der bestehenden Dev-Datenbank `dms_dev`
|
||||
(`NEXARCH_DMS_APP_TENANT_DSN` aus `/etc/nexarch-dev/dms-dev.env`), echtes Manticore
|
||||
(`TEST_MANTICORE_ADDR`), 4 synthetische PDF-Belege über den echten Upload-/Worker-Pfad
|
||||
(`dms/internal/upload`, `dms/internal/workerruntime`, `dms/internal/testcorpus`) hochgeladen
|
||||
und über die echte Volltextsuche auffindbar gemacht — keine Fixture-Doubles.
|
||||
- **Mail**: echter `mail/internal/mailapi.Server`, mit echtem `mail/internal/search.Client`
|
||||
(Manticore-Tabelle `mail_documents`, eigener Mandant `cmp08-ediscovery-mail`) und echtem
|
||||
`mail/internal/storage.Service`; 4 synthetische Nachrichten über `search.Client.Index`
|
||||
eingetragen. Mail hat noch keinen eigenen `cmd/app`-Produktivserver (siehe
|
||||
`mail/internal/mailapi`-Paketkommentar) — Modul-Token-Verifikation läuft über die ECHTE
|
||||
Verifikationslogik `mail/internal/moduleauth.Verifier`, mit einem lokal erzeugten
|
||||
Test-Schlüsselpaar statt eines laufenden Core-Kontodienstes (`NewTestVerifierAndIssuer`,
|
||||
dieselbe Konvention wie `mail/internal/mailapi/e2e_test.go`) — siehe Restrisiko unten.
|
||||
- Beide Instanzen liefen als Wegwerf-Prüfwerkzeuge (`dms/cmd/cmp08-ediscovery-fixture`,
|
||||
`mail/cmd/cmp08-ediscovery-fixture`), nach dem Testlauf wieder entfernt — nicht Teil dieses
|
||||
Commits, nur die Produktivkomponente (`ediscoveryhttp`) und der Nachweistest bleiben.
|
||||
- Alle Testdaten synthetisch (Suchbegriff `CmpAchtEdiscoveryFund`, Absendername
|
||||
`pruefperson@cmp08.example.test`), keine echten Kunden-/Mandantendaten.
|
||||
|
||||
### Prüfung 1 (Akzeptanzkriterium 1): Export gegen echte, über RET-05 registrierte Instanzen
|
||||
|
||||
Vor dem eigentlichen Such-/Exportlauf registriert der Test beide Instanzen real über das
|
||||
bestehende RET-05-Interface (`archive/internal/moduleadapter.Register`) gegen die echte
|
||||
Postgres-Testdatenbank (`TEST_TENANT_DSN`): `module_name=dms/object_type=dms_document` mit
|
||||
Rückruf-Adresse der echten laufenden DMS-Instanz, `module_name=mail/object_type=mail_message`
|
||||
mit Rückruf-Adresse der echten laufenden Mail-Instanz.
|
||||
|
||||
| Prüfgröße | Zielwert | Messwert | Bewertung |
|
||||
|---|---|---|---|
|
||||
| Registrierungen in `module_registrations` nach Register() | 2 (DMS + Mail) | 2 | bestanden |
|
||||
| Export erfolgt gegen die registrierten, laufenden Instanzen (nicht Referenzdatensatz) | ja | ja — `ediscoveryhttp.DMSAdapter`/`MailAdapter` rufen die echten Endpunkte auf | bestanden |
|
||||
|
||||
### Prüfung 2 (Akzeptanzkriterium 2): Treffer aus beiden Modulen, prüfsummengesichert
|
||||
|
||||
Test `TestEndToEnd_CMP08_RealDMSAndMailInstances`
|
||||
(`archive/internal/ediscoveryhttp/e2e_test.go`): `ediscovery.Search()` über beide echten
|
||||
Adapter, `ediscovery.Export()` baut das ZIP, der Test entpackt es erneut und vergleicht die
|
||||
SHA-256-Prüfsumme jeder Datei gegen den `manifest.json`-Eintrag.
|
||||
|
||||
| Prüfgröße | Zielwert | Messwert | Bewertung |
|
||||
|---|---|---|---|
|
||||
| Treffer mit `module_type=dms_document` im Suchergebnis | ≥ 1 | 4 | bestanden |
|
||||
| Treffer mit `module_type=mail_message` im Suchergebnis | ≥ 1 | 4 | bestanden |
|
||||
| Prüfsumme nach Entpacken stimmt für jede Datei (beide Modultypen) | 100 % Übereinstimmung | 100 % (8/8 Dateien) | bestanden |
|
||||
|
||||
### Prüfung 3 (Pflichtprüfung 2): Export-Prüfsummen bei wiederholtem Testlauf identisch
|
||||
|
||||
Zwei unabhängige `Search()+Export()`-Durchläufe INNERHALB desselben Testlaufs (frischer
|
||||
HTTP-Roundtrip gegen die echten Instanzen, nicht wiederverwendete Treffer), Vergleich über
|
||||
`modultyp+referenz` statt Listenposition (Reihenfolge der Suchtreffer ist zwischen Läufen nicht
|
||||
garantiert stabil). Zusätzlich der komplette Test zweimal als VOLLSTÄNDIG unabhängiger
|
||||
`go test`-Prozessaufruf gegen dieselben laufenden Instanzen wiederholt.
|
||||
|
||||
| Prüfgröße | Zielwert | Messwert | Bewertung |
|
||||
|---|---|---|---|
|
||||
| Prüfsummen Lauf 1 vs. Lauf 2 (innerhalb des Tests, je Treffer) | identisch | identisch (8/8) | bestanden |
|
||||
| Testergebnis über 2 unabhängige Prozessaufrufe hinweg | PASS, PASS | PASS, PASS | bestanden |
|
||||
|
||||
### Build-/Testergebnis (192.168.1.204)
|
||||
|
||||
```
|
||||
go build ./... -> clean
|
||||
go vet ./... -> clean
|
||||
go test ./internal/ediscoveryhttp/... -v -> PASS (2x unabhaengiger Prozessaufruf)
|
||||
go test ./... -p 1 -> alle Archive-Pakete bestanden (2x wiederholt)
|
||||
```
|
||||
|
||||
Ein einzelner, nicht reproduzierbarer Fehlschlag in `archive/internal/reconcile`
|
||||
(`TestListDBStorageKeys_ReadsRealFileRevisions`, "erwartet 1 Eintrag, habe 9") trat einmalig
|
||||
während eines `go test ./... -p 1`-Laufs auf. Isoliert ausgeführt sowie in je zwei weiteren
|
||||
vollständigen Suite-Läufen (mit UND ohne die CMP-08-Änderungen) bestand dieser Test
|
||||
durchgehend — kein durch CMP-08 verursachter Regressionsbefund, sondern dieselbe Art
|
||||
Testisolations-Lücke gegen die geteilte `TEST_TENANT_DSN`-Datenbank, wie sie für das DMS-Modul
|
||||
bereits dokumentiert ist. Nicht in dieser Kachel behoben (unverändertes, fremdes Paket).
|
||||
|
||||
### Restrisiken (neu, durch CMP-08 gefunden)
|
||||
|
||||
- **Mail hat noch keinen RET-05-Rückruf-EMPFÄNGER**: DMS registriert sich bereits produktiv
|
||||
selbst gegen RET-05 inkl. echtem Rückruf-Empfänger (`dms/cmd/app` `setupRetention`,
|
||||
DOC-16, `POST /retention/destroy-callback`). Für Mail existiert dieses Gegenstück noch nicht
|
||||
(nur der RET-13-Sperrabfrage-Client `mail/internal/retentionclient`) — die in diesem Test
|
||||
registrierte Rückruf-Adresse der Mail-Instanz ist real erreichbar, aber die Instanz
|
||||
verarbeitet eingehende Vernichtungs-Rückrufe fachlich noch nicht. Empfehlung: eigenes
|
||||
Folgeticket, Mail-seitige Rückruf-Verarbeitung analog DOC-16 ergänzen, sobald Mail einen
|
||||
eigenen `cmd/app` bekommt.
|
||||
- **Mail-Modul-Token stammt aus einem Test-Schlüsselpaar, nicht vom echten Core-Kontodienst**:
|
||||
weil Mail noch keinen produktiven Server-Prozess hat, an den ein echter Core-JWKS-Abruf
|
||||
gebunden werden könnte (anders als bei DMS, dessen `cmd/app` dafür bereits verdrahtet ist).
|
||||
Die Verifikationslogik selbst (`moduleauth.Verifier`) ist unverändert die Produktivfunktion.
|
||||
Ein Nachweis mit einem vom echten Core ausgestellten Token (wie in
|
||||
`mail/internal/mailapi/e2e_test.go` `TestEndToEnd_RealCoreToken`) ist erst möglich, sobald ein
|
||||
Core-Kontodienst auf demselben Testhost erreichbar ist — außerhalb des Zuschnitts dieser
|
||||
Kachel (keine neue eDiscovery-Funktionalität, kein Core-Deployment).
|
||||
- **RET-05-Tenant-Verifikation (Core TEN-01) nicht Teil dieses Nachweises**: die Registrierung
|
||||
erfolgte über den direkten Aufruf von `moduleadapter.Register` (die reale
|
||||
Persistenzfunktion), nicht über den HTTP-Endpunkt `archive/cmd/moduleadapter-api` mit
|
||||
`tenantregistryclient.VerifyTenant` gegen einen echten Core-TEN-01-Dienst — letzterer war auf
|
||||
diesem Testhost nicht aufgesetzt (separates Infrastrukturthema, keine eDiscovery-Logik). Die
|
||||
eigentliche RET-05-Speicherlogik (Register/ListRegistrations, Idempotenz) ist bereits durch
|
||||
RET-05/RET-09 real geprüft und wird hier nicht erneut bewiesen.
|
||||
- golangci-lint weiterhin nicht auf Host 204 installiert (siehe QA-03 oben, unverändert).
|
||||
|
||||
### Gesamtergebnis CMP-08
|
||||
|
||||
**Bestanden.** Alle drei Akzeptanzkriterien und beide Pflichtprüfungen real gegen echte,
|
||||
laufende DMS- und Mail-Testinstanzen (keine Referenzdatensatz-Fixtures) nachgewiesen:
|
||||
RET-05-Registrierung beider Instanzen, Suchtreffer aus beiden Modulen im Export,
|
||||
prüfsummengesicherte Übereinstimmung nach Entpacken, Reproduzierbarkeit über zwei
|
||||
In-Test-Läufe UND zwei unabhängige Prozessaufrufe hinweg. Neue, bisher offene Restrisiken
|
||||
schriftlich benannt (Mail-seitiger Rückruf-Empfänger fehlt, Core-Token-Ausstellung für Mail
|
||||
noch nicht end-to-end, RET-05-Tenant-Verifikation nicht mitgeprüft).
|
||||
@@ -1,150 +0,0 @@
|
||||
# QA-05 – Gesamtabnahme- & Compliance-Prüfung Archive
|
||||
|
||||
Stand: 2026-10-16. Testhost 192.168.1.204 (frischer Klon, `feature/qa-05-abnahme-und-compliance-prüfung-archive`,
|
||||
abgezweigt von `main`). QA-05 führt keine eigenen fachlichen Prüfungen durch, sondern konsolidiert
|
||||
die drei geforderten Einzelgates (QA-02, QA-03, QA-04) sowie ergänzend QA-06/QA-07 zu einer
|
||||
Gesamtfreigabeentscheidung. Keine Änderung an Produktivcode oder an den Einzelprotokollen.
|
||||
|
||||
## Quellenlage
|
||||
|
||||
`main` enthielt zum Start dieses Tickets nur `QA-04-ABNAHMEPROTOKOLL.md` und
|
||||
`QA-06-PRUEFPROTOKOLL.md` in `archive/docs/`. `QA-02-PRUEFPROTOKOLL.md`, `QA-03-PRUEFPROTOKOLL.md`
|
||||
und `QA-07-PRUEFPROTOKOLL.md` lagen noch nicht in `main`, sondern nur auf den offenen
|
||||
Feature-Branches. Diese wurden per `git fetch` gelesen, ohne zu mergen:
|
||||
|
||||
- `origin/feature/qa-02-prüfgate-retention-und-worm:archive/docs/QA-02-PRUEFPROTOKOLL.md`
|
||||
- `origin/feature/qa-03-prüfgate-compliance-und-ediscovery:archive/docs/QA-03-PRUEFPROTOKOLL.md`
|
||||
- `origin/feature/qa-07-last-leistungstest:archive/docs/QA-07-PRUEFPROTOKOLL.md`
|
||||
|
||||
`archive/docs/QA-04-ABNAHMEPROTOKOLL.md`, `archive/docs/QA-06-PRUEFPROTOKOLL.md` und
|
||||
`archive/docs/RET-11-PRUEFPROTOKOLL.md` wurden direkt aus `main` gelesen.
|
||||
|
||||
## 1. Zusammenfassung der drei fachlichen Prüfgates (Akzeptanzkriterium 1/2)
|
||||
|
||||
| Gate | Gegenstand | Einzelergebnis laut eigenem Protokoll | Bewertung für QA-05 |
|
||||
|---|---|---|---|
|
||||
| **QA-02** | Retention & WORM (RET-03 Legal Hold, RET-04 WORM-Speicher) | Prüfung 1 (Legal Hold gegen Referenzdatensatz): **bestanden**, 7/7 PASS. Prüfung 2 (WORM-Überschreibschutz): **teilweise bestanden** – Anwendungs-/Dateisystem-Schreibschutz (chmod 0400, `ErrAlreadyExists`, `sudo -u nexarch`-Schreibversuch → Permission denied) real nachgewiesen; die zusätzliche Storage-Object-Lock-Ebene (`chattr +i`) auf Host 204 strukturell nicht prüfbar (7 Tests SKIP). Gesamtergebnis des eigenen Protokolls: "Teilweise bestanden". | **bestanden** im Sinne von Akzeptanzkriterium 1 – die für RET-03/RET-04 geforderte Kernfunktion ist nachgewiesen, der offene Rest ist exakt der unten konsolidierte WORM-Storage-Lock-Punkt, kein zusätzlicher Fund |
|
||||
| **QA-03** | Compliance & eDiscovery (CMP-03 Export, CMP-06 Vier-Augen-Freigabe) | Beide Pflichtprüfungen **bestanden**: Export-Prüfsummen bei zwei unabhängigen Läufen gegen den Referenzdatensatz identisch; Vier-Augen-Freigabe mit zwei benannten, unabhängigen Testrollen sowohl im Erfolgsfall als auch beim (abgelehnten) Alleingang real verifiziert. Keine Regression in den bestehenden CMP-03/CMP-06-Pflichttests. | **bestanden** |
|
||||
| **QA-04** | Backup & Restore (BAK-04 bis BAK-07) | Beide Nachhol-Prüfungen (realer Restore-Lauf DB+Objekt, anschließende Reconciliation) **bestanden**, Ergebnis leer/sauber. 5 Restrisiken benannt, keines blockiert laut eigenem Protokoll die Freigabe. Bereits mit Gegenzeichnung "Betreiber" versehen. | **bestanden** |
|
||||
|
||||
**Ergebnis Akzeptanzkriterium 1:** Alle drei fachlichen Prüfgates sind bestanden. QA-02 trägt dabei
|
||||
einen explizit benannten, nicht neu durch QA-05 eingeführten Restpunkt (Storage-Object-Lock), der
|
||||
unten konsolidiert wird.
|
||||
|
||||
## 2. Ergänzend konsolidiert (nicht Teil der drei Pflichtgates, aber laut Ausgangslage dieses Tickets relevant)
|
||||
|
||||
| Gate | Ergebnis |
|
||||
|---|---|
|
||||
| **QA-06** (Schnittstellen-Vertragstests) | **Bestanden**, bereits vorher in `main` gemergt. Contract-Tests (RET-05-Payloads) grün, Breaking-Change-Erkennung nachgewiesen, CI-Lauf real durchgeführt (Gitea-Actions-Run #30, Status success). |
|
||||
| **QA-07** (Last- & Leistungstest) | AC1 (Legal-Hold-Abfrage unter Last: p95 = 30,3 ms ≤ 50 ms, Durchsatz 6564,5/s ≥ 3000/s, 0 Fehler über 6000 Anfragen) **bestanden**. AC3 (RET-05-Registrierung, 240 parallele Aufrufe, 0 Fehler, keine Race-Duplikate/-Verluste) **bestanden**. AC2 (WORM-Schreibpfad unter Last) **offen auf Host 204** aus demselben chattr-Grund wie QA-02/RET-11 – Race-Freiheit der Schlüssel-Kollisionslogik zusätzlich per Code-Analyse (POSIX-Atomarität von `O_EXCL`) verifiziert, kein fabriziertes PASS. |
|
||||
|
||||
## 3. Konsolidierte Restrisiken (Prüfung vor der Abnahme 2)
|
||||
|
||||
### 3.1 Zentrales Restrisiko: Storage-Object-Lock (`chattr +i`) auf keinem bisher geprüften Host nachweisbar
|
||||
|
||||
Dreifach unabhängig bestätigt:
|
||||
|
||||
1. `RET-11-PRUEFPROTOKOLL.md` (Host 131, unprivilegiertes LXC auf ZFS-Root): `chattr +i` scheitert
|
||||
mit `EPERM`, obwohl `cap_linux_immutable` im Namespace-Bounding-Set erscheint – die reale
|
||||
Kernel-Prüfung greift gegen die gemappte UID, nicht gegen echte Capabilities.
|
||||
2. `QA-02-PRUEFPROTOKOLL.md` (Host 204): identischer Befund, 7 Tests SKIP.
|
||||
3. `QA-07-PRUEFPROTOKOLL.md` (Host 204, unter Last): identischer Befund, 2 Lasttests SKIP.
|
||||
|
||||
Zur Verifikation im Rahmen dieser Abnahme wurde der Befund auf Host 204 am frischen
|
||||
QA-05-Arbeitsverzeichnis ein viertes Mal real reproduziert (eigener, unabhängiger Probe-Lauf,
|
||||
nicht aus den obigen Protokollen übernommen):
|
||||
|
||||
```
|
||||
$ df -T /
|
||||
rpool/data/subvol-1204-disk-0 zfs ... /
|
||||
$ chattr +i probe.txt
|
||||
chattr: Operation not permitted while setting flags on probe.txt
|
||||
Exit-Code: 1
|
||||
```
|
||||
|
||||
**Bewertung der Tragweite:** `wormstore.Store.Put` (archive/internal/wormstore/wormstore.go)
|
||||
ruft `lockImmutable` unbedingt auf und entfernt bei Fehlschlag die bereits geschriebene Datei
|
||||
wieder – fail-closed, kein WORM-Objekt ohne tatsächliche Storage-Sperre. Das verhindert eine
|
||||
falsche Compliance-Zusage, bedeutet aber auch: auf einem Host, auf dem `chattr +i` nicht wirkt,
|
||||
schlägt **jeder einzelne** `Put`-Aufruf fehl – keine Archivierung, nicht nur ein Audit-Gap.
|
||||
|
||||
`RET-11-PRUEFPROTOKOLL.md` (Prüfung 3, bestanden) dokumentiert bereits die Betriebsvoraussetzung:
|
||||
das WORM-Basisverzeichnis muss auf einem chattr-fähigen Dateisystem (ext2/3/4, XFS, Btrfs) liegen,
|
||||
ausdrücklich NICHT auf ZFS, und der Prozess braucht reale (nicht nur Namespace-gemappte)
|
||||
`CAP_LINUX_IMMUTABLE`-Rechte. `STORAGE-KONZEPT.md` Abschnitt 2 führt für die Produktions-Zielstufe
|
||||
"Stufe 1 (Einzel-LXC)" jedoch "lokales Dateisystem ODER ZFS" als gleichwertige Optionen – ohne
|
||||
Verweis auf die engere WORM-spezifische Einschränkung aus RET-11. Beide bisher geprüften Hosts
|
||||
(131 und 204) sind exakt die Kombination (unprivilegiertes LXC auf ZFS), die laut RET-11 nicht
|
||||
funktioniert. Der erfolgreiche Pfad (echtes `chattr +i` auf einem konformen Host) wurde in diesem
|
||||
Projekt bislang **auf keinem einzigen Host real nachgewiesen** – es existiert bisher nur die
|
||||
Code-Analyse, dass es auf einem konformen Host funktionieren würde.
|
||||
|
||||
### 3.2 Weitere, nicht blockierende Restrisiken aus den Einzelgates
|
||||
|
||||
- **QA-02:** RET-06/RET-07 (Fristen-Konfiguration, Fristablauf-Benachrichtigung) wurden bewusst
|
||||
nicht erneut geprüft (außerhalb des QA-02-Scopes); `golangci-lint` auf Host 204 nicht verfügbar
|
||||
(Projektregel: keine Toolchain-Installation), `go build`/`go vet` liefen ersatzweise clean.
|
||||
- **QA-03:** Der eDiscovery-Modul-Adapter wurde nur gegen fiktive Testmodule geprüft, nicht gegen
|
||||
echte laufende DMS-/Mail-Instanzen; die Rollenberechtigung der Vier-Augen-Bestätigung selbst wird
|
||||
nicht in diesem Paket geprüft (liegt, falls vorhanden, in einer höheren API-Schicht).
|
||||
QA-03s eigenes Protokoll verweist diese Ende-zu-Ende-Prüfung ausdrücklich an QA-05 – der
|
||||
vorliegende QA-05-Tickettext begrenzt den Auftrag hier aber bewusst auf Konsolidierung der drei
|
||||
Gate-Ergebnisse, ohne eigene neue Prüfungen. Diese Diskrepanz wird hier offen benannt statt
|
||||
stillschweigend übergangen: eine echte Ende-zu-Ende-eDiscovery-Prüfung gegen laufende
|
||||
DMS-/Mail-Instanzen steht weiterhin aus und sollte als eigenes Folgeticket eingeplant werden.
|
||||
- **QA-04:** fünf im Einzelprotokoll benannte Restrisiken (fehlende Rotations-Kohärenz zwischen
|
||||
DB- und Objekt-Backup, manuelle BAK-04-Rollenvergabe je Mandant, BAK-08 deckt keine
|
||||
Storage-Provider-Lücke bei externem, nicht-kompatiblem Storage, Core-FDN-03/FDN-09-Wiring-Lücke,
|
||||
leerer Reconciliation-Testbestand) – laut Einzelprotokoll blockiert keines davon die Freigabe,
|
||||
bereits mit Gegenzeichnung "Betreiber" bestätigt.
|
||||
|
||||
## 4. Freigabeentscheidung (Prüfung vor der Abnahme 3)
|
||||
|
||||
**Bedingte Freigabe des Archive-Boards, mit namentlich benanntem Restrisiko und Empfehlung für ein
|
||||
Folgeticket.**
|
||||
|
||||
Begründung:
|
||||
|
||||
1. Alle drei geforderten fachlichen Prüfgates (QA-02, QA-03, QA-04) sind real, mit Messprotokoll
|
||||
und ohne fabrizierte Ergebnisse bestanden. QA-06 und QA-07 bestätigen dies zusätzlich für
|
||||
Schnittstellenverträge und Last.
|
||||
2. Das verbleibende Risiko (Storage-Object-Lock/`chattr +i`) ist ein **Fail-Closed**-Verhalten:
|
||||
`wormstore.Store.Put` gibt niemals eine WORM-Garantie vor, die storage-seitig nicht tatsächlich
|
||||
besteht – der worst case ist eine verweigerte Schreibung (Verfügbarkeits-/Betriebsproblem),
|
||||
niemals eine stillschweigend verletzte Unveränderlichkeits- oder Löschsperre
|
||||
(Integritäts-/Compliance-Problem). Das ist exakt das in der Produkt-DNA geforderte Verhalten
|
||||
("keine Freigabe auf Zuruf", hier technisch erzwungen statt nur organisatorisch versprochen) und
|
||||
entspricht dem Verhalten von S3 Object Lock Compliance-Mode, an dem sich RET-11 orientiert.
|
||||
3. Das Risiko ist kein neuer oder versteckter Befund, sondern seit RET-11 bekannt, in zwei weiteren,
|
||||
unabhängigen Prüfläufen (QA-02, QA-07) sowie einer vierten Probe im Rahmen dieser Abnahme erneut
|
||||
bestätigt, und in `RET-11-PRUEFPROTOKOLL.md` Prüfung 3 bereits als Betriebsvoraussetzung
|
||||
dokumentiert.
|
||||
4. Eine Freigabe ohne jede Einschränkung wäre dennoch nicht gerechtfertigt: der erfolgreiche Pfad
|
||||
(ein Host, auf dem `chattr +i` tatsächlich greift) wurde in diesem Projekt bislang **auf keinem
|
||||
einzigen Host real bestätigt** – nur per Code-Analyse. Zusätzlich widerspricht
|
||||
`STORAGE-KONZEPT.md` Abschnitt 2 (ZFS als gleichwertige Stufe-1-Backend-Option) ohne Verweis auf
|
||||
die RET-11-Einschränkung faktisch der dokumentierten WORM-Betriebsvoraussetzung – ein Ops-Team
|
||||
könnte Stufe 1 unwissentlich auf ZFS provisionieren und würde dort erst im Betrieb feststellen,
|
||||
dass jede WORM-geschützte Archivierung fehlschlägt.
|
||||
|
||||
**Bedingungen der Freigabe:**
|
||||
|
||||
- Folgeticket: realer End-to-End-Nachweis von `wormstore.Store.Put`/`Release`/`Destroy` auf
|
||||
mindestens einem Host mit echtem (nicht Namespace-gemapptem) `CAP_LINUX_IMMUTABLE` auf einem
|
||||
chattr-fähigen Dateisystem (ext4/xfs/btrfs, privilegierter Container oder VM), bevor WORM in
|
||||
einer produktiven Stufe-1-Umgebung als abgenommen gilt.
|
||||
- `STORAGE-KONZEPT.md` Abschnitt 2 um einen expliziten Verweis/Ausnahmevermerk ergänzen: das
|
||||
WORM-Basisverzeichnis ist von der generischen "lokales Dateisystem oder ZFS"-Option
|
||||
ausgenommen und benötigt zwingend ein chattr-fähiges Dateisystem mit realen
|
||||
`CAP_LINUX_IMMUTABLE`-Rechten (vor erster produktiver Stufe-1-Inbetriebnahme).
|
||||
- Offene, nicht blockierende Folgepunkte aus Abschnitt 3.2 (insbesondere die noch ausstehende
|
||||
echte Ende-zu-Ende-eDiscovery-Prüfung gegen laufende DMS-/Mail-Instanzen, von QA-03 an QA-05
|
||||
verwiesen, hier aber nicht in dessen Scope) als eigenes Ticket einplanen.
|
||||
|
||||
## 5. Unterschriften
|
||||
|
||||
- **Umsetzung:** Claude (Agent), 2026-10-16 — Konsolidierung durchgeführt, Quelldokumente geprüft,
|
||||
chattr-Befund auf Host 204 eigenständig reproduziert, Protokoll erstellt.
|
||||
- **Gegenzeichnung:** aussteht (wie bei früheren QA-Gates wird das Gegenlesen im Pull Request
|
||||
nachgetragen, sobald eine zweite Person verfügbar ist; blockiert nicht das technische
|
||||
Inkrafttreten dieses Protokolls).
|
||||
@@ -1,196 +0,0 @@
|
||||
# QA-07 — Last- & Leistungstest: Prüfprotokoll
|
||||
|
||||
Datum: 2026-10-16
|
||||
Host: 192.168.1.204 (Dev/Test, PostgreSQL-Testdatenbank, Wegwerf-DB `dms_dev`-Pendant für `archive`)
|
||||
Pakete: `archive/internal/loadtest` (neu, gemeinsam genutzt), Lasttests in
|
||||
`archive/internal/legalholdapi`, `archive/internal/moduleadapter`,
|
||||
`archive/internal/wormstore`
|
||||
|
||||
## Umsetzung
|
||||
|
||||
Neues, kleines Paket `archive/internal/loadtest`: parallele Ausführung
|
||||
über die Go-Standardbibliothek (`sync`, Worker-Pool über gepuffertem
|
||||
Channel), Latenzaufzeichnung je Durchlauf, Perzentil-/Durchsatzberechnung
|
||||
(`loadtest.Run`). Kein k6/vegeta nötig und keine Installation zusätzlicher
|
||||
Toolchains (Projektregel) — reale nebenläufige Aufrufe gegen die echten,
|
||||
in dieser Sitzung gebauten Pakete und eine echte PostgreSQL-Testdatenbank
|
||||
(`TEST_TENANT_DSN`), kein Mocking.
|
||||
|
||||
Je betroffenem Pfad ein Lasttest, DMS und Mail durch zwei disjunkte
|
||||
Schlüssel-/Objekttyp-Räume innerhalb desselben Testlaufs simuliert:
|
||||
|
||||
1. **Retention-/Legal-Hold-Abfrage (RET-03)** —
|
||||
`legalholdapi.TestLoadtest_LegalHoldQueryParallelFromDMSAndMail`:
|
||||
echter HTTP-Server (`httptest.NewServer`) vor dem produktiven
|
||||
`Handler`, 150 parallele Worker, 6000 Anfragen, abwechselnd
|
||||
`object_type=document` (DMS-Simulation, 300 vorab angelegte Objekte,
|
||||
jedes 5. gesperrt) und `object_type=message` (Mail-Simulation, 300
|
||||
Objekte, jedes 7. gesperrt).
|
||||
2. **Modul-Adapter-Registrierung (RET-05)** —
|
||||
`moduleadapter.TestLoadtest_ConcurrentRegistrationAcrossModules`: 30
|
||||
Objekttypen (15 je simuliertem Modul `dms-loadtest`/`mail-loadtest`),
|
||||
je Objekttyp 8 Racer, alle 240 Aufrufe gleichzeitig gestartet
|
||||
(`concurrency == total`), um den `ON CONFLICT DO NOTHING`-Pfad in
|
||||
`Register()` real in Konkurrenz zu zwingen statt nur sequenziell wie
|
||||
die bestehenden Tests (`TestRegister_TwoModulesNoCollision`).
|
||||
3. **WORM-Schreibpfad unter Last (RET-04/RET-11)** —
|
||||
`wormstore.TestLoadtest_ConcurrentPutFromDMSAndMail` (500 `Put`-Aufrufe,
|
||||
40 parallel, disjunkte Schlüssel je Modul, Nachweis über `GetVerified`
|
||||
je Objekt) und `wormstore.TestLoadtest_ConcurrentPutSameKeyFromBothModules`
|
||||
(20 gleichzeitige `Put`-Aufrufe auf GENAU DENSELBEN Schlüssel aus beiden
|
||||
simulierten Modulen — die geforderte Rennsituation).
|
||||
|
||||
**Zielwerte (Akzeptanzkriterium 1)** wurden vor dem entscheidenden
|
||||
Testlauf im Code festgelegt (`legalHoldTargetP95Latency`,
|
||||
`legalHoldTargetThroughput`), auf Basis einer Vorab-Messung auf
|
||||
demselben Host (reale Messung: p95 ≈ 25–33 ms, Durchsatz ≈ 6700–7300/s),
|
||||
mit Sicherheitsabstand:
|
||||
|
||||
| Pfad | Ziel p95-Latenz | Ziel-Durchsatz | Reale Messung (192.168.1.204) |
|
||||
|---|---|---|---|
|
||||
| Legal-Hold-Abfrage (RET-03) | ≤ 50 ms | ≥ 3000 Anfragen/s | p95 = 30,3 ms, Durchsatz = 6564,5/s |
|
||||
|
||||
(Für die Modul-Adapter-Registrierung (RET-05) und den WORM-Schreibpfad
|
||||
ist laut Ticket kein eigener Latenz-/Durchsatz-Zielwert gefordert,
|
||||
AC3/AC2 verlangen Race-Freiheit bzw. Datenverlustfreiheit — diese werden
|
||||
unten als Pass/Fail geprüft, Latenz/Durchsatz trotzdem mitprotokolliert.)
|
||||
|
||||
## Pflichtprüfung 1: Lasttest mit simulierten parallelen Anfragen aus DMS und Mail durchgeführt, Ergebnis dokumentiert
|
||||
|
||||
Realer Testlauf, `go test ./internal/legalholdapi/... ./internal/moduleadapter/... ./internal/wormstore/... -run TestLoadtest -v`:
|
||||
|
||||
```
|
||||
QA-07 Legal-Hold-Abfrage: 6000 Anfragen, 150 parallel, Dauer 914.0ms
|
||||
Fehler: 0
|
||||
Durchsatz: 6564.5 Anfragen/s (Ziel: >= 3000.0)
|
||||
Latenz p50=21.5ms p95=30.3ms (Ziel: <= 50ms) max=52.7ms
|
||||
|
||||
QA-07 Modul-Adapter-Registrierung: 240 Aufrufe, 240 parallel (30 Objekttypen x 8 Racer), Dauer 219.8ms
|
||||
Fehler: 0
|
||||
Durchsatz: 1092.1 Registrierungen/s
|
||||
Latenz p50=212.2ms p95=213.4ms max=216.3ms
|
||||
```
|
||||
|
||||
(WORM-Schreibpfad-Lauf siehe Pflichtprüfung 2 — auf diesem Host SKIP aus
|
||||
dokumentiertem Infra-Grund, kein gefälschtes Ergebnis.)
|
||||
|
||||
Ergebnis: **BESTANDEN** für Legal-Hold-Abfrage und Modul-Adapter-
|
||||
Registrierung — Null Fehler über 6000 bzw. 240 reale, parallele
|
||||
Aufrufe gegen die echte Testdatenbank `TEST_TENANT_DSN`.
|
||||
|
||||
## Pflichtprüfung 2: WORM-Schreibpfad unter Last auf Datenverlust/Race Conditions geprüft
|
||||
|
||||
Beide Tests sind vollständig implementiert und wurden real ausgeführt
|
||||
(kein Mock, reale Dateisystem- und DB-Operationen über
|
||||
`wormstore.Store.Put`/`GetVerified`). Ergebnis auf 192.168.1.204:
|
||||
|
||||
```
|
||||
=== RUN TestLoadtest_ConcurrentPutFromDMSAndMail
|
||||
chattr +i wird in TEST_WORMSTORE_LOCK_DIR nicht durchgesetzt (fehlende Capability oder ungeeignetes Dateisystem), Test uebersprungen
|
||||
--- SKIP
|
||||
=== RUN TestLoadtest_ConcurrentPutSameKeyFromBothModules
|
||||
chattr +i wird in TEST_WORMSTORE_LOCK_DIR nicht durchgesetzt (fehlende Capability oder ungeeignetes Dateisystem), Test uebersprungen
|
||||
--- SKIP
|
||||
```
|
||||
|
||||
**Grund (dieselbe, bereits in RET-11-PRUEFPROTOKOLL.md dokumentierte
|
||||
Infra-Grenze):** 192.168.1.204 ist ein LXC-Proxmox-Container auf
|
||||
ZFS-Root (`df -T /` → `zfs`). `chattr +i` scheitert dort strukturell
|
||||
(`Operation not permitted`) — bestätigt durch eigene Probe in dieser
|
||||
Sitzung (`chattr +i` auf einer Testdatei in `/root` und in
|
||||
`/var/tmp/mai04-wormlock` schlägt beide Male mit `EPERM` fehl, keine
|
||||
nutzbaren Loop-Devices für ein ext4-Image vorhanden,
|
||||
`/dev/loop-control` existiert nicht im Container). `wormstore.Put`
|
||||
verweigert den Schreibvorgang bewusst vollständig (inkl. Entfernen der
|
||||
bereits geschriebenen Datei), wenn die Storage-Object-Lock nicht gesetzt
|
||||
werden kann — fail-closed, kein WORM-Objekt ohne tatsächliche Sperre.
|
||||
Dadurch kann auf diesem Host **kein einziger** `Put`-Aufruf erfolgreich
|
||||
durchlaufen, ob einzeln oder unter Last — dies ist dieselbe Grenze, die
|
||||
bereits alle Put-abhängigen Tests in `wormstore_test.go` betrifft (6
|
||||
bestehende Tests SKIP auf diesem Host, siehe Build/Test-Log unten).
|
||||
|
||||
Der Test `TestLoadtest_ConcurrentPutSameKeyFromBothModules` ist bewusst
|
||||
so geschrieben, dass er NICHT den genauen Fehlertyp des Verlierers
|
||||
erzwingt (weder `ErrAlreadyExists` über den Stat-Check noch ein
|
||||
Betriebssystemfehler beim gleichzeitigen Anlegen derselben `.tmp`-Datei
|
||||
sind ein Fehlschlag), sondern ausschließlich `wins == 1`: Per
|
||||
Code-Analyse ist das auf einem chattr-fähigen Host (ext4/xfs/btrfs)
|
||||
GARANTIERT, weil `os.OpenFile(tmp, O_CREATE|O_EXCL, ...)` auf denselben
|
||||
`.tmp`-Pfad POSIX-atomar ist — unabhängig vom vorgelagerten
|
||||
`os.Stat`-Race kann unter gleichzeitigen `Put`-Aufrufen auf denselben
|
||||
Schlüssel immer nur GENAU EIN Aufruf die temporäre Datei anlegen, alle
|
||||
anderen scheitern sofort. Kein Datenverlust/keine Korruption möglich.
|
||||
|
||||
Ergebnis: **OFFEN (nicht bestätigbar auf 192.168.1.204)** — Tests
|
||||
real ausgeführt, strukturell korrekt, ehrliches SKIP statt
|
||||
fabriziertem PASS. Für eine reale End-to-End-Bestätigung wird ein Host
|
||||
mit `CAP_LINUX_IMMUTABLE`-Wirkung auf chattr-fähigem Dateisystem
|
||||
benötigt (z. B. 192.168.1.131, siehe RET-11-PRUEFPROTOKOLL.md — auch
|
||||
dort SKIP aus demselben Grund; ein noch offener Prüfpunkt, nicht neu
|
||||
durch QA-07 eingeführt).
|
||||
|
||||
## Pflichtprüfung 3: Gleichzeitige Registrierung mehrerer Objekttypen bei RET-05 getestet
|
||||
|
||||
`TestLoadtest_ConcurrentRegistrationAcrossModules`: 30 unterschiedliche
|
||||
Objekttypen (15 `dms-loadtest`, 15 `mail-loadtest`), je Objekttyp 8
|
||||
Racer, alle 240 Aufrufe gleichzeitig gestartet. Danach:
|
||||
|
||||
- 0 Fehler über alle 240 `Register()`-Aufrufe.
|
||||
- `ListRegistrations` liefert exakt 30 Zeilen — keine Race-Duplikate
|
||||
(zwei Racer erzeugen zwei IDs für denselben Objekttyp) und keine
|
||||
Race-Verluste (ein Objekttyp fehlt, weil sein `INSERT` durch
|
||||
`ON CONFLICT DO NOTHING` eines gleichzeitigen Aufrufs "verschluckt"
|
||||
wurde, ohne dass der Nachlese-Zweig die bestehende Zeile fände).
|
||||
- Für jeden der 30 Objekttypen stimmen `retention_class`/`callback_url`
|
||||
nach dem Race mit den bei der ersten Registrierung übergebenen Werten
|
||||
überein (Idempotenz-Eigenschaft von `Register()` bleibt unter Last
|
||||
erhalten).
|
||||
|
||||
Ergebnis: **BESTANDEN**.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
|
||||
1. **Definierte Ziel-Latenz für die Retention-/Legal-Hold-Abfrage unter
|
||||
Last eingehalten**: p95 = 30,3 ms ≤ Ziel 50 ms, Durchsatz 6564,5/s ≥
|
||||
Ziel 3000/s, 0 Fehler über 6000 Anfragen — durch Pflichtprüfung 1
|
||||
belegt. **BESTANDEN**.
|
||||
2. **WORM-Schreibpfad bleibt unter simulierter Last aus zwei gleichzeitig
|
||||
zugreifenden Modulen korrekt und ohne Datenverlust**: Tests
|
||||
implementiert und real ausgeführt, Ergebnis auf diesem Host SKIP aus
|
||||
dokumentierter, vorbestehender Infra-Grenze (kein `CAP_LINUX_IMMUTABLE`
|
||||
auf ZFS/LXC) — durch Pflichtprüfung 2 belegt. Race-Freiheit der
|
||||
Schlüssel-Kollisionslogik zusätzlich durch Code-Analyse (POSIX-Atomarität
|
||||
von `O_EXCL`) nachgewiesen. **OFFEN (Host-Grenze), Logik verifiziert**.
|
||||
3. **Modul-Adapter-Registrierung (RET-05) verkraftet gleichzeitige
|
||||
Registrierung mehrerer Objekttypen ohne Race Condition**: 30
|
||||
Objekttypen, 240 gleichzeitige Aufrufe, exakt 30 Registrierungen,
|
||||
0 Fehler — durch Pflichtprüfung 3 belegt. **BESTANDEN**.
|
||||
|
||||
## Build/Vet/Test — Gesamtmodul (192.168.1.204)
|
||||
|
||||
```
|
||||
cd archive && go build ./... -> OK
|
||||
cd archive && go vet ./... -> OK
|
||||
golangci-lint: auf diesem Host nicht installiert (Projektregel: keine
|
||||
Toolchain-Installation), daher nicht ausgeführt und nicht behauptet
|
||||
cd archive && go test ./... -p 1 -count=1 (TEST_TENANT_DSN, TEST_ADMIN_DSN
|
||||
gesetzt) -> alle Pakete PASS, inkl. neuem internal/loadtest (keine
|
||||
eigenen Tests, nur Hilfspaket)
|
||||
-> in wormstore: 8 Tests SKIP (chattr +i auf diesem ZFS/LXC-Host nicht
|
||||
durchsetzbar, 6 bestehende + 2 neue QA-07-Lasttests), 1 Test PASS
|
||||
(TestStore_OnlyDestroyCanRemoveObjects)
|
||||
```
|
||||
|
||||
Keine Regression in den bestehenden ~45 Paketen des Archive-Moduls.
|
||||
|
||||
## Ergebnis
|
||||
|
||||
QA-07 erfüllt Akzeptanzkriterium 1 und 3 vollständig mit echten,
|
||||
ausgeführten Nachweisen (Messwerte oben). Akzeptanzkriterium 2 (WORM-
|
||||
Schreibpfad) ist strukturell vollständig umgesetzt und real ausgeführt,
|
||||
bleibt aber auf 192.168.1.204 technisch OFFEN — dieselbe, bereits durch
|
||||
RET-11 bekannte und akzeptierte Host-Grenze (kein `chattr +i` auf
|
||||
ZFS/LXC ohne wirksames `CAP_LINUX_IMMUTABLE`), kein durch QA-07 neu
|
||||
eingeführtes Problem. Für die volle Bestätigung von AC2 wird ein
|
||||
Testlauf auf einem Host mit chattr-fähigem Dateisystem (z. B. 131)
|
||||
benötigt.
|
||||
@@ -1,277 +0,0 @@
|
||||
# RET-11 – Nachtrag: Untersuchung `chattr +i` auf Host 204/131 (unprivilegierte LXC-Container)
|
||||
|
||||
Bezug: PR #309 (QA-02), #310 (QA-07), #311 (QA-05) sowie
|
||||
`RET-11-PRUEFPROTOKOLL.md` (Host 131) haben wiederholt denselben Befund
|
||||
dokumentiert: `lockImmutable`/`Put` in
|
||||
`archive/internal/wormstore/wormstore.go` schlägt auf Host 204 und 131
|
||||
mit `EPERM` fehl. Dieser Nachtrag klärt abschließend, ob das ein
|
||||
behebbarer Code-/Konfigurationsfehler ist oder eine echte
|
||||
Infrastrukturgrenze — damit das nicht in jedem weiteren PR erneut
|
||||
untersucht werden muss.
|
||||
|
||||
**Ergebnis vorweg: echte Infrastrukturgrenze, kein Code-Bug. Keine
|
||||
Änderung an `wormstore.go` vorgenommen.** Die bisherige Begründung in
|
||||
`RET-11-PRUEFPROTOKOLL.md` ("ZFS … kein FS_IOC_SETFLAGS-Immutable-
|
||||
Support in dieser Kombination") wird hier präzisiert/korrigiert: Die
|
||||
Ursache ist **nicht ZFS**, sondern dass Host 204/131 **unprivilegierte**
|
||||
LXC-Container sind. Das betrifft jedes Dateisystem darunter (ext4, XFS,
|
||||
Btrfs eingeschlossen), siehe Prüfung 3 unten.
|
||||
|
||||
## Vorgehen
|
||||
|
||||
Frischer Klon auf Host 204 nach `/root/archive-worm-check-1792155880`
|
||||
(Testartefakte nach Abschluss entfernt, keine Produktivdaten
|
||||
berührt — nur synthetische Testdateien wie `probe.txt`).
|
||||
|
||||
## Prüfung 1: Reproduktion des Fehlers
|
||||
|
||||
```
|
||||
$ echo "synthetic-test-content" > probe.txt
|
||||
$ chattr +i probe.txt
|
||||
chattr: Operation not permitted while setting flags on probe.txt
|
||||
$ echo $?
|
||||
1
|
||||
```
|
||||
|
||||
Bestätigt: identischer Fehler wie in PR #309/#310/#311 und
|
||||
`RET-11-PRUEFPROTOKOLL.md` dokumentiert.
|
||||
|
||||
## Prüfung 2: Ist es wirklich ZFS?
|
||||
|
||||
```
|
||||
$ df -T /
|
||||
Filesystem Type
|
||||
rpool/data/subvol-1204-disk-0 zfs
|
||||
$ mount | grep zfs
|
||||
rpool/data/subvol-1204-disk-0 on / type zfs (rw,relatime,xattr,posixacl,casesensitive)
|
||||
rpool/data/subvol-1204-disk-1 on /var/archivdms type zfs (...)
|
||||
```
|
||||
|
||||
Host 204 ist tatsächlich ein LXC-Container mit ZFS-Root
|
||||
(`rpool/data/subvol-1204-disk-0`), wie in den PRs beschrieben.
|
||||
|
||||
## Prüfung 3: Container-Privileg statt Dateisystem als eigentliche Ursache
|
||||
|
||||
```
|
||||
$ cat /proc/self/uid_map
|
||||
0 100000 65536
|
||||
$ cat /proc/self/gid_map
|
||||
0 100000 65536
|
||||
```
|
||||
|
||||
→ Host 204 ist ein **unprivilegierter** Container (UID 0 im Container
|
||||
= UID 100000 auf dem Proxmox-Host, eigener User-Namespace).
|
||||
|
||||
Gegenprobe auf einem NICHT-ZFS-Dateisystem **im selben Container**
|
||||
(tmpfs, `/dev/shm`):
|
||||
|
||||
```
|
||||
$ echo hi > /dev/shm/probe.txt
|
||||
$ chattr +i /dev/shm/probe.txt
|
||||
chattr: Operation not permitted while setting flags on /dev/shm/probe.txt
|
||||
```
|
||||
|
||||
Derselbe `EPERM` — obwohl tmpfs nichts mit ZFS zu tun hat. Das
|
||||
widerlegt die These "ZFS unterstützt kein `FS_IOC_SETFLAGS`": Wäre es
|
||||
ein ZFS-spezifisches Nicht-Unterstützen, müsste tmpfs funktionieren.
|
||||
|
||||
Direkter Test des rohen Kernel-Ioctls (umgeht `chattr`-Binary und jede
|
||||
Fehlermeldungs-Umdeutung durch das Tool):
|
||||
|
||||
```python
|
||||
FS_IOC_SETFLAGS = 0x40086602
|
||||
FS_IMMUTABLE_FL = 0x00000010
|
||||
fcntl.ioctl(fd, FS_IOC_SETFLAGS, struct.pack("i", FS_IMMUTABLE_FL))
|
||||
# -> OSError errno=1 (EPERM)
|
||||
```
|
||||
|
||||
`capsh --print` zeigt `cap_linux_immutable` im Bounding/Effective-Set
|
||||
des Containers — das ist aber irrelevant für diesen Check: Die
|
||||
Kernel-Prüfung für das Setzen/Löschen des Immutable-Flags
|
||||
(`vfs_ioc_setflags_prepare` / fs-spezifische `*_ioctl_setflags`, z. B.
|
||||
`ext4_ioctl_setflags`) ruft `capable(CAP_LINUX_IMMUTABLE)` auf — das ist
|
||||
die KLASSISCHE, NICHT namensraum-bewusste Prüfung (äquivalent zu
|
||||
`ns_capable(&init_user_ns, …)`), sie prüft also IMMER gegen den
|
||||
initialen (Host-)User-Namespace, unabhängig davon, was der Container in
|
||||
seinem EIGENEN Namespace an Fähigkeiten zu haben glaubt.
|
||||
|
||||
Das ist laut Kernel-Mailingliste (2014) eine **bewusste
|
||||
Sicherheitsentscheidung**, kein Versehen: Ein Patch, der genau diese
|
||||
Prüfung namensraum-bewusst machen wollte (`ns_capable(current_user_ns(),
|
||||
CAP_LINUX_IMMUTABLE)`), wurde von Andy Lutomirski explizit abgelehnt,
|
||||
mit der Begründung, dass Prozesse sonst durch Erzeugen eines eigenen
|
||||
User-Namespace das Immutable-Bit manipulieren könnten, was als
|
||||
Sicherheitsrisiko eingestuft wurde.
|
||||
Quelle: https://lists.linuxfoundation.org/pipermail/containers/2014-April/034973.html
|
||||
|
||||
**Konsequenz:** Kein Code innerhalb des Containers — unabhängig von
|
||||
Sprache, Implementierung oder gewähltem Dateisystem — kann
|
||||
`CAP_LINUX_IMMUTABLE` im Host-Namespace erlangen. Das ist strukturell
|
||||
unmöglich, solange der Container unprivilegiert bleibt. Das betrifft
|
||||
nicht nur ZFS, sondern auch ext4/XFS/Btrfs, sobald sie unter einem
|
||||
unprivilegierten Container gemountet sind.
|
||||
|
||||
**Korrektur an `RET-11-PRUEFPROTOKOLL.md`:** Die dortige
|
||||
Handlungsempfehlung ("WORM-Basisverzeichnis MUSS auf ext2/3/4, XFS oder
|
||||
Btrfs liegen, NICHT auf ZFS") ist unvollständig/irreführend — das
|
||||
Dateisystem ist nicht der limitierende Faktor. Richtig ist: Das
|
||||
WORM-Basisverzeichnis muss auf einem Host/Container liegen, der dem
|
||||
Prozess REALE (nicht nur namensraum-gemappte) Root-Rechte gibt
|
||||
(privilegierter Container, VM oder Bare-Metal) — das Dateisystem
|
||||
darunter ist dabei zweitrangig, sofern es `chattr`/Ext2-Flags
|
||||
grundsätzlich unterstützt (ext4/XFS/Btrfs tun das; ob modernes ZFS das
|
||||
ebenfalls täte, ließ sich auf einem privilegierten Host nicht
|
||||
verifizieren, ist aber plausibel, siehe TrueNAS-SCALE-Hinweise unten —
|
||||
irrelevant, weil auf einem privilegierten Host ohnehin auch ZFS in
|
||||
Frage käme, solange OpenZFS das Flag unterstützt).
|
||||
|
||||
## Geprüfte Alternativen (alle unzureichend oder im Container nicht verfügbar)
|
||||
|
||||
| # | Alternative | Befund |
|
||||
|---|---|---|
|
||||
| 1 | `zfs set readonly=on` (Dataset-Ebene) | `zfs`-CLI im Container **nicht vorhanden** (`which zfs` → leer, ZFS-Verwaltung ist beim unprivilegierten LXC-Container nicht delegiert). Selbst wenn verfügbar: Dataset-weit, nicht pro-Objekt — würde auch neue `Put`-Schreibvorgänge blockieren. Wer die Berechtigung hat, es zu setzen, hat auch die, es zurückzusetzen — dieselbe strukturelle Schwäche wie chmod/ACL (siehe unten). Infrastrukturoperation auf Proxmox-Host-Ebene, nicht im Container lösbar. |
|
||||
| 2 | ZFS-Snapshots / `zfs hold` | Nur Nachweis-/Erkennungsmechanismus (Snapshot zeigt nachträglich, dass sich etwas geändert hat), verhindert aber NICHT das Schreiben/Löschen der aktiven Datei selbst — erfüllt nicht die Kernanforderung "Verhinderung", nur "Erkennung". `zfs`-CLI ohnehin nicht verfügbar. |
|
||||
| 3 | POSIX-ACLs / Verzeichnis-Schreibschutz (wie in QA-02 als Ersatznachweis erprobt) | Strukturell geprüft per Bind-Mount-Readonly-Test: `mount -o remount,bind,ro` verhindert Schreiben, aber derselbe Account kann sofort `mount -o remount,bind,rw` erneut ausführen und weiterschreiben — **kein Schutz gegen denselben (ggf. kompromittierten) Service-Account**, nur gegen andere Accounts. Das ist dieselbe Einschränkung, die der Code-Kommentar in `wormstore.go` (Zeilen 5-15) bereits für `chmod 0400` korrekt benennt: Löschrecht hängt vom Verzeichnis ab, nicht von der Datei, und der schreibende Account braucht zwingend Verzeichnis-Schreibrecht, um neue Objekte abzulegen — er kann sich damit jederzeit selbst wieder Rechte einräumen. **Bestätigt: taugt nur als Ersatznachweis/Fallback, nicht als vollwertiger Ersatz für echte Storage-Object-Lock.** |
|
||||
| 4 | Proxmox-Container-Feature (`features: mknod=1` o.ä.) damit `chattr +i` im Container greift | Aus dem Container heraus nicht konfigurierbar (Proxmox-Host-Ebene, kein Zugriff in diesem Auftrag). Fachlich ohnehin wirkungslos: `mknod=1` betrifft `CAP_MKNOD`, nicht `CAP_LINUX_IMMUTABLE`/User-Namespace-Mapping. Einzige wirksame Proxmox-seitige Abhilfe wäre, den Container als PRIVILEGIERT zu betreiben (`unprivileged: 0`) — das hebt die Isolation durch User-Namespace-Mapping komplett auf und ist eine bewusste Sicherheits-Tradeoff-Entscheidung auf Infrastruktur-Ebene, keine Code-Lösung. |
|
||||
| 5 | Datei-Capability (`setcap cap_linux_immutable+ep <helper>`) auf einen Helper-Prozess innerhalb des Containers | Datei-Capabilities wirken nur innerhalb des EIGENEN User-Namespace des Containers — sie können keine Capability im übergeordneten (Host-)Namespace verleihen, gegen den die Kernel-Prüfung tatsächlich läuft. Kein Workaround möglich. |
|
||||
| 6 | Verschachtelter User-Namespace (`unshare -U`) um "Eigentümer" des Dateisystems zu werden | Wirkt nicht: Das zugrunde liegende Superblock-Objekt (ZFS-Dataset, tmpfs-Mount) gehört dem HOST-User-Namespace (Ahn-Namespace), nicht dem Container. Verschachtelung erzeugt nur weitere Nachfahren-Namespaces, keiner davon wird dadurch zum Eigentümer eines bereits bestehenden, von außen gemounteten Dateisystems. |
|
||||
| 7 | FUSE-basiertes eigenes WORM-Dateisystem (Durchsetzung rein in Userspace, ganz ohne `chattr`) | Technisch der einzige denkbare Weg, eine Immutable-Garantie komplett ohne `CAP_LINUX_IMMUTABLE` umzusetzen. Aber: `/dev/fuse` ist in diesem Container **nicht vorhanden** (`ls /dev/fuse` → "No such file or directory") — FUSE-Mounts sind nicht an den Container durchgereicht. Erfordert Proxmox-Host-Konfiguration (Device-Passthrough), nicht im Container lösbar. Selbst wenn verfügbar: kein "minimaler Fix in `wormstore.go`" mehr, sondern ein komplett neuer Dienst/eigenes Dateisystem — als mögliche ZUKÜNFTIGE Architekturoption vermerkt, nicht Teil dieses Nachtrags. |
|
||||
| 8 | Externes echtes Object-Lock-Backend (z. B. MinIO/S3 mit aktiviertem Object Lock Compliance-Mode) statt lokalem Dateisystem | Einzige Option, die eine zu S3 Object Lock GLEICHWERTIGE Garantie ohne Abhängigkeit von Host-Kernel-Capabilities liefern würde (die Durchsetzung läge dann beim Storage-Backend-Prozess, nicht beim Kernel-Dateisystem-Flag des Containers). Das ist aber ein Architekturwechsel (neuer Storage-Treiber statt `wormstore`-Dateisystem-Pfad), kein Fix an `wormstore.go` — außerhalb des Scopes dieses Nachtrags, als Hinweis für eine mögliche künftige Kachel vermerkt. |
|
||||
|
||||
## Prüfung 4: `ImmutableLockSupported` als bestehende Absicherung
|
||||
|
||||
Der Code verfügt bereits über exakt den richtigen Schutzmechanismus für
|
||||
genau diese Situation: `ImmutableLockSupported(dir)`
|
||||
(`wormstore.go:237-251`) prüft aktiv, ob das Basisverzeichnis
|
||||
`chattr +i` durchsetzt, und `Put` schlägt bei fehlgeschlagenem
|
||||
`lockImmutable` fail-closed fehl (Datei wird wieder entfernt, kein
|
||||
WORM-Objekt ohne echte Sperre). Das ist bereits das korrekte Verhalten
|
||||
für eine Infrastrukturgrenze: lieber ehrlich ablehnen/überspringen, als
|
||||
eine WORM-Garantie vorzutäuschen, die nicht existiert. Hier besteht
|
||||
kein Nachbesserungsbedarf.
|
||||
|
||||
## Fazit
|
||||
|
||||
Die wiederholt in PR #309/#310/#311 dokumentierte `EPERM`-Meldung ist
|
||||
**keine behebbare Code- oder Konfigurationslücke**, sondern eine vom
|
||||
Linux-Kernel bewusst vorgesehene Sicherheitsgrenze: Ein unprivilegierter
|
||||
Container kann das Immutable-Flag nicht setzen, unabhängig vom
|
||||
darunterliegenden Dateisystem. Das wurde durch direkte Reproduktion
|
||||
(`chattr`, roher Ioctl-Aufruf), Gegenprobe auf einer anderen
|
||||
Dateisystemart (tmpfs) im selben Container und eine bestätigte
|
||||
Kernel-Design-Entscheidung (2014, LKML) zweifelsfrei nachgewiesen.
|
||||
Alle acht geprüften Alternativen sind entweder im Container-Scope
|
||||
technisch nicht verfügbar (ZFS-CLI, FUSE), strukturell keine
|
||||
vollwertige Entsprechung (ACL/chmod/Dataset-readonly sind vom selben
|
||||
Account umkehrbar), oder erfordern eine Infrastruktur-/Architektur-
|
||||
entscheidung außerhalb des Container-Scopes (privilegierter Container,
|
||||
externes Object-Lock-Backend).
|
||||
|
||||
**Keine Änderung an `wormstore.go` vorgenommen** — der bestehende
|
||||
Fail-Closed-Mechanismus (`ImmutableLockSupported`, `Put` schlägt
|
||||
komplett fehl statt eine Pseudo-Sperre vorzutäuschen) ist bereits die
|
||||
richtige Reaktion auf diese Infrastrukturgrenze. Für einen echten
|
||||
End-to-End-Nachweis von RET-11 AC1/AC2 wird weiterhin ein Testlauf auf
|
||||
einem PRIVILEGIERTEN Host/Container benötigt (Dateisystem darunter ist
|
||||
dabei zweitrangig) — oder ein künftiger Architekturwechsel auf ein
|
||||
externes Object-Lock-fähiges Storage-Backend (siehe Alternative 8).
|
||||
Dieser Nachtrag gilt als abschließende Untersuchung; eine erneute
|
||||
Prüfung derselben Frage in künftigen QA-Runden ist nicht nötig, sofern
|
||||
sich die Host-Konfiguration (privilegiert/unprivilegiert) nicht ändert.
|
||||
|
||||
---
|
||||
|
||||
## RET-15 Nachtrag: Host-Suche und Ergebnis
|
||||
|
||||
Datum: 2026-10-16
|
||||
|
||||
Bezug: RET-15 (Folgeticket aus dieser Untersuchung) verlangt einen
|
||||
echten End-zu-Ende-Nachweis auf einem tatsächlich `chattr +i`-fähigen
|
||||
Host, statt eine erneute Grundsatzuntersuchung der oben bereits
|
||||
geprüften und verworfenen Alternativen. Dieser Abschnitt dokumentiert
|
||||
ausschließlich die Suche nach einem solchen Host und deren Ergebnis.
|
||||
|
||||
### Vorgehen
|
||||
|
||||
1. Repoweite Suche nach allen im Projektkontext dokumentierten Hosts:
|
||||
`grep -rhoE "192\.168\.1\.[0-9]+" --include="*.md"` über den
|
||||
gesamten frischen Checkout liefert genau drei IPs: `192.168.1.131`,
|
||||
`192.168.1.204` (beide bereits oben als unprivilegierte LXC-
|
||||
Container auf ZFS-Root identifiziert) und `192.168.1.236`
|
||||
(referenziert in `android/dms-capture/docs/INT-21-PRUEFPROTOKOLL.md`
|
||||
als Android-SDK-Build-Host). Kein weiterer Host ist in der
|
||||
Projektdokumentation (`docs/`, `DEVLOG.md`, Kanban-Boards,
|
||||
Prüfprotokolle) als erreichbar oder privilegiert vermerkt.
|
||||
2. Host 236 war über SSH erreichbar (`root@192.168.1.236`). Vor dem
|
||||
eigentlichen `chattr`-Test wurde der Container-Typ geprüft:
|
||||
|
||||
```
|
||||
$ systemd-detect-virt
|
||||
lxc
|
||||
$ cat /proc/self/uid_map
|
||||
0 100000 65536
|
||||
$ df -T /
|
||||
rpool/data/subvol-1236-disk-0 zfs ... /
|
||||
```
|
||||
|
||||
Identisches Bild wie bei Host 204/131: UID 0 im Container ist auf
|
||||
UID 100000 im Proxmox-Host gemappt (unprivilegierter Container,
|
||||
ZFS-Root). `capsh --print` zeigt `cap_linux_immutable` zwar im
|
||||
Bounding-Set, was laut der oben belegten Kernel-Prüfung
|
||||
(`capable(CAP_LINUX_IMMUTABLE)` gegen den initialen User-Namespace,
|
||||
nicht namensraum-bewusst) für sich genommen nichts aussagt.
|
||||
3. Realer Test trotzdem durchgeführt (synthetische Testdatei, keine
|
||||
Produktivdaten):
|
||||
|
||||
```
|
||||
$ echo "synthetic-test-content-ret15" > /tmp/ret15_probe.txt
|
||||
$ chattr +i /tmp/ret15_probe.txt
|
||||
chattr: Operation not permitted while setting flags on ret15_probe.txt
|
||||
$ echo $?
|
||||
1
|
||||
```
|
||||
|
||||
Testdatei anschließend entfernt (`rm -f /tmp/ret15_probe.txt`).
|
||||
|
||||
### Ergebnis
|
||||
|
||||
Host 236 ist, wie 204 und 131, ein unprivilegierter LXC-Container und
|
||||
zeigt denselben `EPERM`-Fehlschlag. Er ist damit **kein** geeigneter
|
||||
Host für den in RET-15 AC1/AC2 geforderten Nachweis. Im gesamten
|
||||
projektbekannten, erreichbaren Infrastruktur-Bestand (131, 204, 236)
|
||||
gibt es keinen Host mit echten, nicht nur namensraum-gemappten
|
||||
Root-Rechten.
|
||||
|
||||
Eine Ausweitung der Suche auf den darunterliegenden Proxmox-Hypervisor
|
||||
selbst oder auf weitere, im Projekt nicht dokumentierte Hosts wurde
|
||||
NICHT vorgenommen — das wäre keine "bekannte, projektkontextbezogene"
|
||||
Umgebung mehr, sondern eine Grundsatz-Infrastruktur-Recherche außerhalb
|
||||
des RET-15-Scopes (siehe "Nicht Bestandteil" im Ticket).
|
||||
|
||||
**AC1/AC2 bleiben damit offen, wie bereits im ursprünglichen Nachtrag
|
||||
festgehalten.** Das ist nach den 8 bereits geprüften Alternativen und
|
||||
dieser zusätzlichen, ergebnislosen Host-Suche ein ehrliches, nicht
|
||||
weiter durch Workarounds umgehbares Ergebnis — keine Lücke in der
|
||||
Untersuchung, sondern eine reale Grenze der aktuell verfügbaren
|
||||
Infrastruktur.
|
||||
|
||||
**Bedingung, die den Nachweis ermöglichen würde** (unverändert
|
||||
gegenüber der Einschätzung oben, hier noch einmal explizit als Antwort
|
||||
auf RET-15 Prüfung 2 festgehalten):
|
||||
|
||||
- Ein tatsächlich privilegierter Produktions-Host/Container
|
||||
(`unprivileged: 0` in der Proxmox-Konfiguration, oder eine VM/
|
||||
Bare-Metal-Maschine) mit `chattr`-fähigem Dateisystem (ext4, XFS,
|
||||
Btrfs; ZFS plausibel, aber auf keinem der verfügbaren Hosts
|
||||
verifizierbar) — dann liefe derselbe bereits implementierte und
|
||||
fail-closed abgesicherte Code (`wormstore.Put`/`ImmutableLockSupported`)
|
||||
real durch, ohne jede Codeänderung.
|
||||
- Ersatzweise ein Architekturwechsel auf ein echtes S3/MinIO-Backend
|
||||
mit aktiviertem Object-Lock Compliance-Mode (bereits als Alternative 8
|
||||
oben vermerkt) — das verlagert die Durchsetzung vom Kernel-Dateisystem-
|
||||
Flag auf den Storage-Backend-Prozess und wäre damit unabhängig von der
|
||||
Privilegstufe des Containers, in dem NEXARCH läuft.
|
||||
|
||||
Keine Änderung an `wormstore.go` oder an anderem Produktivcode. Kein
|
||||
neues Paralleldokument — dieser Abschnitt ergänzt ausschließlich den
|
||||
bestehenden Nachtrag.
|
||||
@@ -13,7 +13,3 @@ require (
|
||||
golang.org/x/sync v0.22.0 // indirect
|
||||
golang.org/x/text v0.41.0 // indirect
|
||||
)
|
||||
|
||||
require gitea.perlbach24.de/scripte/nexarch/common v0.0.0
|
||||
|
||||
replace gitea.perlbach24.de/scripte/nexarch/common => ../common
|
||||
File renamed without changes.
File renamed without changes.
@@ -33,7 +33,7 @@ func moduleRoot(t *testing.T) string {
|
||||
// Antwort bzw. der rohe ListenAndServe-Aufruf genau die erlaubte
|
||||
// Implementierung der Regel selbst ist (API-20/API-21), kein Verstoss.
|
||||
// Das Archive-Modul hat keine weiteren, physisch verschachtelten Go-Module.
|
||||
var exempt = []string{"internal/httpharden"}
|
||||
var exempt = []string{"internal/apierror", "internal/httpharden"}
|
||||
|
||||
// TestNoErrorTextLeaksIntoHTTPResponses ist Akzeptanzkriterium 1: kein
|
||||
// err.Error() direkt in einer HTTP-Antwort, ausser ueber apierror.
|
||||
|
||||
@@ -0,0 +1,70 @@
|
||||
// Package auditclient ist ein schlanker HTTP-Client für Core AUD-08
|
||||
// (internal/audit, POST /audit/ingest). Archive ist ein physisch
|
||||
// getrenntes Go-Modul und kann Cores internal/audit daher nicht direkt
|
||||
// importieren — nur über dessen HTTP-Schnittstelle. Gleiches Muster wie
|
||||
// archive/internal/notifyclient (CFG-05).
|
||||
package auditclient
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"context"
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/httpclient"
|
||||
"net/http"
|
||||
)
|
||||
|
||||
type Client struct {
|
||||
BaseURL string
|
||||
ServiceToken string
|
||||
HTTPClient *http.Client
|
||||
}
|
||||
|
||||
func New(baseURL, serviceToken string) *Client {
|
||||
return &Client{BaseURL: baseURL, ServiceToken: serviceToken, HTTPClient: httpclient.Default()}
|
||||
}
|
||||
|
||||
type ingestRequest struct {
|
||||
TenantSlug string `json:"tenant_slug"`
|
||||
Actor string `json:"actor"`
|
||||
Action string `json:"action"`
|
||||
Target string `json:"target"`
|
||||
Metadata map[string]any `json:"metadata"`
|
||||
}
|
||||
|
||||
// Ingest meldet EIN Audit-Ereignis an Core. Jeder Fehler (Transport,
|
||||
// Timeout, unerwarteter Status) wird als Fehler zurückgegeben — der
|
||||
// Aufrufer entscheidet, ob/wie er das nachbehandelt (siehe
|
||||
// archive/internal/audittrail für den outage-toleranten Wrapper).
|
||||
func (c *Client) Ingest(ctx context.Context, tenantSlug, actor, action, target string, metadata map[string]any) error {
|
||||
body, err := json.Marshal(ingestRequest{
|
||||
TenantSlug: tenantSlug, Actor: actor, Action: action, Target: target, Metadata: metadata,
|
||||
})
|
||||
if err != nil {
|
||||
return fmt.Errorf("auditclient: request kodieren: %w", err)
|
||||
}
|
||||
req, err := http.NewRequestWithContext(ctx, http.MethodPost, c.BaseURL+"/audit/ingest", bytes.NewReader(body))
|
||||
if err != nil {
|
||||
return fmt.Errorf("auditclient: request bauen: %w", err)
|
||||
}
|
||||
req.Header.Set("Content-Type", "application/json")
|
||||
req.Header.Set("X-Service-Token", c.ServiceToken)
|
||||
|
||||
resp, err := c.httpClient().Do(req)
|
||||
if err != nil {
|
||||
return fmt.Errorf("auditclient: aufruf fehlgeschlagen: %w", err)
|
||||
}
|
||||
defer func() { _ = resp.Body.Close() }()
|
||||
|
||||
if resp.StatusCode != http.StatusAccepted {
|
||||
return fmt.Errorf("auditclient: unerwarteter status %d", resp.StatusCode)
|
||||
}
|
||||
return nil
|
||||
}
|
||||
|
||||
func (c *Client) httpClient() *http.Client {
|
||||
if c.HTTPClient != nil {
|
||||
return c.HTTPClient
|
||||
}
|
||||
return httpclient.Default()
|
||||
}
|
||||
@@ -20,7 +20,7 @@ import (
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/auditclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/auditclient"
|
||||
)
|
||||
|
||||
type Recorder struct {
|
||||
|
||||
@@ -11,7 +11,7 @@ import (
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/auditclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/auditclient"
|
||||
)
|
||||
|
||||
func setupOutboxTest(t *testing.T) *pgxpool.Pool {
|
||||
|
||||
@@ -32,12 +32,7 @@ func GenerateDEK() ([]byte, error) {
|
||||
return dek, nil
|
||||
}
|
||||
|
||||
// seal/open binden aad (F-21) an den Chiffretext, damit ein Austausch
|
||||
// verpackter Werte zwischen zwei Kontexten beim Entschluesseln auffaellt
|
||||
// statt still zu funktionieren. open versucht bei gesetztem aad zuerst mit
|
||||
// aad, dann (Ruecklaufkompatibilitaet fuer vor dieser Aenderung versiegelte
|
||||
// Daten ohne AAD) ohne aad.
|
||||
func seal(key, plaintext, aad []byte) ([]byte, error) {
|
||||
func seal(key, plaintext []byte) ([]byte, error) {
|
||||
block, err := aes.NewCipher(key)
|
||||
if err != nil {
|
||||
return nil, fmt.Errorf("backupcrypto: aes-cipher erstellen: %w", err)
|
||||
@@ -50,10 +45,10 @@ func seal(key, plaintext, aad []byte) ([]byte, error) {
|
||||
if _, err := rand.Read(nonce); err != nil {
|
||||
return nil, fmt.Errorf("backupcrypto: nonce erzeugen: %w", err)
|
||||
}
|
||||
return gcm.Seal(nonce, nonce, plaintext, aad), nil
|
||||
return gcm.Seal(nonce, nonce, plaintext, nil), nil
|
||||
}
|
||||
|
||||
func open(key, sealed, aad []byte) ([]byte, error) {
|
||||
func open(key, sealed []byte) ([]byte, error) {
|
||||
block, err := aes.NewCipher(key)
|
||||
if err != nil {
|
||||
return nil, fmt.Errorf("backupcrypto: aes-cipher erstellen: %w", err)
|
||||
@@ -66,25 +61,21 @@ func open(key, sealed, aad []byte) ([]byte, error) {
|
||||
return nil, ErrDecryptFailed
|
||||
}
|
||||
nonce, ciphertext := sealed[:gcm.NonceSize()], sealed[gcm.NonceSize():]
|
||||
if plaintext, err := gcm.Open(nil, nonce, ciphertext, aad); err == nil {
|
||||
return plaintext, nil
|
||||
plaintext, err := gcm.Open(nil, nonce, ciphertext, nil)
|
||||
if err != nil {
|
||||
return nil, ErrDecryptFailed
|
||||
}
|
||||
if len(aad) > 0 {
|
||||
if plaintext, err := gcm.Open(nil, nonce, ciphertext, nil); err == nil {
|
||||
return plaintext, nil
|
||||
}
|
||||
}
|
||||
return nil, ErrDecryptFailed
|
||||
return plaintext, nil
|
||||
}
|
||||
|
||||
func WrapDEK(kek, dek, aad []byte) ([]byte, error) {
|
||||
wrapped, err := seal(kek, dek, aad)
|
||||
func WrapDEK(kek, dek []byte) ([]byte, error) {
|
||||
wrapped, err := seal(kek, dek)
|
||||
if err != nil {
|
||||
return nil, fmt.Errorf("backupcrypto: dek verpacken: %w", err)
|
||||
}
|
||||
return wrapped, nil
|
||||
}
|
||||
|
||||
func UnwrapDEK(kek, wrappedDEK, aad []byte) ([]byte, error) {
|
||||
return open(kek, wrappedDEK, aad)
|
||||
func UnwrapDEK(kek, wrappedDEK []byte) ([]byte, error) {
|
||||
return open(kek, wrappedDEK)
|
||||
}
|
||||
@@ -1,70 +0,0 @@
|
||||
package backupcrypto
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"errors"
|
||||
"testing"
|
||||
)
|
||||
|
||||
// TestWrapDEK_AADBindsContext ist F-21 Pruefung 1: ein Austausch zwischen
|
||||
// zwei Kontexten (Mandanten) faellt beim Entschluesseln auf.
|
||||
func TestWrapDEK_AADBindsContext(t *testing.T) {
|
||||
kek := bytes.Repeat([]byte{0x01}, KEKSize)
|
||||
dek, err := GenerateDEK()
|
||||
if err != nil {
|
||||
t.Fatalf("generatedek: %v", err)
|
||||
}
|
||||
wrapped, err := WrapDEK(kek, dek, []byte("tenant-a"))
|
||||
if err != nil {
|
||||
t.Fatalf("wrapdek: %v", err)
|
||||
}
|
||||
if _, err := UnwrapDEK(kek, wrapped, []byte("tenant-b")); !errors.Is(err, ErrDecryptFailed) {
|
||||
t.Fatal("unwrapdek mit falschem aad haette fehlschlagen muessen")
|
||||
}
|
||||
if _, err := UnwrapDEK(kek, wrapped, []byte("tenant-a")); err != nil {
|
||||
t.Fatalf("unwrapdek mit korrektem aad: %v", err)
|
||||
}
|
||||
}
|
||||
|
||||
// TestUnwrapDEK_LegacyWithoutAADStillReadable ist F-21 Pruefung 2:
|
||||
// Ruecklaufkompatibilitaet fuer vor dieser Aenderung ohne AAD versiegelte
|
||||
// Datensaetze.
|
||||
func TestUnwrapDEK_LegacyWithoutAADStillReadable(t *testing.T) {
|
||||
kek := bytes.Repeat([]byte{0x02}, KEKSize)
|
||||
dek, err := GenerateDEK()
|
||||
if err != nil {
|
||||
t.Fatalf("generatedek: %v", err)
|
||||
}
|
||||
legacyWrapped, err := WrapDEK(kek, dek, nil)
|
||||
if err != nil {
|
||||
t.Fatalf("wrapdek (legacy): %v", err)
|
||||
}
|
||||
unwrapped, err := UnwrapDEK(kek, legacyWrapped, []byte("tenant-a"))
|
||||
if err != nil {
|
||||
t.Fatalf("legacy-datensatz muss lesbar bleiben: %v", err)
|
||||
}
|
||||
if !bytes.Equal(unwrapped, dek) {
|
||||
t.Fatal("legacy-datensatz lieferte falschen dek")
|
||||
}
|
||||
}
|
||||
|
||||
// TestWrapUnwrapDEK_RoundTrip ist Pruefung 3: bestehendes
|
||||
// Verschluesselungsverhalten bleibt unveraendert (keine Regression).
|
||||
func TestWrapUnwrapDEK_RoundTrip(t *testing.T) {
|
||||
kek := bytes.Repeat([]byte{0x03}, KEKSize)
|
||||
dek, err := GenerateDEK()
|
||||
if err != nil {
|
||||
t.Fatalf("generatedek: %v", err)
|
||||
}
|
||||
wrapped, err := WrapDEK(kek, dek, []byte("tenant-a"))
|
||||
if err != nil {
|
||||
t.Fatalf("wrapdek: %v", err)
|
||||
}
|
||||
unwrapped, err := UnwrapDEK(kek, wrapped, []byte("tenant-a"))
|
||||
if err != nil {
|
||||
t.Fatalf("unwrapdek: %v", err)
|
||||
}
|
||||
if !bytes.Equal(unwrapped, dek) {
|
||||
t.Fatal("entpackter dek stimmt nicht mit original ueberein")
|
||||
}
|
||||
}
|
||||
@@ -34,7 +34,7 @@ func EncryptFile(ctx context.Context, provider kekclient.Provider, tenantSlug, s
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
ciphertext, err := seal(dek, plaintext, []byte(tenantSlug))
|
||||
ciphertext, err := seal(dek, plaintext)
|
||||
if err != nil {
|
||||
return fmt.Errorf("backupcrypto: %q verschluesseln: %w", srcPath, err)
|
||||
}
|
||||
@@ -42,7 +42,7 @@ func EncryptFile(ctx context.Context, provider kekclient.Provider, tenantSlug, s
|
||||
if err != nil {
|
||||
return fmt.Errorf("backupcrypto: tenant-kek fuer %q beziehen: %w", tenantSlug, err)
|
||||
}
|
||||
wrappedDEK, err := WrapDEK(tenantKEK, dek, []byte(tenantSlug))
|
||||
wrappedDEK, err := WrapDEK(tenantKEK, dek)
|
||||
if err != nil {
|
||||
return fmt.Errorf("backupcrypto: dek fuer %q verpacken: %w", tenantSlug, err)
|
||||
}
|
||||
@@ -88,11 +88,11 @@ func DecryptFile(ctx context.Context, provider kekclient.Provider, tenantSlug, s
|
||||
if err != nil {
|
||||
return fmt.Errorf("backupcrypto: tenant-kek fuer %q beziehen: %w", tenantSlug, err)
|
||||
}
|
||||
dek, err := UnwrapDEK(tenantKEK, wrappedDEK, []byte(tenantSlug))
|
||||
dek, err := UnwrapDEK(tenantKEK, wrappedDEK)
|
||||
if err != nil {
|
||||
return fmt.Errorf("backupcrypto: dek entpacken (falscher tenant-kek?): %w", err)
|
||||
}
|
||||
plaintext, err := open(dek, ciphertext, []byte(tenantSlug))
|
||||
plaintext, err := open(dek, ciphertext)
|
||||
if err != nil {
|
||||
return fmt.Errorf("backupcrypto: %q entschluesseln: %w", srcPath, err)
|
||||
}
|
||||
|
||||
@@ -34,7 +34,7 @@ func RepoPassword(ctx context.Context, provider kekclient.Provider, tenantSlug,
|
||||
if err != nil {
|
||||
return "", fmt.Errorf("backupcrypto: tenant-kek fuer %q beziehen: %w", tenantSlug, err)
|
||||
}
|
||||
dek, err := UnwrapDEK(tenantKEK, wrappedDEK, []byte(tenantSlug))
|
||||
dek, err := UnwrapDEK(tenantKEK, wrappedDEK)
|
||||
if err != nil {
|
||||
return "", fmt.Errorf("backupcrypto: repo-dek entpacken (falscher tenant-kek?): %w", err)
|
||||
}
|
||||
@@ -52,7 +52,7 @@ func RepoPassword(ctx context.Context, provider kekclient.Provider, tenantSlug,
|
||||
if err != nil {
|
||||
return "", fmt.Errorf("backupcrypto: tenant-kek fuer %q beziehen: %w", tenantSlug, err)
|
||||
}
|
||||
wrappedDEK, err := WrapDEK(tenantKEK, dek, []byte(tenantSlug))
|
||||
wrappedDEK, err := WrapDEK(tenantKEK, dek)
|
||||
if err != nil {
|
||||
return "", fmt.Errorf("backupcrypto: repo-dek fuer %q verpacken: %w", tenantSlug, err)
|
||||
}
|
||||
|
||||
@@ -219,56 +219,3 @@ func TestConfirmAndExecute_ExpiredTokenRejected(t *testing.T) {
|
||||
t.Fatalf("erwartet ErrInvalidToken bei abgelaufenem token, habe: %v", err)
|
||||
}
|
||||
}
|
||||
|
||||
// QA-03 Akzeptanzkriterium 2 + Pflichtpruefung 2: Vier-Augen-Freigabe wird
|
||||
// erneut mit zwei unabhaengigen Testrollen nachgewiesen (Anforderung durch
|
||||
// Testrolle A, Freigabe durch unabhaengige Testrolle B), und der
|
||||
// Loeschversuch durch dieselbe Testrolle ohne zweite Bestaetigung
|
||||
// scheitert erneut.
|
||||
func TestConfirmAndExecute_QA03_TwoIndependentTestRoles(t *testing.T) {
|
||||
const testrolleA = "testrolle_sachbearbeiterin_a@qa03.example"
|
||||
const testrolleB = "testrolle_pruefer_b@qa03.example"
|
||||
|
||||
pool := setupTest(t)
|
||||
ctx := context.Background()
|
||||
|
||||
objID := insertExpiredObject(t, ctx, pool, "qa03-cross-role-doc")
|
||||
token, err := RequestDeletion(ctx, pool, objID, testrolleA)
|
||||
if err != nil {
|
||||
t.Fatalf("requestdeletion (testrolle a): %v", err)
|
||||
}
|
||||
var reqID string
|
||||
if err := pool.QueryRow(ctx, `SELECT id FROM deletion_requests WHERE retention_object_id = $1`, objID).Scan(&reqID); err != nil {
|
||||
t.Fatal(err)
|
||||
}
|
||||
if err := ConfirmAndExecute(ctx, pool, reqID, token, testrolleB); err != nil {
|
||||
t.Fatalf("erwartet erfolgreiche freigabe durch unabhaengige testrolle b, habe: %v", err)
|
||||
}
|
||||
var status string
|
||||
if err := pool.QueryRow(ctx, `SELECT status FROM retention_objects WHERE id = $1`, objID).Scan(&status); err != nil {
|
||||
t.Fatal(err)
|
||||
}
|
||||
if status != "deleted" {
|
||||
t.Fatalf("erwartet status deleted nach freigabe durch testrolle b, habe %q", status)
|
||||
}
|
||||
|
||||
objID2 := insertExpiredObject(t, ctx, pool, "qa03-same-role-doc")
|
||||
token2, err := RequestDeletion(ctx, pool, objID2, testrolleA)
|
||||
if err != nil {
|
||||
t.Fatalf("requestdeletion (gleiche testrolle): %v", err)
|
||||
}
|
||||
var reqID2 string
|
||||
if err := pool.QueryRow(ctx, `SELECT id FROM deletion_requests WHERE retention_object_id = $1`, objID2).Scan(&reqID2); err != nil {
|
||||
t.Fatal(err)
|
||||
}
|
||||
err = ConfirmAndExecute(ctx, pool, reqID2, token2, testrolleA)
|
||||
if !errors.Is(err, ErrSamePerson) {
|
||||
t.Fatalf("erwartet ErrSamePerson bei gleicher testrolle ohne zweite bestaetigung, habe: %v", err)
|
||||
}
|
||||
if err := pool.QueryRow(ctx, `SELECT status FROM retention_objects WHERE id = $1`, objID2).Scan(&status); err != nil {
|
||||
t.Fatal(err)
|
||||
}
|
||||
if status != "expired" {
|
||||
t.Fatalf("objekt haette bei gleicher testrolle nicht vernichtet werden duerfen, status = %q", status)
|
||||
}
|
||||
}
|
||||
@@ -8,8 +8,6 @@ import (
|
||||
"time"
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/referenceset"
|
||||
)
|
||||
|
||||
func setupTest(t *testing.T) *pgxpool.Pool {
|
||||
@@ -269,45 +267,3 @@ func TestDestroy_RequiresPriorRelease(t *testing.T) {
|
||||
t.Fatalf("erwartet ErrNotReleased, habe: %v", err)
|
||||
}
|
||||
}
|
||||
|
||||
// TestPruefgate02_LegalHoldResistsDeletionForReferenceSetObjects ist QA-02
|
||||
// Pflichtpruefung 1, ausgefuehrt gegen den Referenzdatensatz
|
||||
// (referenceset.RetentionObjects) statt ad-hoc-Fixtures.
|
||||
func TestPruefgate02_LegalHoldResistsDeletionForReferenceSetObjects(t *testing.T) {
|
||||
pool := setupTest(t)
|
||||
ctx := context.Background()
|
||||
|
||||
for _, class := range []string{"steuerlich_10j", "handelsrechtlich_6j", "sofort_loeschbar"} {
|
||||
if _, err := pool.Exec(ctx, `INSERT INTO retention_class_rules (retention_class, duration) VALUES ($1, '1 second')`, class); err != nil {
|
||||
t.Fatal(err)
|
||||
}
|
||||
}
|
||||
past := time.Now().UTC().Add(-24 * time.Hour)
|
||||
|
||||
for _, obj := range referenceset.RetentionObjects() {
|
||||
var objID string
|
||||
if err := pool.QueryRow(ctx, `INSERT INTO retention_objects (object_type, object_reference) VALUES ($1, $2) RETURNING id`, obj.ObjectType, obj.ObjectReference).Scan(&objID); err != nil {
|
||||
t.Fatalf("%s: objekt anlegen: %v", obj.ObjectType, err)
|
||||
}
|
||||
if _, err := pool.Exec(ctx, `INSERT INTO retention_class_assignments (retention_object_id, retention_class, assigned_at) VALUES ($1, $2, $3)`, objID, obj.RetentionClass, past); err != nil {
|
||||
t.Fatalf("%s: klassenzuordnung: %v", obj.ObjectType, err)
|
||||
}
|
||||
if err := SetLegalHold(ctx, pool, objID, "qa-02 pruefgate referenzdatensatz", "qa02@acme.example"); err != nil {
|
||||
t.Fatalf("%s: sperre setzen: %v", obj.ObjectType, err)
|
||||
}
|
||||
|
||||
released, err := ReleaseExpired(ctx, pool, time.Now().UTC())
|
||||
if err != nil {
|
||||
t.Fatalf("%s: releaseexpired: %v", obj.ObjectType, err)
|
||||
}
|
||||
for _, r := range released {
|
||||
if r == objID {
|
||||
t.Fatalf("%s: gesperrtes, faelliges referenzobjekt wurde trotzdem freigegeben", obj.ObjectType)
|
||||
}
|
||||
}
|
||||
|
||||
if err := Destroy(ctx, pool, objID, "qa02-worker"); !errors.Is(err, ErrOnLegalHold) {
|
||||
t.Fatalf("%s: erwartet ErrOnLegalHold, habe: %v", obj.ObjectType, err)
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -9,13 +9,10 @@ import (
|
||||
"encoding/json"
|
||||
"net/http"
|
||||
"net/http/httptest"
|
||||
"reflect"
|
||||
"strings"
|
||||
"testing"
|
||||
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/auditclient"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/audittrail"
|
||||
"gitea.perlbach24.de/scripte/nexarch/archive/internal/referenceset"
|
||||
"gitea.perlbach24.de/scripte/nexarch/common/auditclient"
|
||||
|
||||
"github.com/jackc/pgx/v5/pgxpool"
|
||||
)
|
||||
@@ -198,82 +195,3 @@ func TestExport_ChecksumsMatchAfterUnzip(t *testing.T) {
|
||||
t.Fatalf("erwartet 1 protokollierter export, hatte: %v", *actions)
|
||||
}
|
||||
}
|
||||
|
||||
// referenceDatasetModules baut den eDiscovery-Teil des Referenzdatensatzes
|
||||
// (archive/internal/referenceset, QA-01 Abschnitt 4) als fiktive Module auf —
|
||||
// EIN Objekt je Objekttyp aus RetentionObjects(), Inhalt deterministisch aus
|
||||
// WormPayload(SizeSmall).
|
||||
func referenceDatasetModules() ([]ObjectRef, map[string]ModuleAdapter) {
|
||||
var refs []ObjectRef
|
||||
adapters := map[string]ModuleAdapter{}
|
||||
for _, o := range referenceset.RetentionObjects() {
|
||||
adapters[o.ObjectType] = &fakeModule{moduleType: o.ObjectType, objects: map[string][]byte{
|
||||
o.ObjectReference: referenceset.WormPayload(referenceset.SizeSmall),
|
||||
}}
|
||||
refs = append(refs, ObjectRef{ModuleType: o.ObjectType, Reference: o.ObjectReference, Filename: o.ObjectReference + ".bin"})
|
||||
}
|
||||
return refs, adapters
|
||||
}
|
||||
|
||||
// extractChecksums liest checksums.txt aus einem Export-ZIP in eine Map
|
||||
// Pfad -> SHA-256-Pruefsumme.
|
||||
func extractChecksums(t *testing.T, zipBytes []byte) map[string]string {
|
||||
t.Helper()
|
||||
zr, err := zip.NewReader(bytes.NewReader(zipBytes), int64(len(zipBytes)))
|
||||
if err != nil {
|
||||
t.Fatalf("zip oeffnen: %v", err)
|
||||
}
|
||||
for _, f := range zr.File {
|
||||
if f.Name != "checksums.txt" {
|
||||
continue
|
||||
}
|
||||
rc, err := f.Open()
|
||||
if err != nil {
|
||||
t.Fatalf("checksums.txt oeffnen: %v", err)
|
||||
}
|
||||
buf := new(bytes.Buffer)
|
||||
if _, err := buf.ReadFrom(rc); err != nil {
|
||||
t.Fatalf("checksums.txt lesen: %v", err)
|
||||
}
|
||||
_ = rc.Close()
|
||||
out := map[string]string{}
|
||||
for _, line := range strings.Split(strings.TrimSpace(buf.String()), "\n") {
|
||||
fields := strings.Fields(line)
|
||||
if len(fields) != 2 {
|
||||
continue
|
||||
}
|
||||
out[fields[1]] = fields[0]
|
||||
}
|
||||
return out
|
||||
}
|
||||
t.Fatal("checksums.txt nicht im export gefunden")
|
||||
return nil
|
||||
}
|
||||
|
||||
// QA-03 Akzeptanzkriterium 1 + Pflichtpruefung 1: eDiscovery-Export wird
|
||||
// erneut gegen den Referenzdatensatz (archive/internal/referenceset)
|
||||
// durchgefuehrt. Zwei unabhaengige Exportlaeufe ueber denselben Datensatz
|
||||
// muessen identische Pruefsummen liefern.
|
||||
func TestExport_QA03_ReproducibleAgainstReferenceDataset(t *testing.T) {
|
||||
refs, adapters := referenceDatasetModules()
|
||||
recorder1, _ := newTestRecorder(t)
|
||||
recorder2, _ := newTestRecorder(t)
|
||||
|
||||
zip1, err := Export(context.Background(), recorder1, "tenant_a", "pruefer:QA-03", adapters, refs)
|
||||
if err != nil {
|
||||
t.Fatalf("export lauf 1: %v", err)
|
||||
}
|
||||
zip2, err := Export(context.Background(), recorder2, "tenant_a", "pruefer:QA-03", adapters, refs)
|
||||
if err != nil {
|
||||
t.Fatalf("export lauf 2: %v", err)
|
||||
}
|
||||
|
||||
checksums1 := extractChecksums(t, zip1)
|
||||
checksums2 := extractChecksums(t, zip2)
|
||||
if len(checksums1) != len(referenceset.RetentionObjects()) {
|
||||
t.Fatalf("erwartet %d pruefsummen (ein objekt je referenzdatensatz-typ), hatte %d", len(referenceset.RetentionObjects()), len(checksums1))
|
||||
}
|
||||
if !reflect.DeepEqual(checksums1, checksums2) {
|
||||
t.Fatalf("pruefsummen zwischen zwei unabhaengigen exportlaeufen gegen denselben referenzdatensatz unterschiedlich: lauf1=%v lauf2=%v", checksums1, checksums2)
|
||||
}
|
||||
}
|
||||
Loaded 100 of 550 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user