vasily/TCPDashboard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

init

Browse Source
This commit is contained in:
Ajasra 2025-05-29 23:04:08 +08:00
parent 2c63537a69
commit d90681b788
9 changed files with 559 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
.cursor/rules/create-prd.mdc Normal file
View File

@ -0,0 +1,67 @@
---
description:
globs:
alwaysApply: false
---
---
description:
globs:
alwaysApply: false
---
# Rule: Generating a Product Requirements Document (PRD)
## Goal
To guide an AI assistant in creating a detailed Product Requirements Document (PRD) in Markdown format, based on an initial user prompt. The PRD should be clear, actionable, and suitable for a junior developer to understand and implement the feature.
## Process
1. **Receive Initial Prompt:** The user provides a brief description or request for a new feature or functionality.
2. **Ask Clarifying Questions:** Before writing the PRD, the AI *must* ask clarifying questions to gather sufficient detail. The goal is to understand the "what" and "why" of the feature, not necessarily the "how" (which the developer will figure out).
3. **Generate PRD:** Based on the initial prompt and the user's answers to the clarifying questions, generate a PRD using the structure outlined below.
4. **Save PRD:** Save the generated document as `prd-[feature-name].md` inside the `/tasks` directory.
## Clarifying Questions (Examples)
The AI should adapt its questions based on the prompt, but here are some common areas to explore:
* **Problem/Goal:** "What problem does this feature solve for the user?" or "What is the main goal we want to achieve with this feature?"
* **Target User:** "Who is the primary user of this feature?"
* **Core Functionality:** "Can you describe the key actions a user should be able to perform with this feature?"
* **User Stories:** "Could you provide a few user stories? (e.g., As a [type of user], I want to [perform an action] so that [benefit].)"
* **Acceptance Criteria:** "How will we know when this feature is successfully implemented? What are the key success criteria?"
* **Scope/Boundaries:** "Are there any specific things this feature *should not* do (non-goals)?"
* **Data Requirements:** "What kind of data does this feature need to display or manipulate?"
* **Design/UI:** "Are there any existing design mockups or UI guidelines to follow?" or "Can you describe the desired look and feel?"
* **Edge Cases:** "Are there any potential edge cases or error conditions we should consider?"
## PRD Structure
The generated PRD should include the following sections:
1. **Introduction/Overview:** Briefly describe the feature and the problem it solves. State the goal.
2. **Goals:** List the specific, measurable objectives for this feature.
3. **User Stories:** Detail the user narratives describing feature usage and benefits.
4. **Functional Requirements:** List the specific functionalities the feature must have. Use clear, concise language (e.g., "The system must allow users to upload a profile picture."). Number these requirements.
5. **Non-Goals (Out of Scope):** Clearly state what this feature will *not* include to manage scope.
6. **Design Considerations (Optional):** Link to mockups, describe UI/UX requirements, or mention relevant components/styles if applicable.
7. **Technical Considerations (Optional):** Mention any known technical constraints, dependencies, or suggestions (e.g., "Should integrate with the existing Auth module").
8. **Success Metrics:** How will the success of this feature be measured? (e.g., "Increase user engagement by 10%", "Reduce support tickets related to X").
9. **Open Questions:** List any remaining questions or areas needing further clarification.
## Target Audience
Assume the primary reader of the PRD is a **junior developer**. Therefore, requirements should be explicit, unambiguous, and avoid jargon where possible. Provide enough detail for them to understand the feature's purpose and core logic.
## Output
* **Format:** Markdown (`.md`)
* **Location:** `/tasks/`
* **Filename:** `prd-[feature-name].md`
## Final instructions
1. Do NOT start implmenting the PRD
2. Make sure to ask the user clarifying questions
3. Take the user's answers to the clarifying questions and improve the PRD

70
.cursor/rules/generate-tasks.mdc Normal file
View File

