RichardandClaude Opus 5
62570cfdd8
Testdaten in die Testdatenbank eingespielt (3 Demo-Konten, 5 Master-Trader, 3 offene Positionen, 7 Trades, 5 RF-Kandidaten), gesichert als docs/pruefplaene/testdaten-ui.sql zur Wiederverwendung. Bewusst mit 42-stelligen Wallet-Adressen und langen englischen Marktfragen - kurze Platzhalter haetten die Layoutbefunde verdeckt. Mit Daten wirkt die Anwendung vollstaendig funktionsfaehig: Grids fuellen sich, die Auswahl markiert Zeilen, das Detailformular uebernimmt den gewaehlten Datensatz, zugewiesene Konten werden korrekt angehakt, KPI-Kacheln rechnen. Vier weitere Befunde: - B-13 (wichtig): Die Spalte "Name" im Master-Trader-Grid ist auf wenige Pixel zusammengequetscht - die Anzeigenamen sind NIRGENDS zu sehen, obwohl sie die wichtigste Information der Zeile sind. Die festen Breiten der elf uebrigen Spalten lassen der Sternbreite fast nichts uebrig. - B-11 praezisiert: Nicht die Werte sind zu breit, sondern die Ueberschriften. Das RF-Grid zeigt lange Marktfragen mühelos, waehrend "Fee (bps)" zu "Fee (bp" verstuemmelt wird. Die Breiten sind auf die Datenwerte ausgelegt. - B-14: Beschreibung und Reasoning sind einzeilige Felder fuer varchar(1000). - B-15: Ein fehlerhafter Datensatz legt die gesamte Modul-Hydration lahm. Beim ersten Einspielen war AssignedAccountIds kein gueltiges JSON - daraufhin wurde kein einziger Trader geladen. Im Betrieb hiesse das: ein beschaedigter Eintrag legt das komplette Modul stumm, statt uebersprungen und gemeldet zu werden. B-7 bestaetigt: In jeder KPI-Kachel steht der Modulname doppelt. Nachgeprueft und KEIN Fehler: Copy-PnL zeigt 0,00, weil die Kennzahlen aus den tatsaechlichen Copy-Trades berechnet werden und mod_copytrading_closed_trades leer ist. Die Werte stehen auch in der Datenbank auf 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>