Remix

Make your own version of NEXUS QUANT AI

Get an exact, working copy in your account, then change anything with chat.

Original by MR. THUVA

What would you change?

Start free with 40 credits. No card needed.

Start fresh from this prompt

Builds a brand new app from the first prompt only, so later changes to the original are not included.

NEXUS QUANT AI

COMPLETE ENTERPRISE MASTER BUILD PROMPT

Production Architecture | Quantitative Trading | AI Intelligence | Multi-Exchange

---

0. MASTER DEVELOPMENT INSTRUCTIONS

You are an entire senior fintech software development team consisting of:

- Principal Software Architect
- Senior Python Backend Engineer
- Senior React/Next.js Frontend Engineer
- Quantitative Trading Systems Engineer
- Market Microstructure Research Engineer
- AI/ML Engineer
- Database Engineer
- Cybersecurity Engineer
- DevOps Engineer
- QA Automation Engineer
- Enterprise UI/UX Designer

Your mission is to design, develop, integrate, test, and document a complete enterprise-grade cryptocurrency trading intelligence platform.

PROJECT NAME: NEXUS QUANT AI

Do not create a simple website, static dashboard, landing-page-only project, or visual prototype.

Build a real, modular, scalable application with functional interfaces, backend services, database persistence, real market data integrations, quantitative research, demo execution, and independent risk management.

Every feature must be implemented or explicitly identified as pending.

Never claim an integration works without testing it.

Do not replace missing backend functionality with frontend mock data.

Do not generate fake trading profits.

Do not leave buttons, menus, navigation items, or important dashboard panels nonfunctional.

Build incrementally while maintaining one consistent architecture.

IMPORTANT OPERATIONAL RESTRICTION:

The initial application is a research, monitoring, backtesting, and demo-trading platform. Real-money order execution must remain disabled. Exchange live account information may only be accessed through appropriately authorized read-only credentials. Never request or expose withdrawal permissions or enable real-money trading execution.

---

1. PRODUCT VISION

Build a premium institutional-grade quantitative trading platform that combines:

1. Cryptocurrency market intelligence.
2. Multi-exchange market connectivity.
3. Automated quantitative strategy research.
4. Avellaneda–Stoikov market-making calculations.
5. Inventory-aware strategy modelling.
6. Independent risk supervision.
7. Demo execution.
8. Historical backtesting.
9. AI-powered market explanations.
10. Portfolio and performance analytics.
11. Professional monitoring.
12. Complete audit and event history.

The system must be designed for future expansion to additional exchanges, assets, strategies, and analytics modules.

The platform must work on desktop, laptop, tablet, and Android mobile browsers.

---

2. COMPLETE SYSTEM ARCHITECTURE

Implement the following architecture:

A. Presentation Layer
B. API and Application Layer
C. Market Data Layer
D. Quantitative Strategy Layer
E. Risk Supervision Layer
F. Demo Execution Layer
G. Exchange Integration Layer
H. AI Intelligence Layer
I. Persistence Layer
J. Monitoring and Observability Layer

Each layer must have clear responsibilities.

Use dependency injection and well-defined service interfaces.

No circular dependencies.

No direct database access from frontend components.

No direct exchange access from frontend JavaScript.

All sensitive operations must be validated by the backend.

---

3. EXCHANGE CONNECTIVITY

Implement independent exchange adapters.

3.1 BINANCE

Support:

- Binance market data REST API.
- Binance public WebSocket streams.
- Ticker streams.
- Order book streams.
- Kline/candlestick streams.
- Recent trade streams.
- Exchange metadata.
- Symbol filters.
- Tick sizes.
- Quantity precision.
- Minimum order information.
- Exchange status.
- API health.

Demo integration:

- Support the appropriate Binance Spot Demo Trading environment where available.
- Separate demo credentials and configuration.
- Clearly identify simulated execution.
- Never assume demo fills equal live fills.

Read-only account integration:

- Account balance.
- Asset information.
- Account status where supported.

Use official exchange documentation to validate current endpoints, permissions, authentication and rate limits.

3.2 GEMINI EXCHANGE

Implement:

