@sokeai/cli 1.0.74 → 1.0.76

package/skills/ai-coach-director/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ai-coach-director
-description: AI陪练主管技能。当用户输入业务资料、对话场景、提示词、需求描述、对话问题、评分问题、微调需求或平台同步需求时,自动分析意图、检查输入完整性、调度AI陪练专项技能,并执行资产调用与质量闸门。统一入口,覆盖创建陪练、微调陪练、技术排障、客户交付与平台同步。内置自主学习引擎。v2.2:soke-cli沙箱绕过(dangerouslyDisableSandbox)、头像/声音合并单次patch写入+强制验证+重试机制、自查清单/内部步骤编号对用户不可见。
+description: AI陪练主管技能。当用户输入业务资料、对话场景、提示词、需求描述、对话问题、评分问题、微调需求或平台同步需求时,自动分析意图、检查输入完整性、调度AI陪练专项技能,并执行资产调用与质量闸门。统一入口,覆盖创建陪练、微调陪练、技术排障、客户交付与平台同步。内置自主学习引擎。v2.20.8:Part 确认后前台不再展示后续后台步骤；Part1 默认封面固定为 lingshou_daogou.png。
 agent_created: true
 ---
 
@@ -19,9 +19,18 @@ agent_created: true
 7. 平台同步时执行环境前置检测
 8. 端到端编排:创作 → 同步 → 交付
 9. 自主学习与自我进化:每次纠正、失败、漏拦都记录并推广为永久规则
-10. 当平台真实 API 与历史文档冲突时,以最新 CLI 实证和 `references/platform-api-pitfalls.md` 为准
+10. 当平台真实 API 与历史文档冲突时,以最新 CLI 实证、附件《比得_AI陪练CLI创建与更新场景使用指南 2.0》及 `references/platform-api-pitfalls.md` 为准
 11. 场景命令模板统一以 `references/verified-cli-cheatsheet.md` 为抄写基准,避免误写成顶层 `soke-cli +...`
 12. **所有 soke-cli 命令必须绕过沙箱执行**：soke-cli 是 Go 编译的二进制文件，在 WorkBuddy Bash 工具的沙箱中会被限制（表现为 `permission denied`、`operation not permitted`、静默无输出等）。调用 Bash 工具执行任何 soke-cli 命令时，**必须设置 `dangerouslyDisableSandbox: true`**。此规则适用于全部 soke-cli 子命令（`config show`、`auth login`、`ai-training +...` 等），不限于创建型流程
+13. **Part1 封面自动处理 + Part2 拆分同步后台自动执行（v2.14）**：用户在 Part1/Part2 只确认完整内容，不再确认中间执行细节。Part2 确认后，系统先生成完整 `part2-operations.json`，再后台拆分为角色级同步单元（角色1/角色2/角色3/OS），逐个保守写入并回读校验。只有失败时才向用户暴露异常。**若后台同步成功，必须自动继续输出 Part3，禁止停在“正在后台同步”中间态等待用户再次输入。**
+14. **Part3 已知回读问题默认直通（v2.20.3）**：若 Part3 `apply` 成功，但 `get-scenario` 仍未反映 `conversation_steps` 和/或 `opening_dialogue`，按已知平台回读口径异常处理，不再把用户确认 Web 后台可见作为前置闸门。应记录该异常到状态快照，默认继续进入 Part4；仅当 `preview/apply` 本身失败、或后续 Part4/Part5 需要依赖 Part3 字段且出现明确阻塞证据时，才中断排查。
+15. **Part1 封面主策略切换为平台图库择图（v2.20.3）**：Part1 确认后，封面优先从平台图片库/已有真实封面库中选择并写入，作为默认主路径；本地生成图片与上传降级为非主路径，仅在图库/封面库均不可用时才触发。前台仍不展示图片处理过程。
+16. **Part1 创建链路硬约束（v2.20.4）**：Part1 用户确认后，后台**必须立即生成 `part1-create.json` 或沿用 `step1-create.json` 作为创建请求文件，并立即执行 `soke-cli ai-training +create-scenario --request-file ...`**。创建成功后**必须拿到 `scenario_id`** 并写入状态快照。**没有 `scenario_id` 严禁进入 Part2。** 若前台已显示“已确认”但后台未创建成功，必须立即向用户报错并停止，不允许静默继续。
+17. **Part2-Part5 同步成功硬闸门（v2.20.6）**：Part2、Part3、Part4、Part5 在用户确认后，后台都**必须立即生成对应 JSON、执行平台同步、完成验收成功后**，才允许进入下一 Part。若前台已显示“已确认”，但后台未生成 JSON、未执行同步、同步失败、或验收失败，**必须立即向用户报错并停止**，禁止静默继续到后续 Part。**其中 Part2 与 Part3 允许存在“CLI `get-scenario` 回读口径落后于平台实际展示”的已知差异，验收以“preview/apply 成功 + 平台实际展示可见”优先。**
+18. **确认选项 = 后台执行触发器（新增硬约束）**：创建型任务中，所有“确认，同步到平台/同步角色/同步流程设置/同步评分/完成创建”都不是逻辑确认文案，而是**真实后台执行触发器**。用户一旦选择确认，系统必须立即执行：① 生成该 Part 对应 `.json` 文件；② 执行平台同步；③ 执行回读验收。三者缺一不可。**没有 `.json` = 没执行；没有同步成功 = 不得推进；没有验收通过 = 不得视为当前 Part 完成。**
+20. **统一输出参数与文件约定（v2.7）**：场景相关命令默认只解析 `BaseResponse.data`；排障时才追加 `--raw`。需要落盘时优先使用 `--output <file>` 保存返回 JSON。`+preview-scenario-update` / `+apply-scenario-update` 现统一支持两种输入方式：① `--request-file <scenario-update.json>` 传完整更新请求；② `--operations-file <operations.json>` 并搭配 `--base-updated-at`、`--reason`、`--idempotency-key`（仅 apply 必填）。**preview 不需要也不应要求 `--idempotency-key`**
+20. **soke-cli 多版本故障降级（v2.6）**：若默认 `soke-cli` 出现 Node wrapper `spawn Unknown system error -88`、Go 二进制 Exit 137、或 `config show` 因短 token / 空 token 触发 `slice bounds out of range [-4:]` panic，必须立即执行 `references/env-check.md` 的「soke-cli 多版本与配置修复」流程：按优先级探测 `which -a soke-cli`、`/Users/edy/soke-cli/soke-cli/soke-cli`、QClaw npm-global、nvm 安装路径；优先使用能正常 `config show` 和 `auth login` 的本地二进制完成登录；不要反复重试已知坏路径。若配置中 `UserToken` 为 `test_token_12345` 或长度不足 4、`CorpID` 为空，判定为未登录/未绑定，不得进入平台同步
+20. **跨平台适配（v2.4）**：本技能支持在 WorkBuddy、悟空(Wukong)、QClaw、Zework 四大平台运行。交互层按 `platform/adapters/` 加载对应平台的适配器（弹窗/纯文本/IM 对话），业务逻辑层（Part1-5 管线、质量闸门、资产调用）所有平台完全一致。当 soke-cli 在目标平台不可用时，降级为 `platform/api-fallback.md` 的 REST API 直接调用——JSON 结构和字段映射与 CLI 路径完全一致，仅传输方式不同
 
 ---
 
@@ -42,6 +51,10 @@ agent_created: true
 | `soke-ai-training` | 知识包/提示词 → MentorAI 平台同步 | `platform/soke-ai-training/soke-ai-training.md` |
 | `sync-engine` | JSON 生成规则、字段映射表、CLI 命令模板 | `platform/sync-engine.md` |
 | `interaction` | 弹窗交互规则（优先 render_ui 弹窗，兜底结构化文本） | `platform/interaction.md` |
+| `adapters/` | **跨平台交互适配器**（WorkBuddy/悟空/QClaw/Zework） | `platform/adapters/README.md` |
+| `api-fallback` | **REST API 降级方案**（soke-cli 不可用时的 HTTP 直接调用） | `platform/api-fallback.md` |
+| `resource-finalizer` | **资源完善器**（封面/头像/语音回填） | `platform/resource-finalizer.md` |
+| `publish-gate` | **发布闸门**（结构+资源验收后才允许发布） | `platform/publish-gate.md` |
 
 ---
 
@@ -53,6 +66,8 @@ agent_created: true
 
 **典型表达**:帮我搭建AI陪练 / 创建陪练场景 / 根据资料生成提示词 / 做一个销售/面访/电话约访陪练
 
