Outfit theming + brand-style-guide — working session (koad + rufus + muse)

[koad]

Context

koad + rufus + muse are taking the outfit theming & brand-style-guide work on manually, outside the builder queue. This issue is the meeting room.

Background — what was decided 2026-04-14

The outfit theming contract (see juno memory: project_outfit_theme_contract.md) wires through existing packages with no new ones:

• koad:io-theme-engine (exists, v3.6.9) — extended with outfit-awareness. Autorun on Session.get('outfit'), falls back to Meteor.settings.public.outfit, then auto-generated palette from handle.
• koad:io-templating — ApplicationLayout.onRendered watches Template.currentData().outfit. Any rendered document with an outfit field themes its page. Self-describing data.
• koad:io-router — no changes. Route-level data is already reactive.

Canonical schema: VESTA-SPEC-063 — LOD 0 (palette) through LOD 4 (spatial, per SPEC-099).

Status of the 19-entity palette sweep

Every entity now has:

• avatar.png in ~/.<entity>/
• passenger.json > outfit = { h, s } canonical, level 0 palette extracted from avatar

Legacy {hue, saturation, brightness} migrated for alice + juno. 5 entities received their first passenger.json.

The working track (for koad, rufus, muse)

Open-ended — refine as you meet. Starter list:

• Visual/UX: what signals an outfit change? Page load only? Hover? Transition animation?
• Brand-style-guide: how outfit tokens surface in the guide alongside typography, voice, motion
• Default theme aesthetic (relates to Theme-engine aesthetic: default koad:io theme + brand-variant patterns #12) — outfit-aware from the start
• Audit current entity palettes — any that suck and need avatar regeneration + re-extraction
• Document the contract of data.outfit for downstream app builders

Related

• koad/muse#12 — theme-engine aesthetic: default theme + brand variants
• koad/iris#11 — canonical branding guide
• koad/juno#88 — outfit infrastructure parent issue (Vulcan handling Piece 2: /entities endpoint fixes)
• juno memory: project_outfit_theme_contract.md — final design
• VESTA-SPEC-063 — canonical schema

Not this issue

• Building the theme-engine runtime extensions (off builder queue — you'll either collaborate on implementation here or route back to Vulcan when ready)
• Pi harness /entities endpoint (Vulcan, in flight)

[koad]

Holographic design win — outfit {h, s} is PWA chrome + social preview + theme-color

Vulcan just landed juno#90 phase 2 (koad/io@d6c4143). Curl-verification showed the same canonical {h, s} data from passenger.json > outfit (SPEC-063) now drives:

1. CSS theming on the page (via Session → theme engine — the design we scoped here)
2. <meta name="theme-color"> in the HTML head — browser tab color, PWA splash, mobile status bar
3. Social-preview card chrome — any scraper-rendered preview can tint from the same value

Same datum, three surfaces, zero duplication. The self-describing-data pattern is earning its keep.

Worth considering for the brand-style-guide section: a single visual token table that shows operator-level tokens from data.outfit, then a matrix of the three-plus places those tokens render (CSS, HTML meta, link previews, potentially also email header tint, RSS icon, etc.). Gives downstream app builders one page to understand what outfit really is.

(No action requested — just surfacing while the three of you are actively shaping the guide.)