slidemind 0.2.1 → 0.2.2

package/.agents/plugins/marketplace.json

@@ -0,0 +1,29 @@
+{
+  "name": "slidemind",
+  "interface": {
+    "displayName": "slidemind",
+    "shortDescription": "On-brand PowerPoint decks from your coding agent",
+    "longDescription": "slidemind connects Codex to the slidemind PowerPoint add-in over its local bridge, so the agent can build and edit native .pptx decks against whatever corporate design the add-in has active. It is brand-agnostic: the corporate design, the layout palette, and the OOXML render all live in the add-in, and the agent reads every brand rule from the design bundle it serves. This marketplace publishes the slidemind plugin, which carries the authoring and search skills. The slidemind CLI itself is installed separately from public npm (npm install -g slidemind); the skills explain that step when the command is missing."
+  },
+  "plugins": [
+    {
+      "name": "slidemind",
+      "description": "Build and edit native, on-brand PowerPoint decks against the active corporate design.",
+      "source": {
+        "source": "local",
+        "path": "./"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity",
+      "interface": {
+        "displayName": "slidemind",
+        "shortDescription": "On-brand PowerPoint decks from Codex",
+        "developerName": "statworx",
+        "longDescription": "Adds two skills. slidemind-create-slides owns the intake, plan, create and edit workflow that turns per-slide sources into an editable .pptx rendered by the add-in, plus a local HTML preview. slidemind-search discovers and reuses existing slides and brand imagery from the corporate design's engines, or from a PowerPoint file on disk. Both are brand-agnostic and read the active corporate design's rules, layout palette, and authoring workflow from the design bundle the add-in serves. Requires the slidemind CLI (npm install -g slidemind) and an open PowerPoint with the add-in for anything that renders or reads a live deck."
+      }
+    }
+  ]
+}

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "slidemind",
-  "version": "0.2.1",
+  "version": "0.2.2",
   "description": "Connect Claude Code to the slidemind PowerPoint add-in — build and edit native, on-brand PowerPoint decks against the active corporate design, from the terminal.",
   "author": {
     "name": "statworx",

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "slidemind",
-  "version": "0.2.1",
+  "version": "0.2.2",
   "description": "Connect Codex to the slidemind PowerPoint add-in — build and edit native, on-brand PowerPoint decks against the active corporate design. Requires the slidemind CLI (npm install -g slidemind); the skills explain the install when it is missing.",
   "author": {
     "name": "statworx",
@@ -20,6 +20,7 @@
   "interface": {
     "displayName": "slidemind",
     "shortDescription": "On-brand PowerPoint decks from Codex",
+    "longDescription": "Adds two skills. slidemind-create-slides owns the intake, plan, create and edit workflow that turns per-slide sources into an editable .pptx rendered by the add-in, plus a local HTML preview. slidemind-search discovers and reuses existing slides and brand imagery from the corporate design's engines, or from a PowerPoint file on disk. Both are brand-agnostic and read the active corporate design's rules, layout palette, and authoring workflow from the design bundle the add-in serves. Requires the slidemind CLI (npm install -g slidemind) and an open PowerPoint with the add-in for anything that renders or reads a live deck.",
     "developerName": "statworx",
     "category": "Productivity",
     "capabilities": [

package/{CLAUDE.md → AGENTS.md}

@@ -1,6 +1,6 @@
-# CLAUDE.md
+# AGENTS.md
 
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
+Guidance for coding agents working in this repository. `CLAUDE.md` is a symlink to this file — there is ONE guidance document, so edit it here and every harness sees the change. (It used to be two near-identical files kept in sync by hand, which drifted.)
 
 ## Project purpose
 
@@ -24,12 +24,19 @@ npm install -g slidemind
 slidemind init --for all          # claude | codex | opencode | all | none
 ```
 
-`npx slidemind <command>` runs it without a global install. `slidemind update` is a thin wrapper over `npm install -g slidemind@latest` (`--ref <version>` to pin, `--for <target>` to control the redeploy). The `files` whitelist in `package.json` controls what ships (`bin/ src/ skills/ .claude-plugin/ .codex-plugin/ CLAUDE.md README.md`); `archive/`, `docs/`, `scripts/`, `test/`, and `.agents/` are excluded.
+`npx slidemind <command>` runs it without a global install. `slidemind update` is a thin wrapper over `npm install -g slidemind@latest` (`--ref <version>` to pin, `--for <target>` to control the redeploy). The `files` whitelist in `package.json` controls what ships (`bin/ src/ skills/ .claude-plugin/ .codex-plugin/ .agents/plugins/ AGENTS.md README.md`); `archive/`, `docs/`, `scripts/`, and `test/` are excluded. Two traps live in that list:
+
+- `.agents/plugins/`, **not** `.agents/` — `files` globs the filesystem rather than git, and `.agents/` also holds gitignored per-developer harness scratch that a bare entry would publish.
+- `AGENTS.md`, **not** `CLAUDE.md` — `CLAUDE.md` is a symlink and **npm silently drops symlinks from the tarball**, so listing it would ship nothing at all. The repo keeps the symlink for local harness convenience; the package ships the real `AGENTS.md`.
+
+A packaging test guards both.
 
 Both agent harnesses can also install slidemind as a **plugin** — this private repo doubles as the marketplace (a public marketplace repo can be split out later; the files move as-is). The marketplace is named `slidemind`, NOT `statworx`: the team already registers a `statworx` marketplace from `STATWORX/intern-marketplace-test`, and both harnesses allow only one marketplace per name.
 
-- **Claude Code** (one step, no `npm -g`): `/plugin marketplace add STATWORX/intern-slidemind-cli` → `/plugin install slidemind@slidemind`. The marketplace entry (`.claude-plugin/marketplace.json`) points at the **public npm package, unpinned** — Claude installs the latest tarball and the installed version comes from the tarball's `.claude-plugin/plugin.json`, so only the marketplace add needs repo access. The tarball's `bin/slidemind` + `bin/slidemind.cmd` shims land on PATH inside plugin sessions, so the plugin carries the CLI too.
-- **Codex**: `codex plugin marketplace add STATWORX/intern-slidemind-cli` → `codex plugin add slidemind@slidemind`. Codex clones the repo (marketplace file `.agents/plugins/marketplace.json`; plugin manifest `.codex-plugin/plugin.json`; plugin source = repo root) and carries the skills only — the CLI still arrives via `npm install -g slidemind`, which the skills' remediation covers.
+- **Claude Code** (one step, no `npm -g`, **no GitHub account**): `/plugin marketplace add https://unpkg.com/slidemind/.claude-plugin/marketplace.json` → `/plugin install slidemind@slidemind`. A Claude marketplace source may be a plain HTTPS URL, and an npm CDN serves files straight out of the published tarball — which ships `.claude-plugin/marketplace.json`. So the marketplace needs no repo of its own and follows releases automatically (no version in the URL, no version pin in the plugin entry). `https://cdn.jsdelivr.net/npm/slidemind/.claude-plugin/marketplace.json` is the equivalent fallback. The tarball's `bin/slidemind` + `bin/slidemind.cmd` shims land on PATH inside plugin sessions, so the plugin carries the CLI too. (`/plugin marketplace add STATWORX/intern-slidemind-cli` also works but needs read access to this private repo — prefer the URL.)
+- **Codex**: a Codex marketplace source must be a **local path or a git remote** — no URL, no npm — so the CDN trick does NOT transfer. Instead the tarball ships `.agents/plugins/marketplace.json`, which makes the INSTALLED package a valid local marketplace: `npm install -g slidemind` → `codex plugin marketplace add "$(npm root -g)/slidemind"` → `codex plugin add slidemind@slidemind`. No GitHub account needed. (`codex plugin marketplace add STATWORX/intern-slidemind-cli` works for anyone with repo access.) Codex plugins cannot put a binary on PATH, so the CLI always comes from npm; the skills' remediation covers that.
+
+> The Codex **admin console** validates harder than the CLI does: it rejects an import when any `interface` block lacks a non-blank `longDescription`, which `codex plugin add` never complains about. `test/plugin-manifests.test.mjs` guards it.
 
 `slidemind init --for <target>` remains the universal fallback on all three harnesses; the Claude installer prints a dedup hint when it detects the plugin is also installed.
 
@@ -73,7 +80,7 @@ Teammates pick up the release with `npm install -g slidemind@latest` (or `slidem
 slidemind/
 ├── package.json                  npm package metadata, single bin: slidemind
 ├── README.md                     end-user quickstart
-├── CLAUDE.md                     this file
+├── AGENTS.md                     this file (CLAUDE.md is a symlink to it)
 ├── .claude-plugin/
 │   ├── plugin.json               Claude Code plugin manifest (version release-synced to package.json)
 │   └── marketplace.json          Claude Code marketplace — serves the plugin from public npm, unpinned
@@ -144,6 +151,24 @@ slidemind uninstall --for <target>   # remove the skill (also clears the bundle
 
 **The design truth lives in the add-in, not the CLI.** The `.pptx` is rendered server-side over the local bridge (no local exporter), the corporate design is fetched as a bundle, brand imagery comes from the add-in's engine, and slide reuse (extract / insert / splice) executes in the add-in too. So `create`/`build-pptx`/`push`/`ls engines`/`search`/`insert-slide`/`add-slide` all hard-require an **open PowerPoint host with the slidemind add-in and an active corporate design**. The engine-search + slide-reuse wire contract is in `docs/slidemind-cli-connect/11-engine-search-slide-reuse.md`; see `docs/slidemind-cli-connect/` for the rest.
 
+## External skill packs (this repo ships none)
+
+Some decks build from a **template pack** (`mode: "fill-template"` in the pack's `skill.json`) rather than from the design bundle. Those packs are distributed privately, on their own — as a harness plugin, an admin-pushed workspace skill, or a hand-installed directory. **This package must never carry, name, or hardcode anything from one.** No layout component names, no template file names, no master-fixed titles, no client names. `src/pptx/fill/` is generic machinery; every pack-specific fact is read from the pack:
+
+| Fact | Read from |
+|---|---|
+| semantic name → shape id | `fields.json` |
+| repeat groups | `repeats.json` |
+| immutable tables, hygiene deletions, freeform placeholders | `skill.json` `policy` |
+| layout component naming | `skill.json` `components` — `{ canonical, localized }`, regex sources; `canonical` group 1 is the slide number, `localized` group 1 the locale and group 2 the number |
+| template-fixed slide titles | `skill.json` `policy.fixedTitles` — `{ <locale>: [{ stem, title }] }`, `stem` a case-insensitive regex on the slide file stem |
+
+A pack that declares no `components.canonical` fails loudly in `layoutNumber()` — returning null instead would silently demote every master-backed slide to freeform and build a deck that quietly lost its template.
+
+Packs resolve through `locateSkillDir()` (`src/builders/resolve-skill.mjs`): `$SLIDEMIND_SKILLS_DIR/<name>` → `~/.config/slidemind/skills/<name>` → `<package>/skills/<name>` → the **harness** skill and plugin dirs (`~/.claude`, `~/.codex`, opencode; both `<name>` and `slidemind-<name>`). That last tier is what makes every distribution channel work — a plugin or admin upload lands the pack in a harness directory, never in ours — and it ranks *after* the package so this CLI's own skills are never shadowed by a stale copy.
+
+Pack-dependent integration tests belong in the pack's own repo, not here.
+
 ## Design system ground rules
 
 The corporate design is **served by the add-in, not shipped by the CLI.** `slidemind download-bundle` materializes it (keyed by the deck's `.bundle-ref.json`) into `${XDG_CACHE_HOME:-~/.cache}/slidemind/bundles/<presFP>/`:

package/README.md

@@ -135,16 +135,20 @@ npx slidemind <command>
 
 ### Install as a plugin (Claude Code / Codex)
 
-Both harnesses can install slidemind as a **plugin** from this repo's marketplace instead of the two-command npm flow. The repo is private, so the one-time `marketplace add` uses your existing GitHub credentials (`gh auth login`, a git credential helper, or SSH).
+Both harnesses can install slidemind as a **plugin** instead of the two-command npm flow.
 
-**Claude Code — fully self-contained (no `npm install -g` needed):**
+**Claude Code — fully self-contained (no `npm install -g`, no GitHub account):**
 
 ```
-/plugin marketplace add STATWORX/intern-slidemind-cli
+/plugin marketplace add https://unpkg.com/slidemind/.claude-plugin/marketplace.json
 /plugin install slidemind@slidemind
 ```
 
-The plugin ships both skills *and* the CLI: under the hood Claude Code installs the public npm package and puts `slidemind` on `PATH` inside its sessions (the headless-Chrome heads-up above applies to this install too). Outside Claude Code sessions the command is not on your `PATH` — add the global install if you also want to drive the CLI by hand. Updates ship with every release; apply them via `/plugin`. If background marketplace refreshes fail against the private repo, use SSH for the marketplace add or set `CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1`.
+The marketplace is served straight out of the published npm package — the tarball ships `.claude-plugin/marketplace.json`, and an npm CDN serves it over plain HTTPS. Nothing here needs repo access, and it follows releases automatically (no version in the URL, no version pin in the plugin entry). `https://cdn.jsdelivr.net/npm/slidemind/.claude-plugin/marketplace.json` works the same way.
+
+The plugin ships both skills *and* the CLI: Claude Code installs the public npm package and puts `slidemind` on `PATH` inside its sessions (the headless-Chrome heads-up above applies to this install too). Outside Claude Code sessions the command is not on your `PATH` — add the global install if you also want to drive the CLI by hand. Apply updates via `/plugin`.
+
+> `/plugin marketplace add STATWORX/intern-slidemind-cli` also works if you have read access to the repo, but the URL above is preferred — it needs no credentials. If background refreshes ever fail against the private repo, use SSH or set `CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1`.
 
 **Codex — skills via plugin, CLI via npm:**
 
@@ -153,7 +157,7 @@ codex plugin marketplace add STATWORX/intern-slidemind-cli
 codex plugin add slidemind@slidemind
 ```
 
-Codex plugins carry the skills only — the CLI still comes from `npm install -g slidemind` (the skills walk you through it if it's missing). `slidemind init --for codex` remains the most robust path; it additionally writes an `~/.codex/AGENTS.md` pointer.
+Codex plugins carry the skills only — the CLI still comes from `npm install -g slidemind` (the skills walk you through it if it's missing). Codex clones the repo for this, so it needs read access; without it, get the skills from your workspace's Codex admin skill upload and the CLI from npm. `slidemind init --for codex` remains the most robust path; it additionally writes an `~/.codex/AGENTS.md` pointer.
 
 > Already ran `slidemind init` and switching to a plugin? Drop the copied skills once with `slidemind uninstall --for claude` (or `--for codex`) so they don't duplicate the plugin's.
 

package/bin/slidemind.mjs

@@ -468,6 +468,13 @@ async function cmdBuildPptx(rest) {
       deckDir,
       locale: skill.locale ?? "en",
       srcDir: SRC_DIR,
+      // Both are the PACK's contract, read from its skill.json — this CLI
+      // knows no layout names and no template-fixed titles of its own.
+      components: {
+        ...(skill.manifest?.components ?? {}),
+        skillDir: skill.skillDir,
+      },
+      policy: skill.manifest?.policy ?? {},
       onLog: (line) => process.stdout.write(`  ${line}\n`),
     });
     for (const w of ff.warnings) process.stderr.write(`  warning: ${w}\n`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "slidemind",
-  "version": "0.2.1",
+  "version": "0.2.2",
   "description": "Connect Claude Code, Codex & opencode to the slidemind PowerPoint add-in — let your coding agent build and edit native, on-brand PowerPoint decks against your active corporate design, from the terminal.",
   "type": "module",
   "bin": {
@@ -20,7 +20,8 @@
     "skills/",
     ".claude-plugin/",
     ".codex-plugin/",
-    "CLAUDE.md",
+    ".agents/plugins/",
+    "AGENTS.md",
     "README.md"
   ],
   "scripts": {

package/src/builders/build.mjs

@@ -840,10 +840,10 @@ export async function buildDeck(deckDir, opts = {}) {
   if (!fs.existsSync(slidesDir) || !fs.statSync(slidesDir).isDirectory()) {
     throw new Error(`Expected a 'slides/' folder in ${deckDir}`);
   }
-  if (skill.mode === "fill-template" && !opts.internalProposalFreeformRender) {
-    // Proposal decks are PPTX-native. The exporter may render freeform JSX
+  if (skill.mode === "fill-template" && !opts.internalFillFreeformRender) {
+    // fill-template decks are PPTX-native. The exporter may render freeform JSX
     // inserts internally, but `slidemind build` should not create a lossy
-    // presentation.html artifact for proposal decks.
+    // presentation.html artifact for them.
     throw new Error(
       `Deck ${path.basename(deckDir)} uses skill '${skill.skillName}' (mode ` +
         `fill-template); it has no HTML preview. Run 'slidemind build-pptx ` +

package/src/builders/resolve-skill.mjs

@@ -92,12 +92,15 @@ export function resolveDeckMode(deckDir) {
   }
 }
 
-// Skill packs can live outside the npm package: confidential template packs
-// (e.g. proposal masters) install to the user-level skills dir and are found
-// FIRST, so the public package never has to carry them. Lookup order:
+// Skill packs can live outside the npm package: private, org-internal packs
+// (templates, brand-specific assets) are distributed on their own and this
+// package never carries them. Lookup order:
 //   1. $SLIDEMIND_SKILLS_DIR/<name>   (tests / non-standard installs)
 //   2. ~/.config/slidemind/skills/<name>
-//   3. <package>/skills/<name>
+//   3. <package>/skills/<name>        (this CLI's own skills win on their names)
+//   4. the harness skill + plugin dirs (see harnessSkillDirs)
+// 3 precedes 4 so adding 4 is strictly additive: it is reached only for names
+// this package does not ship, i.e. exactly the externally-distributed packs.
 export function userSkillsRoot() {
   return (
     process.env.SLIDEMIND_SKILLS_DIR ||
@@ -109,12 +112,69 @@ export function userSkillsRoot() {
   );
 }
 
-function locateSkillDir(skillName) {
+// Every distribution channel a pack can arrive through — a Claude Code or
+// Codex plugin, or a workspace/admin-pushed skill — installs it into a HARNESS
+// directory, not ours. Without these the agent reads the pack's SKILL.md and
+// the build then fails to find the pack's own templates, which looks like a
+// broken pack rather than a lookup gap.
+//
+// Installers namespace copied skills as `slidemind-<name>`, so both spellings
+// are tried. Plugin caches nest as <root>/<marketplace>/<plugin>/skills/<name>.
+function harnessRoots() {
+  const home = os.homedir();
+  return [
+    path.join(home, ".claude"),
+    path.join(home, ".codex"),
+    // opencode keeps its config under XDG.
+    path.join(
+      process.env.XDG_CONFIG_HOME || path.join(home, ".config"),
+      "opencode",
+    ),
+  ];
+}
+
+function harnessSkillDirs(skillName) {
+  const names = [skillName, `slidemind-${skillName}`];
+  const dirs = [];
+  for (const root of harnessRoots()) {
+    for (const name of names) dirs.push(path.join(root, "skills", name));
+    // Plugin caches: <root>/plugins/cache/<marketplace>/<plugin>/skills/<name>
+    const cacheRoot = path.join(root, "plugins", "cache");
+    let marketplaces = [];
+    try {
+      marketplaces = fs.readdirSync(cacheRoot);
+    } catch {
+      continue;
+    }
+    for (const mp of marketplaces) {
+      let plugins = [];
+      try {
+        plugins = fs.readdirSync(path.join(cacheRoot, mp));
+      } catch {
+        continue;
+      }
+      for (const plugin of plugins) {
+        for (const name of names) {
+          dirs.push(path.join(cacheRoot, mp, plugin, "skills", name));
+        }
+      }
+    }
+  }
+  return dirs;
+}
+
+// Exported for tests: the pack-location rules are the contract every external
+// distribution channel depends on, and they deserve assertions that do not
+// also have to satisfy design resolution.
+export function locateSkillDir(skillName) {
   const candidates = [
     path.join(userSkillsRoot(), skillName),
     path.join(PACKAGE_ROOT, "skills", skillName),
+    ...harnessSkillDirs(skillName),
   ];
-  return firstExisting(candidates) ?? candidates[candidates.length - 1];
+  // The fallback stays the package path, so a missing pack still reports the
+  // location a bundled skill would live at rather than a harness cache dir.
+  return firstExisting(candidates) ?? path.join(PACKAGE_ROOT, "skills", skillName);
 }
 
 export function resolveSkill(skillName, planMeta = {}, opts = {}) {

package/src/pptx/fill/engine.mjs

@@ -1,5 +1,5 @@
 // The fill-template deck builder — the host-free `build-pptx` path for
-// proposal-style packs (mode: "fill-template" in the pack's skill.json).
+// template packs (mode: "fill-template" in the pack's skill.json).
 //
 // Assembly direction: the template .pptx is cloned WHOLE (masters, layouts,
 // media, tags, embeddings), then only declared shapes inside the clone are
@@ -74,7 +74,7 @@ export async function buildFillTemplateDeck({ deckDir, skill, outPath, onLog })
       problems.push(err.message);
       continue;
     }
-    const layout = layoutNumber(parsed.component, locale);
+    const layout = layoutNumber(parsed.component, locale, pack.components);
     if (!layout) {
       problems.push(`${file}: <${parsed.component}> is a freeform (create-slides) slide with no ` +
         `rendered artifact next to it — 'slidemind build-pptx' renders slides/${file.replace(/\.jsx$/, "")}.pptx ` +
@@ -190,6 +190,9 @@ function loadPack(skill) {
     fields,
     repeats: read("repeats.json", {}),
     policy: skill.manifest.policy ?? {},
+    // The pack's layout-component naming contract (see parse-slides.mjs).
+    // skillDir rides along so a bad pattern names the pack that shipped it.
+    components: { ...(skill.manifest.components ?? {}), skillDir: skill.skillDir },
   };
 }
 
@@ -283,7 +286,7 @@ function checkIdentities(sequence, warnings, problems) {
     problems.push(`WP count mismatch: slide 10 declares ${wpItems.length} work packages but there are ${details.length} WP-detail files (slide 11)`);
   }
   // Every WP detail must carry FULL bullet lists — a section left empty (or a
-  // one-liner) is a defect in a client proposal, not a style choice.
+  // one-liner) is a defect in a client deliverable, not a style choice.
   details.forEach((d, i) => {
     for (const section of ["services", "assumptions", "deliverables"]) {
       const lines = asLines(d.props?.[section]);

package/src/pptx/fill/freeform.mjs

@@ -1,12 +1,12 @@
 // In-deck freeform slides for fill-template decks.
 //
-// Contract: a proposal deck's slides/ may carry create-slides freeform JSX
+// Contract: a fill-template deck's slides/ may carry create-slides freeform JSX
 // (NN-name.jsx composing the design bundle's layouts) directly next to the
 // master-backed slides — no sibling deck. The rendered native artifact lives
 // beside its source as NN-name.pptx; the fill engine inserts that artifact at
 // the filename position like any native slide. This module keeps the
 // artifacts fresh: stale or missing renders go through the add-in's render
-// path (the ONLY host-dependent step of a proposal build) and are folded to
+// path (the ONLY host-dependent step of such a build) and are folded to
 // pruned one-slide packages. Unchanged freeform slides rebuild fully offline.
 
 import crypto from "node:crypto";
@@ -22,22 +22,26 @@ import { layoutNumber } from "./parse-slides.mjs";
 
 const SIDE_CAR = ".freeform-renders.json";
 
-// The template's Challenge/Solution slides carry FIXED titles; freeform
-// replacements must keep them so the deck reads like the master.
-const FIXED_TITLES = {
-  en: [
-    { stem: /challenge/i, title: "Challenge" },
-    { stem: /solution/i, title: "Solution" },
-  ],
-  de: [
-    { stem: /challenge|herausforderung/i, title: "Herausforderung" },
-    { stem: /solution|loesung|lösung/i, title: "Lösung" },
-  ],
-};
+// Some templates fix a slide's title (the master prints it, so a freeform
+// replacement must keep it or the deck stops reading like the master). WHICH
+// slides, and in which locale, is the pack's business — it declares them in
+// skill.json as policy.fixedTitles:
+//
+//   "fixedTitles": {
+//     "en": [ { "stem": "agenda", "title": "Agenda" } ],
+//     "de": [ { "stem": "agenda|ablauf", "title": "Ablauf" } ]
+//   }
+//
+// `stem` is a case-insensitive regex matched against the slide file's stem.
+// A pack that declares none simply gets no title warnings.
+function fixedTitleRules(policy, locale) {
+  const all = policy?.fixedTitles ?? {};
+  return all[locale] ?? all.en ?? [];
+}
 
-function isFreeformSource(src) {
+function isFreeformSource(src, components) {
   const comp = src.match(/<([A-Z][A-Za-z0-9]*)/)?.[1];
-  return Boolean(comp) && layoutNumber(comp, "en") === null;
+  return Boolean(comp) && layoutNumber(comp, "en", components) === null;
 }
 
 function contentHash(parts) {
@@ -53,9 +57,10 @@ function slideText(bytes) {
   return [...(xml ?? "").matchAll(/<a:t>([^<]*)<\/a:t>/g)].map((m) => m[1]).join("\n");
 }
 
-function fixedTitleWarning(stem, bytes, locale) {
-  const rules = FIXED_TITLES[locale] ?? FIXED_TITLES.en;
-  const rule = rules.find((r) => r.stem.test(stem));
+function fixedTitleWarning(stem, bytes, locale, policy) {
+  const rule = fixedTitleRules(policy, locale).find((r) =>
+    new RegExp(r.stem, "i").test(stem),
+  );
   if (!rule) return null;
   if (slideText(bytes).includes(rule.title)) return null;
   return (
@@ -69,7 +74,14 @@ function fixedTitleWarning(stem, bytes, locale) {
  * `{ rendered, warnings }`; throws with the offending file named when a stale
  * render is needed but the paired backend cannot render.
  */
-export async function ensureFreeformRenders({ deckDir, locale = "en", srcDir, onLog = () => {} }) {
+export async function ensureFreeformRenders({
+  deckDir,
+  locale = "en",
+  srcDir,
+  components,
+  policy = {},
+  onLog = () => {},
+}) {
   const slidesDir = path.join(deckDir, "slides");
   const jsxFiles = fs.existsSync(slidesDir)
     ? fs.readdirSync(slidesDir).filter((f) => f.endsWith(".jsx")).sort()
@@ -77,7 +89,9 @@ export async function ensureFreeformRenders({ deckDir, locale = "en", srcDir, on
   const items = [];
   for (const file of jsxFiles) {
     const src = fs.readFileSync(path.join(slidesDir, file), "utf8");
-    if (isFreeformSource(src)) items.push({ file, stem: file.replace(/\.jsx$/, ""), src });
+    if (isFreeformSource(src, components)) {
+      items.push({ file, stem: file.replace(/\.jsx$/, ""), src });
+    }
   }
   const warnings = [];
   if (items.length === 0) return { rendered: 0, warnings };
@@ -149,7 +163,7 @@ export async function ensureFreeformRenders({ deckDir, locale = "en", srcDir, on
   for (const it of items) {
     const target = path.join(slidesDir, `${it.stem}.pptx`);
     if (!fs.existsSync(target)) continue;
-    const warn = fixedTitleWarning(it.stem, fs.readFileSync(target), locale);
+    const warn = fixedTitleWarning(it.stem, fs.readFileSync(target), locale, policy);
     if (warn) warnings.push(warn);
   }
   return { rendered: stale.length, warnings };

package/src/pptx/fill/parse-slides.mjs

@@ -1,27 +1,61 @@
-// Parser for proposal slide files. Proposal JSX is declarative by contract —
-// one default export returning exactly one <SlideProposalLayoutNN …/> element
-// whose props are data literals. That constraint is what makes a real JSX
-// runtime unnecessary: attributes are scanned textually and brace expressions
-// are evaluated as plain JS literals in an empty vm sandbox.
+// Parser for fill-template slide files. Their JSX is declarative by contract —
+// one default export returning exactly one <SomeLayout …/> element whose props
+// are data literals. That constraint is what makes a real JSX runtime
+// unnecessary: attributes are scanned textually and brace expressions are
+// evaluated as plain JS literals in an empty vm sandbox.
+//
+// The component NAMES are the pack's business, not this engine's: a pack ships
+// its own layouts under its own naming scheme, so it declares the scheme in
+// skill.json and this file only applies it.
 
 import vm from "node:vm";
 
-// Accepted component spellings → template slide number.
-//   SlideProposalLayout07           (canonical, locale-neutral)
-//   SlideProposalEn07Slide7 / SlideProposalDe07Slide7 (generated concrete names)
-export function layoutNumber(component, locale) {
-  let m = component.match(/^SlideProposalLayout(\d{2})$/);
+// Compiled once per distinct pattern — layoutNumber runs per slide file.
+const patternCache = new Map();
+function compile(pattern, which, skillDir) {
+  let re = patternCache.get(pattern);
+  if (re) return re;
+  try {
+    re = new RegExp(pattern);
+  } catch (err) {
+    throw new Error(
+      `pack ${skillDir ?? "(unknown)"}: skill.json components.${which} is not a ` +
+        `valid regular expression (${err.message})`,
+    );
+  }
+  patternCache.set(pattern, re);
+  return re;
+}
+
+// Map a component name → the template slide number it fills, or null when the
+// component is not master-backed at all (i.e. a freeform slide).
+//
+// `components` comes from the pack's skill.json and declares two patterns:
+//   canonical  — locale-neutral spelling; capture group 1 is the slide number
+//   localized  — optional generated spelling; group 1 is the locale, group 2
+//                the slide number (so a locale mismatch can be reported)
+export function layoutNumber(component, locale, components) {
+  if (!components || !components.canonical) {
+    throw new Error(
+      "fill-template pack declares no components.canonical pattern in " +
+        "skill.json — the pack owns its layout naming contract and must " +
+        "declare it, e.g. { \"components\": { \"canonical\": \"^MyLayout(\\\\d{2})$\" } }",
+    );
+  }
+  let m = component.match(compile(components.canonical, "canonical", components.skillDir));
   if (m) return { no: Number(m[1]) };
-  m = component.match(/^SlideProposal(En|De)(\d{2})Slide\d+$/);
-  if (m) {
-    const compLocale = m[1].toLowerCase();
-    return {
-      no: Number(m[2]),
-      warn:
-        compLocale === locale
-          ? `use the canonical <SlideProposalLayout${m[2]}> alias`
-          : `component locale "${compLocale}" does not match deck locale "${locale}"`,
-    };
+  if (components.localized) {
+    m = component.match(compile(components.localized, "localized", components.skillDir));
+    if (m) {
+      const compLocale = String(m[1]).toLowerCase();
+      return {
+        no: Number(m[2]),
+        warn:
+          compLocale === locale
+            ? `use the canonical alias for slide ${Number(m[2])}`
+            : `component locale "${compLocale}" does not match deck locale "${locale}"`,
+      };
+    }
   }
   return null;
 }
@@ -81,7 +115,7 @@ function evalLiteral(expr, file) {
     return value === undefined ? undefined : JSON.parse(JSON.stringify(value));
   } catch (err) {
     throw new Error(`${file}: cannot evaluate prop expression (${err.message}). ` +
-      `Proposal props must be data literals — strings, numbers, arrays, objects.`);
+      `Slide props must be data literals — strings, numbers, arrays, objects.`);
   }
 }
 
@@ -136,7 +170,7 @@ export function parseSlideFile(source, file) {
     const inner = closeIdx > 0 ? src.slice(i + 1, closeIdx).trim() : "";
     if (inner) {
       throw new Error(
-        `${file}: <${component}> has children. Master-backed proposal slides are ` +
+        `${file}: <${component}> has children. Master-backed slides are ` +
           `self-closing props-only elements; freeform content belongs to create-slides.`,
       );
     }

package/src/pptx/fill/xml.mjs

@@ -30,7 +30,7 @@ const stripHighlight = (rPr) =>
 
 const SHAPE_TAGS = ["sp", "pic", "cxnSp", "graphicFrame"];
 
-// Top-level shape blocks of one kind. The proposal masters keep all editable
+// Top-level shape blocks of one kind. Template masters keep all editable
 // shapes at spTree top level (verified by inventory); grouped shapes are not
 // addressed by the pack metadata.
 export function* blocks(xml, tag) {