Dev

.github/chatmodes/Architecture.chatmode.md

@@ -0,0 +1,5 @@
+---
+description: 'Architecture'
+tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'readCellOutput', 'runCommands', 'runNotebooks', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'sequential-thinking', 'context7', 'mcp-feedback-enhanced', 'websearch']
+---
+You are Copilot, an accomplished technical leader celebrated for your relentless curiosity, visionary strategic thinking, and masterful planning abilities. You consistently pursue groundbreaking solutions, foresee and mitigate potential obstacles, and empower teams with clear, insightful guidance and unwavering precision.

.github/chatmodes/Debug.chatmode.md

@@ -0,0 +1,5 @@
+---
+description: 'Debug'
+tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'readCellOutput', 'runCommands', 'runNotebooks', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'sequential-thinking',  'context7', 'mcp-feedback-enhanced', 'deepwiki', 'configurePythonEnvironment', 'getPythonEnvironmentInfo', 'getPythonExecutableCommand', 'installPythonPackage', 'websearch']
+---
+You are Copilot, an expert software debugger renowned for your methodical approach to diagnosing, analyzing, and resolving complex code issues with precision and clarity.

.github/copilot-instructions.md

@@ -0,0 +1,138 @@
+# Lithium Next - AI Agent Instructions
+
+## Project Overview
+Lithium-Next is a modular C++20 astrophotography control software with a task-based architecture. It provides comprehensive control over astronomical devices (cameras, telescopes, focusers, etc.) through multiple backends (Mock, INDI, ASCOM, Native) and features an intelligent task sequencing system.
+
+## Architecture
+
+### Core Components
+- **Device System**: Unified interface for controlling astronomical devices
+- **Task System**: Flexible system for creating and executing astronomical workflows
+- **Sequencer**: Manages and executes tasks in sequence with dependencies
+- **Config System**: Handles serialization/deserialization of configurations and sequences
+
+### Key Directories
+- `/src/device/`: Device control implementations (camera, telescope, etc.)
+- `/src/task/`: Task system and implementations
+- `/libs/atom/`: Core utility library
+- `/modules/`: Self-contained feature modules
+- `/example/`: Usage examples
+
+## Development Guidelines
+
+### Build System
+```bash
+# Standard build
+mkdir build && cd build
+cmake ..
+make
+
+# Optimized build with Clang
+mkdir build-clang && cd build-clang
+cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release ..
+make
+```
+
+### Device System Patterns
+1. Use the `DeviceFactory` to create device instances:
+   ```cpp
+   auto factory = DeviceFactory::getInstance();
+   auto camera = factory.createCamera("MainCamera", DeviceBackend::MOCK);
+   ```
+
+2. Device lifecycle pattern:
+   ```cpp
+   device->initialize();  // Initialize driver/backend
+   device->connect();     // Connect to physical device
+   // Use device...
+   device->disconnect();  // Close connection
+   device->destroy();     // Clean up resources
+   ```
+
+### Task System Patterns
+1. Create and configure a sequence:
+   ```cpp
+   ExposureSequence sequence;
+
+   // Set callbacks
+   sequence.setOnSequenceStart([]() { /* ... */ });
+   sequence.setOnTargetEnd([](const std::string& name, TargetStatus status) { /* ... */ });
+   ```
+
+2. Create targets and tasks:
+   ```cpp
+   auto target = std::make_unique<Target>("MainTarget", std::chrono::seconds(5), 3);
+
+   // Create and add task
+   auto task = std::make_unique<Task>("CustomTask", [](const json& params) {
+       // Task implementation
+   });
+   target->addTask(std::move(task));
+
+   // Add target to sequence
+   sequence.addTarget(std::move(target));
+   ```
+
+3. Execute sequence:
+   ```cpp
+   sequence.executeAll();
+   ```
+
+### C++20 Features
+- Use concepts for type constraints
+- Use std::filesystem for file operations
+- Use std::format for string formatting
+- Prefer std::span over pointer+size
+- Use std::jthread for automatically joining threads
+
+## Testing
+- Unit tests are in `/tests/`
+- Example code in `/example/` demonstrates intended usage patterns
+- Use mock devices for testing without hardware
+
+## Document Search
+When searching for documentation related to cpp, spldog, curl, tinyxml2, nlohmann/json, etc., always use Context7 to obtain the latest version-specific documentation. When searching for xxx documentation, **search for the stable version of xxx documentation**. In your query, explicitly include `use context7` and specify the need for the stable version of xxx documentation. For example: use context7 to search for the latest version of C++ documentation on vectors.
+
+## Project-Specific Conventions
+
+### Error Handling
+- Use structured exceptions from `exception/` for domain-specific errors
+- Return false/nullptr for failures in device operations, don't throw
+- Use std::optional for operations that might not return a value
+
+### Memory Management
+- Use smart pointers (std::shared_ptr, std::unique_ptr) for ownership
+- Avoid raw pointers except for non-owning references
+- Use RAII for resource management
+
+### Task Implementation Pattern
+```cpp
+class CustomTask : public Task {
+public:
+    static auto taskName() -> std::string { return "CustomTask"; }
+
+    void execute(const json& params) override {
+        // Extract parameters with validation
+        double exposure = params.value("exposure", 1.0);
+
+        // Implement task logic
+        // ...
+
+        // Signal completion
+        notifyCompletion(true);
+    }
+};
+```
+
+### Integration Points
+- Device drivers implement interfaces from `/libs/atom/device/`
+- Task implementations extend the Task class
+- Sequence serialization uses the ConfigSerializer
+
+## MCP Interactive Feedback Rules
+
+1. During any process, task, or conversation, whether asking, responding, or completing stage tasks, must call MCP mcp-feedback-enhanced.
+2. When receiving user feedback, if feedback content is not empty, must call MCP mcp-feedback-enhanced again and adjust behavior based on feedback.
+3. Only when user explicitly indicates "end" or "no more interaction needed" can you stop calling MCP mcp-feedback-enhanced, then the process is complete.
+4. Unless receiving end command, all steps must repeatedly call MCP mcp-feedback-enhanced.
+5. Before completing the task, use the MCP mcp-feedback-enhanced to ask the user for feedback.