- Gemini public market data.
- WebSocket market streams.
- Ticker data.
- Order book data.
- Trade history.
- Symbol metadata.
- Sandbox connectivity.
- Account information using authorized read-only credentials.
- API connection monitoring.

Keep Gemini Exchange completely separate from Google Gemini AI.

Sandbox and production configurations must never share credentials.

3.3 EXCHANGE ADAPTER INTERFACE

Create a common exchange interface:

- connect()
- disconnect()
- health_check()
- get_symbols()
- get_ticker()
- get_order_book()
- get_historical_candles()
- get_recent_trades()
- get_account_balance_readonly()
- get_exchange_metadata()

Implement capability detection because exchange features and endpoint support differ.

All exchange integrations must have independent error handling.

3.4 MARKET DATA NORMALIZATION

Normalize exchange data into common internal models.

Required fields:

- exchange
- symbol
- timestamp
- bid
- ask
- last_price
- volume
- spread
- bid_depth
- ask_depth
- sequence_number where available

Validate timestamps and stale data.

Reject invalid or incomplete market snapshots.

---

4. REAL-TIME MARKET DATA ENGINE

Create an asynchronous market data service.

Features:

- WebSocket subscription management.
- Multiple symbol subscriptions.
- Multiple exchange subscriptions.
- Automatic reconnection.
- Heartbeat monitoring.
- Sequence gap detection where supported.
- Order book synchronization.
- Data normalization.
- Stale feed detection.
- Rate-limit monitoring.
- Connection status.
- Data buffering.
- Historical data storage.

Display real-time connection health.

Never display stale information as live data.

Provide clear data timestamps.

If an exchange connection fails, show the failure and last successful update.

---

5. QUANTITATIVE STRATEGY ENGINE

5.1 AVELLANEDA–STOIKOV MODEL

Implement the Avellaneda–Stoikov market-making model as a configurable research strategy.

Core calculations:

reservation_price()
estimate_volatility()
estimate_inventory()
calculate_optimal_spread()
calculate_bid_quote()
calculate_ask_quote()
calculate_inventory_skew()
calculate_quote_distance()

Model inputs:

- Mid price.
- Inventory.
- Volatility.
- Risk aversion.
- Liquidity parameters.
- Time horizon.
- Remaining trading time.
- Market spread.
- Fee assumptions.

Provide configurable parameters.

Explain every calculated output.

Display:

- Mid price.
- Reservation price.
- Theoretical bid.
- Theoretical ask.
- Quote spread.
- Inventory adjustment.
- Volatility adjustment.
- Model timestamp.

Do not present model outputs as guaranteed profitable orders.

5.2 STRATEGY MANAGEMENT

Create a strategy management module.

Features:

- Create strategy configuration.
- Edit configuration.
- Duplicate configuration.
- Archive configuration.
- Strategy version history.
- Enable/disable research calculations.
- Parameter validation.
- Strategy status.
- Performance comparison.

Initial strategy:

Avellaneda–Stoikov Market Making.

Future strategy interfaces:

- EMA research.
- RSI research.
- Momentum analysis.
- Mean-reversion analysis.
- Volatility-based strategy.
- Statistical arbitrage research.

Future strategies must not be automatically enabled.

---

6. INVENTORY MANAGEMENT ENGINE

Implement:

- Per-asset inventory tracking.
- Inventory ratio.
- Total exposure.
- Asset concentration.
- Inventory valuation.
- Inventory history.
- Average acquisition price where data permits.
- Unrealized valuation.
- Inventory imbalance.
- Inventory limit alerts.

Calculate inventory using reconciled data.

Clearly distinguish simulated inventory from actual account information.

---

7. INDEPENDENT RISK SUPERVISOR

This is a mandatory independent service.

Every proposed execution must be checked by the risk supervisor.

Implement the following controls:

1. Emergency stop state.
2. Maximum inventory.
3. Maximum notional exposure.
4. Maximum portfolio concentration.
5. Maximum drawdown.
6. Daily loss threshold.
7. Maximum order quantity.
8. Maximum open-order count.
9. Maximum order frequency.
10. Stale market data rejection.
11. Exchange health verification.
12. Abnormal volatility alerts.
13. Invalid price rejection.
14. Insufficient balance detection.
15. Duplicate order detection.

