Chaos testing exercises error paths

Error boundaries, circuit breakers, and retry logic are only as good as the failure scenarios they were written to handle. Without chaos testing, these resilience mechanisms are untested hypotheses. ISO 25010 reliability.fault-tolerance requires demonstrated tolerance, not assumed tolerance. Vibe-coded applications are especially prone to this gap: the happy path is well-exercised, but the circuit breaker has never opened in a real test, and the error boundary's fallback has never rendered in a staged failure. The first time these paths run is in production, during an incident.

Add at least one chaos test that deliberately injects a failure and asserts the application degrades gracefully. MSW (Mock Service Worker) is the lowest-friction option for frontend tests.

// tests/chaos/api-failure.test.tsx
import { server } from '../mocks/server'
import { http, HttpResponse } from 'msw'

test('shows error message when dashboard API fails', async () => {
  server.use(
    http.get('/api/dashboard', () =>
      HttpResponse.json({ error: 'service unavailable' }, { status: 503 })
    )
  )
  render(<Dashboard />)
  expect(await screen.findByText(/failed to load/i)).toBeVisible()
  expect(screen.queryByRole('progressbar')).not.toBeInTheDocument()
})

Document findings from each chaos run — what failed, what recovered correctly, what needed fixing — in docs/chaos-findings.md.