.github/prompts/CleanCode.prompt.md

@@ -0,0 +1,4 @@
+---
+mode: ask
+---
+Refactor the code to improve its organization, eliminate duplicate sections, and enhance readability. Ensure the codebase follows best practices for maintainability, including clear structure, consistent formatting, and comprehensive documentation.

.github/prompts/ImproveCPP.prompt.md

@@ -0,0 +1,4 @@
+---
+mode: ask
+---
+Utilize cutting-edge C++ standards to achieve peak performance by implementing advanced concurrency primitives, lock-free and high-efficiency synchronization mechanisms, and state-of-the-art data structures, ensuring robust thread safety, minimal contention, and seamless scalability across multicore architectures. Note that the logs should use spdlog, all output and comments should be in English, and there should be no redundant comments other than doxygen comments

.github/prompts/ImprovePython.prompt.md

@@ -0,0 +1,4 @@
+---
+mode: ask
+---
+Refactor the current Python code to leverage the latest language features for improved performance and readability. Ensure the code is highly maintainable, with robust exception handling throughout. Replace all logging with the loguru library for advanced logging capabilities. If any issues arise during optimization, proactively research solutions online to implement best practices.

.gitignore

@@ -34,4 +34,6 @@
 .cache/
 build/
 test/
-.venv/
+.venv/
+build-test/
+__pycache__/

.kilocode/mcp.json

@@ -0,0 +1,3 @@
+{
+  "mcpServers": {}
+}

ARCHITECTURE.md

