PolyTraderSharp/docs/umsetzungsplaene/UMSETZUNGSPLAN-Modularisierung.md

Umsetzungsplan: Modularisierung PolyTraderSharp

Stand: 22.08.2026 — Ziel erreicht, Plan weitgehend abgearbeitet. Ursprünglicher Plan vom 01.07.2026. Ziel war der Umbau des monolithischen WinForms-Copytraders in ein modulares System mit schlankem Core und unabhängigen Modulen. Erstes Modul: Copytrading.

Was daraus geworden ist: Der Core steht, und es sind vier Module entstanden — CopyTrading, ResolutionFarming, Supervisor und Accounting. Die Phasen 0–6 sind abgeschlossen, der WinForms-Monolith ist am 22.08.2026 vollständig aus dem Repo entfernt. Offen sind nur noch zwei bewusst zurückgestellte Nacharbeiten aus Phase 7.

⚠️ Die Phasen 3–6 waren bis zum 22.08.2026 fälschlich als „IN ARBEIT" bzw. offen markiert — die Arbeit war längst getan, der Plan wurde nur nicht mitgezogen. Die Häkchen unten sind am Code nachgeprüft, nicht aus der Erinnerung gesetzt.

---

1. Leitprinzipien

1. Core kennt keine Module. Der Core stellt nur Basis-Infrastruktur bereit (Host, DB/Persistenz, Settings, Jobs, Logging, API-Clients, Benachrichtigungen, Modul-Contract). Er hat keine Referenz auf irgendein Modul.
2. Module hängen nicht voneinander ab. Jedes Modul referenziert nur den Core. Ein Modul kennt kein anderes Modul. Dies wird durch getrennte Projekte zur Compile-Zeit erzwungen.
3. Jede Phase lässt die App lauffähig und baubar zurück. Kein „Big Bang". Nach jeder Phase: Debug-Build grün, App startet, Copytrading funktioniert.
4. WinForms bleibt. Die GUI-Anforderung ist fix. Module tragen ihre eigenen UI-Tabs zur Shell bei.
5. Sicherheit vor Geschwindigkeit beim Refactoring. CLOB-Integration ist hochkritisch (siehe .agents/rules/clob.md) – bei Berührung besonders sorgfältig, jede Änderung mehrfach prüfen. Rollback jederzeit über Git möglich.

---

2. Zielarchitektur

2.1 Solution-Struktur (Multi-Projekt)

PolyTraderSharp.sln
│
├── PolyTrader.Core            (Class Library, net8.0-windows)
│     • Generic Host / Bootstrap-Infrastruktur
│     • Persistenz: Repository-Interfaces + Implementierung (EF Core)
│     • Settings (appsettings.json + IOptions) + Core-Settings-Sektion
│     • JobManager, Logging (TerminalLogger / ILogger-Sink)
│     • Polymarket-Infrastruktur: PolymarketApiService, PolymarketClobClient,
│       PolymarketWssClient, AlchemyWebsocketService
│     • Querschnitt: MullvadVpnService, ThreemaService
│     • Eigene Trading-Accounts (AccountState) — die Konten, mit denen WIR traden
│     • Generischer Trade-Log (modulübergreifend auswertbar)
│     • Gesamt-Dashboard (Overview über alle Module)
│     • Core-State (generisch): MarketCache, globale Betriebsschalter
│     • IPolyTraderModule-Contract + Modul-Registry
│
├── PolyTrader.Modules.CopyTrading   (Class Library, net8.0-windows)
│     • TraderMonitorService (Signalquelle)
│     • CopyTradingEngine (Ausführung)
│     • MasterTraderAnalyticsJob, TraderAnalyticsJob
│     • Models: TrackedTrader (kopierte Master-Trader), CopySignal,
│       CopyTradeRecord, TraderAnalyticsResult, MasterTraderHistoryRecord
│     • Copytrading-State: Traders (Master), MasterTraderPositions,
│       PendingOrderTimestamps, TraderAnalyticsCache
│     • Channels: CopySignal, ClosedTrade
│     • Eigener Copytrading-Trade-Log (Detail-Auswertung kopierter Trades,
│       zusätzlich zum generischen Core-Log)
│     • Eigene UI-Tabs (Master/Slave-Verwaltung, Modul-Analyse, Closed Trades)
│     • Eigene Modul-Settings-Sektion
│     • CopyTradingModule : IPolyTraderModule
│
├── PolyTrader.App             (WinForms .exe, net8.0-windows)
│     • Program.cs: Host-Bootstrap, lädt Core + registrierte Module
│     • Shell-Form (frm_main reduziert auf Rahmen: Terminal, Jobs, Settings-Tab)
│     • Referenziert Core + alle aktiven Module
│
└── PolyTrader.Tests           (xUnit, optional — spätere Phase)
      • Risk-/Entscheidungslogik des Copytrading-Moduls

