Options-Fundament und Kapitalmodell im Core; Modul OptionsWheel
Build & Test / build (ubuntu-latest) (push) Canceled after 0s
Build & Test / build (windows-latest) (push) Canceled after 0s

Das OptionsWheel setzt auf Dingen auf, die es im Core nicht gab. Diese
Sitzung baut sie.

#298 Optionen als Instrument. InstrumentKind/OptionSpec und ein
druckbarer Instrumentenschluessel ("AAPL|20260918|C|150"); TradeSignal
und OrderRequest tragen ein optionales OptionSpec, ohne das sich der
Aktienpfad unveraendert verhaelt. Position.Notional rechnet ab jetzt mit
der Kontraktgroesse - vorher war jede Option um Faktor 100 zu klein
bewertet und damit jedes Risikolimit wirkungslos, lautlos und in die
gefaehrliche Richtung. Daneben neu BoundCapital: ein Short Put bindet
Strike x Kontraktgroesse, nicht die vereinnahmte Praemie.

#300 sell-to-open. Jeder Auftrag zerfaellt in einen schliessenden und
einen eroeffnenden Teil; der schliessende wird von keinem Limit
verhindert - auch nicht vom Kaufstopp, denn ein Rueckkauf baut eine
Verpflichtung ab. Deckungspruefung im Core, nicht im Modul: Short Call
nur mit freien Aktien, Short Put nur mit reservierbarem Bargeld.

#302-#305 Kapital- und Buchmodell. Buecher mit reservierten Namen und
Eigentumsregeln, Pool mit Caps und Headroom, Margin-Sperre in vier
Schichten, core_reservation mit Lebenszyklus, Frist, Idempotenz ueber
(SignalId, ContractKey) und Quarantaene beim Start.

#309/#310 Modul OptionsWheel: ow_-Schema mit fuenf Tabellen,
Zustandsautomat, StrikeSelector, RollDecider, PremiumMath - vollstaendig
ohne Broker testbar. Der Handelsbetrieb bleibt gesperrt, solange #299
und #294 fehlen; das Modul sagt das ueber GetActivationBlocker, statt
still nichts zu tun.

#293 --verify-order am Daemon: eine Order durch die vollstaendige Kette
(Buch, Risiko, Bindung, Order, Fill, Buchung, Abschluss). Ohne --confirm
ein Trockenlauf; Abbruch ausserhalb von Paper-Modus UND Paper-Port.

Drei Widersprueche in den Konzepten sind dabei entschieden worden:
Schicht B heisst ab jetzt "kein UNGEDECKTER Short" (der Grund der Regel
war der Kredit, nicht der Short), die Hausreserve wird einmal abgezogen
statt zweimal, und der Positionsschluessel ist eine Spalte statt eines
Sechser-Verbunds (MySQL verlangt NOT NULL fuer Schluesselspalten).
Begruendungen stehen in docs/ROADMAP.md.

Enthaelt ausserdem die noch nicht committete Arbeit aus der vorigen
Sitzung: die Fehlerbehebungen aus Epic X (WorkerBase-Intervall,
BackupWorker, --check gegen die Datenbank, CapitolTrades-429, SIGTERM)
samt DatabaseEndpoint, MysqlDumpTool und der Roadmap-Umstellung. Sie lag
im Arbeitsbaum und liess sich nicht abtrennen, weil beide Staende
dieselben Dateien beruehren.

213 -> 369 Tests, Build ohne Warnung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Richard
2026-09-04 09:35:38 +02:00
co-authored by Claude Opus 5
parent 9f66183f1c
commit 084cd7ef77
99 changed files with 9947 additions and 445 deletions
@@ -0,0 +1,85 @@
using IBKRTrader.Core.Settings;
using MySqlConnector;
namespace IBKRTrader.Core.Configuration;
/// <summary>
/// Die eine maßgebliche Datenbankverbindung der Anwendung – aufgelöst aus den beiden Quellen,
/// die es historisch gab.
///
/// <para>Bisher lasen EF-Kontexte den Connection-String aus <c>appsettings(.Local).json</c>,
/// während BackupWorker und die Versionsdiagnose Host/Port/Datenbank/Benutzer aus
/// <c>settings.json</c> nahmen. Nichts erzwang, dass beide dasselbe meinen: eine Installation
/// konnte monatelang sauber laufen und dabei eine Datenbank sichern, die es gar nicht gibt.</para>
///
/// <para>Regel: Ist in der Konfiguration ein Connection-String hinterlegt, ist <b>er</b>
/// maßgeblich und alles Weitere wird aus ihm abgeleitet. Fehlt er, wird die Verbindung aus
/// <c>settings.json</c> gebaut – dann sind beide Quellen zwangsläufig deckungsgleich.</para>
/// </summary>
public sealed class DatabaseEndpoint
{
public string ConnectionString { get; }
public string Host { get; }
public int Port { get; }
public string Database { get; }
public string User { get; }
public string Password { get; }
/// <summary>Woher die maßgebliche Verbindung stammt – für die Startmeldung.</summary>
public string Source { get; }
private DatabaseEndpoint(string connectionString, string source)
{
ConnectionString = connectionString;
Source = source;
var b = new MySqlConnectionStringBuilder(connectionString);
Host = b.Server;
Port = (int)b.Port;
Database = b.Database;
User = b.UserID;
Password = b.Password;
}
/// <summary>
/// Löst die maßgebliche Verbindung auf. Ein unlesbarer Connection-String fällt auf
/// <c>settings.json</c> zurück, statt den Start zu verhindern – sichtbar wird das über
/// <see cref="Source"/> und die Startprüfung.
/// </summary>
public static DatabaseEndpoint Resolve(string? configuredConnectionString, DatabaseSettings settings)
{
if (!string.IsNullOrWhiteSpace(configuredConnectionString))
{
try { return new DatabaseEndpoint(configuredConnectionString, "appsettings"); }
catch (Exception ex)
{
return new DatabaseEndpoint(settings.BuildConnectionString(),
$"settings.json (Connection-String unlesbar: {ex.Message})");
}
}
return new DatabaseEndpoint(settings.BuildConnectionString(), "settings.json");
}
/// <summary>
/// Beschreibt eine Abweichung zwischen der maßgeblichen Verbindung und dem, was in
/// <c>settings.json</c> steht – sonst <c>null</c>. Beides darf existieren, aber wer sie
/// auseinanderlaufen lässt, sichert die falsche Datenbank.
/// </summary>
public string? DescribeDivergence(DatabaseSettings settings)
{
if (Source != "appsettings") return null;
var differs = !string.Equals(Host, settings.Host, StringComparison.OrdinalIgnoreCase)
|| !string.Equals(Database, settings.Database, StringComparison.OrdinalIgnoreCase)
|| Port != settings.Port;
return differs
? $"Datenbank-Konfiguration weicht ab: maßgeblich ist {this} (appsettings), " +
$"settings.json nennt {settings}. Es gilt die maßgebliche Verbindung."
: null;
}
/// <summary>Benutzer@Host:Port/Datenbank – nie das Passwort.</summary>
public override string ToString() => $"{User}@{Host}:{Port}/{Database}";
}