+> ⚠️ **创建型任务第一步强制执行**：识别为创建型任务后，**立即进入「创建型任务流程（严格顺序管线）」**，不得跳步、不得省略任何步骤。流程起点固定为 **Step 0 环境检测**，经 Step 1-4 后必须进入 **Step 5 Part1 创建同步（先于其他 Part 同步到平台）→ Part2 → Part3 → Part4 → Part5 分段同步**。此规则 **不管是什么平台（WorkBuddy / WebChat / CLI / 纯文本 / 群聊）都强制执行**，任何平台不得跳过 Step 0 或省略 Part1 优先创建同步。若当前运行环境不支持 soke-cli（如纯聊天平台），则引导用户在支持的终端执行环境检测和平台同步步骤。
+
 ### 2. 微调型
 
 已有提示词、对话记录或反馈,需要优化。
@@ -90,6 +105,8 @@ agent_created: true
 5. 仅当知识库超长或用户明确要求知识包同步时,才追加调度 `platform/soke-ai-training/soke-ai-training.md`
 6. 任一步未通过 → 按 `references/env-check.md` 修复流程引导,不进入同步
 7. 创建型流程在 Step 8 自动执行 `+publish-scenario`;单独发布已有场景时同样走此命令
+8. 在发布前必须先执行 `platform/resource-finalizer.md` 与 `platform/publish-gate.md`：封面、头像、语音任一缺失都禁止发布
+9. 场景列表、快照、恢复能力已纳入标准工具集：不确定 `scenario_id` 时先 `+list-scenarios`; 更新异常先 `+list-scenario-snapshots`, 必要时 `+restore-scenario-snapshot`
 
 ---
 
@@ -124,7 +141,9 @@ agent_created: true
 
 ## 创建型任务流程（严格顺序管线）
 
-> ⚠️ **强制串行执行**：以下 Step 0-7 必须严格按顺序执行，每一步必须完成并通过闸门检查后才能进入下一步。**禁止跳步、禁止并行、禁止省略中间步骤**。如果某一步检测不通过，必须在当前步骤修复后再继续，不可将未解决的问题带入下一步。
+> ⚠️ **强制串行执行（不管什么平台）**：以下 Step 0-8 必须严格按顺序执行，每一步必须完成并通过闸门检查后才能进入下一步。**禁止跳步、禁止并行、禁止省略中间步骤**。如果某一步检测不通过，必须在当前步骤修复后再继续，不可将未解决的问题带入下一步。
+
+> ⚠️ **Part1 优先创建同步**：Step 5 内容生成时，**Part1 必须第一个生成并立即同步到平台创建场景**。Part1 创建成功后，再按 Part2 → Part3 → Part4 → Part5 顺序逐 Part 生成并同步。不得先生成全部 5 个 Part 再批量同步，也不得跳过 Part1 直接进入后续 Part。
 
 ### 管线总览
 
@@ -143,9 +162,11 @@ Step 5: 内容生成（prompt-engineer 逐 Part 流水线）
   ↓ ✅ 逐 Part 确认同步
 Step 6: 平台同步验证
   ↓ ✅ 同步成功
-Step 7: 创建质量闸门（10 项全部通过）
+Step 7: 创建质量闸门（12 项全部通过）
   ↓ ✅ 闸门通过
-Step 8: 场景发布
+Step 8: 资源完善与发布闸门
+  ↓ ✅ 资源完整、允许发布
+Step 9: 场景发布
   ↓ ✅ 发布成功
 交付
 ```
@@ -154,9 +175,11 @@ Step 8: 场景发布
 
 ---
 
-### ⚙️ Step 0: 平台就绪检测（必做，先于内容生成）
+### ⚙️ Step 0: 平台就绪检测（必做，不管什么平台都是第一步）
+
+创建型流程全程依赖 soke-cli 与平台交互。**必须在 Step 1 之前**完成环境检测。此步骤是创建型管线的**绝对起点**，不管用户在什么平台（WorkBuddy / 悟空 / QClaw / Zework / WebChat / 纯文本群聊 / CLI / API）发起请求，**都必须从 Step 0 开始执行**。
 
-创建型流程全程依赖 soke-cli 与平台交互。**必须在 Step 1 之前**完成环境检测。
+> 📱 **跨平台适配（v2.4）**：Step 0 检测按当前运行平台自动选择执行策略——WorkBuddy 用 `dangerouslyDisableSandbox: true`，悟空/QClaw/Zework 直接执行 CLI（各自的沙箱机制不同），纯聊天平台可跳过 CLI 步骤直接检测 Token（从 `soke-cli config show` 或引导用户获取）。若 soke-cli 完全不可用，降级为 `platform/api-fallback.md` 的 REST API 模式——用 Token 验证 API 连通性代替 CLI 命令检测。交互方式按 `platform/adapters/` 加载对应平台适配器。
 
 > ⚠️ **沙箱绕过（全局规则）**：soke-cli 是 Go 编译的二进制文件，在 WorkBuddy Bash 沙箱中执行会被限制（`permission denied` / 静默失败）。**所有 soke-cli 命令调用 Bash 工具时必须设置 `dangerouslyDisableSandbox: true`**，包括环境检测中的 `which soke-cli`、`soke-cli --version`、`soke-cli config show`、`soke-cli auth login` 以及后续全部 `soke-cli ai-training +...` 命令。
 
@@ -289,18 +312,41 @@ read references/cases/AI陪练场景分类库.md
 
 ---
 
-### Step 5: 内容生成（prompt-engineer 逐 Part 流水线）
+### Step 5: 内容生成（prompt-engineer 逐 Part 流水线，不管什么平台都遵循同一协议）
 
-> ⚠️ **强制顺序**：必须按 Part1 → Part2 → Part3 → Part4 → Part5 严格串行执行。**禁止跳 Part、禁止并行生成、禁止一次性批量输出多个 Part**。每个 Part 必须完成「**生成 → 完整展示 → 用户确认 → 同步**」四步闭环后才能进入下一 Part。
+> ⚠️ **强制顺序（不管什么平台）**：必须按 Part1 → Part2 → Part3 → Part4 → Part5 严格串行执行。**禁止跳 Part、禁止并行生成、禁止一次性批量输出多个 Part**。每个 Part 必须完成「**生成 → 完整展示 → 用户确认 → 同步**」四步闭环后才能进入下一 Part。
 >
-> 📺 **用户可见规则**：Step 5 对话中**仅展示**各 Part 的标题（`## 🔨 PartN`）和确认弹窗（`AskUserQuestion`）。以下内容**全部在内部推理中执行，严禁写入对话窗口**：
+> ⚠️ **Part1 强制优先创建同步（不管什么平台）**：Part1 是创建型管线的第一个同步步骤，**必须先于 Part2-5 完成平台创建**。Part1 确认后立即调用 `soke-cli ai-training +create-scenario` 创建场景并拿到 `scenario_id`（若 soke-cli 不可用，降级为 `platform/api-fallback.md` 的 REST API POST），再逐个推进 Part2-5。若当前平台无法执行 soke-cli 也无法调用 API，在完成 Part1 内容生成和确认后，引导用户到支持的终端完成创建，**在此之前不得生成 Part2**。
+>
+> ⚠️ **Part2 资源匹配双通道（不管什么平台）**：Part2 内容完整展示并由用户确认后，系统在后台执行头像和声音资源匹配，再生成写入 JSON。先检测 soke-cli 可用性 → CLI 可用走 `references/role-resource-matching.md`；CLI 不可用走 `platform/api-fallback.md`「资源匹配完整流程」的 REST API 路径。**禁止因 CLI 不可用直接跳过资源匹配**——Zework/悟空/QClaw 等平台若没有 soke-cli，必须降级到 REST API 完成 avatar/voice 匹配。资源匹配、写入、回读校验都不向用户二次确认。
+>
+> 📺 **用户可见规则（v2.17 硬约束）**：Step 5 对话中**仅展示**各 Part 的标题（`## 🔨 PartN`）和确认交互（根据运行平台加载 `platform/adapters/` 对应适配器——WorkBuddy 用 `AskUserQuestion` / `render_ui`，悟空/QClaw/Zework 用结构化文本编号，但**所有平台的选项文案和分支路由完全一致**）。以下内容**全部在后台（内部推理 + 终端命令）中执行，严禁以任何形式写入对话窗口**：
 > - 内部思考与生成过程
