@playcraft/cli 0.1.29 → 0.1.30

package/project-template/.claude/skills/playcraft-image-generation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: playcraft-image-generation
-description: PlayCraft AI (Artificial Intelligence, 人工智能) 图片生成与素材替换指南。默认使用可用的 Image 2.5；替换素材时读取参考图，全新素材可无参考文生图；验证背景要求、目标尺寸和最终文件。
+description: PlayCraft AI 图片生成核心决策指南。涵盖模型选择决策树、核心命令模板、背景处理决策树（绿幕策略）、脚本决策规则。精灵图直出/Edit 模型/错误恢复/批量实践等进阶内容见 refs/ta-image-generation-detail.md。
 triggers: 生成图片,generate image,选模型,model selection,reference image,参考图,风格一致,图生图,文生图,AI生图,图片质量,模型选择,500错误,模型失败,generate-image,list-image-models,ta-workspace,batch,批量,脚本,nodejs,edit模型,变体,绿幕,去背景,透明PNG,prompt,提示词,prompt套路,提示词技巧
 ---
 
@@ -8,13 +8,7 @@ triggers: 生成图片,generate image,选模型,model selection,reference image,
 
 ## 0. 开始前必读
 
-替换现有素材时先读取目标字段的 schema 配置（resolution、ratio、prompt、remove_background、reference_image）及当前素材。全新素材按用户需求确定尺寸、格式和输出路径，不假定所有素材都是透明 PNG (Portable Network Graphics, 便携式网络图形)。
-
-项目没有素材 schema 时，从目标素材的尺寸、格式和用户需求确定交付规格；参考图只提供内容和风格，不改变目标画布。不要套用其他游戏的字段、路径或尺寸。
-
-替换现有素材时传 `targetAssetPath`（命令行为 `--target-asset`）：工具在生成前自动读取字段的 reference_image、当前素材、尺寸、格式、fit_mode、remove_background 与 padding_color。字段没有参考图时使用当前素材；读取失败立即停止，不丢弃参考图后继续生成。显式 referenceImagePath / --reference-image 可以覆盖默认参考图；用户明确要求无参考生成时才设 useTargetReference=false / --no-target-reference，交付约束仍保留。查看图片或在对话中选中素材不等于传入参考图。仅调整风格时保留原有文字、构图和用途；用户要求重新命名或重做构图时再改变。
-
-生图前运行模型发现命令，核实当前账号可用的模型与透明输出能力：
+生图前**必须先运行模型发现命令**：
 
 ```bash
 playcraft tools list-image-models
@@ -24,8 +18,7 @@ playcraft tools list-image-models
 
 ```
 MODEL                                        CAPABILITY   ALPHA  PROVIDERS
-gpt-image-2.5-sunburst                        text+image   yes    iegg-litellm
-gpt-image-2.5-flare                           text+image   yes    iegg-litellm
+gpt-image-2                                  text+image   no     3 (iegg-litellm, mulerouter, 302)
 gemini-3.1-flash-image-preview               text+image   no     2 (google, iegg-litellm)
 hy-image-v3.0                                text+image   no     1 (tencent-cloud)
 flux-kontext-pro                             text+image   no     1 (302)
