Files

T

sysopsandClaude Sonnet 5 08d54715d4 FDN-01: repository & projektgerüst

DMS-Modul-Grundgerüst als Unterordner im bestehenden nexarch-Monorepo
(dms/), eigenes Go-Modul (gitea.perlbach24.de/scripte/nexarch/dms),
getrennt von Core. App/Worker-Trennung nach paperless-ngx-Vorbild (lange
Aufgaben blockieren nie eine Anfrage): cmd/app (HTTP, /healthz),
cmd/worker (Hintergrund-Dienst-Stub), internal/shared.

golangci-lint (govet/staticcheck/errcheck/unused/ineffassign/gofmt/
goimports) + Makefile-Targets (install/run/lint/fmt/test). Auf
192.168.1.131 verifiziert: build/fmt/lint/test clean, absichtlich
eingefuegter Lint-Verstoss bricht den Build wie gefordert ab (Exit 2),
make run startet App+Worker und /healthz antwortet innerhalb 2s.

Siehe dms/docs/FDN-01-PRUEFPROTOKOLL.md fuer alle Pruefungsergebnisse.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ

2026-08-29 17:32:35 +02:00

1.7 KiB

Raw Permalink Blame History

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 :8090 (überschreibbar über NEXARCH_DMS_APP_LISTEN_ADDR), GET /healthz liefert den Status.

Struktur

cmd/app — Anfrage-Dienst (HTTP), blockiert nie durch lange Aufgaben
cmd/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.

1.7 KiB Raw Permalink Blame History