mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0ebcfaa3b7
meldestelle/docs/01_Architecture/MASTER_ROADMAP_2026_Q1.md
StefanMoCoAt c50acd641e chore(docs+infra): add hardware setup logs, guidelines, and Minisforum MS-R1 documentation 
- Updated `MASTER_ROADMAP_2026_Q1.md` to reflect delivery of Minisforum MS-R1 hardware and progress on infrastructure setup.
- Added detailed documentation for Minisforum MS-R1, including specifications, host OS setup guide, and service configuration guide.
- Logged DevOps setup session and curator's session with focus on hardware integration, SSH hardening, and networking adjustments (Macvlan workaround).
- Included user manual for Minisforum MS-R1 and related assets (e.g., images).
2026-02-08 01:27:28 +01:00

4.1 KiB
Raw Blame History

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: Incus (LXC/LXD Fork).
    • 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.