resilience-review

What this skill does

# Resilience Review

Evaluate how your application behaves when things go wrong — network failures, API errors, slow connections, missing data, and edge cases. Most apps are built for the happy path; this review systematically tests the unhappy paths that real users encounter.

## When to use

Use `/resilience-review` when:
- Before launching a user-facing feature
- After adding new API integrations or data sources
- When reliability is critical (healthcare, finance, e-commerce checkout)
- After production incidents caused by unhandled errors
- When moving from prototype to production quality

## Standards Referenced

- **Google SRE Principles** — Error budgets, graceful degradation
- **Netflix Chaos Engineering Principles** — Verify steady state, inject real-world failures
- **OWASP Error Handling** — Secure and user-friendly error responses
- **Nielsen Norman Group** — Error message usability heuristics

## Phase Overview

```
Phase 1: EDUCATE   → Why resilience matters and what we test
Phase 2: SCOPE     → Map failure points, dependencies, critical flows
Phase 3: ANALYZE   → Browser-based fault injection and edge case testing
Phase 4: REPORT    → Findings with evidence and user impact assessment
Phase 5: REMEDIATE → Fix guidance + YAML regression tests
```

---

## Phase 1: Educate

> **Why this matters:** Users don't experience your app in ideal conditions. 53% of mobile visits are abandoned if a page takes >3 seconds. Error pages with no guidance increase support tickets 5x. A blank screen is the worst possible failure mode — it tells the user nothing and offers no recovery path. Resilient apps maintain trust even when backend systems fail.

This review simulates real-world failure conditions in the browser and evaluates how your UI responds.

---

## Phase 2: Scope

### Gather context

1. **Auto-detect from codebase:**
   - API calls and their endpoints
   - Error boundary components (React ErrorBoundary, Vue errorHandler)
   - Loading state implementations (spinners, skeletons, suspense)
   - Empty state components
   - Retry logic / error recovery patterns
   - Offline support (service workers, cache strategies)
   - Third-party service dependencies

2. **Ask the user** (one at a time):
   - **Target URL**: Where is the app running?
   - **Critical user flows**: Which flows must never show a blank screen? (auto-detect from routes)
   - **Key API dependencies**: Which APIs does the frontend depend on? (auto-detected)
   - **Known fragile areas**: Any pages/features that break frequently? (optional)

3. **Map failure points:**
   - API endpoints the frontend calls (and what happens if each fails)
   - Third-party dependencies (CDN, auth provider, analytics, maps, payment)
   - Data-dependent UI (what shows when data is empty, missing, or malformed)
   - User input edge cases (long text, special characters, empty submissions)

---

## Phase 3: Analyze

Open a browser session with `new_session` using `record_evidence: true`. Run all applicable check categories.

### Category A: Error Handling (ERR)

| Check ID | Check | Standard | Method |
|----------|-------|----------|--------|
| ERR-01 | API errors show user-friendly message (not blank screen) | UX best practice | Mock API to return 500, check UI response |
| ERR-02 | Network timeout shows appropriate state | UX best practice | Mock network delay (30s), check UI |
| ERR-03 | 404 page exists and is helpful | UX best practice | Navigate to non-existent route |
| ERR-04 | JavaScript errors don't crash the page | Error boundaries | Inject JS error, check if page recovers |
| ERR-05 | Error messages are actionable | NN/g heuristics | Check error messages for: what happened, why, what to do |
| ERR-06 | Errors don't expose technical details | OWASP | Check error messages for stack traces, SQL, internal paths |
| ERR-07 | Form validation errors are clear and positioned | UX best practice | Submit invalid forms, check error placement and text |
| ERR-08 | Error states allow retry without page refresh | UX best practice | After error, check for retry button or recovery action |
| ERR-09 | Concurrent error handling (multiple simultaneous failures) | Resilience | Mock multiple API failures, check UI doesn't cascade |
| ERR-10 | Error logging doesn't expose PII | OWASP / Privacy | Check `get_browser_console_logs` during errors |

**Browser validation:** Use `description: + js:` statements to intercept network requests via `page.route()` to simulate failures. Check UI state after each failure. Use `get_browser_console_logs` for JavaScript errors.

```javascript
// Example: Mock API 500 error
await page.route('**/api/**', route => {
  route.fulfill({ status: 500, body: JSON.stringify({ error: 'Internal Server Error' }) });
});
```

### Category B: Graceful Degradation (DEG)

| Check ID | Check | Standard | Method |
|----------|-------|----------|--------|
| DEG-01 | Page works with JavaScript disabled (basic content) | Progressive enhancement | Disable JS, check if content is accessible |
| DEG-02 | Page works on slow connection (3G simulation) | Performance | Throttle to Slow 3G, check load behavior |
| DEG-03 | Non-critical features degrade without breaking critical ones | Graceful degradation | Disable third-party scripts, check core functionality |
| DEG-04 | Offline state is handled (if applicable) | PWA best practice | Go offline, check UI state and messaging |
| DEG-05 | Third-party service failure doesn't block page load | Resilience | Block third-party domains, check page loads |
| DEG-06 | Image loading failure shows fallback | UX best practice | Block image URLs, check for alt text/placeholder |
| DEG-07 | Font loading failure doesn't hide text | FOUT handling | Block font URLs, check text remains visible |
| DEG-08 | Feature detection over browser sniffing | Progressive enhancement | Check code for `navigator.userAgent` vs feature detection |

**Browser validation:** Use `page.route()` to block specific resources. Use CDP to simulate network conditions. Disable JavaScript via browser settings. Verify each degradation scenario.

### Category C: Empty & Edge States (EDGE)

| Check ID | Check | Standard | Method |
|----------|-------|----------|--------|
| EDGE-01 | Empty data state shows helpful message | UX best practice | Navigate to pages with no data, check display |
| EDGE-02 | Pagination handles zero results | UX best practice | Search for nonexistent term, check pagination |
| EDGE-03 | Long text doesn't break layout | Defensive CSS | Enter very long strings (500+ chars), check overflow |
| EDGE-04 | Special characters in input don't break UI | Input handling | Enter `<script>`, `"'&<>`, emoji, Unicode |
| EDGE-05 | Large data sets don't freeze UI | Performance | Load pages with maximum data, check responsiveness |
| EDGE-06 | Rapid user actions don't cause duplicate submissions | State management | Double-click submit buttons, rapid nav |
| EDGE-07 | Back/forward navigation maintains state | History management | Fill form, navigate away, come back |
| EDGE-08 | Refresh preserves expected state | State persistence | Refresh during multi-step flow, check state |
| EDGE-09 | Concurrent tab/session behavior | Session management | Open same page in two tabs, perform actions |
| EDGE-10 | Maximum file upload size handled | Input validation | Upload oversized file, check error message |

**Browser validation:** Navigate to pages and test each edge case. Use `act` to interact with forms, submit empty/extreme data. Use JavaScript to check for UI overflow, frozen states.

### Category D: API Contract & Data Handling (API)

| Check ID | Check | Standard | Method |
|----------|-------|----------|--------|
| API-01 | UI handles all HTTP error codes gracefully | API contract | Mock 400, 401, 403, 404, 422, 429, 500, 503 |
| API-02 | UI handles null/undefined fields without crashing | Defensive coding | Mock API response with null fields |
| API-03 | UI handles empty arrays/objects | Defensive coding