@ -0,0 +1,70 @@
---
description:
globs:
alwaysApply: false
---
---
description:
globs:
alwaysApply: false
---
# Rule: Generating a Task List from a PRD
## Goal
To guide an AI assistant in creating a detailed, step-by-step task list in Markdown format based on an existing Product Requirements Document (PRD). The task list should guide a developer through implementation.
## Output
- **Format:** Markdown (`.md`)
- **Location:** `/tasks/`
- **Filename:** `tasks-[prd-file-name].md` (e.g., `tasks-prd-user-profile-editing.md`)
## Process
1. **Receive PRD Reference:** The user points the AI to a specific PRD file
2. **Analyze PRD:** The AI reads and analyzes the functional requirements, user stories, and other sections of the specified PRD.
3. **Phase 1: Generate Parent Tasks:** Based on the PRD analysis, create the file and generate the main, high-level tasks required to implement the feature. Use your judgement on how many high-level tasks to use. It's likely to be about 5. Present these tasks to the user in the specified format (without sub-tasks yet). Inform the user: "I have generated the high-level tasks based on the PRD. Ready to generate the sub-tasks? Respond with 'Go' to proceed."
4. **Wait for Confirmation:** Pause and wait for the user to respond with "Go".
5. **Phase 2: Generate Sub-Tasks:** Once the user confirms, break down each parent task into smaller, actionable sub-tasks necessary to complete the parent task. Ensure sub-tasks logically follow from the parent task and cover the implementation details implied by the PRD.
6. **Identify Relevant Files:** Based on the tasks and PRD, identify potential files that will need to be created or modified. List these under the `Relevant Files` section, including corresponding test files if applicable.
7. **Generate Final Output:** Combine the parent tasks, sub-tasks, relevant files, and notes into the final Markdown structure.
8. **Save Task List:** Save the generated document in the `/tasks/` directory with the filename `tasks-[prd-file-name].md`, where `[prd-file-name]` matches the base name of the input PRD file (e.g., if the input was `prd-user-profile-editing.md`, the output is `tasks-prd-user-profile-editing.md`).
## Output Format
The generated task list _must_ follow this structure:
```markdown
## Relevant Files
- `path/to/potential/file1.ts` - Brief description of why this file is relevant (e.g., Contains the main component for this feature).
- `path/to/file1.test.ts` - Unit tests for `file1.ts`.
- `path/to/another/file.tsx` - Brief description (e.g., API route handler for data submission).
- `path/to/another/file.test.tsx` - Unit tests for `another/file.tsx`.
- `lib/utils/helpers.ts` - Brief description (e.g., Utility functions needed for calculations).
- `lib/utils/helpers.test.ts` - Unit tests for `helpers.ts`.
### Notes
- Unit tests should typically be placed alongside the code files they are testing (e.g., `MyComponent.tsx` and `MyComponent.test.tsx` in the same directory).
- Use `npx jest [optional/path/to/test/file]` to run tests. Running without a path executes all tests found by the Jest configuration.
## Tasks
- [ ] 1.0 Parent Task Title
- [ ] 1.1 [Sub-task description 1.1]
- [ ] 1.2 [Sub-task description 1.2]
- [ ] 2.0 Parent Task Title
- [ ] 2.1 [Sub-task description 2.1]
- [ ] 3.0 Parent Task Title (may not require sub-tasks if purely structural or configuration)
```
## Interaction Model
The process explicitly requires a pause after generating parent tasks to get user confirmation ("Go") before proceeding to generate the detailed sub-tasks. This ensures the high-level plan aligns with user expectations before diving into details.
## Target Audience
Assume the primary reader of the task list is a **junior developer** who will implement the feature.

8
.cursor/rules/project.mdc Normal file
View File

@ -0,0 +1,8 @@
---
description:
globs:
alwaysApply: true
---
- use UV for package management
- ./docs folder for the documetation and the modules description, update related files if logic changed

44
.cursor/rules/task-list.mdc Normal file
View File