Initial configurable research defaults:

- Maximum inventory ratio: 20%.
- Maximum drawdown threshold: 3%.
- Risk aversion parameter: 0.1.
- Base spread: 3 ticks.

These are configurable example values, not universally safe parameters.

KILL SWITCH

Implement a persistent emergency stop.

When activated:

- Reject new order proposals.
- Stop the demo execution engine.
- Cancel eligible outstanding demo orders.
- Set engine status to HALTED.
- Record the triggering event.
- Notify the dashboard.
- Require manual review and explicit restart.

Never automatically restart after a risk breach.

The risk supervisor must operate independently of the AI service.

The AI service must never override risk controls.

---

8. DEMO EXECUTION ENGINE

Create a complete demo execution environment.

Features:

- Demo account balances.
- Simulated order placement.
- Simulated order cancellation.
- Simulated fills.
- Partial fills.
- Order lifecycle.
- Trading fees.
- Configurable latency.
- Configurable slippage.
- Liquidity-aware fill simulation.
- Insufficient balance handling.
- Order rejection.
- Trade reconciliation.
- Inventory updates.
- Demo P&L.

Order lifecycle:

PROPOSED
VALIDATING
APPROVED
SUBMITTED
OPEN
PARTIALLY_FILLED
FILLED
CANCEL_PENDING
CANCELLED
REJECTED
EXPIRED
ERROR

All state transitions must be validated.

The simulator must not fabricate guaranteed fills.

Support different execution assumptions and display the assumptions used.

Keep demo records separate from actual exchange records.

---

9. PAPER TRADING

Create a separate paper-trading environment.

Characteristics:

- Real public exchange market data.
- Internal virtual account balances.
- Internal simulated execution.
- No real exchange orders.
- Configurable fees and slippage.
- Persistent virtual portfolio.
- Historical trade log.
- Performance reports.

Paper trading and exchange demo trading must be separately identified.

Never combine their P&L.

---

10. P&L AND ACCOUNTING ENGINE

Create a dedicated accounting service.

Track:

- Realized P&L.
- Unrealized P&L.
- Gross P&L.
- Net P&L.
- Trading fees.
- Estimated slippage.
- Average execution price.
- Position valuation.
- Total portfolio value.
- Peak equity.
- Maximum drawdown.

Use reconciled execution records for exchange-reported performance.

Use separate accounting ledgers for:

1. Paper trading.
2. Exchange demo trading.
3. Read-only actual account information.

Never mix simulated and actual P&L.

Document valuation assumptions.

Handle partial fills and fees correctly.

Use decimal arithmetic for financial calculations.

---

11. GOOGLE GEMINI AI INTELLIGENCE

Integrate Google Gemini AI through a secure backend service.

This is separate from Gemini Exchange.

AI modules:

A. Market Explanation
B. Volatility Analysis
C. Market Regime Explanation
D. Strategy Performance Explanation
E. Risk Event Explanation
F. Portfolio Summary
G. Anomaly Explanation
H. Natural Language Dashboard Assistant
I. Historical Performance Interpretation

AI output must:

- Identify its data timestamp.
- Identify missing information.
- Explain uncertainty.
- Avoid guaranteed predictions.
- Distinguish observations from recommendations.
- Never generate fake market data.
- Never place orders.
- Never override risk supervision.

Implement:

- API timeout handling.
- Rate-limit handling.
- Token usage monitoring.
- Error handling.
- Secure API key management.
- AI request history.
- Response validation.
- User-visible AI status.

When AI is unavailable, the core trading research and dashboard must continue working.

---

12. COMPLETE ENTERPRISE DASHBOARD

Create a polished institutional-grade trading terminal.

12.1 COMMAND CENTER

Display:

- Platform status.
- Exchange connection status.
- Market data status.
- Strategy engine status.
- Risk supervisor status.
- AI service status.
- Current operating mode.
- Portfolio overview.
- Realized P&L.
- Unrealized P&L.
- Current drawdown.
- Active market symbols.
- Recent activity.
- System alerts.

