AH-Oil-Trader

340 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Axel HocksandClaude Opus 5	3391e04f32	Bibliotheken geprueft: zwei Ertraege, keine neue Laufzeit-Abhaengigkeit Nicht nach Katalog beantwortet, sondern gegen die dokumentierten Schwachstellen des Projekts - und beide Kandidaten wurden GEMESSEN, nicht empfohlen. ERTRAG 1 - BLOCK-BOOTSTRAP (core/stichprobe.block_ci95), braucht GAR KEINE Bibliothek. Die Luecke stand seit dem 07.08. woertlich in backtest_cost_gate: "fuer ueberlappende Beobachtungen zu optimistisch ... dafuer braeuchte es einen Block-Bootstrap". Behelf war entkoppeln(). Auf echten Daten (pbreak_predictions): naiv, alle Zeilen n=4702 Breite 0,028 <- 3x zu eng entkoppelt (bisher) n= 552 Breite 0,083 <- 88 % Datenverlust Block L=30 n=4702 Breite 0,081 <- gleiche Breite, ALLE Daten Und das Entkoppeln kostet nicht nur Genauigkeit, es VERSCHIEBT die Schaetzung (0,399 gegen 0,427) - es nimmt systematisch die ERSTE Beruehrung je Level+Stunde. KALIBRIERUNG GEMESSEN (AR(1), bekanntes Mittel, 200 Laeufe, Soll 95 %): rho naiv L=10 L=30 L=60 0,00 94 % 94 % 91 % 92 % 0,50 76 % 92 % 91 % 91 % 0,90 40 % 80 % 89 % 90 % 0,97 18 % 55 % 74 % 83 % Die naive Zeile ist der Befund: bei rho=0,97 behauptet sie 95 % Sicherheit und liegt in 18 % der Faelle richtig. Ehrlich zu den Grenzen: bei unabhaengigen Daten kostet der Block ~3 Punkte (dort bleibt ci95 besser), und bei rho=0,97 deckt auch er nur 83 % - eine Verbesserung, keine Garantie. ERTRAG 2 - hypothesis (dev-only), aufgenommen NACH einer Gegenprobe. Die Suite prueft bisher BEISPIELE, und die waehle ich selbst aus. Die teuersten Fehler sassen auf GRENZEN: room_info musste `frei` auf dem UNGERUNDETEN Abstand entscheiden, weil 0,5951 gerundet durchs 0,6-Gate rutscht. hypothesis findet genau diesen Fall (dist=0.59765625) in Sekunden. Erst danach aufgenommen. Neu tests/test_invarianten.py (4 Eigenschafts-Tests auf REINEN Funktionen), per importorskip - die Suite laeuft auch ohne. Beim ersten Lauf fielen zwei Tests, beide waren MEINE Fehler: cluster rundet auf 3 Stellen (Invariante zu streng) und zwei inhaltsgleiche dicts sind == (Reihenfolge muss ueber die Identitaet geprueft werden). Genau dafuer sind Property-Tests da. Mutationsprobe: Rundung verbogen -> 2 Tests fallen. BEGRUENDET ABGELEHNT: numba (Backtests 11 s/12k Bars = nicht der Engpass, und ein Rewrite verletzt die Bit-Gleichheits-Regel) · statsmodels/arch (jetzt 15 Zeilen stdlib mit eigener Kalibrierung) · polars/pyarrow (kein DataFrame- Workload) · loguru/structlog/rich (das Logformat ist forensisch tragend) · tenacity (Wiederholungen haben eigene Semantik, _mark_dead) · httpx (requests laeuft) · pandas_ta (Indikatoren sind validiert, ein Austausch verschoebe jede dokumentierte Zahl) · mypy (kaum Annotationen, ty deckt die Aritaet ab). requirements.txt (Laufzeit) bleibt UNVERAENDERT - auf einer frischen Maschine soll der Bot mit moeglichst kleiner Oberflaeche wieder laufen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 19:57:31 +02:00
Axel HocksandClaude Opus 5	792355e8f9	Sieben Verbesserungen umgesetzt: Breaker scharf, B5 entschieden, 5 Werkzeuge 1) CIRCUIT-BREAKER SCHARF -- daily_loss_limit_pct 0 -> 8. Live verifiziert: enabled=True, limit_eur 89,44. Steht nicht in runtime_state.json, die ini greift direkt. Begruendung: MaxDD 82,8 % auf dem gemessenen IST-Pfad, schlechtester Einzeltrade -381 EUR. 2) B5-DEADLOCK RECHNERISCH AUFGELOEST -- die Regel ist ENTSCHIEDEN, nicht vertagt. Stand 11/20: Verhaeltnis 0,14 (Latte 1,0), PF 0,39 (Latte 1,0). Was die 9 Rest-Trades leisten muessten: 9/0 Gewinner -> 165,72 EUR je Trade = 12,2x der bisherige Schnitt 7/2 -> 186,17 EUR 5/4 -> 222,99 EUR Der groesste Squeeze-Gewinn des Zeitraums war 77,34 EUR -- selbst der beste Fall verlangt 2,1x den Rekord, neunmal in Folge. Latte nicht mehr erreichbar. auto_squeeze bleibt FALSE. Wiederaufnahme waere eine NEUE Entscheidung mit NEUER, vorab fixierter Latte. 3) core/kontrolle.py -- Kontroll-Fixture mit den Referenzwerten. Bricht bewusst NICHT ab: ein Backtest darf abweichen, er muss es nur wissen und sagen. 4) core/live_config.py -- EINE Quelle der Live-Parameter (ini + runtime_state in der Vorrangfolge des Engine-Starts). Dritte Instanz derselben Fehlerklasse: ATRMIN_STD 0,12 statt 0,06, fehlendes set_entry_room, nachgebauter Cluster. 5) stichprobe.paarweise()/zeig_paarweise() -- gepaarter Vergleich. Anlass: trail_start sah sequentiell besser aus, gepaart kippte das Vorzeichen (Selektions- statt Exit-Effekt). Selbsttest in drei Richtungen bestanden. 6) tools/check_konstanten.py -- Waechter fuer veraltete Zahlen. Erster Lauf: zwei Befunde, BEIDE Fehler in meiner eigenen Ableitung (Margin aus Balance geschaetzt statt vom Broker gelesen; Elliott ohne Gueltigkeitsfenster gezaehlt). Beide korrigiert. Danach ein ECHTER Fund: meine am 13.08. notierten "~405 EUR/Lot" sind falsch, der exakte Broker-Wert ist 712,84 -- die urspruenglich notierten 670 lagen naeher als meine Korrektur. Lehre: eine abgeleitete Zahl ist keine gemessene. Stand jetzt 0 Befunde. 7) Puls-Waechter bedingungs-bewusst: PULS traegt je Zeile die Vorbedingung, bedingte Tabellen erscheinen als Hinweis statt als Ausfall. 0 Zeilen bleibt IMMER ein Befund (der rec_outcomes-Fall). Grund: ein Waechter mit Fehlalarmen wird ignoriert -- so ist der Divergenz-Waechter verstummt. Pipeline gruen (85 Tests), Deployment ueber deploy.py --feld circuit_breaker verifiziert, genau eine Instanz je Port. Nicht angefasst: Sizing (User-Entscheidung) und die 44 Backtests mit eigener Exit-Kopie (Migrations-Regel). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 00:57:38 +02:00
Axel HocksandClaude Opus 5	3f1f19087d	Live-Backtest-Vergleich in die Pipeline: core/stichprobe.py + Abschnitt E Konsequenz aus dem Messfehler vom 07.08.: der Vergleich lief nur, wenn jemand daran dachte - und als er lief, war er falsch gebaut. 1) core/stichprobe.py - die Praevention ist KONSTRUKTIV, nicht ermahnend: entkoppeln() / anteil_ci() / unterscheidbar() / schluessel_level_stunde(). Regel: vor jeder berichteten Rate entkoppeln, jede Aussage ueber einen Unterschied mit Konfidenzintervall belegen. Die Zeilen in pbreak_predictions und recommendations sind nicht unabhaengig. 8 Tests, darunter einer, der die reale Konstellation nachspielt (roh 77 %, entkoppelt 33 %). Fallstrick beim Bau, gefunden weil ich es laufen liess: ein sqlite3-Cursor liefert Tupel, keine dicts - die Feldangabe akzeptiert jetzt Namen UND Spaltennummern. 2) analyze_divergence.sec_d0 war selbst der Fehler. Es mittelte AVG(p_break) ueber ALLE Rohzeilen und flaggte bei Delta > 8 Pp: vorher 1058 rohe Zeilen, Delta +8,7 Pp -> ALARM jetzt 110 entkoppelte, 37,6 % liegt in [37,3 ... 55,5] % -> OK Der Waechter haette heute also einen Fehlalarm produziert - genau den, dem ich elf Hypothesen lang nachgegangen bin. 3) NEU: Abschnitt E "GLEICHES FENSTER" (--backtest). Rechnet den Backtest ueber genau den Live-Zeitraum und haelt ihn gegen das Intervall der entkoppelten Live-Rate. Erster Lauf: live 46,4 % [37,3 ... 55,5] gegen Backtest 43,9 % -> im Intervall, kein Befund. 4) Eingebaut in den Wochenreport (weekly_review._divergenz_section, montags 07:30 per Mail + Telegram), mit demselben Fail-safe wie der Squeeze-Abschnitt. Bewusst NICHT in den pre-commit-Hook: der braucht MT5 und Minuten, Stufe 1 muss bei ~5 s bleiben. Ausserdem ein Rechenfehler in meinem ersten Entwurf behoben (p_break steht in der DB bereits in Prozent, ich hatte zusaetzlich skaliert -> "3763,9 %") und ein \n-Heredoc-Fall, der genau gegen die dokumentierte Regel verstiess. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 11:55:05 +02:00

