341 lines
20 KiB
Markdown
341 lines
20 KiB
Markdown
---
|
||
type: Note
|
||
tags: [trading, mt5, architecture, historical-v2, m12, m13, phase9, readiness-audit, phase2]
|
||
created: 2026-08-22
|
||
---
|
||
|
||
# Phase 9 — M12/M13 Phase-2-Readiness-Audit + Implementierungsmatrix A–N
|
||
|
||
> Autor: Rain Ocampo | Datum: 22.08.2026 | Status: ✅ ANALYSE + DESIGN + VERIFIKATION (KEINE Implementierung)
|
||
> **Geändert von: Rain Ocampo, Datum: 22.08.2026, Grund: Phase-9-Audit (read-only, Code-Evidenz)**
|
||
|
||
## Executive Summary
|
||
|
||
Phase 2 (realistischer Backtest: Bid/Ask-Fill, Spread, Slippage, Kosten, Intrabar, Gap) ist NICHT implementiert. Das heutige M12 nutzt ein **reines Single-Price-Bid-Modell** (nur Legacy-`ohlcv`-`close`, oder V2-`bid_close` als `close`). Es gibt keine Bid/Ask-Fill-Logik, kein separates Spread-Modell außer einem pauschalen Preispunkte-Abschlag auf Entry+Exit, keine Slippage außer derselben Punkte-Verschlechterung, und keinen Kosten-Breakdown. Der wichtigste Verzerrungs-Punkt: **Der Intrabar-Exit ist symmetrie-verzerrt** — Stop gewinnt immer bei Stop+Target-in-einer-Bar (konservativ, aber pessimistisch für Target-Trades).
|
||
|
||
Die Erweiterung muss einen **ExecutionContext** einführen, der `execution_model`, `spread_model`, `slippage_model`, `cost_model`, `intrabar_policy`, `price_basis`, `feed_type` transportiert und versioniert — inklusive Run-Hash-Integration, aber **strikt getrennt** von Dataset-Identität und Strategie-Parameter.
|
||
|
||
---
|
||
|
||
## A — PRICE MODEL / SINGLE-PRICE AUDIT
|
||
|
||
### Candle-Datenmodell (M12)
|
||
- **Legacy** (`repository.py:_load_candles_legacy`, Zeile 305-327): `ohlcv`-Tabelle, Keys `timestamp, open, high, low, close, volume`. **Nur Einzelpreis** pro Bar (Mid/Einzelpreis). Kein bid/ask.
|
||
- **V2** (`repository.py:_load_candles_v2`, Zeile 332-371): liest aus `historical_bar` und mappt **`bid_open→open, bid_high→high, bid_low→low, bid_close→close`**. Das `historical_bar`-Schema HAT bid_open..ask_close (verifiziert: 37.480/37.480 bid+ask, mid=0), aber `load_candles` **transportiert sie NICHT** — wirft die ask-Seite weg und liefert nur bid-OHLC.
|
||
- Die Engine bekommt also immer OHLC (nur bid/Einzel) — **niemals ask**.
|
||
|
||
### Entry / Exit / Stop / Target (engine.py)
|
||
| Feld | Quelle | Zeile |
|
||
|---|---|---|
|
||
| Entry (Signal) | `setup.entry` = **letzter Close der Signal-Candle** (Strategie: `entry = last_close`) | strategy 134/175 |
|
||
| Entry-Fill (Open Pos) | `next_candle["open"]` + Spread + Slippage (verschlechtert) | `_open_position` 192-214 |
|
||
| Stop | `setup.stop_loss` = Swing-Low/High ± buffer | 135, 176 |
|
||
| Target | `setup.target` = Entry ± 2R | 139, 180 |
|
||
| Exit (normales Ende) | `candle["close"]` (OHNE Slippage/Spread auf Stop/Target) | `_close_position` 283-336 |
|
||
| Market-Order-Fill | pauschaler Preispunkte-Abschlag LONG+ / SHORT- | 198-200 |
|
||
| Gap | Open-Fill zum Gap-Open | `_evaluate_exit` 268-280 |
|
||
| Run-Ende | Force-Close zum letzten `close` | 141-153 |
|
||
|
||
### Aktuelle Annahmen (Single-Price)
|
||
| Annahme | Konsequenz |
|
||
|---|---|
|
||
| `open`/`close` sind handelbarer Preis (Einzel) | Kein Bid/Ask-Spread |
|
||
| LONG Entry = OPEN + spread + slippage | Wird besser (künstlicher Overhead) |
|
||
| LONG Exit = CLOSE (bei normalem Exit) | Kein Exit-Spread/Slippage — nur Entry hat Kosten |
|
||
|
||
**RISIKO**: V2-Daten sind real `bid_ask`, aber `load_candles` reduziert auf bid — die ask-Seite wird VOR der Engine verworfen. Realisierung als Bid/Ask-Fill ist daher **nicht möglich ohne Datenmodell-Änderung**.
|
||
|
||
**SOLL**: Engine muss `price_basis` + `bid_*`/`ask_*`/`mid_*` transportieren; Entry/Exit-Getrennt je nach Richtung; Stop/Target auf entsprechende Seite anwenden.
|
||
|
||
---
|
||
|
||
## B — BID/ASK READINESS
|
||
|
||
### Was liefert Historical V2 tatsächlich?
|
||
- `historical_bar` hat **`bid_open/high/low/close` UND `ask_open/high/low/close`** (verifiziert: 37.480/37.480/37.480, mid=0) — bid_ask vorhanden, mid NICHT.
|
||
- `load_bars_with_quality` (Zeile 163-247) transportiert bid+ask+mid+quality-Keys (vollständig).
|
||
- ABER: `load_candles` (der Pfad, den die Engine nutzt) liefert **nur bid-OHLC** — ask wird verworfen.
|
||
|
||
### Kann M12 es heute transportieren?
|
||
**Nein, nicht über den Engine-Pfad.** Die Engine bekommt `open/high/low/close` als Einzelwerte. `build_dataset_context` bringt `price_basis="bid_ask"` (aus Bar-Metadaten), aber diese Info erreicht die Engine-Fills **nicht** (nur Run-Audit).
|
||
|
||
### Zielmodell
|
||
```
|
||
LONG: Entry grundsätzlich Ask (Käufer zahlt ask)
|
||
Exit grundsätzlich Bid (Verkäufer erhält bid)
|
||
SHORT: Entry grundsätzlich Bid (Verkäufer verkauft bid)
|
||
Exit grundsätzlich Ask (Käufer erhält ask)
|
||
```
|
||
**Sonderfälle (zu dokumentieren, NICHT implementieren):**
|
||
- **Stop LONG**: Löse aus, wenn bid_low ≤ stop → fill = stop (oder gap-open bid, wenn gap unter)
|
||
- **Stop SHORT**: bid_high ≥ stop → fill = stop (bid/ask?)
|
||
- **Target LONG**: ask_high ≥ target → fill = target
|
||
- **Market**: Entry LONG = ask_open; Entry SHORT = bid_open
|
||
- **Limit**: (Phase 2 nicht eingeführt — kein Limit-Fill)
|
||
- **Gap**: bid/ask-gap-opening überschlägt Stop/Target
|
||
- **Bar Open**: Entry zum nächsten Bar-Open auf der korrekten Seite
|
||
- **End-of-data**: force-close zum letzten bid/ask-close
|
||
|
||
---
|
||
|
||
## C — SPREAD AUDIT
|
||
|
||
Heute (**engine.py** `_open_position` Zeile 198-201, `_close_position` Zeile 297-303):
|
||
- **Spread = ein fester Punktwert** (`params["spread"]`, Default 0.0, M13-Default 0.0).
|
||
- **Einheit: Preispunkte** (absolute Preisdifferenz, nicht %).
|
||
- Anwendung: **sowohl Entry als auch Exit**, je Richtung versetzt — d.h. ein **doppelter Spread pro Trade** (Entry+Exit) statt einmal.
|
||
- **Preisbasis**: unklar — es wird einfach von `open`/`close` abgezogen, ohne bid/ask-Bezug. Da Daten heute bid-single sind, ist es ein "Abschlag" auf den einzigen Preis.
|
||
|
||
**Doppelzählungsrisiko**: Wenn Bid/Ask-Fill eingeführt wird, ist der aktuelle pauschale Spread-Abzug bereits implizit im echten bid/ask-Spread enthalten. Zusätzlich ein künstlicher `spread`-Abzug ⇒ **Doppelzählung**.
|
||
|
||
**Zielregel**:
|
||
- `price_basis=bid_ask` (echte bid/ask) → Spread NICHT künstlich aufschlagen; nutze den intrinsischen bid/ask.
|
||
- `price_basis=mid`/single → synthetisches Spread-Modell möglich (aufzuschlagen).
|
||
- Beide Modi **strikt unterscheidbar** durch `spread_model` (z.B. `BID_ASK_INTRINSIC` vs `SYNTHETIC_FIXED` vs `SYNTHETIC_POINTS`).
|
||
|
||
---
|
||
|
||
## D — SLIPPAGE AUDIT
|
||
|
||
Heute (engine.py):
|
||
- **Wann**: nur Entry + normaler Exit (nicht Stop/Target, siehe unten).
|
||
- **Einheit**: Preispunkte (`params["slippage"]`, Default 0.0).
|
||
- **Long/Short**: symmetrisch — Long schlägt auf (Entry+Exit), Short zieht ab. Adversarial in beiden Fällen.
|
||
- **Deterministisch**: JA — ein fester Punkte-Wert. Kein Zufall, kein Seed.
|
||
- **Bestandteil run_hash**: JA (steht in `params_snapshot` → `_compute_run_hash` inkludiert `params`). Slippage-Änderung ändert run_hash.
|
||
- **Bestandteil Audit**: indirekt über `parameters` (in `metrics.audit` nicht explizit).
|
||
|
||
**Zielmodell**: `slippage_model` (`DETERMINISTIC_FIXED` | `SYNTHETIC_POINTS` | `BROKER_REPLAY`...). Kein Zufall im deterministischen Kern; falls stochastisch, Seed fix + in Hash. Jeder Trade trennbar slippage_cost.
|
||
|
||
---
|
||
|
||
## E — COST MODEL
|
||
|
||
| Kosten | Status | Quelle | Heutige Modellierung |
|
||
|---|---|---|---|
|
||
| **Commission** | TEILWEISE | CONFIG (`fee_fixed`+`fee_pct`) | `_fee()` auf Entry+Exit |
|
||
| **Spread** | TEILWEISE | CONFIG (`spread`, Punkte) | pauschaler Preispunkte-Abschlag auf Entry+Exit |
|
||
| **Slippage** | TEILWEISE | CONFIG (`slippage`, Punkte) | pauschaler Preispunkte-Abschlag auf Entry+Exit |
|
||
| **Financing/Overnight/Swap** | NICHT | — | nicht modelliert |
|
||
| **FX conversion** | NICHT | — | nicht modelliert |
|
||
| **Guaranteed Stop Premium** | NICHT | — | nicht modelliert |
|
||
| **sonstige Gebühren** | NICHT | — | nicht modelliert |
|
||
|
||
**Kosten-Quellen heute**: ausschließlich **CONFIG** (keine Broker-, keine Referenz-Kosten). Keine IG-Gebühren erfunden ✓.
|
||
|
||
**Doppelzählungsrisiko (Kosten)**: `fee` UND `spread` UND `slippage` werden alle separat abgezogen — kein Broker/Referenz-Double-count, aber `spread` als pauschaler Abzug + künftiges bid/ask würde doppelt zählen (siehe C).
|
||
|
||
---
|
||
|
||
## F — INTRABAR AMBIGUITY (engine.py `_evaluate_exit`, Zeile 251-281)
|
||
|
||
**Aktuelles Verhalten — Code-Evidenz:**
|
||
- **LONG**: Stop wird VOR Target geprüft. Wenn `open<=stop`→Gap-Stop. Dann `if low<=stop`→Stop. Dann `if high>=target`→Target.
|
||
⇒ **Wenn Stop UND Target in derselben Bar** → **Stop gewinnt IMMER** (Worst-Case konservativ).
|
||
- **SHORT**: spiegelbildlich (Stop zuerst).
|
||
|
||
**Verzerrung**: M1-OHLC kann reale Intrabar-Reihenfolge nicht bestimmen (bekannt aus POC). Aktuelle Wahl ist deterministisch-pessimistisch (Stop-first), aber **kann Target-Gewinner in realistischen Sequenzen unterschätzen** (Stop-first bei bar mit beiden → Trades als Verluste klassifiziert, die real oft Target-Trades wären).
|
||
|
||
**Zielmodi (Design, NICHT implementiert)**:
|
||
- `PESSIMISTIC` (= Stop-first, heutiges Verhalten)
|
||
- `OPTIMISTIC` (= Target-first)
|
||
- `STOP_FIRST` / `TARGET_FIRST` (explizite Varianten)
|
||
- `TICK_RESOLUTION` (benötigt Tick-Daten — nur V2 nicht lieferbar)
|
||
- `UNKNOWN/BLOCK` (fail-closed: keine Intrabar-Reihenfolge festgelegt → Run blocken)
|
||
- Optional `DEFAULT=STOP_FIRST` (behält heutiges Verhalten als Baseline; künftig wählbar)
|
||
|
||
---
|
||
|
||
## G — GAP EXECUTION (engine.py, Zeile 268-280)
|
||
|
||
- **LONG Stop-Gap**: wenn `open<=stop` → Fill zum `min(open, stop)` = Gap-Open (schlechter). Bewiesen: ein Gap-Down unter Stop füllt nicht perfekt bei stop, sondern Gap-Open.
|
||
- **LONG Target**: `high>=target`→ fill=target (kein Gap-Fall bei Target gesondert). wenn `open>=target` → wird als `high>=target` abgefangen und zum target gefüllt (das wäre Optimistisch — Gap UP über Target müsste evtl. Gap-Open, nicht target).
|
||
- **SHORT analog**.
|
||
- **RISIKO**: `target`-Fill bei Gap wird zum target (nicht gap-open) — unrealistisch optimistisch für Gap-UP-LONG (sollte bid/ask-open nach gap). Umgekehrt ist der Stop-Gap korrekt pessimistisch.
|
||
- **Zielverhalten**: Gap-Fill-Regel konsistent: bei Gap-Öffnung jenseits Stop/Target → zum **Gap-Open der realen ausführbaren Seite**, nie zum anvisierten Level.
|
||
|
||
---
|
||
|
||
## H — REFERENCE VS BROKER FEED
|
||
|
||
- **Heute**: M12 kennt keinen Feed-Unterschied. Engine ignoriert `feed_type`/`price_basis`. Ergebnis wird als generischer Backtest-Output geliefert (einzig Run-Audit enthält `feed_type`/`price_basis`, aber nur bei V2 + Context).
|
||
- **Zielregel**: REFERENCE-Daten nie als exakte Broker-Ausführung ausgeben. Run muss `execution_model` + `cost_model` + `spread_model` + `feed_type` + `price_basis` sichtbar kennzeichnen.
|
||
- **Execution-Klassen (Phase 2)**:
|
||
- `MARKET_SIMULATION` — nur OHLC, synthetische Modelle (Spread/Slippage/Cost als config)
|
||
- `BROKER_APPROXIMATION` — echte bid/ask OHLC (REFERENCE), realistische Spread/Fill
|
||
- `BROKER_REPLAY` — echte Broker-Feed + Broker-Fill (IG later), fehler bei REFERENCE
|
||
- `BROKER_REPLAY` auf REFERENCE-Daten → **fail-closed** (inconsist).
|
||
|
||
---
|
||
|
||
## I — M13 OPTIMIZATION IMPACT
|
||
|
||
M13 (optimizer.py) ruft M12 mit `spread`/`slippage`/`fee_fixed`/`fee_pct` als **feste Baustein-Argumente** (`_bt_kwargs`, Zeile 326-335, alle Default 0.0). **NICHT Teil des Optimizer-Suchraums** — `param_space` enthält nur Strategie-Parameter.
|
||
|
||
**Gefahr**: Wenn `spread`/`slippage`/Fees in `param_space` aufgenommen würden, könnte der Optimizer sie MINIMIEREN (um Score zu maximieren) — realistische Kosten würden "schönoptimiert". Das ist **verboten**.
|
||
|
||
**Klassifikation (Phase-2-Design)**:
|
||
| Klasse | Beispiele | M13 optimiert? |
|
||
|---|---|---|
|
||
| STRATEGY_PARAMETER | ema_period, rr_multiplier, stop_buffer | JA |
|
||
| EXECUTION_PARAMETER | intrabar_policy, gap_rule | NEIN |
|
||
| BROKER_PARAMETER | spread, slippage, commission, financing | NEIN |
|
||
| DATA_PARAMETER | data_source, feed, price_basis, timeframe | NEIN |
|
||
| POLICY_PARAMETER | eligibility_policy, quality_rule | NEIN |
|
||
|
||
M13 darf **standardmäßig nur STRATEGY_PARAMETER** optimieren; alle anderen Klassen bleiben fix aus dem Backtest-Request (nicht optimierbar).
|
||
|
||
---
|
||
|
||
## J — RUN HASH / REPRODUCIBILITY
|
||
|
||
Phase-2-Parameter, die die Run-Identität beeinflussen müssen (Kandidaten):
|
||
- `execution_model_version`
|
||
- `spread_model_version`
|
||
- `slippage_model_version`
|
||
- `cost_model_version`
|
||
- `intrabar_policy_version`
|
||
|
||
**Entscheidung** (Grundregel: Daten ≠ Ausführungsmodell ≠ Strategieparameter):
|
||
- **Dataset-Hash** (data_hash): rein die OHLC/Bar-Daten (bid/ask). Unverändert durch Execution-Modelle.
|
||
- **Run-Hash**: Dataset-Hash + Strategie+Param + **Execution/Broker/Cost-Modell-Versionen** (weil anderer Execution-Modus → anderes Ergebnis → anderes run_hash, sonst falscher Cache-Hit).
|
||
- **Audit**: alle expliziten Modelle/Versions + breakdown, aber NICHT in den Hash (nur repräsentativ).
|
||
- M13-Optimizer-Hash analog: Execution-Modell-Versionen zusätzlich.
|
||
|
||
---
|
||
|
||
## K — RESULT METRICS
|
||
|
||
Heute (`_compute_metrics`): total_trades, winrate, profit_factor, expectancy_r, avg_r, net_pnl, gross_profit, gross_loss, avg_holding_h, long_count, short_count, max_drawdown, by_regime. **Kein Kosten-Breakdown.**
|
||
|
||
**Zielmetriken (Phase-2-Design)**:
|
||
- `gross_pnl` (ohne Kosten)
|
||
- `net_pnl` (nach allen Kosten)
|
||
- `spread_cost` / `slippage_cost` / `commission_cost` / `financing_cost` / `total_cost`
|
||
- `ambiguous_bars` (Bars mit Intrabar-Ambiguität)
|
||
- `gap_fills`
|
||
- `conditional_bars_used` (V2-Conditional)
|
||
- `reference_feed_warning`
|
||
|
||
---
|
||
|
||
## L — FAIL-CLOSED CONDITIONS (Phase-2)
|
||
|
||
Design-Liste, Situationen in denen Phase-2-M12 NICHT rechnen darf:
|
||
| Fall | Error-Code |
|
||
|---|---|
|
||
| Bid/Ask erforderlich aber fehlt | `BID_ASK_REQUIRED_MISSING` |
|
||
| unbekannte price_basis | `UNKNOWN_PRICE_BASIS` |
|
||
| unbekanntes execution_model | `UNKNOWN_EXECUTION_MODEL` |
|
||
| Fixture blockiert | `FIXTURE_DATA_BLOCKED` |
|
||
| Dataset nicht eligible | `DATASET_NOT_ELIGIBLE` / `UNKNOWN_CRITICAL_METADATA` |
|
||
| DatasetContext fehlt | `DATASET_CONTEXT_MISSING` |
|
||
| Kostenmodell verlangt Brokerdaten fehlen | `COST_MODEL_BROKER_DATA_MISSING` |
|
||
| BROKER_REPLAY + REFERENCE-Feed | `BROKER_REPLAY_REFERENCE_INCOMPATIBLE` |
|
||
| Tick-Modus verlangt Tickdaten, hat nur M1 | `TICK_DATA_REQUIRED_MISSING` |
|
||
|
||
---
|
||
|
||
## M — MIGRATION / COMPATIBILITY
|
||
|
||
| Modus | Daten | Execution | Spread | Slippage | Costs | Intrabar | Audit | Reproducibility | Zulässig |
|
||
|---|---|---|---|---|---|---|---|---|---|
|
||
| **LEGACY Single-Price** | ohlcv single | open/close, Stop-first | Config-punkte | Config-punkte | Config-fix/% | Stop-first | Legacy-Hash | run_hash | ✅ |
|
||
| **V2 REFERENCE BID/ASK** | historical bid/ask | bid/ask-Fill | intrinsic (bid/ask) | Config/Determ. | Config-fix/% | wählbar | full-Audit | run_hash + execution_version | ✅ (nach Implementierung) |
|
||
| **BROKER BID/ASK** | Broker bid/ask | broker-Fill | real broker | real broker | real broker | broker | full | Broker-Feed-Audit | (künftig) |
|
||
| **TICK** | tick-data | tick-seq | real | real | real | tick-resolved | full | Tick-Audit | (künftig) |
|
||
|
||
Legacy bleibt **unverändert** (durch `price_basis`/`execution_model`-Gates). Kein stiller Fallback.
|
||
|
||
---
|
||
|
||
## N — IMPLEMENTIERUNGSREIHENFOLGE (begründet)
|
||
|
||
Code-Audit belegt, dass die Engine rein Single-Price ist. Empfohlene Reihenfolge (jede Phase testbar + rückbaubar):
|
||
|
||
1. **ExecutionContext** (Datenmodell/Versionierung) — Voraussetzung, trennt alles. LOW
|
||
2. **Bid/Ask-Datenmodell** (load_candles/bars trägt bid/ask; Engine liest nach price_basis) — MEDIUM
|
||
3. **Bid/Ask Fill** (LONG buy ask/sell bid, SHORT bid/ask) — HIGH (Fill-Preis)
|
||
4. **Spread-Modell** (bid_ask intrinsic vs synthetic, keine Doppelzählung) — HIGH
|
||
5. **Slippage** (slippage_model, Entry/Exit-Einheit, Determinismus) — MEDIUM
|
||
6. **Cost-Breakdown** (Commission/Financing getrennt, nicht nur pauschal) — MEDIUM
|
||
7. **Gap-Fills** (konsistentes Gap-Open-Verhalten, Stop+Target) — HIGH
|
||
8. **Intrabar-Policy** (PESSIMISTIC/OPTIMISTIC/STOP_FIRST/TARGET_FIRST/TICK/UNKNOWN-BLOCK) — MEDIUM
|
||
9. **Result-Cost-Breakdown** (gross/net/cost-Metriken) — LOW
|
||
10. **M13-Param-Grenzen** (nur STRATEGY_PARAMETER optimizierbar, Execution-Kosten fix) — MEDIUM
|
||
11. **Reproducibility** (execution_model_version in run_hash, Audit-Vollständigkeit) — MEDIUM
|
||
12. **Regression/Legacy** (unverändert; Gate-Zusammenheit) — LOW
|
||
13. **Acceptance-Tests** (Plan unten)
|
||
|
||
Die Reihenfolge weicht von der (User)-Suggestions ab: **ExecutionContext-Versionierung zuerst** ist zwingend, sonst werden Modelle ohne Versionierung eingebaut und Reproducibility bricht nachträglich. Bid/Ask-Datenmodell vor Fill zwingend.
|
||
|
||
---
|
||
|
||
## RISIKO-MATRIX
|
||
|
||
| Änderung | Modul | Datei/Fn | Risiko | Regression | Test | Rollback |
|
||
|---|---|---|---|---|---|---|
|
||
| ExecutionContext | M12 | service.py/engine.py | LOW | — | Hash-Vergleich | revert service+engine |
|
||
| Bid/Ask-Datenmodell | M12 | marketdata/client.py, repo | **MEDIUM** | Daten-Format | load-candles-Pfad | revert client/repo |
|
||
| Bid/Ask-Fill | M12 | engine.py | **HIGH** | Fill-Preis | LONG/SHORT Fill-Test | revert engine |
|
||
| Spread-Modell | M12 | engine.py | **HIGH** | Spread, PnL | No-Doppelzählung | revert |
|
||
| Slippage | M12 | engine.py | MEDIUM | slippage-Einheit | Entry/Exit-Slipp | revert |
|
||
| Commission/Costs | M12 | engine.py | MEDIUM | Cost-Breakdown | Fee-Test | revert |
|
||
| Gap-Fills | M12 | engine.py | **HIGH** | Stop/Target, PnL | Gap-Tests | revert |
|
||
| Intrabar-Policy | M12 | engine.py | MEDIUM | Stop/Target | Intrabar-Tests | revert |
|
||
| Result-Cost-Breakdown | M12 | engine.py | **HIGH** | PnL | Metrics | revert |
|
||
| M13-Param-Grenzen | M13 | optimizer.py | MEDIUM | Overfit | Optimizer-Test | revert |
|
||
| Reproducibility | M12/M13 | service.py/optimizer.py | MEDIUM | Run-Hash | Hash-Repro | revert |
|
||
|
||
---
|
||
|
||
## ACCEPTANCE PLAN (vor Implementierung — Katalog)
|
||
|
||
**Fill/Spread:**
|
||
- LONG Entry Ask, LONG Exit Bid (BID-ASK)
|
||
- SHORT Entry Bid, SHORT Exit Ask
|
||
- echte bid/ask-Spread NICHT doppelt (Bid/Ask-Modus)
|
||
- synthetischer Spread korrekt (Single-Price-Modus)
|
||
|
||
**Slippage/Cost:**
|
||
- Slippage Long/Short adversarial
|
||
- Commission korrekt (fix+%)
|
||
|
||
**Intrabar/Gap:**
|
||
- Stop-only, Target-only, Stop+Target gleiche Bar
|
||
- Gap über Stop, Gap über Target
|
||
- PESSIMISTIC/OPTIMISTIC unterscheidbar
|
||
|
||
**Feed/Klassifizierung:**
|
||
- REFERENCE korrekt markiert
|
||
- BROKER_REPLAY + REFERENCE → fail-closed
|
||
|
||
**Reproduzierbarkeit:**
|
||
- gleicher Input → identisches Ergebnis
|
||
- andere Execution-Version → anderer run_hash
|
||
|
||
**Regression:**
|
||
- Legacy unverändert
|
||
|
||
---
|
||
|
||
## OFFENE ENTSCHEIDUNGEN (für Christian)
|
||
|
||
1. **Spread-Anwendung**: heutiger doppelter Entry+Exit-Spread → auf **einmaliger Roundtrip** oder je Seite ändern? Empfehlung: je Seite (realistisch).
|
||
2. **Intrabar-Default**: PESSIMISTIC (heutig, konservativ) als Standard bis Tick? Oder OPTIMISTIC?
|
||
3. **Slippage-Form**: deterministisch (Punkte) oder stochastisch (Seed)? Empfehlung: deterministisch default, stochastisch nur mit Seed+Hash.
|
||
4. **Cost-Modell-Version**: initial simple (fix+%, Spread/Punkte) → spätere Finanzierung/Swap/GS-Premium nachgeschaltet?
|
||
5. **Bid/Ask-Datenmodell**: sollen V2-bid/ask OHLC-Daten direkt in Engine (execution_model=APPROXIMATION) oder erst als REFERENCE-Feed (MARKET_SIMULATION) weitergegeben werden? Empfehlung: bid/ask zuerst nur in `load_bars_with_quality`, Engine-Pfad weiterhin single, bis Fill implementiert.
|
||
6. **M13**: Execution-Costs fix → ja (nicht optimizierbar) bestätigt.
|
||
7. **feed_type-Klassifizierung**: MARKT_SIMULATION vs BROKER_APPROXIMATION Bezeichnungen beibehalten?
|
||
|
||
---
|
||
|
||
## EXAKTER NÄCHSTER IMPLEMENTIERUNGSSCHRITT
|
||
|
||
Sobald Christian die offenen Entscheidungen freigibt, ist der **1. Schritt von Phase 10**:
|
||
1. **ExecutionContext-Dataclass** (execution_model, spread_model, slippage_model, cost_model, intrabar_policy, price_basis, feed_type + je *_version) — **ausser** DatasetContext, reine Ausführungs-Konfiguration.
|
||
2. Engine lädt als Einzelz: `execution_model` in `BacktestRequest`.
|
||
3. Tests: deterministisch, Hash-Integration, Legacy unverändert.
|
||
|
||
**NOCH NICHT implementiert** (verboten bis Freigabe): Bid/Ask-Fill, Spread-Änderung, Slippage-Änderung, Kostenmodell-Änderung, Intrabar-Ausführungslogik, Jahresbackfill, IG-Calls, Orders, Docker-Netzwerkänderung.
|