Erster Befund aus dem Linux-Lauf auf der Test-VM (Roadmap A4a): Ohne
konfigurierte Datenbank startete die Anwendung los und starb erst tief im
DI-Aufbau mit einer unbehandelten ArgumentException und rund 50 Zeilen
Stacktrace - "The string argument 'connectionString' cannot be empty", geworfen
aus dem EF-Kern. Exitcode 134 (SIGABRT).
Fuer den Serverbetrieb ist das gleich doppelt schlecht: Der Betreiber sieht
nicht, was fehlt, und systemd startet den Dienst wegen Restart=on-failure alle
zehn Sekunden neu. Im Journal stehen dann endlose Startversuche statt der
Ursache. Genau dieser Zustand ist bei einer Erstinstallation der wahrscheinlichste
- Software liegt da, Zugangsdaten sind noch nicht gesetzt.
Behoben an drei Stellen:
- Program.Main prueft die Verbindung, bevor der Host gebaut wird, und gibt aus,
welcher Schluessel in welcher Datei erwartet wird, samt Beispiel und dem
Hinweis, dass das Schema per "dotnet ef database update" angelegt wird (die
Anwendung migriert nicht selbst).
- Rueckgabewert 78 (EX_CONFIG aus den BSD-sysexits) statt eines Absturzes.
- deploy/polytrader.service traegt RestartPreventExitStatus=78 - ein
Konfigurationsfehler repariert sich durch Neustarts nicht, er wird dadurch nur
unsichtbar.
- AddCorePersistence wirft als zweite Verteidigungslinie eine
InvalidOperationException mit derselben Aussage, falls jemand die Methode
direkt aufruft.
Der Connection-String wird dabei ueber dieselben Dateien und denselben Schluessel
gelesen wie spaeter im Host, damit beide Wege nicht auseinanderlaufen koennen.
Build gruen, 476 Tests gruen (Windows und Linux).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Status des Projekts stand verstreut in elf Umsetzungsplaenen, drei
Konzepten, der Linux-Analyse und dem Projektstand - teils widersprechend, teils
wochenlang veraltet. Ab jetzt gibt es genau eine Statusquelle.
docs/ROADMAP.md (neu):
- Alle Vorhaben in vier Stufen A bis D, plus technische Schuld und Verlauf.
Die Stufen sind eine Reihenfolge, keine Termine: jede schafft die
Voraussetzung fuer die naechste.
- Statuszeichen: erledigt / offen / blockiert (mit Ursache) / bewusst
zurueckgestellt / Idee, nicht beschlossen. Damit ist das, was wir NICHT bauen
wollen, sichtbar vorgehalten statt unauffindbar in einem Plan zu schlummern.
- Inhaltlich getragen, nicht nur verlinkt: je Vorhaben Ziel, Phasen,
Akzeptanzkriterien, offene Entscheidungen und Leitplanken aus den Quelldokumenten.
- Sichtbar gemacht, was vorher zwischen den Dokumenten verborgen lag:
CopyTrading Phase 1 ist der Engpass der gesamten Roadmap (MarketMaking und
BundleArbitrage haben harte Voraussetzungen darauf), und die Sniper-Metriken
aus Phase 3.2 sind ein Spezialfall des StrategieDrift-Fingerprints - zusammen
bauen statt doppelt.
Archiv (docs/archiv/):
- 15 Dokumente verschoben (11 Umsetzungsplaene, 3 Konzepte, ANALYSE-Linux-Portierung).
Sie bleiben die Bauanleitungen mit Code-Bezuegen, Risikotabellen und
Begruendungen - eingefroren ist nur ihr Status.
- archiv/README.md ordnet jedes Dokument seinem Roadmap-Punkt zu.
Verweise nachgezogen - der eigentliche Aufwand:
- 25 Markdown-Links repariert. 15 davon verschiebungsbedingt (eine Ebene
tiefer), der Rest war schon vorher falsch: die Ideensammlung verlinkte
Quellcode relativ zum Repo-Wurzelverzeichnis statt zu docs/.
- 12 Dateien ausserhalb von docs/ verwiesen in Kommentaren auf die Plaene
(csproj, props, setup.json, sechs Quelldateien) - alle auf archiv/ umgebogen.
- Verweise auf Dateien, die der Fruehjahrsputz geloescht hat (Ui/,
Program.cs, WindowMenuBar), zu Klartext entschaerft statt tote Links zu lassen.
- Gegenprobe: 85 Links geprueft, 0 kaputt. Build gruen, 476 Tests gruen.
PROJEKTSTAND.md entdoppelt: Abschnitt "Offen" verweist jetzt auf die Roadmap.
Arbeitsteilung ist damit klar - Projektstand sagt was IST, Roadmap was KOMMT.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sicherungscommit vor dem Aufraeumen des Repos, damit nachvollziehbar bleibt,
welcher Stand vor der Bereinigung galt. Build gruen, 476 Tests gruen.
Zwei Straenge, die sich ueber .csproj, Program.cs und appsettings.json
ueberschneiden und darum gemeinsam abgelegt werden:
Deploymentcenter-Integration (P3c, Plan D-0 bis D-5 code-seitig fertig):
- Deploymentcenter.Client 2.5.0 als lokales Paket, Source-Mapping erweitert
- DeploymentcenterOptions, DeploymentcenterErrorReporter, LicenseGate/LicenseCli
- WatchdogHeartbeatService auf die Deploymentcenter-API umgestellt
(version, os, checks, metrics, status stopped)
- Security: MasterKeyResolver, SecretRedactor, FilePermissions
- Directory.Build.props mit zentraler Version 0.1.0 (Packager-Versionsdisziplin)
- deploy/: Packager-Vorlage und systemd-Unit; echte Zugangsdaten bleiben
ueber .gitignore aussen vor
- setup.json fuer die Erstinstallation
- UMSETZUNGSPLAN-Deploymentcenter-Integration.md; ANALYSE-Linux-Portierung.md
verweist auf den neuen Plan
Einfenster-Shell (UI-Redesign):
- ShellWindow + ShellNavModel als Seitenleisten-Shell
- WindowMenuBar und WindowMenuModel entfallen
- Modul- und Kernfenster auf die Shell-Einbettung angepasst
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Richard