Author

SHA1

Message

Date

Axel HocksandClaude Opus 5

3391e04f32

Bibliotheken geprueft: zwei Ertraege, keine neue Laufzeit-Abhaengigkeit

Nicht nach Katalog beantwortet, sondern gegen die dokumentierten Schwachstellen
des Projekts - und beide Kandidaten wurden GEMESSEN, nicht empfohlen.

ERTRAG 1 - BLOCK-BOOTSTRAP (core/stichprobe.block_ci95), braucht GAR KEINE
Bibliothek. Die Luecke stand seit dem 07.08. woertlich in backtest_cost_gate:
"fuer ueberlappende Beobachtungen zu optimistisch ... dafuer braeuchte es einen
Block-Bootstrap". Behelf war entkoppeln(). Auf echten Daten (pbreak_predictions):
  naiv, alle Zeilen   n=4702  Breite 0,028   <- 3x zu eng
  entkoppelt (bisher) n= 552  Breite 0,083   <- 88 % Datenverlust
  Block L=30          n=4702  Breite 0,081   <- gleiche Breite, ALLE Daten
Und das Entkoppeln kostet nicht nur Genauigkeit, es VERSCHIEBT die Schaetzung
(0,399 gegen 0,427) - es nimmt systematisch die ERSTE Beruehrung je Level+Stunde.

