# Mission: Concurrency (for a robust Playwright suite)

## Why
A Playwright end-to-end (E2E) suite is failing intermittently, and the failures look like concurrency and retry problems. The goal is to stop treating flakiness as noise to be retried away and instead diagnose it by mechanism — so the suite becomes a trustworthy signal that gates deploys rather than a thing people re-run until green.

## Success looks like
- Given a failing test, name the root-cause category (async wait, concurrency, test-order dependency, resource leak, shared fixture, …) rather than "flaky".
- Write tests that cannot race: no `waitForTimeout`, state asserted through conditions rather than delays.
- Reason about worker-level parallelism: what is shared, what is isolated, and where two workers can collide.
- Know when a retry is a legitimate robustness mechanism and when it is hiding a real bug.
- Explain the trade-offs of a chosen concurrency design out loud (throughput vs. isolation vs. debuggability).

## Constraints
- Learning is in service of a live, currently-broken suite — theory must cash out in changes to that suite.
- Suite lives in `~/Git/flowbase/apps/frontend/e2e` — 233 specs, 11 projects, `retries: 3`.

## Out of scope
- Low-level memory-model concurrency (atomics, cache coherence, lock-free data structures).
- Distributed-systems consensus (Raft, Paxos).