Commit Graph

4 Commits

Author SHA1 Message Date
Codex
8d85d75ded PINK DITAv2: Hz writes + vol_ok gate + leverage logging + 8 new tests (94/94 green) 2026-06-03 13:26:36 +02:00
Codex
e7eaa88ce1 PINK Phase 0 and 1: VST WS confirmed plus AccountSnapshotV2 account core 2026-06-01 20:11:03 +02:00
Codex
0c15a7698e PINK DITAv2 L3: fix live LIMIT cancel (kernel order-id propagation + truth-based cancel)
L3 live validation surfaced a live-only defect: a working LIMIT order could not
be cancelled (MARKET never exercised cancel — synchronous fills).

Two coupled fixes:
- Rust FSM (lib.rs): propagate the venue's order id onto the active order for
  ALL order types and event kinds (ACK/partial/full fill) whenever the exchange
  provides one — orders are created at submit with an empty venue_order_id, so a
  later cancel had no real id to reference. Only fills empty ids, never overwrites.
  Requires recompiling libdita_v2_kernel.so.
- Backend (bingx_direct.py): add cancel(order) — a properly-signed DELETE by
  orderId (clientOrderId fallback) with TRUTH-BASED confirmation: BingX can return
  transient errors ("order not exist", dup-within-1s from an internal retry) even
  when the order was removed, so the cancel succeeds iff the order is no longer
  open on the venue. The venue adapter prefers this backend cancel over its raw
  signed_delete fallback (which failed signature with an empty id).

Validated:
- Offline: 63 + new cancel-truth unit tests green (no regression post-recompile).
- Live VST: resting SHORT LIMIT (+5%) rests as ENTRY_WORKING, confirmed as a LIMIT
  open order, cancel -> CANCEL_ACK -> IDLE, exchange flat (test_pink_limit_live.py).
- Live VST MARKET run-through re-validated post-recompile: PASS, exact capital
  reconciliation, two-phase rows visible (ORDER_REQUESTED + ENTRY_FILLED/EXIT).

LIMIT remains execution-infra only; PINK policy stays MARKET. BLUE untouched.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-05-31 08:03:27 +02:00
Codex
55ed6902d8 PINK DITAv2 L0-L2: two-phase persistence + async-fill pump + LIMIT wiring
Execution-infra only (policy stays MARKET; algorithmic integrity untouched).

L0 — two-phase (request->result) persistence (pink_clickhouse.py):
- Split persist_step into persist_request (policy_events + trade_reconstruction
  ORDER_REQUESTED) and persist_result (state snapshot + per-fill lifecycle rows).
- Lifecycle rows (ENTRY_FILLED/EXIT/trade_events/trade_exit_legs) gated on
  evidence of an actual fill (FULL/PARTIAL_FILL event, closed slot, or size drop
  vs _leg_state) -> a resting LIMIT (ACK only) emits no terminal rows.
- Add persist_fill_events: synthesizes a minimal decision/intent from slot+event
  for async fills and routes through persist_result.

L1 — async-fill pump (pink_direct.py):
- PinkDirectRuntime.pump_venue_events(): venue.reconcile() -> kernel.on_venue_event
  (capital settles, FSM advances), persists applied fills; kernel dedups
  duplicates (no double-settle). Called at the start of step().

L2 — LIMIT placement (bingx_direct.py):
- submit_intent now honors _order_type/_limit_price from intent metadata
  (was hardcoded MARKET): LIMIT -> type=LIMIT + price + GTC; MARKET default;
  invalid limit price falls back to MARKET.

Offline: 63 passed (persistence/groundwork/pump/limit-payload/runtime/accounting/
flaws/kernel). MARKET path unchanged; resting LIMIT now correct end-to-end offline.
Live VST validation (L3) pending. BLUE untouched.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-05-31 03:23:44 +02:00