@liustack/pptwise 0.22.0 → 0.24.0

package/skills/pptwise/references/validate.md

@@ -1,82 +1,70 @@
-# Validate loop
+# Validation and review loop
 
-Read this when running assemble / validate / audit / preview / serve, or revising a page.
+Read this when filling pages, assembling a deck project, rendering, auditing, previewing, serving, or revising.
 
-### Phase 3 — Fill pages in batches of at most 4, validate immediately
+## Fill small batches
 
-For each page in the confirmed spec, write `pages/<page-id>.json` with its content (`components`, and optionally `layout`/`arrangement`/`background`/`image_side`/`footnote`/`notes` — never `type`/`heading`, those are locked by the spec). Remember Phase 1's boundary-page rule while drafting `cover`/`chapter`/`ending` pages — do not give them `components` or `footnote` and then have to move it. `notes` is speaker notes prose for whoever presents the deck — writing a good speaking script is a model strength. Draft `notes` whenever the page needs a spoken walkthrough beyond what is on the slide (Sparse-page contract). That is the default, not optional.
+For each confirmed spec page, write `pages/<page-id>.json`. A page file may contain only `components`, `background`, `image_side`, `footnote`, and `notes`. The spec owns `type`, content `kind`, `heading`, and page order. Repeating any locked field in a page file is a hard error.
+
+Fill at most four pages, then run:
 
 ```bash
-pptwise assemble deck-dir/     # materializes deck.json — catches structural drift: orphan page files, locked-field violations, a broken spec
-pptwise validate deck-dir/     # content-quality gate: heading length, density, bullets budget (warnings) + unknown theme, boundary-page content, and a bullet item past render-safety (hard errors)
+pptwise assemble deck-dir/
+pptwise validate deck-dir/
 ```
 
-Fix whatever either command reports as an error and re-run until both print `OK`. `validate` can print `OK` alongside `warning:` lines (e.g. a long heading or a dense slide) — tighten those too when practical, they read better, but they do not block. Only an error stops `OK` from printing. A spec page with no page file yet is a placeholder (heading only) — assemble and validate both accept that. Leaving some pages as placeholders between batches is normal, not an error. `assemble` also prints `note: N layouts auto-selected into deck.json` whenever a page's `layout` was left to auto-selection — informational, not an error. Pin `layout` in a page file only when a specific pick needs to be locked — a `pinOnly` layout like `quote-stage`, `statement`, `pull-quote`, `verse-chapter`, `stat-hero`, `one-evidence`, or `mono-bleed` needs this pin every single time, since it never comes up through auto-selection at all (see `references/layouts.md`). Climax, quote, and evidence pages pin those by default (see `references/layouts.md`).
+`assemble` merges the locked semantics and page content into IR v5. It does not write face choices or any other rendering decision into the project. A missing page file remains an accepted placeholder. An orphan page file, a locked-field conflict, an unknown theme, or a kind absent from the bound theme menu is a hard error.
+
+`validate` applies schema, component, asset, narrative, physical capacity, and editorial checks. Fix errors until it prints `OK`. Warnings do not block output, but long headings, excessive density, dangling assets, and repetitive choices should normally be tightened before delivery.
 
-### Phase 4 — Render
+Speaker `notes` export as native PowerPoint notes and never paint on the slide.
+
+## Render only from the binding
 
 ```bash
 pptwise render deck-dir/
 ```
 
-The `.pptx` lands in `.pptwise/<deck>/`. The command prints the absolute path. Report that line to the user.
+The `.pptx` is written under `.pptwise/<deck>/`, and the command prints its absolute path. There is no render-time theme switch. The project spec is the binding.
 
-`--theme <id>` overrides the deck theme without editing the spec. `--style <path>` layers a style-token override on top (re-color without forking a theme, schema: `pptwise schema --style`). Render refuses a deck with unfilled placeholder pages unless you add `--draft` — reach for that only when the user explicitly wants a look before every page is done. It also refuses a deck where a page holds more than fits, so the layout left blocks out with nothing on the slide to say so: the error names the pages and how many blocks each lost. Fix it by shortening that page or splitting it in two, and re-render — `--allow-dropped-content` ships the file with the content missing, so only pass it if the user says to.
+An unfinished project requires explicit `--draft`. Content that would be dropped remains blocked unless the user explicitly accepts `--allow-dropped-content`. Prefer fixing or splitting the page.
 