2.2 Modul-Contract (Entwurf)

public interface IPolyTraderModule
{
    string Name { get; }                       // "CopyTrading"
    string DbPrefix { get; }                    // Namespace für DB-Objekte, z.B. "ct_"

    void RegisterServices(IServiceCollection services, IConfiguration config);
    void RegisterUi(IModuleUiHost uiHost);      // Modul hängt seine Tabs ein
    Task StartAsync(CancellationToken ct);      // läuft NACH Core-Hydration
    Task StopAsync(CancellationToken ct);
}

• Discovery: Die App registriert Module explizit in Program.cs (services.AddPolyTraderModule<CopyTradingModule>()). Kein Runtime-Assembly-Scanning (bewusst einfach gehalten; kann später zum Plugin-System ausgebaut werden).
• Feature-/Lizenz-Gating: IPolyTraderModule ist die natürliche Schnittstelle, um Module später per Lizenz zu aktivieren/deaktivieren (vgl. lizenssystem.md).

2.3 State-Aufteilung

TradingState wird zerlegt:

Feld	Ziel
MarketCache	Core (generischer Markt-Cache)
GlobalTradingPaused, LiveTradingMode, DemoTradingMode	Core (globale Betriebsschalter)
Accounts (unsere eigenen Trading-Accounts, AccountState)	Core — die Konten, mit denen WIR traden; modulübergreifend nutzbar
Traders (kopierte Master-Trader, TrackedTrader)	CopyTrading-Modul
MasterTraderPositions, PendingOrderTimestamps, TraderAnalyticsCache, TotalCopyTrades, GlobalPnl	CopyTrading-Modul

Entschieden (2026-07-01): Eigene Trading-Accounts liegen im Core (auch künftige Module handeln über dieselben Konten). Die kopierten Master-Trader (TrackedTrader) sind ein Copytrading-Konzept und liegen im Modul.

2.4 Trade-Logging (zweistufig)

Zwei unabhängige, parallel geführte Logs:

1. Generischer Core-Trade-Log (TradeRecord + ITradeLogRepository): modulneutrale Felder (ModulName, AccountId, Markt, Side, Entry/Exit, PnL, Zeiten, ExitReason). Ermöglicht die modulübergreifende Gesamtauswertung. Jedes Modul, das Trades ausführt, schreibt hier einen Eintrag.
2. Copytrading-spezifischer Log (CopyTradeRecord, im Modul): erweitert die generischen Felder um Copytrading-Details (SourceTraderId, SourceTraderName, Master-Adresse, Signal-Herkunft) für die detaillierte Copytrading-Analyse.

Beim Schließen eines kopierten Trades schreibt das Modul beides: einen generischen Eintrag in den Core-Log und einen Detaileintrag in seinen eigenen Log.

2.5 Dashboard & Analyse

• Core-Gesamt-Dashboard: Overview über alle Module (aggregierte PnL, Kontostände, offene Positionen, grobe Kennzahlen je Modul) — gespeist aus dem generischen Core-Log.
• Modul-Analyse: Jedes Modul liefert seine eigene Detailansicht (Copytrading: Trader-Winrates, kopierte Trades, Master-Performance) — gespeist aus dem Modul-Log.

2.6 Settings

• Core-Settings-Sektion: globale/Infrastruktur-Einstellungen (DB, VPN, Threema, Betriebsschalter).
• Modul-Settings-Sektion: jedes Modul trägt seine eigene Sektion zum Settings-Tab bei (analog zu den UI-Tabs), registriert über den IPolyTraderModule-Contract.
• API-Keys sind Modul-Settings: Alchemy-/Polymarket-WSS-Keys wandern von der globalen ServerSettings in die jeweilige Modul-Settings-Sektion (siehe 2.7).

2.7 Streaming / WebSocket-Architektur (Entscheidung 2026-07-01)

