@open-slide/core 1.1.0 → 1.3.0

package/dist/{types-DYgVpIGo.d.ts → types-JYG1cmwC.d.ts}

@@ -38,6 +38,7 @@ type Locale = {
   home: {
     appTitle: string;
     draft: string;
+    themes: string;
     folders: string;
     newFolder: string;
     folderName: string;
@@ -52,7 +53,6 @@ type Locale = {
     nothingMatchesSuffix: string;
     noSlidesYet: string;
     createSlideHintPrefix: string;
-    createSlideHintMid: string;
     createSlideHintSuffix: string;
     folderEmptyTitle: string;
     folderEmptyHint: string;
@@ -85,6 +85,10 @@ type Locale = {
   slide: {
     home: string;
     backToHome: string;
+    agentConnected: string;
+    agentConnectedTooltip: string;
+    agentDisconnected: string;
+    agentDisconnectedTooltip: string;
     download: string;
     exportAsHtml: string;
     exportAsPdf: string;
@@ -157,6 +161,10 @@ type Locale = {
   inspector: {
     inspect: string;
     deselect: string;
+    agentWatching: string;
+    agentWatchingTooltip: string;
+    agentNotWatching: string;
+    agentNotWatchingTooltip: string;
     contentSection: string;
     typographySection: string;
     colorSection: string;
@@ -194,10 +202,10 @@ type Locale = {
     cropFitContain: string;
     cropApply: string;
     cropResetAria: string;
-    noteForAgent: string;
-    noteAgentPlaceholder: string;
-    noteShortcutHint: string;
-    addNote: string;
+    leaveComment: string;
+    commentPlaceholder: string;
+    commentShortcutHint: string;
+    addComment: string;
     /** templates: "{count} unsaved change" / "{count} unsaved changes" */
     unsavedChanges: Plural;
     /** templates: "{count} comment" / "{count} comments" */
@@ -300,6 +308,17 @@ type Locale = {
     pages: string;
     /** template: "Go to page {n}" */
     goToPageAria: string;
+    duplicatePage: string;
+    deletePage: string;
+    /** template: "Page {n} actions" */
+    pageActionsAria: string;
+    /** template: "Duplicated page {n}" */
+    toastDuplicated: string;
+    /** template: "Deleted page {n}" */
+    toastDeleted: string;
+    toastDuplicateFailed: string;
+    toastDeleteFailed: string;
+    resizeRail: string;
   };
   pdfToast: {
     title: string;
@@ -319,5 +338,40 @@ type Locale = {
     prevAria: string;
     nextAria: string;
   };
+  imagePlaceholder: {
+    dropOverlay: string;
+    uploading: string;
+    uploadFailed: string;
+  };
+  notesDrawer: {
+    toggle: string;
+    /** template: "page {n}/{total}" */
+    pageLabel: string;
+    placeholder: string;
+    statusSaving: string;
+    statusSaved: string;
+    /** template: "Save failed: {msg}" */
+    statusError: string;
+  };
+  themes: {
+    title: string;
+    noThemesTitle: string;
+    noThemesHintPrefix: string;
+    noThemesHintSuffix: string;
+    noDemoYet: string;
+    noDemoHintPrefix: string;
+    noDemoHintSuffix: string;
+    backToGallery: string;
+    /** template: "page {n}/{total}" */
+    pageOf: string;
+    nextPageAria: string;
+    prevPageAria: string;
+    /** template: "Open theme {name}" */
+    openThemeAria: string;
+    usedBy: string;
+    usedByEmpty: string;
+    expandPromptAria: string;
+    collapsePromptAria: string;
+  };
 }; //#endregion
 export { Locale, Plural };

package/dist/vite/index.d.ts

@@ -1,5 +1,5 @@
-import "../types-DYgVpIGo.js";
-import { OpenSlideConfig } from "../config-C7vMYzFD.js";
+import "../types-JYG1cmwC.js";
+import { OpenSlideConfig } from "../config-D9cZ1A0X.js";
 import { InlineConfig } from "vite";
 
 //#region src/vite/config.d.ts

package/dist/vite/index.js

@@ -1,4 +1,4 @@
-import "../design-C13iz9_4.js";
-import { createViteConfig } from "../config-KdiYeWtK.js";
+import "../design-cpzS8aud.js";
+import { createViteConfig } from "../config-BAwKWNtW.js";
 
 export { createViteConfig };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@open-slide/core",
-  "version": "1.1.0",
+  "version": "1.3.0",
   "description": "Runtime and CLI for open-slide — write slides in slides/, we handle the rest.",
   "type": "module",
   "exports": {
@@ -42,11 +42,19 @@
     "vite"
   ],
   "license": "MIT",
+  "author": {
+    "name": "1weiho",
+    "url": "https://github.com/1weiho"
+  },
+  "homepage": "https://open-slide.dev",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/1weiho/open-slide.git",
     "directory": "packages/core"
   },
+  "bugs": {
+    "url": "https://github.com/1weiho/open-slide/issues"
+  },
   "publishConfig": {
     "access": "public"
   },

package/skills/create-slide/SKILL.md

@@ -13,7 +13,7 @@ You only write files under `slides/<id>/`. Never modify `package.json`, `open-sl
 
 List files under `themes/`. If any theme markdown files exist (anything other than `README.md`), call `AskUserQuestion` with each theme id as an option plus a final **"no theme — design from scratch"** option.
 
-- If the user picks a theme: read `themes/<id>.md` end-to-end. The theme's palette, typography, layout, and Title/Footer components are now authoritative — copy them directly into the slide. In Step 2, skip the **aesthetic direction** question (the theme already commits to one direction); you still need the topic itself, so confirm it before moving on. Page count, text density, and motion are independent of theme — ask those normally.
+- If the user picks a theme: read `themes/<id>.md` end-to-end. The theme's palette, typography, layout, and Title/Footer components are now authoritative — copy them directly into the slide. **Also set `theme: '<theme-id>'` on the `meta` export in `index.tsx`** (e.g. `export const meta: SlideMeta = { title: '…', theme: '<theme-id>' };`) so the slide back-links to the theme (chip on the slide card + listing on `/themes/<id>`). In Step 2, skip the **aesthetic direction** question (the theme already commits to one direction); you still need the topic itself, so confirm it before moving on. Page count, text density, and motion are independent of theme — ask those normally.
 - If the user picks "no theme", or `themes/` is empty (or contains only `README.md`): proceed to Step 2 unchanged.
 
 If you skip the aesthetic question because a theme was picked, restate the theme name in Step 2 so the user can correct course before you start writing.

package/skills/create-theme/SKILL.md

@@ -1,15 +1,20 @@
 ---
 name: create-theme
-description: Use this skill when the user wants to create, draft, author, or extract a slide theme in this open-slide repo. Triggers on phrases like "create a theme", "make a theme called X", "extract a theme from <slide>", "build a theme from these images". Produces a single markdown file under `themes/<id>.md` describing palette, typography, layout, fixed Title/Footer components, and motion philosophy. Do NOT use for editing slides themselves — only for authoring `themes/<id>.md`.
+description: Use this skill when the user wants to create, draft, author, or extract a slide theme in this open-slide repo. Triggers on phrases like "create a theme", "make a theme called X", "extract a theme from <slide>", "build a theme from these images". Produces two paired files under `themes/`: `<id>.md` (palette, typography, layout, fixed Title/Footer components, motion) and `<id>.demo.tsx` (a runnable demo slide that the dev-UI Themes panel previews). Do NOT use for editing real slides — only for authoring the theme bundle.
 ---
 
 # Create a slide theme
 
-This skill produces one markdown file under `themes/<id>.md` that describes a reusable visual identity for slides — palette, typography, layout, fixed Title/Footer/Eyebrow components, motion. Themes are agent-facing documentation, not executable runtime: a slide author reads the theme markdown and applies it when writing `slides/<id>/index.tsx`.
+This skill produces a **theme bundle** under `themes/`: two paired files that together describe a reusable visual identity.
 
-A theme is **distinct from a slide's `design` const**. The theme markdown is authoring-time aesthetic direction (read by `create-slide`, copied into slide source). A per-slide `const design: DesignSystem = { … }` (declared at the top of `slides/<id>/index.tsx`) is the runtime tokens object the user can tweak from the Design panel in the dev UI. Both can coexist: the markdown theme commits the *direction*, the per-slide `design` const makes the slide *tweakable*. This skill only writes the markdown.
+1. `themes/<id>.md` — agent-facing documentation: palette, typography, layout, fixed Title/Footer/Eyebrow components, motion. This is what `create-slide` reads when an author picks the theme.
+2. `themes/<id>.demo.tsx` — a runnable mini-slide (a normal slide module: `export default Page[]`) that demonstrates the theme on 2–3 pages. The dev UI's **Themes panel** loads this file and renders it as the theme's live preview.
 
-You only write a single file under `themes/`. Never modify slides or other configuration. The canvas / type-scale defaults that themes can override live in the **`slide-authoring`** skill — read it before writing the theme so your overrides are stated explicitly.
+Both files share the same stem so the runtime can pair them automatically.
+
+A theme is **distinct from a slide's `design` const**. The theme markdown is authoring-time aesthetic direction (copied into a real slide's source by `create-slide`). The demo `.tsx` is a self-contained preview, not a real slide — it does not appear in the slides list. A per-slide `const design: DesignSystem = { … }` (declared at the top of `slides/<id>/index.tsx`) is the runtime tokens object the user can tweak from the Design panel. The markdown commits the *direction*; the per-slide `design` const makes the slide *tweakable*; the demo `.tsx` makes the theme *previewable*.
+
+You only write files under `themes/<id>.md` and `themes/<id>.demo.tsx`. Never modify real slides or other configuration. The canvas / type-scale defaults that themes can override live in the **`slide-authoring`** skill — read it before writing the theme so your overrides are stated explicitly.
 
 ## Step 1 — Identify the input source
 
@@ -47,7 +52,6 @@ Produce a file with this exact section order. Section bodies adapt to the theme;
 ---
 name: <Human title, e.g. "Editorial Noir">
 description: <one-line elevator pitch>
-mode: light | dark | system
 ---
 
 # <Theme name>
@@ -163,6 +167,46 @@ const Cover: Page = () => (
 ```
 ````
 
+## Step 4b — Write `themes/<id>.demo.tsx`
+
+The demo is a normal slide module — same shape as `slides/<id>/index.tsx`, just sitting under `themes/` so the runtime knows it's preview-only. The dev-UI Themes panel imports it and renders it inside `SlideCanvas` (1920×1080).
+
+Contract:
+
+- `import type { Page } from '@open-slide/core';`
+- Inline the **same** `Title`, `Footer`, `Eyebrow` components defined in the theme markdown — verbatim, no abstractions, no imports from elsewhere. The demo and the markdown must stay in lockstep so what the user sees in the panel matches what `create-slide` will paste into a real slide.
+- Export 2–3 `Page` components and a default array. Aim for: a Cover (Eyebrow + Title + subtitle), one Content page exercising body type + accent, and a Closer or "End" card. The "Example usage" block at the bottom of the markdown is a good starting point — extend it.
+- If the theme has runtime-tweakable tokens worth surfacing in the Design panel later, also `export const design: DesignSystem = {...}`.
+- No external assets, no `import` from `@/`, no slides-only helpers (e.g. `WindowShell` from a real slide). Demo files must be self-contained.
+
+Skeleton:
+
+```tsx
+import type { Page } from '@open-slide/core';
+
+const Title = ({ children }: { children: React.ReactNode }) => (
+  // …same JSX as in themes/<id>.md
+);
+const Footer = ({ pageNum, total }: { pageNum: number; total: number }) => (
+  // …
+);
+const Eyebrow = ({ children }: { children: React.ReactNode }) => (
+  // …
+);
+
+const Cover: Page = () => (
+  // …
+);
+const Content: Page = () => (
+  // …
+);
+const Closer: Page = () => (
+  // …
+);
+
+export default [Cover, Content, Closer];
+```
+
 ## Step 5 — Self-review
 
 Run this checklist before finishing:
@@ -172,23 +216,27 @@ Run this checklist before finishing:
 - [ ] At least Title and Footer are defined as paste-ready React with concrete inline styles.
 - [ ] Motion section commits to one of static / subtle / rich.
 - [ ] Aesthetic paragraph names a single coherent direction.
-- [ ] File lives at `themes/<id>.md` and only that file was created — no slide changes, no config changes.
-- [ ] Frontmatter `mode` is one of `light`, `dark`, `system`.
+- [ ] Both files written: `themes/<id>.md` and `themes/<id>.demo.tsx`. No slide changes, no config changes.
+- [ ] Demo `.tsx` exports 2–3 pages and inlines the same Title/Footer/Eyebrow components defined in the markdown.
+- [ ] Demo opens cleanly in the **Themes** panel of the dev UI — re-checked by you only by reading the file (do not start a server).
 
 ## Step 6 — Hand off
 
 Tell the user:
 
-- The theme id and file path.
-- That `/create-slide` will list it as a picker option on its next run.
+- The theme id and the two file paths (`themes/<id>.md` + `themes/<id>.demo.tsx`).
+- That the demo will appear in the dev UI's **Themes** panel as a live card and detail view (HMR — no restart needed).
+- That `/create-slide` will list the theme as a picker option on its next run.
 - A one-line summary of the look (palette + aesthetic).
 
-Do not run the dev server. Do not modify slides — even to demonstrate the theme; that is the user's next move.
+Do not run the dev server. Do not modify real slides — even to demonstrate the theme; the demo `.tsx` is the demonstration.
 
 ## Anti-patterns
 
-- ❌ Writing executable code in `themes/<id>.md` outside the labeled component snippets — the file is documentation.
-- ❌ Producing more than one file. One theme = one `themes/<id>.md`.
+- ❌ Writing executable code in `themes/<id>.md` outside the labeled component snippets — the markdown is documentation.
+- ❌ Producing only the markdown without the demo, or only the demo without the markdown. A theme is the **bundle** — both files, every time.
+- ❌ Treating `themes/<id>.demo.tsx` as a real slide. It is preview-only and lives outside the slides list; never put it under `slides/`.
+- ❌ Importing from `@/` or any slide-specific helper inside the demo. The demo is self-contained.
 - ❌ Inventing palette / fonts when the user supplied images or an existing slide. Extract, don't fabricate.
 - ❌ Editing `slides/`, `packages/`, `package.json`, or `open-slide.config.ts`.
 - ❌ Skipping the Fixed components section. Title and Footer are the most common reuse target — they must be paste-ready.

package/skills/current-slide/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: current-slide
+description: Resolve which slide, page, and (optionally) selected element the user is currently viewing in the open-slide dev server. Consult this whenever the user references "this page", "this slide", "this element", "the slide I'm on", "the current page", or any deictic reference to slide content without naming it. Re-read `node_modules/.open-slide/current.json` at the start of every such turn — the user navigates between turns, so a value you read earlier in the conversation is almost certainly stale.
+---
+
+# Where is the user right now?
+
+When the user says "fix this page", "tweak this heading", or "the slide I'm looking at", they almost never name the slide id, page number, or element — they mean wherever they are in the dev viewer. Before asking "which slide?" or "which element?", check the file the dev server writes on every navigation and inspector pick.
+
+## Re-read on every deictic turn — never reuse a prior read
+
+`current.json` is a live cursor, not a fact about the conversation. The user moves between slides, pages, and elements freely between your turns — including while you were doing other work. **Read the file fresh at the start of every new turn that uses a deictic reference**, even if:
+
+- you already read it earlier in this same conversation,
+- you just finished editing the slide it pointed to,
+- the user's new message sounds like a continuation ("now make it bigger", "also fix this one", "keep going").
+
+A "continue editing" follow-up is exactly the case where the user has likely just navigated to a different slide or picked a different element. Trusting your last read here will silently edit the wrong file. Re-read, compare `slideId` / `pageIndex` / `selection` against what you used last time, and act on the new values.
+
+## How to read it
+
+```
+node_modules/.open-slide/current.json
+```
+
+Path is relative to the project root (the user's `cwd`, the directory that contains `slides/` and `package.json`). Use the `Read` tool. The file is JSON.
+
+## What you get
+
+```json
+{
+  "slideId": "q2-roadmap",
+  "pageIndex": 2,
+  "pageNumber": 3,
+  "totalPages": 8,
+  "slideTitle": "Q2 Roadmap",
+  "view": "slides",
+  "pagePath": "slides/q2-roadmap/index.tsx",
+  "selection": {
+    "line": 42,
+    "column": 6,
+    "tagName": "h1",
+    "text": "Q2 Roadmap"
+  },
+  "updatedAt": "2026-05-09T14:32:11.123Z"
+}
+```
+
+- `slideId` — folder name under `slides/`. Use as-is for any `/__slides/<id>/...` API or as the URL segment.
+- `pageIndex` — 0-based, for use with the page array in `index.tsx` (`export default [Cover, Body, ...]`).
+- `pageNumber` — 1-based, for use in messages to the user ("page 3 of 8") and for the URL `?p=N`.
+- `pagePath` — relative path to the slide source. Hand straight to `Read` / `Edit`.
+- `view` — `"slides"` (canvas view) or `"assets"` (asset manager). If `"assets"`, the user is browsing files for that slide rather than viewing a page.
+- `selection` — `null` if nothing is selected. Otherwise, the JSX element the user picked in the inspector overlay:
+  - `line` (1-indexed) and `column` (0-indexed) point to the JSX opening tag inside `pagePath`. This is the canonical handle — match against the source line, not the rendered DOM.
+  - `tagName` is the rendered DOM tag, lowercased (`"h1"`, `"div"`, `"img"`).
+  - `text` is a trimmed text snippet (≤120 chars) from the element's `textContent`, useful as a sanity check that you're looking at the right node.
+  - Selection auto-clears whenever the user navigates to a different slide or page.
+- `updatedAt` — ISO timestamp of the last navigation or selection change. Use it to detect staleness.
+
+## When to use this
+
+- The user references the current slide/page deictically: "this", "here", "the page I'm on", "the slide I'm looking at", "what I'm working on".
+- The user references a specific element: "this heading", "this image", "the button I just clicked", "tighten this", "change the color of this". If `selection` is non-null, that's the element they mean.
+- Before asking "which slide?" or "which element?" as a clarifying question — check this file first.
+- Before guessing from `git log`, recently-edited files, or the most recent slide folder.
+
+## When NOT to use this
+
+- The user names a slide explicitly ("edit `q2-roadmap`") — use that name directly.
+- The `apply-comments` workflow already finds the right file via `@slide-comment` markers; it doesn't need this skill.
+- For listing or discovering slides — read `slides/` directly.
+
+## Staleness — verify before acting
+
+`updatedAt` is the last time the user navigated. Treat it like a cache:
+
+- **Fresh (under ~5 minutes old)**: trust it. Open `pagePath`, do the work.
+- **Older than ~5 minutes, or older than your last interaction with the user**: confirm with the user before editing. The dev server may not be running; the user may have switched contexts.
+- **Hours/days old**: ignore it. Ask the user which slide they mean.
+
+A *newer* `updatedAt` than the one you saw last turn is the normal signal that the user has moved — switch to the new `slideId` / `pageIndex` / `selection` without asking.
+
+## When the file is missing
+
+- The dev server hasn't been opened on a slide yet, or has never run.
+- Don't create the file or guess. Ask the user which slide they mean, or suggest they open the slide in the dev server first.
+
+## Example — page-level reference
+
+User: "tighten the spacing on this page"
+
+1. Read `node_modules/.open-slide/current.json`.
+2. Check `updatedAt` is recent.
+3. Read `pagePath` (e.g. `slides/q2-roadmap/index.tsx`).
+4. Identify the page at `pageIndex` in the default-exported array.
+5. Consult the `slide-authoring` skill for spacing rules, then edit that page in place.
+
+If `current.json` is missing or stale, ask: "Which slide and page should I tighten? The dev server hasn't published a current page recently."
+
+## Example — element-level reference
+
+User: "make this bigger"
+
+1. Read `node_modules/.open-slide/current.json`.
+2. If `selection` is non-null, the user means that element. Read `pagePath`, jump to `selection.line`, and find the JSX opening tag near that line/column. Confirm with the snippet in `selection.text` and the `tagName`.
+3. Consult `slide-authoring` for type-scale and layout rules before editing.
+4. Edit the JSX node in place.
+
+If `selection` is null, fall back to the page-level flow above — and consider asking "which element?" since the user used a deictic but hasn't picked one in the inspector.

package/skills/slide-authoring/SKILL.md

@@ -9,6 +9,7 @@ This skill is the **technical reference** for everything that happens inside `sl
 
 - `create-slide` owns "draft a new deck" — it asks the user scoping questions, then delegates the *how* to this skill.
 - `apply-comments` owns "process inspector markers" — it finds markers and applies edits, but the edits themselves follow the rules here.
+- `current-slide` resolves deictic references ("this page", "the slide I'm on") to a concrete `slideId` + `pageIndex`. Consult it **first** when the user references the current slide without naming it, then come back here for how to edit it.
 - Any ad-hoc slide edit (manual tweak, one-off fix) should also consult this skill before touching the file.
 
 When any of those paths reach the point of *writing React code for a page*, this is the source of truth. Do not duplicate the knowledge below into other skills — link here instead.
@@ -19,7 +20,7 @@ When any of those paths reach the point of *writing React code for a page*, this
 - Entry is `slides/<id>/index.tsx`. Images/videos/fonts go under `slides/<id>/assets/`.
 - Do **not** touch `package.json`, `open-slide.config.ts`, or other slides.
 - Do not add dependencies. Only `react` and standard web APIs are available.
-- Do not create `README.md` or other prose files inside the slide folder — just `index.tsx` + `assets/`.
+- A slide is **one `index.tsx` plus `assets/`** — nothing else. Do not create sibling `.tsx`/`.ts` files (`Card.tsx`, `components/`, `helpers.ts`, etc.); helper components and constants go inside `index.tsx`. Do not create `README.md` or other prose files either.
 
 ## File contract
 
@@ -37,6 +38,17 @@ export default [Cover, Body] satisfies Page[];
 - `export default` is a **non-empty array of zero-prop React components**, one per page, in order.
 - `meta.title` (optional) shows in the slide header. Default is the folder name.
 - The slide id is the kebab-case folder name. Pick something short and descriptive (`q2-roadmap`, `team-offsite-2026`).
+- `meta.theme` (optional) marks the slide as built from a theme under `themes/`. The id must match a `<id>.md` basename. Surfaces a back-link chip on the slide card and lists the slide on `/themes/<id>`. Omit if the slide isn't derived from a registered theme.
+
+## Editing an existing slide
+
+A finished slide commonly runs 1000–1800 lines. When you only need to touch one page, **don't read the whole file** — locate the page first, then read just that range:
+
+```bash
+grep -n ": Page = " slides/<id>/index.tsx
+```
+
+This lists every `const Foo: Page = …` declaration with its line number. Read the target page with `Read` using `offset` + `limit` (~150 lines is usually enough to capture one page plus its helper components). Read the whole file only when you need cross-page context (palette audit, reordering, design const tweaks).
 
 ## Canvas
 
@@ -264,6 +276,50 @@ The user uploads the real file via the Assets panel, then clicks the placeholder
 
 Size the placeholder to the slot it occupies. Pass `width`/`height` when the layout has a fixed image box; omit them when the placeholder fills a flex/grid cell. The `hint` should describe the *content* the user needs ("Q3 revenue chart") not the *role* ("hero image").
 
+## Repeated elements: component, not `map`
+
+When a page has visually repeated items — cards, logo rows, gallery tiles, list rows, step indicators — **define a small component and instantiate it once per item**. Do **not** render the group with `array.map` over a data array.
+
+Define the component **in the same `index.tsx`**, alongside the `Page` components. Never split it into a sibling file like `Card.tsx` — a slide is always a single `index.tsx` plus its `assets/`.
+
+```tsx
+// ✅ Each card is its own JSX node — inspector edits one at a time.
+const Card = ({ src, label }: { src: string; label: string }) => (
+  <div style={{ display: 'flex', flexDirection: 'column', gap: 16 }}>
+    <img src={src} style={{ width: 320, height: 320, objectFit: 'cover', borderRadius: 12 }} />
+    <p style={{ fontSize: 32 }}>{label}</p>
+  </div>
+);
+
+<div style={{ display: 'grid', gridTemplateColumns: 'repeat(3, 1fr)', gap: 64 }}>
+  <Card src={alpha} label="Alpha" />
+  <Card src={beta}  label="Beta"  />
+  <Card src={gamma} label="Gamma" />
+</div>
+```
+
+```tsx
+// ❌ One shared template — replacing the image or text in the inspector
+//    changes every rendered card at once.
+const items = [
+  { src: alpha, label: 'Alpha' },
+  { src: beta,  label: 'Beta'  },
+  { src: gamma, label: 'Gamma' },
+];
+items.map((item) => (
+  <div>
+    <img src={item.src} />
+    <p>{item.label}</p>
+  </div>
+));
+```
+
+The inspector edits source JSX in place. A `map` body is **one source location** shared by every rendered instance, so when the user replaces an image or tweaks a label there, every card mutates together. Explicit instances give each card its own JSX node and its own props — the unit the inspector can target.
+
+The component definition stays the single source of truth for layout/styling (change it once → all cards update). Only the per-instance data — `src`, `label`, accent color — lives at the call site.
+
+This applies whenever the *visual element* repeats, not whenever the *data* does. Pure-text lists (`<ul><li>` bullets) are fine: each `<li>` is already its own JSX node, so plain literal markup is the correct shape — no need to wrap them in a component.
+
 ## Runtime behavior you get for free
 
 - Home page lists every folder under `slides/`.
@@ -282,6 +338,7 @@ Size the placeholder to the slot it occupies. Pass `width`/`height` when the lay
 - [ ] One coherent visual direction across every page (palette + type scale).
 - [ ] Slide declares a top-level `export const design: DesignSystem = { … }` and references the values via `var(--osd-X)` (use `design.X` only when you need a JS number for arithmetic). Only omit the `design` const for a one-off slide whose palette is intentionally locked.
 - [ ] One idea per page.
+- [ ] Visually repeated elements (cards, tiles, logo rows) are rendered as explicit `<Component />` instances, not via `array.map` over a data list.
 - [ ] All imported assets exist on disk under `slides/<id>/assets/`.
 - [ ] Every `<ImagePlaceholder>` corresponds to a real image the user must supply — not decorative filler. If it could be replaced by typography or layout, it should be.
 - [ ] Nothing outside `slides/<id>/` was edited.
@@ -302,3 +359,4 @@ Size the placeholder to the slot it occupies. Pass `width`/`height` when the lay
 - ❌ Editing `package.json`, `open-slide.config.ts`, or other slides.
 - ❌ Sprinkling `<ImagePlaceholder>` across pages "for visual interest". Placeholders are for content the user owns; they're not stock-photo slots.
 - ❌ Using a placeholder for an icon or decorative shape — those are typography/SVG problems, not asset problems.
+- ❌ Rendering visually repeated elements with `array.map(...)` over a data array. Define a component and instantiate it explicitly per item (`<Card />`, `<Card />`, `<Card />`) so the inspector can edit each independently — a shared `map` body mutates every instance at once.

package/src/app/app.tsx

@@ -3,14 +3,24 @@ import { BrowserRouter, Route, Routes } from 'react-router-dom';
 import { Toaster } from './components/ui/sonner';
 import { useLocale } from './lib/use-locale';
 import { Home } from './routes/home';
+import { HomeShell } from './routes/home-shell';
 import { Presenter } from './routes/presenter';
 import { Slide } from './routes/slide';
+import { ThemeDetailPage, ThemesGalleryPage } from './routes/themes';
 
 export function App() {
   return (
     <BrowserRouter>
       <Routes>
-        <Route path="/" element={config.build.showSlideBrowser ? <Home /> : <NotFound />} />
+        {config.build.showSlideBrowser ? (
+          <Route element={<HomeShell />}>
+            <Route path="/" element={<Home />} />
+            <Route path="/themes" element={<ThemesGalleryPage />} />
+            <Route path="/themes/:themeId" element={<ThemeDetailPage />} />
+          </Route>
+        ) : (
+          <Route path="/" element={<NotFound />} />
+        )}
         <Route path="/s/:slideId" element={<Slide />} />
         <Route path="/s/:slideId/presenter" element={<Presenter />} />
         <Route path="*" element={<NotFound />} />

package/src/app/components/asset-view.tsx

@@ -33,6 +33,7 @@ import {
 import {
   type AssetEntry,
   fetchSvgAsFile,
+  renamedCopy,
   type SvglItem,
   searchSvgl,
   useAssets,
@@ -315,19 +316,6 @@ function hasFiles(e: React.DragEvent): boolean {
   return false;
 }
 
-function renamedCopy(file: File, taken: Set<string>): File {
-  const dot = file.name.lastIndexOf('.');
-  const stem = dot > 0 ? file.name.slice(0, dot) : file.name;
-  const ext = dot > 0 ? file.name.slice(dot) : '';
-  let i = 1;
-  let next = `${stem}-${i}${ext}`;
-  while (taken.has(next)) {
-    i += 1;
-    next = `${stem}-${i}${ext}`;
-  }
-  return new File([file], next, { type: file.type, lastModified: file.lastModified });
-}
-
 function AssetCard({
   asset,
   onPreview,