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.