Der Bereich war sichtbar, wurde aber übersehen: ein 12-Pixel-Knopf, der an der
Überschrift klebte, während "Handel pausieren" und "Training starten" jeweils in
einer eigenen Box mit normalgroßem Knopf sitzen. 71x26 px gegenüber 90x58 und
79x58 - das liest sich nicht als Bedienelement.
Der Bereich sieht jetzt aus wie die beiden anderen: eigene Panel-Box, Knopf
"Konfiguration bearbeiten" in gleicher Größe (114x58 px, 14px Schrift), daneben
eine Zeile, die sagt, was dahintersteckt. Geöffnet heißt der Knopf
"Konfiguration schließen".
Zwei neue Tests halten die drei Haupt-Bedienelemente auf gleicher Linie: keine
Inline-Styles, die Schrift oder Polsterung verkleinern, und jeder Knopf muss in
einer Panel-Box stehen statt in einer Überschrift.
233 Tests (6 neue), ruff sauber. Im Browser durchgespielt: öffnen, 76 Felder,
risk.cooldown_bars_after_exit geändert und sofort wirksam, schließen.
Der Abschnitt war für Benutzer unerreichbar: Er startet mit hidden, und sichtbar
gemacht hat ihn nur renderConfig() - die ausschließlich nach einem Klick auf
"anzeigen" lief, einen Knopf innerhalb des versteckten Abschnitts. Er konnte sich
also nie selbst einblenden. refresh() rief renderConfig nicht auf.
Die Sichtbarkeit entscheidet jetzt der Statuslauf, der ohnehin alle fünf Sekunden
durchläuft, anhand von trading.control_enabled.
Warum das durchgerutscht ist: Die Prüfung des Formulars lief über
getElementById("cfg-toggle").click(). Das funktioniert auch bei unsichtbaren
Elementen - die gesamte Konfigurationsoberfläche wurde damit über einen Knopf
bedient, den kein Mensch je gesehen hätte. Dieselbe Lücke wie beim vorigen
Dashboard-Fehler: Mechanik geprüft, Sichtbarkeit nicht.
Neuer Test: Für jeden <section ... hidden> wird geprüft, dass er im Statuslauf
sichtbar gemacht wird, also in refresh() oder einer der von dort gerufenen
render-Funktionen. Gegenprobe gelaufen - vor dem Fix meldet er config-section als
unerreichbar, nach dem Fix sind alle drei Abschnitte in Ordnung.
227 Tests (5 neue), ruff sauber. Im Browser ohne jeden Skriptklick geprüft: Der
Abschnitt erscheint nach dem Laden, der Knopf liegt mit 71x26 px im Dokumentfluss,
keine Blockade durch display, visibility, pointer-events oder opacity in der
Elternkette, und das Panel öffnet mit 76 Eingabefeldern.
Das Dashboard blieb bei "lädt ..." stehen und zeigte weder Kacheln noch die
Steuerungs-Abschnitte.
Ursache: _DASHBOARD ist ein Python-String. Der in d081edf ergänzte
prompt()-Dialog für die Live-Bestätigung enthält \n, das Python zu echten
Zeilenumbrüchen aufgelöst hat. Das dadurch offene JavaScript-String-Literal ist
ein Syntaxfehler, der den gesamten <script>-Block mitreißt - im Browser waren
refresh und $ schlicht undefined, es lief kein einziger Ausdruck. Behoben durch
ein r-Präfix am Template, mit Kommentar an Ort und Stelle.
Warum das durchgerutscht ist: Die bisherige Prüfung hat nur kontrolliert, ob die
Bedienelemente im HTML stehen und ob die HTTP-Endpunkte antworten. Beides war
grün, während die Seite tot war. Markup-Präsenz ersetzt nicht das Ausführen der
Seite.
Neu: tests/test_dashboard.py
- Mini-Lexer über das ausgelieferte Skript, der String-Literale findet, die vor
dem Zeilenende nicht geschlossen werden (Backtick-Template-Literale dürfen
mehrzeilig sein). Gegenprobe im Test enthalten; gegen den echten Defekt
geprüft, er wird erkannt.
- Ausgeglichene Klammern, jede im Skript referenzierte Element-ID existiert im
HTML, und \n kommt als zwei Zeichen beim Browser an.
186 Tests (12 neue), ruff sauber. Im Browser durchgeklickt: Skript lädt, 10
Kacheln, Handel pausieren/starten und der Lernschalter ändern den Serverzustand
und die Anzeige, historisches Training läuft durch bis "Fertig in 0.8s: +146
Beobachtungen, gespeichert", null Loop-Fehler.
Tobias Zimmermann