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>

CLAUDE.md

@@ -8814,6 +8814,83 @@ das der Nutzer gleichzeitig bedient, gehört die Logspur mitgelesen.**
 nächsten Squeeze mit offener Position — Log `🧷 BRK-Slot uebernimmt
 Pending-Fill` und `position_brk.trail == true`.
 
+## ✅⚠⚠ G/V-TRENNUNG GEPRÜFT — die Sperre riss bei JEDEM Neustart auf (2026-08-20, v=201)
+
+User: „überprüfe 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."
+
+✅ **Das Frontend ist sauber**: `#hdr-pnl` liest ausschließlich `d.position`,
+`#hdr-pnl-brk` ausschließlich `d.position_brk`. Keine Summe, kein Fallback,
+keine gemeinsame Variable. ⚠ Aber das ist auch die *falsche* Stelle zum Suchen:
+stehen im Backend beide Felder auf derselben Position, kann keine Anzeige das
+mehr richten. Geprüft wurde deshalb die **Auswahl** in
+`TradeManager._refresh_locked`.
+
+⚠⚠ **DER FUND — die Adoptions-Sperre war unvollständig, und sie riss bei JEDEM
+Neustart auf.** Ein BRK-Ticket kann aus **drei** Quellen kommen; die Sperrliste
+kannte nur zwei:
+| Quelle | in `fremde_tickets`? | lebt |
+|---|---|---|
+| `trader_brk.ticket` | ✅ | nur im Speicher |
+| `_pending_tickets` | ✅ | nur im Speicher |
+| **`_brk_restore`** (aus `runtime_state.json`) | ❌ **fehlte** | überlebt den Neustart |
+Nach einem Neustart sind die ersten beiden **leer**. Und die Reihenfolge im
+`_pos_loop` besiegelt es: `trader.refresh()` läuft, und erst **drei Zeilen
+später** `_rebind_brk()`. Slot 1 greift die BRK-Position also, **bevor** sie
+zurückgebunden werden kann.
+⚠ `_rebind_brk` erkennt das zwar und bricht ab („hängt bereits an Slot 1") —
+aber damit ist der Schaden nur festgestellt, nicht behoben: die BRK-Position
+hängt 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
+— dieselbe Signatur wie der Fehler vom Vortag, der `_rebind_brk` überhaupt erst
+nötig gemacht hat.
+✅ **Behoben**: `_brk_restore` steht jetzt mit in der Sperrliste. Der Zugriff
+läuft über `getattr(..., None)`, ist also unabhängig davon, WANN das Attribut
+gesetzt wird — genau die Reihenfolge-Falle, die in zwei Tagen zweimal
+zugeschlagen hat.
+
+✅✅ **ZWEITER FUND — zwei verschiedene Rechnungen nebeneinander.** Bei
+geschlossenem Markt zeigt Slot 1 seit dem 01.08. eine **HL-Schätzung**
+(`pnl_hl`), weil der Broker-P&L stillsteht. Der BRK-Slot bekam die nie — er
+zeigte den **eingefrorenen** Broker-Wert, ohne dass man es der Anzeige ansieht.
+Neu `pnl_hl_brk` (dieselbe `live_pnl`-Rechnung auf dem eigenen Slot, mit ≈
+markiert). ⚠ Geprüft statt angenommen, dass `_tick_size`/`_tick_value` am
+BRK-Slot überhaupt gesetzt sind — `_refresh_locked` zieht sie bei gesetztem
+Ticket jeden Tick nach.
+
+✅ **`day_pl.open` summiert korrekt BEIDE Slots** — die Summe gehört dorthin,
+die Trennung in die beiden G/V-Felder.
+
+**BELEG — `tests/test_slot_gv.py`, 6 Tests auf dem ECHTEN `TradeManager`**
+(Broker gestubbt, Sperrliste wortgleich zur Engine nachgebaut): zwei Positionen
+gleichzeitig landen je im eigenen Slot · Slot 1 adoptiert die BRK-Position nicht
+· ein Pending-Fill wird nicht vorher weggeschnappt · der BRK-Slot adoptiert
+**nie** · und die **Regressionsprobe**, die den alten Zustand festhält: ohne den
+Merker in der Sperrliste greift Slot 1 zu.
+✅ **Neue Pipeline-Stufe (E, `tools/check_slots.py`)**: die Sperrliste muss alle
+**drei** Namen erwähnen. Mutationsprobe: Merker entfernt → Stufe E **Exit 1**.
+⚠⚠ **Ehrlich zur Arbeitsteilung der beiden Prüfungen:** der pytest belegt den
+**Mechanismus** (eine Sperrliste ohne das Ticket lässt die Adoption zu) — er
+baut die Lambda selbst nach und bleibt bei der Mutation deshalb grün. Erst die
+statische Stufe belegt, dass die **Engine** sie richtig verdrahtet. **Keine der
+beiden allein hätte gereicht.**
+
+⚠ Live nach dem Deploy verifiziert: Slot 1 `T=50396824` (+10,34), BRK flat,
+`day_pl.open` 10,34 — kein gemeinsames Ticket. Der Neustart adoptierte das
+Ticket korrekt in Slot 1 (BRK war flat, die Sperre blockt also nicht zu viel).
+⚠ **Noch nicht beobachtet**: ein Neustart *mit* offener BRK-Position — der Fall,
+den der Fix adressiert. Beweis wäre dann „BRK-Slot nach Neustart
+zurueckgebunden" **ohne** vorangehendes „magic-match" auf dasselbe Ticket.
+
+⚠⚠ **VIERTER Surrogat-Abbruch beim Schreiben dieses Abschnitts — und wieder
+OHNE Schaden.** Ein Emoji als ZWEI getrennte Unicode-Escapes erzeugt lone
+surrogates; das Öffnen im Schreibmodus kürzt die Datei aber schon VOR dem
+Schreiben. Die Regel vom 19.08. (erst `.tmp`, Größe prüfen, dann `os.replace`)
+hat gehalten: CLAUDE.md blieb unversehrt, es entstand nur eine leere `.tmp`.
+✅ Konsequenz: dieser Abschnitt wurde als **reiner UTF-8-Text** geschrieben,
+ohne jedes Escape — das ist der Weg, der die Falle gar nicht erst aufstellt.
+
 ## ⚠⚠⚠ P(break) IST LIVE **INVERTIERT** — und es steuert echtes Geld (2026-08-19)
 
 Die fällige Messung ist entscheidbar geworden: **n=530 entkoppelt** gegen die