dms-kanban: Folgetickets FDN-13 bis FDN-15 (Kollisionsvermeidung beim Deployment)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

dms-kanban/tickets/FDN-13.md

@@ -0,0 +1,55 @@
+# FDN-13 – Datenbank-/Schema-Trennung & eigene Migrationstabelle je Modul
+
+**Epic:** ⚙️ Fundament  |  **Rolle:** Backend  |  **Komplexität:** Klein  |  **Aufwand:** 1 Personentag  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+In Betriebsstufe 1 teilen sich alle Module einen PostgreSQL-Cluster. `internal/migrate` legt die Tabelle `schema_migrations` unqualifiziert an; liegen zwei Module in derselben Datenbank/demselben Schema, überschreiben sie gegenseitig ihren Migrationsfortschritt. Migrationstabelle modulspezifisch benennen (`dms_schema_migrations`), bestehende Installationen ohne Datenverlust umstellen und die Zuordnung Datenbank/Schema je Modul in `PROXMOX-DEPLOYMENT.md` verbindlich festlegen.
+
+**Technische Grundlage:** Go-Migrationsrunner (FDN-02), PostgreSQL-Schemas
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Ein Binary pro Modul, unabhängig deploybar (`PROXMOX-DEPLOYMENT.md` Abschnitt 7): jedes Modul verwaltet seinen eigenen Migrationsstand.
+
+**Bewusst vermeiden:**
+- Namensräume, die erst beim gemeinsamen Deployment kollidieren.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: FDN-02, FDN-12.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Der Migrationsrunner des DMS nutzt eine modulspezifisch benannte Tabelle
+2. Eine bestehende `schema_migrations`-Tabelle mit DMS-Versionen wird verlustfrei übernommen (Umbenennung, keine erneute Ausführung)
+3. Zwei Module in derselben Datenbank behindern sich nicht gegenseitig beim Migrieren
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Migration gegen leere Datenbank legt `dms_schema_migrations` an
+2. Test: Upgrade von Bestand mit `schema_migrations` führt keine Migration doppelt aus
+3. Test: zweiter Runner mit anderem Tabellennamen in derselben Datenbank migriert unabhängig
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Routenpräfix je Modul
+- Anpassung anderer Module (eigene Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `FDN-13: datenbank-schema-trennung-je-modul`
+- Branch: `feature/fdn-13-datenbank-schema-trennung-je-modul`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

dms-kanban/tickets/FDN-14.md

@@ -0,0 +1,55 @@
+# FDN-14 – Routenpräfix je Modul hinter dem gemeinsamen Reverse Proxy
+
+**Epic:** ⚙️ Fundament  |  **Rolle:** Backend  |  **Komplexität:** Klein  |  **Aufwand:** 1 Personentag  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Das DMS registriert HTTP-Pfade auf Root-Ebene (`/search`, `/documents/{id}/content`, `/healthz`). Hinter einem gemeinsamen nginx (Betriebsstufe 1) kollidieren diese, sobald ein anderes Modul denselben Pfad nutzt. Alle DMS-Routen unter einem einheitlichen Präfix `/api/dms/v1` bereitstellen (konfigurierbar), `/healthz` bleibt zusätzlich ohne Präfix erreichbar, nginx-Beispielkonfiguration in `PROXMOX-DEPLOYMENT.md` ergänzen.
+
+**Technische Grundlage:** net/http ServeMux, Reverse-Proxy-Konfiguration
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Die Oberfläche nutzt ausschließlich die öffentliche Schnittstelle: stabile, versionierte Pfade.
+
+**Bewusst vermeiden:**
+- Pfadkollisionen zwischen Modulen hinter einem Proxy.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: FDN-02, FDN-12.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle fachlichen DMS-Routen sind unter dem konfigurierbaren Präfix erreichbar
+2. Ohne Präfix sind sie nicht mehr erreichbar (außer `/healthz`)
+3. Die Präfixe aller Module sind im Port-/Routenregister ohne Überschneidung eingetragen
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Routen unter Präfix antworten, Root-Pfade liefern 404
+2. Test: Präfix über Umgebungsvariable ändert alle Routen konsistent
+3. Prüfskript: doppelte Präfixe im Register werden erkannt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Modul-zu-Modul-Authentifizierung (Core API-09)
+- Anpassung anderer Module (eigene Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `FDN-14: routenpraefix-je-modul`
+- Branch: `feature/fdn-14-routenpraefix-je-modul`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

dms-kanban/tickets/FDN-15.md

@@ -0,0 +1,55 @@
+# FDN-15 – Preflight-Prüfung im Installationsskript
+
+**Epic:** ⚙️ Fundament  |  **Rolle:** Backend  |  **Komplexität:** Klein  |  **Aufwand:** 1 Personentag  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Das Installationsskript (Betriebsstufe 1, `PROXMOX-DEPLOYMENT.md` Abschnitt 2) soll vor dem Einspielen prüfen, ob die Standard-Ports frei sind, ob die systemd-Unit-Namen (`nexarch-dms.service`, `nexarch-dms-worker.service`) bereits belegt sind und ob die Ziel-Datenbank bzw. das Schema erreichbar ist und keinen fremden Migrationsstand enthält. Bei Konflikt: Abbruch vor jeder Änderung mit klarer Meldung.
+
+**Technische Grundlage:** Bash-Installationsskript, `deploy/ports.tsv` (FDN-12), systemd
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Das bewährte `install.sh`-Muster aus archivdms: natives Setup, kein Docker.
+
+**Bewusst vermeiden:**
+- Halb installierte Systeme durch Abbruch mitten im Ablauf; Kollisionen, die erst beim Start des zweiten Dienstes sichtbar werden.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: FDN-02, FDN-12.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Preflight läuft vor jeder Änderung am System
+2. Belegter Port, vorhandene Unit oder fremder Migrationsstand führt zum Abbruch ohne Änderung
+3. Ein freies System besteht den Preflight
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Port mit Testlistener belegt, Preflight bricht ab und nennt Port und Modul
+2. Test: vorhandene Unit-Datei erkannt
+3. Test: freies System besteht
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Vollständiges Installationsskript für alle Module (eigene Kachel)
+- systemd-Unit-Dateien selbst
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `FDN-15: preflight-im-installationsskript`
+- Branch: `feature/fdn-15-preflight-im-installationsskript`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.