Stephan Schellworth ea566c270f docs: add gateway docs and Cursor plan artifacts

Made-with: Cursor

2026-04-22 07:21:43 +02:00

29 KiB

Raw Blame History

name

overview

todos

isProject

Swift iOS App Nachbau

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.

id	content	status
phase-0	Phase 0: Xcode-Projekt erstellen, Ordnerstruktur, SPM-Dependencies, Build-Configs (Dev/Int/Prod)	pending

id	content	status
phase-1	Phase 1: Core Networking Layer -- APIClient, SSEClient, WebSocketClient, CSRFManager (analog api.ts + sseClient.ts)	pending

id	content	status
phase-2	Phase 2: Authentication -- LocalAuth, MSAL, Google, Biometrie, Keychain (analog authApi.ts + AuthProvider.tsx)	pending

id	content	status
phase-3	Phase 3: Domain Models + FeatureStore (analog mandate.ts + featureStore.tsx)	pending

id	content	status
phase-4	Phase 4: App Shell -- NavigationSplitView (iPad) / TabView (iPhone), Dashboard, Settings, backend-driven Sidebar	pending

id	content	status
phase-5	Phase 5: i18n String Catalogs (de/en/fr) + Theme System (Light/Dark)	pending

id	content	status
phase-6	Phase 6: Core Pages -- Store, GDPR, Basedata (Prompts/Files/Connections), Billing Transactions	pending

id	content	status
phase-7	Phase 7: Shared UI Components -- FormGenerator, ContentPreview, ChatMessage, AccessRules, NotificationBell	pending

id	content	status
phase-8	Phase 8: Push Notifications (APNs Registration, Deep-Link Handling)	pending

id	content	status
phase-9	Phase 9: Admin Module -- alle 16 Admin-Seiten (Mandates, Users, RBAC, Invitations, Wizards, etc.)	pending

id	content	status
phase-10	Phase 10: Feature Trustee -- Dashboard, Documents, Positions, Roles, Expense-Import, Scan, Accounting	pending

id	content	status
phase-11	Phase 11: Feature Workspace -- Chat-Streaming (SSE), Files, Datasources, Voice	pending

id	content	status
phase-12	Phase 12: Feature Chatbot -- SSE-Streaming Chat, Threads, Conversations	pending

id	content	status
phase-13	Phase 13: Feature Teamsbot -- Sessions, WebSocket Bot-Kommunikation, Voice, MFA	pending

id	content	status
phase-14	Phase 14: Feature CommCoach -- Coaching Sessions, Audio-Streaming, Personas, Dossier	pending

id	content	status
phase-15	Phase 15: Feature ChatPlayground -- Workflows, Playground mit SSE-Stream	pending

id	content	status
phase-16	Phase 16: Feature Automation -- Definitions, Templates, Logs, Execute	pending

id	content	status
phase-17	Phase 17: Feature CodeEditor -- Editor mit SSE-Stream, Code-Anzeige, Apply	pending

id	content	status
phase-18	Phase 18: Feature RealEstate/PEK -- MapKit-Integration, Parcels, Address-Search, BZO	pending

id	content	status
phase-19	Phase 19: Feature Neutralization -- Config, Neutralize Text/File	pending

id	content	status
phase-20	Phase 20: Billing-Erweiterung -- Admin-Views, Stripe Checkout	pending

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<T>
      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<T>(), post<T>(), put<T>(), delete<T>(), 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)):

// 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

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:

API-Modul erstellen (alle Endpunkte des Features)
ViewModels fuer jede View
SwiftUI Views fuer jede registrierte View
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

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).
Push Notifications: Das Backend hat aktuell kein APNs-Token-Management. Ein neuer Endpoint /api/notifications/register-device muss im Gateway implementiert werden.
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.
Stripe Checkout: Im Web oeffnet sich ein Stripe-Redirect. In iOS: SFSafariViewController oder Stripe iOS SDK.
SharePoint Integration: Einige Features nutzen SharePoint-Folder-Picker. In iOS muss eine alternative UI gebaut werden (Liste statt Filepicker).
WebSocket Auth: Der Web-Client nutzt Cookies fuer WebSocket-Auth. iOS URLSessionWebSocketTask unterstuetzt Cookies via URLSession Configuration.

29 KiB Raw Blame History

Nyla iOS/iPadOS App -- Vollständiger Implementierungsplan

Ausgangslage

Technische Entscheidungen

Architektur: MVVM + Repository Pattern

Projektstruktur

Phasen-Plan

Phase 0: Projekt-Setup (1-2 Tage)

Phase 1: Core Networking Layer (3-5 Tage)

Phase 2: Authentication (3-5 Tage)

Phase 3: Domain Models + Feature Store (2-3 Tage)

Phase 4: App Shell + Navigation (4-6 Tage)

Phase 5: i18n + Theme (2-3 Tage)

Phase 6: Core Pages (5-7 Tage)

Phase 7: Shared UI Components (5-8 Tage)

Phase 8: Push Notifications (2-3 Tage)

Phase 9: Admin Module (5-7 Tage)

Phase 10-20: Feature-Module (je 3-7 Tage pro Feature)

Phase 10: Trustee (5-7 Tage)

Phase 11: Workspace (5-7 Tage)

Phase 12: Chatbot (3-5 Tage)

Phase 13: Teamsbot (4-6 Tage)

Phase 14: CommCoach (4-6 Tage)

Phase 15: ChatPlayground (3-5 Tage)

Phase 16: Automation (3-5 Tage)

Phase 17: CodeEditor (3-5 Tage)

Phase 18: RealEstate / PEK (5-7 Tage)

Phase 19: Neutralization (2-3 Tage)

Phase 20: Billing View-Erweiterung (1-2 Tage)

API-Header-Konvention (fuer alle Requests)

Gesamtaufwand-Schaetzung

Offene Punkte / Risiken

29 KiB

Raw Blame History