6189d1bf8c67187ed7cc1ea174b2f23d758c04f3
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 RichardandClaude Opus 5
|
27b594ca8f |
Sperren des Betreibers: Positionen und Instrumente, im Core durchgesetzt
Vier Stufen je Position (frei, nur schliessen, nur aufbauen, gesperrt) und je Instrument ein Handelsverbot samt harter Bestandsobergrenze. Beides gilt fuer Module; der manuelle Handel in TWS bleibt unberuehrt. Die Pruefung sitzt im RiskService, nicht im Modul: Eine Sperre, die ein Modul selbst pruefen muesste, ist keine Sperre, sondern eine Bitte. Sie laeuft NACH der fachlichen Bewertung, weil erst dort feststeht, welcher Teil eines Auftrags eroeffnet und welcher schliesst - genau daran haengen die Stufen. Drei Entscheidungen, die im Betrieb zaehlen: "Gesperrt" verhindert auch den Ausgang. Eine Position, die aus Risikogruenden geschlossen werden muesste, bleibt liegen, bis jemand die Sperre loest. Das ist gewollt und steht als eigener Test da, damit es niemand fuer einen Fehler haelt. Ein Handelsverbot sperrt das Eroeffnen, nicht das Schliessen. Ein nachtraeglich gesetztes Verbot darf keine Position einsperren, die man gerade loswerden will; wer auch das will, nimmt die Positionssperre. Die harte Stueckzahl zaehlt den Bestand ueber ALLE Buecher, MANUAL eingeschlossen, und Short-Positionen mit ihrer Groesse statt ihrem Vorzeichen: "hoechstens 100" meint die Groesse der Verpflichtung. Sie ersetzt das prozentuale Konzentrationslimit nicht - der Prozentsatz waechst mit dem Konto, die Stueckzahl ist eine Aussage ueber ein bestimmtes Papier. Es zieht die engere Grenze. TradingRuleService haelt die Regeln im Speicher, weil sie bei jeder Risikopruefung gebraucht werden, sich aber selten aendern. Laesst sich die Liste NICHT laden, gilt das nicht als "keine Sperren": der Dienst meldet es und sperrt, bis sie wieder lesbar ist. Eine Sperre, die bei einem Datenbankfehler verschwindet, waere keine. Ein unlesbarer Stufenwert wird ebenso als schaerfste Stufe gelesen. Auf dem Testserver angewendet (Tabellen core_position_lock und core_instrument_rule) und der Dienst damit neu gestartet - keine Ladefehler, der Handel bleibt frei. Zur Probe stehen dort die beiden Beispiele des Betreibers: WIRECARD gesperrt, NVDA hoechstens 100 Stueck. 425 Tests gruen, 11 davon neu. Arbeit an #485 und #486; die Oberflaeche fehlt noch, die Durchsetzung steht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
b042396f2d |
Kapitalmodell rechnet Waehrungen um, statt sie zu addieren
Solange jedes Instrument in USD notierte, war die Frage gegenstandslos. Mit waehrungsfaehigen Instrumenten ist sie es nicht mehr: CapitalService summierte BoundCapital ueber alle Positionen unabhaengig von deren Waehrung und verglich das Ergebnis mit NetLiquidation in Kontobasiswaehrung. Dasselbe galt fuer die Konzentration je Basiswert und fuer die offenen Reservierungen, die von einer Groesse in Basiswaehrung abgezogen wurden. Auf dem Testkonto ist die Basis EUR und USD steht bei 0,8611: jede USD-Position ging bisher rund 16 Prozent zu hoch in das verteilbare Kapital ein. Die Richtung des Fehlers wechselt mit dem Kurs - bei einer starken Fremdwaehrung wird die Auslastung unterschaetzt und ein Buch darf mehr aufmachen als es soll. Die Kurse kommen aus dem Ledger des Brokers ($LEDGER:ALL, Tag ExchangeRate), nicht aus einer eigenen Quelle. Das ist Absicht: NetLiquidation und TotalCashValue sind mit genau diesen Kursen gebildet. Mit einem fremden Kurs verglichen wir den Positionswert gegen eine Kontogroesse, die anders gerechnet wurde. Fuer die Buchhaltung gilt das Gegenteil - dort ist der amtliche Tageskurs der richtige, das ist ein anderer Zweck (#321). Fehlt ein Kurs, wird nicht geraten: der Snapshot meldet FxComplete=false, der Positionswert gilt als Untergrenze, und der Kauf wird angehalten. Schliessen bleibt moeglich. Eine Reservierung ohne Kurs wird dagegen roh angesetzt statt uebersprungen - sie zu ignorieren hiesse, gebundenes Geld als frei zu fuehren. Gemessen am Paper-Gateway: "Konto: Umrechnungskurse EUR 1, USD 0.8611 (Basis EUR)". 388 Tests gruen. Behebt #480. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
084cd7ef77 |
Options-Fundament und Kapitalmodell im Core; Modul OptionsWheel
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> |