-If the project has a `pptwise.config.json`, its theme/style are project defaults — do not fight them with `--theme` unless the user asks. Any page `notes` you wrote in phase 3 export as native PowerPoint speaker notes (View → Notes in PowerPoint/Keynote) — never drawn onto the slide itself.
+When changing themes, compare candidates with `pptwise theme try`. A same-menu fork can replace the binding and proceed through assemble, validate, audit, and render. A different menu requires returning to theme selection, then revising the spec and affected page fills before those checks.
 
-### Phase 5 — Audit and optional visual self-check
+## Audit geometry
 
-Once every page is filled (no placeholders left), run the deterministic geometry audit:
+After every page is filled, run:
 
 ```bash
 pptwise audit deck-dir/
 ```
 
-Zero-token, zero-variance — it renders each page off-screen and checks overflow, out-of-bounds, low-contrast, overlap, content-truncated (an ellipsis cut real text), and content-dropped (an item or whole component silently clamped out, tagged data-dropped in the SVG), exiting 1 when it finds anything (0 when clean). Each finding names its page (and id) and carries a fix. Fix the flagged page's content — same "restructure, don't delete" discipline as a `validate` error — then re-run `pptwise audit deck-dir/` alone (no need to re-render) until it exits 0. This is the deck's visual QA. Do not rely on eyeballing a screenshot instead.
+The deterministic audit checks overflow, out-of-bounds content, low contrast, overlap, truncation, dropped content, and repeated lead components. A finding exits with code 1 and names the page. Restructure the content, rerun assemble and validate when source files changed, then rerun audit until it exits 0.
+
+Add `--pixels` when cover or chapter pages use photo backgrounds. Pixel sampling catches text placed on an unsafe part of a real image.
 
-If any page has a cover/chapter photo background, add `--pixels` — it rasterizes the page and samples real pixels to catch text sitting directly on an unscrimmed photo, the one case the SVG-only checks above can't see.
+## Review the whole deck
+
+When an in-conversation deck preview tool exists, use it. Otherwise generate the self-contained review file:
 
 ```bash
 pptwise preview deck-dir/ --html
 ```
 
-Writes one standalone SVG per slide plus a self-contained `preview.html` into `.pptwise/<deck>/`, never gated on placeholder pages. The command prints the absolute path. Report that line to the user. Read a few SVGs yourself (they are plain text files) to sanity-check layout and density before delivering, especially for image-heavy decks. Hand `preview.html` (thumbnail strip, keyboard navigation, placeholder badges) to the user for their own look instead. When every page is filled, `preview.html` also overlays the same `audit` findings (per-page badges + a findings panel) so the reviewer sees them without a terminal. A deck with any placeholder page shows a one-line "audit skipped" notice instead. `preview.html` is read-only: it shows the deck, it never edits it. When the reviewer wants something changed, they tell you in the conversation. A screenshot of the page in question is the fastest way for both of you, and you route it through phase 6.
-
-### Showing the deck to the user
-
-How you hand a deck over depends on what the harness can render. Take the first one that applies.
+It writes one SVG per page plus `preview.html` under `.pptwise/<deck>/`. The preview is read-only. Placeholder pages are marked, and a complete deck includes audit findings in the review interface.
 
-**If a `pptwise_preview` tool exists, call it.** It renders the deck and puts a real slide preview in the conversation: a thumbnail strip in the tool card, full size on click, arrow keys to page. The user sees the deck without leaving the thread and without opening anything. Never fall back to handing over a file path or a URL when this tool is present. That is the experience it was built to replace. The tool reports only a summary line back to you (page count, audit state). That is deliberate: the deck itself goes to the user's screen, not into your context.
-
-**If the harness has a built-in browser (VS Code, Cursor, and similar), preview to a file.** Run `pptwise preview deck-dir/ --html`. The command prints the absolute path of `preview.html`. Give the user that path so they can open it in the built-in browser. Re-run the same command after each revision: the path does not change, they refresh. No port, no background process.
-
-**Otherwise, serve it.** Most harnesses have no way to draw a slide in the transcript, so the review happens in the user's own browser. Never try to substitute by pasting a thumbnail or a screenshot of one page into the conversation. Serve the whole thing and let the user page through it at full size. Start the server as a background task (in DSH, follow the background-job convention and note the job id so you can stop it later):
+When the user needs a live browser round, run the project server as a background task:
 
 ```bash
 pptwise serve deck-dir/ --no-open
 ```
 