12.2 LIVE MARKET TERMINAL

Include:

- Interactive candlestick chart.
- Multiple timeframes.
- Trading pair selector.
- Exchange selector.
- Bid and ask.
- Mid price.
- Spread.
- Market volume.
- Order book depth.
- Recent trades.
- Volatility chart.
- Market data timestamp.

12.3 ORDER BOOK TERMINAL

Display:

- Bid levels.
- Ask levels.
- Price.
- Quantity.
- Cumulative depth.
- Spread.
- Depth imbalance.
- Exchange source.
- Data freshness.

12.4 TRADING ENGINE PANEL

Display:

- Engine status.
- Strategy name.
- Demo mode.
- Selected symbols.
- Strategy parameters.
- Reservation price.
- Theoretical bid.
- Theoretical ask.
- Inventory ratio.
- Quote spread.
- Strategy calculations.
- Execution simulation status.
- Start/stop demo controls.

12.5 PORTFOLIO DASHBOARD

Display:

- Total demo balance.
- Available balance.
- Locked balance.
- Asset allocation.
- Portfolio valuation.
- Realized P&L.
- Unrealized P&L.
- Fee history.
- Portfolio performance chart.

12.6 RISK CONTROL CENTER

Display:

- Current risk status.
- Drawdown.
- Exposure.
- Inventory.
- Concentration.
- Daily loss.
- Risk limits.
- Trigger history.
- Kill switch.
- Risk validation records.

12.7 ORDER MANAGEMENT

Display:

- Order ID.
- Exchange.
- Symbol.
- Side.
- Price.
- Quantity.
- Filled quantity.
- Average execution price.
- Fee.
- Status.
- Timestamp.

Include order history filters.

12.8 TRADE HISTORY

Display:

- Trade ID.
- Order ID.
- Symbol.
- Side.
- Execution price.
- Quantity.
- Fee.
- Realized result.
- Execution timestamp.

Provide search, filters, pagination, and CSV export.

12.9 ANALYTICS

Include:

- Equity curve.
- Drawdown chart.
- Daily performance.
- Weekly performance.
- Monthly performance.
- Win/loss statistics where meaningful.
- Average trade result.
- Fee analysis.
- Slippage analysis.
- Inventory utilization.
- Strategy comparison.

Display sample size and statistical limitations.

12.10 BACKTESTING LAB

Features:

- Historical date selection.
- Symbol selection.
- Strategy selection.
- Parameter configuration.
- Fee assumptions.
- Slippage assumptions.
- Historical market data validation.
- Backtest execution.
- Results persistence.
- Equity curve.
- Drawdown chart.
- Trade history.
- Performance report.

Prevent look-ahead bias and data leakage.

Include realistic execution assumptions.

12.11 AI INTELLIGENCE CENTER

Display:

- AI service status.
- Market summaries.
- Volatility explanations.
- Risk summaries.
- Strategy explanations.
- Historical analysis.
- AI interaction history.

12.12 EXCHANGE CENTER

Separate cards for:

BINANCE

- Public data connection.
- Demo connectivity.
- Read-only account connectivity.
- API health.

GEMINI EXCHANGE

- Public data connection.
- Sandbox connectivity.
- Read-only account connectivity.
- API health.

Display permissions and connection errors.

Never display API secrets.

12.13 SYSTEM MONITORING

Display:

- CPU utilization.
- Memory utilization.
- Database health.
- Redis health.
- API response time.
- WebSocket status.
- Exchange latency.
- Queue status.
- Background worker status.
- Error count.
- Uptime.

Use Prometheus and Grafana where deployed.

12.14 ADMINISTRATION

Implement:

- User management.
- Role management.
- Permission management.
- Session management.
- Audit history.
- System settings.
- Notification settings.
- Application configuration.

---

13. COMPLETE NAVIGATION STRUCTURE

Create the following navigation:

OVERVIEW

- Command Center

MARKETS

- Live Markets
- Order Book
- Market Analytics

INTELLIGENCE

- AI Intelligence
- Market Regimes
- Strategy Insights

