init

enriched-qwen3-coder-next/DataPRO/Modules/DatabaseImporter/DatabaseImport/Enums/Hardware.md

@@ -0,0 +1,43 @@
+---
+source_files:
+  - DataPRO/Modules/DatabaseImporter/DatabaseImport/Enums/Hardware/HardwareTypes.cs
+generated_at: "2026-04-16T04:32:55.929056+00:00"
+model: "Qwen/Qwen3-Coder-Next-FP8"
+schema_version: 1
+sha256: "38a6927cd83972ad"
+---
+
+# Hardware
+
+### 1. Purpose  
+This module defines the `HardwareTypes` enumeration, which serves as a canonical type-safe identifier for supported hardware devices within the DatabaseImport subsystem. It enables unambiguous referencing and mapping of physical hardware units (e.g., SLICE variants, TOM, SIM, DIM, G5-series devices) during data import operations—likely when correlating raw sensor data or configuration files with specific hardware models in the database. Its role is foundational: it standardizes hardware type representation across the import pipeline, ensuring consistent interpretation of device metadata.
+
+### 2. Public Interface  
+The module exposes a single public type:
+
+- **`HardwareTypes`** (`enum`)  
+  A strongly-typed enumeration of hardware device types used in the system. Each member is assigned an explicit integer value starting from `0`. The enum includes variants of SLICE hardware (e.g., `SLICE_Base`, `SLICE2_IEPE_Hi`, `SLICE6DB`), legacy/legacy-adjacent devices (`TDAS_Pro_Rack`, `TDAS_LabRack`), and specialized modules (`TOM`, `SIM`, `DIM`, `Ribeye`, `G5INDUMMY`, `SLICE_EthernetController`).  
+  *Note:* A commented-out entry `//G5IPORT=22` exists, indicating a planned or deprecated type.
+
+### 3. Invariants  
+- **Sequential integer values (mostly):** All explicitly defined enum members have unique, non-overlapping integer values. However, the sequence is *not strictly contiguous* due to the commented-out `G5IPORT=22`—the value `22` is unused, and the next entry (`G5INDUMMY`) is `23`.  
+- **No negative values:** All enum values are ≥ 0.  
+- **No runtime validation:** The enum itself enforces no semantic constraints (e.g., it does not prevent invalid combinations or enforce hardware-specific rules). Validation (if any) must occur elsewhere in the codebase.  
+- **Stable identity:** The integer values are part of the public contract; changing them would break persistence (e.g., in database records or serialized configs).
+
+### 4. Dependencies  
+- **No external dependencies:** The file imports only the `System` namespace implicitly (via `namespace` declaration) and contains no `using` statements or external references.  
+- **Consumers:** This enum is almost certainly referenced by other modules in the `DatabaseImport` namespace (e.g., classes handling hardware configuration parsing, database schema mapping, or device initialization). Based on naming conventions, consumers may include:  
+  - Hardware-specific importers (e.g., `SLICEImporter`, `TOMImporter`)  
+  - Database schema mappers (e.g., tables/columns storing `HardwareType` as an integer)  
+  - Configuration parsers (e.g., reading hardware type strings and mapping them to `HardwareTypes` enum values)  
+  *Exact consumers cannot be determined from this file alone.*
+
+### 5. Gotchas  
+- **Non-contiguous numbering:** The gap at value `22` (due to commented-out `G5IPORT`) may cause issues if downstream code assumes contiguous ranges (e.g., using `Enum.GetValues(typeof(HardwareTypes)).Length` for array sizing without filtering).  
+- **Commented-out member:** `G5IPORT=22` is commented out but *not removed*, which could mislead developers into expecting support for this type. Its status (deprecated, planned, or obsolete) is unclear.  
+- **No documentation on semantics:** The enum provides no XML comments or inline descriptions explaining what each hardware type *does* (e.g., "SLICE_Bridge" vs. "SLICE2_Bridge_Hi"). This forces reliance on external documentation or reverse engineering.  
+- **Case sensitivity in string parsing:** If string-to-enum conversion is used (e.g., from config files), the enum is case-sensitive (standard C# behavior), and mismatches (e.g., `"slice_base"` vs. `"SLICE_Base"`) will fail unless explicitly handled.  
+- **No `Flags` attribute:** The enum is *not* marked with `[Flags]`, implying bitwise combinations are not intended—though this is not enforced by the compiler.  
+
+*None identified beyond these.*

enriched-qwen3-coder-next/DataPRO/Modules/DatabaseImporter/DatabaseImport/Enums/Sensors.md

@@ -0,0 +1,77 @@
+---
+source_files:
+  - DataPRO/Modules/DatabaseImporter/DatabaseImport/Enums/Sensors/SensorStatus.cs
+  - DataPRO/Modules/DatabaseImporter/DatabaseImport/Enums/Sensors/LinearizationFormula.cs
+  - DataPRO/Modules/DatabaseImporter/DatabaseImport/Enums/Sensors/ZeroMethodType.cs
+generated_at: "2026-04-16T04:32:45.162581+00:00"
+model: "Qwen/Qwen3-Coder-Next-FP8"
+schema_version: 1
+sha256: "fee300d457ca6c5a"
+---
+
+# Sensors
+
+## 1. Purpose  
+This module defines core enumeration types used for representing sensor metadata and calibration behavior within the `DatabaseImport` subsystem of the DataPRO system. Specifically, it standardizes how sensor operational status, nonlinear signal conversion methods, and zero-point calculation strategies are encoded—enabling consistent interpretation of imported sensor configuration data (e.g., from legacy databases like GM ISF). These enums serve as foundational building blocks for deserializing and validating sensor-related records during database import operations.
+
+---
+
+## 2. Public Interface  
+
+### `SensorStatus`  
+- **Namespace**: `DatabaseImport`  
+- **Type**: `public enum`  
+- **Members**:  
+  - `Available`: Sensor is ready for use.  
+  - `InUse`: Sensor is currently deployed or active.  
+  - `OutForService`: Sensor is offline for maintenance.  
+  - `OutForCalibration`: Sensor is offline for calibration.  
+  - `Retired`: Sensor is no longer in service.  
+
+### `NonLinearStyles`  
+- **Namespace**: `DatabaseImport`  
+- **Type**: `public enum`  
+- **Members**:  
+  - `IRTraccManual`: Manual linearization method (likely user-defined or legacy).  
+  - `IRTraccDiagnosticsZero`: Linearization using diagnostic-based zero point.  
+  - `IRTraccZeroMMmV`: Linearization using zero point derived from millivolt-level diagnostics.  
+  - `IRTraccAverageOverTime`: Linearization using time-averaged zero point.  
+  - `Polynomial`: Polynomial-based nonlinearity correction (e.g., higher-order fit).  
+  - `IRTraccCalFactor`: Linearization using a calibration factor (likely multiplicative).  
+
+### `ZeroMethodType`  
+- **Namespace**: `DatabaseImport`  
+- **Type**: `public enum`  
+- **Members**:  
+  - `AverageOverTime = 0`: Compute zero by averaging signal over time.  
+  - `UsePreEventDiagnosticsZero = 1`: Compute zero using diagnostics captured *before* an event.  
+  - `None = 2`: No zero calculation—use an absolute or pre-specified zero value.  
+- **Note**: The comment explicitly warns that legacy compatibility (e.g., GM ISF imports) depends on the *ordinal values* of this enum; changing them would break data import correctness.
+
+---
+
+## 3. Invariants  
+
+- **Ordinal stability for `ZeroMethodType`**: The underlying integer values (`0`, `1`, `2`) are part of the contract with legacy data sources (e.g., GM ISF). Reordering, inserting, or modifying values would corrupt imports.  
+- **Exhaustive status coverage**: `SensorStatus` must account for all known sensor lifecycle states in the system; no new statuses should be added without updating downstream import logic.  
+- **Nonlinearity method alignment**: `NonLinearStyles` values correspond to specific calibration workflows; each implies a particular data structure or processing pipeline (e.g., `Polynomial` likely requires coefficient arrays, while `IRTraccCalFactor` expects a scalar factor).  
+
+---
+
+## 4. Dependencies  
+
+- **Depends on**: None (pure enum definitions; no external references).  
+- **Depended on by**:  
+  - Other types in the `DatabaseImport` module (e.g., sensor record classes, import parsers) that consume these enums to interpret database fields.  
+  - Likely used in serialization/deserialization layers (e.g., JSON/XML converters, database mappers) that handle sensor configuration data.  
+  - Legacy import adapters (e.g., GM ISF importer) rely on `ZeroMethodType`’s fixed ordinals for backward compatibility.  
+
+---
+
+## 5. Gotchas  
+
+- **`ZeroMethodType.None` does *not* mean "no zero calculation" in the intuitive sense**: Its value (`2`) and comment clarify it means "use an absolute/external zero value," not "skip zeroing." Misinterpreting this could lead to incorrect signal offsets.  
+- **`NonLinearStyles` enum name mismatch**: The file is named `LinearizationFormula.cs`, but the enum is `NonLinearStyles`. This may cause confusion—ensure consumers use the *actual* type name.  
+- **Missing `Description` attributes**: Though `ZeroMethodType` members have XML summaries, they lack `[Description]` attributes (commented out). If the system relies on reflection-based description resolution (e.g., for UI or logging), this could cause runtime issues.  
+- **No validation of enum values in source**: The enums themselves do not enforce constraints (e.g., "only one status may be active at a time"). Validation logic, if any, resides elsewhere.  
+- **No guidance on fallback behavior**: If an unknown `NonLinearStyles` or `SensorStatus` value is encountered during import (e.g., from a newer database), the source provides no indication of how it should be handled (throw? default? warn?).