@@ -0,0 +1,83 @@
+
+# Lithium-Next Project Architecture
+
+This document provides a comprehensive overview of the architecture of the Lithium-Next project, a modular and extensible open-source platform for astrophotography.
+
+## 1. High-Level Architecture
+
+Lithium-Next follows a modular, component-based architecture that promotes separation of concerns and high cohesion. The project is organized into several distinct layers, each with a specific responsibility:
+
+- **Application Layer**: The main entry point of the application, responsible for initializing the system and managing the main event loop.
+- **Core Layer**: Provides fundamental services and utilities, such as logging, configuration management, and a tasking system.
+- **Component Layer**: Contains the various components that make up the application's functionality, such as camera control, telescope control, and image processing.
+- **Library Layer**: Includes third-party libraries and internal libraries that provide specialized functionality.
+- **Module Layer**: A collection of self-contained packages that provide additional features and can be easily added or removed from the project.
+
+## 2. Directory Structure
+
+The project's directory structure reflects its modular architecture:
+
+```
+/
+├── src/                # Source code for the core application and components
+│   ├── app/            # Main application entry point
+│   ├── client/         # Client-side components
+│   ├── components/     # Reusable application components
+│   ├── config/         # Configuration management
+│   ├── constant/       # Application-wide constants
+│   ├── database/       # Database interface
+│   ├── debug/          # Debugging utilities
+│   ├── device/         # Device control components (camera, telescope, etc.)
+│   ├── exception/      # Custom exception types
+│   ├── script/         # Scripting engine
+│   ├── server/         # Server-side components
+│   ├── target/         # Target management
+│   ├── task/           # Tasking system
+│   ├── tools/          # Command-line tools
+│   └── utils/          # Utility functions
+├── modules/            # Self-contained modules
+├── libs/               # Third-party and internal libraries
+├── example/            # Example applications and usage demonstrations
+├── tests/              # Unit and integration tests
+├── docs/               # Project documentation
+├── cmake/              # CMake modules and scripts
+└── build/              # Build output
+```
+
+## 3. Build System
+
+The project uses CMake as its build system. The main `CMakeLists.txt` file in the project root orchestrates the build process, while each component and module has its own `CMakeLists.txt` file that defines how it should be built and linked.
+
+The build system is designed to be highly modular and configurable. Components and modules can be easily added or removed by simply adding or removing their corresponding subdirectories and updating the `CMakeLists.txt` files.
+
+## 4. Core Components
+
+### 4.1. Task System
+
+The task system is a key component of the Lithium-Next architecture. It provides a flexible and powerful way to execute and manage long-running operations, such as image exposures, calibration sequences, and automated workflows.
+
+The task system is based on a producer-consumer pattern, where tasks are added to a queue and executed by a pool of worker threads. Tasks can be chained together to create complex workflows, and they can be monitored and controlled through a simple and intuitive API.
+
+### 4.2. Device Control
+
+The device control system provides a unified interface for controlling a wide range of astronomical devices, including cameras, telescopes, focusers, and filter wheels. It is designed to be extensible, allowing new devices to be added with minimal effort.
+
+The device control system is based on a driver model, where each device has a corresponding driver that implements a common set of interfaces. This allows the application to interact with different devices in a consistent and predictable way.
+
+### 4.3. Configuration Management
+
+The configuration management system provides a centralized way to manage the application's settings and preferences. It supports a variety of configuration sources, including command-line arguments, environment variables, and configuration files.
+
+The configuration system is designed to be type-safe and easy to use. It provides a simple API for accessing and modifying configuration values, and it supports a variety of data types, including strings, numbers, and booleans.
+
+## 5. Modularity and Extensibility
+
+Lithium-Next is designed to be highly modular and extensible. New features and functionality can be easily added by creating new components or modules.
+
+Components are reusable building blocks that can be combined to create complex applications. They are designed to be self-contained and have a well-defined interface, which makes them easy to test and maintain.
+
+Modules are self-contained packages that provide additional features and can be easily added or removed from the project. They are designed to be independent of the core application, which allows them to be developed and maintained separately.
+
+## 6. Conclusion
+
+The Lithium-Next project has a well-designed and documented architecture that promotes modularity, extensibility, and maintainability. The project's clear separation of concerns, component-based design, and powerful tasking system make it a flexible and robust platform for astrophotography.