mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
df5276abf2
meldestelle/docs/90_Reports/_archive/2026-01-17_LeadArchitect_Handover.md
StefanMoCoAt c51773a4c7 chore(docs+infra): update roadmap, improve home server plan, and archive outdated reports 
- Adjusted infrastructure roadmap to use VM instead of nested LXC for Docker hosting, enhancing isolation and compatibility.
- Clarified multi-architecture CI/CD setup with native ARM64 builds and QEMU-based x86_64 builds.
- Updated documentation to include backup and offline-first strategies.
- Archived outdated session logs and reports for better file organization.
2026-02-06 20:49:47 +01:00

4.1 KiB
Raw Blame History

type status owner date tags
Report ARCHIVED Lead Architect 2026-01-17
architecture
handover
critique
roadmap

🏗️ Lead Architect Status Report & Handover

ARCHIVED: This report reflects a past state. Please refer to 2026-01-23_Weekend_Status_Report.md for the current status.

Datum: 17. Jänner 2026 Status: 🟡 PARTIALLY BLOCKED (Frontend Architecture Split) Ziel: Abschluss "Trace Bullet" (Ping Feature mit Auth, Sync & Tracing)

1. Executive Summary

Der technische Durchstich ist zu 85% erfolgreich.

  • ✅ Backend & Infrastructure: Exzellent. Zipkin läuft, Endpunkte (/ping/sync) sind deployt und sicher.
  • ⚠️ Frontend: Kritischer Architektur-Bruch. Es existieren zwei parallele Implementierungen des PingViewModel. Die UI nutzt die alte Version (ohne Sync), während die neue Version (mit Sync) isoliert und ungenutzt ist.

2. Kritik & Prozessoptimierung (Collaboration Review)

Um solche "Split-Brain"-Situationen künftig zu vermeiden, ordne ich folgende Prozessänderungen an:

  1. Definition of Done (DoD) Schärfung:

    • Ein Feature gilt nicht als "Done", wenn der Code existiert, sondern erst, wenn er in der MainApp verdrahtet und für den User erreichbar ist.
    • Fehler heute: Der Frontend Expert hat PingEventRepository und ein neues ViewModel gebaut, aber die UI (PingScreen) nicht darauf umgestellt.

  2. Architektur-Konsistenz (Single Source of Truth):

    • Wir haben aktuell Mischbetrieb zwischen at.mocode.clients.* (Legacy/Simple) und at.mocode.ping.feature.* (Clean Arch).
    • Entscheidung: Wir migrieren schrittweise zu Clean Arch, aber bestehende Features müssen funktional bleiben. Keine "Ghost-Klassen" erstellen, die niemand aufruft.

  3. Cross-Functional Verification:

    • Der Backend Developer muss künftig verifizieren, ob seine neuen Endpunkte (z.B. /ping/sync) tatsächlich Traffic erhalten (via Zipkin/Logs), bevor das Ticket geschlossen wird.

3. Arbeitsaufträge (Chronologisch)

A. @Frontend Expert (Priorität: HOCH)

Aufgabe: Behebung der ViewModel-Fragmentierung.

  1. Merge: Integriere die Logik aus at.mocode.ping.feature.presentation.PingViewModel (Sync-Trigger) in das aktiv genutzte at.mocode.clients.pingfeature.PingViewModel.
  2. UI Integration: Erweitere den PingScreen um einen "Sync Now"-Button oder eine Statusanzeige, die den SyncManager Status reflektiert.
  3. Cleanup: Lösche das ungenutzte ViewModel in at.mocode.ping.feature.presentation, um Verwirrung zu vermeiden.
  4. Wiring: Stelle sicher, dass das PingEventRepositoryImpl korrekt via Koin in das konsolidierte ViewModel injiziert wird.

B. @Infrastructure & DevOps (Priorität: MITTEL)

Aufgabe: Verifizierung der Observability Kette.

  1. Sobald das Frontend den Fix (A) geliefert hat: Prüfe im Zipkin UI (Port 9411), ob ein Trace sichtbar ist, der vom web-app Container über das api-gateway bis zum ping-service und zur DB reicht.
  2. Falls Traces abbrechen: Prüfe die Header-Propagation (b3 Header) im Ktor Client.

C. @QA Specialist (Priorität: MITTEL)

Aufgabe: End-to-End Test "Offline Sync".

  1. Szenario: App starten -> Login -> Daten laden -> Netzwerk trennen -> Daten ändern (wenn möglich) -> Netzwerk verbinden -> Sync prüfen.
  2. Da wir aktuell nur "Read-Sync" (Server to Client) beim Ping haben: Prüfe, ob neue Pings vom Server nach Klick auf "Sync" in der lokalen DB landen.

D. @Curator (Priorität: NIEDRIG)

Aufgabe: Dokumentation der Architektur-Entscheidung.

  1. Aktualisiere docs/01_Architecture/02_Frontend_Architecture.md.
  2. Dokumentiere den Beschluss: "Features werden sukzessive in Module (features/) ausgelagert. Während der Transition darf Code im clients/-Package verbleiben, muss aber die neuen Module nutzen (Dependency Injection)."

4. Abschluss

Der "Trace Bullet" ist technisch valide, scheitert aber auf den letzten Metern der Integration. Sobald der Frontend Expert den Merge vollzogen hat, ist Phase 1 des Projekts Meldestelle offiziell abgeschlossen.

Lead Architect End of Report