jgrusewski 11979d7c08 docs(sp5): comprehensive implementation plan — 4 layers, ~21 tasks
SP5 implementation plan covering:
  Layer A: 8 per-pearl commits (Tasks A0-A8)
    A0: ISV slot constants foundation
    A1: Pearl 1 per-branch atom span + Q-stats source
    A2: Pearl 3 per-branch NoisyNet σ
    A3: Pearl 2 per-branch loss budget (after Pearls 1+3)
    A4: Pearl 4 per-group Adam β/β/ε
    A5: Pearl 5 per-branch IQN τ schedule
    A6: Pearl 6 cross-fold-persistent Kelly
    A7: Pearl 8 per-direction trail distance
    A8: Pearl 1-ext per-branch num_atoms

  Layer B: 1 atomic commit (Task B1) — 11 consumer migrations

  Layer C: validation + cleanup (Tasks C1-C6)
    C1: Local GPU unit tests
    C2: L40S 5-epoch smoke
    C3: L40S 3-seed × 50-epoch full validation
    C4: Pearl 7 investigation (post-validation)
    C5: Audit doc + 8 memory pearls
    C6: Layer C commit

  Layer D: separate atomic commit (Tasks D1-D4)
    D1: PnL aggregation kernel
    D2: Health composition kernel
    D3: Training metrics EMA kernel
    D4: Layer D atomic commit

Total: 21 numbered tasks, ~110 ISV slots, 9-11 producer kernels,
11 consumer migrations.

Plan follows SP4's high-fidelity-for-Task-A1 + differential-pattern-
for-A2-A8 structure. Each task has concrete file paths, code blocks,
verification commands, exact commit messages.

Self-review:
  - Spec coverage: all 9 pearls + 4 layers covered
  - No TBD/TODO placeholders in step bodies
  - Type/slot consistency verified across tasks

Refs: docs/superpowers/specs/2026-05-01-sp5-magnitude-differentiation-and-eval-collapse-design.md (HEAD 6e6e0fa11)
2026-05-01 20:01:27 +02:00

Foxhunt

Production HFT trading system in Rust.

Architecture

The workspace contains 32 crates organized as follows:

Core Libraries (16)

Crate Purpose
trading_engine Order processing, FIX 4.4, IB TWS, SIMD, RDTSC timing
risk VaR, Kelly, circuit breakers, kill switches, compliance
risk-data Risk data types and shared structures
trading-data Trading data types
ml DQN Rainbow, PPO, TFT, Mamba2, ensemble inference
ml-data ML data types and feature definitions
data Market data ingestion and storage
backtesting Replay engine, strategy tester
adaptive-strategy Ensemble execution, microstructure analysis
common Shared types, resilience, error handling
storage S3 and local model storage
model_loader Model serialization and loading
market-data Market data feed handlers
database PostgreSQL access layer (SQLx)
config Configuration management
tli CLI commands and tooling

Services (8)

Service Purpose
backtesting_service gRPC backtesting service
broker_gateway_service FIX routing, broker connectivity
trading_service Core trading operations
ml_training_service Model training orchestration
data_acquisition_service Market data acquisition
trading_agent_service Autonomous trading agents
api_gateway gRPC API gateway with auth
web-gateway Axum REST + WebSocket gateway

Frontend

web-dashboard/ -- React 19 + TypeScript + Vite + TradingView charts.

Building

# Check compilation (no PostgreSQL required)
SQLX_OFFLINE=true cargo check --workspace

# Run tests for a specific crate
SQLX_OFFLINE=true cargo test -p <crate> --lib

# Clippy
SQLX_OFFLINE=true cargo clippy --workspace

ML Models

Four production model architectures on Candle v0.9.1 with CUDA:

  • DQN Rainbow -- Deep Q-Network with prioritized replay, dueling heads, noisy nets
  • PPO -- Proximal Policy Optimization with GAE and LSTM policies
  • TFT -- Temporal Fusion Transformer for multi-horizon forecasting
  • Mamba2 -- State space model for sequence prediction

Each model has a standalone trainer and a UnifiedTrainable adapter for the hyperopt pipeline.

Infrastructure

  • Git: Gitea at git.fxhnt.ai (Tailscale-only), Scaleway DEV1-S
  • Observability: OpenTelemetry OTLP (env OTEL_EXPORTER_OTLP_ENDPOINT)
  • Database: PostgreSQL with SQLx offline mode for CI

License

Proprietary. All rights reserved.

Description
No description provided
Readme 849 MiB
Languages
Rust 88.2%
Cuda 7.7%
Python 1.3%
Shell 1.1%
PLpgSQL 0.8%
Other 0.8%