Stefan Mogeritsch
8726129b96
- **Core Updates:** - Implemented `P2pSyncService` interface with platform-specific WebSocket implementations (`JvmP2pSyncService` and no-op for JS). - Developed `SyncEvent` sealed class hierarchy to handle peer synchronization events (e.g., `PingEvent`, `PongEvent`, `DataChangedEvent`, etc.). - **Frontend Integration:** - Introduced `SyncManager` to manage peer discovery and synchronization, coupled with `NetworkDiscoveryService`. - Updated dependency injection to include `syncModule` for platform-specific sync service initialization. - Enhanced `BewerbViewModel` to support new sync capabilities, including observing sync events and UI updates for connected peers. - **Backend Enhancements:** - Added ZNS-specific fields (`zns_nummer`, `zns_abteilung`) to Bewerb table for idempotent imports. - Introduced import ZNS logic to handle duplicates and align with SyncManager updates. - **UI Improvements:** - Enhanced `TurnierBewerbeTab` with updated dialogs (ZNS imports, sync status) and dynamic previews. - Improved network syncing feedback and error handling in frontend components. - **DB Changes:** - Added migration for new column fields in the Bewerb table with relevant indexing for ZNS import optimizations.
278 lines
18 KiB
Markdown
278 lines
18 KiB
Markdown
---
|
||
type: Roadmap
|
||
status: ACTIVE
|
||
owner: Lead Architect
|
||
last_update: 2026-04-03
|
||
---
|
||
|
||
# MASTER ROADMAP: Meldestelle-Biest
|
||
|
||
🏗️ **[Lead Architect]** | 30. März 2026
|
||
|
||
**Strategisches Ziel:**
|
||
Entwicklung einer ÖTO-konformen, offline-fähigen Turnier-Meldestelle als Compose Desktop App (KMP).
|
||
Vollständige Self-Hosted Infrastruktur (Gitea, Pangolin, Zora). Datensouveränität, Offline-First, saubere Wissensbasis.
|
||
|
||
**Produktfokus:**
|
||
- Desktop-App ist der primäre Client (Compose Desktop, KMP) — „Desktop-First“ gilt für UX und Architektur.
|
||
- Offline-First Betrieb mit lokaler Persistenz und opportunistischer Synchronisation.
|
||
|
||
**Aktueller technischer Stand (30.03.2026):**
|
||
* **Infrastruktur:** ✅ "Zora" (MS-R1, ARM64) ist live. Gitea & Registry laufen.
|
||
* **Networking:** ✅ Pangolin Tunnel ersetzt Cloudflare.
|
||
* **CI/CD:** ✅ Gitea Actions mit ARM64-Runner (VM 102) aktiv. Docker-Publish Pipeline grün.
|
||
* **Code-Basis:** ✅ Backend (Java 25 / Spring Boot / Kotlin), Frontend (KMP/Compose Desktop).
|
||
* **Domain-Design:** ✅ 6 Bounded Contexts (SCS-Architektur) definiert. Ubiquitous Language erstellt.
|
||
* **Domain-Modelle:** ✅ `Reiter`, `DomNennung`, `DomNennungsTransfer`, `Pferd`, `Funktionaer`, `Verein`,
|
||
`DomBewerb`, `DomAbteilung`, `DomStartliste`, `DomVeranstaltung`, `DomTurnier`, `DomAusschreibung` implementiert.
|
||
Enums ÖTO-konform.
|
||
* **Dokumentation:** ✅ Konsolidiert. ÖTO-Regelwerk-Referenzen (Abteilungs-Schwellenwerte) dokumentiert.
|
||
|
||
---
|
||
|
||
## Architektur-Übersicht: 6 Bounded Contexts (SCS)
|
||
|
||
Das System ist in **6 Self-Contained Systems (SCS)** aufgeteilt, die fachlich voneinander getrennt sind
|
||
und über definierte Schnittstellen kommunizieren.
|
||
|
||
| SCS | Kontext | Priorität | Status |
|
||
|----------------------------|---------------------------------------|-----------|----------------|
|
||
| `registration-context` | Nennungs-Workflow (Herzstück) | **P1** | ✅ Fertig |
|
||
| `actor-context` | Reiter, Pferde, Funktionäre, ZNS | **P1** | ✅ Fertig |
|
||
| `competition-context` | Bewerbe, Startlisten, Ergebnisse | **P2** | ✅ Fertig |
|
||
| `event-management-context` | Veranstaltung, Turnier, Ausschreibung | **P2** | ✅ Fertig |
|
||
| `billing-context` | Abrechnung, Kassa, Gebühren | **P3** | ✅ Fertig |
|
||
| `identity-context` | Auth, Rollen (Keycloak) | **P3** | ✅ Fertig |
|
||
| `series-context` | Cups, Serien, Meisterschaften | Phase 2+ | 🔵 Vorbereitet |
|
||
|
||
> **Hinweis `series-context`:** Ist Phase 2+, aber die Architektur ist von Anfang an vorbereitet.
|
||
> Cups/Serien/Meisterschaften benötigen eigene, konfigurierbare Reglements (kein Hard-Coding).
|
||
> Pluggable Berechnungsmodell und konfigurierbare Paar-Bindung (Reiter+Pferd vs. nur Reiter) erforderlich.
|
||
|
||
---
|
||
|
||
## 1. Abgeschlossene Phasen
|
||
|
||
### PHASE 1: Documentation Cleanup ✅ ABGESCHLOSSEN
|
||
*Ziel: Eine einzige, vertrauenswürdige Quelle der Wahrheit (SSOT) schaffen.*
|
||
|
||
#### 🧹 Agent: Curator
|
||
* [x] **Archivierung:** Veraltete Docs (Cloudflare, GitHub-Workflows, alte Roadmaps) nach `docs/_archive/` verschoben.
|
||
* [x] **Konsolidierung:** `Zora_System_Architektur.md` als zentrale Infrastruktur-Doku etablieren.
|
||
* [x] **Struktur:** `docs/` Ordner aufräumen (unnötige Root-Files in Unterordner).
|
||
* [x] **Index:** `README.md` im Root als Einstiegspunkt aktualisieren.
|
||
|
||
### PHASE 2: Infrastructure Hardening ✅ ABGESCHLOSSEN
|
||
*Ziel: Stabilisierung der neuen Self-Hosted Umgebung.*
|
||
|
||
#### 🐧 Agent: DevOps Engineer
|
||
|
||
* [x] **Keycloak Fix:** Verbindungsprobleme innerhalb des Docker-Netzwerks behoben (Alias `auth.mo-code.at`).
|
||
* [x] **Backup Strategy:** Automatisierte Backups für Gitea & Datenbanken auf Zora (`config/scripts/backup.sh`).
|
||
* [x] **Monitoring:** Prometheus/Grafana Dashboard für Zora finalisiert (`dc-ops.yaml`).
|
||
* [x] **Deployment:** Git-basiertes Deployment-Skript (`config/scripts/deploy.sh`) erstellt.
|
||
|
||
### PHASE 3: Domain-Design & Ubiquitous Language ✅ ABGESCHLOSSEN
|
||
|
||
*Ziel: Fachliche Grundlage für die Implementierung schaffen.*
|
||
|
||
#### 🏗️ Agent: Lead Architect
|
||
|
||
* [x] **DDD-Analyse:** 6 Bounded Contexts (SCS-Architektur) definiert und priorisiert.
|
||
* [x] **Terminologie:** `Veranstaltung` ≠ `Turnier` gemäß ÖTO § 2 Abs. 1 festgelegt (ADR).
|
||
* [x] **Design-Baseline:** Vision_03 (Figma) als offizieller Design-Baseline festgelegt.
|
||
* [x] **Technologie:** Desktop-First-Strategie mit KMP/Compose Desktop beschlossen.
|
||
|
||
#### 📜 Agent: ÖTO/FEI Rulebook Expert
|
||
|
||
* [x] **Ubiquitous Language:** Offizielle Domänen-Terminologie mit ÖTO-Referenzen erstellt.
|
||
* [x] **Abteilungs-Schwellenwerte:** Alle Trennungs-Schwellenwerte (§ 39 + spartenspezifisch) dokumentiert.
|
||
→ `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`
|
||
|
||
#### 👷 Agent: Backend Developer
|
||
|
||
* [x] **Enums:** `SparteE`, `TurnierkategorieE`, `VeranstaltungsTypE`, `LizenzKlasseE`, `NennungsStatusE`,
|
||
`StartwunschE` – ÖTO-konform.
|
||
* [x] **Domain-Modelle:** `DomReiter` (actor-context), `DomNennung`, `DomNennungsTransfer` (registration-context).
|
||
* [x] **Modul:** `entries-domain` als KMP-Modul aufgesetzt und in `settings.gradle.kts` registriert.
|
||
|
||
---
|
||
|
||
## 2. Aktuelle Phase
|
||
|
||
### PHASE 4: MVP-Implementierung ✅ ABGESCHLOSSEN
|
||
|
||
*Ziel: Lauffähiger MVP für `registration-context` und `actor-context` (P1-Contexts).*
|
||
|
||
#### 🧐 Agent: QA Specialist
|
||
|
||
* [x] **Actor Context Stabilization:** Funktionär-Datenmodell (Richter/Parcoursbauer) auf professionelle Master-Daten-Referenzierung umgestellt und mit Reiter-Daten verknüpft (Import-Idempotenz via `satzNummer`). Redundante Kontakt-/Adressdaten entfernt. Alle ZNS-Import-Tests (9/9) stabilisiert und verwaiste Parser-Reste entfernt.
|
||
* [x] **Masterdata Standardization:** Bereinigung und Standardisierung der Masterdaten-Tabellen (Mehrzahl-Konvention: `bundeslaender`, `funktionaers_qualifikationen`, `reit_lizenzen`, `turnier_klassen`).
|
||
* [x] **ÖTO Data Seeding:** Umfassende Seeder für Funktionärs-Qualifikationen, Turnierklassen und Turnier-Sparten gemäß ÖTO implementiert. Einführung der Tabelle `turnier_sparten`.
|
||
* [x] **ZNS-Import Optimization:** Automatische Verknüpfung von Funktionären mit Reitern (Reihenfolge: VEREIN -> LIZENZ -> PFERDE -> RICHT). `ZnsImportService` für sequentielle Imports in Tests gehärtet.
|
||
* [x] **Service Stability:** Port-Konflikt des `masterdata-service` (Spring Management Port 8081 vs. Gateway) durch Umzug auf Port 8086 und explizite Bind-Adressen (Spring: 127.0.0.1, Ktor: 0.0.0.0) dauerhaft gelöst.
|
||
* [x] **Documentation:** `CHANGELOG.md` aktualisiert und Port-Konfiguration in `application.yml` dokumentiert.
|
||
→ Note: `IdempotencyApiIntegrationTest` bleibt vorerst @Disabled, da das Hochfahren des Spring-Contexts in der
|
||
Testumgebung blockiert (unabhängig vom Plugin).
|
||
→ Task: Integration-Test Umgebung (Port-Binding/Server-Lifecycle) für `masterdata-service` untersuchen.
|
||
|
||
#### 🏗️ Agent: Lead Architect
|
||
|
||
* [x] **ADRs vervollständigen:** Bounded Context Mapping und Context Map dokumentieren.
|
||
→ `docs/01_Architecture/adr/0014-bounded-context-mapping-de.md`
|
||
→ `docs/01_Architecture/adr/0015-context-map-de.md`
|
||
* [x] **API-Design:** Schnittstellen zwischen den Contexts definieren (Anti-Corruption Layer).
|
||
→ `docs/01_Architecture/adr/0016-api-design-acl-de.md`
|
||
* [x] **ÖTO-Validation-Seeds:** Seed-Daten für Lizenz-Matrix und Altersklassen finalisiert (V008).
|
||
|
||
#### 👷 Agent: Backend Developer
|
||
|
||
* [x] **ZNS-Importer:** Support für Richter-Import (RICHT01.DAT) und Reiter-Refactoring (LIZENZ01.DAT) vervollständigt. ✓
|
||
* [x] **Masterdata:** Qualifikations-System und Personen-Referenzen (Vereine, Bundesländer, Nationen) stabilisiert (Consul & MasterdataSeeder). ✓
|
||
* [x] **Infrastruktur:** Service-Discovery (Consul) für alle Microservices (incl. Masterdata) aktiviert.
|
||
* [x] **Infrastruktur:** Bean-Definitionen und Dependency-Injection im `zns-import-service` bereinigt.
|
||
* [x] **Database:** Initialisierung der Funktionärs-Tabellen stabilisiert (PSQLException Fix).
|
||
* [x] **`actor-context`:** Domain-Modelle für `Pferd`, `Funktionaer`, `Verein` implementiert.
|
||
* [x] **`registration-context`:** `DomBewerb`, `DomAbteilung`, `DomStartliste` implementiert.
|
||
* [x] **`event-management-context`:** `DomVeranstaltung`, `DomTurnier`, `DomAusschreibung` implementiert.
|
||
* [x] **Persistenz:** Repository-Interfaces und erste DB-Migrationen (Flyway/Liquibase).
|
||
* [x] **API:** REST-Endpunkte für Nennungs-Workflow (Kern-Use-Cases).
|
||
* [x] **Infrastruktur-Stabilisierung:** Kompilierfehler in `masterdata-infrastructure` behoben.
|
||
* [x] **Identity-Schnittstellen:** Endpunkte für ZNS-Linking über `identity-service` bereitgestellt.
|
||
|
||
#### 🎨 Agent: Frontend Expert
|
||
|
||
* [x] **KMP/Compose Desktop:** Projektstruktur aufgesetzt (`frontend/shells/meldestelle-desktop`).
|
||
* [x] **Navigation:** Sidebar-Navigation gemäß Vision_03 implementiert (Veranstaltungen, Reiter, Pferde, Funktionäre,
|
||
Meisterschaften, Cups).
|
||
* [x] **Nennungs-Screen:** `TurnierDetailScreen` integriert `NennungsMaske` aus `nennung-feature` (Bewerbe-Tab ⭐).
|
||
|
||
#### 📜 Agent: ÖTO/FEI Rulebook Expert
|
||
|
||
* [x] **Voltigieren (CVN):** Abteilungs-Trennungsregeln aus B-Teil § 400 ff. ausgewertet (offene Frage #3 teilweise
|
||
geklärt).
|
||
→ B IV enthält keine eigenen Regeln – verweist auf OEPS-Reglement CVN. § 39 Abs. 1 gilt nicht für CVN. § 39 Abs.
|
||
2 (> 80 Starter) gilt als Fallback.
|
||
→ `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md` (Abschnitt 2.6)
|
||
* [x] **Fahren (CAN):** Starter-Schwellenwerte jenseits der Reitertreffen-Regel geklärt (offene Frage #4 teilweise
|
||
geklärt).
|
||
→ B VII enthält keine eigenen Regeln – verweist auf OEPS-Reglement „Turnierordnung für Gespanne". § 39 Abs. 1 gilt
|
||
nicht für CAN. § 39 Abs. 2 (> 80 Starter) gilt als Fallback. Einzige gesicherte Lizenzregel: § 850 Abs. 9 (F1+ bei
|
||
Fahrertreffen).
|
||
→ `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md` (Abschnitt 2.5)
|
||
* [x] **Warn-Logik:** Spezifikation der `competition-context` Warn-Logik für Abteilungs-Schwellenwerte.
|
||
→ `docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md`
|
||
|
||
#### 🧹 Agent: Curator & Lead Architect (ZNS-Importer)
|
||
|
||
* [x] **ZNS-Importer (MVP) – Phase 1 & 2:** `core:zns-parser` (KMP), `ZnsLegacyParsers` (alle 4 Dateitypen, CP850),
|
||
`ZnsImportService` (Orchestrator, ZIP in-memory, Upsert), Unit-Tests grün.
|
||
→ Detaillierte Planung: `docs/01_Architecture/Roadmap_ZNS_Importer.md`
|
||
* [x] Backend-Infrastruktur & CP850 Parser (Phase 1 – Parser/Modul)
|
||
* [x] Domain-Mapping & Upsert in DB (Phase 2)
|
||
* [x] REST-API & Job-Management (Phase 1 – Controller/Job-Registry)
|
||
* [x] Frontend-Integration mit File-Picker & Status-Polling (Phase 3)
|
||
|
||
---
|
||
|
||
## 3. Aktuelle Phase
|
||
|
||
### PHASE 5: P2-Contexts & Integration ✅ ABGESCHLOSSEN
|
||
|
||
*Ziel: `competition-context` und `event-management-context` implementieren.*
|
||
|
||
* [x] **`competition-context`:** Bewerbe, Startlisten, Ergebnisse, Abteilungs-Warn-Logik.
|
||
* [x] **`event-management-context`:** Veranstaltungs- und Turnier-Verwaltung, Ausschreibungs-Generator.
|
||
* [x] **ZNS-Integration:** Schnittstelle zum Zentralen Nennungs-System (A-Satz / B-Satz).
|
||
* [x] **Offline-Sync:** Offline-First-Strategie für Desktop-App implementieren.
|
||
|
||
### PHASE 6: P3-Contexts & Billing ✅ ABGESCHLOSSEN
|
||
|
||
*Ziel: `billing-context` und `identity-context` implementieren.*
|
||
|
||
* [x] **`billing-context`:** Gebührenberechnung, Kassa, Abrechnung.
|
||
* [x] **`identity-context`:** Rollen-Modell (TBA, Veranstalter, Richter etc.) mit Keycloak.
|
||
* [x] **Reporting:** Startlisten- und Ergebnislisten-Druck (PDF).
|
||
|
||
---
|
||
|
||
## 4. Geplante Phasen
|
||
|
||
### PHASE 7: Desktop-Vernetzung & Zentrale Verwaltung ✅ ABGESCHLOSSEN
|
||
|
||
*Ziel: LAN-Kommunikation Vorbereitung und Etablierung der "Veranstaltung-Verwaltung" als zentrale Schaltstelle.*
|
||
|
||
* [x] **Zentrale Verwaltung:** Etablierung der `Veranstaltung-Verwaltung` (Zentrale) als administratives Cockpit.
|
||
* [x] **Navigation:** Implementierung eines Back-Stack-Systems für intelligente "Zurück"-Navigation.
|
||
* [x] **Domänen-Synchronisation:** Anpassung der Frontend-Stores an die Backend-Masterdata-Modelle (Reiter, Pferde,
|
||
Vereine, Funktionäre).
|
||
* [x] **ZNS-Integration (Frontend):** ZNS-Importer in die Zentrale integriert; Konzept "Globaler Pool -> Lokale
|
||
Synchronisation" gefestigt.
|
||
* [x] **Terminologie:** UI-weit Umstellung von "Event" auf "Veranstaltung" (ÖTO-konform).
|
||
* [x] **Konzept:** LAN-Discovery (mDNS) und Echtzeit-Sync (WebSockets) entworfen.
|
||
* [x] **ADR:** ADR-0020 (Lokale Netzwerk-Kommunikation) erstellt.
|
||
|
||
### PHASE 8: Bewerbe-Management & Startlisten 🔵 IN ARBEIT
|
||
|
||
*Ziel: Fachliche Tiefe in den Turnieren (Import, Generierung, Zeitberechnung).*
|
||
|
||
* [x] **Konzept/ADR:** LAN‑Sync (ADR‑0022) und Offline‑First Desktop↔Backend Konzept definiert und verlinkt.
|
||
* [x] **Bewerbe-Import:** Implementierung der Merge-Logik (ZNS-XML -> BewerbUiModel). ✓
|
||
* [x] **Startlisten-Automatisierung:** Generierung und Zeitberechnung (Pausen, Umbauzeiten). ✓
|
||
* [x] **Discovery:** Implementierung des mDNS-Service (JmDNS) für die Geräte-Suche. ✓
|
||
* [x] **Transport:** Aufbau der WebSocket-Infrastruktur für P2P-Sync (Ktor WebSockets, SyncManager). ✓
|
||
* [ ] **Offline-First Desktop↔Backend:** Umsetzung gemäß Konzept „Offline-First Synchronisation (Desktop ↔ Backend)“ → `docs/01_Architecture/konzept-offline-first-desktop-backend-de.md`.
|
||
|
||
### PHASE 9: Series-Context & Erweiterungen 🔵 PHASE 2+
|
||
|
||
*Ziel: Cups, Serien und Meisterschaften mit konfigurierbaren Reglements.*
|
||
|
||
* [ ] **`series-context`:** Pluggable Berechnungsmodell, konfigurierbare Paar-Bindung.
|
||
* [ ] **Web-Portal:** Shared Module aus Desktop-App extrahieren → Web-Portal aufbauen.
|
||
* [ ] **Mobile:** KMP-Sharing auf Android/iOS ausweiten.
|
||
|
||
---
|
||
|
||
## 4. Wichtige Architektur-Entscheidungen (ADRs)
|
||
|
||
| # | Entscheidung | Status | Dokument |
|
||
|----|--------------------------------------------------------------|--------|------------------------------|
|
||
| 1 | Vision_03 = Design-Baseline | ✅ | Session Log 2026-03-24 |
|
||
| 2 | Desktop-First mit KMP/Compose Desktop | ✅ | ADR-0009 |
|
||
| 3 | `Veranstaltung` ≠ `Turnier` (ÖTO § 2 Abs. 1) | ✅ | Ubiquitous Language |
|
||
| 4 | 6 Bounded Contexts als SCS-Architektur | ✅ | Session Log 2026-03-24 |
|
||
| 5 | `series-context` ist Phase 2+ (Architektur vorbereitet) | ✅ | Session Log 2026-03-24 |
|
||
| 6 | Cups/Serien benötigen konfigurierbare Reglements | ✅ | Session Log 2026-03-24 |
|
||
| 7 | Warn-Logik statt harter Fehler (Override-Event) | ✅ | Abteilungs-Schwellenwerte.md |
|
||
| 8 | 6 Bounded Contexts: Mapping & Aggregate Roots | ✅ | ADR-0014 |
|
||
| 9 | Context Map: Integration Patterns & ACL-Strategie | ✅ | ADR-0015 |
|
||
| 10 | API-Design & ACL: Ports, DTOs, REST-Endpunkte, Domain Events | ✅ | ADR-0016 |
|
||
| 11 | Masterdata: Importer-Einbettung als Worker | ✅ | ADR-0017 |
|
||
| 12 | Masterdata: Rule-Versionierung (Regulation-as-Data) | ✅ | ADR-0018 |
|
||
| 13 | Masterdata: API-Schichten (REST vs. Ingestion) | ✅ | ADR-0019 |
|
||
| 14 | Lokale Netzwerk-Kommunikation und Daten-Isolierung | ✅ | ADR-0020 |
|
||
| 15 | Masterdata: Observability & Operations | ✅ | masterdata-ops.md, CHANGELOG |
|
||
| 16 | Tenant-Resolution: Schema-per-Tenant | ✅ | ADR-0021 |
|
||
| 17 | LAN-Sync-Protokoll (Lamport-Uhren, Event-Sourcing Light) | ✅ | ADR-0022 |
|
||
|
||
---
|
||
|
||
## 5. Wichtige Referenzen
|
||
|
||
| Dokument | Pfad |
|
||
|---------------------------|----------------------------------------------------------------------------------------------|
|
||
| Ubiquitous Language | `docs/03_Domain/01_Glossary/Ubiquitous_Language.md` |
|
||
| Abteilungs-Schwellenwerte | `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md` |
|
||
| Warn-Logik-Spezifikation | `docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md` |
|
||
| Session Log (DDD) | `docs/99_Journal/2026-03-24_Session_Log_DDD_Ubiquitous_Language.md` |
|
||
| Infrastruktur | `docs/07_Infrastructure/Zora_System_Architektur.md` |
|
||
| Deployment Guide | `docs/07_Infrastructure/Guides/Setup_Git_Deployment_Zora.md` |
|
||
| Backup Guide | `docs/07_Infrastructure/Guides/Setup_Backup_Zora.md` |
|
||
| CI/CD | `.gitea/workflows/docker-publish.yaml` |
|
||
| Agent Playbooks | `docs/04_Agents/Playbooks/` |
|
||
| ADR-Verzeichnis | `docs/01_Architecture/adr/` |
|
||
| ZNS-Importer Roadmap | `docs/01_Architecture/Roadmap_ZNS_Importer.md` |
|
||
| Masterdata Roadmap | `backend/services/masterdata/docs/ROADMAP.md` |
|
||
| Masterdata Changelog | `backend/services/masterdata/docs/CHANGELOG.md` |
|
||
| Masterdata Operations | `backend/services/masterdata/docs/runbooks/masterdata-ops.md` |
|