Prinzip: Der Core stellt die WSS-Verbindungs-Klasse als wiederverwendbare Fähigkeit bereit — keinen geteilten Singleton-Stream. Jedes Modul erzeugt seine eigene Instanz mit eigenem API-Key und eigenem Filter.

Begründung: Blockchain-/WSS-Streams werden modulspezifisch gefiltert (sonst viel zu umfangreich). Ein einzelner, Core-gesteuerter Stream, auf den mehrere Module gleichzeitig zugreifen, wäre für jedes einzelne Modul mit nutzlosen Informationen geflutet.

Aufteilung des heutigen AlchemyWebsocketService:

• Core (PolyTrader.Core.Streaming): Verbindungs-Mechanik — ClientWebSocket, eth_subscribe, Empfangs-Loop, Decode, Reconnect/429-Backoff, Health. Parametrisiert über eine BlockchainWssSubscription (Contract, Topics, Adress-Filter) + RPC-URL/Key. Als Factory (IBlockchainWssClientFactory.Create()), damit jedes Modul eine eigene Instanz bekommt.
• Modul (CopyTrading): CopyTradingBlockchainListener : BackgroundService, der eine Core-WSS-Instanz mit dem Copytrading-Filter (Wallets der getrackten Master-Trader) + dem Modul-eigenen Alchemy-Key betreibt, den gefilterten Substream konsumiert und selbst reagiert (TraderMonitor-Poll, Re-Subscribe bei Trader-Listen-Änderung).

Analog für den Polymarket-User/Market-WSS (PolymarketWssClient → Core-Verbindungsklasse + Modul-Listener). IsAlchemyHealthy (heute im Core-State) wird zum Health-Signal der jeweiligen Modul-Instanz.

---

3. Persistenz-Strategie

• Zielrichtung: Wechsel auf MySQL via EF Core + Pomelo.EntityFrameworkCore.MySql, gekapselt hinter Repository-Interfaces im Core.
• Begründung: DB liegt off-hot-path (Live-Pfad ist RAM-only) → kein Performance-Nachteil. Gewinn: saubere relationale Tabellen statt Collection-per-Account + Shim, ACID, EF-Migrations, Standard-Backups.
• Risikoarm durch Reihenfolge: Zuerst Repository-Abstraktion einziehen (Phase 3), MySQL-Umstieg als eigene späte Phase (Phase 6). Die Modularisierung ist davon entkoppelt und nicht blockiert.
• Aufräumen: LiteDB-Paket, data.db und MongoDbLiteDBShim entfallen nach der Migration.
• ORM: Entity Framework Core (entschieden) — Migrations + wenig Boilerplate.

---

4. Phasenplan

Jede Phase endet mit grünem Debug-Build + lauffähiger App + Git-Commit.

Phase 0 — Fundament: Versionskontrolle & Aufräumen (ABGESCHLOSSEN 2026-07-01)

