Analyzed Maintenance Records

docs/maintenance-records.md

@@ -0,0 +1,75 @@
+# MotoVaultPro Maintenance Records Analysis
+
+## Executive Summary
+
+After thoroughly investigating the entire application stack, the key insight that explains the confusion around Service Records, Repairs, and Upgrades is:
+
+**"Repairs" in the UI actually maps to `CollisionRecord` in the backend, not a separate repair entity.**
+
+## Complete Analysis
+
+### 1. Data Models
+
+- **ServiceRecord**: Inherits from `GenericRecord` (/Models/ServiceRecord/ServiceRecord.cs:4)
+- **UpgradeRecord**: Inherits from `GenericRecord` (/Models/UpgradeRecord/UpgradeRecord.cs:4)  
+- **"Repairs"**: Actually uses `CollisionRecord` model - **no separate "RepairRecord" model exists**
+
+### 2. Database Storage
+
+**LiteDB Tables:**
+- Service Records → `"servicerecords"` table
+- Upgrades → `"upgraderecords"` table
+- **Repairs → `"collisionrecords"` table** (/External/Implementations/Litedb/CollisionRecordDataAccess.cs:15)
+
+**PostgreSQL Tables:** 
+- Service Records → `app.servicerecords`
+- Upgrades → `app.upgraderecords`  
+- **Repairs → `app.collisionrecords`**
+
+### 3. Controllers
+
+- **ServiceController.cs**: Handles ServiceRecord operations
+- **UpgradeController.cs**: Handles UpgradeRecord operations
+- **RepairController.cs**: **Actually handles CollisionRecord operations** with "Repair Record" labels in odometer notes (/Controllers/Vehicle/RepairController.cs:41)
+
+### 4. Frontend Evidence
+
+The UI mapping is revealed in the views:
+
+**Collision/_CollisionRecords.cshtml:**
+- Line 17: `@model List<CollisionRecord>` 
+- Line 21: Shows `"# of Repair Records"` to users
+- Line 38: Button labeled `"Add Repair Record"`
+- Uses `ImportMode.RepairRecord` for configuration
+
+### 5. JavaScript Handling
+
+The smoking gun in `/wwwroot/js/shared.js:948-950`:
+```javascript
+case "RepairRecord":
+    friendlySource = "Repairs";
+    refreshDataCallBack = getVehicleCollisionRecords;  // ← Backend calls CollisionRecord APIs
+```
+
+## Key Finding: They ARE Identical (Except for Context)
+
+**Service Records and Upgrades share identical data structures**, differing only in:
+
+1. **Database table names** (`servicerecords` vs `upgraderecords`)
+2. **UI labels and context** 
+3. **Separate controllers for business logic routing**
+
+**"Repairs" is actually CollisionRecord** with confusing UI labeling that presents collision/accident records as "repair records" to users. This creates a conceptual disconnect between the technical implementation (`CollisionRecord`) and the user-facing terminology ("Repairs").
+
+## Conclusion
+
+The system essentially treats them as three separate record types for categorization purposes, but Service Records and Upgrades are functionally identical data containers differentiated only by their intended use case and storage location.
+
+This design allows users to categorize their maintenance activities conceptually while maintaining identical underlying functionality and data structures for consistent behavior across all record types.
+
+---
+
+**Document Version**: 1.0  
+**Last Updated**: August 2025  
+**Analysis Scope**: Complete frontend, backend, and database investigation  
+**Related Documentation**: [MotoVaultPro Architecture Documentation](architecture.md)