TRADING

- Trading Engine
- Strategy Laboratory
- Demo Trading
- Paper Trading
- Order Management
- Trade History

PORTFOLIO

- Overview
- Asset Allocation
- P&L Analytics

RESEARCH

- Backtesting Lab
- Performance Reports
- Strategy Comparison

RISK

- Risk Dashboard
- Exposure Monitor
- Risk Events
- Emergency Controls

EXCHANGES

- Binance
- Gemini Exchange
- API Connections

SYSTEM

- Monitoring
- Notifications
- Audit Logs
- Settings
- Administration

Every navigation item must open a real, implemented page.

---

14. NOTIFICATION SYSTEM

Create notifications for:

- Exchange disconnection.
- WebSocket interruption.
- Stale market data.
- Risk limit breach.
- Drawdown warning.
- Daily loss warning.
- Kill switch activation.
- Strategy error.
- Database failure.
- AI service failure.
- Demo order rejection.
- Execution simulation completion.

Support:

- In-app notifications.
- Notification history.
- Read/unread state.
- Severity classification.
- Timestamp.
- Notification filters.

---

15. DATABASE ARCHITECTURE

Use PostgreSQL with SQLAlchemy and Alembic migrations.

Create normalized tables:

1. users
2. roles
3. permissions
4. user_roles
5. exchange_connections
6. exchange_capabilities
7. market_symbols
8. market_snapshots
9. order_book_snapshots
10. candle_history
11. strategies
12. strategy_versions
13. strategy_parameters
14. strategy_runs
15. demo_accounts
16. demo_balances
17. orders
18. trades
19. positions
20. portfolio_snapshots
21. pnl_snapshots
22. risk_configurations
23. risk_events
24. audit_logs
25. notifications
26. backtest_jobs
27. backtest_results
28. ai_requests
29. ai_responses
30. system_events
31. application_settings

Requirements:

- Foreign key integrity.
- Appropriate indexing.
- Unique constraints.
- Transaction management.
- Database migration history.
- UTC timestamps.
- Financial decimal precision.
- Retention policies.
- Backup and recovery procedures.

Never store passwords in plaintext.

Never store API secrets in publicly accessible tables.

Use encrypted secret storage.

---

16. BACKEND API SPECIFICATION

Use FastAPI.

Create versioned API routes.

Authentication:

- POST /api/v1/auth/login
- POST /api/v1/auth/logout
- GET /api/v1/auth/me

Dashboard:

- GET /api/v1/dashboard/overview
- GET /api/v1/dashboard/health

Markets:

- GET /api/v1/markets/symbols
- GET /api/v1/markets/ticker
- GET /api/v1/markets/orderbook
- GET /api/v1/markets/candles
- GET /api/v1/markets/trades

Strategies:

- GET /api/v1/strategies
- POST /api/v1/strategies
- GET /api/v1/strategies/{id}
- PUT /api/v1/strategies/{id}
- POST /api/v1/strategies/{id}/validate

Demo:

- GET /api/v1/demo/account
- GET /api/v1/demo/orders
- GET /api/v1/demo/trades
- POST /api/v1/demo/start
- POST /api/v1/demo/stop

Risk:

- GET /api/v1/risk/status
- GET /api/v1/risk/events
- POST /api/v1/risk/kill-switch
- POST /api/v1/risk/review

Portfolio:

- GET /api/v1/portfolio/overview
- GET /api/v1/portfolio/positions
- GET /api/v1/portfolio/performance

Backtesting:

- POST /api/v1/backtests
- GET /api/v1/backtests
- GET /api/v1/backtests/{id}

AI:

- POST /api/v1/ai/analyze
- GET /api/v1/ai/history
- GET /api/v1/ai/status

Exchanges:

- GET /api/v1/exchanges
- GET /api/v1/exchanges/health
- GET /api/v1/exchanges/capabilities

Monitoring:

- GET /api/v1/system/health
- GET /api/v1/system/metrics
- GET /api/v1/system/events

All endpoints must have request validation, response schemas, authorization, logging, and documented error responses.

Do not expose sensitive configuration through API responses.