-Then run the round in this order:
-
-1. Always pass `--no-open`. There is no browser to auto-open in an agent environment.
-2. Report the exact localhost URL it prints (default `http://127.0.0.1:4400`) to the user, so they can open it themselves. That one line is the whole handoff.
-3. The user pages through the deck and tells you what needs changing, in the conversation. A screenshot of the offending page is the fastest hand-off — you see exactly what they see.
-4. Route each request through phase 6's revision flow. The page live-reloads on every file you save, so each revision lands in the tab the user already has open. No new link, no re-export, nothing for them to click.
-5. Stay in the loop while they keep looking. When the round is over, stop the serve process (kill the background job). Never leave it running after the task ends.
-
-### Phase 6 — Revision: edit one page, re-assemble
-
-A revision touches the smallest file that captures it:
-
-- Content change ("punch up the KPI page") → edit that page's `pages/<id>.json` only, then repeat phase 3's `assemble` + `validate` pair, and phase 5's `audit`, before re-rendering. Never regenerate pages nobody asked you to touch.
-- Structural change (reorder, add/remove a page, change a page's type or heading) → edit `deck.spec.json` instead, re-run `pptwise spec validate` first (phase 2's no-respeccing rule still applies: only do this when the user actually asked for a structural change).
-- A change the reviewer asked for in conversation (usually with a screenshot of the page) → find that page's `pages/<id>.json` by matching what they described against `deck.spec.json`/`pages/`, and treat their words as a requirement to interpret, not a patch to apply verbatim: they are describing a rendered slide, not writing page-file JSON. Translate it into a concrete content edit, then run the same content-change loop above (`assemble` + `validate` + `audit`) for every page you touched. Preview stays read-only end to end: nothing writes into `pages/*.json` except your own deliberate edit.
+Share the exact localhost URL, keep the process for the review round, and stop only that process when the round ends.
 
-## Routing a follow-up request
+## Revise at the source
 
-Once a deck project exists, a follow-up message routes into exactly one of three branches — decide which before doing anything:
+- For a content change, edit only the affected `pages/<id>.json`, then assemble, validate, audit, and render again.
+- For page order, page type, kind, heading, or theme binding, edit `deck.spec.json`, run `pptwise spec validate`, then repeat the project checks.
+- For a different topic or audience, create a new project and restart from intent and narrative.
 
-1. **Edit a page** ("change slide 3", "make the KPI page punchier", or a screenshot with a note) → phase 6: edit that page's file, re-assemble, re-validate, re-audit. Never touch pages nobody asked about.
-2. **A new deck** (a different topic, audience, or an explicit request to start over) → phase 1: a new deck project directory, fresh narrative/theme decision, fresh spec.
-3. **Unrelated to deck generation** (a question about the content, anything with no connection to slides) → do not invoke pptwise at all.
+Never regenerate unrelated pages during a focused revision. Interpret screenshot feedback as a content requirement, change the smallest source file that owns it, and keep preview output read-only.

package/skills/pptwise/references/validate.zh-CN.md

@@ -3,85 +3,73 @@ summary: 'skills/pptwise/references/validate.md 的中文阅读镜像'
 mirror_of: skills/pptwise/references/validate.md
 ---
 
-# 排错与 validate 循环
+# 验证与评审循环
 
-何时读：跑 assemble / validate / audit / preview / serve，或修订某一页时。
+何时读：填充页面，组装 deck 项目，渲染，审计，预览，启动评审服务，或修订内容时。
 
-### Phase 3 — 分批填页面（每批至多 4 页），随填随 validate
+## 小批量填充
 
-对已确认 spec 里的每一页，写一个 `pages/<page-id>.json` 存放它的内容（`components`，以及可选的 `layout`/`arrangement`/`background`/`image_side`/`footnote`/`notes`——绝不写 `type`/`heading`，这两个字段被 spec 锁定）。撰写 `cover`/`chapter`/`ending` 页面时记住 Phase 1 的边界页规则——不要先给它们塞 `components` 或 `footnote`，然后再回头搬走。`notes` 是给主讲人看的演讲稿——写一份好的讲稿是模型的强项。只要页面需要一段超出幻灯片本身的口头讲解，就起草 `notes`（稀排页合同）。这是默认动作，不是可选项。
+为 spec 中每张已确认页面编写 `pages/<page-id>.json`。页面文件只能包含 `components`、`background`、`image_side`、`footnote` 与 `notes`。Spec 拥有 `type`、内容页 `kind`、`heading` 和页面顺序。在页面文件中重复任何锁定字段都会硬报错。
+
+每次最多填四页，然后运行：
 
 ```bash
-pptwise assemble deck-dir/     # materializes deck.json — catches structural drift: orphan page files, locked-field violations, a broken spec
-pptwise validate deck-dir/     # content-quality gate: heading length, density, bullets budget (warnings) + unknown theme, boundary-page content, and a bullet item past render-safety (hard errors)
+pptwise assemble deck-dir/
+pptwise validate deck-dir/
 ```
 