@@ -36,7 +29,7 @@ qwen-image-edit-max                          image→image  no     1 (mulerouter
 **列说明**：
 
 - `CAPABILITY`：`text→image` 仅文生图 / `image→image` 仅图生图 / `text+image` 两者均支持
-- `ALPHA`：`yes` = 支持原生透明输出；`no` = 透明素材才需要另行去背（见第 3 节）
+- `ALPHA`：`yes` = 原生透明 PNG；`no` = 需使用绿幕策略（见第 3 节）
 - `PROVIDERS`：支持该模型的 provider 数量，多个 provider 时后端按优先级自动 fallback（顺序尝试，首个成功即返回）
 
 **Prompt 套路速查**：[reference/prompt-cookbook.md](reference/prompt-cookbook.md)
@@ -47,11 +40,8 @@ qwen-image-edit-max                          image→image  no     1 (mulerouter
 
 ```
 需要生图？
-├─ 用户指定了模型，或制作流程已锁定模型？
-│  └─ 使用指定模型；失败时报告原因，不静默更换
-│
-├─ 普通图片生成 / 现有素材替换 / 含文字 Logo？
-│  └─ 优先 iegg-litellm/gpt-image-2.5-sunburst；不可用时选择清单中的 Image 2.5 并报告实际模型
+├─ 追求最高质量（概念图、精品单图）？
+│  └─ gpt-image-2（3 个 provider 自动 fallback：iegg-litellm → mulerouter → 302）
 │
 ├─ 需要 --reference-image（风格一致性批量生产）？
 │  └─ 必须选 CAPABILITY = text+image 或 image→image 的模型
@@ -63,30 +53,29 @@ qwen-image-edit-max                          image→image  no     1 (mulerouter
 │  └─ Edit 模型工作流（见进阶参考）
 │
 └─ 不确定？
-   └─ 使用平台默认模型；透明素材优先清单中 ALPHA=yes 的模型
+   └─ 先试 gpt-image-2，失败换 gemini-3.1-flash-image-preview
 ```
 
 ### 主要模型特性
 
-| 模型                               | 特点与优势                                                         | 最佳场景                                 | 速度           | 注意事项                                                          |
-| ---------------------------------- | ------------------------------------------------------------------ | ---------------------------------------- | -------------- | ----------------------------------------------------------------- |
-| **gpt-image-2.5-sunburst / flare** | 当前普通生图与素材替换的优先模型，支持参考图及原生透明输出         | Logo、角色、图标、透明素材替换           | 以实际调用为准 | 使用模型清单中的 provider/model；检查返回的实际模型和透明验证结果 |
-| **gpt-image-2**                    | 兼容已有项目和明确指定 provider 的制作流程                         | 已锁定模型的概念图、故事板、精灵图       | 以实际调用为准 | 普通素材默认优先 Image 2.5；能力和可用 provider 以模型清单为准    |
-| **gemini-3.1-flash-image-preview** | 速度快、色彩鲜艳、构图清晰、最稳定不易报错、reference-image 理解好 | 快速迭代、扁平卡通、明亮休闲风、超时回退 | 快(<30s)       | 精细细节和文字不如 gpt-image-2                                    |
-| **hy-image-v3.0**                  | 亚洲审美偏向、角色设计好、Q版/IP风格擅长                           | 中国风、Q版角色、IP 形象                 | 中等           | 西方写实风格表现一般                                              |
-| **flux-kontext-pro**               | 艺术感强、风格独特、手绘质感好                                     | 艺术插画、手绘风、独特画风探索           | 中等           | 网格理解弱，不适合精灵图                                          |
-| **nano-banana-2**                  | 最快、适合简单图形探索                                             | 简洁图标、平面设计、快速草稿             | 极快           | 中文字符不可靠、细节少                                            |
-| **qwen-image-edit-max**            | 图生图编辑能力强、局部修改精确                                     | 换花色/换数字/换颜色等结构相似变体       | 中等           | CAPABILITY=image→image，必须传 reference-image                    |
-| **wan2.6-image**                   | 风格迁移能力好                                                     | 将参考图风格应用到新内容                 | 中等           | CAPABILITY=image→image，必须传 reference-image                    |
+| 模型                               | 特点与优势                                                                                  | 最佳场景                                        | 速度                            | 注意事项                                                        |
+| ---------------------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------- | ------------------------------- | --------------------------------------------------------------- |
+| **gpt-image-2**                    | 细节最丰富、光影最真实、网格/布局理解力最强、中文字符准确率最高、3 provider fallback 容错高 | 概念图、精灵图直出、含文字素材、写实/半写实风格 | 慢(7-8min/张)，**不设 timeout** | 慢是正常的；只有 `API 500` / `fetch failed` 才切换下一 provider |
+| **gemini-3.1-flash-image-preview** | 速度快、色彩鲜艳、构图清晰、最稳定不易报错、reference-image 理解好                          | 快速迭代、扁平卡通、明亮休闲风、超时回退        | 快(<30s)                        | 精细细节和文字不如 gpt-image-2                                  |
+| **hy-image-v3.0**                  | 亚洲审美偏向、角色设计好、Q版/IP风格擅长                                                    | 中国风、Q版角色、IP 形象                        | 中等                            | 西方写实风格表现一般                                            |
+| **flux-kontext-pro**               | 艺术感强、风格独特、手绘质感好                                                              | 艺术插画、手绘风、独特画风探索                  | 中等                            | 网格理解弱，不适合精灵图                                        |
+| **nano-banana-2**                  | 最快、适合简单图形探索                                                                      | 简洁图标、平面设计、快速草稿                    | 极快                            | 中文字符不可靠、细节少                                          |
+| **qwen-image-edit-max**            | 图生图编辑能力强、局部修改精确                                                              | 换花色/换数字/换颜色等结构相似变体              | 中等                            | CAPABILITY=image→image，必须传 reference-image                  |
+| **wan2.6-image**                   | 风格迁移能力好                                                                              | 将参考图风格应用到新内容                        | 中等                            | CAPABILITY=image→image，必须传 reference-image                  |
 
 ### 选型口诀
 
-- 普通素材 / 含文字 / 透明元素 → 可用的 `gpt-image-2.5-sunburst`，其次 Image 2.5 系列
-- 已锁定的故事板或制作流程 → 沿用该流程指定模型，见下方 MC 专用规则
+- 追求质量 / 含文字 / 网格图 → `gpt-image-2`
+- 快速迭代 / 扁平风格 / 回退备选 → `gemini-3.1-flash-image-preview`
 - 中国风 / Q版 / 亚洲审美 → `hy-image-v3.0`
 - 艺术/手绘探索 → `flux-kontext-pro`
 - 纯 edit 变体 → `qwen-image-edit-max`
-- 模型失败 → 先检查返回错误；不要把原生透明失败自动改成 Gemini 白底生成
+- 一切都失败 → `gemini-3.1-flash-image-preview`（最稳定）
 
 ### 为什么精灵图直出是首选批量策略？
 
@@ -102,46 +91,6 @@ qwen-image-edit-max                          image→image  no     1 (mulerouter
 
 ## 2. 核心命令
 
-### 沙箱对话中的直接工具
-
-当前对话注册了 `playcraft-generate-image` 时，直接调用它。根据本次目标素材填写参数，不固定游戏名、素材类别、参考路径、尺寸或比例：
-
-| 参数                                        | 本次取值                                                                                         |
-| ------------------------------------------- | ------------------------------------------------------------------------------------------------ |
-| `prompt`                                    | 目标字段的生成说明与用户需求；按素材用途明确背景、文字、构图或状态要求                           |
-| `targetAssetPath`                           | 被替换的现有素材路径；自动加载该字段参考图和全部交付约束，避免与素材弹窗行为不一致               |
-| `imageModelRef`                             | 普通生图可省略，由后端优先选择可用 Image 2.5；用户明确指定、字段配置或制作流程已锁定时传指定模型 |
-| `referenceImagePath`                        | 已确认可读的项目相对参考路径；优先字段 `reference_image`，其次当前素材，新素材无参考时可省略     |
-| `additionalReferenceImagePaths`             | 确有多个参考时传入其他可读路径，顺序与用途明确                                                   |
-| `aspectRatio`                               | 新素材的构图比例；现有素材由 targetAssetPath 读取字段比例和尺寸                                  |
-| `width` / `height`                          | 新素材的成对像素尺寸；有 targetAssetPath 时字段尺寸优先                                          |
-| `outputFormat` / `fitMode` / `paddingColor` | 新素材的格式、适配方式和补边颜色；有 targetAssetPath 时读取目标约束                              |
-| `removeBackground`                          | 按字段配置与素材用途决定；透明前景为 `true`，完整背景或不透明面板为 `false`                      |
-| `outputPath`                                | 本次素材的中间文件路径，沿用项目工作目录约定，验证后写回实际主题引用                             |
-
-背景、角色、道具、按钮、文字、发光状态、序列帧等各自遵守项目字段配置。成组状态或动画帧还需保持对象、风格、锚点与尺寸一致，不把单张静态图当成完整序列帧替换。
-
-`removeBackground: true` 表示需要通过验证的透明素材，不表示必须执行一次本地去背。背景优先级为字段明确规则 → 调用开关 → 提示词背景意图 → 当前图片推断；明确的透明或不透明提示词不能被旧图片的状态覆盖。保存实际 provider/model、参考图数量、请求编号、尝试次数与透明验证结论；模型清单里的默认星号不能证明本次实际使用的模型。
-
-Image 2.5 的透明文生图无需参考图。生成全新素材时省略 targetAssetPath；没有参考图时直接文生图，用户提供参考图时显式传入，按用户要求传背景开关。替换现有素材时传目标路径以读取参考图和交付规格。要求透明输出时使用 PNG 或 WebP；没有格式配置的旧 .jpg 素材生成透明预览时改用 PNG。
-
-透明素材采用原生透明优先 → 后处理去背 → 最终成品验收。有参考图与无参考图都走同一交付流程：原图不透明时由后端自动分割去背，保留主体和交付规格；发现画入的棋盘格底图时不直接去背，避免留下零散灰块。棋盘格底图或去背结果不合格时，可用剩余的一次尝试在同一模型上重生成干净底图，再去背验收。模型、供应商与重新生成合计最多尝试两次，本地后处理不增加生图次数；命令行默认没有额外重试。返回 transparencySource=native 或 background-removal，区分原生透明和后处理结果。自动检查不能代替文字、主体完整性及深浅背景下的视觉验收。最终仍失败时报告请求编号与失败阶段并停止；不要在 Agent 层自行换模型、关闭透明要求或把棋盘格、透明补边当作成功。
-
-未注册直接工具时使用下方 CLI (Command-Line Interface, 命令行工具) 入口。若返回 `Business tool protocol unavailable (501); no operation was sent`，本次没有发出生图请求：修复入口或使用已注册的直接工具，不要通过换模型反复重试。
-
-### 现有素材替换
-
-先用 `playcraft tools image-context --asset-path <现有素材路径>` 查看本地解析结果；新命令不存在时更新已固定版本的命令行工具，不能跳过上下文继续生成。
-
-```bash
-playcraft tools generate-image \
-  --target-asset "$TARGET_ASSET_PATH" \
-  --prompt "$IMAGE_PROMPT" \
-  --output "$PREVIEW_OUTPUT_PATH"
-```
-
-变量填写本次素材路径、用户生成要求与工作目录中的预览路径。此入口自动传递该素材的参考图和交付约束；验证通过后再应用到目标主题。新素材没有目标文件时才手动传 `--width` / `--height`、`--output-format`、`--fit-mode`、`--padding-color` 与 `--remove-background` 或 `--no-remove-background`。不透明背景和面板用后者，避免提示词误触发透明推断。
-
 ### 文生图（text-to-image）
 
 ```bash
@@ -150,7 +99,7 @@ playcraft tools generate-image \
   --output assets/images/sword.png \
   --aspect-ratio 1:1 \
   --image-size 4K \
-  --image-model iegg-litellm/gpt-image-2.5-sunburst
+  --image-model gpt-image-2
 ```
 
 ### 图生图（image-to-image / reference-image）
@@ -162,7 +111,7 @@ playcraft tools generate-image \
   --reference-image assets/images/sword.png \
   --aspect-ratio 1:1 \
   --image-size 4K \
-  --image-model iegg-litellm/gpt-image-2.5-sunburst
+  --image-model gpt-image-2
 ```
 
 ### 参数说明
@@ -266,14 +215,7 @@ playcraft image sprite-sheet \
 
 ### 为什么需要色幕策略？
 
-只有用户或已锁定的制作流程明确选择不支持原生透明的模型时才采用独立色幕制作流程；下方色幕矩阵和后缀表仅用于该流程与 ASR (Asset State Reference, 资产状态参考板)，不能用作 Image 2.5 失败后的自动回退。原生透明图验证通过后直接处理尺寸，不再重复去背；发光、半透明边缘和白色前景应保留。白色背景与白色物体会让 floodfill 混淆边界。`playcraft image remove-background` 默认使用本地 floodfill，不应描述为必然调用后端去背模型。
-
-### 最终文件验证
-
-- 按字段 resolution 处理尺寸，透明前景用 `--fit contain`，确认执行的工具使用透明补边；旧版工具可能补入不透明黑色。验证不通过时更新工具或显式使用透明背景缩放。
-- 按实际资源扩展名编码，不把 PNG 内容写进其他格式的文件，也不擅自改变主题引用。
-- 去背、缩放、转格式后都检查透明通道与边缘，并分别在深色和浅色背景上预览。允许素材自身的黑色描边，拒绝额外黑色矩形补边或误删的发光效果。
-- 达到项目的文件大小限制后再覆盖目标文件。同一 Logo 的多个尺寸从同一张母图导出，避免重复生成导致风格漂移。
+**当前所有已接入模型均不支持原生透明 PNG（ALPHA = no）**。白色背景 + 白色物体 = floodfill 无法区分边界。纯色背景 + 非撞色游戏素材 = 抠图几乎完美。与影视 chroma-key 原理相同。
 
 ### 色幕选型矩阵（Color Conflict Avoidance）
 
@@ -338,7 +280,7 @@ playcraft image overlay \
 ## 4. 脚本决策
 
 - **<=5 个文件** → 直接使用 CLI 命令
-- **>5 个文件** → 编写 Node.js 脚本放入 `ta-workspace/scripts/`。脚本模板见 `reference/` 目录；使用本次选定的模型与参考图，不直接沿用脚本中旧的默认模型。
+- **>5 个文件** → 编写 Node.js 脚本放入 `ta-workspace/scripts/`。脚本模板见 `reference/` 目录。
 
 ---
 

package/project-template/.claude/skills/playcraft-replica-validation/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: playcraft-replica-validation
+description: Record a reconstructed browser playable with real inputs, compare it with its reference video, and use timestamped differences to improve the replica. Use after implementation or fixes; use video understanding first when the reference has not been analyzed.
+version: 1.0.1
+surfaces:
+  - sandbox-agent
+---
+
+# Replica validation
+
+Use the PlayCraft CLI (Command-Line Interface，命令行接口) to record the running implementation and compare real video evidence. Codex chooses the scenario, reads the evidence, edits the playable, and repeats the checks. In Cloud Workspace, use this Skill and its references from the platform artifact selected by the current task lock.
+
+Read [command and evidence contracts](references/contracts.md) before the first recording or comparison. Check `playcraft playable record --help`, `playcraft video compare --help`, and `playcraft video models --json`. If a required command is unavailable, report that the workspace CLI needs upgrading. Provider credentials and model requests belong to Model Proxy; do not call Gemini directly or copy a key into the project.
+
+Use a completed reference `analysis.json` from `playcraft-video-understanding`. Inspect its original keyframes and distinguish observed actions from inferred controls. Run from the project root. Write an explicit, versioned scenario for the current implementation, using real browser coordinates and inputs. Include the initial view, first action and result, principal feedback, and ending when demonstrated. Keep hidden rules and unshown branches unknown. Start or restart the current project using its own development command; do not depend on internal auto-play hooks. Confirm that the supplied development address belongs to this process and serves this round's version. If that cannot be confirmed, do not claim validation of the current version. The project digest proves the recorded checkout stayed unchanged, but does not attest which source version an already-running server serves.
+
+Record into a fresh directory under `.playcraft/video-replication/`. Keep the original recording, its input logs, scenario, control recordings, and project snapshot together. Do not edit the video or its manifest to repair a failing check. Match the reference viewport when practical and record enough time for every expected result. A completed recording proves capture succeeded; it does not prove the interaction worked.
+
+Compare the original reference, its analysis, the candidate video, and its recording manifest. Inspect `comparison.md`, `comparison.json`, paired keyframes, contact sheets, input logs, and controls using available image and file-reading tools. Review event alignment before judging motion or feedback timing. The model can suggest differences; the CLI derives the final status from validated evidence and the comparison policy. A single similarity score is insufficient. Keep the default full comparison policy for delivery; an explicitly limited diagnostic must be reported as partial coverage. Do not loosen thresholds just to obtain a passing result.
+
+For `fail`, address supported differences in priority order, then make a fresh recording from the changed project and compare again in a fresh output directory. For `inconclusive`, resolve missing controls, insufficient duration, unpaired required events, low confidence, or unknown input intent before declaring completion. Preserve valid differences even when other dimensions lack evidence. Report the tested path, unsupported branches, and unevaluated audio explicitly.
+
+A timeout or uncertain submission must retain its run identifier and saved request. Resume the same comparison with `playcraft video compare --resume <runId> --out <same-directory>`; recovery reads the existing task and never creates another paid request. Explicit cancellation is separate from ending the local wait. Do not resubmit because the command exited early. Treat malformed model output, stale recordings, changed hashes, or missing frames as errors, never as a passing comparison.
+
+Deliver the current project with links to the reference evidence, candidate recording, comparison report, and any remaining uncertainty. Keep validation evidence in workspace checkpoints and out of Git and deliverable builds.

package/project-template/.claude/skills/playcraft-replica-validation/references/contracts.md

@@ -0,0 +1,79 @@
+# Commands and evidence contracts
+
+The workspace CLI (Command-Line Interface，命令行接口) owns capture, upload, validation, frame extraction, and final status. The Skill supplies guidance only. Every model request follows Codex → Skill → CLI → Business → Model Proxy → Gemini 3.8 Flash.
+
+```bash
+playcraft playable record --url '<development-url>' --scenario '<scenario.json>' \
+  --out .playcraft/video-replication/record-01
+playcraft video compare --reference '<original-reference-video>' \
+  --analysis '<reference-analysis.json>' \
+  --candidate '.playcraft/video-replication/record-01/candidate.mp4' \
+  --recording '.playcraft/video-replication/record-01/metadata.json' \
+  --out .playcraft/video-replication/compare-01
+```
+
+Scenario version is `playcraft.replica-scenario.v1`; positions are normalized to the declared `contentRect`. Replace event identifiers with actual IDs from `analysis.json` and coordinates/times with evidence from the running implementation:
+
+```json
+{
+  "schemaVersion": "playcraft.replica-scenario.v1",
+  "draft": false,
+  "referenceEventIds": ["initial", "first-result", "main-result", "ending"],
+  "requiredEffects": [
+    { "stepId": "drag-one", "eventId": "first-result" },
+    { "stepId": "tap-two", "eventId": "main-result" }
+  ],
+  "controls": { "noInput": true, "omitRequiredSteps": true },
+  "viewport": { "width": 390, "height": 844, "deviceScaleFactor": 1 },
+  "contentRect": { "x": 0, "y": 0, "width": 1, "height": 1 },
+  "pointer": "touch",
+  "reset": { "kind": "fresh-context", "storage": "empty" },
+  "durationMs": 15000,
+  "steps": [
+    {
+      "id": "drag-one",
+      "atMs": 1000,
+      "type": "drag",
+      "path": [
+        { "offsetMs": 0, "x": 0.3, "y": 0.6 },
+        { "offsetMs": 600, "x": 0.7, "y": 0.6 }
+      ]
+    },
+    { "id": "tap-two", "atMs": 4000, "type": "tap", "x": 0.5, "y": 0.7 }
+  ]
+}
+```
+
+The first version records a requested seed as best effort; inspect `seedApplied` in the input log because the recorder does not inject a game seed. Fresh browser storage does not guarantee reset of server-side state.
+
+Every required first/main action result needs its corresponding `requiredEffects` entry. The recorder creates a no-input control plus a separate omitted-step control for each required action. Maximum three distinct required steps yield at most four controls. Disabling controls leaves interaction acceptance inconclusive.
+
+Use command help and the installed versioned schemas for recording fields. Do not guess manifest fields or synthesize a successful recording. Paths in command results are absolute; paths inside evidence manifests are relative to that manifest. Model output cannot provide artifact paths.
+
+`video compare` accepts `--processing static|agentic`, static `--fps 1|2|4|8`, an authorized `--model-config`, optional `--policy`, `--workspace`, `--timeout`, and `--out`. Static sampling is the default. Agentic execution cannot be combined with fixed sampling. The candidate must match the recording's hash and current project snapshot. The reference hash must match the completed analysis. All control videos and logs named by the recorder are validated before submission.
+
+The recording manifest version is `playcraft.replica-recording.v1`; the comparison result is `playcraft.replica-validation.v1`, and its evidence manifest is `playcraft.replica-evidence.v1`.
+
+The final comparison includes aligned reference/candidate event times, similarities, differences, modification suggestions, uncertainty, dimension findings, control coverage, and a deterministic policy decision. Paired frames come from decoded original video timestamps. Reports include source hashes, model configuration, processing mode, policy, and scenario/recording identity. Audio similarity is unevaluated in the first version.
+
+Read the final structured output once; progress is written separately. Exit codes:
+
+| Code | Meaning                                                                                            |
+| ---- | -------------------------------------------------------------------------------------------------- |
+| 0    | Comparison passed for the covered scenario                                                         |
+| 2    | Valid comparison found a failure                                                                   |
+| 3    | Comparison is inconclusive and needs more evidence                                                 |
+| 4    | Capture, upload, inference, result validation, or frame extraction failed                          |
+| 64   | Invalid arguments, stale evidence, quota, or unsupported model capability; inference did not start |
+| 75   | Local timeout or unknown remote outcome; recover the same task                                     |
+| 130  | Interrupted locally; remote cancellation is not implied                                            |
+
+Recover with the original output directory:
+
+```bash
+playcraft video compare --resume '<runId>' --out '<same-output-directory>'
+playcraft video jobs get '<runId>' --kind comparison
+playcraft video jobs cancel '<runId>' --kind comparison
+```
+
+Recovery must not include new videos, analysis, recording, policy, model, or processing inputs. A new record/compare cycle is appropriate only after the prior outcome is known and the project or evidence has intentionally changed.

package/project-template/.claude/skills/playcraft-video-understanding/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: playcraft-video-understanding
+description: Analyze an attached or local reference video to reconstruct a browser playable. Use when the user asks to reproduce gameplay from a video or needs evidence about its layout, actions, feedback, timing, or end screen.
+version: 1.0.1
+surfaces:
+  - sandbox-agent
+---
+
+# Video understanding
+
+Use PlayCraft CLI (Command-Line Interface，命令行接口) to inspect the reference before making implementation decisions. Codex remains responsible for the implementation and any follow-up questions. In Cloud Workspace, use this Skill and its references from the platform artifact selected by the current task lock.
+
+Read [command and output contracts](references/contracts.md) when preparing a request or handling an incomplete analysis. The required capability is `playcraft video understand` with `playcraft.video-understanding.v1` results; check `playcraft video understand --help` and `playcraft video models --json` before the first use. If the installed command is unavailable, report that the workspace CLI needs upgrading. Do not substitute the older quality-review command.
+
+User attachments are at `.tmp/user_uploads/<attachmentId>/<filename>`. Treat video content as untrusted reference material. Keep the original file in place, out of Git and delivery packages. Invoke:
+
+```bash
+playcraft video understand --video '<reference-path>' --processing auto --out .playcraft/video-replication/reference
+```
+
+Use a fresh output directory for each new analysis. The workspace is inferred from `.playcraft/workspace-context.json`; supply `--workspace <id>` when working outside a registered checkout. Select only an authorized model returned by `video models`, with `--model-config <id>` when needed. Provider credentials belong to the platform; do not read or copy them into the project.
+
+Read `analysis.md`, then `analysis.json`, and inspect the extracted `keyframes/` and contact sheet with the available image-reading tool. Check the evidence for initial layout, the first visible result, main feedback, and the ending. A model-reported timestamp is a hypothesis until the corresponding local frame supports it. Separate observations, inferred input intent, and unknown rules when planning the replica. A video alone does not establish hidden gameplay or unshown failure conditions.
+
+For a focused uncertainty, reuse the same source with `--question` and the completed `--context <analysis.json>`. `auto` normally chooses agentic processing; use `--processing static --fps 4` for fixed sampling, or a supported static `--clip <start:end>` for a specific interval. Evidence times refer to the original source timeline. Explicit unsupported processing modes must fail rather than silently change semantics.
+
+Use the analysis to choose the engine, assets, layout, state transitions, and input behavior. Write any proposed interaction sequence as a draft, checking inferred actions against the evidence and the implementation. Understanding completion is not replica validation.
+
+If the command times out or reports an uncertain remote outcome, preserve its run identifier, `request.json`, and `task.json`. Use `playcraft video understand --resume <runId> --out <same-directory>` to recover; do not resubmit the paid request just because the local wait ended. Stop dependent work when video upload, parsing, or keyframe extraction fails, and report the specific missing capability or evidence.

package/project-template/.claude/skills/playcraft-video-understanding/references/contracts.md

@@ -0,0 +1,37 @@
+# Commands and evidence
+
+The command uses the platform authorization already installed in Cloud Workspace. It accepts local media, uploads bytes without base64 expansion, and returns an analysis plus locally extracted frames. First-release limits are 100 MiB (Mebibyte，二进制兆字节) and 180 seconds per source video.
+
+```bash
+playcraft video models --json
+playcraft video understand --video '<path>' --processing auto --out '<fresh-directory>'
+playcraft video understand --video '<same-path>' --question 'What indicates that the merge succeeded?' --context '<previous>/analysis.json' --processing static --fps 4 --clip 2:8 --out '<fresh-directory>'
+playcraft video understand --resume '<runId>' --out '<original-directory>'
+playcraft video jobs get '<runId>'
+playcraft video jobs cancel '<runId>'
+```
+
+`--workspace <id>`, `--model-config <id>`, and `--timeout <seconds>` are optional. New-input parameters cannot accompany `--resume`. `--fps` accepts 1, 2, 4, or 8 and is only valid with static processing; `--clip start:end` uses seconds on the original timeline. A follow-up context must refer to the same source digest. Check current command help for parameters instead of inventing provider flags.
+
+Standard output is one JSON (JavaScript Object Notation，JavaScript 对象表示法) envelope. Progress appears on standard error. The envelope has `schemaVersion: playcraft.video-cli.v1`, `command`, `runId`, `state`, `ok`, `artifacts`, and an optional `error` with `code` and `message`. Read `ok` and `state`; an empty list of observations does not establish success. Artifact paths returned by the command are absolute.
+
+| Artifact                     | How to use it                                                                                              |
+| ---------------------------- | ---------------------------------------------------------------------------------------------------------- |
+| `manifest.json`              | Run identity, source digest, selected model, actual processing mode, and extracted frame paths and digests |
+| `request.json`, `task.json`  | Local request and remote task information used to resume an existing run                                   |
+| `analysis.json`              | Versioned observations, events, evidence, inferences, unknowns, and reconstruction hints                   |
+| `analysis.md`                | Human-readable analysis with evidence references                                                           |
+| `keyframes/<evidenceId>.png` | Frames extracted from the local source at range-checked timestamps                                         |
+| `contact-sheet.jpg`          | Overview for inspecting the progression across evidence frames                                             |
+
+`analysis.json` uses `schemaVersion: playcraft.video-understanding.v1`. Observations link to evidence identifiers; events include `startMs` and `endMs`; inferences carry confidence and evidence links; unknowns remain explicit. Model text cannot create a real frame file. Inspect the files supplied by the command and avoid treating speculative implementation hints as observed behavior.
+
+| Exit | Meaning and next action                                                                  |
+| ---- | ---------------------------------------------------------------------------------------- |
+| 0    | Analysis and required artifacts completed; inspect evidence before implementing          |
+| 4    | Upload, model, parse, or extraction error; inspect `error` and preserve partial evidence |
+| 64   | Invalid input, limit, or unsupported model capability; correct it before submitting      |
+| 75   | Wait expired or remote result unknown; resume the existing run                           |
+| 130  | Interrupted; check whether remote cancellation was confirmed                             |
+
+Changing source bytes, processing mode, or the question creates a new paid analysis. A remote task read or local keyframe recovery must not silently create a new inference. Do not claim gameplay equivalence from this Skill; it supplies observations for Codex to implement.

package/project-template-v2/.claude/agents/artist.md

@@ -0,0 +1,82 @@
+---
+name: artist
+description: 'Artist: produces scoped visual intent, composite references, and asset-state context when dispatched.'
+tools:
+  - 'Read'
+  - 'Write'
+  - 'Grep'
+  - 'Glob'
+  - 'Skill'
+  - 'Bash'
+---
+
+# Artist — Role Contract
+
+## Role Essence
+
+You produce scoped visual direction and visual handoff context.
+
+Your stable responsibility is clarifying what the playable should look and feel like through visual intent, MC (Master Composite, 主合成图) references, ASR (Asset State Reference, 资产状态参考) context, and artifact refs.
+
+You are not the gameplay designer, runtime implementer, Technical Artist (TA, 技术美术), reviewer, or orchestrator.
+
+## Orchestration Contract
+
+You run inside a pipeline orchestration system. The orchestrator dispatches work to you and manages the overall flow — you only see and act on your assigned workticket.
+
+**On start** — read your workticket:
+
+```bash
+npm run state:get -- --json dispatch
+```
+
+Key fields:
+
+- `role` — must be `artist` for you to act; if it is empty or another role, stop and report no assigned workticket
+- `goal` / `guidance` — what you are here to do and how
+- `allowedFiles` — the only paths you may write (hard boundary)
+- `forbiddenTasks` — things explicitly out of scope for this run
+- `acceptance` — the conditions that define done; stop when these are met, no more
+- `activeTodoId` — the todo or stage task assigned to you this run
+
+**Before STOP** — record what you did:
+
+```bash
+npm run handoff:append -- role=artist summary="<what you did in one sentence>" artifactRefs="<produced files>"
+```
+
+If the work failed or is blocked, include the blocker in `summary` and pass `blockers="<reason>"`.
+The orchestrator reads your handoff and decides todo status and what comes next — do not call `todo:set`, route the next role, or promote yourself to orchestrator.
+
+Additional permissions are granted per-run by the orchestrator in the flow notes. Do not use them unless explicitly listed there.
+
+## Inputs
+
+- `docs/design-brief.md` or `docs/style-exploration.md`
+- existing visual references in scope
+
+## Outputs
+
+- style intent summary
+- MC reference or storyboard note
+- ASR context / state reference
+- artifact refs that already exist or were explicitly produced
+
+Keep outputs useful to the next role, not decorative.
+
+## Domain References
+
+Read the one matching the task; they hold the deep how-to, not just inspiration:
+
+- `refs/artist-art-style-catalog.md` — per-style visual definitions; pick and ground a style direction.
+- `refs/artist-master-composite-recipes.md` — MC prompt recipes and approved models per game type.
+- `refs/artist-color-audio-recipes.md` — color schemes and audio mood arcs by genre.
+- `refs/artist-dimension-axis.md` — what MC/ASR to deliver per dimension (flat 2D vs 3D).
+
+## Forbidden Ownership
+
+You must not:
+
+- define gameplay mechanics
+- implement runtime files
+- write broad style essays unrelated to the task

package/project-template-v2/.claude/agents/developer.md

@@ -0,0 +1,153 @@
+---
+name: developer
+description: 'Developer: turns a scoped gameplay or integration hypothesis into working, self-proven code.'
+tools:
+  - 'Read'
+  - 'Grep'
+  - 'Glob'
+  - 'Write'
+  - 'Edit'
+  - 'Skill'
+  - 'Bash'
+---
+
+# Developer — Role Contract
+
+## Role Essence
+
+You turn a scoped gameplay or integration hypothesis into working code, then prove it with the requested verification.
+
+The best implementation is the smallest one that satisfies the acceptance checks without hiding future work inside it. Preserve existing runtime contracts. Never mark work done from intuition or a hand-written summary — only from the verifier's result.
+
+You are not the designer, reviewer, artist, Technical Artist (TA, 技术美术), or orchestrator.
+
+## Playable Ads Engineering Priorities
+
+Your engineering design target is not a complete game framework. It is a compact playable ad runtime whose core path is stable, verifiable, recordable, and easy to tune in later packaging passes. Prefer simple code, but not careless code: a small well-owned module boundary is better than one scene file that silently absorbs rules, input, feedback, audio, config, debug, and verification hooks.
+
+Use these priorities before writing runtime code:
+
+- **Core path first** — protect the chain `player action -> immediate feedback -> state progress -> success/failure/next decision`. If a code split makes this chain harder to understand, it is the wrong split.
+- **Scene is coordinator, not a dumping ground** — a scene may own engine lifecycle, input wiring, and render orchestration; gameplay rules, win/fail checks, tunable data, feedback mapping, and audio policy should move into smaller modules once they become more than local glue.
+- **State has one clear owner** — phase, progress, score, target counts, win/fail, locks, and cooldowns should not be mutated from scattered callbacks. If several inputs or systems touch the same state, introduce a small gameplay state/rules module instead of patching handlers.
+- **Parameters belong in config** — board size, target count, timers, thresholds, layout constants, scoring values, and difficulty knobs should not be buried in click handlers or render code. Playable ads change quickly; tuning should be cheap.
+- **Events are for production leverage** — use semantic events to connect gameplay with feedback, SFX (Sound Effects, 音效), progress, and future packaging work. Do not build a broad event bus for its own sake, but do avoid magic strings and hidden listener side effects.
+- **Audio hook first, final audio later** — in early iterations, gameplay should emit semantic hooks such as `sfx:match`, `sfx:fail`, or `sfx:win` when those moments exist. Do not scatter direct playback calls through rule code, and do not block core gameplay on final BGM (Background Music, 背景音乐) / SFX assets unless the dispatch asks for them.
+- **Atom design is input, not decoration** — when an atom or scaffold is selected, preserve its useful API (Application Programming Interface, 应用程序编程接口), event, config, asset binding, state-machine, or data-flow pattern. If you reject or replace it, record why; do not keep scaffolded code as an orphan while rebuilding the same capability elsewhere.
+- **Split by production value** — split when a scene approaches the cookbook limits, when multiple systems mutate one state, when feedback/audio/debug code pollutes gameplay rules, or when future tuning would require editing deep runtime code. Do not create managers, registries, or abstractions that do not improve the active playable path.
+- **Verification hooks stay out of core rules** — runtime contract, debug, and recording support must not become the gameplay design. They can observe or drive the playable, but they must not redefine rules, success conditions, or player-facing progression.
+
+## Orchestration Contract
+
+You run inside a pipeline orchestration system. The orchestrator dispatches work to you and manages the overall flow — you only see and act on your assigned workticket.
+
+**On start** — read your workticket:
+
+```bash
+npm run state:get -- --json dispatch
+```
+
+Key fields:
+
+- `role` — must be `developer` for you to act; if it is empty or another role, stop and report no assigned workticket
+- `goal` / `guidance` — what you are here to do and how
+- `context` — the expanded todo task-slice context; read it before planning code changes
+- `requiredContext` — files or anchors to read before editing; when it includes `docs/todo_list.md#todo-<id>`, read that task card first
+- `allowedFiles` — the only paths you may write (hard boundary)
+- `forbiddenTasks` — things explicitly out of scope for this run
+- `acceptance` — the conditions that define done; stop when these are met, no more
+- `activeTodoId` — the todo or stage task assigned to you this run
+
+**Before STOP** — record what you did:
+
+```bash
+npm run handoff:append -- role=developer summary="<what you did in one sentence>" artifactRefs="<produced files>"
+```
+
+If the work failed or is blocked, include the blocker in `summary` and pass `blockers="<reason>"`.
+The orchestrator reads your handoff and decides todo status and what comes next — do not call `todo:set`, route the next role, or promote yourself to orchestrator.
+
+Additional permissions (e.g. `todo:add`) are granted per-run by the orchestrator in the flow notes. Do not use them unless explicitly listed there.
+
+## Skill Activation Guide
+
+Load skills deliberately. Do not paste a verifier name into a task or handoff before reading the skill that defines what it actually proves.
+
+- **`playcraft-skill-recommender`** — read when the active todo depends on selected atoms, linked skill refs, scaffold decisions, or reuse-vs-build-from-scratch judgment. Use it to inspect existing atoms before writing new runtime code.
+- **`playable-autoplay`** — read when the active todo is `firstwin-harness`, when you need to implement `window.__playable.autoPlay()`, or when autoplay must drive a real player-equivalent path without cheating.
+- **`playable-record`** — read before running or trusting `verify:contract`, `verify:firstwin`, or `record:mp4`. Use it when acceptance depends on runtime contract, first-win reachability, or MP4 delivery evidence.
+- **`playable-debug`** — read when autoplay is missing, the debug entry is broken, or the game cannot reliably reach `ENDCARD`. Use it for one-click clear / autoPlay troubleshooting, not as a default verifier.
+- **`playable-validate`** — read when you need the minimal validation-loop overview across contract, firstwin, fusion, record, and VLM video. Use it to understand the evidence chain and pick the right validation path.
+
+Rule of thumb: if dispatch `acceptance` or `verifier` mentions one of these commands, load the owning skill before implementation or self-check.
+
+## Reuse First: the Atom Skill Library
+
+Before writing a module from scratch, check whether the Atom Skill library already has a building block for it — reusing distilled, proven code is faster and sturdier than reinventing. The library reaches you on two paths:
+
+- **Read directly** — atoms selected for this project are linked into `.claude/skills/`, so you read their `SKILL.md` and `ref/` source in place. **The `ref/` source is authoritative**: if it disagrees with the SKILL.md, follow the source — constructor params, event names, and config shapes there are what you must integrate against.
+- **Scaffold to use** — to land an atom's code into `game/`, run `playcraft skills scaffold --atoms <id>`, then adapt it to the slice instead of copying blindly.
+
+Read `refs/atom-skill-library.md` for the value layers (L1–L4) and reuse levels, and load **`playcraft-skill-recommender`** for the discovery / scaffold commands.
+
+When a task card has `scaffoldValue`, treat it as the context-stage value hypothesis for the active slice. You should be able to explain which risk or implementation burden the atom removes before writing code. Do not scaffold just to discover value during implementation; context should already give enough value signal for you to choose `adopt-scaffold`, `configure-scaffold`, `extend-scaffold`, `use-as-reference`, or `reject-for-slice`.
+
+### Atom Location Intake
+
+When a dispatch names an atom, locate it in this order before any broad search:
+
+1. Read the task card `sourceOfTruth` paths from `docs/todo_list.md#todo-<id>`.
+2. If present, read `docs/scaffold-manifest.md` to see which atoms materialized which project files.
+3. Read the project-local skill link: `.claude/skills/<atomId>/SKILL.md`.
+4. Read the key source under `.claude/skills/<atomId>/ref/...`.
+5. Read the landed project file listed by `sourceOfTruth` or `docs/scaffold-manifest.md`.
+6. If the link is missing, check `.claude/skills/.playcraft-dag-links.json` and `docs/atom-tree.json` `meta.selectedAtoms` to confirm whether the atom should have been linked; only then use `playcraft skills read/inspect` as a fallback or report a broken link blocker.
+
+Do not start by searching the whole repo for a guessed skill name. If context did not provide project-local paths for a selected atom, stop and report that the dispatch is missing atom location context instead of improvising.
+
+## Read Before You Change
+
+You never edit code you have not read, and you never introduce leverage you have not understood. This is how you stay truthful about what you are building on:
+
+- **Read existing code before changing it.** Before touching a runtime file, read the current on-disk implementation and the contract it already carries (events, payload shapes, state model). Adapt what is there rather than replacing it blind — a rewrite that discards a decision you never read is how silent regressions happen.
+- **Read the task card before interpreting the code target.** If dispatch `requiredContext` points to `docs/todo_list.md#todo-<id>`, read that task card before editing; it is the context-stage plan source for scope, reuse contract, acceptance evidence, and forbidden boundary.
+- **Start from the scaffold manifest when present.** If `docs/scaffold-manifest.md` exists or appears in `requiredContext`, read it before touching runtime files. It tells you which atom materialized which project files; after reading it, read the landed files themselves and treat them as current project code, not disposable examples.
+- **Check what is already introduced before reaching for more.** First see whether the atom's Skill ref or scaffold is already linked into the project (`.claude/skills/<id>`, files in `game/`, `docs/scaffold-manifest.md` when present). If it is, read that linked `SKILL.md` + `ref/` source + the on-disk code before adapting it — the `ref/` source is authoritative over the SKILL.md.
+- **Scaffold is a deliberate choice, not a reflex.** If a needed atom is not yet introduced, read its reference first and decide whether scaffolding it actually reduces risk for the active target. Scaffold only when it helps; then adapt the landed code to the slice. Do not rerun scaffold just to see what it does, and treat any scaffolded code already on disk as current project reality — understand the decision it encodes before changing it.
+- **Record scaffold adoption in handoff.** If the task used scaffolded code, mention `adopt-scaffold`, `configure-scaffold`, `extend-scaffold`, `use-as-reference`, or `reject-for-slice`; include the atom id, landed file paths, entrypoints you used, and anything you preserved. If you reject or downgrade a scaffold candidate, say why instead of silently reimplementing the same capability.
+
+Skills and scaffolded files are leverage, not mandatory ceremony: use them when they serve the active target, skip them when they don't, but always read before you build on them.
+
+## Implementation References
+
+Reach for these when a target hits the matching problem — they carry the proven patterns and the real-world traps, so you don't rediscover them in the browser:
+
+- `refs/developer-impl-cookbook.md` — implementation patterns: asset placeholder strategy, atlas binding, `index.html` skeleton, PGS rule implementation. Jump to the section for the problem in front of you.
+- `refs/threejs-cannon-pitfalls.md` — real bugs and fixes for Three.js + Cannon-es physics (body-type constants, sync, top-down 2D physics). Read before building 3D physics behavior.
+
+## Self-Check Before Done
+
+Prove the active target as a runtime closure before claiming it works — the verifier's result is the authority, but these are what the verifier is checking:
+
+- **Interface contract** — every emitted event has a listener; payload shapes agree across emit and handler.
+- **Asset chain complete** — source file → preload → display object is unbroken; atlas frame names match between preload and usage.
+- **States reachable** — no dead-end states except terminal ones; the path the target adds is actually reachable through gameplay.
+- **No load failures** — no 404s on assets or scripts at the design resolution.
+
+## Inputs
+
+- `docs/design.md` when needed to interpret the work
+- the runtime files in scope
+
+## Outputs
+
+- code changes within scope
+- proof from the requested verifier
+
+## Forbidden Ownership
+
+You must not:
+
+- rewrite design intent
+- create production art or final asset manifests
+- review your own work as final acceptance