Generate OpenAPI documentation.

---

17. FRONTEND ARCHITECTURE

Use:

- Next.js
- React
- TypeScript
- Tailwind CSS
- Lucide Icons
- TradingView Lightweight Charts

Create reusable components:

- AppSidebar
- TopNavigation
- DashboardHeader
- StatusIndicator
- ExchangeStatusCard
- MetricCard
- PnLCard
- MarketChart
- OrderBook
- RecentTrades
- TradingEnginePanel
- StrategyParameters
- RiskStatusPanel
- PortfolioAllocation
- ActivityTimeline
- NotificationCenter
- DataTable
- ConfirmationDialog
- ErrorBoundary
- LoadingState
- EmptyState

Use:

- Strong TypeScript types.
- Centralized API client.
- Server-side authorization.
- Proper loading states.
- Error states.
- Empty states.
- Responsive layout.
- Accessible controls.
- Consistent formatting.

Do not create oversized cards or excessive decorative elements.

---

18. DESIGN SYSTEM

DESIGN DIRECTION:

Institutional quantitative trading software.

Visual identity:

- Premium dark graphite.
- Deep navy surfaces.
- Restrained silver and muted teal accents.
- Clear financial typography.
- High information density.
- Professional charts.
- Precise spacing.
- Consistent border treatments.
- Subtle animations.
- High-quality icons.

Design principles:

1. Information hierarchy.
2. Readability.
3. Operational clarity.
4. Minimal visual noise.
5. Professional financial terminal appearance.

Use green and red only when appropriate for positive and negative financial states.

Avoid:

- Excessive gradients.
- Rainbow colors.
- Excessive glowing effects.
- Cartoon illustrations.
- Generic AI-themed graphics.
- Unnecessary animated backgrounds.
- Decorative elements that reduce readability.

RESPONSIVE DESIGN

Desktop:

- Full multi-panel workspace.
- Collapsible sidebar.
- Multi-column dashboard.
- Advanced data tables.

Tablet:

- Adaptive grid.
- Compact navigation.
- Responsive charts.

Android:

- Mobile navigation.
- Compact metric cards.
- Scrollable data tables.
- Touch-friendly controls.
- Mobile chart interaction.
- Accessible emergency status.
- No horizontal page overflow.

Maintain a consistent identity across all screen sizes.

---

19. AUTHENTICATION AND AUTHORIZATION

Implement:

- Secure login.
- Logout.
- Session expiration.
- Password hashing.
- Role-based access.
- Permission checks.
- Login attempt protection.
- Secure cookies.
- Session revocation.
- Audit logging.

Suggested roles:

- Administrator.
- Analyst.
- Viewer.

Restrict privileged administrative operations.

Never trust frontend role information without backend verification.

---

20. SECURITY ARCHITECTURE

Implement:

- Environment-based secrets.
- Encryption at rest where applicable.
- HTTPS.
- Secure headers.
- CSRF protection.
- Input validation.
- SQL injection protection.
- Rate limiting.
- Authentication security.
- Dependency scanning.
- Audit logging.
- Backup encryption.
- Firewall configuration.
- Non-root containers.
- Secure session handling.

API keys:

- Never hardcode secrets.
- Never expose secrets in frontend code.
- Never commit .env files.
- Use separate credentials for each environment.
- Use read-only permissions for account monitoring.
- Disable withdrawals.
- Rotate credentials when required.

Provide a safe configuration template with placeholder values only.

---

21. ERROR HANDLING AND RESILIENCE

Implement centralized error handling.

Handle:

- Network failures.
- Exchange downtime.
- Authentication errors.
- Rate-limit responses.
- Invalid symbols.
- Invalid quantities.
- WebSocket disconnects.
- Database failures.
- Redis failures.
- AI API failures.
- Invalid market data.
- Stale prices.
- Background task failures.

Use bounded retries with exponential backoff and jitter.

Do not retry rejected operations indefinitely.

Implement:

- Health checks.
- Graceful shutdown.
- Recovery procedures.
- Idempotency.
- Structured logs.
- Failure notifications.

---

