# QWEN3CoderNext - DataPRO Codebase Onboarding Guide ## Quick Start ### Build & Run ```bash # Build solution (Windows/Visual Studio required) msbuild DataPRO/DataPRO.sln /p:Configuration=Debug # Run tests (NUnit-based) # Tests located in DataPRO/UnitTest/ ``` ### Critical Files - **Solution**: `DataPRO.sln` (440+ lines, 100+ projects) - **Main App**: `DataPRO/App.xaml.cs` (4620+ lines - god class warning) - **Database**: `DataPRO/DbAPI/DbAPI.cs` (static facade, no interface) - **Constants**: `Common/DTS.Common.Core/DTSConstants.cs` (hardcoded dev paths) ## Architecture Summary ### Tech Stack - **UI Framework**: WPF (.NET Framework 4.8) - **Architecture**: MVVM + Prism 8.x Modularity - **DI Container**: Unity - **State Machine**: Stateless library ( IService ) ### High-Level Layers ``` ┌─────────────────────────────────────────────────────────────┐ │ UI Layer (Prism Modules) │ │ Sensors, Hardware, Groups, Realtime, Reports, ISO Settings│ │ 30+ modules, each with ViewModels, Views, Services │ └───────────────────────┬───────────────────────────────────────┘ │ EventAggregator (IEventAggregator) ▼ ┌─────────────────────────────────────────────────────────────┐ │ Services Layer (IService, DASFactory) │ │ - Hardware discovery & command execution │ │ - State machine (Prepare→Configure→Arm→Realtime→...) │ │ - UDP streaming for real-time data │ └───────────────────────┬───────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Data Layer (DbAPI, SensorDB) │ │ Static DbAPI facade → IConnections, ISensors, IGroups │ │ SQLite database with hardware-specific schemas │ └───────────────────────────────────────────────────────────────┘ ``` ### Data Flow Patterns 1. **Hardware Discovery**: Hardware → DASFactory → EventBus → Modules 2. **Test Configuration**: Sensors → Groups → TestSetups → DbAPI 3. **Real-time Data**: IService → UDP → Charts + Database Storage ## Development Workflow ### Adding a New Module 1. Follow pattern in `DataPRO/Modules/Sensors/` or `DataPRO/Modules/Hardware/` 2. Module must implement `IModule.Initialize()` 3. Register views/services in `RegisterTypes()` (Unity container) 4. Subscribe to events via `IEventAggregator` (avoid staticDbAPI where possible) ### Adding Hardware Support 1. **Hardware Commands**: Add command library in `HardwareCommands/` (e.g., `RibeyeCommands/`) 2. **Hardware Type**: Add enum to `DTS.Common.Core/DASHardwareType.cs` 3. **Factory Registration**: Register in `DASFactory` (see `DASFactory.cs` hardware discovery logic) 4. **Module**: Create or extend Prism module for UI support ### Event Aggregator Patterns - **Hardware Events**: `HardwareConnectedEvent`, `HardwareDisconnectedEvent` - **Data Events**: `TestDataUpdatedEvent`, `RealtimeDataAvailableEvent` - **State Events**: `SystemStateChangedEvent` - Use `PubSubEvent` for cross-module communication - **Avoid**: Direct coupling, static DbAPI access in ViewModels ### Import/Export Workflow 1. **Template**: See `GLM5Analysis/PatternLibrary/ImportExport.md` 2. **Data Format**: CSV, XML, or custom binary 3. **Validation**: Run through `DbAPI` layer (don't bypass) 4. **Error Handling**: Use `IEventAggregator` to publish导入 errors ## Key Gotchas & Tech Debt ### Critical 1. **Static DbAPI** (`DbAPI.cs:237-373`): No interface abstraction, hard to test 2. **God Class**: `App.xaml.cs` contains 4620+ lines of mixed logic (licensing, test state, DB ops, UI) 3. **Mixed Patterns**: BackgroundWorker (legacy) vs async/await (newer code) 4. **Hardcoded Paths**: `DTSConstants.cs` contains dev environment paths 5. **Module initialization**: Some use `Initialize()`, others `RegisterTypes()` - inconsistent ### Testing - **UnitTest**: NUnit-based tests in `DataPRO/UnitTest/` - **Test Scaffolds**: See `GLM5Analysis/TestScaffolds/` - **Mocking**: Use Moq for `IEventAggregator`, `IService`, `IDbConnection` ### Build Issues - **Windows Only**: Requires Visual Studio (WPF, .NET Framework 4.8) - **Dependencies**: SQLite runtime, National Instruments drivers (if applicable) ## Tooling & Documentation ### AI-Powered Search (Recommended) ```python # Use these tools before grep: retrieval_vector_search("how does hardware discovery work") retrieval_get_module_summary("DataPRO/Modules/Sensors") retrieval_list_enriched_modules() ``` ### Existing Documentation | Location | Purpose | |----------|---------| | `GLM5Analysis/Architecture.md` | System architecture (420-line master guide) | | `GLM5Analysis/PromptTemplates/` | Task-specific guides (AddUnitTest, AddHardware, etc.) | | `GLM5Analysis/PatternLibrary/` | Reusable patterns (MVVM, Prism, ImportExport) | | `GLM5Analysis/TestScaffolds/` | Test templates | | `enriched-qwen3-coder-next/` | AI-generated module docs | | `GIT Migration.md` | SVN → Git migration plan | ## Further Reading 1. **Core Modules** (use `retrieval_get_module_summary()`): - `Common/DTS.Common.Core/` - Constants, base classes - `DataPRO/DbAPI/` - Database access layer - `DataPRO/Modules/Sensors/` - Sensor management module - `DataPRO/Modules/Hardware/` - Hardware discovery module 2. **Critical Files**: - `DataPRO/App.xaml.cs` - Main application initialization - `DataPRO/DbAPI/DbAPI.cs` - Database facade (static, no interface) - `DataPRO/Modules/ModuleBase.cs` - Prism module base class 3. **Patterns** (see `GLM5Analysis/PatternLibrary/`): - MVVM Pattern (ViewModel, View, Model separation) - Prism Module Pattern ( interface, registration) - Event Aggregator Pattern (cross-module communication) - Service Pattern (IDataService, ISensorService) - DataAccess Pattern (DbAPI facade pattern) --- **Remember**: - Use `retrieval` tools first for code exploration - Avoid static DbAPI access in new code - Follow Prism module patterns consistently - Check `AGENTS.md` for opencode-specific workflow configuration