Files
siloqy/prod/docs/VIOLET_TODO_CRITICAL.md
Codex 80ce1a1afe VIOLET OA: partial spec PASS 4 — next plan units (entry gate, exits, accounting, exec-intent, feed)
VIOLET_PART_SPEC_OA_TODO_PASS4.md — six plan-derived independent units continuing from PASS 3,
extending the shared contracts_v3 vocabulary (adds ExecIntent / CapitalState / VolGateResult /
AlphaBar):
  14. Volatility regime gate (faithful vol_ok — the entry precondition).
  15. AlphaExitEngineV7 wrapper (V3a deferred — wrap BLUE's exit engine as-is, discretionary pri 2).
  16. Capital/economics provenance ledger (capital = anchor + Σ deltas, event_seq, exactly-one-row).
  17. Execution-intent emitter, DARK (V4 boundary — ShadowDecision → ExecIntent, log-only sink).
  18. Alpha-side reactor data feed (V2 NT Binance DATA spike → AlphaDataFeedPort, data-only).
  19. MAX_HOLD + MEAN_REVERSION scan-driven exit timers.
Each ships + tests standalone; composition map + recommended order (14→16→15→19→17→18) + the same
HARD RULES + commit/branch policy. VIBRISS/adaptive-TP explicitly excluded.

Also: added PASS 3 + PASS 4 to the review queue in VIOLET_TODO_CRITICAL.md §2.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-17 09:27:23 +02:00

87 lines
4.6 KiB
Markdown

# VIOLET — CRITICAL TODO / review queue (prominent)
Date: 2026-06-17. Single place for the must-not-forget VIOLET items. Review-later, not now.
---
## 🔴 CRITICAL #1 — VIOLET↔BLUE parity is VERY DISAPPOINTING (review + root-cause BEFORE any soak/V4)
Report: `prod/VIOLET_dev/reports/violet_parity_20260616_220412.md` (+ `.json`).
Window 2026-06-14 20:15 → 2026-06-15 21:00. Produced by PASS-2 Task 4 (`parity_report.py`).
**Headline:**
- Pick-match rate: **0.015 (1.5%)** — VIOLET rows 2853, exact pick matches only 43.
- Same-asset rate: **0.136 (13.6%)**; no-pick: **2465 / 2853 (86%)**.
- BLUE rows 25941 (scan_eval 25278 + trade_events 663).
**KEY NUANCE (where the review should START):** on the 43 rows that DID align, **sizing is
near-identical** — leverage abs error mean 0.016 / **median 0.0** / max 0.135. So the V3.4
sizing math (boost/beta/mc_scale/ob/esof/compose) is NOT the problem; the divergence is in
**ASSET SELECTION / TIMING / the comparison's ALIGNMENT method**. Candidate causes to
investigate (do not assume — measure):
1. **Apples-to-oranges population.** BLUE `scan_eval` (25278) is likely per-scan-per-asset
*evaluations*, while VIOLET rows are *actuated* decisions — the report may be comparing
different things. Verify the alignment/join semantics in `parity_report.py` first.
2. **Selection divergence.** VIOLET's `VioletAssetSelector` (IRP) vs BLUE's live selection over
the same scan stream — are they fed the same universe/lookback at the same scan index? The
sizing-gap samples (TRX/ATOM/LTC/XLM SHORT with large notional_rel_err) suggest VIOLET fires
on assets BLUE sized very differently or didn't pick.
3. **Cadence/actuation.** VIOLET actuates at Q=scan; if its scan alignment or dedupe differs,
picks land at different scans → counted as no-pick.
4. **The known structural items** (OB single-shot before V3.4d; mc_scale; live-factor sourcing)
— re-run parity AFTER V3.4d's persistent-OB launcher + the bit-identity fixes to see if the
number moves.
**Action:** full review of `parity_report.py` + a root-cause pass; fix the alignment OR the
selection divergence; re-run. This gates a meaningful DARK soak — a 1.5% pick-match makes the
soak uninterpretable. **Owner: Claude (me), later.**
---
## 🟡 #2 — Review the OA-delegated PASS work (NOT yet reviewed)
The parallel agent reports these DONE; none reviewed for correctness / BLUE-compliance yet.
**PASS 1** (`VIOLET_PART_SPEC_OA_TODO.md`):
- `53bdd90` sizing parity-pin tests
- `12b768b` venue OB provider seam (`venue_ob_provider.py`)
- `bae9284` base-fraction sizing study (+ archived report)
**PASS 2** (`VIOLET_PART_SPEC_OA_TODO_PASS2.md`):
- `parity_report.py` (Task 4 — the report above) + test
- `tradeability.py` (Task 6) + test
- `test_violet_v3_decision_latency_gate.py` (Task 5) → report `violet_v3_decision_latency_2026...`
- `test_violet_replay_determinism_gate.py` (Task 7) → report `violet_replay_determinism_2026...`
**PASS 3**: `VIOLET_PART_SPEC_OA_TODO_PASS3.md` (issued 2026-06-17) — venue feed / mechanical
exits / SL floor / event-restore / slippage / cadence; review when done.
**PASS 4**: `VIOLET_PART_SPEC_OA_TODO_PASS4.md` (issued 2026-06-17) — vol gate / V7 exit wrapper /
economics ledger / exec-intent / alpha data feed / time exits; review when done.
**Action:** review each pass for correctness, BLUE-algo compliance, V-TYPES, no-shared-edits,
real (non-vacuous) tests. **Owner: Claude (me), later.**
---
## 🟢 #3 — Integration / "sprint" consolidation (my later work)
Once the passes are reviewed, I will: **(a)** review ALL passes together, **(b)** integrate them
(resolve interfaces, dedupe), **(c)** test them together, **(d)** plug into the operational
system, **(e)** E2E test.
**Nomenclature note (raised by operator):** a "pass" here = a batch of self-contained tasks
delegated to one agent — smaller than an Agile **sprint** (a time-boxed iteration, typ. 1-4
weeks, team-scoped, ending in a shippable increment, with planning/review/retro ceremonies).
In this project's existing usage, **"Sprint N" already maps to a V-stage bundle** (Sprint 1 =
V0+V1, Sprint 2 = V2, Sprint 3 = V3) — i.e. an epic/milestone. So the cleanest mapping:
**V-stage = sprint/epic; "pass" = a sub-sprint work-package / task-bundle within it.** Renaming
passes to "sprints" would over-claim scope; keep "pass"/"work-package", or call each an
"increment". Decide at integration time.
---
## Gating rule
The DARK soak (operator-held) and V4 are NOT meaningfully runnable until CRITICAL #1 is
root-caused — a 1.5% pick-match means the shadow is not yet tracking BLUE's decisions.