22. INFRASTRUCTURE AND DEPLOYMENT

Backend:

- Python 3.11+
- FastAPI
- Uvicorn

Frontend:

- Next.js
- TypeScript

Database:

- PostgreSQL
- Optional TimescaleDB

Cache:

- Redis

Monitoring:

- Prometheus
- Grafana

Proxy:

- Nginx

Containers:

- Docker
- Docker Compose

Services:

1. frontend
2. backend
3. trading_research_worker
4. market_data_worker
5. ai_service
6. postgres
7. redis
8. nginx
9. prometheus
10. grafana

Use health checks and persistent database volumes.

Provide:

- Dockerfile.
- docker-compose.yml.
- .env.example.
- Database migrations.
- Production configuration.
- Development configuration.
- Deployment guide.
- Backup guide.
- Recovery guide.

Do not expose database or monitoring ports publicly without appropriate access controls.

---

23. PERFORMANCE REQUIREMENTS

Design for:

- Asynchronous market data.
- Efficient WebSocket processing.
- Database connection pooling.
- Indexed queries.
- Pagination.
- Efficient chart updates.
- Bounded background queues.
- Redis caching.
- Controlled subscription management.

Monitor:

- API response time.
- WebSocket lag.
- Data freshness.
- CPU utilization.
- Memory utilization.
- Database query performance.
- Queue depth.

Do not claim latency guarantees without measurement.

---

24. TESTING AND QUALITY ASSURANCE

Create automated tests.

Unit tests

- Reservation price.
- Quote calculation.
- Volatility estimation.
- Inventory calculation.
- Risk validation.
- P&L calculation.
- Fee calculation.
- Order state transitions.

Integration tests

- Binance public API.
- Binance demo environment.
- Gemini public API.
- Gemini sandbox.
- Google Gemini AI.
- PostgreSQL.
- Redis.
- WebSocket processing.

Functional tests

- Login.
- Navigation.
- Dashboard updates.
- Symbol selection.
- Chart rendering.
- Strategy configuration.
- Demo start/stop.
- Kill switch.
- Order history.
- Portfolio updates.
- AI analysis.

Security tests

- Unauthorized access.
- Permission enforcement.
- Input validation.
- Secret exposure.
- Session handling.
- API rate limiting.

Mobile tests

- Android viewport.
- Navigation.
- Tables.
- Charts.
- Forms.
- Touch controls.
- Overflow.
- Readability.

Every test must produce a verifiable result.

---

25. PERFORMANCE AND TRADING REPORTS

Create downloadable reports containing:

- Date range.
- Strategy.
- Exchange.
- Trading pair.
- Starting virtual balance.
- Ending virtual balance.
- Realized P&L.
- Unrealized P&L.
- Fees.
- Drawdown.
- Trade count.
- Win/loss statistics.
- Execution assumptions.
- Data quality notes.

Support CSV export.

Clearly identify demo, paper, and read-only actual account information.

---

26. LEGAL AND USER TRANSPARENCY

Create:

- Terms of Service.
- Privacy Policy.
- Risk Disclosure.
- Data Usage Policy.
- API Credential Security Information.
- System Limitations.

Explain:

- Trading involves risk.
- No profit is guaranteed.
- Historical performance does not predict future results.
- Simulated execution differs from live exchange execution.
- AI analysis may be inaccurate.
- Users must verify applicable local laws and exchange terms.

Do not make unsupported claims of regulatory compliance.

---

27. COMPLETE DEVELOPMENT ROADMAP

PHASE 01 — Project foundation

- Architecture.
- Repository.
- Environment.
- Dependency configuration.

PHASE 02 — Database

- Schema.
- Migrations.
- Persistence.
- Data models.

PHASE 03 — Authentication

- Login.
- Sessions.
- Permissions.

PHASE 04 — Enterprise frontend

- Design system.
- Navigation.
- Responsive layouts.
- Dashboard components.

PHASE 05 — Market data

- Binance.
- Gemini.
- WebSockets.
- Normalization.

PHASE 06 — Strategy research

- Avellaneda–Stoikov.
- Volatility.
- Inventory.
- Quote calculations.

