Projektstand · Gesamtübersicht · lokal

NEXARCH 2.0 — wo wir stehen

Sieben Kanban-Boards, ein gemeinsamer Techstack, neun Konzeptdokumente, eine Konsolidierungsregel: was einmal zentral gebaut wird, wird nicht pro Modul wiederholt. Modul-Kacheln und Dokumente unten sind anklickbar.

Boards7 Tickets298 Personentage825 Konsolidierungen6 Konzeptdokumente9
Stand 2026-08-26 · /home/sysops/Dokumente/Scripte/nexarch/uebersicht.html

01 Techstack — für alle Boards bindend

Go Backend (net/http, pgx/v5)
PostgreSQL · kein ORM, SQL-Migrationsdateien
bcrypt, expliziter Kostenfaktor
Postgres-Jobqueue statt Redis
Manticore Search statt Elasticsearch
Next.js/React/TS · eine Shell (Core SHL-01)
natives systemd · Docker optional (SaaS)
Tenancy: Modell A — tenant_id, kein RLS in v1
JWT + lokale JWKS-Verifikation (Core API-05)

02 Modul-Landkarte — Kachel öffnet das jeweilige Kanban-Board

NEXARCH Core → kanban.html
Identity, Tenancy, Auth, Rollen, Lizenzierung, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring, UI-Shell — Fundament für alle sechs Fachmodule
Tickets54 Epics10 Wellen8 PT145

03 Konsolidierungsverlauf

Sobald zwei Boards dieselbe Fachlogik unabhängig planten, wurde sie in genau ein Board gezogen; die anderen behalten nur einen Verweis in ihrer „Ausgangslage", keinen eigenen dependsOn-Code.

Fachlogikwar dupliziert injetzt zentral inErgebnis
Benutzer, Rollen, SSO, LDAP, Mandanten DMS Core 87→79 DMS-Tickets
Retention, WORM, Compliance, Backup, Kennzahlen DMS + Mail Archive DMS 79→73 · Mail 70→61
Workflow-Engine, Genehmigungen, Aufgaben, Routing DMS Workflow DMS 73→66
KI-Klassifizierung, Extraktion, Zusammenfassung, semant. Suche DMS AI DMS 66→65
REST-Grundgerüst, Token, Rate-Limiting, OpenAPI, Webhooks DMS + Mail Core DMS 66→64 · Mail 62→59 · Core +Webhook-Registry
UI-Shell, Design-System, Komponentenbibliothek DMS (einzig vorhanden) Core neue Epic SHL, DMS 64→63
Krypto-Master-Key-Verwaltung & -Rotation DMS + Mail (je eigene KMS-Anbindung) Core Objekt-Verschlüsselung bleibt modul-lokal, nur Master-Key zentral
Volltextsuche, OCR DMS + Mail bewusst je Modul belassen E-Mail- vs. Dokument-Suche gilt als hinreichend verschieden

04 Dokumentenlandkarte — öffnet die Datei direkt

05 Ausgewählter Entscheidungsverlauf

Techstack
Go statt Node/TypeScript-Backend
archivmail + archivdms sind bereits Go + Next.js/TS, ~59k LOC wiederverwendbares Wissen. Rewrite in Node hätte das verworfen — Go skaliert außerdem besser für Multi-Tenant-SaaS.
DMS / Mail
Unterschiedliche Reuse-Regeln je Board
DMS: kompletter Neubau, kein Codeimport (Fehlervermeidung). Mail: Code-Wiederverwendung erlaubt mit Korrekturpflicht (IMAP/SMTP/POP3 ist komplex, nicht leichtfertig neu schreiben).
Sicherheit
Hash-vor-Verschlüsseln, Dedup-Gate vor OCR/Index
Ohne diese Reihenfolge hätte Dublettenerkennung nie funktioniert (nichtdeterministische Verschlüsselung) und OCR wäre auf Duplikaten verschwendet worden — in DMS und Mail unabhängig gefunden und gefixt.
Resilienz
Core-Ausfall darf andere Module nicht lahmlegen
Lokale JWT-Verifikation + kurzlebiger Rechte-Cache (API-05) statt synchroner Rückfrage; Wiederanlauf mit persistenter Pufferqueue (API-06); Core selbst über Postgres-Primary/Replica-Failover abgesichert (SKALIERUNGSKONZEPT Abschnitt 10).
Konsolidierung
Sechs Fachlogiken aus DMS/Mail nach Core/Archive/Workflow/AI gezogen
Wiederkehrendes Muster: zwei Boards planen dieselbe Sache unabhängig. Größter Einzelfund: Krypto-Master-Key-Verwaltung war doppelt geplant — höchstes Fehlerrisiko im Projekt, jetzt zentral.
Akte & Vorgang
Bidirektionaler Modul-Adapter statt nur Push
Workflow hat selbst keine Rohdaten — Vermerke/Wiedervorlage aus Workflow müssen im Ursprungsmodul (DMS/Mail) sichtbar sein. Rückkanal-API (VOR-04) ergänzt, inkl. explizitem Tenant-Scoping als eigenes Kriterium.
Sicherheitsaudit
10 Lücken über OWASP-Raster gefunden, 9 geschlossen
Security-Header-Baseline, mTLS zwischen Modulen, Master-Key-Konsolidierung, Incident-Response-Plan, externer Penetrationstest, CI-Dependency-Scanning, technisches Merge-Gate für sicherheitsrelevanten Code.
Vollständigkeit
Alle neun ursprünglich geforderten Konzeptdokumente fertig
Migrationskonzept, Skalierung, Storage, Sicherheit, Proxmox-Deployment, Roadmap, Produktarchitektur, UI/UX, Lizenzmodell (Entwurf) und SaaS-Betriebsmodell (kein Rechtsdokument) — fehlende_konzeptdokumente in der State-Datei ist jetzt leer.

Vollständiger, datierter Verlauf mit 29 Einträgen in nexarch-state.json → entscheidungsverlauf.