• git init (Branch main), .gitignore (bin/, obj/, .vs/, *.user, *.db, server_settings.xml, agentspace/antigravity/, .claude/settings.local.json).
• Alle 11 .bak*-Dateien entfernt (per -f im Baseline-Commit 475d396 archiviert, danach entfernt → rekonstruierbar).
• Tote Stubs entfernt: services/database.cs, services/settings.cs, polymarket/*.cs.
• Threema-Lib unter libs/ vendored (nested .git entfernt).
• Baseline-Commit 475d396 + Cleanup-Commit f76ad73; Debug-Build 0 Fehler verifiziert.

Phase 1 — Multi-Projekt-Gerüst anlegen (ABGESCHLOSSEN 2026-07-01, Commit 4f130ff)

• Drei Projekte: PolyTrader.App (umbenanntes WinForms-Projekt, Root), src/PolyTrader.Core, src/PolyTrader.Modules.CopyTrading (net8.0-windows).
• Referenzen: App → Core + CopyTrading; CopyTrading → Core; Core → nichts.
• App-csproj: src\** vom Globbing ausgeschlossen (keine Glob-Kollision); RootNamespace auf PolyTraderSharp gepinnt (schützt .resx/Namespaces).
• Threema-Lib-Referenz bleibt im App-Projekt (wandert in Phase 4 zu Bedarf in Core).
• Ergebnis: Solution-Build 0 Fehler, Code liegt weiterhin im App-Projekt.
• Offen für spätere Phasen: NuGet-Pakete beim Code-Umzug auf Core/Modul verteilen.

Phase 2 — Konfiguration externalisieren (ABGESCHLOSSEN 2026-07-01, Commit e312fbb)

• appsettings.json eingeführt (Mongo-Connection + DB-Name), Copy-to-Output.
• DatabaseOptions im Core, via IOptions<T> gebunden; hart codierte Strings aus Program.cs entfernt.
• Startup-Cleanup-Hack aus Main() entfernt und gekapselt nach Host-Build über die konfigurierte DB neu verankert.
• Offen (bewusst später): Alchemy-Key / Mullvad-Account / Threema bleiben vorerst im GUI-editierbaren server_settings.xml (kein Konflikt mit Settings-Tab).

Phase 3 — Persistenz-Abstraktion (ABGESCHLOSSEN — nachgetragen 22.08.2026)

• 3a (8b3264f): Core-Modelle AccountState/Position/MarketData in den Core verschoben (Namespace PolyTraderSharp.Models beibehalten), MongoDB.Driver-Paket im Core.
• 3b (ed5d6e3): Repository-Interfaces + Mongo-Implementierungen im Core (IAccountRepository, IMarketRepository, IPositionRepository), AddCorePersistence().
• 3c (7197f9b): Unkritische Call-Sites migriert (MarketSyncService, PolymarketWssClient).
• 3d — Hot-Path (a0e367e, 0c6fc6a): TraderMonitorService + CopyTradingEngine auf IPositionRepository/IMarketRepository/IAccountRepository umgestellt. _db aus CopyTradingEngine komplett entfernt; Verhalten unverändert.
• frm_main-UI: erledigt — frm_main existiert nicht mehr (Avalonia-Portierung, Rest mit dem WinForms-Ausbau am 22.08.2026 gelöscht).
• Generisches ITradeLogRepository (Core) + ICopyTradeLogRepository + ITrackedTraderRepository (Modul) sind gebaut und in Gebrauch.
• Ergebnis erreicht: Kein direkter DB-Zugriff mehr außerhalb der Repository-Schicht.

Phase 4 — Core herauslösen (ABGESCHLOSSEN — nachgetragen 22.08.2026)

• 4.1 (9039af8): TerminalLogger, JobManager, JobStatusRow → Core; toten Stub logging.cs gelöscht.
• 4.2 (eebe992): PolymarketClobClient → Core (+ Nethereum.Web3), reines Verschieben.
• 4.3 (8c126cd): ServerSettings → Core.
• 4.4 (a1ce3fc): IPolyTraderModule-Contract im Core (UI-Teil auf Phase 5 vertagt).
• 4.5 (c88eac5): Startup-Reihenfolge-Fix — StartupHydrationService (IHostedService, als erster registriert) hydriert Accounts/Trader vor den Trading-Services; frm_main.LoadDatabaseAndState entfernt.
• 4.6a (9c068b4): CopySignal + PolymarketApiService → Core.
• 4.7 (0ffc041): MullvadVpnService + ThreemaService (+ Threema-Lib-Ref) → Core; toter Stub mullvad.cs gelöscht.
• Ehemals blockiert durch den TradingState-Split: aufgelöst. MarketSyncService und die Streaming-Infrastruktur liegen im Core (src/PolyTrader.Core/Streaming/); PolymarketWssClient ist bewusst im CopyTrading-Modul geblieben, weil er modulspezifisch filtert.
• Ergebnis: Core baut eigenständig und enthält jetzt: Modelle (Account/Position/ Market/CopySignal/JobStatusRow/ServerSettings), Repository-Schicht, Config, Logging, JobManager, CLOB-Client, API-Service, Mullvad, Threema, IPolyTraderModule.

Stand nach Phase 4: Der Core ist substanziell und eigenständig. Was noch in der App liegt: Modul-Services (TraderMonitor, CopyTradingEngine, Analytics-Jobs), die TradingState-abhängige Infra (MarketSync, Alchemy, WSS, Snapshot), PersistenceService, StartupHydrationService, der Shim, TradingState, frm_main und die Modul-Modelle (TrackedTrader, TraderAnalyticsResult, MasterTraderHistoryRecord, ClosedTrade, DashboardRow). Der TradingState-Split ist der Dreh- und Angelpunkt für Phase 5.

Entscheidung (2026-07-01): CopySignal wird ein Core-Typ (generisches Markt-Trade- Signal). Das entkoppelt die Polymarket-Infrastruktur sauber in den Core. Der Channel/Workflow bleibt Copytrading. Umbenennung zu TradeSignal optional/später.

Phase 5 — CopyTrading-Modul herauslösen (ABGESCHLOSSEN — nachgetragen 22.08.2026)

• 5.1 (55050a1): Modul-Modelle (TrackedTrader, TraderAnalyticsResult, MasterTraderHistoryRecord) ins Modul verschoben.
• 5.2 (f8d395b): TradingState-Split — Core TradingState (globale Schalter, Accounts, MarketCache, GlobalPnl) vs. CopyTradingState im Modul (Traders, MasterTraderPositions, TraderAnalyticsCache, TotalCopyTrades, PendingOrderTimestamps, SixSharesMinimum); 10 Konsumenten umgestellt. Modulgrenze auf State-Ebene gezogen.
• 5.3a (f5e7eaf): MarketSyncService → Core (nur Core-State).
• 5.3-WSS 1/2 (3be75c0): Core-WSS-Verbindungsklasse extrahiert (IBlockchainWssClient + Factory + Modelle in PolyTrader.Core.Streaming); AlchemyWebsocketService nutzt sie via Factory. Verhaltensneutral.
• ClosedTrade-Migration (88fc982): ClosedTrade → Modul, ICopyTradeLogRepository (+ Mongo-Impl) im Modul; closed_trades-Zugriffe der Services (TraderMonitor, Persistence, WSS, TraderAnalytics) auf das Repo umgestellt. TraderMonitor nutzt kein _db mehr. frm_main/Program.cs bleiben auf _db.
• 5.3b: erledigt — TraderMonitorService, CopyTradingEngine, TraderAnalyticsJob, MasterTraderAnalyticsJob und PersistenceService liegen unter src/PolyTrader.Modules.CopyTrading/Services/.
• 5.3-WSS 2/2: erledigt — PolymarketWssClient liegt im Modul, die generische Verbindungsschicht (IBlockchainWssClient + Factory) im Core.
• UI-Trennung (Launcher-Modell, entschieden 2026-07-01): Hauptfenster = schlanke Startleiste; jede Ansicht öffnet als eigenständiges Fenster. Module liefern designbare UserControls via IPolyTraderModule.RegisterUi / IModuleUiHost. frm_main bleibt übergangsweise als „Legacy-UI" per Button erreichbar, bis alle Views extrahiert sind.
  • UI-Contract im Core (IModuleUiHost, ModuleView, RegisterUi) — 26dd68a.
  • Proof-of-Pattern: LauncherForm + ViewHostForm + ShellUiHost + erste View TerminalView (designbar); App startet Launcher — 3503bbb.
  • Alle Views extrahiert. Das Launcher-Modell wurde inzwischen selbst wieder abgelöst: seit dem UI-Redesign gibt es eine Shell mit Seitenleiste (src/PolyTrader.App.Avalonia/Views/ShellWindow.axaml) statt vieler Einzelfenster.
  • frm_main (Legacy) entfernt.
• CopyTradingModule : IPolyTraderModule ist implementiert — ebenso ResolutionFarmingModule, SupervisorModule und AccountingModule.
• Dualer Trade-Log verdrahtet (Core-Log + Copytrading-Log).
• Collection-Namensbug (traders vs. trackers) mit der MySQL-Migration hinfällig — relationale Tabellen mit festem Schema statt Mongo-Collections.
• Ergebnis erreicht: Copytrading ist ein eigenständiges, entfernbares Modul; drei weitere Module sind nach demselben Muster entstanden.

Phase 6 — MySQL-Migration (ABGESCHLOSSEN — nachgetragen 22.08.2026)

• EF Core + Pomelo eingerichtet, relationales Schema modelliert; Tabellen mit den Präfixen core_ und mod_, Migrationen je Projekt unter Persistence/Ef/Migrations/.
• Repository-Implementierungen auf EF Core hinter den bestehenden Interfaces.
• Migration der Altdaten über die CLI-Schalter --migrate-json und --verify-mysql (statt eines Skripts in agentspace/scripts).
• Mongo vollständig entfernt: kein MongoDB.Driver- oder LiteDB-Paket mehr in irgendeiner .csproj, kein Shim. data.db und die MongoDB/-Exporte sind am 22.08.2026 auch lokal gelöscht worden.

Phase 7 — Nacharbeiten (teilweise erledigt — Stand 22.08.2026)

• Test-Projekt: Risk-/Entscheidungslogik als reine Funktionen extrahiert und getestet — 476 Tests grün.
• Leere catch {} beseitigt — in src/ findet sich kein einziger leerer Catch-Block mehr.
• Secrets-Verschlüsselung umgesetzt, allerdings nicht mit DPAPI: DPAPI ist Windows-only und hätte die Linux-Portierung blockiert. Stattdessen AES-GCM at-rest über Security/SecretProtection.cs + EncryptedStringConverter, Schlüssel aus POLYTRADER_MASTER_KEY (siehe Security/MasterKeyResolver.cs).
• Offen: God-Methoden splitten (PollLiveAccountsAsync, ProcessAccountOrderAsync); duplizierte Closed-Trade-Erzeugung zentralisieren.
• Offen: TerminalLogger auf Microsoft.Extensions.Logging + UI-Sink umstellen. Hängt mit dem Zeitzonen-Punkt zusammen (Abschnitt C im Avalonia-Leitfaden): der Logger stempelt mit DateTime.Now statt der konfigurierten AppTimeZone.

---

5. Datei-→-Ziel-Zuordnung (Referenz)

Aktuell	Ziel
Program.cs	PolyTrader.App
frm_main.*	PolyTrader.App (Shell) + Copytrading-Tabs → Modul
frm_analytics.*	PolyTrader.Modules.CopyTrading
TradingState.cs	aufgeteilt: Core + Modul
services/PolymarketApiService.cs	Core
services/PolymarketClobClient.cs	Core
services/PolymarketWssClient.cs	Core
services/AlchemyWebsocketService.cs	Core
services/MullvadVpnService.cs, mullvad.cs	Core
services/ThreemaService.cs	Core
services/JobManager.cs, TerminalLogger.cs, logging.cs	Core
services/PersistenceService.cs	Core (generischer Trade-Log-Writer); Copytrading-Detail-Writer → Modul
services/MarketSyncService.cs, SnapshotService.cs	Core
Extensions/MongoDbLiteDBShim.cs	Core (temporär), entfällt in Phase 6
services/CopyTradingEngine.cs	Modul
services/TraderMonitorService.cs	Modul
services/MasterTraderAnalyticsJob.cs, TraderAnalyticsJob.cs	Modul
Models/AccountState.cs, Position.cs, MarketData.cs, ServerSettings.cs, JobStatusRow.cs, DashboardRow.cs	Core
Models/ClosedTrade.cs	aufgeteilt: generischer TradeRecord → Core, CopyTradeRecord (mit SourceTrader-Feldern) → Modul
Models/TrackedTrader.cs, CopySignal.cs, TraderAnalyticsResult.cs, MasterTraderHistoryRecord.cs	Modul
services/database.cs, settings.cs, polymarket/*.cs	löschen (Phase 0)
*.bak*	löschen (Phase 0)

---

6. Getroffene Entscheidungen (2026-07-01)

1. Eigene Trading-Accounts → Core, kopierte Master-Trader → Copytrading-Modul.
2. Zweistufiges Trade-Logging: generischer Core-Log (modulübergreifend) und zusätzlicher Copytrading-Detail-Log im Modul (siehe 2.4).
3. ORM: Entity Framework Core.
4. Dashboard: Core liefert Gesamt-Overview über alle Module; Module liefern eigene Detail-Analysen (siehe 2.5).
5. Settings: getrennte Core- und Modul-Settings-Sektionen (siehe 2.6).

---

7. Risiken & Gegenmaßnahmen

• CLOB-Regression: Höchstes Risiko. Gegenmaßnahme: CLOB-Client möglichst unverändert in den Core verschieben (nur Namespace/Referenzen), keine Logikänderung in der Umstrukturierungsphase.
• Startup-Race weiterhin aktiv, bis Phase 4: Bis der Startup-Fix greift, bleibt das bestehende Verhalten – kein neues Risiko, aber früh angehen.
• Datenmigration (Phase 6): Server läuft produktiv. Migration mit Read-Only-Export + Verifikation vor Umschaltung; Rollback-Pfad (Mongo bleibt bis Verifikation bestehen).