-把两个命令报出的错误都修掉，重新跑，直到两者都打印 `OK`。`validate` 可能在打印 `OK` 的同时带着 `warning:` 行（比如标题太长、某页太密）——条件允许时也应该收紧，读起来会更好，但它们不拦渲染。只有 error 才会让 `OK` 打印不出来。spec 里某一页如果还没有对应的页面文件，就是一个占位页（只有标题）——assemble 和 validate 都接受这种情况。分批之间留一些占位页是正常状态，不是错误。只要某一页的 `layout` 被留给自动选型，`assemble` 也会打印 `note: N layouts auto-selected into deck.json`——这只是提示，不是错误。只有当某个具体选型结果需要被锁定时，才在页面文件里显式钉死 `layout`——像 `quote-stage`、`statement`、`pull-quote`、`verse-chapter`、`stat-hero`、`one-evidence`、`mono-bleed` 这种 `pinOnly` 版式每次都需要这个钉子，因为它从来不会通过自动选型出现（见 `references/layouts.md`）。高潮页、金句页、证据页默认就要钉（见 `references/layouts.md`）。
+`assemble` 把锁定语义与页面内容合并成 IR v5。它不会把脸的选择或其他渲染决定写回项目。没有页面文件时保留为合法占位页。孤儿页面文件、锁定字段冲突、未知主题，或 kind 不在已绑定主题菜单中，都会硬报错。
+
+`validate` 检查 schema、组件、资产、叙事、物理容量与编辑预算。修复错误，直到它打印 `OK`。警告不拦输出，但长标题、密度过高、资产悬空和重复选择通常都应在交付前收紧。
 
-### Phase 4 — 渲染
+演讲者 `notes` 会导出为原生 PowerPoint 备注，从不画在页面上。
+
+## 只按绑定渲染
 
 ```bash
 pptwise render deck-dir/
 ```
 
-`.pptx` 落在 `.pptwise/<deck>/`。命令会打印绝对路径，把那一行报给用户。
+`.pptx` 写到 `.pptwise/<deck>/`，命令会打印绝对路径。渲染阶段没有临时换主题的开关。项目 spec 就是绑定。
 
-`--theme <id>` 在不改动 spec 的前提下覆盖 deck 的 theme。`--style <path>` 在其上叠加一层 style-token 覆盖（不用分叉 theme 就能重新配色，schema 见 `pptwise schema --style`）。deck 里还有未填的占位页时，render 会拒绝导出，除非加上 `--draft`——只有当用户明确想在所有页面都写完之前先看一眼时，才用它。某一页装不下、版面丢掉了放不下的块而页面上毫无提示时，render 同样拒绝导出，报错会写清哪几页各丢了几块。正确做法是把那一页缩短或拆成两页再重新渲染，`--allow-dropped-content` 会带着缺失的内容出片，只有用户明确要求时才用。
+未填完的项目需要显式使用 `--draft`。可能丢失的内容仍会被拦截，除非用户明确接受 `--allow-dropped-content`。应优先修复或拆页。
 
-如果项目里有 `pptwise.config.json`，它的 theme/style 就是项目默认值——除非用户要求，不要用 `--theme` 跟它对着干。阶段三里写的任何页面 `notes` 都会导出成原生 PowerPoint 演讲者备注（PowerPoint/Keynote 里的 View → Notes）——从不会画到幻灯片本身上。
+更换主题前，用 `pptwise theme try` 比较候选。菜单相同的分叉可以换绑，再依次运行 assemble、validate、audit 和 render。菜单不同则要回到主题选择，修订 spec 与受影响的页面填充，再重复这些检查。
 
-### Phase 5 — 审查，可选的视觉自查
+## 审计几何
 