PHASE 07 — Risk supervisor

- Risk configuration.
- Validation.
- Kill switch.
- Event logging.

PHASE 08 — Demo execution

- Virtual account.
- Order lifecycle.
- Simulated fills.
- Accounting.

PHASE 09 — AI intelligence

- Gemini AI.
- Analysis services.
- Dashboard assistant.

PHASE 10 — Portfolio and analytics

- Positions.
- P&L.
- Performance reports.

PHASE 11 — Backtesting

- Historical data.
- Simulation.
- Reports.

PHASE 12 — Monitoring

- Prometheus.
- Grafana.
- Logs.
- Health checks.

PHASE 13 — Security

- Audit.
- Permission testing.
- Credential protection.

PHASE 14 — Quality assurance

- Unit tests.
- Integration tests.
- Functional tests.
- Mobile tests.

PHASE 15 — Deployment

- Docker.
- HTTPS.
- Production configuration.
- Documentation.

Do not skip phases merely to produce a quick visual result.

---

28. PROJECT FILE STRUCTURE

Create a clean repository structure:

nexus-quant-ai/
frontend/
app/
components/
features/
hooks/
services/
types/
styles/
tests/

backend/
app/
api/
core/
models/
schemas/
services/
repositories/
middleware/
integrations/
binance/
gemini_exchange/
google_gemini_ai/
market_data/
strategies/
risk/
execution/
accounting/
analytics/
backtesting/
monitoring/
migrations/
tests/

workers/
market_data/
research/
analytics/

infrastructure/
docker/
nginx/
prometheus/
grafana/

docs/
architecture/
api/
security/
deployment/
user_guide/

scripts/
docker-compose.yml
.env.example
README.md

Adjust this structure only when there is a documented architectural reason.

---

29. ACCEPTANCE CRITERIA

The project is not complete until:

1. Application starts successfully.
2. Frontend connects to backend.
3. Authentication works.
4. Database migrations succeed.
5. Market data integration is verified.
6. WebSocket data updates correctly.
7. Exchange connectivity status is accurate.
8. Strategy calculations pass tests.
9. Risk supervisor validates proposed actions.
10. Kill switch works and persists.
11. Demo simulation works.
12. Paper trading works independently.
13. P&L accounting passes test cases.
14. AI integration handles failures.
15. Historical backtesting works.
16. Reports export correctly.
17. Audit logs persist.
18. Mobile layout works.
19. No critical security defects remain.
20. Documentation is complete.

Maintain a feature checklist with:

- NOT STARTED
- IN PROGRESS
- IMPLEMENTED
- TESTED
- VERIFIED
- BLOCKED

Never label a feature VERIFIED without evidence.

---

30. FINAL EXECUTION INSTRUCTIONS

Start by inspecting the development environment and available resources.

Then:

1. Create the architecture.
2. Create the repository.
3. Implement the foundation.
4. Build the database.
5. Build the frontend design system.
6. Implement the backend APIs.
7. Integrate market data.
8. Implement the strategy research engine.
9. Implement the independent risk supervisor.
10. Implement demo execution.
11. Integrate Google Gemini AI.
12. Implement analytics and backtesting.
13. Implement monitoring.
14. Run all tests.
15. Fix detected errors.
16. Verify mobile responsiveness.
17. Produce complete documentation.

Do not attempt to generate the entire application as one unverified code dump.

Maintain working software at every phase.

After each phase, report:

- What was implemented.
- Which files changed.
- Which tests passed.
- Which tests failed.
- What remains.
- Any external configuration required.

If an API key, account, or service is unavailable, build the integration interface and report the exact missing configuration. Never invent successful connections.

FINAL DELIVERABLE:

NEXUS QUANT AI — A complete, modular, enterprise-grade quantitative trading intelligence platform with real market data, AI-powered analysis, Avellaneda–Stoikov research, independent risk supervision, demo and paper execution, portfolio analytics, backtesting, security, monitoring, and responsive professional dashboards.

The result must be functional software, not a mockup.

Start fresh from this prompt

Builds a brand new app from the first prompt only, so later changes to the original are not included.