C3F FINAL AUTO_SAFE BATCH 3: migriert alle 21 verbleibenden AUTO_SAFE Knowledge Objects auf knowledge_schema v1 (18 standalone logs + 3 standalone-canonical). Body byte-genau, IDs stabil (0 Kollisionen). Keine HR/DO_NOT_TOUCH berührt. C3 MIGRATION weiter IN_PROGRESS.
4 KiB
| id | type | role | representation | state | knowledge_schema | _organized |
|---|---|---|---|---|---|---|
| object/da874dfe-edd4-a6ba-1587-a145ae045ddc | arch | history | canonical | historical | 1 | 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→ blockiertREFERENCE_BID_ASK+ Single-Price → blockiertBROKER_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…vsbc6e2553…ist geklärt — der echte Hash aus der Run-Wahrheit istbc6e2553…(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