# Mission: OPFS (Origin Private File System)

## Why
As a frontend engineer, you want durable judgment about **file-shaped client storage** — not a one-off `getDirectory` tutorial. When a feature needs large blobs, offline export pipelines, editors, or high-throughput byte I/O on device, you should pick OPFS correctly, defend that choice in design reviews, and spot deal-breakers early (quotas, eviction, worker vs main-thread patterns, “not user-visible files”).

## Success looks like
- Given a product requirement, choose among memory, Web Storage, Cache API, IndexedDB, OPFS, and user-visible File System Access (and say why)
- Know what OPFS gives you (origin-private file/directory handles, optional high-perf sync access in workers) — and what it does not (not Finder/Explorer; not a keyed entity DB; not automatic multi-device truth)
- Spot deal-breakers early (wrong tool for Request/Response shells or structured records, quota/eviction assumptions, main-thread performance traps, confusing OPFS with user-visible pickers)
- Defend the choice in a design review with clear constraints

## Status
**Complete** — lessons 1–5 done (lesson-first; external primaries deferred; quizzes all correct through playbook). Design-review tools: `reference/decision-playbook.html`, `reference/integration-checklist.html`.

## Constraints
- Frontend-first: system design decisions and browser APIs, not DBA theory
- Sibling track to IndexedDB and Cache API: decision fluency first; hands-on handle CRUD and sync access after the spectrum
- Short interactive lessons; optimize for retention over speed
- Learner already has FE storage framing from IndexedDB + Cache API tracks

## Out of scope
- Full File System Access API product design (user-visible pickers) beyond comparison
- Building a production file-sync engine / CRDT layer
- Deep SQLite-wasm internals beyond “when that family wins”
- Server file storage and CDN configuration as the main topic