@ -0,0 +1,44 @@
---
description:
globs:
alwaysApply: false
---
---
description:
globs:
alwaysApply: false
---
# Task List Management
Guidelines for managing task lists in markdown files to track progress on completing a PRD
## Task Implementation
- **One sub-task at a time:** Do **NOT** start the next sub‑task until you ask the user for permission and they say “yes” or "y"
- **Completion protocol:**
1. When you finish a **sub‑task**, immediately mark it as completed by changing `[ ]` to `[x]`.
2. If **all** subtasks underneath a parent task are now `[x]`, also mark the **parent task** as completed.
- Stop after each sub‑task and wait for the user’s go‑ahead.
## Task List Maintenance
1. **Update the task list as you work:**
- Mark tasks and subtasks as completed (`[x]`) per the protocol above.
- Add new tasks as they emerge.
2. **Maintain the “Relevant Files” section:**
- List every file created or modified.
- Give each file a one‑line description of its purpose.
## AI Instructions
When working with task lists, the AI must:
1. Regularly update the task list file after finishing any significant work.
2. Follow the completion protocol:
- Mark each finished **sub‑task** `[x]`.
- Mark the **parent task** `[x]` once **all** its subtasks are `[x]`.
3. Add newly discovered tasks.
4. Keep “Relevant Files” accurate and up to date.
5. Before starting work, check which sub‑task is next.
6. After implementing a sub‑task, update the file and then pause for user approval.

120
README.md
View File

@ -0,0 +1,120 @@
# Crypto Trading Bot Dashboard
A simple control dashboard for managing and monitoring multiple cryptocurrency trading bots simultaneously. Test different trading strategies in parallel using real OKX market data and virtual trading simulation.
## Features
- **Multi-Bot Management**: Run up to 5 trading bots simultaneously with different strategies
- **Real-time Monitoring**: Live price charts with bot buy/sell decision markers
- **Performance Tracking**: Monitor virtual balance, P&L, trade count, and timing for each bot
- **Backtesting**: Test strategies on historical data with accelerated execution
- **Simple Configuration**: JSON-based bot configuration files
- **Hot Reloading**: System remembers active bots and restores state on restart
## Tech Stack
- **Backend**: Python with existing OKX, strategy, and trader modules
- **Frontend**: Plotly Dash for rapid development
- **Database**: PostgreSQL with SQLAlchemy ORM
- **Package Management**: UV
- **Development**: Docker for consistent environment
## Quick Start
### Prerequisites
- Python 3.10+
- Docker and Docker Compose
- UV package manager
### Development Setup
1. **Clone the repository**
```bash
git clone <repository-url>
cd Dashboard
```
2. **Install dependencies**
```bash
uv sync
```
3. **Start development environment**
```bash
docker-compose up -d # Start PostgreSQL
```
4. **Run the application**
```bash
uv run python main.py
```
5. **Access the dashboard**
Open your browser to `http://localhost:8050`
## Project Structure
```
Dashboard/
├── app.py # Main Dash application
├── bot_manager.py # Bot lifecycle management
├── database/
│ ├── models.py # SQLAlchemy models
│ └── connection.py # Database connection
├── data/
│ └── okx_integration.py # OKX API integration
├── components/
│ ├── dashboard.py # Dashboard components
│ └── charts.py # Chart components
├── backtesting/
│ └── engine.py # Backtesting framework
├── config/
│ └── bot_configs/ # Bot configuration files
├── strategies/ # Trading strategy modules
├── trader/ # Virtual trading logic
└── docs/ # Project documentation
```
## Documentation
- **[Product Requirements](tasks/prd-crypto-bot-dashboard.md)** - Detailed project requirements and specifications
- **[Implementation Tasks](tasks/tasks-prd-crypto-bot-dashboard.md)** - Step-by-step development task list
- **[API Documentation](docs/)** - Module and API documentation
## Bot Configuration
Create bot configuration files in `config/bot_configs/`:
```json
{
"bot_id": "ema_crossover_01",
"strategy": "EMA_Crossover",
"parameters": {
"fast_period": 12,
"slow_period": 26,
"symbol": "BTC-USDT"
},
"virtual_balance": 10000
}
```
## Development Status
This project is in active development. See the [task list](tasks/tasks-prd-crypto-bot-dashboard.md) for current implementation progress.
### Current Phase: Setup and Infrastructure
- [ ] Development environment setup
- [ ] Database schema design
- [ ] Basic bot management system
- [ ] OKX integration
- [ ] Dashboard UI implementation
- [ ] Backtesting framework
## Contributing
1. Check the [task list](tasks/tasks-prd-crypto-bot-dashboard.md) for available tasks
2. Follow the project's coding standards and architectural patterns
3. Use UV for package management
4. Write tests for new functionality
5. Update documentation when adding features