-所有页面都填完（没有占位页剩下）之后，跑一次确定性几何审查：
+全部页面填完后运行：
 
 ```bash
 pptwise audit deck-dir/
 ```
 
-零 token、零方差——它离屏渲染每一页，检查溢出（overflow）、越界（out-of-bounds）、低对比度（low-contrast）、重叠（overlap）、内容截断（content-truncated，省略号截掉了真实文字）、内容丢失（content-dropped，某个条目或整个 component 被静默截掉，SVG 里标成 data-dropped），发现问题就 exit 1（干净则是 0）。每条 finding 都标出所在页面（和 id），并带一个修法。修那一页被标出的内容——和处理 `validate` 报错一样遵循「重组，不要删除」的纪律——然后单独重跑一次 `pptwise audit deck-dir/`（不用重新渲染）直到 exit 0。这是这份 deck 的视觉 QA。不要用肉眼看截图来代替它。
+确定性审计会检查溢出、越界、低对比度、重叠、截断、内容丢失和连续使用相同首组件。发现问题时退出码为 1，并指出页面。重组内容，源文件改变后重跑 assemble 与 validate，再重复 audit，直到退出码为 0。
+
+封面或章节页使用照片背景时，加上 `--pixels`。像素采样能发现文字落在真实图片不安全区域的问题。
 
-如果有页面用了 cover/chapter 照片背景，加上 `--pixels`——它会把该页光栅化并采样真实像素，抓住文字直接压在一张没有遮罩的照片上的情况，这是上面纯 SVG 检查唯一看不到的一种。
+## 评审整份 deck
+
+运行环境若有对话内 deck 预览工具，优先使用。否则生成自包含评审文件：
 
 ```bash
 pptwise preview deck-dir/ --html
 ```
 
-为每张 slide 各写一个独立 SVG，外加一个自包含的 `preview.html`，都落在 `.pptwise/<deck>/`，永远不受占位页拦截。命令会打印绝对路径，把那一行报给用户。交付之前自己读几个 SVG（它们就是纯文本文件），核对 layout 与密度是否合理，图片较多的 deck 尤其要看。把 `preview.html`（缩略图条、键盘翻页、占位页角标）交给用户自己看，而不是代替这一步。所有页面都填完时，`preview.html` 还会叠加同一份 `audit` 检查结果（每页一个角标 + 一个 findings 面板），让审查者不用打开终端就能看到问题。deck 里如果还有占位页，则改为显示一行「audit skipped」的提示。`preview.html` 是只读的：它只负责把 deck 呈现出来，从不改动它。审查者想改什么，直接在对话里告诉你。把那一页截图发给你是最快的交接方式，你再走阶段六处理。
-
-### 把 deck 拿给用户看
-
-怎么交付取决于 harness 能画什么。按下面的顺序，用第一条成立的。
+它会在 `.pptwise/<deck>/` 下写出每页一个 SVG 与 `preview.html`。预览只读。占位页会被标记，完整 deck 会在评审界面中带上 audit 发现。
 
-**如果存在 `pptwise_preview` 工具，就调它。** 它渲染完直接把幻灯片预览放进对话：卡片里是缩略图条，点开看全尺寸，方向键翻页。用户不用离开对话，也不用打开任何东西。**这个工具在场时绝不要退回去甩一个文件路径或 URL 给用户**。它就是为了取代那个体验才存在的。工具只回给你一行摘要（页数、审计状态），这是刻意的：deck 去用户屏幕，不进你的上下文。
-
-**如果 harness 有内置浏览器（VS Code、Cursor 一类），就预览成文件。** 跑 `pptwise preview deck-dir/ --html`。命令会打印 `preview.html` 的绝对路径，把那条路径给用户，让他在内置浏览器里打开。每轮修订后重跑同一条命令，路径不变，用户刷新即可。不占端口，不留常驻进程。
-
-**否则就起服务。** 大多数 harness 没办法在对话里画出一页幻灯片，审阅就发生在用户自己的浏览器里。绝不要用「贴一张缩略图或某一页的截图」来代替。把整份 deck 服务出去，让用户全尺寸自己翻。启动服务（在 DSH 里遵循后台任务的规矩，记下 job id，方便之后停掉）：
+用户需要浏览器实时评审时，把项目服务作为后台任务启动：
 
 ```bash
 pptwise serve deck-dir/ --no-open
 ```
 
