# Severity Levels & Response Standards

## Legend
| Symbol | Meaning | | Abbrev | Meaning |
|--------|---------|---|--------|---------|
| 🚨 | critical/urgent | | sev | severity |
| ⚠ | warning/caution | | resp | response |
| ℹ | information | | act | action |
| ✅ | success/ok | | esc | escalation |

## Universal Severity Classification

```yaml
Severity_Levels:
  CRITICAL [10]:
    Definition: "Data loss, security breach, production down, system compromise"
    Response: "Immediate stop, alert, rollback, incident response"
    Recovery: "Manual intervention required, full investigation"
    Escalation: "Immediate user notification + system halt"
    Examples:
      - Security vulnerabilities being committed
      - Data deletion without backup
      - Production system failures
      - Credential exposure
      - System corruption
    
  HIGH [7-9]:
    Definition: "Build failure, test failure, deployment issues, significant bugs"
    Response: "Stop workflow, notify user, suggest fixes"
    Recovery: "Automated retry with backoff, alternative paths"
    Escalation: "User notification + corrective action required"
    Examples:
      - Compilation errors
      - Test suite failures
      - Deployment rollbacks
      - API integration failures
      - Major functionality breaks
    
  MEDIUM [4-6]:
    Definition: "Warning conditions, performance degradation, code quality issues"
    Response: "Continue with warning, log for later review"
    Recovery: "Attempt optimization, monitor for escalation"
    Escalation: "Log warning + optional user notification"
    Examples:
      - Performance bottlenecks
      - Code quality violations
      - Deprecated API usage
      - Configuration warnings
      - Non-critical dependency issues
    
  LOW [1-3]:
    Definition: "Info messages, style violations, minor optimizations, suggestions"
    Response: "Note in output, continue execution"
    Recovery: "Background fixes, cleanup on completion"
    Escalation: "Silent logging only"
    Examples:
      - Code style violations
      - Minor optimization opportunities
      - Documentation suggestions
      - Informational messages
      - Best practice recommendations
```

## Response Time Requirements

```yaml
Response_Times:
  CRITICAL [10]:
    Detection_Time: "Immediate (real-time)"
    Response_Time: "< 1 second"
    User_Notification: "Immediate blocking alert"
    
  HIGH [7-9]:
    Detection_Time: "< 5 seconds"
    Response_Time: "< 10 seconds"
    User_Notification: "Immediate non-blocking alert"
    
  MEDIUM [4-6]:
    Detection_Time: "< 30 seconds"
    Response_Time: "< 60 seconds"
    User_Notification: "End of operation summary"
    
  LOW [1-3]:
    Detection_Time: "Background monitoring"
    Response_Time: "Batch processing"
    User_Notification: "Optional reporting"
```

## Context-Specific Severity Mapping

```yaml
Development_Context:
  File_Operations:
    File_Not_Found: "HIGH [8] - blocks workflow"
    Permission_Denied: "HIGH [7] - requires intervention"
    File_Lock_Conflict: "MEDIUM [5] - retry possible"
    Large_File_Warning: "LOW [2] - informational"
    
  Code_Quality:
    Syntax_Error: "HIGH [9] - prevents execution"
    Type_Error: "HIGH [8] - runtime failure likely"
    Unused_Variable: "MEDIUM [4] - code quality"
    Style_Violation: "LOW [2] - cosmetic issue"
    
  Git_Operations:
    Merge_Conflict: "HIGH [8] - manual resolution required"
    Uncommitted_Changes: "MEDIUM [6] - data loss possible"
    Branch_Behind: "MEDIUM [5] - sync recommended"
    Clean_Working_Tree: "LOW [1] - status information"

Security_Context:
  Credential_Exposure:
    Hardcoded_API_Key: "CRITICAL [10] - immediate security risk"
    Password_In_Code: "CRITICAL [10] - credential leak"
    Weak_Authentication: "HIGH [8] - security vulnerability"
    HTTP_vs_HTTPS: "MEDIUM [6] - protocol downgrade"
    
  Vulnerability_Detection:
    Known_CVE: "CRITICAL [10] - exploit available"
    Dependency_Alert: "HIGH [8] - update required"
    Insecure_Config: "HIGH [7] - hardening needed"
    Security_Header_Missing: "MEDIUM [5] - best practice"

Operations_Context:
  Deployment:
    Health_Check_Failed: "CRITICAL [10] - service down"
    Database_Connection_Lost: "CRITICAL [10] - data access failure"
    Memory_Exhaustion: "HIGH [9] - service degradation"
    Slow_Response_Time: "MEDIUM [6] - performance issue"
    
  Performance:
    CPU_Spike: "HIGH [8] - resource exhaustion"
    Memory_Leak: "HIGH [7] - gradual degradation"
    Cache_Miss_Rate: "MEDIUM [5] - efficiency concern"
    Log_Volume_High: "LOW [3] - monitoring alert"
```

