G/V-Trennung geprueft: Adoptions-Sperre riss bei JEDEM Neustart auf

User: "ueberpruefe ob wirklich die G/V und G/V BRK Anzeigen stimmen, besonders
bei gleichzeitig laufenden Trades. Die Anzeige darf jeweils nur den eigenen
Slot anzeigen."

FRONTEND SAUBER: #hdr-pnl liest nur d.position, #hdr-pnl-brk nur
d.position_brk - keine Summe, kein Fallback. Aber das ist die falsche Stelle
zum Suchen: stehen im Backend beide Felder auf derselben Position, kann keine
Anzeige das mehr richten. Geprueft wurde deshalb die AUSWAHL in
TradeManager._refresh_locked.

⚠⚠ FUND 1 - die Sperrliste kannte nur zwei von DREI Quellen eines BRK-Tickets:
  trader_brk.ticket     nur im Speicher
  _pending_tickets      nur im Speicher
  _brk_restore          FEHLTE - und nur das ueberlebt den Neustart
Nach einem Neustart sind die ersten beiden leer, und die Reihenfolge im
_pos_loop besiegelt es: trader.refresh() laeuft DREI Zeilen vor _rebind_brk().
Slot 1 greift die BRK-Position also, bevor sie zurueckgebunden werden kann.
_rebind_brk erkennt das zwar und bricht ab - damit ist der Schaden aber nur
festgestellt, nicht behoben: die BRK-Position haengt am falschen Slot, ihr G/V
steht links statt rechts, und "G/V BRK" zeigt "—". Danach sieht alles normal
aus, was es besonders schwer sichtbar macht.
Behoben ueber getattr(..., None), also unabhaengig davon, WANN das Attribut
gesetzt wird - genau die Reihenfolge-Falle, die in zwei Tagen zweimal
zugeschlagen hat.

 FUND 2 - zwei verschiedene Rechnungen nebeneinander. Bei geschlossenem
Markt zeigt Slot 1 seit dem 01.08. eine HL-Schaetzung (pnl_hl), der BRK-Slot
bekam die nie und zeigte den EINGEFRORENEN Broker-Wert, ohne dass man es der
Anzeige ansieht. Neu pnl_hl_brk, mit ≈ markiert. Geprueft statt angenommen,
dass _tick_size/_tick_value am BRK-Slot gesetzt sind.

 day_pl.open summiert korrekt BEIDE Slots - die Summe gehoert dorthin, die
Trennung in die beiden G/V-Felder.

BELEG - tests/test_slot_gv.py, 6 Tests auf dem ECHTEN TradeManager (Broker
gestubbt): zwei Positionen gleichzeitig je im eigenen Slot · Slot 1 adoptiert
die BRK-Position nicht · Pending-Fill wird nicht weggeschnappt · der BRK-Slot
adoptiert nie · plus die Regressionsprobe, die den alten Zustand festhaelt.
NEUE PIPELINE-STUFE E (tools/check_slots.py): die Sperrliste muss alle drei
Namen erwaehnen. Mutationsprobe: Merker entfernt -> Exit 1.
⚠⚠ Ehrlich zur Arbeitsteilung: der pytest belegt den MECHANISMUS, baut die
Lambda aber selbst nach und bleibt bei der Mutation gruen. Erst die statische
Stufe belegt, dass die ENGINE sie richtig verdrahtet. Keine der beiden allein
haette gereicht.

⚠⚠ NEBENBEFUND, korrigiert: mein Schreib-Helfer hat SECHS Dateien still von
LF auf CRLF gedreht (io.open(...,"w") uebersetzt auf Windows). Mein erster
Check mit `grep -c $'\r$'` meldete faelschlich 0 - erst die BYTE-Zaehlung zeigte
8959 CR in CLAUDE.md. Alle sechs auf LF zurueckgesetzt. core.autocrlf=true
haette es im Repo normalisiert, im Arbeitsbaum aber nicht.

Live verifiziert: Slot 1 T=50396824 (+10,34), BRK flat, day_pl.open 10,34 -
kein gemeinsames Ticket. Deploy mit --feld pnl_hl_brk, alle 5 Schritte gruen.
⚠ Noch nicht beobachtet: ein Neustart MIT offener BRK-Position - der Fall, den
der Fix adressiert.

v=201.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Axel Hocks
2026-08-20 13:07:16 +02:00
co-authored by Claude Opus 5
parent 3e275e7515
commit 0966caf1b8
6 changed files with 320 additions and 15 deletions
+35 -1
View File
@@ -125,12 +125,46 @@ def _close_beide(baum: ast.AST) -> list:
return []
def _sperrliste_vollstaendig(baum: ast.AST) -> list:
"""(D) Die Adoptions-Sperre muss ALLE DREI Quellen eines BRK-Tickets kennen.
⚠⚠ Sie hatte am 2026-08-20 eine Luecke, die bei JEDEM Neustart aufriss:
`trader_brk.ticket` und `_pending_tickets` leben nur im Speicher, nach einem
Neustart sind beide leer. Das Ticket steht dann allein im Merker
`_brk_restore` — und weil `trader.refresh()` im `_pos_loop` DREI Zeilen vor
`_rebind_brk()` laeuft, griff Slot 1 die BRK-Position, bevor sie
zurueckgebunden werden konnte. Folge: ihr G/V stand links statt rechts, und
„G/V BRK" zeigte „—". Belegt in `tests/test_slot_gv.py`.
"""
for kls in [n for n in ast.walk(baum) if isinstance(n, ast.ClassDef)]:
if kls.name != "TradingEngine":
continue
init = next((f for f in kls.body if isinstance(f, ast.FunctionDef)
and f.name == "__init__"), None)
if not init:
continue
for kn in ast.walk(init):
if (isinstance(kn, ast.Assign)
and any(isinstance(t, ast.Attribute) and t.attr == "fremde_tickets"
for t in kn.targets)):
q = ast.unparse(kn)
fehlt = [n for n in ("trader_brk", "_pending_tickets", "_brk_restore")
if n not in q]
if fehlt:
return ["fremde_tickets: Sperrliste erwaehnt {} NICHT — eine "
"BRK-Position kann von Slot 1 adoptiert werden "
"(G/V stuende dann im falschen Feld)"
.format(", ".join(fehlt))]
return []
return []
def pruefe() -> list:
p = WURZEL / "core" / "engine.py"
quelle = p.read_text(encoding="utf-8")
baum = ast.parse(quelle)
return (_init_reihenfolge(baum, quelle) + _slot_trennung(baum)
+ _close_beide(baum))
+ _close_beide(baum) + _sperrliste_vollstaendig(baum))
if __name__ == "__main__":