6
main.py Normal file
View File

@ -0,0 +1,6 @@
def main():
print("Hello from dashboard!")
if __name__ == "__main__":
main()

7
pyproject.toml Normal file
View File

@ -0,0 +1,7 @@
[project]
name = "dashboard"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.10"
dependencies = []

159
tasks/prd-crypto-bot-dashboard.md Normal file
View File

@ -0,0 +1,159 @@
# Product Requirements Document: Crypto Trading Bot Dashboard
## Introduction/Overview
Create a simple control dashboard for managing and monitoring multiple cryptocurrency trading bots simultaneously. The system will allow testing different strategies in parallel using real OKX market data and virtual trading simulation. The focus is on rapid implementation to enable strategy testing within days rather than weeks.
**Core Problem**: Currently, testing multiple trading strategies requires manual coordination and lacks real-time monitoring capabilities. There's no unified way to compare strategy performance or manage multiple bots running simultaneously.
## Goals
1. **Enable Parallel Strategy Testing**: Run up to 5 different trading bots simultaneously with different strategies
2. **Real-time Monitoring**: Visualize bot performance, trading decisions, and market data in real-time
3. **Quick Strategy Validation**: Reduce the time from strategy implementation to performance assessment
4. **Historical Analysis**: Enable backtesting with previously collected market data
5. **Operational Control**: Simple start/stop functionality for individual bots
## User Stories
1. **As a strategy developer**, I want to start multiple bots with different strategies so that I can compare their performance over the same time period.
2. **As a trader**, I want to see real-time price charts and bot decisions so that I can understand how my strategies are performing.
3. **As an analyst**, I want to view historical performance metrics so that I can evaluate strategy effectiveness over different market conditions.
4. **As a system operator**, I want to stop underperforming bots so that I can prevent further virtual losses.
5. **As a researcher**, I want to run backtests on historical data so that I can validate strategies before live testing.
## Functional Requirements
### Core Bot Management
1. **Bot Lifecycle Control**: System must allow starting and stopping individual bots via web interface
2. **Multi-Bot Support**: System must support running up to 5 bots simultaneously
3. **Bot Configuration**: System must read bot configurations from JSON/YAML files in a configs directory
4. **Status Monitoring**: System must display current status (running/stopped) for each configured bot
### Data Management
5. **Market Data Integration**: System must connect to existing OKX data feed and display real-time price information
6. **Trading Decision Storage**: System must record all bot trading decisions (buy/sell signals, amounts, timestamps) to database
7. **Performance Tracking**: System must calculate and store key metrics (balance, profit/loss, number of trades) for each bot
8. **Data Persistence**: System must use SQLite for simplicity with separate tables for market data and bot decisions
### User Interface
9. **Dashboard Layout**: System must provide a single-page dashboard showing all bot information
10. **Price Visualization**: System must display candlestick charts with bot buy/sell markers overlaid
11. **Bot Switching**: System must allow switching chart view between different active bots
12. **Performance Metrics**: System must show current balance, total profit/loss, and trade count for each bot and trade time
13. **Real-time Updates**: System must refresh data every 2 seconds minimum
### Backtesting
14. **Historical Mode**: System must allow running bots against historical market data
15. **Time Range Selection**: System must provide date range picker for backtest periods
16. **Accelerated Testing**: System must support running backtests faster than real-time
## Non-Goals (Out of Scope)
- **Multi-exchange Support**: Only OKX integration for MVP
- **Real Money Trading**: Virtual trading simulation only
- **Advanced UI/UX**: Basic functional interface, not polished design
- **User Authentication**: Single-user system for MVP
- **Strategy Editor**: Strategy creation/editing via code only, not UI
- **Advanced Analytics**: Complex statistical analysis beyond basic P&L
- **Mobile Interface**: Desktop web interface only
- **High-frequency Trading**: Strategies with sub-second requirements not supported
## Technical Considerations
### Technology Stack
- **Backend**: Python with existing OKX, strategy, and trader modules
- **Frontend**: Plotly Dash for rapid development and Python integration
- **Database**: PostgreSQL, SQLAlchemy
- **Communication**: Direct database polling (no WebSockets for MVP)
### Architecture Simplicity
- **Monolithic Design**: Single Python application with all components
- **File-based Configuration**: JSON files for bot settings
- **Polling Updates**: 2-second refresh cycle acceptable for MVP
- **Process Management**: Simple threading or multiprocessing for bot execution
### Integration Requirements
- **Existing Module Refactoring**: May need to modify current strategy and trader modules for unified signal processing
- **Database Schema**: Design simple schema for bot decisions and performance metrics
- **Error Handling**: Basic error logging and bot restart capabilities
## Success Metrics
1. **Functionality**: Successfully run 3+ bots simultaneously for 24+ hours without crashes
2. **Data Completeness**: Capture 100% of trading decisions and market data during bot operation
3. **Performance Visibility**: Display real-time bot performance with <5 second update latency
4. **Backtesting Capability**: Run historical tests covering 1+ weeks of data in <10 minutes
5. **Operational Control**: Start/stop bots with <10 second response time
## Design Considerations
### Dashboard Layout
```
+------------------+-------------------+
| Bot Controls | Active Charts |
| [Bot1] [Start] | |
| [Bot2] [Stop] | Price/Strategy |
| [Bot3] [Start] | Chart |
+------------------+-------------------+
| Performance Metrics |
| Bot1: +$50 Bot2: -$20 Bot3: +$35 |
+--------------------------------------+
```
### Configuration Example
```json
{
"bot_id": "ema_crossover_01",
"strategy": "EMA_Crossover",
"parameters": {
"fast_period": 12,
"slow_period": 26,
"symbol": "BTC-USDT"
},
"virtual_balance": 10000
}
```
## Implementation Phases
### Phase 1 (Week 1-2): Core Infrastructure
- Set up basic Dash application
- Integrate existing OKX data feed
- Create bot manager for start/stop functionality
- Basic database schema for trading decisions
### Phase 2 (Week 3): Visualization
- Implement price charts with Plotly
- Add bot decision overlays
- Create performance metrics dashboard
- Bot switching functionality
### Phase 3 (Week 4): Testing & Refinement
- Add backtesting capability
- Implement error handling and logging
- Performance optimization
- User acceptance testing
## Open Questions
1. **Strategy Module Integration**: What modifications are needed to current strategy modules for unified signal processing?
2. **Database Migration**: Start with PostgreSQL
3. **Bot Resource Management**: How should we handle memory/CPU limits for individual bots?
4. **Configuration Management**: Bot can have hot reloading (we can save current active, paused bots so on start it restore last state.)
5. **Error Recovery**: On bot crash system should restart it if it is active.
## Acceptance Criteria
- [ ] Start 5 different bots simultaneously via web interface
- [ ] View real-time price charts with buy/sell decision markers
- [ ] Switch between different bot views in the dashboard
- [ ] See current virtual balance and P&L for each bot
- [ ] Stop/start individual bots without affecting others
- [ ] Run backtest on 1 week of historical data
- [ ] System operates continuously for 48+ hours without manual intervention
- [ ] All trading decisions logged to database with timestamps

