feat(slides): typed themes selectable per slide #26

New issue

Closed

opened 2026-04-16 13:44:51 +00:00 by casper-stevens · 0 comments

casper-stevens commented

2026-04-16 13:44:51 +00:00

Member

Context

Theme is a single freeform markdown block applied globally — there is no type, no reference images, and no way to select a different theme per slide without editing the slide file directly. Making theme a structured on-disk resource with a type and reference images enables reusable visual identities, per-slide selection, and auto-assignment based on slide role. See ADR-0004 for the on-disk format decision.

Goals

Theme resource: themes/<name>/theme.toml with fields name, type (intro | outro | stats | content | generic), description, tags; sibling image files treated as style reference images
Slide front-matter field theme: "<name>" selects a theme; no theme text embedded in the slide file
Auto-assign rule: first slide → intro type if one exists, last → outro, remainder → content or generic
Generator passes description as style guidance and ref images as style-only multimodal refs (not reproduced — style cues only)
UI: theme picker on slide edit screen; theme management tab for create/edit/delete

Feasibility

Medium-to-high complexity. The on-disk format and discovery are low-risk, but the theme.md stack is deeply embedded and the replacement is a meaningful refactor, not just an addition.

Code to remove / replace:

deck_get_theme() and deck_save_theme() in deck.rs — the read/write API for theme.md is replaced by structured TOML loading/saving
parse_theme() call in deck.rs — replaced by serde deserialization of theme.toml
Theme.raw_content field used in generator.rs:302 as freeform prompt text — replaced by the structured description field; the prompt injection point changes but does not grow
default_theme() string function in parser.rs — replaced by seeding a default themes/default/theme.toml on deck creation
create_deck() in deck.rs:394 currently writes theme.md — changes to create the themes/ directory and default TOML
theme_hash tracking in metadata.toml needs to target the TOML file instead of theme.md

Migration path is required: decks with an existing theme.md must either be auto-migrated (read theme.md, write themes/default/theme.toml from its content, delete theme.md) or supported via a legacy fallback read path. Recommend auto-migration on first scan.

The UI (theme picker + management tab) is additive and follows existing background panel patterns — lower risk than the backend refactor.

## Context Theme is a single freeform markdown block applied globally — there is no type, no reference images, and no way to select a different theme per slide without editing the slide file directly. Making theme a structured on-disk resource with a type and reference images enables reusable visual identities, per-slide selection, and auto-assignment based on slide role. See ADR-0004 for the on-disk format decision. ## Goals - Theme resource: `themes/<name>/theme.toml` with fields `name`, `type` (`intro | outro | stats | content | generic`), `description`, `tags`; sibling image files treated as style reference images - Slide front-matter field `theme: "<name>"` selects a theme; no theme text embedded in the slide file - Auto-assign rule: first slide → `intro` type if one exists, last → `outro`, remainder → `content` or `generic` - Generator passes `description` as style guidance and ref images as style-only multimodal refs (not reproduced — style cues only) - UI: theme picker on slide edit screen; theme management tab for create/edit/delete ## Feasibility Medium-to-high complexity. The on-disk format and discovery are low-risk, but the `theme.md` stack is deeply embedded and the replacement is a meaningful refactor, not just an addition. Code to remove / replace: - `deck_get_theme()` and `deck_save_theme()` in `deck.rs` — the read/write API for `theme.md` is replaced by structured TOML loading/saving - `parse_theme()` call in `deck.rs` — replaced by `serde` deserialization of `theme.toml` - `Theme.raw_content` field used in `generator.rs:302` as freeform prompt text — replaced by the structured `description` field; the prompt injection point changes but does not grow - `default_theme()` string function in `parser.rs` — replaced by seeding a default `themes/default/theme.toml` on deck creation - `create_deck()` in `deck.rs:394` currently writes `theme.md` — changes to create the `themes/` directory and default TOML - `theme_hash` tracking in `metadata.toml` needs to target the TOML file instead of `theme.md` Migration path is required: decks with an existing `theme.md` must either be auto-migrated (read `theme.md`, write `themes/default/theme.toml` from its content, delete `theme.md`) or supported via a legacy fallback read path. Recommend auto-migration on first scan. The UI (theme picker + management tab) is additive and follows existing background panel patterns — lower risk than the backend refactor.