-> - JSON 文件创建命令
-> - CLI 预览/应用命令及输出（含 `+preview-scenario-update` / `+apply-scenario-update` 及其返回的 diff_summary、changed_fields、operation_count 等）
-> - CLI 查询命令及输出（含 `+get-scenario` / `+list-scenarios` / `+list-scenario-snapshots` / `+list-role-avatars` / `+list-role-voices` 及其返回数据）
+> - **任何 `.json` 文件名或路径**（`.json`、`step1-create.json`、`part2-operations.json`、`state-snapshot.json` 等全部禁止在对话中出现）
+> - JSON 文件创建命令与 Python 生成脚本
+> - CLI 命令及输出（`soke-cli`、`+preview-scenario-update`、`+apply-scenario-update`、`+get-scenario`、`+list-scenarios`、`+list-scenario-snapshots`、`+list-role-avatars`、`+list-role-voices`、`+create-scenario`、`+publish-scenario`、`python3` 脚本执行及其返回的 diff_summary、changed_fields、operation_count、snapshot_id 等全部禁止在对话中出现）
 > - 协议阶段 1 自检清单与结果
 > - 角色资源匹配过程（含头像/声音的 CLI 查询和写入）
 > - 工作流步骤编号（如"步骤 6：预览更新""步骤 8：发布场景"等工作流元信息）
+> - 任一同步操作的执行进度、成功/失败判断过程
+> - 环境检测命令（`node --version`、`which soke-cli`、`soke-cli config show`、`soke-cli auth login`）及其输出
+>
+> **⛔ 仅允许在对话中展示的三种信息**：
+> 1. Part 完整内容（`## 🔨 PartN` + 纯文本内容展示）
+> 2. 确认弹窗交互（`AskUserQuestion` 或结构化文本编号）
+> 3. 最终摘要（Part5 完成后的一句场景信息 + 本地文件路径 + 封面缺口提示，不含任何 `.json` 文件名）
+
+> ⚠️ **确认后前台静默规则（v2.20.8）**：用户对任一 Part 回复“确认”后，后续 JSON 生成、preview、apply、回读、资源匹配、封面处理、状态快照写入等全部属于后台步骤，**前台不再展示任何“已确认”“正在同步”“继续处理中”“请稍候”等过渡消息**。后台成功则直接进入下一个 Part 展示；后台失败才允许前台报错。
+
+> ⚠️ **确认选项极简展示规则（v2.19）**：所有纯文本确认选项只展示「编号 + 选项文案」，禁止展示破折号说明、下一步解释、同步动作解释、长句说明。正确示例：`1. 确认，同步到平台（推荐）`；错误示例：`1. 确认，同步到平台（推荐）— 场景基础信息确认无误，立即创建场景到平台`。
+
+> ⚠️ **`.json` 前台零泄露规则（v2.19）**：任何 `.json` 文件名、路径、文件生成提示、脚本执行提示、CLI 参数中出现的文件名、同步中间文件、状态快照文件，均禁止出现在对话前台。即使是最终摘要，也只可说明「已完成同步/已发布」，不得出现 `step1-create.json`、`partX-update.json`、`operations.json`、`state-snapshot.json` 等字样。
+
+> ⚠️ **本地图片前台零展示规则（v2.20）**：创建型流程中本地生成的封面图、角色图、流程图等图片均属于后台资源处理，不得在对话前台展示、不得调用图片预览工具展示给用户、不得在最终摘要中主动输出本地图片路径。只有用户明确要求“给我看封面/预览图片/导出图片文件”时，才可展示或提供路径。封面是否正确由后台内部检查，不作为用户确认步骤。
+
+> ⚠️ **Part2-Part5 同等完整展示规则（v2.20）**：Part2、Part3、Part4、Part5 的内容展示必须与 Part1 同等严格：在对话框中逐字段完整展示，再给确认选项。禁止只展示摘要版、压缩版、标题版、部分字段版；禁止以“已同步/已生成/进入下一步”替代内容展示。隐藏字段仍按各 Part 隐藏规则不展示，但所有面向用户字段必须全文展示。
+
+
 
 ---
 
@@ -318,6 +364,7 @@ read references/cases/AI陪练场景分类库.md
 
 各 Part 必须展示的内容清单（**展示内容严禁使用 Markdown 表格格式，必须用纯文本段落/列表呈现**）：
 
+
 **Part1 展示清单**：
 - 场景名称（完整原文）
 - 全部标签（逐条列出）
@@ -326,9 +373,10 @@ read references/cases/AI陪练场景分类库.md
 - 场景语言
 
 **Part2 展示清单**：
+- **展示顺序固定**：先展示 AI角色整体设定 OS 全文，再逐个展示角色1、角色2、角色3...；禁止先展示角色资源匹配、写入、回读步骤。
 - AI角色整体设定 OS 全文（核心铁律/状态机/双层逻辑/行为模拟规范/知识库合规——全部章节完整原文）
 - 每个角色卡逐字段展示：名称/描述/沟通风格/MBTI/性格/标签/禁忌/知识水平
-- 角色背景四段深度画像完整正文（我是谁/我的困扰/我的过往经历/我今天的心态——四段全部完整展示）
+- 每个角色的角色背景四段深度画像完整正文（我是谁/我的困扰/我的过往经历/我今天的心态——四段全部完整展示）
 - **隐藏字段**（不向用户展示）：`scenario_role_id`、来源类型、专项技能与触发器、`avatar`（平台头像资源）、`voice_id`（平台语音资源）——以上为平台元数据/内部配置
 
 **Part3 展示清单**：
@@ -336,11 +384,15 @@ read references/cases/AI陪练场景分类库.md
 - 每个环节完整展示：环节名/学员目标完整原文/AI任务完整原文（含环节进入条件+IF-THEN逻辑+环节退出条件）/最大轮次
 - **隐藏字段**（不向用户展示）：开场语类型——由 AI 根据开场内容智能判断（系统旁白式→2 学员先开口；AI直发式→1 AI先开口）
 
+> 🔴 **同等展示硬约束（v2.20）**：以下清单对 Part1-Part5 具有同等约束力。Part2、Part3、Part4、Part5 不得低于 Part1 的展示完整度。若任一 Part 只展示摘要、只展示维度名/环节名、只展示配置值、或省略应展示正文，视为协议阶段 1 失败，必须回退重新完整展示。
+
 **Part4 展示清单**：
 - 评分标准名称
 - 评分标准描述完整原文
-- 每个评分维度展示：名称/描述/权重
-- **隐藏字段**（不向用户展示）：维度 `code`、`scoring_rule` 分档标准全文、`criteria` 评分点列表、`sort_order` 排序号——以上为平台评分引擎内部字段
+- 每个评分维度展示：名称/描述/权重/评分规则全文/评分点列表
+- **隐藏字段**（不向用户展示）：维度 `code`、`id`、`sort_order`、平台内部层级字段——以上为平台评分引擎内部字段
+
+> ⚠️ **Part4 展示修订（v2.20）**：评分规则和评分点必须作为面向用户内容完整展示，不再视为隐藏字段。不得只展示“名称/描述/权重”。
 
 **Part5 展示清单**：
 - 练习时间：默认关闭（不限时）
@@ -360,7 +412,7 @@ read references/cases/AI陪练场景分类库.md
 ☐ 无"……""（略）""（同上）""详见材料""（下略）"等缩略标记
 ☐ Part2 未展示 scenario_role_id、来源类型、专项技能与触发器、avatar、voice_id
 ☐ Part2 每个角色的 background 四段深度画像（我是谁/我的困扰/我的过往经历/我今天的心态）均已逐段完整展示，无缩略
-☐ Part4 未展示维度 code、scoring_rule 分档全文、criteria 列表、sort_order
+☐ Part4 未展示维度 code/id/sort_order 等平台内部字段，但已展示每个维度的评分规则全文和评分点列表
 ☐ Part5 未展示 completion_rule；pass_difficulty 已展示为"中（默认锁定）"
 ☐ 角色卡已展示全部面向用户字段，非仅名称
 ☐ 场景描述/OS/背景/评分规则已展示全文，非仅标题或首句
@@ -375,7 +427,25 @@ read references/cases/AI陪练场景分类库.md
 
 ##### 协议阶段 2：用户确认（必须提供按钮弹窗选项）
 
