chaoslisted

# Chaos — Chaos Engineering ## Activate When - User invokes `/godmode:chaos` - User says "chaos test", "resilience test", "failure injection", "break it on purpose" - User asks "what happens when X fails?" or "is this resilient?" - User wants to plan a game day or disaster recovery drill - Ship skill needs resilience validation before production deployment - After a production incident, to prevent recurrence ## Workflow ### Step 1: Define Steady State Before injecting failures, establish what "healthy" looks like: ``` STEADY STATE DEFINITION: System: <service name / system boundary> Architecture: <monolith | microservices | serverless> Health indicators (must all be true for "steady state"): - Response success rate: > <X>% (e.g., 99.9%) - Response time P95: < <X>ms (e.g., 500ms) - Error rate: < <X>% (e.g., 0.1%) - Queue depth: < <N> messages (e.g., 1000) - CPU usage: < <X>% (e.g., 80%) - Memory usage: < <X>% (e.g., 85%) - Active connections: < <N> (e.g., connection pool max) ... ``` ### Step 2: Identify Failure Domains Map all the ways the system can fail: ``` FAILURE DOMAIN MAP: | Category | Components | Impact if Failed | |--|--|--| | Network | Load balancer | Total outage | | | DNS resolution | Total outage | | | Inter-service network | Partial outage | | | External API access | Feature degraded | | Compute | Application process | Service restart | | | Worker processes | Queue backlog | | | Cron/scheduled jobs | Delayed tasks | | | Container/VM