## Automated Response Actions

```yaml
CRITICAL_Responses:
  Immediate_Actions:
    - Stop all operations immediately
    - Create emergency checkpoint
    - Block further execution
    - Generate incident report
    - Alert user with full context
    
  Recovery_Actions:
    - Rollback to last known good state
    - Isolate affected components
    - Enable safe mode operation
    - Require manual intervention
    
HIGH_Responses:
  Immediate_Actions:
    - Pause current operation
    - Attempt automatic fix
    - Log detailed error information
    - Notify user of issue and resolution attempt
    
  Recovery_Actions:
    - Retry with alternative approach
    - Escalate if retry fails
    - Provide user with fix options
    - Continue with degraded functionality if safe

MEDIUM_Responses:
  Immediate_Actions:
    - Log warning with context
    - Continue operation with monitoring
    - Add issue to cleanup queue
    - Track for trend analysis
    
  Recovery_Actions:
    - Schedule background fix
    - Monitor for escalation
    - Include in next maintenance cycle
    - Update user on resolution

LOW_Responses:
  Immediate_Actions:
    - Silent logging
    - Continue normal operation
    - Add to improvement backlog
    - Include in periodic reports
    
  Recovery_Actions:
    - Batch with similar issues
    - Address during optimization cycles
    - Include in documentation updates
    - Track for pattern analysis
```

## Escalation Pathways

```yaml
Escalation_Rules:
  Frequency_Based:
    Same_Issue_3x: "Increase severity by 1 level"
    Same_Issue_5x: "Increase severity by 2 levels"
    Pattern_Detected: "Escalate to system-level investigation"
    
  Time_Based:
    Unresolved_1h: "Increase visibility"
    Unresolved_4h: "Escalate to user attention"
    Unresolved_24h: "Mark as systemic issue"
    
  Impact_Based:
    Multiple_Users: "Increase severity by 1 level"
    Production_Environment: "Increase severity by 2 levels"
    Data_Integrity: "Immediate CRITICAL classification"

Escalation_Actions:
  Level_1: "Automated retry with different approach"
  Level_2: "User notification with recommended actions"
  Level_3: "System halt with manual intervention required"
  Level_4: "Emergency protocols + external alerting"
```

## Integration Standards

```yaml
Usage_in_Commands:
  Error_Classification:
    - Always assign severity level to errors
    - Use consistent [level] notation
    - Include severity in log messages
    - Map to appropriate response actions
    
  Response_Selection:
    - Check severity level first
    - Apply appropriate response template
    - Escalate based on frequency/pattern
    - Document resolution approach
    
  Reporting_Format:
    Structure: "[SEVERITY_LEVEL] Category: Description"
    Examples:
      - "[CRITICAL] Security: API key detected in commit"
      - "[HIGH] Build: Compilation failed with 3 errors"
      - "[MEDIUM] Performance: Query took 2.3s (>1s threshold)"
      - "[LOW] Style: 5 formatting issues found"

Cross_Reference_Usage:
  Commands: "@see shared/severity-levels.yml for error classification"
  Shared_Files: "@include shared/severity-levels.yml#CRITICAL for critical responses"
  Templates: "@flags shared/severity-levels.yml#Response_Times for SLA requirements"
```

---
*Severity Levels v1.0 - Universal classification and response standards for SuperClaude operations*