feat: 重构项目心跳数据结构并实现项目列表API

- 新增统一项目列表Redis键和迁移工具
- 实现GET /api/projects端点获取项目列表
- 实现POST /api/projects/migrate端点支持数据迁移
- 更新前端ProjectSelector组件使用真实项目数据
- 扩展projectStore状态管理
- 更新相关文档和OpenSpec规范
- 添加测试用例验证新功能

openspec/specs/logging/design.md

@@ -1,11 +1,13 @@
 # Logging Capability Design
 
 ## Context
+
 This design document describes the technical implementation of the logging capability for the BLS Project Console, which allows the system to read log records from Redis queues and display them in the console interface.
 
 ## Goals / Non-Goals
 
 ### Goals
+
 - Implement real-time log reading from Redis queues
 - Provide a user-friendly log display interface
 - Support log filtering by level and time range
@@ -13,6 +15,7 @@ This design document describes the technical implementation of the logging capab
 - Implement proper error handling and reconnection mechanisms
 
 ### Non-Goals
+
 - Log storage or persistence beyond memory
 - Log analysis or visualization (charts, graphs)
 - Advanced log search capabilities
@@ -20,29 +23,33 @@ This design document describes the technical implementation of the logging capab
 ## Decisions
 
 ### Decision: Redis Queue Implementation
+
 - **What**: Use Redis List as the queue data structure
 - **Why**: Redis Lists provide efficient push/pop operations with O(1) time complexity, making them ideal for message queues
-- **Alternatives considered**: 
+- **Alternatives considered**:
   - Redis Streams: More advanced but overkill for our use case
   - Redis Pub/Sub: No persistence, so logs would be lost if the server is down
 
 ### Decision: Real-time Updates
+
 - **What**: Use Server-Sent Events (SSE) for real-time log updates
 - **Why**: SSE is simpler than WebSockets for one-way communication, has better browser support, and is easier to implement
-- **Alternatives considered**: 
+- **Alternatives considered**:
   - WebSockets: More complex for one-way communication
   - Polling: Higher latency and more resource-intensive
 
 ### Decision: Log Storage
+
 - **What**: Store logs in memory with a configurable maximum size
 - **Why**: In-memory storage provides fast access times and avoids the complexity of database management
-- **Alternatives considered**: 
+- **Alternatives considered**:
   - Database storage: Adds complexity and latency
   - File system: Not suitable for real-time access
 
 ## Architecture
 
 ### Frontend Architecture
+
 ```
 LogView Component
 ├── LogList Component
@@ -51,6 +58,7 @@ LogView Component
 ```
 
 ### Backend Architecture