KALIBRIERUNG GEMESSEN (AR(1), bekanntes Mittel, 200 Laeufe, Soll 95 %):
  rho    naiv   L=10   L=30   L=60
  0,00   94 %   94 %   91 %   92 %
  0,50   76 %   92 %   91 %   91 %
  0,90   40 %   80 %   89 %   90 %
  0,97   18 %   55 %   74 %   83 %
Die naive Zeile ist der Befund: bei rho=0,97 behauptet sie 95 % Sicherheit und
liegt in 18 % der Faelle richtig. Ehrlich zu den Grenzen: bei unabhaengigen
Daten kostet der Block ~3 Punkte (dort bleibt ci95 besser), und bei rho=0,97
deckt auch er nur 83 % - eine Verbesserung, keine Garantie.

ERTRAG 2 - hypothesis (dev-only), aufgenommen NACH einer Gegenprobe. Die Suite
prueft bisher BEISPIELE, und die waehle ich selbst aus. Die teuersten Fehler
sassen auf GRENZEN: room_info musste `frei` auf dem UNGERUNDETEN Abstand
entscheiden, weil 0,5951 gerundet durchs 0,6-Gate rutscht. hypothesis findet
genau diesen Fall (dist=0.59765625) in Sekunden. Erst danach aufgenommen.
Neu tests/test_invarianten.py (4 Eigenschafts-Tests auf REINEN Funktionen), per
importorskip - die Suite laeuft auch ohne.
Beim ersten Lauf fielen zwei Tests, beide waren MEINE Fehler: cluster rundet auf
3 Stellen (Invariante zu streng) und zwei inhaltsgleiche dicts sind ==
(Reihenfolge muss ueber die Identitaet geprueft werden). Genau dafuer sind
Property-Tests da. Mutationsprobe: Rundung verbogen -> 2 Tests fallen.

