Architektur-Journal: Blueprint-Migration - ZNS Import Feature

Datum: 19. April 2026 Agent: 🏗️ [Lead Architect] | 🎨 [Frontend Expert]

🎯 Status-Update

Das Modul frontend/features/zns-import-feature wurde erfolgreich auf den neuen Module Architecture Blueprint (Klasse B: UI_COMPONENT) migriert.

🛠️ Durchgeführte Änderungen

1. Gradle-Konfiguration (`build.gradle.kts`)

Group-ID: Geändert von at.mocode.clients auf at.mocode.frontend.features.
KMP-Alignment:
- wasmJsMain Source-Set hinzugefügt und mit kotlin.stdlib.wasm.js konfiguriert.
- Abhängigkeiten von jvmMain nach commonMain verschoben, um die Logik plattformunabhängig verfügbar zu machen (Klasse B Anforderung).
- compose.uiTooling zu jvmMain hinzugefügt für IDE-Previews.

2. Strukturelle Begradigung & KMP-Refactoring

Die Verzeichnisstruktur wurde auf den neuen Standard-Namensraum at.mocode.frontend.features.zns.import umgestellt.
KMP-Shift: Das ZnsImportViewModel wurde nach commonMain verschoben. Die Datei-Logik wurde von java.io.File entkoppelt und nutzt nun ByteArray für den Datei-Upload, was die Plattformunabhängigkeit erhöht.
UI-Separation:
- StammdatenImportScreen in jvmMain nutzt weiterhin Swing (JFileChooser) für die Dateiauswahl auf dem Desktop.
- Ein Skelett-Screen wurde in wasmJsMain erstellt, um die "Consistency Rule" zu erfüllen und Web-Kompatibilität (mit Platzhalter) zu signalisieren.
Dependency Injection: Redundante Factory-Definitionen in ZnsImportModule.kt wurden bereinigt.

3. Shell-Integration

Die Importe und Aufrufe in der Desktop-Shell (frontend/shells/meldestelle-desktop) wurden auf den neuen Namensraum aktualisiert.

⚖️ Konformitäts-Check

Rule 1 (Dependency Direction): Gewahrt.
Rule 3 (Consistency Rule): wasmJsMain Struktur ist vorhanden.
Taxonomie: Klasse B (UI_COMPONENT) erfolgreich angewendet.

🚀 Nächste Schritte

Fortsetzung der Migration mit weiteren Feature-Modulen.
Langfristig: Refactoring von ZnsImportViewModel zur Nutzung von KMP-konformen Datei-APIs.

2.1 KiB Raw Blame History