User: "dann sieh dir die Luecke an" (nach "DB-Nachtrag fehlgeschlagen" im Log,
20.08. 07:40:12, T=50371599).
URSACHE - ein Rennen zwischen zwei Pfaden: _check_pending_fill erkennt den Fill
aus trader_brk.snapshot(), die DB-ZEILE schreibt aber trader._refresh_locked ->
log_trade_open. War der noch nicht durch, traf das UPDATE keine Zeile und der
Nachtrag scheiterte STILL. Der Trade blieb setup=NULL und war damit von einem
manuellen nicht unterscheidbar - genau die Buchfuehrungs-Luecke, gegen die
tag_bot_trade ueberhaupt gebaut wurde (Deployment-Drift Fall 8), nur eine Ebene
tiefer. Folge: squeeze_entry_count blieb 0, der Trade fehlte in B4/B5.
BEHOBEN: gescheiterte Nachtraege landen in `_tag_nachtrag` und werden im
_pos_loop wiederholt, bis die Zeile da ist - dasselbe Retry-Muster wie beim
Gewinn-Close (23.07.). Nach 60 Versuchen (~1 min) wird aufgegeben und LAUT
gemeldet: eine Zeile, die nach einer Minute nicht existiert, kommt nicht mehr,
und dann soll es nicht still bleiben.
T=50371599 nachgetragen (DB-Backup oil_widget_history.db.bak-2026-08-20).
✅ NEBENBEFUND, und zwar ein guter: derselbe Logausschnitt enthaelt
"🧷 BRK-Slot uebernimmt Pending-Fill T=50371599" - das ist der ERSTE
Live-Beleg, dass der Zwei-Slot-Umbau vom 19.08. funktioniert. Der BRK-Slot hat
die gefuellte Pending-Order korrekt uebernommen.
⚠ ZWEITER NEBENBEFUND, NICHT behoben (User-Entscheidung): die Order wurde mit
0,01 Lots platziert. Das ist die direkte Folge von margin_brk = 10 % auf eine
fast erschoepfte freie Margin - die Einstellung wirkt also, nur vermutlich
anders als gedacht. Dazu steht margin_pct in runtime_state auf 95, waehrend die
ini 40 sagt (runtime gewinnt). Beides gemeldet, nichts geaendert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
