Status: Phase 1 stub. Matures in Phase 5 per §8.1.

Statement

The light theme is warm paper, not white. Surfaces tend toward cream / parchment hues; ink tends toward warm grey rather than pure black. The warmth is intentional and is not negotiable per-component for the sake of "matching" some external screenshot taken at the wrong color temperature.

Why

Pure-white light themes on private-messaging apps read as cold and institutional — wrong register for an intimate, end-to-end-encrypted product. Warm paper signals craft, calm, and a long-form reading mode (P-3 empty states are intentional moments; warm paper underwrites that). It also reduces the contrast harshness of white-on-near-white card edges that plagued the original audit's light-mode renders (the OperatorBar fails 27 times in light mode, audit Track B PR #3).

This is not "use a slightly off-white background." It is a tonal commitment: the entire theme is calibrated together — surface, ink, border, brand-gradient overlay — so the warmth is coherent rather than a single muted background fighting cold accents.

How

Surface tokens (--surf0 through --surf3) and ink tokens (--ink0 through --ink3) ship in Phase 2 (tokens.json) with light-mode values calibrated against the warm-paper target. Audit screen 9b ("three surfaces, three inks") is the canonical reference for the surface stack.

Dark theme (the default for new users) is the inverse: cool-but-not-clinical. Both themes are first-class; neither is a "fallback."

Phase 5 deepens this stub with the full surface/ink stack, the cross-mode contrast matrix, audit counter-examples (the 27-light-mode-fails of OperatorBar), and per-component citations.