meldestelle/docs/01_Architecture/MASTER_ROADMAP_2026_Q1.md
Stefan Mogeritsch 5ab0c9524e docs: update architecture to reflect Proxmox migration and correct network configurations
Revised multiple documents to align with the migration from Incus to Proxmox VE 8.4.10. Updated hypervisor, IP ranges, subnet details, and NAT configurations across all relevant files. Marked Incus sections as historical for clarity. Added AI-Stack setup guide for Proxmox LXC.
2026-03-06 13:50:56 +01:00

4.1 KiB

type status owner last_update
Roadmap ACTIVE Lead Architect 2026-02-07

MASTER ROADMAP Q1 2026: "Operation Tracer Bullet"

Strategisches Ziel: Wir validieren die gesamte Architektur-Kette (Frontend -> Gateway -> Service -> DB) anhand des Ping-Service. Dieser Service dient als technischer Blueprint (Vorlage) für alle kommenden Fach-Services. Er muss "Production Ready" gehärtet sein, bevor wir Fachlichkeit implementieren.

Aktueller technischer Stand (07.02.2026):

  • Build System: Grün (Gradle, Kotlin 2.3, Spring Boot 3.5.9, Spring Cloud 2025.0.1).
  • Code-Basis: ping-service existiert, Delta-Sync implementiert.
  • Infrastruktur: Docker Environment stabil (Valkey, Keycloak, Consul, Zipkin).
  • Frontend: Web-App & Desktop-App (KMP), Login funktioniert, Sync-Logik vorhanden.
  • Hardware: Minisforum MS-R1 eingetroffen.

2. Arbeitsaufträge an die AGENTS (Phasenplan)

PHASE 1: Backend Hardening & Infrastructure (ABGESCHLOSSEN)

Ziel: Der Ping-Service läuft sicher, stabil und beobachtbar in der Docker-Umgebung.

👷 Agent: Senior Backend Developer

  • Security Implementation: OAuth2 Resource Server & RBAC implementiert.
  • Resilience: CircuitBreaker für /ping/enhanced aktiv.
  • Observability: Actuator, Micrometer & Zipkin Tracing aktiv.
  • Persistence: Flyway & Postgres Integration stabil.

🏗️ Agent: Infrastructure & DevOps

  • Docker Environment: dc-infra, dc-backend, dc-gui stabil. Valkey als Redis-Ersatz integriert.
  • Gateway Config: Routing /api/ping/** -> ping-service mit CircuitBreaker Fallback konfiguriert.

PHASE 2: Frontend Integration (ABGESCHLOSSEN)

Ziel: Das Frontend kann authentifiziert mit dem Backend sprechen.

🎨 Agent: KMP Frontend Expert

  • HTTP Client Core: Ktor Client mit Auth & Error Handling.
  • Authentication Flow: OIDC Login Flow (Keycloak) implementiert.
  • UI Implementation: Debug-Screen für Pings vorhanden.

PHASE 3: Offline & Sync (ABGESCHLOSSEN)

Ziel: Datenkonsistenz auch bei Netzwerk-Verlust.

🤝 Joint Task Force (Backend & Frontend)

  • Sync-Protokoll: PingEvent Contract definiert.
  • Sync-Fix (CRITICAL): Typ-Mismatch behoben! Backend und Frontend nutzen nun konsistent since: Long.
  • Web-App Sync: SQLDelight Integration vorbereitet.

3. Definition of Done (für Phase 1 & 2)

  1. docker compose up startet den kompletten Stack fehlerfrei.
  2. Frontend-User kann sich einloggen (Keycloak).
  3. Frontend zeigt Daten vom ping-service an.
  4. Beim Abschalten der DB zeigt der Service einen sauberen Fallback (CircuitBreaker offen).
  5. In Zipkin ist der komplette Request-Trace (Frontend -> Gateway -> Service -> DB) sichtbar.

4. Next Steps (Q1/2026)

  1. Entries Service: Beginn der Implementierung des ersten echten Fach-Services ("Nennungen").
  2. System Hardening: Keycloak Production-Config (kein start-dev).
  3. Reporting / Printing: (Vorgemerkt)
    • Anforderung: PDF-Generierung für Startlisten, Ergebnislisten, Dressur-Protokolle (personalisiert).
    • Architektur-Entscheidung: Dezentraler Microservice (wegen Resource-Bursts).
    • Technologie-Evaluierung: JasperReports, Thymeleaf + Flying Saucer, etc.
  4. Infrastructure Setup (Home-Server):
    • Hardware: Minisforum MS-R1 (ARM64, 12 Cores, 10G LAN) GELIEFERT (07.02.2026).
    • OS: Debian 12 (Vendor Variant) als Host.
    • Hypervisor: Proxmox VE 8.4.10 (pve.mo-code.at).
    • Virtualization Strategy:
      • infra-gitea (LXC Container): Gitea + Actions Runner (Native ARM Builds).
      • docker-host-prod (VM): Debian VM als Docker Host für den Meldestelle-Stack (Isolation, keine Nesting-Probleme).
    • CI/CD: Multi-Arch Support (Native ARM64 Builds + x86_64 via docker buildx & QEMU).
    • Networking: Cloudflare Tunnel (Remote Access).
    • Local Discovery: DNS/mDNS Strategie für Offline-Szenarien (Main-App als lokaler Anchor).
    • Backup: Automatisierte Snapshots auf externe USB-SSD.