+
 ```
 Log Routes
 ├── Log Service
@@ -62,28 +70,33 @@ Log Routes
 ## Implementation Details
 
 ### Redis Connection
+
 - Use the `redis` npm package to connect to Redis
 - Implement automatic reconnection with exponential backoff
 - Handle connection errors gracefully
 
 ### Log Reading
+
 1. Server establishes connection to Redis
 2. Server listens for new log records using `BLPOP` command (blocking pop)
 3. When a log record is received, it's added to the in-memory log store
 4. The log is then sent to all connected SSE clients
 
 ### Log Storage
+
 - Use an array to store log records in memory
 - Implement a circular buffer to limit memory usage
 - Default maximum log count: 10,000
 - Configurable via environment variable
 
 ### Log Display
+
 - Use a scrollable list to display logs
 - Implement virtual scrolling for large log sets to improve performance
 - Color-code logs by level (INFO: gray, WARN: yellow, ERROR: red, DEBUG: blue)
 
 ### Log Filtering
+
 - Implement client-side filtering for performance
 - Allow filtering by log level (INFO, WARN, ERROR, DEBUG)
 - Allow filtering by time range using a date picker
@@ -91,21 +104,26 @@ Log Routes
 ## Risks / Trade-offs
 
 ### Risk: Redis Connection Failure
+
 - **Risk**: If Redis connection is lost, logs won't be received
 - **Mitigation**: Implement automatic reconnection with exponential backoff, and notify users when connection is lost
 
 ### Risk: High Log Volume
+
 - **Risk**: Large number of logs could cause performance issues
 - **Mitigation**: Implement a circular buffer to limit memory usage, and use virtual scrolling in the frontend
 
 ### Risk: Browser Performance
+
 - **Risk**: Displaying thousands of logs could slow down the browser
 - **Mitigation**: Use virtual scrolling and limit the number of logs displayed at once
 
 ## Migration Plan
+
 No migration is required as this is a new feature.
 
 ## Open Questions
+
 - What is the expected maximum log volume per minute?
 - Should we add support for log persistence to disk?
-- Should we implement log search functionality?
+- Should we implement log search functionality?

openspec/specs/logging/spec.md

@@ -1,43 +1,53 @@
 # Logging Capability Specification
 
 ## Overview
+
 This specification defines the logging capability for the BLS Project Console, which allows the system to read log records from Redis queues and display them in the console interface.
 
 ## Requirements
 
 ### Requirement: Log Reading from Redis
+
 The system SHALL read log records from a Redis queue.
 
 #### Scenario: Reading logs from Redis queue
+
 - **WHEN** the server starts
 - **THEN** it SHALL establish a connection to the Redis queue
 - **AND** it SHALL begin listening for new log records
 - **AND** it SHALL store log records in memory for display
 
 ### Requirement: Log Display in Console
+
 The system SHALL display log records in a user-friendly format.
 
 #### Scenario: Displaying logs in the console
+
 - **WHEN** a log record is received from Redis
 - **THEN** it SHALL be added to the log list in the console
 - **AND** it SHALL display the log timestamp, level, and message
 - **AND** it SHALL support scrolling through historical logs
 
 ### Requirement: Log Filtering
+
 The system SHALL allow users to filter logs by level and time range.
 
 #### Scenario: Filtering logs by level
+
 - **WHEN** the user selects a log level filter
 - **THEN** only logs with the selected level SHALL be displayed
 
 #### Scenario: Filtering logs by time range
+
 - **WHEN** the user selects a time range
 - **THEN** only logs within the specified range SHALL be displayed
 
 ### Requirement: Log Auto-Refresh
+
 The system SHALL automatically refresh logs in real-time.
 
 #### Scenario: Real-time log updates
+
 - **WHEN** a new log is added to the Redis queue
 - **THEN** it SHALL be automatically displayed in the console
 - **AND** the console SHALL scroll to the latest log if the user is viewing the end
@@ -45,6 +55,7 @@ The system SHALL automatically refresh logs in real-time.
 ## Data Model
 
 ### Log Record
+
 ```json
 {
   "id": "string",
@@ -58,14 +69,34 @@ The system SHALL automatically refresh logs in real-time.
 ## API Endpoints
 
 ### GET /api/logs
-- **Description**: Get log records
+
+- **Description**: Get log records for a specific project
 - **Query Parameters**:
-  - `level`: Filter logs by level
-  - `startTime`: Filter logs from this timestamp
-  - `endTime`: Filter logs up to this timestamp
-  - `limit`: Maximum number of logs to return
-- **Response**: Array of log records
+  - `projectName`: Project name (required)
+  - `limit`: Maximum number of logs to return (default: 200)
+- **Response**:
+  ```json
+  {
+    "logs": [
+      {
+        "id": "string",
+        "timestamp": "ISO-8601 string",
+        "level": "string",
+        "message": "string",
+        "metadata": "object"
+      }
+    ],
+    "projectStatus": "在线|离线|null",
+    "heartbeat": {
+      "apiBaseUrl": "string",
+      "lastActiveAt": "number",
+      "isOnline": "boolean",
+      "ageMs": "number"
+    }
+  }
+  ```
 
 ### GET /api/logs/live
+
 - **Description**: Establish a WebSocket connection for real-time log updates
 - **Response**: Continuous stream of log records