-协议阶段 1 自检全部通过后，**必须使用 `AskUserQuestion` 工具提供确认弹窗**，选项映射如下：
+协议阶段 1 自检全部通过后，**必须使用 `AskUserQuestion` 工具提供确认弹窗或按当前平台适配器输出结构化文本编号确认**。纯文本编号确认只展示选项文案，不展示破折号说明。
+
+正确纯文本格式：
+```
+请选择：
+1. 确认，同步到平台（推荐）
+2. 内容需要微调
+
+回复数字编号即可。
+```
+
+错误纯文本格式：
+```
+请选择：
+1. 确认，同步到平台（推荐）— 场景基础信息确认无误，立即创建场景到 MentorAI 平台
+2. 内容需要微调 — 场景名称、标签、描述或考核关键点需要调整
+```
+
+选项映射如下：
 
 | Part | 弹窗标题 | 选项 1（推荐） | 选项 2 | 选项 3 |
 |------|---------|--------------|--------|--------|
@@ -392,8 +462,36 @@ read references/cases/AI陪练场景分类库.md
 
 > ⚠️ **Part1 确认后强制同步到平台**：模板 1 不提供"取消"或"跳过同步"选项。Part1 确认即意味着场景必须创建到平台。
 
+> 🔴 **Part1 创建成功闸门（v2.20.4）**：Part1 的“同步到平台”不是逻辑确认，而是实际创建动作。必须满足以下四项后，才允许进入 Part2：
+> 1. 已生成创建请求文件（`part1-create.json` 或 `step1-create.json`）
+> 2. 已执行 `+create-scenario`
+> 3. CLI/API 返回成功
+> 4. 已提取到非空 `scenario_id`
+>
+> 任一项未满足 → 立即报错并停在 Part1，禁止静默继续到 Part2。
+
 ---
 
+#### ⛔ Part1 确认硬约束（v2.18，一票否决）
+
+Part1 完整展示之后，**必须立即在对话中提供确认选项**，格式根据当前运行平台加载 `platform/adapters/` 对应适配器：
+- WorkBuddy → `AskUserQuestion` 弹窗（模板 1：确认同步到平台 / 内容需要微调）
+- 悟空/QClaw/Zework → 结构化文本编号确认（只展示 `1. 确认，同步到平台（推荐）` / `2. 内容需要微调`，禁止追加破折号说明）
+
+**以下行为视为执行错误，一票否决，必须打断回退**：
+- ❌ Part1 展示后直接进入 Part2 生成，未在对话中提供任何确认选项
+- ❌ Part1 展示后直接开始创建封面图或执行 `soke-cli ai-training +create-scenario`，未经用户确认
+- ❌ 展示"以上 Part1 内容如上""接下来进入 Part2"等跳过确认的过渡语句
+- ❌ 将 Part1 内容展示和确认选项合并在同一条消息中，用户直接看到 Part1 内容下方无确认选项即被跳过
+
+**合规执行流程**：
+```
+对话消息 1: 展示 Part1 全部内容（## 🔨 Part1 + 逐字段全文）
+对话消息 2: 提供极简确认选项（编号或弹窗，只含选项文案）→ 等待用户选择
+→ 用户选"确认"后方可进入封面生成和平台创建
+→ 用户选"微调"后回到内容层修改 Part1 并重新执行协议阶段 1+2
+```
+
 #### 流水线执行（Part1-Part5 完整顺序）
 
 ```
@@ -401,58 +499,111 @@ Part1 基础信息
   协议阶段1: 在对话中完整展示 Part1 全部内容
   协议阶段1自检: 内部逐项确认无缩略无截断
   协议阶段2: AskUserQuestion 弹窗确认（模板 1）
-  → 生成封面图 → 上传封面 → 生成 step1-create.json → 创建场景 → 更新 state-snapshot
+  → 确定封面来源 → 生成 part1-create.json 或 step1-create.json → 执行 create-scenario → 取得 scenario_id → 更新 state-snapshot
   ↓
 Part2 AI角色设定
-  协议阶段1: 在对话中完整展示 Part2 OS全文+角色卡全部面向用户字段（background 四段深度画像必须逐段完整展示）
+  协议阶段1: 在对话中按固定顺序完整展示 Part2：先 OS 全文 → 再逐个角色展示全部面向用户字段（background 四段深度画像必须逐段完整展示）
   协议阶段1自检: 内部逐项确认→特别是 background 四段是否完整逐段展示、scenario_role_id/来源类型/专项技能已隐藏
   协议阶段2: AskUserQuestion 弹窗确认（模板 2）
-  → 生成 part2-operations.json → ⚠️ background 逐字比对闸门（JSON vs 展示文本）→ preview+apply → ⚠️ apply 后逐字段验收（name/description/communication_style/background/personality/tags/knowledge/taboos 逐字段对比 + ai_roles_overall_description 前100字符一致性 + background 四维完整性）→ 验收通过后方可进入匹配头像/声音 → 提取角色性别年龄 → CLI 精准过滤并行查询头像+声音 → ⚠️ 单次 patch_ai_role 合并写入 avatar+voice_id → ⚠️ get-scenario 强制验证 avatar+voice_id 均非空 → 验证失败则重新读取 updated_at 后重试一次 → 仍失败则标注「⚠️ 资源匹配未完成」但继续 Part3（不阻断） → 更新 state-snapshot
+  → 后台自动执行（不向用户确认）：为每个角色匹配头像/声音资源 → 生成完整 part2-operations.json（avatar/voice_id 已写入真实值）→ 后台拆分为角色级同步单元 → 逐个角色 preview+apply+回读验证 → 最后写入 OS 并回读验证 → 更新 state-snapshot → 全部同步成功后立即自动输出 Part3
+
+> 🔴 **Part2 同步成功闸门（v2.20.6）**：Part2 只有在以下条件全部满足后，才允许进入 Part3：1. 已生成 `part2-operations.json` 与 `part2-update.json`；2. 已完成资源匹配并写入真实 `avatar`/`voice_id`；3. 已执行 preview/apply；4. 验收通过。**验收优先级**：a. `get-scenario` 回读正常且角色与 OS 验收通过；或 b. `get-scenario` 回读仍为 `ai_roles: []`、`ai_roles_overall_description: null`，但平台实际已展示 Part2 内容，则按已知平台回读差异记账通过。仅当 preview/apply 失败，或平台侧也未展示时，才立即报错并停在 Part2，禁止静默继续到 Part3。
+
+> ⚠️ **Part2 自动续流硬约束（v2.20.1）**：Part2 用户确认后，前台不得停留在“Part2 已确认，正在后台同步角色设定。”或同类中间态消息后等待用户再次输入“继续”。正确行为是：后台同步成功后，系统在同一轮任务中自动继续输出 Part3；只有出现失败、超时或必须人工介入的异常时，才允许中断并向用户暴露最小必要异常。
   ↓
 Part3 流程设置
   协议阶段1: 在对话中完整展示开场语+每个环节的学员目标/AI任务全文
   协议阶段1自检: 内部逐项确认→特别是环节IF-THEN逻辑是否完整展示
   协议阶段2: AskUserQuestion 弹窗确认（模板 3）
   → 生成 part3-operations.json → preview+apply → 更新 state-snapshot
+  → ⚠️ apply 后验证：回读 `conversation_steps` 和 `opening_dialogue`；若未反映到 `get-scenario`，按已知平台回读问题记录并直接续流 Part4，不再以前台确认 Web 可见性作为阻断条件。详见 `sync-engine.md` Part3 验证规则。
+
+> 🔴 **Part3 同步成功闸门（v2.20.5）**：Part3 只有在以下条件全部满足后，才允许进入 Part4：1. 已生成 `part3-operations.json` 与 `part3-update.json`；2. 已执行 preview/apply；3. 若 CLI 回读正常，则回读字段验收通过；若 CLI 回读异常但 preview/apply 成功，则已按已知平台问题记录到状态快照。若 preview/apply 本身失败，或未生成 JSON，必须立即报错并停在 Part3，禁止静默继续到 Part4。
   ↓
 Part4 评分标准
-  协议阶段1: 在对话中完整展示评分名称+描述+每个维度scoring_rule/criteria全文
+  协议阶段1: 在对话中完整展示评分名称+描述+每个维度名称/描述/权重/评分规则全文/评分点列表
   协议阶段1自检: 内部逐项确认→特别是一票否决是否嵌入各维度scoring_rule
   协议阶段2: AskUserQuestion 弹窗确认（模板 4）
   → 生成 part4-operations.json → preview+apply → apply后验收评分同步 → 更新 state-snapshot
+
+> 🔴 **Part4 同步成功闸门（v2.20.7）**：Part4 只有在以下条件全部满足后，才允许进入 Part5：1. 已生成 `part4-operations.json` 与 `part4-update.json`；2. 已执行 preview/apply；3. 验收通过。**验收优先级**：a. `get-scenario` 回读确认 `scoring_criteria_config.criteria_data.dimensions` 非空；或 b. `get-scenario` 回读仍为 `scoring_criteria_config: null`，但平台实际已展示评分标准，则按已知平台回读差异记账通过。仅当 preview/apply 失败，或平台侧也未展示评分标准时，才立即报错并停在 Part4，禁止静默继续到 Part5。
   ↓
 Part5 教练设置
   协议阶段1: 在对话中向用户展示：练习时间（关闭）/最大练习次数（10）/通关分数（60）/通关难度（中，默认锁定）/AI助答（开启）
   协议阶段1自检: 内部逐项确认→所有值与固定模板一致、completion_rule 未泄露
   协议阶段2: AskUserQuestion 弹窗确认（模板 5）
   → 生成 part5-operations.json → preview+apply → apply后验收练习配置 → 完成摘要
+
+> 🔴 **Part5 同步成功闸门（v2.20.5）**：Part5 只有在以下条件全部满足后，才允许进入完成摘要/发布闸门：1. 已生成 `part5-operations.json` 与 `part5-update.json`；2. 已执行 preview/apply；3. `get-scenario` 验收确认练习配置字段已同步。任一项未满足 → 立即报错并停在 Part5，禁止静默结束或误报完成。
 ```
 
 #### 各 Part 专项约束
 
 1. **保持既有 Part1-Part5 输出框架和章节顺序不变**