-然后按这个顺序走完这一轮：
-
-1. 必须带 `--no-open`。agent 环境里没有可以自动打开的浏览器。
-2. 把它打印的 localhost URL（默认 `http://127.0.0.1:4400`）原样报给用户，让用户自己打开。这一行就是全部交付动作。
-3. 用户翻完整份 deck，在对话里告诉你哪里要改。把出问题的那一页截图发过来是最快的交接方式——你看到的和他看到的完全一致。
-4. 把每一条请求都走阶段六的修订流程。你每保存一次文件页面就实时重渲染，每一次修订都直接落在用户已经打开的那个标签页里。不用发新链接，也不用让他点任何东西。
-5. 用户还在继续看就留在这个循环里。这一轮结束时停掉 serve 进程（kill 掉那个后台任务）。任务结束后绝不留着它继续跑。
-
-### Phase 6 — 修订：改一页，重新 assemble
-
-一次修订，只改能承载这次改动的最小那份文件：
-
-- 内容改动（「把 KPI 那页写得更有冲击力」）→ 只改那一页的 `pages/<id>.json`，然后重复阶段三的 `assemble` + `validate` 组合，以及阶段五的 `audit`，再重新渲染。没人要求你改的页面，绝不重新生成。
-- 结构性改动（调整顺序、增删页面、改某页的 type 或 heading）→ 改 `deck.spec.json`，先重新跑一次 `pptwise spec validate`（阶段二的「不要重新定 spec」规则依然适用：只有在用户确实要求结构性改动时才这么做）。
-- 审查者在对话里提出的改动（通常附一张页面截图）→ 对照他描述的内容在 `deck.spec.json`/`pages/` 里找到那一页的 `pages/<id>.json`。把他的话当成一条需要你去理解的需求，而不是可以照抄的补丁：他描述的是渲染出来的 slide，不是在写页面文件 JSON——你自己要把它翻译成具体的内容改动，然后对每一页你动过的页面跑上面同一套内容改动流程（`assemble` + `validate` + `audit`）。preview 全程只读：除了你自己主动做出的编辑之外，没有任何环节会写入 `pages/*.json`。
+分享命令打印的准确 localhost 地址，在评审轮次中保留进程，结束时只停止这个进程。
 
-## 后续请求怎么分流
+## 在源头修订
 
-一旦 deck 项目已经存在，后续消息恰好分流进三条分支之一——动手之前先判断走哪一条：
+- 内容变化只编辑受影响的 `pages/<id>.json`，再依次运行 assemble、validate、audit 和 render。
+- 页面顺序、页型、kind、标题或主题绑定变化时，编辑 `deck.spec.json`，运行 `pptwise spec validate`，再重复项目检查。
+- 主题或受众完全不同的新任务应创建新项目，从意图与叙事重新开始。
 
-1. **改一页**（「改一下第 3 页」「把 KPI 那页写得更有冲击力」，或者一张截图加一句说明）→ 走阶段六：改那一页的文件，重新 assemble、重新 validate、重新 audit。没人问起的页面绝不去碰。
-2. **一份新 deck**（不同的主题、不同的受众，或明确要求重新开始）→ 走阶段一：新建一个 deck 项目目录，重新决定 narrative/theme，重新起一份 spec。
-3. **和 deck 生成无关**（关于内容本身的问题，或任何和 slides 没有关联的事）→ 完全不要调用 pptwise。
+聚焦修订时不要重新生成无关页面。把截图反馈解释为内容要求，修改拥有这项要求的最小源文件，并始终保持预览产物只读。

package/skills/pptwise/scripts/run.ps1

@@ -23,7 +23,7 @@ $ErrorActionPreference = 'Stop'
 # package.json version, and `pnpm release:version` rewrites it on every bump.
 $Package = '@liustack/pptwise'
 $Bin = 'pptwise'
-$Pinned = '0.22.0'
+$Pinned = '0.24.0'
 # ------------------------------------------------------------------------------
 
 # Environment snapshot, filled by Collect and read by the emitter.

package/skills/pptwise/scripts/run.sh

@@ -21,7 +21,7 @@ set -eu
 # package.json version, and `pnpm release:version` rewrites it on every bump.
 PKG="@liustack/pptwise"
 BIN="pptwise"
-PINNED="0.22.0"
+PINNED="0.24.0"
 # ------------------------------------------------------------------------------
 
 # Split "X.Y.Z" (extra suffix ignored) into the globals _MAJ, _MIN, _PAT.