--- name: Swift iOS App Nachbau overview: Vollständiger Implementierungsplan für den Nachbau des React-Web-Frontends (frontend_nyla) als native Swift/SwiftUI iOS/iPadOS-App. Die App kommuniziert mit dem bestehenden FastAPI-Gateway-Backend und bildet alle UI-Screens, Navigation und API-Schnittstellen nach. todos: - id: phase-0 content: "Phase 0: Xcode-Projekt erstellen, Ordnerstruktur, SPM-Dependencies, Build-Configs (Dev/Int/Prod)" status: pending - id: phase-1 content: "Phase 1: Core Networking Layer -- APIClient, SSEClient, WebSocketClient, CSRFManager (analog api.ts + sseClient.ts)" status: pending - id: phase-2 content: "Phase 2: Authentication -- LocalAuth, MSAL, Google, Biometrie, Keychain (analog authApi.ts + AuthProvider.tsx)" status: pending - id: phase-3 content: "Phase 3: Domain Models + FeatureStore (analog mandate.ts + featureStore.tsx)" status: pending - id: phase-4 content: "Phase 4: App Shell -- NavigationSplitView (iPad) / TabView (iPhone), Dashboard, Settings, backend-driven Sidebar" status: pending - id: phase-5 content: "Phase 5: i18n String Catalogs (de/en/fr) + Theme System (Light/Dark)" status: pending - id: phase-6 content: "Phase 6: Core Pages -- Store, GDPR, Basedata (Prompts/Files/Connections), Billing Transactions" status: pending - id: phase-7 content: "Phase 7: Shared UI Components -- FormGenerator, ContentPreview, ChatMessage, AccessRules, NotificationBell" status: pending - id: phase-8 content: "Phase 8: Push Notifications (APNs Registration, Deep-Link Handling)" status: pending - id: phase-9 content: "Phase 9: Admin Module -- alle 16 Admin-Seiten (Mandates, Users, RBAC, Invitations, Wizards, etc.)" status: pending - id: phase-10 content: "Phase 10: Feature Trustee -- Dashboard, Documents, Positions, Roles, Expense-Import, Scan, Accounting" status: pending - id: phase-11 content: "Phase 11: Feature Workspace -- Chat-Streaming (SSE), Files, Datasources, Voice" status: pending - id: phase-12 content: "Phase 12: Feature Chatbot -- SSE-Streaming Chat, Threads, Conversations" status: pending - id: phase-13 content: "Phase 13: Feature Teamsbot -- Sessions, WebSocket Bot-Kommunikation, Voice, MFA" status: pending - id: phase-14 content: "Phase 14: Feature CommCoach -- Coaching Sessions, Audio-Streaming, Personas, Dossier" status: pending - id: phase-15 content: "Phase 15: Feature ChatPlayground -- Workflows, Playground mit SSE-Stream" status: pending - id: phase-16 content: "Phase 16: Feature Automation -- Definitions, Templates, Logs, Execute" status: pending - id: phase-17 content: "Phase 17: Feature CodeEditor -- Editor mit SSE-Stream, Code-Anzeige, Apply" status: pending - id: phase-18 content: "Phase 18: Feature RealEstate/PEK -- MapKit-Integration, Parcels, Address-Search, BZO" status: pending - id: phase-19 content: "Phase 19: Feature Neutralization -- Config, Neutralize Text/File" status: pending - id: phase-20 content: "Phase 20: Billing-Erweiterung -- Admin-Views, Stripe Checkout" status: pending isProject: false --- # Nyla iOS/iPadOS App -- Vollständiger Implementierungsplan ## Ausgangslage Das bestehende Web-Frontend (`frontend_nyla`) ist eine **React 19 + Vite + TypeScript** Anwendung mit: - **12+ Feature-Module** (Trustee, Workspace, Chatbot, Teamsbot, CommCoach, CodeEditor, Automation, RealEstate, Neutralization, ChatPlayground, Billing, Admin) - **21 API-Module** unter `src/api/*.ts` mit insgesamt **200+ API-Endpunkten** - **120+ UI-Komponenten** inkl. dynamischem FormGenerator, ContentPreview, Chat-Streaming, Maps, Charts - **Multi-Tenant-Architektur**: Mandate > Features > Instanzen > Views/Permissions - **3 Auth-Provider**: Local, Microsoft MSAL, Google OAuth - **Echtzeit**: SSE-Streaming (Chat, Workspace, CodeEditor) + WebSockets (Voice) - **Backend**: FastAPI (Python) auf PostgreSQL, erreichbar unter konfigurierbarer `VITE_API_BASE_URL` --- ## Technische Entscheidungen | Aspekt | Entscheidung | | -------------------- | --------------------------------------------------- | | Plattform | iOS 18+ / iPadOS 18+ | | UI-Framework | SwiftUI | | Architektur | **MVVM + Repository Pattern** (s. unten) | | Networking | URLSession + async/await | | SSE | Custom SSE-Client auf URLSession-Basis | | WebSocket | URLSessionWebSocketTask | | Auth | MSAL SDK, Google Sign-In SDK, Keychain + Local Auth | | Biometrie | LocalAuthentication (Face ID / Touch ID) | | State | `@Observable` (Observation Framework, iOS 17+) | | Navigation | `NavigationStack` + `NavigationSplitView` (iPad) | | Dependency Injection | Environment-basiert (SwiftUI `@Environment`) | | Package Manager | Swift Package Manager (SPM) | | Karten | MapKit (SwiftUI) | | Charts | Swift Charts | | i18n | String Catalogs (`.xcstrings`) fuer de/en/fr | | Push | APNs + UserNotifications Framework | | PDF-Anzeige | PDFKit | | Markdown | Native AttributedString (iOS 15+) | | Persistenz | Keychain (Secrets), UserDefaults (Preferences) | | Distribution | TestFlight | ### Architektur: MVVM + Repository Pattern ``` Presentation Layer (SwiftUI Views) | v ViewModels (@Observable) | v Repositories (Protokolle) | v API Services (URLSession) | v Gateway Backend (FastAPI) ``` Begründung: SwiftUI ist nativ MVVM-orientiert. Das Repository Pattern kapselt die Datenzugriffe und macht den Code testbar. `@Observable` (iOS 17+) ist leichter als `ObservableObject` und performanter. ### Projektstruktur ``` NylaApp/ NylaApp.swift // App Entry Point Config/ AppConfig.swift // API URLs, Build Configs Environment.swift // Dev/Int/Prod Environments Core/ Networking/ APIClient.swift // Zentraler HTTP-Client (= api.ts) APIError.swift // Error Types APIEndpoints.swift // Endpoint Definitionen SSEClient.swift // Server-Sent Events Client WebSocketClient.swift // WebSocket Client CSRFManager.swift // CSRF Token Handling RequestInterceptor.swift // Auth/Mandate Headers Auth/ AuthManager.swift // Zentrale Auth-Logik LocalAuthService.swift // Username/Password MSALAuthService.swift // Microsoft MSAL GoogleAuthService.swift // Google Sign-In BiometricAuthService.swift // Face ID / Touch ID KeychainService.swift // Secure Storage Navigation/ AppRouter.swift // Root Navigation NavigationStore.swift // Backend-driven Nav State DeepLinkHandler.swift // URL Scheme Handling Localization/ Localizable.xcstrings // String Catalog LanguageManager.swift // Sprachauswahl Theme/ ThemeManager.swift // Light/Dark Mode DesignTokens.swift // Farben, Spacing, Fonts Permissions/ PermissionChecker.swift // RBAC Client-Checks Domain/ Models/ // Shared Domain Models Mandate.swift // Mandate, Feature, Instance User.swift // User Model Permissions.swift // AccessLevel, TablePermission Pagination.swift // PaginatedResponse I18nLabel.swift // Mehrsprachige Labels Repositories/ // Repository Protokolle AuthRepository.swift MandateRepository.swift FeatureRepository.swift ... Data/ API/ // API-Implementierungen (= src/api/*.ts) AuthAPI.swift UserAPI.swift MandateAPI.swift FeaturesAPI.swift BillingAPI.swift TrusteeAPI.swift ... (21 Module) Repositories/ // Repository Implementierungen DefaultAuthRepository.swift DefaultMandateRepository.swift ... Features/ // Feature-Module (je Ordner) Dashboard/ Store/ Settings/ GDPR/ Basedata/ Prompts/ Files/ Connections/ Billing/ Admin/ Mandates/ Users/ Access/ Invitations/ ... Trustee/ Workspace/ Chatbot/ Teamsbot/ CommCoach/ CodeEditor/ ChatPlayground/ Automation/ RealEstate/ Neutralization/ Shared/ Components/ // Wiederverwendbare UI (= src/components/) FormGenerator/ // Dynamische Formulare ContentPreview/ // PDF, Bild, JSON Vorschau ChatMessage/ // Chat-Nachrichten-Rendering AccessRules/ // Zugriffsregeln-Editor NotificationBell/ // Notification Badge + Overlay SearchBar/ LoadingView/ ErrorView/ EmptyStateView/ Extensions/ Utilities/ Resources/ Assets.xcassets ``` --- ## Phasen-Plan ### Phase 0: Projekt-Setup (1-2 Tage) - Xcode-Projekt erstellen (iOS 18+, SwiftUI App Lifecycle) - Ordnerstruktur nach obigem Schema anlegen - SPM Dependencies einrichten: - `MSAL` (Microsoft Authentication Library for iOS) - `GoogleSignIn` (Google Sign-In SDK) - Keine weiteren externen Deps noetig (MapKit, Charts, PDFKit sind System-Frameworks) - Build-Konfigurationen: **Dev** / **Int** / **Prod** mit je eigenem `API_BASE_URL` - Analog zu den `.env.dev` / `.env.int` / `.env.prod` Dateien im Web-Frontend - Werte: `http://localhost:8000` (Dev), INT-URL, PROD-URL - TestFlight-Vorbereitung: App ID, Provisioning Profile, Signing ### Phase 1: Core Networking Layer (3-5 Tage) **Ziel**: Equivalent zu `[src/api.ts](frontend_nyla/src/api.ts)` + `[src/hooks/useApi.ts](frontend_nyla/src/hooks/useApi.ts)` **APIClient.swift** -- Zentraler HTTP-Client: - `URLSession.shared` mit Custom-Configuration - Cookie-basierte Auth (`httpCookieStorage`) - Request-Interceptor fuer: - `Authorization: Bearer` Header (aus Keychain) - `X-Mandate-Id` / `X-Instance-Id` Header (aus aktuellem Navigation-Context) - CSRF-Token fuer POST/PUT/PATCH/DELETE - Response-Handler: - 401 -> Redirect zu Login (analog Web `api.ts` Zeile 127-151) - 429 -> Rate-Limit Warning - Generische Fehlerextraktion (FastAPI `detail` Array/String) - Generische Request-Methoden: `get()`, `post()`, `put()`, `delete()`, `upload()` - `Codable`-basierte JSON Serialisierung **SSEClient.swift** -- Server-Sent Events: - Analog zu `[src/utils/sseClient.ts](frontend_nyla/src/utils/sseClient.ts)` - URLSession mit `bytes(for:)` async stream - Parsing von `data:` Lines - Callbacks: `onMessage`, `onError`, `onComplete` - Wird benoetigt fuer: Workspace, Chatbot, CodeEditor, CommCoach Streaming **WebSocketClient.swift** -- WebSockets: - `URLSessionWebSocketTask` - Fuer Voice-Features (Teamsbot: `/api/teamsbot/{instanceId}/bot/ws/{sessionId}`) - Ping/Pong, Reconnect-Logik **CSRFManager.swift**: - Token-Generierung und -Speicherung - Analog zu `[src/utils/csrfUtils.ts](frontend_nyla/src/utils/csrfUtils.ts)` ### Phase 2: Authentication (3-5 Tage) **Ziel**: Alle 3 Auth-Provider + Biometrie **Mapping Web -> Swift:** | Web (authApi.ts) | Swift | | ---------------------------------------- | -------------------------------------------- | | `POST /api/local/login` (form-data) | `LocalAuthService.login(username:password:)` | | `POST /api/local/register` | `LocalAuthService.register(...)` | | `POST /api/local/password-reset-request` | `LocalAuthService.requestPasswordReset(...)` | | `POST /api/local/password-reset` | `LocalAuthService.resetPassword(...)` | | `GET /api/local/available?username=` | `LocalAuthService.checkAvailability(...)` | | `GET /api/local/me` | `AuthManager.fetchCurrentUser()` | | `POST /api/local/logout` | `AuthManager.logout()` | | MSAL Login/Callback | `MSALAuthService` via MSAL SDK | | `GET /api/msft/me` | `MSALAuthService.fetchUser()` | | Google Login/Callback | `GoogleAuthService` via Google Sign-In SDK | | `GET /api/google/me` | `GoogleAuthService.fetchUser()` | **AuthManager.swift** (zentral): - Verwaltet aktiven Auth-Provider (`local` / `msft` / `google`) - Speichert Auth-State in Keychain (nicht UserDefaults!) - Published `isAuthenticated`, `currentUser`, `authAuthority` - Analog zu `[src/providers/auth/AuthProvider.tsx](frontend_nyla/src/providers/auth/AuthProvider.tsx)` **BiometricAuthService.swift**: - `LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics)` - Nach erstem erfolgreichen Login: Credentials in Keychain speichern - Bei App-Start: Face ID/Touch ID -> Keychain Credentials -> Auto-Login **Login Screen (SwiftUI)**: - Username/Password Felder - "Anmelden mit Microsoft" Button (MSAL) - "Anmelden mit Google" Button (Google Sign-In) - "Face ID / Touch ID" Option (wenn verfuegbar) - Registrierung / Passwort vergessen Links - Analog zu `[src/pages/Login.tsx](frontend_nyla/src/pages/Login.tsx)` ### Phase 3: Domain Models + Feature Store (2-3 Tage) **Ziel**: Alle geteilten Datenmodelle + Feature-State Zentrale Models (analog zu `[src/types/mandate.ts](frontend_nyla/src/types/mandate.ts)`): ```swift // Mandate.swift struct I18nLabel: Codable { var de: String; var en: String; var fr: String? } enum AccessLevel: String, Codable { case none = "n", my = "m", group = "g", all = "a" } struct TablePermission: Codable { var view: Bool; var read, create, update, delete: AccessLevel } struct FieldPermission: Codable { var read: Bool; var write: Bool } struct InstancePermissions: Codable { var tables: [String: TablePermission]; var fields: [String: [String: FieldPermission]]?; var views: [String: Bool]; var isAdmin: Bool? } struct FeatureInstance: Codable, Identifiable { var id: String; var featureCode, mandateId, mandateName, instanceLabel: String; var userRoles: [String]; var permissions: InstancePermissions } struct MandateFeature: Codable { var code: String; var label: I18nLabel; var icon: String; var instances: [FeatureInstance] } struct Mandate: Codable, Identifiable { var id, name: String; var label, code: String?; var features: [MandateFeature] } struct FeaturesMyResponse: Codable { var mandates: [Mandate] } ``` **FeatureStore.swift** (analog zu `[src/stores/featureStore.tsx](frontend_nyla/src/stores/featureStore.tsx)`): - `@Observable class FeatureStore` - `loadFeatures()` -> `GET /api/features/my` - Cache: `[String: FeatureInstance]` fuer schnellen Zugriff - Methoden: `getMandateById()`, `getInstanceById()`, `getAllInstances()`, etc. - Injected via SwiftUI `@Environment` ### Phase 4: App Shell + Navigation (4-6 Tage) **Ziel**: MainLayout + FeatureLayout + backend-driven Navigation **Adaptive Layout:** - **iPad**: `NavigationSplitView` (Sidebar + Detail) -- analog Web-Sidebar - **iPhone**: `TabView` mit Hauptbereichen + Navigation Stack pro Tab **Sidebar / Navigation:** - Backend-driven: `GET /api/navigation?language={lang}` liefert Navigationsbaum - Analog zu `[src/components/Navigation/MandateNavigation.tsx](frontend_nyla/src/components/Navigation/MandateNavigation.tsx)` - Hierarchie: Mandate > Feature > Instance > Views - Icon-Mapping: SF Symbols statt React Icons (Mapping-Tabelle erstellen) **Screen-Routing:** - `NavigationStack` mit `NavigationPath` fuer programmatische Navigation - Deep-Link-Schema: `nyla://mandates/{mandateId}/{featureCode}/{instanceId}/{view}` - Feature-View-Dispatcher: analog zu `[src/pages/FeatureView.tsx](frontend_nyla/src/pages/FeatureView.tsx)` `VIEW_COMPONENTS` **Screens in Phase 4:** - Dashboard (`/`) -- Mandate/Instance-Karten, analog `[src/pages/Dashboard.tsx](frontend_nyla/src/pages/Dashboard.tsx)` - Settings (`/settings`) -- Theme-Toggle, Sprache (de/en/fr), Profil - UserSection im Sidebar-Footer ### Phase 5: i18n + Theme (2-3 Tage) **Internationalisierung:** - Xcode String Catalog (`.xcstrings`) fuer de/en/fr - Alle statischen Strings aus den Web-Locales uebernehmen: `[src/locales/de.ts](frontend_nyla/src/locales/de.ts)`, `en.ts`, `fr.ts` - Dynamische Labels (I18nLabel vom Backend): Helper `label.localized(lang:)` analog `getLabel()` im Web - `LanguageManager` speichert Praeferenz in UserDefaults **Theme:** - SwiftUI `.preferredColorScheme()` fuer System-Integration - Custom `DesignTokens` fuer konsistente Farben/Spacing - Analog zu `[src/styles/themes/light.css](frontend_nyla/src/styles/themes/light.css)` + `.dark-theme` ### Phase 6: Core Pages (5-7 Tage) **Store** (Feature Marketplace): - `GET /api/store/features` -> Feature-Liste - `POST /api/store/activate` / `POST /api/store/deactivate` - Analog `[src/pages/Store.tsx](frontend_nyla/src/pages/Store.tsx)` **GDPR**: - `GET /api/user/me/data-export` + `/data-portability` - `DELETE /api/user/me/` - Analog `[src/pages/GDPR.tsx](frontend_nyla/src/pages/GDPR.tsx)` **Basedata - Prompts** (`/basedata/prompts`): - CRUD auf `/api/prompts` mit FormGenerator - Analog `[src/pages/PromptsPage.tsx](frontend_nyla/src/pages/PromptsPage.tsx)` **Basedata - Files** (`/basedata/files`): - `GET /api/files/list`, Upload, Download, Preview - Analog `[src/pages/FilesPage.tsx](frontend_nyla/src/pages/FilesPage.tsx)` - Nutzung von `UIDocumentPickerViewController` (via UIKit-Bridge) fuer File-Upload - `QuickLook` fuer Dateivorschau **Basedata - Connections** (`/basedata/connections`): - CRUD auf `/api/connections/` - Connect/Disconnect Aktionen - Analog `[src/pages/ConnectionsPage.tsx](frontend_nyla/src/pages/ConnectionsPage.tsx)` **Billing** (`/billing/transactions`): - `GET /api/billing/balance`, `/transactions`, `/statistics/{period}` - Swift Charts fuer Statistik-Visualisierung - Analog `[src/pages/billing/BillingDataView.tsx](frontend_nyla/src/pages/billing/BillingDataView.tsx)` ### Phase 7: Shared UI Components (5-8 Tage) **FormGenerator** (zentral, wird von fast allen Features genutzt): - Analog zu `[src/components/FormGenerator/](frontend_nyla/src/components/FormGenerator/)` - Dynamische Formulare basierend auf `AttributeDefinition[]` vom Backend (`GET /api/attributes/{entityType}`) - Feldtypen: String, Email, Select, Multiselect, Textarea, Checkbox, File, Number, DateTime, Multilingual - Tabellen-Ansicht (`FormGeneratorTable`) + Listen-Ansicht (`FormGeneratorList`) - Action Buttons (Edit, Delete, Download, Custom) - Pagination-Support **ContentPreview**: - PDF: `PDFKitView` (UIKit PDFView in UIViewRepresentable) - Bilder: AsyncImage - JSON: Syntax-Highlighting - HTML: WKWebView - Analog `[src/components/ContentPreview/](frontend_nyla/src/components/ContentPreview/)` **NotificationBell**: - `GET /api/notifications/unread-count` (Polling) - Push Notifications via APNs - In-App Notification Sheet - Analog `[src/components/NotificationBell/](frontend_nyla/src/components/NotificationBell/)` **Chat Message Components**: - Message-Bubbles mit Markdown-Rendering - File-Attachments - Streaming-Indicator (typing animation) - Auto-Scroll - Analog `[src/components/UiComponents/Messages/](frontend_nyla/src/components/UiComponents/Messages/)` **AccessRules Components**: - Tabelle + Editor fuer RBAC-Regeln - Analog `[src/components/AccessRules/](frontend_nyla/src/components/AccessRules/)` ### Phase 8: Push Notifications (2-3 Tage) - APNs-Registrierung in `AppDelegate` - Device Token an Backend senden (neuer Endpoint oder bestehender `/api/messaging/subscriptions`) - `UNUserNotificationCenter` fuer lokale + remote Notifications - Deep-Link Handling aus Notification-Tap ### Phase 9: Admin Module (5-7 Tage) Alle Admin-Seiten analog zu `[src/pages/admin/](frontend_nyla/src/pages/admin/)`: | Admin-Seite | API-Endpunkte | | -------------------- | ------------------------------------------ | | Mandates | CRUD `/api/mandates/` | | Users | CRUD `/api/users/` | | User-Mandates | `/api/mandates/{id}/users` | | Access Hub | `/api/rbac/permissions`, `/api/rbac/rules` | | Feature Instances | `/api/features/instances` | | Feature Roles | `/api/features/templates/roles` | | Feature Users | `/api/features/instances/{id}/users` | | Invitations | CRUD `/api/invitations/` | | Mandate Roles | `/api/rbac/roles` | | Role Permissions | `/api/rbac/rules/by-role/{roleId}` | | User Access Overview | `/api/admin/user-access-overview/`* | | Billing Admin | `/api/billing/admin/`* | | Automation Events | `/api/admin/automation-events` | | Logs | `/api/admin/logs` | | Mandate Wizard | Kombination mehrerer Endpoints | | Invitation Wizard | Kombination mehrerer Endpoints | ### Phase 10-20: Feature-Module (je 3-7 Tage pro Feature) Jedes Feature folgt demselben Pattern: 1. **API-Modul** erstellen (alle Endpunkte des Features) 2. **ViewModels** fuer jede View 3. **SwiftUI Views** fuer jede registrierte View 4. **Feature-spezifische Komponenten** wo noetig --- #### Phase 10: Trustee (5-7 Tage) Views: Dashboard, Documents, Positions, Instance-Roles, Expense-Import, Scan-Upload, Accounting Settings API-Basis: `/api/trustee/{instanceId}/` - Organisations, Roles, Access, Contracts, Documents, Positions CRUD - Accounting: Connectors, Config, Sync - Document Upload mit base64-Konvertierung - Options-Endpoints fuer Dropdowns Besonderheiten: - Viele verschachtelte CRUD-Entitaeten (Organisation > Contract > Document > Position) - Scan-Upload: iOS-Kamera-Integration + VisionKit (OCR) #### Phase 11: Workspace (5-7 Tage) Views: Dashboard (Chat-Stream), Settings API-Basis: `/api/workspace/{instanceId}/` - SSE-Streaming fuer Chat (`POST .../start/stream`) - Workflows, Messages, Files, Datasources CRUD - Voice: Transcribe, Synthesize, Settings - File Browser mit Ordnerstruktur Besonderheiten: - **Zentrales SSE-Streaming** -- das Keep-Alive-Pattern aus dem Web (`WorkspaceKeepAlive`) muss in Swift via Task/Actor geloest werden - Voice: AVFoundation fuer Audio-Aufnahme, URLSession fuer Upload #### Phase 12: Chatbot (3-5 Tage) Views: Conversations, Settings API-Basis: `/api/chatbot/{instanceId}/` - `POST .../start/stream` -- SSE-Streaming via fetch (nicht Axios!) - Threads: List, Get, Delete - Stop Workflow Besonderheiten: - Streaming-Chat mit File-Attachments - Analog zu `chatbotApi.startChatbotStreamApi` -- Custom SSE via POST #### Phase 13: Teamsbot (4-6 Tage) Views: Dashboard, Sessions, Settings API-Basis: `/api/teamsbot/{instanceId}/` - Sessions CRUD + Stream (EventSource/SSE) - Config, System Bots, User Account - Voice Test - MFA fuer Sessions - WebSocket fuer Bot-Kommunikation (`/bot/ws/{sessionId}`) Besonderheiten: - **WebSocket** fuer Live-Bot-Interaction - SSE via EventSource fuer Session-Stream - Screenshot-Anzeige #### Phase 14: CommCoach (4-6 Tage) Views: Dashboard, Coaching, Dossier, Settings API-Basis: `/api/commcoach/{instanceId}/` - Contexts CRUD + Archive/Activate - Sessions: Start, Message-Stream, Audio-Stream, Complete, Cancel - Tasks CRUD + Status - Personas CRUD, Documents, Badges, Score History - Voice: Languages, Voices, TTS - Export (Dossier, Session) Besonderheiten: - **Audio-Streaming**: Mikrofon-Aufnahme -> POST Audio-Stream - SSE fuer Session-Nachrichten - Score/Badge-Visualisierung #### Phase 15: ChatPlayground (3-5 Tage) Views: Playground, Workflows API-Basis: `/api/chatplayground/{instanceId}/` - Start/Stop Workflow (mit SSE-Stream) - Workflows CRUD + Status/Logs/Messages - Attributes, Actions #### Phase 16: Automation (3-5 Tage) Views: Definitions, Templates, Logs API-Basis: `/api/automations/` - Automations CRUD + Execute + Duplicate - Templates CRUD - Workflow-Management (gleiche API wie ChatPlayground, anderer Base-Path) #### Phase 17: CodeEditor (3-5 Tage) Views: Editor, Workflows API-Basis: `/api/codeeditor/{instanceId}/` - Start/Stop/Apply (mit SSE-Stream) - ChatData, Workflows, Files, File Content Besonderheiten: - Code-Darstellung: Syntax-Highlighting (z.B. via `Highlightr` SPM Package oder custom) - Diff-Ansicht fuer Code-Apply #### Phase 18: RealEstate / PEK (5-7 Tage) Views: Dashboard (Map), Instance-Roles API-Basis: `/api/realestate/{instanceId}/` - Projects + Parcels CRUD - Parcel Search, WFS, Selection Summary, Adjacent Parcels - Address Autocomplete - BZO Information, Parcel Documents - Gemeinden Besonderheiten: - **MapKit** Integration: Parcel-Visualisierung auf Karte - Address-Autocomplete: MKLocalSearchCompleter oder Backend-API - Komplexe Karteninteraktion (Parcel-Selektion, Adjacent Parcels) #### Phase 19: Neutralization (2-3 Tage) Views: Dashboard/Playground (gleiche View) API-Basis: `/api/neutralization/` - Config GET/POST - Neutralize File/Text, Resolve Text - Process SharePoint, Batch Process - Stats, Attributes #### Phase 20: Billing View-Erweiterung (1-2 Tage) Admin-Billing-Views falls in Phase 9 nicht vollstaendig abgedeckt: - Checkout (Stripe -- SFSafariViewController fuer Redirect) - Mandate/User Balances und Transaktionen --- ## API-Header-Konvention (fuer alle Requests) Jeder API-Request muss folgende Header senden (analog `[src/api.ts](frontend_nyla/src/api.ts)`): | Header | Quelle | Wann | | -------------------------------- | ------------------ | --------------------- | | `Authorization: Bearer {token}` | Keychain | Wenn JWT vorhanden | | `X-Mandate-Id: {mandateId}` | Navigation Context | Bei Feature-Seiten | | `X-Instance-Id: {instanceId}` | Navigation Context | Bei Feature-Seiten | | `X-CSRF-Token: {token}` | CSRFManager | POST/PUT/PATCH/DELETE | | `Content-Type: application/json` | Standard | JSON Bodies | | Cookie (httpOnly) | URLSession | Automatisch | --- ## Gesamtaufwand-Schaetzung | Phase | Tage (geschaetzt) | | ------------------------------- | ----------------- | | Phase 0: Setup | 1-2 | | Phase 1: Networking | 3-5 | | Phase 2: Authentication | 3-5 | | Phase 3: Domain Models + Store | 2-3 | | Phase 4: App Shell + Navigation | 4-6 | | Phase 5: i18n + Theme | 2-3 | | Phase 6: Core Pages | 5-7 | | Phase 7: Shared UI Components | 5-8 | | Phase 8: Push Notifications | 2-3 | | Phase 9: Admin | 5-7 | | Phase 10: Trustee | 5-7 | | Phase 11: Workspace | 5-7 | | Phase 12: Chatbot | 3-5 | | Phase 13: Teamsbot | 4-6 | | Phase 14: CommCoach | 4-6 | | Phase 15: ChatPlayground | 3-5 | | Phase 16: Automation | 3-5 | | Phase 17: CodeEditor | 3-5 | | Phase 18: RealEstate | 5-7 | | Phase 19: Neutralization | 2-3 | | Phase 20: Billing Erweit. | 1-2 | | **Gesamt** | **~70-105 Tage** | Hinweis: Dies ist eine Einzelperson-Schaetzung. Mit Team (z.B. 2-3 Devs) kann parallelisiert werden, besonders ab Phase 10+ (Features sind unabhaengig voneinander). --- ## Offene Punkte / Risiken 1. **Backend-Anpassungen**: Das Backend setzt teilweise httpOnly Cookies nach Browser-Redirect (MSAL, Google). Fuer eine native App muss das Backend ggf. alternative Token-Flows unterstuetzen (z.B. Device Code Flow oder Token-Exchange). 2. **Push Notifications**: Das Backend hat aktuell kein APNs-Token-Management. Ein neuer Endpoint `/api/notifications/register-device` muss im Gateway implementiert werden. 3. **SSE ueber POST**: Die Web-App nutzt `fetch` POST + ReadableStream fuer SSE (nicht standard EventSource GET). In Swift muss dies mit `URLSession.bytes(for:)` nachgebaut werden. 4. **Stripe Checkout**: Im Web oeffnet sich ein Stripe-Redirect. In iOS: SFSafariViewController oder Stripe iOS SDK. 5. **SharePoint Integration**: Einige Features nutzen SharePoint-Folder-Picker. In iOS muss eine alternative UI gebaut werden (Liste statt Filepicker). 6. **WebSocket Auth**: Der Web-Client nutzt Cookies fuer WebSocket-Auth. iOS `URLSessionWebSocketTask` unterstuetzt Cookies via URLSession Configuration.