nexo312/trading-system-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trading-system-docs/notes/trading/system-docs/phase10b_semantic_correction.md

3.9 KiB
Raw Blame History

type _organized
Note true

Phase 10b — Semantische Korrektur REFERENCE_BID_ASK → BID_ASK_INTRINSIC

Geändert von: Rain Ocampo (Hermes) Datum: 23.08.2026 Grund: Semantische Korrektur des Spread-Modells für den REFERENCE_BID_ASK-Ausführungspfad + vollständiger Beweis + kontrollierter Minimal-Deploy.

Zusammenfassung

Phase 10b schließt die semantische Korrektur des Spread-Modells ab: Für den Ausführungspfad REFERENCE_BID_ASK ist der Spread intrinsisch (ergibt sich aus Entry-/Exit-Seite, KEIN Zusatz-Aufschlag). Deshalb gilt dort standardmäßig spread_model = BID_ASK_INTRINSIC, sofern nicht explizit ein anderes Spread-Modell übergeben wird. Legacy (LEGACY_SINGLE_PRICE) bleibt unverändert NONE.

Damit zeigen ExecutionContext, Audit und run_hash dieselbe Wahrheit — es gibt keine Sonderbehandlung nur im Audit.

Semantische Korrektur (Option 1, User-Entscheidung)

  • REFERENCE_BID_ASK (Default) → spread_model = BID_ASK_INTRINSIC (explizit übersteuerbar)
  • LEGACY_SINGLE_PRICE → spread_model = NONE (unverändert)
  • V2-run_hash DARF sich ändern (ist gewollt)
  • Keine Sonderbehandlung nur im Audit — Context/Audit/Hash konsistent

Slippage-Wording

Phase 10b verwendet noch kein Slippage-Modell (nicht „ignoriert grundsätzlich"). slippage_model = NONE im Audit.

Fail-Closed (11 Fälle)

  • fehlendes/unvollständiges Bid/Ask → BID_ASK_REQUIRED
  • price_basis != bid_ask → blockiert
  • REFERENCE_BID_ASK + Single-Price → blockiert
  • BROKER_APPROXIMATION / BROKER_REPLAY / TICK_REPLAY → blockiert
  • unbekanntes execution_model → blockiert
  • kein Legacy-Fallback

Beweis (Tests)

Suite Ergebnis
Phase10a (execution_context) 15/15 grün
Phase10bFills 5/5 grün
Phase10bEngineFills 8/8 grün
Phase10bFixtureE2E 4/4 grün
M13Compat 5/5 grün
Gesamtsuite (Runner) 2× alle 11 Suiten grün

Beweis-Kernpunkte (Phase10a)

  • A) REFERENCE_BID_ASK Default → spread_model = BID_ASK_INTRINSIC
  • B) explizites NONE-Override → NONE
  • C) LEGACY → NONE
  • D) NONE vs intrinsic → verschiedene V2-run_hash
  • E) gleiche Konfig 2× → identischer V2-run_hash
  • F) Legacy unberührt

Fixture-E2E (4/4)

  • LONG + SHORT COMPLETED
  • Audit: execution_model=REFERENCE_BID_ASK, spread_model=BID_ASK_INTRINSIC, slippage_model=NONE, is_fixture=true
  • ohne ALLOW_FIXTURE_DATA → FIXTURE_DATA_BLOCKED
  • Reset-Beweis (Flag an→COMPLETED, Flag aus→BLOCKED, ENV wiederhergestellt)
  • kein Doppelspread

Deployment (kontrollierter Minimal-Deploy, Backup + Rollback)

  • Backup: /opt/data/backup_phase10b_deploy_20260823_090949/ (m12 + m13, md5-verifiziert)
  • M12 (Modul-12-Backtesting): /app/core/engine.py, /app/core/service.py, /app/core/pricing.py (NEU), /app/shared/historical/execution_context.py, /app/shared/historical/repository.py
  • M13 (Modul-13-Optimization): /app/shared/historical/execution_context.py, /app/shared/historical/repository.py
  • Verifikation: py_compile OK in beiden Containern; Restart; /health=200, /health/ready={"status":"ready","db":"ok"} (M12), /health=200 (M13)
  • KEINE Phase 10c, keine anderen Module, keine IG-Calls/Orders

Legacy-Produktions-Smoke (nach Deploy)

  • run_hash: bc6e25533d22ee102b6921eeeccd8f7b7dff4ec74a3316e381007ec56b0e1b37 (deterministisch, 2 Runs identisch)
  • data_hash: d76a75496453d9c05d5690237f4621534f954f9f3e87b67eee4ae9327c5c6bb9 (identisch Phase 8)
  • RESULT: PASS — Legacy bleibt nach 10b-Deploy byte-identisch
  • Hinweis: Die frühere Diskrepanz b3c2553… vs bc6e2553… ist geklärt — der echte Hash aus der Run-Wahrheit ist bc6e2553… (b3c2553… war ein Tippfehler im Zwischenbericht).

Produktions-Gate

  • M12 + M13: HISTORICAL_DATA_SOURCE=UNSET, ALLOW_FIXTURE_DATA=UNSET
  • Produktion bleibt auf echtem Datensatz, nie auf Fixture