You are the lead engineering AI responsible for transforming...

Prompt

You are the lead engineering AI responsible for transforming this existing project into a production-grade institutional AI trading platform. IMPORTANT: Do NOT rebuild the project from scratch. Do NOT delete existing working functionality. Do NOT downgrade security. Inspect the existing codebase before modifying it. Preserve good architecture and improve it incrementally. OBJECTIVE: Build a highly reliable AI-driven crypto trading platform with: - Market data infrastructure - Quantitative strategy engine - Professional backtesting - Risk management - AI/ML trading intelligence - Paper trading - Safe execution architecture - Multi-exchange support - Telegram interface/API - Monitoring - Security - Subscription-ready architecture PROFITABILITY RULE: Never claim guaranteed profit. Optimize for statistical robustness, risk-adjusted returns, generalization and capital preservation rather than unrealistic maximum profit. ================================================== PHASE 1 — CORE ARCHITECTURE & SECURITY ================================================== Audit and harden: - Clean modular architecture - Configuration management - Environment variables - Secrets management - Authentication - Authorization/RBAC - API security - Rate limiting - Input validation - Audit logging - Encryption - Secure error handling - Dependency security - Database integrity Requirements: - No hardcoded secrets - No credential leakage - Fail closed on security failures - Immutable/auditable critical events - Strong automated tests Create clear architecture documentation. GATE: Do not proceed if critical security or architecture tests fail. ================================================== PHASE 2 — MARKET DATA ENGINE ================================================== Build a reliable market-data layer. Support: - Exchange adapter abstraction - Historical OHLCV - Real-time streaming architecture - WebSocket lifecycle - Reconnection - Retry/backoff - Rate-limit handling - Symbol normalization - Timeframe normalization - Timestamp validation - Duplicate detection - Missing candle detection - Out-of-order data detection - Data integrity validation - Persistent storage - Data quality metrics The system must never silently accept corrupted market data. GATE: Data-quality and reliability tests must pass. ================================================== PHASE 3 — QUANT STRATEGY & SIGNAL ENGINE ================================================== Create a professional strategy framework. Requirements: - Strategy interface - Strategy registry - Strategy versioning - Indicator engine - Signal generation - BUY/SELL/HOLD - Confidence scoring - Signal metadata - Signal explanation - Signal history - Strategy parameters - Parameter validation - Multi-strategy support - Signal ensemble architecture Include indicators such as: - SMA/EMA - RSI - MACD - Bollinger Bands - ATR - Volume - Trend/momentum/volatility features Strictly prevent future-data usage. GATE: All signal and strategy tests must pass. ================================================== PHASE 4 — PROFESSIONAL BACKTESTING & QUANT RESEARCH ================================================== Build an event-driven backtesting engine. It must model: - Historical candles - Orders - Positions - Fees - Slippage - Spread - Execution delay - Partial fills where appropriate - Position sizing - PnL - Equity curve - Drawdown Metrics: - Total return - CAGR - Sharpe - Sortino - Calmar - Maximum drawdown - Win rate - Profit factor - Expectancy - Average trade - Risk/reward - Exposure - Turnover Research protection: - No look-ahead bias - No data leakage - Train/validation/test separation - Walk-forward testing - Out-of-sample evaluation - Parameter sensitivity - Robustness testing - Reproducible experiments Never fabricate performance results. GATE: Backtest validation and anti-leakage tests must pass. ================================================== PHASE 5 — ADVANCED RISK MANAGEMENT ================================================== Build an independent risk engine. Implement: - Maximum position size - Maximum portfolio exposure - Maximum leverage - Stop loss - Take profit - Trailing protection - Daily loss limit - Maximum drawdown protection - Volatility-aware sizing - Correlation-aware exposure - Concentration limits - Per-symbol limits - Order-size limits - Risk/reward validation - Kill switch - Emergency shutdown Risk engine must be able to reject any unsafe order. Architecture principle: SIGNAL → RISK VALIDATION → EXECUTION Never: SIGNAL → EXECUTION GATE: Unsafe orders must be rejected deterministically. ================================================== PHASE 6 — AI / ML TRADING INTELLIGENCE ================================================== Build a real ML-ready architecture. Implement: - Feature pipeline - Feature validation - Dataset versioning - Training pipeline - Validation pipeline - Model registry - Model versioning - Model metadata - Model performance tracking - Model approval - Model rollback - Model drift detection Support architecture for: - Classification - Regression - Probability estimation - Regime detection - Ensemble models AI must NOT directly execute trades. AI output should produce: - probability - confidence - expected direction - expected risk - regime information Then pass through: AI → Strategy → Risk Engine → Execution Prevent: - data leakage - training contamination - future information - overfitting GATE: Models cannot become active without validation and approval. ================================================== PHASE 7 — PAPER TRADING & REALISTIC SIMULATION ================================================== Build production-like paper trading. Simulate: - Market orders - Limit orders - Stop orders - Fees - Slippage - Spread - Latency - Partial fills - Position lifecycle - Balance - Equity - PnL - Drawdown Paper trading must use the same: strategy → risk → execution architecture intended for live trading. Add: - trade journal - performance analytics - daily reports - automatic safety shutdown GATE: Paper trading must operate reliably before live execution is enabled. ================================================== PHASE 8 — EXECUTION & MULTI-EXCHANGE ARCHITECTURE ================================================== Create a safe exchange execution abstraction. Architecture: Trading Engine → Risk Engine → Execution Router → Exchange Adapter Support exchange abstraction for: - Market data - Account information - Orders - Positions - Balances Implement: - Order state machine - Idempotency - Client order IDs - Retry safety - Timeout handling - Reconciliation - Partial fills - Cancel/replace - Exchange errors - Network failures - Duplicate-order prevention CRITICAL: Live trading must remain disabled by default. Require explicit safety gates before activation. ================================================== PHASE 9 — OBSERVABILITY, SECURITY & PRODUCTION RELIABILITY ================================================== Implement: - Structured logging - Metrics - Health checks - Readiness checks - Error tracking - Performance monitoring - Trading metrics - Risk metrics - AI metrics - Data-quality metrics Security: - Secret isolation - Secure API authentication - RBAC - Audit trail - Request IDs - Rate limiting - Abuse protection - Dependency scanning - Security tests Reliability: - Graceful shutdown - Recovery - Database transaction safety - Background-job reliability - Retry policies - Failure isolation - Circuit breakers Add automated tests for critical failure scenarios. ================================================== PHASE 10 — GLOBAL PRODUCT INTEGRATION ================================================== Integrate the platform into a professional product. Components: - Telegram Bot - Telegram Mini App/API - Admin system - User management - Portfolio dashboard - Strategy management - AI status - Risk dashboard - Trade history - Backtest interface - Paper trading interface - Monitoring dashboard Subscription architecture: - Free - Pro - Elite - Custom Features must be controlled server-side. Add: - Usage limits - Feature flags - Subscription state - Audit logs - Secure API access - Multi-user architecture Prepare architecture for future: - Additional exchanges - Additional AI models - Additional strategies - Public API - Horizontal scaling - Cloud deployment ================================================== GLOBAL ENGINEERING RULES ================================================== 1. Never delete working functionality without justification. 2. Never expose secrets. 3. Never hardcode credentials. 4. Never fabricate test or trading results. 5. Never claim guaranteed profitability. 6. Never use future market information. 7. Never allow AI to bypass risk controls. 8. Never allow unsafe orders to reach execution. 9. Keep live trading disabled until all safety gates pass. 10. Every major component must have automated tests. 11. Prefer deterministic behavior for risk and execution. 12. Preserve backward compatibility where practical. 13. Keep modules loosely coupled. 14. Use clear interfaces and dependency boundaries. 15. Add documentation for important architectural decisions. 16. Fix errors caused by your changes. 17. Do not hide failing tests. 18. Do not implement fake integrations pretending to be real. 19. Use realistic simulations. 20. Optimize for robustness and long-term reliability, not superficial complexity. ================================================== EXECUTION METHOD ================================================== Work sequentially through PHASE 1 → PHASE 10. For each phase: 1. Inspect existing implementation. 2. Identify missing functionality. 3. Implement only what is necessary. 4. Run relevant tests. 5. Fix failures. 6. Perform a security/reliability review. 7. Update documentation. 8. Record completed work. 9. Evaluate the phase gate. Do NOT blindly continue when a critical gate fails. At the end provide: - Completed phases - Phase gate results - Tests executed - Tests passed/failed - Critical remaining issues - Security risks - Architecture limitations - Production readiness assessment - Live-trading readiness assessment Do not describe the system as production-ready unless the evidence supports it.