Vault is Coffee’s unified file / object layer under a configurable ROOT_DIR. The important architectural choice: the main HTTP process does not own every fs call and directory watcher for that tree. Instead, a Vault worker (child process) owns vault I/O and speaks a small IPC protocol — coordinator on main, disk work elsewhere.
In the cloud you might use S3, MinIO, or a NAS API. They all answer: list, get, put, delete — with policy on top. Vault is that idea at crib scale: paths under one root, enforced normalization, reserved subtrees like .coffee/ for internal state.
You trade infinite scale for simplicity: one machine, one root, JSON-line messages over stdio — a small, explicit contract between coordinator and worker (same shape as bigger systems, without the ceremony).
The sidecar can spin up on first storage use rather than blocking server boot. Default CE folders are created when something runs the init layout flow (POST /api/vault/init) — not automatically on every empty disk — so you explicitly bless a root. That matches a real ops habit: no surprise writes until you confirm where data lives.
Keyman state can live under .coffee/keyman/ in the same root. Revoking vault init wipes that too — by design.
When Keyman enforcement is on, /api/file/* and /api/vault/* expect a valid Bearer token or API key before the main process proxies work into the Vault client. Module 3 unpacks that; for Vault itself, remember: auth is on the boundary, storage is behind it.
Use the Vault POC to feel list/upload/delete; the concepts above are what make that layer safe to grow.