# Skins

Representation leaves game logic. An app's board is a grid of role
integers (0 = void); a skin is the one dictionary that says what each
role wears; faces just apply it.

## The law

- Apps emit role ids. No color names, chars, or emoji tables in
  `mrlyapps` or in web views - ever.
- A skin is data: role -> visual. Curated per-app dictionaries live in
  `mrlyui::skin::<app>` presets, keyed by the app's `skin` setting.
- The state carries the resolved dictionary next to the ids, so the web
  grid, the canvas, the CLI, and PNG all read the same one.

## The shape

`mrlyui::skin` defines the closed enum:

- `Visual { bg, motif, face }` - a cell background, an optional motif
  pattern (bg doubles as its color), an optional face on top.
- `Face::Glyph(text)` - baked from the bitmap font.
- `Face::Emoji(value)` - a unicode string; DOM-only until the emoji
  atlas exists (`FACE.md`), so canvas surfaces skip it.
- `Face::Sprite(rows)` - a small bitmap, e.g. chess pieces.

On the wire, state gains two keys: `ids` (rows of role integers) and
`skin` (an array indexed by role; each entry
`{ bg?, motif?, face?: { as, value | rows } }`).

`Skin::tileset(k, ink)` builds the canvas `TileSet` from the same
dictionary: solid or motif base, glyph faces baked in ink, emoji faces
skipped. Web views use `src/skin.tsx` (`visual()`, `face()`).

## Why

Same seed, same verbs, N skins: identical id grids, N renders. One
replayed episode times N skins is N perfectly labeled samples with
identical semantics - the gym's augmentation story lives in this layer.