tooling: make .junie/.gemini docs-first (remove legacy guidelines)
This commit is contained in:
@@ -0,0 +1,76 @@
|
||||
Repository-Architektur (MP-22)
|
||||
|
||||
Dieses Dokument beschreibt die Zielstruktur und das Mapping vom bisherigen Stand (Ist) zur neuen Struktur (Soll). Es begleitet Epic 2 (MP-22).
|
||||
|
||||
Zielstruktur (Top-Level)
|
||||
|
||||
backend/ Gateway, Discovery (optional), Services
|
||||
gateway
|
||||
discovery
|
||||
services
|
||||
frontend/ KMP Frontend
|
||||
shells Ausführbare Apps (Assembler)
|
||||
features Vertical Slices (kein Feature→Feature)
|
||||
core Shared Foundation (Design-System, Network, Local-DB, Auth, Domain)
|
||||
design-system
|
||||
domain
|
||||
network
|
||||
local-db
|
||||
navigation
|
||||
docker/ Docker Compose, .env.example, Monitoring-/Core-Konfiguration
|
||||
docs/ Architektur, ADRs, C4-Modelle, Guides
|
||||
adr Architecture Decision Records (ADRs)
|
||||
c4 C4-Diagramme (PlantUML Quellen)
|
||||
|
||||
Ist → Soll Mapping (erste Tranche)
|
||||
|
||||
- Frontend
|
||||
- clients/app → frontend/shells/meldestelle-portal (verschieben in Folge-Commit)
|
||||
- clients/shared/common-ui → frontend/core/design-system (verschieben in Folge-Commit)
|
||||
- clients/shared/navigation → frontend/core/navigation (verschieben in Folge-Commit)
|
||||
|
||||
- Backend
|
||||
- infrastructure/gateway → backend/gateway (verschieben in Folge-Commit)
|
||||
- services/* → backend/services/* (verschieben in Folge-Commit)
|
||||
- Discovery (falls genutzt) → backend/discovery
|
||||
|
||||
- Docker
|
||||
- compose.yaml → docker/docker-compose.yml (neu angelegt, Makefile angepasst)
|
||||
- .env Handling → docker/.env.example (neu, als Template)
|
||||
|
||||
Build/Gradle
|
||||
|
||||
- settings.gradle.kts bleibt vorerst unverändert. Modul-Verschiebungen folgen in einem separaten Schritt mit angepassten include-Pfaden.
|
||||
- Version Catalog (gradle/libs.versions.toml) bleibt die einzige Quelle der Versionswahrheit.
|
||||
|
||||
Richtlinien (Kurzfassung)
|
||||
|
||||
- Features kommunizieren ausschließlich über Routen (Navigation) und Shared-Modelle in frontend/core/domain.
|
||||
- Kein manueller Authorization-Header – nur der DI-verwaltete apiClient aus frontend/core/network (Koin Named Binding).
|
||||
- SQLDelight als Offline-SSoT: Schema/Migrationen zentral versionieren, UI liest stets lokal und synchronisiert im Hintergrund.
|
||||
|
||||
DI-Policy & Architecture Guards (MP-23)
|
||||
|
||||
- DI-Policy (Frontend)
|
||||
- Http‑Requests erfolgen ausschließlich über den via Koin bereitgestellten `apiClient` (named Binding) aus `:frontend:core:network`.
|
||||
- Manuelles Setzen des `Authorization`‑Headers ist verboten. Token‑Handling wird zentral im `apiClient` konfiguriert (Auth‑Plugin/Interceptor).
|
||||
- Basis‑URL wird plattformspezifisch aufgelöst:
|
||||
- JVM/Desktop: Env `API_BASE_URL` (Fallback `http://localhost:8081`).
|
||||
- Web/JS: `globalThis.API_BASE_URL` (z. B. per `index.html` oder Proxy), sonst `window.location.origin`, Fallback `http://localhost:8081`.
|
||||
|
||||
- Architecture Guards (Frontend‑Scope)
|
||||
- Root‑Task `archGuards` bricht den Build ab, wenn verbotene Muster gefunden werden (manuelle `Authorization`‑Header). Tests sind ausgenommen; Backend ist ausgenommen.
|
||||
- Statische Analyse verfügbar über `detekt` und `ktlintCheck`; Aggregator `staticAnalysis` führt alles zusammen.
|
||||
|
||||
- Hinweise für Features
|
||||
- Features importieren keine anderen Features (Kommunikation über Navigation + Shared‑Domain‑Modelle). Eine explizite Detekt‑Regel folgt.
|
||||
- Netzwerkzugriffe in Features nutzen Koin über die App‑Shell (DI‑Bootstrap). Für schrittweise Migration kann eine Factory den `apiClient` optional beziehen.
|
||||
|
||||
Nächste Schritte (MP-22 Folgetasks)
|
||||
|
||||
1. Physisches Verschieben der Frontend-Module gemäß Mapping und Anpassung von settings.gradle.kts.
|
||||
2. Physisches Verschieben der Backend-Komponenten in backend/* inkl. evtl. Package-Pfade, sofern notwendig.
|
||||
3. Ergänzung von docker-compose.services.yml und docker-compose.clients.yml mit echten Overlays.
|
||||
4. Erstellen der ersten ADRs unter docs/adr (Koin, SQLDelight, Optimistic Locking, Freshness UI, Core Domain).
|
||||
|
||||
Hinweis: ADRs liegen ab sofort zentral unter `docs/adr/` (nicht mehr unter `docs/architecture/adr/`). C4-Diagramme wurden nach `docs/c4/` verschoben.
|
||||
Reference in New Issue
Block a user