c87b0195fd0c084afbd6bfc058fc63ae2e9e71a8
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 RichardandClaude Opus 5
|
c87b0195fd |
Logdateinamen haengen nicht mehr am Kalender der Host-Kultur
Im Logverzeichnis der Test-VM lagen neben 2026-09-03.jsonl auch 1405-06-12.jsonl und 2569-09-03.jsonl - dieselben Tage im Sonnen-Hidschra- und im buddhistischen Kalender. Eine interpolierte Zeichenkette formatiert mit CurrentCulture, und die bringt ihren Kalender mit. Betroffen waren beide Schreibpfade des LoggingService und die Lesestelle im DossierService, die denselben Namen wieder zusammensetzt. CA1305 greift hier nicht: die Regel sieht string.Format und ToString, nicht die interpolierte Form. Die .editorconfig deckt diesen Fall also nicht ab. FormattableString.Invariant an allen drei Stellen, dazu ein Regressionstest ueber fa-IR, th-TH und de-DE - mit Gegenbeweis, dass die naive Form tatsaechlich abweicht, damit der Test nicht eines Tages unbemerkt trivial wird. Ausserdem: Verweise auf die Bugtracker-Nummern richtiggestellt (488/489). 461 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
e7e3970dec |
Orders, die beim Broker liegen, gelten nicht mehr als gescheitert
Am geschlossenen Markt gemessen: IBKR nimmt eine Order an und merkt sie fuer die naechste Eroeffnung vor. Dazu schickt es Code 399 - eine Mitteilung, deren Text mit "Warning" beginnt. Der Adapter las jede Meldung aus dem Fehler-Callback als Ablehnung, meldete "Order abgelehnt", und das Kapitalmodell gab die Bindung frei. Auf dem Testkonto lagen dadurch 67 Orders ueber 306 BAS, 140 SAP und 43 ALV beim Broker, vorgemerkt fuer Montag 09:00, ohne eine einzige Reservierung dahinter. OrderResult kannte nur "erfolgreich" und "gescheitert". Der haeufigste Fall passte in keines von beiden. Es gibt jetzt einen dritten Ausgang - Working: abgesendet, Ausgang offen. Die Trennlinie ist, ob BEWIESEN ist, dass beim Broker nichts liegt; ohne Beweis bleibt das Kapital gebunden. Eine Bindung, die zu lange steht, kostet Spielraum und faellt auf. Eine, die zu frueh verschwindet, kostet Geld und faellt nicht auf. - 399/404 sind Ordermeldungen, keine Ablehnungen; nur 201/202/203 u. a. beenden eine Order beweisbar. Ein Verbindungsabbruch beendet unsere Sicht, nicht die Order. - IsDeadStatus ist enger als IsTerminalStatus: "Inactive" ist kein Beweis. - ExecutionService haelt die Bindung bei Working (MarkSubmittedAsync statt CancelReservationAsync) und journalisiert Pending/OrderWorking statt Failed. - Neu lesbar: das Orderbuch des Brokers (reqAllOpenOrders) samt Storno. --open-orders stellt Orderbuch und eigene Bindungen gegenueber, --cancel-order <ID>|all --confirm nimmt zurueck (Sammelstorno nur im Paper-Modus). - Der Wiederanlauf-Abgleich lief bisher gegen eine leere Orderliste und haette ab jetzt jede gesunde Bindung in Quarantaene gestellt. Er sitzt jetzt im ReservationWatchdogWorker, hinter dem Beweis, dass der Broker antwortet. 457 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
0feeeba815 |
Optionskette und Bewertungsgroessen im Core
Der Core kennt jetzt die handelbaren Verfallstage und Strikes eines Basiswerts
(reqSecDefOptParams) und die Bewertungsgroessen eines Kontrakts
(tickOptionComputation). Damit steht der letzte Baustein, den eine
Wheel-Strategie braucht, um ueberhaupt einen Kontrakt auswaehlen zu koennen.
OptionChain ist bewusst nur eine Liste und trifft keine Marktentscheidung. Die
Auswahlhilfen daran sind reine Rechnung - "der Verfall bei etwa 35 Tagen" ist
eine Kalenderfrage, "welches Delta will ich" nicht. Letzteres gehoert ins Modul.
Zwei Eigenheiten der TWS-API sind beim Messen aufgefallen und haben je einen
Fehler gekostet:
1. Greeks kommen NICHT im Snapshot. reqMktData mit snapshot=true liefert Geld-,
Brief- und letzten Kurs, aber keine tickOptionComputation. Es braucht ein Abo,
das beim ersten Modell-Tick wieder abbestellt wird.
2. TWS meldet je Basiswert MEHRERE Serien. Fuer AAPL kamen "AAPL" und "2AAPL" -
letztere eine Sonderserie mit eigenen Ausuebungspreisen. Der erstbeste Satz
war die falsche: Strike 320 in "2AAPL" gibt es nicht, TWS antwortete mit 200
("No security definition has been found"). Die Auswahl nimmt jetzt SMART vor
allen anderen Boersen und darin die Handelsklasse, die dem Symbol entspricht.
Massgeblich ist ausserdem allein das Modell-Feld (13 bzw. 83 bei verzoegerten
Daten). Die Varianten zu Geld-, Brief- und letztem Kurs fehlen bei illiquiden
Serien und lieferten sonst ein Delta aus einem Kurs, den niemand stellt. Fehlende
Werte meldet TWS als double.MaxValue oder -1; sie werden zu null, nicht zu 0 -
ein Delta von 0 hiesse "reagiert nicht auf den Basiswert".
Gemessen gegen das Paper-Gateway:
AAPL (USD, SMART/AAPL, x100): 22 Verfallstage, 123 Strikes
Auswahl wie beim Wheel: AAPL|20261009|P|320 (Kurs 320.01, 34 Tage Laufzeit)
Deckungsbedarf je Kontrakt: 32.000,00 USD
IV 24.5 %, Delta -0.471, Gamma 0.0169, Vega 0.392, Theta -0.123 (verzoegert)
Der Schalter --option-chain SYMBOL [--currency X] faehrt genau diesen Ablauf und
bleibt als Pruefwerkzeug. 414 Tests gruen.
Behebt #299.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
RichardandClaude Opus 5
|
40f7bb0d6e |
Bestandsabgleich gegen den Broker: Zuteilung, Verfall, Fremdbestand
Zuteilung und Verfall aendern Positionen ohne eine Order von uns - es gibt kein Ereignis, an das sich ein Abgleich haengen koennte. Nach einem Verfallstag fuehren wir Kontrakte, die es nicht mehr gibt; nach einer Zuteilung liegen Aktien im Konto, die in keinem Buch stehen. Beides verschiebt still die Deckungslage: Ein Covered Call, dessen Aktien in Wahrheit abgerufen wurden, ist ab dann ein nackter Call. PositionReconciler ist reine Rechnung und deutet die Differenz, statt nur Mengen anzugleichen. Verschwindet ein geschriebener Put und tauchen zugleich Aktien des Basiswerts auf, gehoeren diese Aktien dem Buch, das den Put geschrieben hat - landeten sie in UNASSIGNED, verloere ein Wheel-Modul genau den Bestand, aus dem es den naechsten Call schreiben muss. Der Einstand ist dabei der Strike, denn zu genau dem Preis wurde geliefert. Passt die Aktienbewegung nicht zur Groesse der Option, gilt sie NICHT als Zuteilung. Verfall wird nur angenommen, wenn der Verfallstag erreicht ist. Ein Kontrakt, der vorher verschwindet, ist eine Abweichung und wird als solche gemeldet - von Hand geschlossen ist kein Verfall. Die gefaehrlichste Stelle ist die leere Antwort: Die Leseschnittstelle liefert bei gestoerter Verbindung eine leere Liste, die von einem leeren Konto nicht zu unterscheiden ist. Solange wir selbst Positionen fuehren, gilt sie deshalb als Stoerung. Ohne diese Sperre setzte ein Verbindungsabbruch jede Position auf null. Gehandelt wird nie. Der Abgleich bucht ausschliesslich nach. BrokerPosition traegt jetzt das Instrument (IbkrMapping.ToInstrument); ein Kontrakt, den unser Modell nicht kennt - Future, Devise, Fonds -, liefert null und wird uebersprungen statt als Aktie gedeutet. Gemessen auf dem Testserver gegen das Paper-Konto: vier Altlasten erkannt (GOOG, MIGA:EUR, die SAP-ADR aus dem Fehllauf und zwei ungebuchte SAP:EUR), alle an UNASSIGNED gebucht, das Buch DIAG unangetastet. Gegenprobe danach: "Bestand stimmt ueberein (5 Positionen)". 402 Tests gruen. Erledigt den offenen Teil von #300, Kern von #306. 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
|
2a73172e27 |
Instrumente sind waehrungsfaehig
Die Waehrung gehoert zur Identitaet eines Instruments und nicht zu
seiner Beschreibung: derselbe Ticker kann an mehreren Plaetzen in
verschiedenen Waehrungen notieren, und ein Kauf darf nur aus Bargeld
derselben Waehrung finanziert werden (Kapitalmodell §4 Schicht C). Zwei
Notierungen als eine Position zu fuehren, wuerde Bestand und Deckung
vermischen.
USD bleibt im Instrumentenschluessel IMPLIZIT ("AAPL", nicht
"AAPL:USD"). Andernfalls waere jede Bestandszeile ab sofort ein anderes
Instrument als vorher und aus einer Position wuerden zwei. Trennzeichen
ist der Doppelpunkt und nicht der Punkt - Ticker enthalten Punkte
(BRK.B).
Neu: Currencies (kanonische Schreibweise an allen vier Stellen, die sie
gleich haben muessen), Currency an OptionSpec, InstrumentRef,
TradeSignal, OrderRequest und core_position. CapitalService nimmt die
Waehrung ab jetzt aus dem Instrument statt vom Aufrufer - wer sie
uebergeben koennte, koennte die Deckungspruefung gegen den falschen Topf
laufen lassen. --verify-order kennt --currency.
Anlass: das Paper-Konto haelt EUR 91.832 und USD -3.751. Ein
USD-Nachweis waere ein USD-Kredit gewesen und wurde von Schicht C
zu Recht abgelehnt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
RichardandClaude Opus 5
|
bd04642735 |
Bargeld je Waehrung: $LEDGER:ALL statt $LEDGER, und melden was ankam
Beim ersten echten Order-Nachweis gegen das Paper-Konto (#293) lehnte Schicht C jeden Kauf mit "Waehrungsdeckung [USD]: benoetigt 344, verfuegbar 0" ab, obwohl das Konto Bargeld hat. Ursache: das nackte "$LEDGER" liefert nur die Zusammenfassung in Kontobasiswaehrung, und die traegt als Waehrungskennung "BASE" - also genau den Wert, den die Auswertung ueberspringen muss, damit dasselbe Geld nicht zweimal zaehlt. Die Aufschluesselung blieb dadurch leer, und eine leere Aufschluesselung heisst fuer Schicht C bewusst "Deckung unbekannt, also ablehnen". Mit ":ALL" kommen die Bestaende je Waehrung. Dazu eine Logzeile mit dem, was der Broker gemeldet hat. Ohne sie ist eine Ablehnung durch Schicht C von aussen nicht von einem echten Geldmangel zu unterscheiden - man sieht "verfuegbar 0" und weiss nicht, ob kein Geld da ist oder keine Auskunft kam. Genau diese Stunde hat der Fund gekostet. Gemessen am Paper-Konto DUR371528: EUR 91.832,22 / USD -3.751,01. 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> |
||
|
RichardandClaude Opus 5
|
87194bfc48 |
IBKR: Zeitkontext einer Verbindung nachvollziehbar machen
ResolveExecutionTime liefert neben dem UTC-Zeitpunkt jetzt die Herkunft der verwendeten Zeitzone (gemeldet / angenommen / unbekannt / unlesbar). Bisher war im Nachhinein nicht unterscheidbar, ob ein Buchungszeitpunkt von TWS stammte oder eine Annahme war - genau der Fehler, der beim Umzug zwischen EU- und US-Host lautlos entsteht. IbkrConnection schreibt beim Verbinden einmalig Betriebszeitzone, Systemzeitzone und den Versatz zur TWS-Serverzeit ins Log; ab 5 s Abweichung gilt die Uhr des Hosts als verstellt. TWS-Setup-Checkliste um den Linux-Abschnitt ergaenzt (Betrieb und Umgebung unterscheiden sich, das Protokoll nicht). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
d8273c3a1e |
L1b/1: Betriebszeitzone statt Rechnerzeit - EU- und US-Instanzen sauber trennen
Wir betreiben Instanzen in zwei Regionen. Bisher hing jede Ortszeit an der Zeitzone des Rechners (DateTime.Now, DateTimeKind.Local): derselbe Code haette auf einem Windows-Desktop mit Europe/Berlin und in einem Linux-Container mit UTC lautlos unterschiedliche Werte geliefert - ohne Fehler, nur um Stunden verschoben, mitten in Buchungszeitstempeln. AppTimeZone (Core/Time): Betriebszeitzone der Instanz, einmalig aus Trading.ApplicationTimeZoneId gesetzt, IANA- und Windows-Schreibweise tragen beide, unbekannter Wert weicht auf die Systemzone aus und warnt. Wird laut Festlegung vor den ersten Trades gesetzt und danach nie gewechselt - ein Wechsel verschoebe rueckwirkend alle Tagesgrenzen. Persistenz bleibt UTC, damit die Daten beider Instanzen vergleichbar sind. IbkrMapping.ParseExecutionTime verwirft die von TWS gemeldete Zeitzone nicht mehr, sondern rechnet gegen sie nach UTC; ohne Zonenangabe gilt die Betriebszeitzone. Das ist der Kern: eine NYSE-Ausfuehrung darf nicht mit demselben nackten Zeitwert in die Buecher wie eine an der Eurex. Rueckgabe ist jetzt immer Kind=Utc. DailyReportService.NextRun -> NextRunUtc(nowUtc, hour, zone): der Bericht laeuft zu einer festen ORTSZEIT. Sommerzeitumstellung wird behandelt - bei der uebersprungenen Stunde weicht er aus, statt den Tag ausfallen zu lassen. LoggingService fuehrt Anzeigezeit und UTC getrennt: Dateinamen und Anzeige in Ortszeit (Tagesgrenzen gehoeren zur Instanz, der Supervisor liest die JSONL-Dateien ueber diese Namen), das ts-Feld im JSONL in UTC. Beides musste getrennt werden, weil die umgerechnete Ortszeit Kind=Unspecified traegt und ein ToUniversalTime() darauf sie als Zeit des HOSTS gedeutet haette. Verbleibende DateTime.Now in Worker-Zeitplaenen und Statuszeilen ebenfalls auf AppTimeZone.Now umgestellt. Verifiziert: 183 Tests gruen (+20), darunter EU/US-Versatz, Winter-/Sommerzeit, unbekannte Zone und die uebersprungene Stunde bei der Zeitumstellung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
b96a20788c |
R10: Lesender Bestandsabgleich (IBrokerPortfolioReader) + Datenlage-Konzepte
Eigener Seam neben IBrokerClient: Wer handelt, braucht ihn nicht; wer die eigene Buchfuehrung gegen den Broker abstimmt, braucht nur ihn. Zuteilung und Verfall aendern Positionen ohne Order von uns - ohne Abgleich laeuft das Managementbuch zwangslaeufig auseinander. - IBrokerPortfolioReader mit GetPositionsAsync/GetExecutionsAsync; implementiert von IbkrBrokerClient und NullBrokerClient (DI registriert beide Rollen auf derselben Instanz). - IbkrConnection: reqAccountUpdates statt reqPositions (nur dieser Weg liefert Marktwert und unrealisierten G/V), reqExecutions inkl. Zuordnung der verspaetet eintreffenden commissionReport-Callbacks ueber die ExecId. - BrokerPosition/BrokerExecution als Broker-Wahrheit neben Position; IbkrMapping: ParseSide, ParseExecutionTime, FormatExecutionFilterTime (UTC wegen TWS-Warnung 2174) - mit Unit-Tests. - Verifiziert gegen Paper-Konto DUR371528: 2 Positionen, 2 Ausfuehrungen inkl. Kommissionen. Doku: Kapital- und Buchmodell (drei Wahrheiten, Kapitalzuteilung), KONZEPT-Datenlage-und-Strategien (gemessen, was die API auf diesem Konto liefert). Options-Wheel: Greeks bei verzoegerten Daten funktionieren (Feld 83); Earnings-Termine sind ueber die TWS API nicht erreichbar (Fehler 10358) - Behelf ueber IV-Filter statt Fremddatenquelle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
RichardandClaude Opus 5
|
80afcd49c1 |
R9: Echter IbkrBrokerClient über die TWS API
Broker-Adapter gegen TWS/IB Gateway, aktivierbar über IBKRSettings.UseTwsApi;
NullBrokerClient bleibt Default. TradingEnabled bleibt als zweite, unabhängige
Sicherung bestehen – ohne ihn platziert der ExecutionService keine Order.
Aufteilung (src/IBKRTrader.Core/Trading/Ibkr/):
- IbkrMapping – reine Abbildung Core <-> TWS (Kontrakt, Order, Kurs, Port-
und Statusregeln), vollständig unit-getestet
- IbkrConnection – Socket-Lebenszyklus, Reader-Thread, reqId-Korrelation über
TaskCompletionSource
- IbkrBrokerClient – implementiert IBrokerClient, übersetzt Fehler in leere
Ergebnisse (Konto 0 lässt die Risikoprüfung alles ablehnen)
Bewusste Entscheidungen:
- Träges Verbinden mit Wiederholung statt Verbindungsaufbau beim Start: TWS ist
nach einem Neustart minutenlang nicht bereit.
- Port wird gegen den Handelsmodus geprüft; Paper-Modus auf Live-Port (oder
umgekehrt) lässt den Broker inaktiv, statt auf dem falschen Konto zu handeln.
- MarketDataType Default 4: Paper-Konten ohne Datenabo bekommen sonst keine Kurse.
- Fehlercode 10167 ist ein Statushinweis (verzögerte Daten folgen), kein Fehler.
Als Fehler behandelt scheiterte jede einzelne Kursabfrage.
Verifiziert gegen Paper-Konto DUR371528: Verbindung, Konto (100.105,50 EUR),
Kurse (AAPL/MSFT/NVDA, verzögert), Fehlerpfade. Orderpfad bis zur Broker-Annahme
per What-If-Order geprüft (Aktie + Option, ohne Ausführung); dabei zugleich die
Optionsberechtigung des Kontos bestätigt. Offen: echte Ausführung (Fill ->
Buchung) und asynchrone Fill-Verfolgung – beides in IBKR-Integration.md notiert.
Doku: TWS-Setup-Checkliste.md (Einstellungen für Neuinstallation) neu,
IBKR-Integration.md / ARCHITECTURE.md / README.md nachgezogen.
154/154 Tests grün.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|