Roadmap

The visual + chess-aware UI surface that pairs with Tabia (data) and Rabbit (board rendering). Like Tabia’s roadmap, Motif extracts on consumer demand, not on schedule.

Already landed

• Design tokens (design/tokens.css) — surface, text, shadow, radius, transition tokens, dark-first.
• Chess tokens (design/chess-tokens.css) — win/loss colors, NAG palette, state gradients.
• Theme runtime (design/theme.js) — piece / board-color / color-scheme switcher with localStorage persistence.
• Chess-aware web components — <motif-move-list>, <motif-engine-panel>, <motif-fen-area>, <motif-branch-popover>, <motif-eco-opening-bar>, <motif-player-header>, <motif-toolbar>, SanPreview, ContextMenu, PgnArea composer.
• bindGame helper (components/utils/bindGame.js) — wires a LitElement to Tabia’s slice subscriptions with auto-cleanup on disconnect. Standard pattern for slice-driven components after the lifecycle migration.
• Static reference data — 39 piece SVG sets, ECO opening table (3641 positions), test-PGN fixtures.
• Canonical keymap spec (docs/KEYBOARD.md) — the agreed-upon key → action mapping all Motif/Tabia apps should bind.

Queued

Step	What	Driven by
1	bindKeyboard — drop-in keybinder that implements the KEYBOARD.md spec. Takes a { game, board, panel, ... } handle bag and a target element; returns an unbind function. Handles focus-aware suppression (inputs/textareas/contentEditable), branch-popover priority routing, and the autorepeat scrubbing rule.	every consumer currently rewires keys inline
2	Editor mounters — comment editing surface, NAG picker, variation promote/demote UI. Consumes Tabia’s editor-state primitives once Tabia roadmap step 3 lands.	first consumer that wants editing UI (likely a prep reader)
3	Piece-set cleanup — only 8 of the 39 sets are commercially safe (see PIECE-LICENSING.md). Decide whether to drop, relicense, or re-skin the unsafe ones before any stack project ships.	first project that wants to ship publicly
4	Autoplay helper + <motif-play-button> — a GameAutoPlayer class (chess-aware, DOM-agnostic) drives a Tabia game forward on a timer via goToNext; a <motif-play-button> web component wraps it with toggle UI. Companion <motif-speed-control> (interval slider or stepped) optionally slots onto the button as a popover/settings modal. Future flags as separate slots or options: loop-at-end, pause-on-annotated-moves, pause-on-variation. Same architectural pattern as the keybinder in step 1 — chess-aware UX helper + components that consume it.	autoplay was removed from Tabia core (a chess library shouldn’t own timers); apps need a drop-in replacement
5	<motif-position-setup> FEN validation — wire the board-editor component into Tabia’s validateFen (already used by <motif-fen-area>) so a user can’t commit a structurally-invalid position via Done. UX design TBD: block the commit with a specific error toast vs. warn-and-allow vs. inline highlight on the offending element (e.g., the rank with too many pieces). Currently the component emits whatever FEN it composes, even nonsense like no-kings or pawns-on-rank-1.	first consumer that wants robust position editing without trusting the user not to compose impossible positions

The order is “extract when there’s a consumer,” not “extract on schedule.” Many steps can be partially deferred.

Where data and rendering live

Motif owns visual + UX. It does not own:

• Game state, parsing, merge, or engine protocol → Tabia
• Board rendering → Rabbit
• App shell — modals, routing, persistence — consumer responsibility
• Generic UI primitives (filters, virtual lists, dropdowns, searchboxes) — consumer responsibility; Motif stays chess-specific

Non-goals

• Non-chess components. A generic dropdown is not Motif’s job.
• Framework wrappers. Components are Lit web components, framework- agnostic by virtue of being custom elements. No React adapter, no Vue plugin — pull <motif-move-list> into anything that speaks HTML.
• Chord shortcuts in the keymap (Cmd+X) — see KEYBOARD.md for the single-key-only rationale.