78
tasks/tasks-prd-crypto-bot-dashboard.md Normal file
View File

@ -0,0 +1,78 @@
## Relevant Files
- `app.py` - Main Dash application entry point and layout definition
- `bot_manager.py` - Core bot lifecycle management and orchestration
- `database/models.py` - SQLAlchemy models for bots, trades, and market data
- `database/connection.py` - Database connection and session management
- `data/okx_integration.py` - OKX API connection and real-time data feed
- `strategies/` - Directory containing strategy modules (existing, may need refactoring)
- `trader/` - Directory containing virtual trading logic (existing, may need refactoring)
- `components/dashboard.py` - Dash dashboard components and layout
- `components/charts.py` - Plotly chart components for price and performance visualization
- `backtesting/engine.py` - Backtesting execution engine
- `config/bot_configs/` - Directory for JSON bot configuration files
- `utils/logging.py` - Logging configuration and utilities
- `requirements.txt` - Python dependencies using UV package manager
### Notes
- Use docker for development and database
- Use UV for package management as specified in project requirements
- PostgreSQL with SQLAlchemy for database persistence
- Plotly Dash for rapid UI development
- Bot configurations stored as JSON files in config directory
- System should support hot-reloading of bot states
## Tasks
- [ ] 0.0 Dev environment and Docker setup
- [ ] 0.1 Create Docker Compose file with PostgreSQL service
- [ ] 0.2 Set up UV package management with pyproject.toml dependencies
- [ ] 0.3 Create .env file template for database and API configuration
- [ ] 0.4 Add development scripts for starting/stopping services
- [ ] 0.5 Test database connection and basic container orchestration
- [ ] 1.0 Database Infrastructure Setup
- [ ] 1.1 Design PostgreSQL schema for bots, trades, market_data, and bot_states tables
- [ ] 1.2 Create SQLAlchemy models in `database/models.py` for all entities
- [ ] 1.3 Implement database connection management in `database/connection.py`
- [ ] 1.4 Create Alembic migration scripts for initial schema
- [ ] 1.5 Add database utility functions for common queries
- [ ] 1.6 Implement bot state persistence for hot-reloading capability
- [ ] 2.0 Bot Management System Development
- [ ] 2.1 Create `bot_manager.py` with BotManager class for lifecycle control
- [ ] 2.2 Implement bot configuration loading from JSON files in `config/bot_configs/`
- [ ] 2.3 Add start/stop functionality for individual bots using threading/multiprocessing
- [ ] 2.4 Create bot status tracking and monitoring system
- [ ] 2.5 Implement error handling and automatic bot restart on crash
- [ ] 2.6 Add bot state persistence to database for system restart recovery
- [ ] 2.7 Create unified signal processing interface for strategy integration
- [ ] 3.0 OKX Integration and Data Pipeline
- [ ] 3.1 Create `data/okx_integration.py` with OKX API client
- [ ] 3.2 Implement real-time WebSocket connection for market data
- [ ] 3.3 Add market data normalization and validation
- [ ] 3.4 Create data storage pipeline to PostgreSQL with proper indexing
- [ ] 3.5 Implement data feed monitoring and reconnection logic
- [ ] 3.6 Add historical data retrieval for backtesting
- [ ] 3.7 Test data pipeline with multiple cryptocurrency pairs
- [ ] 4.0 Dashboard UI and Visualization
- [ ] 4.1 Set up basic Dash application structure in `app.py`
- [ ] 4.2 Create dashboard layout with bot controls and chart areas
- [ ] 4.3 Implement bot control panel in `components/dashboard.py`
- [ ] 4.4 Build candlestick charts with buy/sell markers in `components/charts.py`
- [ ] 4.5 Add performance metrics display for each bot (balance, P&L, trade count, trade time)
- [ ] 4.6 Implement bot switching functionality for chart views
- [ ] 4.7 Add real-time data updates with 2-second refresh cycle
- [ ] 4.8 Create responsive layout that works on different screen sizes
- [ ] 5.0 Backtesting System Implementation
- [ ] 5.1 Create `backtesting/engine.py` with backtesting framework
- [ ] 5.2 Implement historical data loading and time range selection
- [ ] 5.3 Add accelerated testing capability (faster than real-time)
- [ ] 5.4 Create backtesting results storage and comparison system
- [ ] 5.5 Integrate backtesting with dashboard for result visualization
- [ ] 5.6 Add date range picker component for backtest periods
- [ ] 5.7 Test backtesting with sample strategies on 1+ week datasets