@liustack/pptfast 0.4.0 → 0.7.0

package/README.md

@@ -58,12 +58,34 @@ installNodePlatform()
 const bytes = await generatePptx(ir) // Uint8Array, ready to write to a .pptx
 ```
 
+## Browser
+
+The default `@liustack/pptfast` entry is browser-safe by construction — its whole dependency closure has no `fs`, no `commander`, no Node-only API (`docs/architecture.md`'s platform seam). Which subpath to import depends on how your page loads code:
+
+- **Bundler** (Vite, webpack, esbuild, Next.js, …) — the default entry, unchanged: `import { generatePptx, validateIr } from "@liustack/pptfast"`. `react`/`react-dom`/`zod`/`jszip`/`dagre`/`pptxgenjs` stay external, resolved from your own `node_modules` and deduped against whatever else you already depend on.
+- **Bare `<script type="module">`, no build step** — `@liustack/pptfast/browser` instead. Every dependency is bundled in (react + react-dom/server + zod + jszip + dagre + pptxgenjs, ~1.7 MB raw / ~455 KB gzip), so it loads with nothing else on the page and no import map:
+
+  ```html
+  <script type="module">
+    import { validateIr, generatePptx } from "https://esm.sh/@liustack/pptfast/browser"
+    const { ok, ir, errors } = validateIr(deckJson)
+    if (!ok) throw new Error(errors.map((e) => e.message).join("\n"))
+    const bytes = await generatePptx(ir) // Uint8Array — new Blob([bytes]) to download
+  </script>
+  ```
+
+- **Embedding just the validator** — a page that checks pasted/edited IR JSON and shows errors has no reason to carry the render/export chain at all. `@liustack/pptfast/validate` exports `validateIr`, `formatIssues`/`formatWarnings`, `irJsonSchema`/`styleJsonSchema`, `listThemes`, and the IR/style zod schemas — `react`, `react-dom/server`, `pptxgenjs`, `jszip`, and `dagre` are all absent from its closure by construction, not just unused at runtime, landing at a fraction of `/browser`'s size (~730 KB raw / ~155 KB gzip).
+
+No `installPlatform()` call is needed in a browser — DOM parsing and (for `--pixels`-equivalent audits) SVG rasterization both default to the real browser globals (`DOMParser`, `OffscreenCanvas`) automatically, unlike `installNodePlatform()` (Quick start above), which is a Node-only requirement. Two honest caveats, not bugs: an image asset needs to already be a `data:` URI, or an `http(s)` URL the browser's own `fetch` can read cross-origin (the host needs permissive CORS headers — reading raw bytes to inline needs more than an `<img>` tag ever does) — `generatePptx` fetches such a URL for you at export time, but `auditDeck`'s pixel path (`{ pixels: true }`) refuses a remote `http(s)` image reference outright, the same "never a surprise network request" rule the Node/Sharp path also follows. `--pixels`-equivalent auditing needs `OffscreenCanvas`, which every evergreen browser has, while Node needs the optional `sharp` dependency instead (see Auditing below).
+
+`pptfast preview --html` (see For AI agents below) is the project's most mature "ships to a browser" artifact today: a self-contained review page a Node CLI run generates once, with zero further dependencies or network calls once it's open in a tab — distinct from importing the SDK live into your own page, but worth knowing about if "zero-dependency browser artifact" is what you actually need.
+
 ## CLI
 
 | Command | Does |
 |---|---|
 | `render <target> -o <out.pptx> [--theme <id>] [--style <file>] [--draft]` | Validate + render to a `.pptx` — `target` is an IR JSON file, a deck project directory, or a bare deck name (see Deck projects) |
-| `validate <target>` | Check the IR, print page-scoped errors — same `target` forms as `render` |
+| `validate <target>` | Check the IR, print page-scoped errors and advisory warnings — same `target` forms as `render` |
 | `audit <target> [--json] [--pixels]` | Deterministic geometry review (overflow/out-of-bounds/low-contrast/overlap/content-truncated/content-dropped) — same `target` forms as `render`, exits 1 when it finds anything (see Auditing) |
 | `spec validate <spec.json>` | Check a deck spec against the schema and strategy-aware hard gates (see Deck projects) |
 | `assemble <dir\|name> [-o <file>]` | Materialize a deck project directory into a single IR JSON file |
@@ -110,7 +132,7 @@ A theme bundles a style (design tokens), a brand (identity chrome), and a layout
 
 A narrative is three axes, independent of theme (visual style), that set editorial discipline: `strategy` (how the argument is built — `pyramid`, `storytelling`, `instructional`, `showcase`, `briefing`), `pacing` (how dense the content is — `dense`, `balanced`, `spacious`), and `audience` (a tone anchor — `executive`, `technical`, `customer`, `public`, no rendering effect yet). Set the IR's top-level `narrative` to a named preset string (e.g. `"boardroom-report"`) or a partial axes object (e.g. `{ "pacing": "spacious" }`) — an omitted axis, or an omitted `narrative` field entirely, falls back to `general` (`briefing` × `balanced` × `public`). An unknown preset name or axis value is a hard validate error listing what's available.
 
-`pacing` drives the content-quality gate and the body-text baseline (paragraph/bullets/callout only — every other component's own type scale and the heading system are unaffected): the per-slide component budget and the bullets budget (item count and per-item length) both tighten from `dense` toward `spacious`, while the body font size grows the other way — density is additionally capped by whichever layout the slide resolves to, whichever ceiling is tighter.
+`pacing` drives the content-quality gate and the body-text baseline (paragraph/bullets/callout only — every other component's own type scale and the heading system are unaffected): the per-slide component budget and the bullets budget (item count and per-item length) both tighten from `dense` toward `spacious`, while the body font size grows the other way — density is additionally capped by whichever layout the slide resolves to, whichever ceiling is tighter. These are editorial guidance, not hard limits: `validate` reports them as warnings and still succeeds — only genuine render-safety ceilings (below) can block generation.
 
 | pacing | body text | components / slide | bullets |
 |---|---|---|---|
@@ -118,13 +140,13 @@ A narrative is three axes, independent of theme (visual style), that set editori
 | `balanced` (the default) | 24px | 4 | up to 5 items, ~40 characters each |
 | `spacious` | 32px | 3 | up to 4 items, ~30 characters each |
 
-Bullets shrink below their tier's baseline to fit when needed, down to a 14px floor, before any overflow handling kicks in. `pptfast validate` reports the exact numbers that applied to each slide.
+Bullets shrink below their tier's baseline to fit when needed, down to a 14px floor, before any overflow handling kicks in. Across every bullet style — `default`, `plain`, `divided`, `numbered`, and `checklist` alike — an item long enough to still overflow at that floor is a hard validate error, distinct from, and looser than, the per-pacing length guidance above, since it genuinely loses text to an ellipsis at render, not just reads as verbose. `pptfast validate` reports the exact numbers that applied to each slide.
 
 Run `pptfast narratives [--json]` to list the named presets (each carries soft theme recommendations — a starting suggestion, never a constraint) plus the raw axes tables.
 
 ## Layout selection
 
-When a slide omits `layout`, pptfast resolves one automatically in four deterministic steps: the page type's full registry pool → the theme's layout set for that page type (full by default, see Themes above) → the narrative's `strategy` softly upweights (×3) a handful of content-layout ids that suit that strategy, everything else stays at a ×1 floor (cover/chapter/ending are never weighted — their character comes from the theme, not the strategy) → a seeded weighted pick, swapped deterministically to the runner-up when it would repeat the immediately preceding slide's layout. An explicit `layout` always wins and skips every step above. Whether the content actually fits is enforced separately by `validate`'s density gate, never by selection — so editing a page's content cannot silently flip its layout.
+When a slide omits `layout`, pptfast resolves one automatically in four deterministic steps: the page type's full registry pool → the theme's layout set for that page type (full by default, see Themes above) → the narrative's `strategy` softly upweights (×3) a handful of content-layout ids that suit that strategy, everything else stays at a ×1 floor (cover/chapter/ending are never weighted — their character comes from the theme, not the strategy) → a seeded weighted pick, swapped deterministically to the runner-up when it would repeat the immediately preceding slide's layout. An explicit `layout` always wins and skips every step above. Whether the content fits is flagged separately by `validate`'s density gate (editorial guidance, not a hard block — see Narratives above), never by selection — so editing a page's content cannot silently flip its layout.
 
 The pick is fully deterministic — the same IR always resolves the same way, so preview and the final render never disagree. Staying stable *across revisions* (editing one page without reshuffling every other page's auto-picked layout) additionally needs a persisted `seed`, resolved in this order:
 
@@ -180,7 +202,7 @@ pptfast audit examples/basic.json
 
 ## For AI agents
 
-The recommended loop for an agent generating a deck: read `pptfast schema` to learn the vocabulary, write an IR JSON, run `pptfast validate` and fix whatever it reports (errors carry a page number and a fixable-in-place message — the point is to close this loop without a human), then `pptfast audit` for the same kind of fixable-in-place feedback on what a *valid* deck can still get wrong at render time (overflow, low-contrast, overlap — exit code alone says whether it's clean), then `pptfast render`. `pptfast preview` gives the agent SVG files it can look at to self-check layout before committing to a render. Add `--html` to also write a self-contained `preview.html` for a human to review (keyboard nav, placeholder badges — a remote-URL image asset stays remote, the one self-containment gap). When every page is filled, that `preview.html` also overlays the same `audit` findings (per-page badges plus a findings panel, click to jump to the page) so a human reviewer sees them without a terminal — a deck with any placeholder page shows a one-line "audit skipped" notice instead. The reviewer can leave free-text per-page annotations right in `preview.html` and export them as a `revision-request.json` (a Blob download, no network or file write — preview stays read-only) for the agent to route back through `pages/*.json`. The Claude Code plugin above wraps this loop as a skill ([`skills/pptfast/SKILL.md`](./skills/pptfast/SKILL.md)). This exact loop is exercised by an internal, model-agnostic benchmark (`tests/bench/`, not published to npm) that mechanically scores how well a model follows the skill on a fixed question bank — see `tests/bench/README.md`.
+The recommended loop for an agent generating a deck: read `pptfast schema` to learn the vocabulary, write an IR JSON, run `pptfast validate` and fix whatever it reports (errors carry a page number and a fixable-in-place message — the point is to close this loop without a human), then `pptfast audit` for the same kind of fixable-in-place feedback on what a *valid* deck can still get wrong at render time (overflow, low-contrast, overlap — exit code alone says whether it's clean), then `pptfast render`. `pptfast preview` gives the agent SVG files it can look at to self-check layout before committing to a render. Add `--html` to also write a self-contained `preview.html` for a human to review (keyboard nav, placeholder badges — a remote-URL image asset stays remote, the one self-containment gap) — zero network calls and zero further dependencies once it's open in a tab, the project's most mature zero-dependency browser artifact today (see Browser above). When every page is filled, that `preview.html` also overlays the same `audit` findings (per-page badges plus a findings panel, click to jump to the page) so a human reviewer sees them without a terminal — a deck with any placeholder page shows a one-line "audit skipped" notice instead. The reviewer can leave free-text per-page annotations right in `preview.html` and export them as a `revision-request.json` (a Blob download, no network or file write — preview stays read-only) for the agent to route back through `pages/*.json`. The Claude Code plugin above wraps this loop as a skill ([`skills/pptfast/SKILL.md`](./skills/pptfast/SKILL.md)). This exact loop is exercised by an internal, model-agnostic benchmark (`tests/bench/`, not published to npm) that mechanically scores how well a model follows the skill on a fixed question bank — see `tests/bench/README.md`.
 
 ## Roadmap
 
@@ -191,7 +213,7 @@ The recommended loop for an agent generating a deck: read `pptfast schema` to le
 
 ## Credits
 
-Icon primitives are extracted from [lucide](https://lucide.dev) (ISC License). pptfast itself was extracted from a production AI-deck-generation system and CJK-typography-tuned (full-width punctuation width, Chinese line breaking, a Chinese-first font stack) from day one.
+Icon primitives are extracted from [lucide](https://lucide.dev) (ISC License). pptfast itself was extracted from a production AI-deck-generation system and CJK-typography-tuned (full-width punctuation width, Chinese line breaking, a Chinese-first font stack, explicit east-asian font-slot declarations) from day one.
 
 ## License
 

package/README.zh-CN.md

@@ -56,12 +56,34 @@ installNodePlatform()
 const bytes = await generatePptx(ir) // Uint8Array，可直接写成 .pptx 文件
 ```
 
+## 浏览器
+
+`@liustack/pptfast` 默认入口天生浏览器安全——它的整个依赖闭包不含 `fs`、不含 `commander`、不含任何 Node-only API（见 `docs/architecture.md` 的 platform seam 一节）。具体该 import 哪个子路径，取决于页面怎么加载代码：
+
+- **打包器场景**（Vite、webpack、esbuild、Next.js 等）——默认入口，写法不变：`import { generatePptx, validateIr } from "@liustack/pptfast"`。`react`/`react-dom`/`zod`/`jszip`/`dagre`/`pptxgenjs` 依旧是 external，从你自己的 `node_modules` 解析，和你项目里其他依赖一起去重。
+- **裸 `<script type="module">`，零构建**——改用 `@liustack/pptfast/browser`。每个依赖都已打包进去（react + react-dom/server + zod + jszip + dagre + pptxgenjs，约 1.7MB 原始 / 约 455KB gzip），页面上不需要任何 import map 或额外脚本就能加载：
+
+  ```html
+  <script type="module">
+    import { validateIr, generatePptx } from "https://esm.sh/@liustack/pptfast/browser"
+    const { ok, ir, errors } = validateIr(deckJson)
+    if (!ok) throw new Error(errors.map((e) => e.message).join("\n"))
+    const bytes = await generatePptx(ir) // Uint8Array —— new Blob([bytes]) 即可触发下载
+  </script>
+  ```
+
+- **只嵌入校验器**——一个校验用户粘贴/编辑的 IR JSON 并展示错误的页面，完全没理由带上整条渲染/导出链。`@liustack/pptfast/validate` 导出 `validateIr`、`formatIssues`/`formatWarnings`、`irJsonSchema`/`styleJsonSchema`、`listThemes`，以及 IR/style 的 zod schema——`react`、`react-dom/server`、`pptxgenjs`、`jszip`、`dagre` 从依赖闭包层面就不存在（不是「运行时用不到」，而是构建时就没打进去），体积只有 `/browser` 的一个零头（约 730KB 原始 / 约 155KB gzip）。
+
+浏览器里不需要调用 `installPlatform()`——DOM 解析，以及（等价于 `--pixels` 的）SVG 光栅化，都会自动 fallback 到真实的浏览器全局对象（`DOMParser`、`OffscreenCanvas`），`installNodePlatform()`（见上文快速开始）只是 Node 场景下的硬性要求。两条如实说明的限制，而非缺陷：图片资产要么已经是 `data:` URI，要么是浏览器自身 `fetch` 能跨域读取的 `http(s)` URL（宿主需要开放的 CORS 头——把原始字节读出来内联，比 `<img>` 标签单纯显示图片的要求更高）——`generatePptx` 会在导出时替你 fetch 这类 URL，但 `auditDeck` 的像素审查路径（`{ pixels: true }`）会直接拒绝还带着远程 `http(s)` 图片引用的页面，和 Node/Sharp 路径共享同一条「绝不擅自发起意外网络请求」的规则。等价于 `--pixels` 的审查需要 `OffscreenCanvas`，现代浏览器都有，Node 一侧则需要可选依赖 `sharp`（见下文审查一节）。
+
+`pptfast preview --html`（见下文「面向 AI agent」）是这个项目目前最成熟的「产物直接跑在浏览器里」的例子：Node CLI 跑一次生成一个自包含的审阅页，打开后零网络请求、零进一步依赖——和「把 SDK 实时 import 进你自己的页面」是两回事，但如果你要的正好是「零依赖浏览器产物」，这个已经是现成答案。
+
 ## CLI
 
 | 命令 | 作用 |
 |---|---|
 | `render <target> -o <out.pptx> [--theme <id>] [--style <file>] [--draft]` | 校验并渲染成 `.pptx`——`target` 可以是 IR JSON 文件、deck 项目目录，或裸名（见「Deck 项目」） |
-| `validate <target>` | 校验 IR，输出带页码的错误信息——`target` 形式同 `render` |
+| `validate <target>` | 校验 IR，输出带页码的错误信息与提示性警告——`target` 形式同 `render` |
 | `audit <target> [--json] [--pixels]` | 确定性几何审查（溢出/越界/低对比度/重叠/内容截断/内容丢失）——`target` 形式同 `render`，一旦发现问题 exit 1（见「审查」） |
 | `spec validate <spec.json>` | 校验 deck spec 是否符合 schema 与随 strategy 变化的硬门（见「Deck 项目」） |
 | `assemble <dir\|name> [-o <file>]` | 把 deck 项目目录合并成单个 IR JSON 文件 |
@@ -108,7 +130,7 @@ v4 IR schema 自 0.4.0 起冻结——后续演进只走加法（新增可选字
 
 叙事（narrative）是三条独立于主题（视觉风格）之外的轴，用来定编辑纪律：`strategy`（论证方式——`pyramid`、`storytelling`、`instructional`、`showcase`、`briefing`）、`pacing`（内容密度——`dense`、`balanced`、`spacious`）、`audience`（语气锚点——`executive`、`technical`、`customer`、`public`，目前无渲染效果）。把 IR 顶层的 `narrative` 设为具名预设字符串（如 `"boardroom-report"`），或部分轴对象（如 `{ "pacing": "spacious" }`）——省略任意一轴、或整个省略 `narrative` 字段，均回落到 `general` 预设（`briefing` × `balanced` × `public`）。未知的预设名或轴值会硬报错并列出可用项。
 
-`pacing` 驱动内容质量门，也驱动正文字号基线（仅 paragraph/bullets/callout 三件套——其余组件各自的字阶与标题体系不受影响）：每页的 component 数预算与 bullets 预算（条目数与单条长度上限）都随 `pacing` 从 `dense` 向 `spacious` 收紧，正文字号则反向增长——密度上限还会再叠加所选 layout 的容量，取两者中更紧的一个。
+`pacing` 驱动内容质量门，也驱动正文字号基线（仅 paragraph/bullets/callout 三件套——其余组件各自的字阶与标题体系不受影响）：每页的 component 数预算与 bullets 预算（条目数与单条长度上限）都随 `pacing` 从 `dense` 向 `spacious` 收紧，正文字号则反向增长——密度上限还会再叠加所选 layout 的容量，取两者中更紧的一个。这些是编辑性指导，不是硬限制——`validate` 只会把它们报成警告，仍然校验通过，真正能拦下生成的只有下面这条渲染安全上限。
 
 | pacing | 正文字号 | 每页 component 数 | bullets |
 |---|---|---|---|
@@ -116,13 +138,13 @@ v4 IR schema 自 0.4.0 起冻结——后续演进只走加法（新增可选字
 | `balanced`（默认） | 24px | 4 | 至多 5 条，每条约 40 字 |
 | `spacious` | 32px | 3 | 至多 4 条，每条约 30 字 |
 
-bullets 需要时会在各自档位基线之下收缩以适配空间，最低到 14px 地板，再触发溢出处理。`pptfast validate` 会报出每页实际生效的具体数值。
+bullets 需要时会在各自档位基线之下收缩以适配空间，最低到 14px 地板，再触发溢出处理。`default`、`plain`、`divided`、`numbered`、`checklist` 五种要点样式一视同仁：一条要点长到在这个地板字号下仍然放不下，会是一条硬校验错误——不同于（也宽于）上面按 pacing 分档的长度指导，因为它在渲染时会真的被省略号截掉文字，不只是显得啰嗦。`pptfast validate` 会报出每页实际生效的具体数值。
 
 运行 `pptfast narratives [--json]` 查看全部具名预设（各自带一份软性 theme 推荐表——仅供参考，从不构成约束）及三轴的原始数据表。
 
 ## 版式选型
 
-当某页省略 `layout` 时，pptfast 按四个确定性步骤自动选型：该页型的全部注册版式 → 主题该页型的版式集合（默认全集，见上文「主题」）→ 叙事的 `strategy` 对一小撮适配该 strategy 的 content 版式做 ×3 软加权，其余维持 ×1 底权（cover/chapter/ending 三个页型永不加权——它们的个性来自主题，不来自 strategy）→ 按 seed 加权取样，若命中结果与紧邻的上一页版式相同则确定性地换成次优候选。显式 `layout` 恒优先，跳过以上全部步骤。内容装不装得下由 `validate` 的密度门单独把关，从不参与选型——因此改一页的内容不会悄悄翻转它的版式。
+当某页省略 `layout` 时，pptfast 按四个确定性步骤自动选型：该页型的全部注册版式 → 主题该页型的版式集合（默认全集，见上文「主题」）→ 叙事的 `strategy` 对一小撮适配该 strategy 的 content 版式做 ×3 软加权，其余维持 ×1 底权（cover/chapter/ending 三个页型永不加权——它们的个性来自主题，不来自 strategy）→ 按 seed 加权取样，若命中结果与紧邻的上一页版式相同则确定性地换成次优候选。显式 `layout` 恒优先，跳过以上全部步骤。内容装不装得下由 `validate` 的密度门单独标记（编辑性指导，不是硬拦截——见上文「叙事」），从不参与选型——因此改一页的内容不会悄悄翻转它的版式。
 
 选型本身完全确定——同一份 IR 永远选出同一个结果，预览与最终渲染绝不会不一致。但要在**多次修订之间**保持稳定（改一页不搅动其余页的自动选型），还需要一个持久化的 `seed`，按以下顺序解析：
 
@@ -172,7 +194,7 @@ pptfast audit examples/basic.json
 
 ## 面向 AI agent
 
-推荐给 agent 的生成回路：先读 `pptfast schema` 学词汇表，写出 IR JSON，跑 `pptfast validate` 并根据报错自纠（错误信息带页码和可直接照抄的修正方式，目的就是让这个回路不必依赖人工介入），再跑 `pptfast audit`——同样是可直接照抄的修正反馈，只是针对一份*合法* deck 在渲染层仍可能出现的问题（溢出、低对比度、重叠——exit code 本身就说明干不干净），最后执行 `pptfast render`。`pptfast preview` 能让 agent 在正式渲染前先看一遍 SVG，自查版式是否合理。加上 `--html` 还会额外写出一个自包含的 `preview.html`，供人工审查（键盘翻页、占位页角标——远程 URL 的图片资产仍是远程链接，这是自包含性上唯一的缺口）。当所有页面都已填写时，这份 `preview.html` 还会叠加同一份 `audit` 检查结果（每页一个数量角标，加一个可点击跳转的 findings 面板），让人工审查者不必打开终端就能看到问题——如果 deck 里还有占位页，则显示一行「audit 已跳过」的提示代替。审查者可以直接在 `preview.html` 里给每页写自由文本批注，并导出为 `revision-request.json`（浏览器 Blob 下载，不联网也不写文件——preview 始终只读），交给 agent 通过 `pages/*.json` 回填。上文的 Claude Code 插件已把这套回路封装成 skill（[`skills/pptfast/SKILL.md`](./skills/pptfast/SKILL.md)）。这套回路本身由一个模型无关的内部基准测试（`tests/bench/`，不发布到 npm）机械化验证——固定题库，评估模型跟随该 skill 的表现，细节见 `tests/bench/README.md`。
+推荐给 agent 的生成回路：先读 `pptfast schema` 学词汇表，写出 IR JSON，跑 `pptfast validate` 并根据报错自纠（错误信息带页码和可直接照抄的修正方式，目的就是让这个回路不必依赖人工介入），再跑 `pptfast audit`——同样是可直接照抄的修正反馈，只是针对一份*合法* deck 在渲染层仍可能出现的问题（溢出、低对比度、重叠——exit code 本身就说明干不干净），最后执行 `pptfast render`。`pptfast preview` 能让 agent 在正式渲染前先看一遍 SVG，自查版式是否合理。加上 `--html` 还会额外写出一个自包含的 `preview.html`，供人工审查（键盘翻页、占位页角标——远程 URL 的图片资产仍是远程链接，这是自包含性上唯一的缺口）——打开后零网络请求、零进一步依赖，是这个项目目前最成熟的零依赖浏览器产物（见上文「浏览器」）。当所有页面都已填写时，这份 `preview.html` 还会叠加同一份 `audit` 检查结果（每页一个数量角标，加一个可点击跳转的 findings 面板），让人工审查者不必打开终端就能看到问题——如果 deck 里还有占位页，则显示一行「audit 已跳过」的提示代替。审查者可以直接在 `preview.html` 里给每页写自由文本批注，并导出为 `revision-request.json`（浏览器 Blob 下载，不联网也不写文件——preview 始终只读），交给 agent 通过 `pages/*.json` 回填。上文的 Claude Code 插件已把这套回路封装成 skill（[`skills/pptfast/SKILL.md`](./skills/pptfast/SKILL.md)）。这套回路本身由一个模型无关的内部基准测试（`tests/bench/`，不发布到 npm）机械化验证——固定题库，评估模型跟随该 skill 的表现，细节见 `tests/bench/README.md`。
 
 ## 路线图
 
@@ -183,7 +205,7 @@ pptfast audit examples/basic.json
 
 ## 致谢
 
-图标原语抽取自 [lucide](https://lucide.dev)（ISC License）。pptfast 本身从一套生产环境的 AI 出 PPT 系统中抽取而来，从第一天起就针对 CJK 排版做了优化（全角标点宽度、中文换行、雅黑优先字体栈）。
+图标原语抽取自 [lucide](https://lucide.dev)（ISC License）。pptfast 本身从一套生产环境的 AI 出 PPT 系统中抽取而来，从第一天起就针对 CJK 排版做了优化（全角标点宽度、中文换行、雅黑优先字体栈、显式东亚字体槽声明）。
 
 ## License