# Mission: Session Storage (`sessionStorage`)

## Why
As a frontend engineer, you want durable judgment about **short-lived, tab-scoped client state** — not a one-off `setItem` tutorial. When a feature needs multi-step wizard drafts in one tab, temporary UI flags, or isolation between parallel tabs, you should pick `sessionStorage` only when it is the right tool, defend that choice in design reviews, and spot deal-breakers early (sync main-thread cost, string-only / ~5 MB, no workers, wrong place for secrets or durable data).

## Success looks like
- Given a product requirement, choose among memory, `sessionStorage`, `localStorage`, cookies, Cache API, OPFS, and IndexedDB (and say why)
- Know what `sessionStorage` gives you (same-origin string map, **per tab / page session**, survives reload, dies when the tab closes) — and what it does not (not shared across tabs, not for workers, not durable across browser restarts)
- Spot deal-breakers early (auth tokens, bulk structured data, multi-tab sync, main-thread thrashing, treating it like a database)
- Defend the choice in a design review with clear lifetime and isolation constraints

## Status
**Complete** — lessons 1–4 done (lesson-first path; external primaries optional). Keep `reference/decision-playbook.html` + `integration-checklist.html` + `storage-api.html` for design reviews.

## Constraints
- Frontend-first: system design decisions and browser APIs
- Sibling to IndexedDB, Cache API, OPFS, and Service Workers: decision fluency first; API mechanics after the spectrum
- Short interactive lessons; optimize for retention over speed
- Learner already has storage-spectrum framing from IndexedDB / Cache API / OPFS tracks

## Out of scope
- Full IndexedDB / OPFS / Cache Storage implementation depth (comparison only; other tracks own those)
- Building a production multi-tab sync bus or CRDT layer
- Cookie / auth protocol design beyond “don’t put secrets in Web Storage”
- Server-side session stores and backend session middleware