## Summary: Why History Shows "SCAN" Generically

**The Confusion You See**:
- Each subsystem has its own "Scan" button (✅ correct)
- But history only shows generic "SCAN" (❌ confusing)

**The Implementation Flow**:
```
You click: "Scan Storage" button
  → UI passes: subsystem="storage"  ✅
  → Backend creates: command_type="scan_storage"  ✅
  → Agent runs: handleScanStorage()  ✅
  → Results stored: updates=[4 items]  ✅
  → History logged: action="scan"  ❌ (should be "storage scan" or similar)
```

**Root Cause**: 
The history table's `action` field stores only generic "scan" instead of including the subsystem context. Even though:
- Backend knows it's "scan_storage"
- UI sends subsystem parameter
- Results are subsystem-specific

**The Result**:
```
History shows unhelpful entries like:
  [14:20] SCAN → Success → 4 updates found
  [14:19] SCAN → Success → 461 updates found

Which subsystem found which updates? Unknown from history.
```

**This is a UX Issue, NOT a Bug**:
- ✅ Scans run for correct subsystems
- ✅ Results are accurate
- ✅ Backend distinguishes types ("scan_storage", "scan_system", "scan_docker")
- ❌ History display is generic "SCAN" instead of "Storage Scan", "System Scan", "Docker Scan"

**Why It Happened**:
- Early design had simple action types ("scan", "install", "upgrade")
- Later added docker/storage/system scans
- Database schema never evolved to include subsystem context
- History display just shows action field directly

**Files Involved**:
- ✅ Working: AgentHealth.tsx (per-subsystem scan buttons)
- ✅ Working: Backend API (creates "scan_storage", "scan_system", etc.)
- ❌ Broken: History logging (stores only "scan", not subsystem)
- ❌ Broken: History display (shows generic text, no subsystem parsing)

**Full Analysis**: `/home/casey/Projects/RedFlag/UX_ISSUE_ANALYSIS_scan_history.md`