-2. **Part1 封面**：确认后先生成封面图（场景名称+标签+行业为 prompt），上传后获得 CDN URL 再创建场景，不得使用默认占位图
+2. **Part1 封面**：确认后优先在后台从平台图片库或已有真实封面库中选择一张匹配封面并写入；仅当图库/封面库都不可用时，才允许本地生成并上传。无论走哪条路径，**都必须拿到真实平台 URL 后**再创建场景，不得使用默认占位图，也不得只保留本地封面文件不上传
+3. **Part1 场景语言固定写死**：`scene_lang` 在创建请求中必须固定写成 `简体中文`，不得跟随材料语言、用户输入语言、场景语种或文件内容变化，前台展示中的“场景语言”与后台创建字段都必须一致
 3. **Part2 角色背景来源与完整性**：必须来自用户上传的业务材料，禁止 AI 凭空编造。若材料不足以支撑角色背景，标注"⚠️ 材料不足"并追问用户补充。`background` 字段直接复制四段深度画像全文，不压缩不修改。**⚠️ JSON 写入后、preview 前强制闸门**：生成 `part2-operations.json` 后，必须逐字比对每个角色的 `role_data.background` 与 Part2 展示中的「角色背景」文本是否完全一致（标点、措辞、空格均不可有差异），同时确认四段深度画像（我是谁/我的困扰/我的过往经历/我今天的心态）全部完整。**任一项不通过 → 驳回修正，禁止直接 preview。** 这是最高频疏漏场景——背景文本在 JSON 生成阶段被截断/缩略/改写
-4. **Part2 头像/声音自动匹配 + apply 后逐字段验收（CLI 过滤模式 v2.0）**：角色 apply 后，**先从角色卡提取性别(gender)和年龄(age_group)**，映射为 CLI 的 `--gender` / `--age-group` 参数，再调用 `+list-role-avatars` / `+list-role-voices` 精准过滤查询（详见 `references/role-resource-matching.md`）。匹配失败时自动降级（去年龄→去性别→全量默认）。**apply 后立即逐字段验收**：执行 `soke-cli ai-training +get-scenario --scenario-id <id> --pretty`，对比以下全部项，**任一不一致 → 判定同步失败，禁止进入 Part3**：
+4. **Part2 头像/声音自动匹配 + 回读验收（CLI 过滤模式 v2.0）**：用户确认 Part2 完整内容后，后台**先从角色卡提取性别(gender)和年龄(age_group)**，映射为 CLI 的 `--gender` / `--age-group` 参数，再调用 `+list-role-avatars` / `+list-role-voices` 精准过滤查询（详见 `references/role-resource-matching.md`）。匹配失败时自动降级（去年龄→去性别→全量默认）。随后优先尝试整包 `replace_ai_roles` 写入；**仅当整包写入的 preview/apply 失败，或平台 Web 端也未展示内容时，才降级为角色级拆分同步单元。** 每次写入后执行验收：执行 `soke-cli ai-training +get-scenario --scenario-id <id> --pretty`，对比以下全部项；若 CLI 回读为空但平台 Web 端已展示，则按已知回读差异记账通过，不得直接判失败。
    - `ai_roles` 数组长度 = JSON 角色数
    - 每个角色逐字段（name/description/communication_style/background/personality_type/personality/tags/knowledge_level/taboos_objections）与 JSON 逐字一致
    - `ai_roles_overall_description` 非空且前 100 字符与 OS 原文一致（确保 OS 完整写入非丢失）
    - `role_data.name` ≠ `"角色数据异常"`（出现此值 → 检查外壳字段是否误放入 `role_data` 内部）
    - `background` 四段完整（我是谁/我的困扰/我的过往经历/我今天的心态）
    - **同步失败处理**：回退检查 JSON 结构（data.roles vs data.ai_roles、外壳字段层级、字段类型），修正后重新 preview+apply+验收，不得带缺陷进入 Part3
-   - **⚠️ avatar/voice_id 验收规则变更**：角色首次 apply 时 `avatar`/`voice_id` 留空（`""`），此阶段验收不检查 avatar/voice_id 是否为非空。验收通过后，进入下方「头像/声音资源回填」流程完成写入并二次验证。
-
-**⚠️ 头像/声音资源回填（apply 验收通过后强制执行）**：
-
-   角色逐字段验收通过后，立即执行资源匹配并**合并为单次 patch_ai_role 写入**：
-
-   a. 提取角色性别(gender) + 年龄(age_group) → CLI 过滤参数
-   b. **并行查询**：`+list-role-avatars` + `+list-role-voices`（同时发起，节省往返时间）
-   c. **合并写入**：将 avatar URL + voice_id 写入**同一个** `patch_ai_role` 操作，`customized_fields` 写 `["avatar", "voice_id"]`
-      - 禁止分两次 patch_ai_role：分开调用会导致第二次 patch 的 `updated_at` 变化后第一次写入的 avatar/voice_id 被后续 get 验证误判为丢失
-   d. **强制验证**：patch apply 后立即执行 `soke-cli ai-training +get-scenario --pretty`，确认每个角色的 `avatar` 非空 URL、`voice_id` 非空 ID
-   e. **重试机制**：任一角色 avatar/voice_id 为空 → 重新读取场景 `updated_at`，重新生成 patch，重试 1 次
-   f. **降级处理**：重试后仍失败 → 标注「⚠️ {角色名} 资源匹配未完成」，**不阻断 Part3**，但必须在最终交付摘要中提醒用户手动补充
+   - **⚠️ avatar/voice_id 验收规则（v2.11）**：角色首次 apply 时 `avatar`/`voice_id` 应为真实值。验收时确认 avatar 为非空 URL、voice_id 为非空 ID。若个别角色匹配失败保留空值，不阻断流程但需在摘要中标注。
+
+**⚠️ Part2 彻底解决方案：最小稳定结构 + 自动降级重试（新增）**
+
+当 Part2 回读出现以下任一异常时：
+- `role_data.name = "角色数据异常"`
+- `description = "角色数据格式异常，请检查数据"`
+- `background` / `communication_style` / `avatar` / `voice_id` 被平台回读为 `null`
+
+不得继续沿用当前整包结构硬重试，必须立即进入以下“彻底解决链路”：
+
+1. **第一层：字段级排雷**
+   - 将 `personality_type` 强制收敛为**单个 MBTI 值**，禁止写复合值（如 `ISTJ / ISFJ / ESTJ`）
+   - 检查 `source_type` 是否发生内外层重复写入；若有冲突，按已验证唯一层级保留，禁止双写博弈
+   - `customized_fields` 必须与实际保留字段逐项严格一致，禁止多报或漏报
+
+2. **第二层：最小稳定结构重试**
+   - 若第一层修正后仍异常，必须退化为**最小稳定角色结构**，首次仅保留以下字段：
+     - `name`
+     - `description`
+     - `communication_style`
+     - `background`
+     - `avatar`
+     - `voice_id`
+   - 以下字段默认从首次稳定写入中移除，待平台解析稳定后再逐步恢复：
+     - `knowledge_level`
+     - `taboos_objections`
+     - `tags`
+     - `personality`
+     - 非必要扩展型元字段
+
+3. **第三层：回读即准，不以 preview/apply 成功代替验收成功**
+   - `preview` 成功 ≠ Part2 成功
+   - `apply` 成功 ≠ Part2 成功
+   - 只有在 `get-scenario` 回读满足以下全部条件时，Part2 才算真正通过：
+     - `role_data.name` 不是“角色数据异常”
+     - `description` 正常
+     - `communication_style` 非空
+     - `background` 非空且四段完整
+     - `avatar` 为非空 URL
+     - `voice_id` 为非空 ID
+     - `ai_roles_overall_description` 非空
+
+4. **第四层：禁止带病续流**
+   - 只要回读仍出现“角色数据异常”，就必须停在 Part2
+   - 不得因为 preview/apply 成功就继续展示 Part3
+   - 不得口头说明“稍后再修”或“先继续后面 Part”
+
+5. **第五层：策略升级**
+   - 自此以后，Part2 默认策略不再是“高复杂字段整包写入”
+   - 默认策略改为：**最小稳定结构优先，稳定后再扩展字段**
+   - 只有在相同平台、相同结构已被实证稳定时，才允许恢复高复杂整包结构
+
+**⚠️ Part2 头像/语音强制前置（v2.15）**：avatar 和 voice_id 必须在生成 `part2-operations.json` 之前完成匹配并写入。流程：a. 按「OS → 角色1 → 角色2 → 角色3...」完整展示 Part2 内容并弹窗确认；b. 后台执行 `+list-role-avatars` 和 `+list-role-voices`；c. 按 `references/role-resource-matching.md` 为每个角色匹配资源；d. 将匹配结果写入 `role_data.avatar` 和 `role_data.voice_id`；e. 先生成完整 `part2-operations.json` 与 `part2-update.json` 并优先尝试整包同步；f. 仅在整包同步失败或平台 Web 端也未展示时，再降级为角色1、角色2、角色3、OS 的拆分保守写入。用户只确认完整 Part2 内容，不确认资源匹配、写入或回读步骤。
 5. **⚠️ Part2 JSON 关键结构规则**：
    - `replace_ai_roles` 数据键用 `data.roles`（非 `data.ai_roles`）
    - `role_data.avatar` 写头像资源 **URL**（来自 `+list-role-avatars` 的 `url` 字段），严禁用 `id`
