DP44/docs/QWEN3CoderNext.md

# 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<T>` 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 (<IModule> 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