stefan
aba5b5c7a0
Archived several outdated reports (`Ping-Service_Impl_01-2026.md`, `Frontend_Integration_Status.md`, etc.) and added archival notes and references to updated documents. Introduced a centralized reference structure for tech stack documentation, consolidating files under `01_Architecture/Reference/Tech_Stack`. Added new resources (`Gradle_Kotlin_DSL_Primer`, `Kotlin_2-3-0_ReleaseNotes`) for improved project organization and clarity.
76 lines
4.1 KiB
Markdown
76 lines
4.1 KiB
Markdown
---
|
|
type: Report
|
|
status: ARCHIVED
|
|
owner: Lead Architect
|
|
date: 2026-01-17
|
|
tags: [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*
|