@@ -463,12 +614,13 @@ Part5 教练设置
 6. 平台同步优先按 `platform/sync-engine.md` 的 Partwise 流程；执行前参考 `references/platform-api-pitfalls.md`；复制命令统一参考 `references/verified-cli-cheatsheet.md`
 7. 仅在知识库超长或用户明确要求知识包时，才追加调度 `platform/soke-ai-training/soke-ai-training.md`
 8. prompt-engineer 内部一致性扫描在每个 Part 生成后自动执行；无告警不输出，有告警才提示 ⚠️
+8.1 **Part2 默认生成策略升级（新增）**：首次同步角色时，默认优先生成“最小稳定结构”版本，不再默认把全部扩展字段一次性写入平台。高风险字段（如复合 `personality_type`、`knowledge_level`、`taboos_objections`、冗余 `source_type`）必须在平台解析稳定后再逐步恢复
 9. **Part3 开场语类型智能判断**：`opening_dialogue_type` 不固定值，由 AI 根据开场引导语内容自动判断——系统旁白叙事式→2（学员先开口），AI角色直发式→1（AI先开口）。此字段不向用户展示
 10. **Part4 apply 后强制验收**：立即执行 `soke-cli ai-training +get-scenario --pretty` 验证 `scoring_criteria_config.criteria_data.dimensions` 非空。**生成 part4-operations.json 后，必须先对照 `platform/sync-engine.md`「Part4 replace_scoring_criteria_config 自查清单」逐项核对 13 项**，全部通过后方可 preview。#1 最高频错误：漏掉 `config` 包裹层，`criteria_data` 直接放 `data` 下
 11. **⚠️ Part4 禁止金牌话术**：`scoring_rule` 和 `criteria` 中禁止出现引号包裹的示例对话（如"太好了谢谢姐！"），评分规则仅描述行为标准和得分条件
 12. **⚠️ Part4 一票否决嵌入维度**：不再使用全局 `one_vote_veto` 字段。每个维度的一票否决写在 `scoring_rule` 末尾（格式"以下行为触犯即该维度0分且总分不合格：…"）
 13. **⚠️ Part5 练习配置固定模板**：`min_practice_duration`=0, `max_practice_duration`=0, `max_practice_attempts`=10, `passing_score`=60, `pass_difficulty`=2（中，默认锁定不可调整）, `completion_rule`="all_steps"（写死，不展示）, `ai_assistance_enabled`=true。所有场景统一，不提供"调整"选项。不含收尾话术/SOP摘要/考核关键点摘要——这些已在 Part1 或 Part3 中同步。`completion_rule` 不向用户展示
-14. **每个 Part JSON 生成后必须先对照 `platform/sync-engine.md` 对应自查清单逐项核对，全部通过后方可 preview**：
+20. **每个 Part JSON 生成后必须先对照 `platform/sync-engine.md` 对应自查清单逐项核对，全部通过后方可 preview**：
    - Part1 → `step1-create.json 自查清单`（7 项）：最高频错误 `key_points` 写成数组
    - Part2 → `replace_ai_roles 自查清单`（14 项）：最高频错误 `data.roles` 误写为 `data.ai_roles`
    - Part3 → `Part3 operations 自查清单`（8 项）：最高频错误 `opening_dialogue_type` 写成字符串
@@ -496,9 +648,9 @@ Part5 教练设置
 
 ---
 
-### Step 7: 创建质量闸门（10 项）
+### Step 7: 创建质量闸门（12 项）
 
-> ⚠️ **交付前必做**：完成全部生成和同步后，必须逐项通过以下 10 项闸门（定义详见「质量闸门 → 创建闸门」节）。任一未通过，返回对应步骤修复，修复后重新执行本闸门。
+> ⚠️ **交付前必做**：完成全部生成和同步后，必须逐项通过以下 12 项闸门（定义详见「质量闸门 → 创建闸门」节）。任一未通过，返回对应步骤修复，修复后重新执行本闸门。
 >
 > 📺 **以下闸门检查在内部推理中执行，严禁将逐项检查结果以任何形式（文本/表格/Markdown/代码块）输出到对话窗口。** 闸门全部通过后，仅在对话中输出一行摘要「✅ 质量闸门全部通过」。如有 ❌ 项，只在对话中告知用户"需返回 Step N 修复 X 问题"，不列出逐项明细。
 
@@ -517,11 +669,27 @@ Part5 教练设置
 | 9 | 整体设定节去空白字符 ≤ 3000 | ✅ / ❌ | Part2 | 返回 Step 5 Part2 压缩 |
 | 10 | 每个 Part 内容已在对话中完整展示 | ✅ / ❌ | Step 5 | 回退重新完整展示 |
 
-> 🚦 **闸门**：10 项全部 ✅ 后方可进入 Step 8。如有 ❌，必须回到对应步骤修复后重新跑本闸门，不得带缺陷交付。
+> 🚦 **闸门**：12 项全部 ✅ 后方可进入 Step 8。如有 ❌，必须回到对应步骤修复后重新跑本闸门，不得带缺陷交付。
 
 ---
 
-### Step 8: 场景发布
+### Step 8: 发布闸门（资源兜底）
+
+> 在执行发布前，必须先补齐资源并通过发布闸门。
+
+1. 执行 `platform/resource-finalizer.md`
+   - 检查并补齐真实封面图
+   - 检查并补齐所有角色头像
+   - 检查并补齐所有角色语音
+2. 执行 `platform/publish-gate.md`
+   - 验证封面不是默认图
+   - 验证 avatar 全部非空 URL
+   - 验证 voice_id 全部非空 ID
+   - 验证无“角色数据异常”
+3. 任一失败 → 停止发布，输出缺口清单
+4. 全部通过 → 进入 Step 9
+
+### Step 9: 场景发布
 
 > 质量闸门全部通过后，执行场景发布，使其在 MentorAI 平台正式生效。
 
