docs: add Lead Architect handover report and recommendations
Added a detailed report for the Lead Architect handover summarizing key challenges, process critiques, and roadmap adjustments. Included specific tasks for team members to resolve architectural inconsistencies, improve feature integration, and enhance observability.
This commit is contained in:
@@ -0,0 +1,71 @@
|
||||
---
|
||||
type: Report
|
||||
status: ACTION_REQUIRED
|
||||
owner: Lead Architect
|
||||
date: 2026-01-17
|
||||
tags: [architecture, handover, critique, roadmap]
|
||||
---
|
||||
|
||||
# 🏗️ Lead Architect Status Report & Handover
|
||||
|
||||
**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*
|
||||
Reference in New Issue
Block a user