designlisted

# Very Happy design Read `docs/design-language.md` from the repository root before changing UI. It is the sole design authority; `packages/happy-web-v2/src/styles/tokens.css` owns concrete tokens. Do not substitute a fresh style or copy the review prototype's reduced feature set. - Product direction: compact, content-first workspace inspired by Codex, with the existing Very Happy smile-terminal identity and live connection signals. Public Landing/docs/login must retain deliberate brand expression; workspace density does not mean shrinking public hero sections. - For a visual migration, inspect actual routes, actions, capability checks, shortcuts and persistence first. Use `specs/2026-09-workspace-entry-audit.md` as an index, then verify current code. Record coverage in `specs/2026-09-workspace-rollout.md`; a pretty fixture is not proof of retained functionality. - Reuse `ui/` primitives and real feature components. Migrate owners instead of appending a parallel override stylesheet. Delete superseded components/assets only after checking imports and route references; compare production entry/chunk sizes and avoid new dependencies for cosmetic work. - Verify real rendered pages in light/dark, desktop and 320/390px coarse viewports. Use `scripts/dev/css-probe.mjs` before/after, including pixels for layered decoration. Keep xterm geometry and always-dark behavior separate. Mobile editable controls use 16px; keyboard focus remains visible without external glow. - Documentation a