@@ -535,6 +703,8 @@ soke-cli ai-training +publish-scenario \
   --pretty
 ```
 
+> 若 soke-cli 不可用，降级为 `platform/api-fallback.md` 的 REST API POST 发布端点。
+
 参数说明：
 | 参数 | 说明 |
 |---|---|
@@ -684,7 +854,7 @@ T排障 → O拟真 → P指令执行 → N自然度 → I信息释放/K知识
 10. **⚠️ Part2 外壳字段在外层**：`customization_level`、`is_custom_role`、`customized_fields`、`source_type`、`created_at`、`updated_at` 必须与 `role_data`、`scenario_role_id` 同级（外层），**严禁**写入 `role_data` 内部。写入内部会触发平台回读 `name: "角色数据异常"`，全部字段 null。判断规则：描述"角色有什么属性"→ `role_data` 内；描述"这个数据是什么类型/何时创建"→ 外层。详见 `references/platform-api-pitfalls.md` §4.1
 11. **⚠️ Part2 background 必填不可漏**：`role_data.background` 必须包含四段深度画像（我是谁/我的困扰/我的过往经历/我今天的心态），**严禁留空或 null**。这是最常见疏漏——replace_ai_roles 中写了其他字段但忘记 background。apply 后验收时检查 `ai_roles[].role_data.background` 非空
 12. **⚠️ Part5 练习配置已写死**：Part5 operations 使用固定模板（时长关闭、最大次数 10、通关分数 60、通关难度 中=2 默认锁定、完成规则 all_steps、AI助答开启）。所有场景统一，不含收尾话术、SOP 流程摘要、考核关键点摘要——这些已在 Part1/Part3 中同步。`completion_rule` 不向用户展示；`pass_difficulty`=2（中）向用户展示但不可调整
-13. **⚠️ `add_conversation_step` 数据不持久化**：平台 CLI v1.0.66 存在已知 bug——`add_conversation_step` apply 返回 snapshot_id 但数据不保存，`get-scenario` 始终返回空 steps。创建型流程的对话步骤需在 MentorAI Web 管理后台手动补充。`replace_conversation_steps` 同样不可用（422 校验拒绝）。仅 `create-scenario --request-file` 中 `conversation_steps` 全量创建时可写入，但会同时忽略 `ai_roles` 和 `scoring_criteria_config` 等复杂字段。详见 `references/platform-api-pitfalls.md`
+13. **⚠️ Part3 `add_conversation_step` CLI 回读口径**：`add_conversation_step` apply 可能返回成功但 `get-scenario` 回读 `conversation_steps` 为空，`opening_dialogue` 也可能不同步反映——这是已知的 CLI/Web 回读口径差异，不代表数据未写入。验收时如 `preview/apply` 已成功，即记录为「平台回读异常待观察」，**默认直接进入 Part4**；不再要求用户先去 Web 后台确认。仅当 `preview/apply` 本身失败，或后续步骤出现明确依赖阻塞时，才回到 JSON/CLI 排查。严禁因 CLI 回读为空直接阻断流程。
 
 ---
 
@@ -694,7 +864,7 @@ T排障 → O拟真 → P指令执行 → N自然度 → I信息释放/K知识
 >
 > 创建型任务交付前，须在「创建型任务流程 → Step 7」中逐项执行以下闸门检查。
 
-### 创建闸门(10 项)
+### 创建闸门(12 项)
 
 1. 材料完整
 2. 场景拆解合理
@@ -706,6 +876,8 @@ T排障 → O拟真 → P指令执行 → N自然度 → I信息释放/K知识
 8. 有测试用例
 9. `整体设定` 节去空白字符 ≤ 3000,阶段专属规则已下沉到 `流程设置` 对应环节
 10. 每个 Part 内容已在对话中完整展示（无截断、缩略、省略号，逐字段原文可见）
+11. Part2-Part5 展示完整度不低于 Part1：Part2 OS+角色全字段、Part3 开场+所有环节全文、Part4 评分规则+评分点全文、Part5 固定配置全部展示
+12. 本地生成的封面/图片未在前台展示，未主动输出图片路径，除非用户明确要求预览或导出
 
 ### 微调闸门(8 项)
 
@@ -736,7 +908,169 @@ T排障 → O拟真 → P指令执行 → N自然度 → I信息释放/K知识
 
 > 创建型任务必须在上方标注当前管线进度（如"Step 1: 材料接收与完整性检查"），并与「创建型任务流程（严格顺序管线）」中的 Step 编号对应。
 
-如果用户明确说"直接做/不用确认",可跳过确认,但**不能跳过输入质检和技术分流**。
+### 创建/生成场景前台执行格式硬约束（新增）
+
+当任务类型 = **创建型** 且用户意图为“生成陪练场景 / 创建陪练场景 / 根据资料搭建场景”时，前台输出必须严格遵循以下顺序，**任何一项都不可省略、合并或重排**：
+
+1. **先输出 `## 🎯 意图识别`**
+   - 必须明确写出：任务类型、建议链路、当前管线步骤、必读资产、输入缺口、下一步
+   - 若是创建型任务，`当前管线步骤` 初始必须是 `Step 0: 平台就绪检测` 或当前真实步骤
+
+2. **再进入 Step 0 ~ Step 4 的前台汇报**
+   - Step 0：平台就绪检测结果
+   - Step 1：材料接收与完整性检查结果
+   - Step 2：场景类型判定结果
+   - Step 3：链路判定结果
+   - Step 4：7项必问清单结果
+   - 以上五步若有任一步未完成或未通过，**禁止输出 Part1**
+
+3. **只有 Step 0 ~ Step 4 全部通过后，才允许输出 `## 🔨 Part1`**
+   - 禁止一上来直接展示 Part1
+   - 禁止仅在内部完成 Step 0 ~ Step 4，却不在前台明确汇报当前已到哪个步骤
+   - **若 Step 4 结论为“7项全部可答，可进入 Part1”，则必须直接衔接输出 Part1；禁止停在结论句结束，禁止再插入解释、复述、流程说明或额外确认**
+
+4. **Part 展示与确认必须拆成两条前台消息**
+   - **默认理想模式**：消息A只展示完整 Part 内容；消息B只展示极简确认选项
+   - **平台兼容单消息模式（新增）**：若当前平台/会话引擎无法稳定连续发出两条独立 assistant 消息，则允许在**同一条消息内**按固定顺序输出：
+     1. `## 🔨 PartN` 完整内容
+     2. 空一行
+     3. `请选择：` + 对应确认选项
+   - 在单消息模式下，必须保证**先完整展示内容，后给确认选项**，不得把确认选项插入内容中间，不能只给确认不展示内容，也不能只展示内容不带确认
+   - **`## 🔨 Part1：基础信息` 输出完成之后，必须立刻给出“确认/修改”选项，不允许停住、不允许等用户自行猜测、不允许直接进入后台创建**
+   - **`## 🔨 Part2`、`## 🔨 Part3`、`## 🔨 Part4`、`## 🔨 Part5` 输出完成之后，同样必须立刻给出对应的确认/修改选项，不允许停住、不允许让用户猜下一步、不允许直接进入后台同步或直接展示下一 Part**
+   - **执行优先级**：若平台支持稳定双消息 → 用双消息；若平台不支持稳定双消息 → 自动降级为单消息兼容模式
+   - **禁止把 Part 内容和确认选项放在同一条消息中**
+   - **禁止在同一条消息里既展示 Part1 又顺带进入 Part2**
+
+5. **用户确认后，前台必须静默等待后台完成真实同步，再直接进入下一 Part**
+   - 禁止出现“已确认”“正在同步”“稍等”“继续处理中”等中间态提示
+   - 后台若失败，直接报错并停在当前 Part
+   - 后台若成功，直接输出下一 Part 内容
+
+6. **严禁“伪流程”**
+   - 所谓伪流程，指的是：口头声称“已按规则重置/已进入正式流程”，但实际仍在继续用未闭环的展示式回复推进任务
+   - 若没有完成当前 Part 的后台同步成功闸门，就不得声称“进入下一 Part”或“正式继续”
+
+### 创建型任务一票否决行为（新增）
+
+出现以下任一行为，视为**没有按照技能规则执行**：
+
+- ❌ 未先输出 `## 🎯 意图识别` 就直接展示 Part1
+- ❌ 未前台汇报 Step0~Step4 结果，就直接展示 Part1
+- ❌ Step4 已得出“7项全部可答，可进入 Part1”后，没有直接进入 Part1，而是继续解释、重复总结或空转结束
+- ❌ `## 🔨 Part1：基础信息` 展示完成后，没有在下一条消息立即提供“确认/修改”选项
+- ❌ `## 🔨 Part2`、`## 🔨 Part3`、`## 🔨 Part4` 或 `## 🔨 Part5` 展示完成后，没有在下一条消息立即提供对应确认/修改选项
+- ❌ 把“Part内容展示完成”当成可单独结束的消息，而没有自动继续发出下一条确认消息
+- ❌ 在不支持双消息的平台上，既没有双消息，也没有按单消息兼容模式补上确认步骤
+- ❌ Part 展示消息发出后，系统没有执行“自动续发确认消息”这一后置动作
+- ❌ 技能热更新后，没有立即回到当前断点按新规则执行，而是先解释“已优化/已修复/正确动作应为”
+- ❌ 把 Part 内容和确认选项放在同一条消息
+- ❌ 用户确认后未完成真实后台同步，就继续展示下一 Part
+- ❌ 用“我现在按规则重置”“我已正式进入流程”等措辞替代真实流程执行
+- ❌ 在创建型任务中，把“参考规则生成文案”误当成“按规则执行创建流水线”
+
+### 创建型任务防呆规则（新增）
+
+若当前任务 = 创建型，则系统必须遵守以下防呆约束：
+
+1. **不得在同一轮里跳过 Step 汇报直接输出 Part**
+   - 只要本轮前台还没有完整输出 Step0、Step1、Step2、Step3、Step4 的结果，就绝对禁止输出 `## 🔨 Part1`
+   - 即使内部已经完成判断，也不能省略前台 Step 汇报
+
+2. **Step4 通过后必须直接衔接 Part1**
+   - 若当前回复已输出“7项全部可答，可进入 Part1”，则该回复后续必须直接开始 `## 🔨 Part1`
+   - 若因长度或交互策略拆到下一条消息，则下一条消息必须以 `## 🔨 Part1` 开头，禁止插入任何过渡话术
+
+3. **禁止 Step 汇报后空转**
+   - 既然 Step4 已通过，就不能停在“可进入 Part1”这句话结束任务
+   - 必须立即衔接到 Part1（同条回复内直接继续，或下一条消息直接开始 Part1）
+
+4. **禁止 Part 前重复铺垫**
+   - 一旦 Step4 已通过，后续不得再重复“我现在开始正式进入流程”“下面重新按规则开始”“现在进入Part1”等口头铺垫
+   - 正确做法是：直接输出 `## 🔨 Part1`
+
+5. **Part1 展示后必须立即确认**
+   - `## 🔨 Part1：基础信息` 完整展示结束后，下一条前台消息只能是确认选项
+   - 允许的选项语义只有两类：`确认，同步到平台（推荐）` / `内容需要微调`
+   - 不允许缺少确认消息，不允许把用户留在“看完内容但不知道怎么操作”的状态
+
+6. **Part2-Part5 展示后也必须立即确认**
+   - `## 🔨 Part2` 完整展示结束后，下一条前台消息只能是：
+     - `1. 确认，同步角色（推荐）`
+     - `2. 调整角色设定`
+     - `3. 重设角色设定`
+   - `## 🔨 Part3` 完整展示结束后，下一条前台消息只能是：
+     - `1. 确认，同步流程设置（推荐）`
+     - `2. 调整流程设置`
+     - `3. 重设流程设置`
+   - `## 🔨 Part4` 完整展示结束后，下一条前台消息只能是：
+     - `1. 确认，同步评分（推荐）`
+     - `2. 调整评分标准`
+     - `3. 重设评分标准`
+   - `## 🔨 Part5` 完整展示结束后，下一条前台消息只能是：
+     - `1. 确认，完成创建（推荐）`
+     - `2. 调整教练设置`
+     - `3. 重设教练设置`
+   - 不允许省略确认步骤，不允许先解释后台动作，不允许直接进入下一 Part
+
+7. **技能热更新即时生效规则（新增）**
+   - 当用户在创建流程进行中提出“优化技能 / 补规则 / 修正执行规则”，且该规则影响当前所在断点时，更新技能后必须立即对当前断点生效
+   - 生效顺序固定为：
+     1. 更新技能文件
+     2. 识别当前流程断点（如 Part1 展示后、Part4 展示后、Part5 展示后）
+     3. **直接输出按新规则本应输出的那条前台消息**
+   - 禁止在技能更新后先输出“已优化”“已补规则”“现在正确动作是”等解释性过渡消息替代真实执行
+   - 若新规则要求“展示后下一条必须确认”，则技能更新后必须立刻补发该确认步骤，而不是先解释规则内容
+
+8. **确认步骤自动续发规则（新增）**
+   - 在支持双消息的平台中：当系统刚输出完任一 Part 的完整展示消息后，必须自动续发该 Part 的确认消息
+   - 这里的“下一条消息”不是“等待用户再说一句之后的下一条”，而是**系统自己紧接着发出的下一条前台消息**
+   - 若当前平台无法稳定做到这一点，则必须自动切换到**单消息兼容模式**，在同一条消息内补足确认区
+   - 如果系统既没有自动续发第二条消息，也没有在同一条消息中补足确认区，则视为本轮执行不合规
+
+9. **确认消息自动续发升级为执行级硬规则（新增）**
+   - 对创建型任务而言，“Part 展示后立即给出确认步骤”不是格式建议，而是**必须执行的后置动作**
+   - 在双消息平台：只要某条前台消息完成了 `## 🔨 PartN` 的完整展示，系统就必须立即执行一个后置动作：**再发送一条独立前台消息，内容只能是该 Part 的确认/修改选项**
+   - 在单消息兼容模式：只要 `## 🔨 PartN` 内容展示完成，系统就必须在**同一条消息末尾**追加确认区，且保持“内容在前、确认在后”的顺序
+   - 若该后置动作未执行成功，则判定为当前轮执行失败
+   - 执行失败时，系统不得继续任何后续流程，不得解释，不得进入下一 Part，唯一允许的补救动作是：**优先补发缺失的确认消息**
+   - 缺确认消息时，系统的最高优先级动作永远是“补发确认消息”，而不是解释原因、总结规则或继续流程
+
+10. **后台闭环执行级硬规则（新增）**
+   - 在创建型任务中，用户点击或回复任一确认选项后，系统必须立即进入后台闭环：
+     1. 生成该 Part 的 `.json` 文件
+     2. 执行平台同步
+     3. 执行回读验收
+   - 只有 1+2+3 全部完成，当前 Part 才算完成
+   - 若缺少任一环节：
+     - 没生成 `.json` → 视为当前 Part 未执行
+     - 没执行同步 → 视为当前 Part 未执行
+     - 同步失败或验收失败 → 视为当前 Part 未完成
+   - **禁止把“用户已确认”误当成“当前 Part 已完成”**
+   - **禁止前台已经进入下一 Part，但后台其实没有生成 `.json` 或没有完成同步**
+   - 出现上述情况时，必须立即报错并停在当前 Part
+
+### 创建型任务自检问句（新增，内部执行）
+
+在每次准备输出创建型任务前台内容前，必须先在内部逐条自问：
+
+- 我是否已经先输出了 `## 🎯 意图识别`？
+- 我是否已经明确前台汇报当前处于 Step0~Step4 的哪个步骤？
+- 如果我正要输出 Part1，Step0~Step4 是否已经全部完成并在前台说明？
+- 如果 Step4 已经通过，我是否会直接输出 Part1，而不是继续解释？
+- 如果我刚输出完 Part1，我的下一条消息是否一定会给出确认/修改选项？
+- 如果我刚输出完 Part2/Part3/Part4/Part5，我的下一条消息是否一定会给出对应的确认/修改选项？
+- 我是否错误地把“下一条消息”理解成“等用户再说话之后的下一条”，而不是系统自己立刻续发的下一条？
+- 我是否已经先判断当前平台是否支持稳定双消息；若不支持，是否已切换到单消息兼容模式？
+- 如果我刚发完 Part 展示消息，我是否已经真正执行了“自动续发确认消息”这个后置动作？
+- 如果我刚完成技能热更新，而新规则影响当前断点，我是否已经直接回到当前断点执行，而不是先解释？
+- 我这条消息是否错误地把“Part内容 + 确认选项”合并了？
+- 我是否在没有真实完成后台同步的情况下，试图口头推进到下一 Part？
+- 如果 Part2 回读出现“角色数据异常”，我是否已经立即切换到最小稳定结构 + 自动降级重试，而不是继续硬推原结构？
+
+任一回答为“否”或“是（存在违规）”，都必须中断当前输出并回到正确步骤。
+
+如果用户明确说"直接做/不用确认",可跳过确认,但**不能跳过输入质检和技术分流**；对创建型任务而言，**也不能跳过 Step0~Step4 的前台步骤汇报与当前管线定位**。
 
 ---