BEGRUENDET ABGELEHNT: numba (Backtests 11 s/12k Bars = nicht der Engpass, und
ein Rewrite verletzt die Bit-Gleichheits-Regel) · statsmodels/arch (jetzt 15
Zeilen stdlib mit eigener Kalibrierung) · polars/pyarrow (kein DataFrame-
Workload) · loguru/structlog/rich (das Logformat ist forensisch tragend) ·
tenacity (Wiederholungen haben eigene Semantik, _mark_dead) · httpx (requests
laeuft) · pandas_ta (Indikatoren sind validiert, ein Austausch verschoebe jede
dokumentierte Zahl) · mypy (kaum Annotationen, ty deckt die Aritaet ab).

requirements.txt (Laufzeit) bleibt UNVERAENDERT - auf einer frischen Maschine
soll der Bot mit moeglichst kleiner Oberflaeche wieder laufen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-20 19:57:31 +02:00

Axel HocksandClaude Opus 5

792355e8f9

Sieben Verbesserungen umgesetzt: Breaker scharf, B5 entschieden, 5 Werkzeuge

1) CIRCUIT-BREAKER SCHARF -- daily_loss_limit_pct 0 -> 8. Live verifiziert:
   enabled=True, limit_eur 89,44. Steht nicht in runtime_state.json, die ini
   greift direkt. Begruendung: MaxDD 82,8 % auf dem gemessenen IST-Pfad,
   schlechtester Einzeltrade -381 EUR.

2) B5-DEADLOCK RECHNERISCH AUFGELOEST -- die Regel ist ENTSCHIEDEN, nicht
   vertagt. Stand 11/20: Verhaeltnis 0,14 (Latte 1,0), PF 0,39 (Latte 1,0).
   Was die 9 Rest-Trades leisten muessten:
     9/0 Gewinner -> 165,72 EUR je Trade = 12,2x der bisherige Schnitt
     7/2          -> 186,17 EUR
     5/4          -> 222,99 EUR
   Der groesste Squeeze-Gewinn des Zeitraums war 77,34 EUR -- selbst der beste
   Fall verlangt 2,1x den Rekord, neunmal in Folge. Latte nicht mehr erreichbar.
   auto_squeeze bleibt FALSE. Wiederaufnahme waere eine NEUE Entscheidung mit
   NEUER, vorab fixierter Latte.

3) core/kontrolle.py -- Kontroll-Fixture mit den Referenzwerten. Bricht bewusst
   NICHT ab: ein Backtest darf abweichen, er muss es nur wissen und sagen.

4) core/live_config.py -- EINE Quelle der Live-Parameter (ini + runtime_state in
   der Vorrangfolge des Engine-Starts). Dritte Instanz derselben Fehlerklasse:
   ATRMIN_STD 0,12 statt 0,06, fehlendes set_entry_room, nachgebauter Cluster.

5) stichprobe.paarweise()/zeig_paarweise() -- gepaarter Vergleich. Anlass:
   trail_start sah sequentiell besser aus, gepaart kippte das Vorzeichen
   (Selektions- statt Exit-Effekt). Selbsttest in drei Richtungen bestanden.

