patrickandClaude Sonnet 5
78ab9a1300
Fable-Review auf Code-Dopplung/interne Links (siehe Analyse). P0-Funde: - Dangling Prosa-Verweise auf die per PR #367 geloeschten *-kanban/-Ordner in SKALIERUNGSKONZEPT.md, STORAGE-KONZEPT.md, MIGRATIONSKONZEPT.md, SICHERHEITSKONZEPT.md (7x "siehe X-kanban/README.md"), PRODUKTARCHITEKTUR.md um Hinweis ergaenzt, dass Boards jetzt in main-Historie/Gitea-PRs liegen. - dms/internal/searchsync/searchsync_test.go:19: falscher Pfad im Kommentar ("internal/bulkedit"/"internal/jobqueue" statt "dms/internal/..."). - web/shl/components/ModuleNavShell.tsx: resolveHrefClientOnly war inhaltlich identisch zu resolveModuleHref in web/portal/app/ModuleGrid.tsx (zwei unabhaengig gepflegte Kopien derselben Hostname-Ersetzung). Als resolveModuleHref aus shl exportiert, ModuleGrid.tsx nutzt jetzt die gemeinsame Funktion, Test-Import entsprechend umgestellt. - web/portal/lib/modules.test.ts: KNOWN_REAL_PERMISSIONS-Whitelist hatte kennzahlen.read (migrations/0019_kennzahlen_policy_rule.up.sql, real existierend seit ANA-02/PR #362) nie nachgetragen, Test lief seitdem unbemerkt im Fehler. Ergaenzt. go test/vitest: web/portal (15/15) und web/shl (61/61) gruen auf Testhost 131. Verbleibender P0-Punkt (14 Web-Apps ohne ModuleNavShell) braucht Produktentscheidung -- mehrere Registry-Keys (ai/mail/workflow/connect) sind bereits durch eine jeweils ANDERE App belegt als die ohne Navigation (z.B. mail-search hat "mail", mail-postfach nicht), daher keine mechanische Zuordnung moeglich ohne zu raten. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
NEXARCH DMS
Dokumentenmanagement-Modul von NEXARCH. Vereint die Stärken von
paperless-ngx, Alfresco, Docspell und ecoDMS, vermeidet deren bekannte
Schwächen (siehe known-issues-archivdms.md im dms-kanban/-Ordner).
Identität, Rechte, Mandantenverwaltung, Authentifizierung, UI-Shell,
API-Grundgerüst und Benachrichtigungen kommen aus NEXARCH Core (siehe
../ bzw. ../../core-kanban/) — dieses Modul implementiert nur die
DMS-eigene Logik.
Setup
Voraussetzung: Go 1.22+.
cd dms
make install # baut App und Worker
make run # startet beide (Strg+C beendet beide)
App läuft danach auf :8600 (überschreibbar über
NEXARCH_DMS_APP_LISTEN_ADDR), GET /healthz liefert den Status. Der Worker
liefert Metriken auf :8601 (NEXARCH_DMS_WORKER_METRICS_ADDR). Portbereich des
DMS laut deploy/ports.tsv: 8600–8699; Prüfung: scripts/check-port-defaults.sh.
Fachliche Routen (z. B. POST /retention/destroy-callback) liegen unter dem Präfix
/api/dms/v1 (NEXARCH_DMS_APP_ROUTE_PREFIX, Register deploy/routes.tsv, Prüfung
scripts/check-route-prefixes.sh); nur /healthz und /metrics bleiben auf Wurzelebene. Die bei archive
registrierte Rückruf-URL (NEXARCH_DMS_APP_RETENTION_CALLBACK_URL) muss den Präfix enthalten.
Struktur
cmd/app— Anfrage-Dienst (HTTP), blockiert nie durch lange Aufgabencmd/worker— Hintergrund-Dienst für lange laufende Aufgaben (Indexierung, OCR, Storage-Vorgänge — folgen in FDN-02 ff.)internal/shared— von App und Worker gemeinsam genutzter Code
Prüfungen
make fmt # gofmt-Verstöße brechen ab
make lint # golangci-lint
make test # go test ./...
Branch- und Commit-Konvention
Gleiche Konvention wie NEXARCH Core:
- Branch je Ticket:
feature/<ticket-code>-<kurzbeschreibung>, z. B.feature/fdn-02-datenmodell-migrationen - Commit-Nachricht beginnt mit dem Ticket-Code, z. B.
FDN-02: datenmodell & migrationen - Ein Ticket = ein Branch. Schrittweise committen, Branch pushen, dann anhalten (kein Merge, kein Deploy durch die bearbeitende Person selbst).
- Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
- Keine Zugangsdaten/Schlüssel/Verbindungszeichenfolgen im Code — ausschließlich über Umgebungsvariablen.