latency-ux-tradeofflisted

# Latency UX Tradeoff Waiting is a design surface. Every recommendation here hangs on a number — what users actually tolerate — or it doesn't ship. ## Verification gates (defined first; output is blocked until all pass) - **G1 — Threshold-tied:** every recommendation cites the user-tolerance threshold it serves — measured from the input when available, otherwise a named heuristic explicitly labeled `[heuristic, not measured on your users]`. "Feels fast enough" fails the gate. - **G2 — p50 AND p95 designed for:** the tail is a real user, not a rounding error — show the arithmetic (p95 at 30 uses/session ≈ 1.5 tail hits per session). A design that only works at p50 fails. - **G3 — Mechanism + cost:** each recommendation names its mechanism (stream, skeleton, optimistic UI, async+notify, precompute, cache) and its tradeoff (precompute burns tokens on unopened items; streaming reveals drafts). No invented user research — unstated thresholds are heuristics, labeled. ## Steps 1. **Bank the numbers:** p50/p95, what already renders fast, and any measured waiting behavior (bail rates, session patterns). Measured beats heuristic; a stated "40% bail at 3s" outranks any industry band. 2. **Fix the tolerance thresholds** for THIS flow: from measurements first; where none exist, apply the standard bands (~0.1s imperceptible · ~1s keeps flow · ~10s attention lost) explicitly labeled heuristic. High-frequency flows (30x/session) get tighter thresholds than one-shot flows — state the adj