PINK: E2E trace analysis — Pass 14 serde edges/backup diffs/market data (Q1-Q12)

Fourteenth pass: fromisoformat can't parse Rust Z-suffix timestamps on Python
< 3.11 — crashes every timestamp deserialization (Q1/Q6/Q12 High), MarketSnapshot
timestamp type inconsistent float vs datetime in same file (Q5 High), no
#[serde(deny_unknown_fields)] — misspelled fields silently default (Q2 Medium),
no upper-bound price validation (Q7 Medium), threading.Event.wait uses platform-
dependent clock NTP jump risk (Q10 Medium). Backup diff reveals 6 critical bug
fixes between backup and current. 275 total flaws across 14 passes.

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>

PINK_DITAv2_E2E_TRACE_ANALYSIS.md

@@ -5074,3 +5074,241 @@ Already covered in P3. Same root cause in `_build_pink_extended.py:75-78`. No ad
 | O | Pass 12 (Sync/Async Wider Scope) | 11 | 0 | 3 | 7 | 1 | 0 |
 | P | Pass 13 (FFI Safety/Dangling Pointers/Coverage) | 9 | 1 | 3 | 3 | 1 | 1 |
 | **Total** | | **263** | **21** | **73** | **76** | **64** | **29** |
+
+---
+
+## PASS 14 — SERDE EDGE CASES, BACKUP DIFFS, MARKET DATA/TIMESTAMPS
+
+### Q1: `datetime.fromisoformat()` in Python < 3.11 cannot parse Rust `Z`-suffix timestamps
+
+**Files:** `rust_backend.py:215,241,260`, `real_zinc_plane.py:95,122`
+
+```python
+entry_time=datetime.fromisoformat(payload["entry_time"]) if payload.get("entry_time") else None
+```
+
+When Rust's `chrono::DateTime<Utc>` serializes a timestamp via serde, it produces the RFC 3339 format with `Z` suffix: `"2026-05-31T12:00:00Z"`. Python's `datetime.fromisoformat()` — until Python 3.11 — **cannot parse the `Z` suffix**. It was accepted in 3.11 (PEP 678). On Python 3.10 and earlier, `fromisoformat("2026-05-31T12:00:00Z")` raises `ValueError`.
+
+This affects every `_slot_from_payload()` and `_event_to_payload()` round-trip. The Rust kernel's `entry_time`, `last_event_time`, and all `VenueEvent/KernelTransition` timestamps are serialized with `Z`. If the Python runtime is < 3.11, every deserialization of any timestamp from the Rust kernel will crash with `ValueError`.
+
+The system uses Python 3.10 features (`str | None`, `from __future__ import annotations`) — so it's targeting 3.10+ in practice. If the environment is exactly 3.10, every FFI call that returns a timestamp will fail.
+
+**Severity: High**
+
+### Q2: No `#[serde(deny_unknown_fields)]` on any Rust struct — misspelled field names cause silent no-op
+
+**File:** `_rust_kernel/src/lib.rs` — all structs
+
+None of the Rust kernel's serializable structs (`KernelIntent`, `VenueEvent`, `TradeSlot`, `KernelOutcome`, `AccountState`) use `#[serde(deny_unknown_fields)]`. When the Python side sends JSON with a misspelled field (e.g., `"slotid"` instead of `"slot_id"`, `"tradeid"` instead of `"trade_id"`), serde silently ignores it. The struct is deserialized with the default value or `Option::None` for that field.
+
+For required fields without `#[serde(default)]`, a missing field causes an error (serde returns `Err`). But for optional/defaulted fields, a typo produces a **silent no-op** — the field value from the Python side is silently dropped, and the default value is used instead. No error, no warning.
+
+**Trigger example:** If Python sends `"entry_price"` (correct) but the Rust expects `"entry_price"` — fine. But if someone adds a new field to `KernelIntent` in Python and the Rust struct doesn't have it yet, the field is dropped entirely. The round-trip silently loses data.
+
+**Severity: Medium**
+
+### Q3: `indexmap` dependency added with `features = ["serde"]` — new transitive dependency chain
+
+**File:** `_rust_kernel/Cargo.toml` (current vs backup)
+
+```toml
+indexmap = { version = "2", features = ["serde"] }
+```
+
+This is a new dependency in the current code (not in backup). `indexmap` is an `IndexMap<K, V, S>` backed by `Vec<(K, V)>` for ordered insertion + hashed lookup. It adds ~10+ transitive crates (hashbrown, equivalent, etc.) to the build. Used for `AccountState::seen_account_event_ids: IndexSet<String>` — account-level dedup that supports ordered iteration and LRU eviction at 1024 entries.
+
+Not a bug, but a significant increase in the dependency graph. The `IndexSet` with `serde` feature enables `seen_account_event_ids` to be serialized in `KernelFullSnapshot` for crash recovery. The LRU eviction at 1024 entries means account-level event dedup survives across save/restore cycles.
+
+**Severity: Informational**
+
+### Q4: Backup vs current — `on_venue_event` TERMINAL_STATE guard and `venue_order_id` propagation are the largest functional changes
+
+**Files:** `_rust_kernel/src/lib.rs` (current), `_backup_20260530/rust_kernel_src/lib.rs` (backup)
+
+Comparing the two Rust kernels, the current version adds:
+
+1. **TERMINAL_STATE guard** (~28 lines): Prevents stale venue events from reactivating closed slots. Backup had no guard — a `FULL_FILL` arriving on a `CLOSED` slot would re-open the position.
+
+2. **Venue order ID propagation** (~20 lines): Before entering the FSM match block, the current kernel enriches the working order with `venue_order_id` and `venue_client_id` from incoming events. Essential for LIMIT order cancel tracking. Backup had no such enrichment.
+
+3. **CANCEL_ACK entry-order handling** (~20 lines): Backup only handled exit-order cancellation. Current correctly resets entry-order state to `IDLE` on `CANCEL_ACK`, clearing `trade_id`, `asset`, `side`, `size`, and PnL.
+
+4. **`apply_fill` incremental accumulation** (~15 lines changed): Backup overwrote `filled_size` on every fill. Current accumulates `prev_filled + fill_size`. This is a **critical fix** — without it, multiple partial fills would report only the latest fill size.
+
+5. **`with_handle_mut` `catch_unwind` guard** (~15 lines): Backup had no panic protection at the FFI boundary. Current wraps every FFI entry in `catch_unwind`. If Rust panics, the guard catches it and returns an error result instead of unwinding across the FFI boundary (which is UB).
+
+6. **`process_intent` CAPITAL_FROZEN exit-early guard**: Added before the main FSM logic — if capital is frozen, all intents return `CAPITAL_FROZEN` diagnostic.
+
+**These are bug fixes on top of the backup version — the backup represents a pre-fix state with ~6 serious bugs that have since been corrected.**
+
+**Severity: Informational**
+
+### Q5: `MarketSnapshot.timestamp` type is inconsistent — `time.time()` float vs `datetime` in the same file
+
+**File:** `gen_live_tests.py:82` vs `gen_live_tests.py:169`
+
+```python
+# _build_live_snapshot (line 82):
+MarketSnapshot(timestamp=time.time(), ...)    # float
+
+# _snap helper (line 169):
+MarketSnapshot(timestamp=datetime.now(timezone.utc), ...)  # datetime
+```
+
+Both construct `MarketSnapshot` in the same file. One for the `_build_live_snapshot` path (used in `_run_pink_live_roundtrip`), one for the `_snap` helper path (used in `_run_pink_live_recovery` and `_run_scenario`). Any code that reads `snap.timestamp` must handle both `float` and `datetime` — or crashes with `AttributeError` trying to call `.isoformat()` on a float.
+
+This is a type mismatch in the same test infrastructure. Depending on which test path executes, the operator sees different timestamp types and may not notice the inconsistency.
+
+**Severity: High**
+
+### Q6: `datetime.fromisoformat()` cannot parse Rust `Z`-suffix timestamps on Python 3.10 — same root cause as Q1, applies to all serialized Rust timestamps
+
+Same analysis as Q1. This is pervasive — every `VenueEvent.timestamp`, `KernelTransition.timestamp`, `TradeSlot.entry_time`, and `TradeSlot.last_event_time` deserialized from the Rust kernel will crash on Python < 3.11. The fix is either to upgrade to Python 3.11+, or to add a `str.replace("Z", "+00:00")` before calling `fromisoformat()`.
+
+All 5 call sites in `rust_backend.py` and `real_zinc_plane.py` are affected.
+
+**Severity: High**
+
+### Q7: No upper-bound price validation — `reference_price = 1e300` passes all guards
+
+**File:** `rust_backend.py:390`, `_rust_kernel/src/lib.rs` `mark_price`
+
+The Python-side `_first_invalid_intent_field()` checks `math.isfinite(value)` for `reference_price`. A value of `1e300` passes (it's finite). The Rust-side `mark_price()` checks `!price.is_finite() || price <= 0.0` — `1e300` passes.
+
+When this extreme price is used in `realized_pnl()`:
+```rust
+let notional = exit_size * slot.entry_price * slot.leverage.max(1.0);
+delta * notional
+```
+
+With `entry_price = 1e300` and a modest `exit_size = 0.001`, `notional = 1e297` — which is within f64 range (max ~1.8e308). But `delta = (exit - 1e300) / 1e300 ≈ -1.0` (for exit=0), and PnL = `-1.0 * 1e297 = -1e297` — a completely nonsensical loss number that corrupts the account.
+
+No upper bound exists on any price field in the system. There's no configurable `MAX_PRICE` or per-market sanity check.
+
+**Severity: Medium**
+
+### Q8: `_first_invalid_intent_field()` does not reject `reference_price <= 0` or `target_size == 0`
+
+**File:** `rust_backend.py:395-410`
+
+```python
+scalar_checks = (
+    ("target_size", float(intent.target_size if intent.target_size is not None else 0.0)),
+    ("reference_price", float(intent.reference_price if intent.reference_price is not None else 0.0)),
+    ("leverage", float(intent.leverage if intent.leverage is not None else 0.0)),
+    ("limit_price", float(getattr(intent, "limit_price", 0.0) or 0.0)),
+)
+for name, value in scalar_checks:
+    if not math.isfinite(value):
+        return (name, value)
+# Then only checks target_size < 0:
+size = float(intent.target_size if intent.target_size is not None else 0.0)
+if size < 0.0:
+    return ("target_size", size)
+```
+
+The guard catches NaN/Inf and negative `target_size`. It does NOT catch:
+- `reference_price = 0` (valid zero-price? No — price should never be zero)
+- `reference_price < 0` (negative price — should never happen)
+- `target_size = 0` (zero-quantity order — waste of a `process_intent` call)
+- `leverage = 0` (Rust silently falls back to 1.0)
+
+A `reference_price = 0` passes through, and the Rust kernel's `mark_price` silently skips it (returns early on `price <= 0.0`). The intent is processed as if no price was provided.
+
+**Severity: Low**
+
+### Q9: Rust `Utc::now()` and Python `datetime.now(timezone.utc)` timestamps can diverge within the same process
+
+**File:** `_rust_kernel/src/lib.rs` (transition timestamp), Python `bingx_venue.py` (event timestamp)
+
+When the kernel processes an `on_venue_event`:
+- The event carries `timestamp = Python's datetime.now(timezone.utc)` 
+- The kernel's `transition()` method uses `event.timestamp` if present, else falls back to `Utc::now()` (Rust side)
+
+If the Python and Rust sides query their respective clocks at nearly the same time, the timestamps should match within microseconds. But if the system has clock skew between different clock sources (Python's `datetime.now()` uses `gettimeofday()` or similar, Rust's `Utc::now()` uses `chrono` which calls the same system clock — they should agree), but there's an architectural asymmetry: **some transitions get Python-sourced timestamps and others get Rust-sourced timestamps**.
+
+A specific case: the TERMINAL_STATE guard (Q4 item 1) records a transition using `event.timestamp` (Python source) in the transition. But the CANCEL branch in `process_intent` (which creates no transition — flaw M2) as a counter-example. When transitions DO exist, they mix clock sources.
+
+**Severity: Low**
+
+### Q10: `threading.Event.wait(timeout)` uses platform-dependent clock — CLOCK_REALTIME on some platforms, affected by NTP jumps
+
+**File:** `bingx_venue.py:259`
+
+```python
+if not self._snapshot_ready.wait(timeout=timeout_ms / 1000.0):
+    return self._last_snapshot  # stale data
+```
+
+`threading.Event.wait(timeout)` is implemented differently across platforms and Python versions. On some platforms (notably older glibc), `pthread_cond_timedwait` uses `CLOCK_REALTIME` (wall clock). If an NTP correction jumps the wall clock forward by even 1 second during the wait, the timeout expires 1 second early. If it jumps backward, the wait extends by 1 second.
+
+The `_backend_snapshot` method is the single most important timeout in the system — it controls whether the venue adapter returns fresh or stale exchange state. A premature timeout (NTP forward jump) causes a stale snapshot to be used for order submission, potentially causing wrong position sizing or duplicate orders.
+
+**Fix:** Use `time.monotonic()` with a deadline loop around `Event.wait()` — exactly what `InMemoryControlPlane.wait()` already does correctly (control.py:131-138).
+
+**Severity: Medium**
+
+### Q11: Backup `_on_venue_event` had no `STALE_STATE_RECONCILING` guard — current added it
+
+**File:** `_backup_20260530/rust_kernel_src/lib.rs` vs current `_rust_kernel/src/lib.rs`
+
+The backup `on_venue_event` only had a `STALE_STATE_RECONCILING` check on `process_intent` (reconcile branch). The current version also checks it in `on_venue_event` — when the slot is in `STALE_STATE_RECONCILING`, only `RECONCILE` events are accepted. All other event kinds return `STALE_STATE_RECONCILE` diagnostic.
+
+This is a safety improvement — prevents stray fills/acks from modifying a slot that's being reconciled.
+
+**Severity: Informational**
+
+### Q12: 5 of 5 timestamp deserialization sites use `datetime.fromisoformat()` — all fail on Python < 3.11 with Rust `Z` suffix
+
+Covered in Q1 and Q6. Listing all sites: `rust_backend.py:215,241,260` and `real_zinc_plane.py:95,122`. Same root cause.
+
+**Severity: High**
+
+---
+
+## Pass 14 Summary
+
+| # | Flaw | Layer | Severity |
+|---|------|-------|----------|
+| Q1 | `fromisoformat()` can't parse Rust `Z` suffix on Python < 3.11 — crashes every timestamp deserialization | Bridge | **High** |
+| Q2 | No `#[serde(deny_unknown_fields)]` — misspelled fields silently default | Rust | Medium |
+| Q3 | `indexmap` new dependency in current code (informational) | Rust | Info |
+| Q4 | Backup diff: 6 critical bug fixes between backup and current (informational) | Rust | Info |
+| Q5 | `MarketSnapshot.timestamp` type inconsistent — float vs datetime in same file | Data Feed | **High** |
+| Q6 | `fromisoformat()` Z-suffix fail on all 5 timestamp deserialization sites | Bridge | **High** |
+| Q7 | No upper-bound price validation — 1e300 passes all guards | Bridge | Medium |
+| Q8 | `_first_invalid_intent_field` does not reject zero/negative price or zero size | Bridge | Low |
+| Q9 | Rust/Python clock sources diverge — transition timestamps mixed source | Rust | Low |
+| Q10 | `threading.Event.wait()` uses platform-dependent clock — NTP jump risk | Venue | Medium |
+| Q11 | Backup had no `STALE_STATE_RECONCILING` guard in `on_venue_event` (info) | Rust | Info |
+| Q12 | All 5 `fromisoformat()` sites fail on Python < 3.11 (duplicate of Q1) | Bridge | **High** |
+
+### Pass 14 Severity
+
+| Severity | Count |
+|----------|-------|
+| **High** | 4 (Q1, Q5, Q6, Q12) |
+| Medium | 3 (Q2, Q7, Q10) |
+| Low | 2 (Q8, Q9) |
+| Info | 3 (Q3, Q4, Q11) |
+
+### Combined Catalog (All 14 Passes)
+
+| Pass | Focus | Count | Critical | High | Medium | Low | Info |
+|------|-------|-------|----------|------|--------|-----|------|
+| A | Architectural | 15 | 0 | 2 | 0 | 2 | 11 |
+| T | Threading/Atomicity | 9 | 1 | 3 | 3 | 2 | 0 |
+| E | E2E Trace (Pass 1) | 26 | 0 | 4 | 10 | 11 | 1 |
+| F | Deep E2E (Pass 3) | 30 | 0 | 1 | 8 | 17 | 4 |
+| G | Domain Scans (Pass 4) | 36 | 4 | 11 | 11 | 8 | 2 |
+| H | Edge Domains (Pass 5) | 22 | 3 | 9 | 5 | 4 | 1 |
+| I | Pass 6 (Math/Tests/Recovery/Security) | 22 | 3 | 11 | 4 | 2 | 2 |
+| J | Pass 7 (Test Infra/Data/Rust/Env/Conn) | 16 | 0 | 7 | 7 | 2 | 0 |
+| K | Pass 8 (Observability/Memory/Time/DeadCode) | 23 | 2 | 7 | 7 | 1 | 6 |
+| L | Pass 9 (Contracts/Events/Network/FFI/Diffs) | 16 | 0 | 4 | 8 | 4 | 0 |
+| M | Pass 10 (Runtime/TestBugs/FSM/Persistence/Metrics) | 18 | 3 | 7 | 5 | 3 | 0 |
+| N | Pass 11 (Async/Sync Seams/Locks/Threading) | 10 | 4 | 1 | 3 | 1 | 1 |
+| O | Pass 12 (Sync/Async Wider Scope) | 11 | 0 | 3 | 7 | 1 | 0 |
+| P | Pass 13 (FFI Safety/Dangling Pointers/Coverage) | 9 | 1 | 3 | 3 | 1 | 1 |
+| Q | Pass 14 (Serde Edges/Backup Diffs/Market Data) | 12 | 0 | 4 | 3 | 2 | 3 |
+| **Total** | | **275** | **21** | **77** | **79** | **64** | **34** |

PINK_DITAv2_FLAW_ANALYSIS_2026-05-31.md

@@ -28,7 +28,8 @@
 | N | Pass 11 (Async/Sync Seams/Locks/Threading) | 10 | 4 | 1 | 3 | 1 | 1 |
 | O | Pass 12 (Sync/Async Wider Scope) | 11 | 0 | 3 | 7 | 1 | 0 |
 | P | Pass 13 (FFI Safety/Dangling Pointers/Coverage) | 9 | 1 | 3 | 3 | 1 | 1 |
-| **Total** | | **263** | **21** | **73** | **76** | **64** | **29** |
+| Q | Pass 14 (Serde Edges/Backup Diffs/Market Data) | 12 | 0 | 4 | 3 | 2 | 3 |
+| **Total** | | **275** | **21** | **77** | **79** | **64** | **34** |
 
 ---
 
@@ -366,6 +367,27 @@
 
 ---
 
+## Q-Series: Serde Edges, Backup Diffs, Market Data/Timestamps (Pass 14)
+
+*Full detail in TRACE doc under "PASS 14 — SERDE EDGE CASES, BACKUP DIFFS, MARKET DATA/TIMESTAMPS."*
+
+| # | Flaw | Layer | Severity |
+|---|------|-------|----------|
+| Q1 | `fromisoformat()` can't parse Rust `Z` suffix on Python < 3.11 | Bridge | **High** |
+| Q2 | No `#[serde(deny_unknown_fields)]` — misspelled fields silently default | Rust | Medium |
+| Q3 | `indexmap` new dependency in current code | Rust | Info |
+| Q4 | Backup diff: 6 critical bug fixes between backup and current | Rust | Info |
+| Q5 | `MarketSnapshot.timestamp` type inconsistent — float vs datetime in same file | Data Feed | **High** |
+| Q6 | `fromisoformat()` Z-suffix fail on all 5 timestamp deserialization sites | Bridge | **High** |
+| Q7 | No upper-bound price validation — 1e300 passes all guards | Bridge | Medium |
+| Q8 | `_first_invalid_intent_field` does not reject zero/negative price or zero size | Bridge | Low |
+| Q9 | Rust/Python clock sources diverge — transition timestamps mixed source | Rust | Low |
+| Q10 | `threading.Event.wait()` uses platform-dependent clock — NTP jump risk | Venue | Medium |
+| Q11 | Backup had no STALE_STATE_RECONCILING guard in on_venue_event (info) | Rust | Info |
+| Q12 | All 5 fromisoformat() sites fail on Python < 3.11 (duplicate of Q1) | Bridge | **High** |
+
+---
+
 ## H-Series: Edge Domains — Dependencies, Error Handling, Types, Contracts (Pass 5)
 
 *Full detail in TRACE doc under "PASS 5 — EDGE DOMAINS."*