6) tools/check_konstanten.py -- Waechter fuer veraltete Zahlen.
   Erster Lauf: zwei Befunde, BEIDE Fehler in meiner eigenen Ableitung (Margin
   aus Balance geschaetzt statt vom Broker gelesen; Elliott ohne
   Gueltigkeitsfenster gezaehlt). Beide korrigiert.
   Danach ein ECHTER Fund: meine am 13.08. notierten "~405 EUR/Lot" sind falsch,
   der exakte Broker-Wert ist 712,84 -- die urspruenglich notierten 670 lagen
   naeher als meine Korrektur. Lehre: eine abgeleitete Zahl ist keine gemessene.
   Stand jetzt 0 Befunde.

7) Puls-Waechter bedingungs-bewusst: PULS traegt je Zeile die Vorbedingung,
   bedingte Tabellen erscheinen als Hinweis statt als Ausfall. 0 Zeilen bleibt
   IMMER ein Befund (der rec_outcomes-Fall). Grund: ein Waechter mit
   Fehlalarmen wird ignoriert -- so ist der Divergenz-Waechter verstummt.

Pipeline gruen (85 Tests), Deployment ueber deploy.py --feld circuit_breaker
verifiziert, genau eine Instanz je Port.
Nicht angefasst: Sizing (User-Entscheidung) und die 44 Backtests mit eigener
Exit-Kopie (Migrations-Regel).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-17 00:57:38 +02:00

Axel HocksandClaude Opus 5

3f1f19087d

Live-Backtest-Vergleich in die Pipeline: core/stichprobe.py + Abschnitt E

Konsequenz aus dem Messfehler vom 07.08.: der Vergleich lief nur, wenn jemand
daran dachte - und als er lief, war er falsch gebaut.

1) core/stichprobe.py - die Praevention ist KONSTRUKTIV, nicht ermahnend:
   entkoppeln() / anteil_ci() / unterscheidbar() / schluessel_level_stunde().
   Regel: vor jeder berichteten Rate entkoppeln, jede Aussage ueber einen
   Unterschied mit Konfidenzintervall belegen. Die Zeilen in
   pbreak_predictions und recommendations sind nicht unabhaengig.
   8 Tests, darunter einer, der die reale Konstellation nachspielt
   (roh 77 %, entkoppelt 33 %).
   Fallstrick beim Bau, gefunden weil ich es laufen liess: ein sqlite3-Cursor
   liefert Tupel, keine dicts - die Feldangabe akzeptiert jetzt Namen UND
   Spaltennummern.

2) analyze_divergence.sec_d0 war selbst der Fehler. Es mittelte AVG(p_break)
   ueber ALLE Rohzeilen und flaggte bei Delta > 8 Pp:
     vorher  1058 rohe Zeilen, Delta +8,7 Pp -> ALARM
     jetzt   110 entkoppelte, 37,6 % liegt in [37,3 ... 55,5] % -> OK
   Der Waechter haette heute also einen Fehlalarm produziert - genau den, dem
   ich elf Hypothesen lang nachgegangen bin.

3) NEU: Abschnitt E "GLEICHES FENSTER" (--backtest). Rechnet den Backtest ueber
   genau den Live-Zeitraum und haelt ihn gegen das Intervall der entkoppelten
   Live-Rate. Erster Lauf: live 46,4 % [37,3 ... 55,5] gegen Backtest 43,9 %
   -> im Intervall, kein Befund.

4) Eingebaut in den Wochenreport (weekly_review._divergenz_section, montags
   07:30 per Mail + Telegram), mit demselben Fail-safe wie der
   Squeeze-Abschnitt. Bewusst NICHT in den pre-commit-Hook: der braucht MT5 und
   Minuten, Stufe 1 muss bei ~5 s bleiben.

Ausserdem ein Rechenfehler in meinem ersten Entwurf behoben (p_break steht in
der DB bereits in Prozent, ich hatte zusaetzlich skaliert -> "3763,9 %") und
ein \n-Heredoc-Fall, der genau gegen die dokumentierte Regel verstiess.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-07 11:55:05 +02:00