diff --git a/dms-kanban/tickets/FDN-13.md b/dms-kanban/tickets/FDN-13.md new file mode 100644 index 00000000..bf581eec --- /dev/null +++ b/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. diff --git a/dms-kanban/tickets/FDN-14.md b/dms-kanban/tickets/FDN-14.md new file mode 100644 index 00000000..5c430983 --- /dev/null +++ b/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. diff --git a/dms-kanban/tickets/FDN-15.md b/dms-kanban/tickets/FDN-15.md new file mode 100644 index 00000000..2f7db1a7 --- /dev/null +++ b/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.