@miniidealab/openlogos 0.9.23 → 0.9.24

package/skills/change-writer/SKILL.md

@@ -20,9 +20,10 @@
 
 1. 理解用户描述的变更意图
 2. 扫描 `logos/resources/` 中的现有文档，定位受影响范围
-3. 根据变更传播规则判断变更类型（需求级 / 设计级 / 接口级 / 代码级）
-4. 生成符合规范的 proposal.md
-5. 按变更类型自动拆解 tasks.md
+3. 根据变更传播规则判断变更类型（需求级 / 设计级 / 接口级 / 部署级 / 代码级）
+4. 判断本次变更是否需要部署、是否需要数据迁移、是否需要 smoke 验证
+5. 生成符合规范的 proposal.md
+6. 按变更类型自动拆解 tasks.md
 
 ## 执行步骤
 
@@ -40,10 +41,11 @@
 
 1. 读取需求文档（`prd/1-product-requirements/`），检查相关场景定义
 2. 读取产品设计（`prd/2-product-design/`），检查相关功能规格和原型
-3. 读取技术方案（`prd/3-technical-plan/`），检查相关时序图
+3. 读取技术方案（`prd/3-technical-plan/`），检查相关架构、时序图、部署方案
 4. 读取 API 文档（`api/`），检查相关端点
 5. 读取 DB 文档（`database/`），检查相关表结构
 6. 读取编排测试（`scenario/`），检查相关测试用例
+7. 读取 smoke 测试用例（`test/smoke/`），检查部署后冒烟覆盖是否需要更新
 
 ### Step 3: 判断变更类型
 
@@ -51,10 +53,11 @@
 
 | 变更类型 | 最少需要更新 |
 |---------|------------|
-| 需求级变更 | 全链路（需求 → 设计 → 架构 → API/DB → 编排 → 代码） |
-| 设计级变更 | 原型 + 场景 + API/DB + 编排 + 代码 |
-| 接口级变更 | API/DB + 编排 + 代码 |
-| 代码级修复 | 代码 + 重新验收 |
+| 需求级变更 | 全链路（需求 → 设计 → 架构 → 部署 → API/DB → 测试 → 编排 → 代码） |
+| 设计级变更 | 原型 + 场景 + API/DB + 测试/编排 + 代码 + 部署影响分析 |
+| 接口级变更 | API/DB + 编排 + 代码 + 部署影响分析 |
+| 部署级变更 | 部署方案 + smoke 用例 + `[deploy]` 任务 |
+| 代码级修复 | 代码 + 重新验收 + 部署影响分析 |
 
 ### Step 4: 生成 proposal.md
 
@@ -67,15 +70,25 @@
 [为什么要做这个变更？来源于哪个需求/反馈/Bug？]
 
 ## 变更类型
-[需求级 / 设计级 / 接口级 / 代码级]
+[需求级 / 设计级 / 接口级 / 部署级 / 代码级]
 
 ## 变更范围
 - 影响的需求文档：[列表，精确到文件名和章节]
 - 影响的功能规格：[列表]
 - 影响的业务场景：[场景编号列表]
+- 影响的部署方案：[列表]
 - 影响的 API：[端点列表]
 - 影响的 DB 表：[表名列表]
 - 影响的编排测试：[列表]
+- 影响的 smoke 测试：[列表]
+
+## 部署影响
+- 是否需要部署：是 / 否
+- 部署原因：[说明为什么需要或不需要部署]
+- 影响环境：[本地 / 测试 / 预发 / 生产 / 无]
+- 是否涉及数据迁移：是 / 否
+- 是否需要回滚预案：是 / 否
+- 是否需要 smoke：是 / 否
 
 ## 变更概述
 [用 1-3 段话概述具体改什么]
@@ -85,14 +98,35 @@
 
 根据变更类型和影响范围，使用结构化 section 格式生成任务清单。完整格式规范见 `spec/tasks-spec.md`。
 
-> **禁止在 tasks.md 中写入 verify / 验收 / 人工验证类条目**——这些属于 verify 步骤，不属于实现任务。`openlogos verify` 是独立的 CLI 操作节点，由面板的 verify 步骤触发；tasks.md 只追踪实现任务。
+> **禁止在 tasks.md 中写入 verify / smoke / 人工验证类条目**——这些属于独立 CLI 操作节点。tasks.md 只追踪 delta、代码和部署执行任务。
 
 **格式规则**：
 - `## [delta] <描述>` section：只列 delta 文档产出任务，每条对应一个 delta 文件
 - `## [code] <描述>` section：只列代码实现任务，直接修改源文件，不产出 delta
-- 两个 section 均为可选：纯代码提案只有 `[code]`，纯规格提案只有 `[delta]`
+- `## [deploy] <描述>` section：只列部署执行任务，只能在 verify PASS 后、人类明确确认后执行
+- 不需要部署的提案不得创建 `[deploy]` section
+- 需要部署的提案必须在 `[delta]` section 中包含部署方案和 smoke 用例变更（如受影响）
 - **严禁混用**：delta 任务不得写入 `[code]` section，代码任务不得写入 `[delta]` section
 
+**需要部署的变更模板**：
+
+```markdown
+# 实现任务
+
+## [delta] 规格变更
+- [ ] 产出 delta 文件到 `deltas/prd/3-technical-plan/3-deployment/` — 更新部署方案
+- [ ] 产出 delta 文件到 `deltas/test/smoke/` — 更新部署后冒烟测试用例
+
+## [code] 代码实现
+- [ ] 实现 src/xxx 中的业务逻辑
+- [ ] 编写对应测试
+- [ ] 编写 smoke 测试代码或脚本
+
+## [deploy] 部署任务
+- [ ] 按部署方案部署到 staging
+- [ ] 确认迁移、配置、服务启动和回滚预案
+```
+
 **需求级 / 设计级变更模板**（有 delta + 有代码）：
 
 ```markdown
@@ -152,9 +186,18 @@ Delta 文件写入 `logos/changes/<slug>/deltas/` 下对应子目录，与 `logo
 | `logos/resources/prd/2-product-design/2-page-design/` | `deltas/prd/2-product-design/2-page-design/` |
 | `logos/resources/prd/3-technical-plan/1-architecture/` | `deltas/prd/3-technical-plan/1-architecture/` |
 | `logos/resources/prd/3-technical-plan/2-scenario-implementation/` | `deltas/prd/3-technical-plan/2-scenario-implementation/` |
+| `logos/resources/prd/3-technical-plan/3-deployment/` | `deltas/prd/3-technical-plan/3-deployment/` |
+| `logos/resources/test/smoke/` | `deltas/test/smoke/` |
 
 代码实现（`src/`、`test/`）**不产出 delta**，直接修改源文件。
 
+部署相关行为规范：
+
+- 需要部署时，必须产出部署方案 delta
+- 需要部署且 smoke 覆盖受影响时，必须产出 smoke 测试用例 delta
+- 不允许把部署执行命令写入 `[code]` section
+- 不允许 AI 在 delta-writing 阶段执行部署命令
+
 #### 文件命名
 
 与目标主文档**同名**（含子目录层级）。例如：
@@ -204,6 +247,13 @@ Delta 文件写入 `logos/changes/<slug>/deltas/` 下对应子目录，与 `logo
 - 用户明确要求执行（包括使用 `/openlogos:merge`、`/openlogos:archive` slash command）时，AI 可以代为执行
 - 不得在"顺手完成流程"、"按流程走完"、"继续"等隐式场景中自动触发
 
+merge 后的后续提示应按是否需要部署区分：
+
+- **不需要部署**：实现代码 → `openlogos verify` → `openlogos archive`
+- **需要部署**：实现代码 → `openlogos verify` → 用户明确授权部署 → `openlogos smoke` → `openlogos archive`
+
+**部署执行、`openlogos smoke` 也是人类确认点**。AI 未经用户明确授权不得自动部署或自动运行 smoke。
+
 AI 只负责驱动内容修改，不得在未获明确授权的情况下推进提案状态。
 
 ## 输出规范

package/skills/code-implementor/SKILL.md

@@ -5,7 +5,7 @@
 ## 触发条件
 
 - 用户要求实现代码、生成代码或编写代码
-- 用户提到 "Phase 3 Step 4"、"代码生成"、"帮我实现 S01"
+- 用户提到 "Phase 3 Step 5"、"代码生成"、"帮我实现 S01"
 - 测试用例设计已完成（`logos/resources/test/` 非空），需要开始编码
 - 用户指定某个场景编号（如 S01）需要实现
 
@@ -17,7 +17,7 @@
 - `logos/resources/test/` 中包含测试用例规格（**必需**）
 - `logos/logos-project.yaml` 中包含 `tech_stack`（**必需**）
 
-如果时序图或测试用例目录为空，提示用户先完成 Phase 3 Step 1（scenario-architect）和 Step 3a（test-writer）。
+如果时序图或测试用例目录为空，提示用户先完成 Phase 3 Step 1（scenario-architect）和 Step 4a（test-writer）。
 
 ## 核心能力
 
@@ -33,9 +33,9 @@
 
 本 Skill 处于三者链条的中间位置：
 
-- **test-writer**（Step 3a）：设计测试用例**规格文档**（Markdown），定义 UT/ST ID——是"出卷人"
-- **code-implementor**（Step 4，本 Skill）：将所有规格转化为**可运行的业务代码和测试代码**——是"答卷人"
-- **code-reviewer**（Step 4 之后）：拿着规格**审计已生成的业务代码**，输出审查报告——是"阅卷人"
+- **test-writer**（Step 4a）：设计测试用例**规格文档**（Markdown），定义 UT/ST ID——是"出卷人"
+- **code-implementor**（Step 5，本 Skill）：将所有规格转化为**可运行的业务代码和测试代码**——是"答卷人"
+- **code-reviewer**（Step 5 之后）：拿着规格**审计已生成的业务代码**，输出审查报告——是"阅卷人"
 
 test-writer 不写代码；code-implementor 不设计用例；code-reviewer 不修改代码。三者形成 **设计 → 执行 → 审查** 闭环。
 

package/skills/code-reviewer/SKILL.md

@@ -5,7 +5,7 @@
 ## 触发条件
 
 - 用户要求审查代码或 Code Review
-- 用户提到 "Phase 3 Step 4"、"代码审核"、"代码审查"
+- 用户提到 "Phase 3 Step 5"、"代码审核"、"代码审查"
 - AI 刚生成了一段代码，需要验证其质量
 - 部署前的最终检查
 - 编排测试失败后需要定位代码问题

package/skills/deployment-designer/SKILL.md

@@ -0,0 +1,137 @@
+# Skill: Deployment Designer
+
+> 在代码实现前输出完整部署方案：部署拓扑、环境配置、发布命令、数据迁移、回滚策略和部署后冒烟测试方案。该 Skill 是 Phase 3 Step 3 的执行入口。
+
+## 触发条件
+
+- 用户要求设计部署方案、发布方案或上线方案
+- 用户提到 “Phase 3 Step 3”、“部署方案”、“deployment plan”
+- API / DB 设计完成后，需要进入部署方案设计
+- Initial 阶段准备进入测试设计前，`3-technical-plan/3-deployment/` 仍为空
+
+## 前置依赖
+
+1. `logos/resources/prd/3-technical-plan/1-architecture/` 中存在架构概要
+2. `logos/resources/prd/3-technical-plan/2-scenario-implementation/` 中存在场景实现文档
+3. API / DB 设计已完成，或对应模块在 `skip_phases` 中明确跳过
+4. `logos/logos-project.yaml` 可读
+
+## 核心能力
+
+1. 从架构、API、DB 和技术栈中推导部署目标
+2. 设计本地 / 测试 / 预发 / 生产环境部署拓扑
+3. 明确环境变量、密钥来源、构建命令和发布命令
+4. 定义数据迁移、初始化数据和回滚策略
+5. 设计部署后检查清单
+6. 设计 smoke 测试方案输入，供 `test-writer` 生成 `SMOKE-*` 用例
+7. 更新 `logos-project.yaml` 的部署门禁信息
+
+## 执行步骤
+
+### Step 1: 读取上下文
+
+必须读取：
+
+- `logos/logos-project.yaml`
+- 架构概要文档
+- 场景实现文档
+- API 规格（如存在）
+- DB DDL（如存在）
+- 现有部署方案（如存在）
+
+重点确认：
+
+- 项目是否需要部署
+- 目标环境有哪些
+- 是否存在远程服务、生产环境、密钥、域名、证书或数据迁移
+- smoke 需要覆盖哪些最小链路
+
+### Step 2: 判断部署门禁
+
+默认规则：
+
+- 软件项目默认需要部署方案
+- 有运行环境的项目默认需要部署执行和 smoke
+- 纯文档、纯规范、无需运行环境的库项目可声明 `deployment_required: false`
+
+若用户选择无需部署，部署方案仍需写明原因和跳过条件。
+
+### Step 3: 输出部署方案
+
+默认文件：
+
+`logos/resources/prd/3-technical-plan/3-deployment/core-01-deployment-plan.md`
+
+文档结构：
+
+```markdown
+# core-01-deployment-plan
+
+## 一、部署目标
+
+## 二、部署拓扑
+
+## 三、环境变量与密钥
+
+## 四、构建与发布命令
+
+## 五、数据迁移策略
+
+## 六、回滚策略
+
+## 七、部署后检查清单
+
+## 八、冒烟测试方案
+
+## 九、门禁结论
+```
+
+### Step 4: 设计 smoke 输入
+
+在部署方案的“冒烟测试方案”中列出必须覆盖的 smoke 检查项：
+
+- 健康检查
+- 核心入口
+- 数据库迁移
+- 静态资源
+- 配置与密钥
+- 关键链路
+- 日志与监控
+
+具体 `SMOKE-*` 用例由 `test-writer` 输出到 `logos/resources/test/smoke/`。
+
+### Step 5: 更新 logos-project.yaml
+
+如模块需要部署，建议写入：
+
+```yaml
+deployment_gates:
+  core:
+    deployment_required: true
+    smoke_required: true
+    environments:
+      - staging
+```
+
+并将部署方案加入 `resource_index`。
+
+## 输出规范
+
+- 部署方案：`logos/resources/prd/3-technical-plan/3-deployment/core-01-deployment-plan.md`
+- 文档语言遵循项目 locale
+- Mermaid 可用于部署拓扑图
+- 不执行任何部署命令
+
+## 人类确认点
+
+本 Skill 只设计部署方案，不执行部署。部署执行必须等到：
+
+1. 代码实现完成
+2. `openlogos verify` 通过
+3. 用户明确授权部署
+
+## 推荐提示词
+
+- `帮我设计部署方案`
+- `按 Phase 3 Step 3 输出部署方案`
+- `基于当前架构设计 staging 部署和 smoke 方案`

package/skills/deployment-executor/SKILL.md

@@ -0,0 +1,133 @@
+# Skill: Deployment Executor
+
+> 在 `openlogos verify` 通过后，按已合并的部署方案执行经人类明确确认的部署任务，并引导运行 `openlogos smoke`。该 Skill 只在部署执行阶段使用。
+
+## 触发条件
+
+- 用户明确要求执行部署
+- 用户说“按部署方案部署”“执行当前提案的部署任务”“部署到 staging / production”
+- 当前提案 `tasks.md` 存在 `[deploy]` section
+- Initial 阶段 verify 通过后需要部署到目标环境
+
+## 前置依赖
+
+1. 用户明确授权部署
+2. `logos/resources/prd/3-technical-plan/3-deployment/` 中存在部署方案
+3. 当前提案已 `VERIFY_PASS`
+4. 当前提案 `tasks.md` 中存在 `[deploy]` section
+5. 部署所需命令、环境变量和回滚策略已在部署方案中声明
+
+如果任一条件不满足，停止并说明缺少哪一项。
+
+## 核心能力
+
+1. 读取部署方案和当前提案部署任务
+2. 将部署任务拆解为可执行步骤
+3. 在关键命令前说明目的、影响环境和回滚点
+4. 执行部署命令并记录结果
+5. 生成部署报告
+6. 写入部署完成标记
+7. 引导用户运行 `openlogos smoke`
+
+## 执行步骤
+
+### Step 1: 确认授权
+
+部署是人类确认点。必须看到用户明确表达，例如：
+
+- `执行部署`
+- `部署到 staging`
+- `按部署方案部署`
+
+不能因为用户说“继续”“按流程走完”而自动部署。
+
+### Step 2: 读取部署上下文
+
+必须读取：
+
+- `logos/resources/prd/3-technical-plan/3-deployment/*.md`
+- 当前提案 `proposal.md`
+- 当前提案 `tasks.md` 的 `[deploy]` section
+- 已合并后的相关主规格
+
+### Step 3: 执行前检查
+
+检查：
+
+- 当前是否 `VERIFY_PASS`
+- 是否存在未完成代码任务
+- 部署目标环境是否明确
+- 回滚策略是否可执行
+- 必要环境变量和密钥是否已由用户确认
+- smoke 测试命令是否配置或已有替代说明
+
+### Step 4: 执行部署
+
+按部署方案逐项执行。
+
+每个关键命令前必须说明：
+
+- 命令目的
+- 影响环境
+- 失败后的中止或回滚方式
+
+不得执行部署方案中没有定义的命令。
+
+### Step 5: 生成部署报告
+
+写入：
+
+`logos/resources/verify/deployment-report.md`
+
+报告包含：
+
+- 部署时间
+- 目标环境
+- 执行命令摘要
+- 迁移结果
+- 服务启动结果
+- 回滚点
+- 未解决风险
+
+### Step 6: 写入部署完成标记
+
+部署成功后：
+
+- 勾选当前提案 `tasks.md` 中的 `[deploy]` 任务
+- 写入 `logos/changes/<slug>/DEPLOY_DONE`
+
+部署失败时：
+
+- 不得写入 `DEPLOY_DONE`
+- 输出失败点和回滚建议
+- 以 `logos/resources/verify/deployment-report.md` 记录失败摘要
+
+### Step 7: 引导 smoke
+
+部署完成后提示用户明确授权运行：
+
+```bash
+openlogos smoke
+```
+
+如有目标环境：
+
+```bash
+openlogos smoke --env staging
+```
+
+AI 不得自动运行 `openlogos smoke`，除非用户明确授权。
+
+## 禁止行为
+
+- 未经用户明确确认自动部署
+- 跳过部署方案，凭经验执行命令
+- 自动执行涉及生产、远程服务器、密钥、发布、域名或数据迁移的命令
+- 部署失败后写入 `DEPLOY_DONE`
+- 部署后直接 archive，跳过 `openlogos smoke`
+
+## 推荐提示词
+
+- `按部署方案部署到 staging`
+- `执行当前提案的部署任务`
+- `部署完成后帮我准备 smoke 命令`

package/skills/merge-executor/SKILL.md

@@ -22,7 +22,7 @@
 3. 精准定位主文档中的对应章节并执行合并
 4. 保持主文档的格式和风格一致性
 5. 输出变更摘要
-6. **等待人类确认后停止** — 合并完成后 AI 的职责即结束，不得主动执行 `openlogos archive`
+6. **等待人类确认后停止** — 合并完成后 AI 的职责即结束，不得主动执行 verify、部署、smoke 或 archive
 
 ## 执行步骤
 
@@ -83,13 +83,25 @@ touch logos/changes/{slug}/SPEC_MERGED
 **Step 2：运行验收（代码实现完成后）**
 请在项目根目录运行：
 openlogos verify
-- 验收通过（PASS）→ 继续 Step 3 归档
+- 验收通过（PASS）→ 无部署任务时可进入归档；有部署任务时进入 Step 3
 - 验收失败（FAIL）→ 修复代码后重新运行，无需重走 merge 流程
 
-**Step 3：归档提案（验收通过后）**
+**Step 3：部署（仅当 tasks.md 存在 [deploy] section）**
+验收通过后，由用户明确授权 AI 按部署方案执行部署任务。
+
+AI 必须读取：
+- logos/resources/prd/3-technical-plan/3-deployment/
+- 当前提案 tasks.md 的 [deploy] section
+
+**Step 4：冒烟测试（仅当已部署）**
+部署完成后，由用户明确授权运行：
+openlogos smoke
+
+**Step 5：归档提案**
+verify 通过且无部署任务，或部署完成且 smoke 通过后：
 openlogos archive <slug>
 
-openlogos verify 和 openlogos archive 均为人类确认点，AI 未经用户明确授权不得自行执行。
+openlogos verify、部署执行、openlogos smoke 和 openlogos archive 均为人类确认点，AI 未经用户明确授权不得自行执行。
 ```
 
 ## 合并原则
@@ -104,6 +116,7 @@ openlogos verify 和 openlogos archive 均为人类确认点，AI 未经用户
 - 直接修改 `logos/resources/` 中的主文档（就地编辑）
 - 除写入 `logos/changes/<slug>/SPEC_MERGED` 外，不修改 `logos/changes/` 中的任何文件
 - 合并过程中不创建新文件（除非 delta 指定新增一个全新的文档）
+- 合并部署 delta 时，只合并部署方案文档，不执行部署命令
 
 ## 实践经验
 

package/skills/project-init/SKILL.md

@@ -15,6 +15,7 @@
 3. 生成 `logos/logos-project.yaml` AI 协作索引
 4. 生成 `AGENTS.md` / `CLAUDE.md` AI 指令文件（根目录）
 5. 创建 `logos/changes/` 变更管理目录
+6. 创建部署方案与 smoke 测试所需目录
 
 ## 执行步骤
 
@@ -42,10 +43,15 @@ project-root/
     │   │   │   └── 2-page-design/
     │   │   └── 3-technical-plan/
     │   │       ├── 1-architecture/
-    │   │       └── 2-scenario-implementation/
+    │   │       ├── 2-scenario-implementation/
+    │   │       └── 3-deployment/
     │   ├── api/
     │   ├── database/
-    │   └── scenario/
+    │   ├── test/
+    │   │   └── smoke/
+    │   ├── scenario/
+    │   ├── implementation/
+    │   └── verify/
     └── changes/
 ```
 
@@ -66,6 +72,11 @@ project-root/
       "path": "./resources/api",
       "pattern": "**/*.{yaml,yml,json}"
     },
+    "test": {
+      "label": { "en": "Test Cases", "zh": "测试用例" },
+      "path": "./resources/test",
+      "pattern": "**/*.md"
+    },
     "scenario": {
       "label": { "en": "Scenarios", "zh": "业务场景" },
       "path": "./resources/scenario",
@@ -75,7 +86,24 @@ project-root/
       "label": { "en": "Database", "zh": "数据库" },
       "path": "./resources/database",
       "pattern": "**/*.sql"
+    },
+    "implementation": {
+      "label": { "en": "Implementation", "zh": "实现清单" },
+      "path": "./resources/implementation",
+      "pattern": "**/*.md"
+    },
+    "verify": {
+      "label": { "en": "Verify Reports", "zh": "验收报告" },
+      "path": "./resources/verify",
+      "pattern": "**/*.{jsonl,md}"
     }
+  },
+  "verify": {
+    "result_path": "logos/resources/verify/test-results.jsonl"
+  },
+  "smoke": {
+    "result_path": "logos/resources/verify/smoke-results.jsonl",
+    "report_path": "logos/resources/verify/smoke-report.md"
   }
 }
 ```
@@ -124,6 +152,8 @@ Read `logos/logos-project.yaml` first to understand the project resource index.
 3. All API designs must originate from scenario sequence diagrams
 4. All code changes must have corresponding API orchestration tests
 5. Use the Delta change workflow for iterations (see logos/changes/ directory)
+6. Deployment is a human confirmation point; AI must not deploy without explicit authorization
+7. If deployment is required, smoke tests must be designed and run via `openlogos smoke` after deployment
 
 ## Conventions
 {从 logos-project.yaml 的 conventions 提取}
@@ -131,6 +161,13 @@ Read `logos/logos-project.yaml` first to understand the project resource index.
 
 同时生成 `CLAUDE.md`，内容与 AGENTS.md 一致。
 
+Phase 检测逻辑必须包含：
+
+- API/DB 完成但 `3-technical-plan/3-deployment/` 为空 → Phase 3 Step 3（deployment-designer）
+- 部署方案存在但 `logos/resources/test/` 为空 → Phase 3 Step 4a（test-writer）
+- verify 通过但部署未完成 → Phase 3 Step 7（deployment-executor，人类确认点）
+- 部署完成但 smoke 未通过 → Phase 3 Step 8（openlogos smoke，人类确认点）
+
 ### Step 6: 输出初始化报告
 
 向用户报告创建了哪些文件和目录，并给出下一步建议：
@@ -145,6 +182,9 @@ Read `logos/logos-project.yaml` first to understand the project resource index.
 - `logos/logos-project.yaml`：有效的 YAML
 - `AGENTS.md` / `CLAUDE.md`：Markdown 格式，位于项目根目录
 - `logos/` 下所有目录已创建，空目录包含 `.gitkeep`
+- 必须创建 `logos/resources/prd/3-technical-plan/3-deployment/`
+- 必须创建 `logos/resources/test/smoke/`
+- 必须创建 `logos/resources/verify/`
 
 ## 实践经验
 

package/skills/test-orchestrator/SKILL.md

@@ -1,23 +1,23 @@
 # Skill: Test Orchestrator
 
-> 基于业务场景和时序图设计 **API 编排测试**用例（Phase 3 Step 3b），覆盖正常/异常/边界场景，自动识别外部依赖并应用测试策略，作为端到端 API 验收标准。**仅适用于涉及 API 的项目。**
+> 基于业务场景和时序图设计 **API 编排测试**用例（Phase 3 Step 4b），覆盖正常/异常/边界场景，自动识别外部依赖并应用测试策略，作为端到端 API 验收标准。**仅适用于涉及 API 的项目。**
 
 ## 与 test-writer 的关系
 
-本 Skill 负责测试金字塔的**顶层**——API 编排测试（HTTP 请求级别），执行于 Phase 3 Step 3b。
+本 Skill 负责测试金字塔的**顶层**——API 编排测试（HTTP 请求级别），执行于 Phase 3 Step 4b。
 
-底层的单元测试和场景测试（函数调用级别）由 `test-writer` Skill 在 Step 3a 完成。Step 3a 是所有项目的必选步骤，Step 3b（本 Skill）仅在项目涉及 API 时执行。
+底层的单元测试和场景测试（函数调用级别）由 `test-writer` Skill 在 Step 4a 完成。Step 4a 是所有项目的必选步骤，Step 4b（本 Skill）仅在项目涉及 API 时执行。
 
 ## 触发条件
 
 - 用户要求设计 API 编排测试
-- 用户提到 "Phase 3 Step 3b"、"API 编排"、"编排测试"
-- Step 3a（test-writer）完成后，AI 引导用户继续进入 Step 3b
+- 用户提到 "Phase 3 Step 4b"、"API 编排"、"编排测试"
+- Step 4a（test-writer）完成后，AI 引导用户继续进入 Step 4b
 - 用户需要验收已部署的 API 代码
 
 ## 前置依赖
 
-- `logos/resources/test/` 中包含测试用例规格文档（Step 3a 已完成）
+- `logos/resources/test/` 中包含测试用例规格文档（Step 4a 已完成）
 - `logos/resources/prd/3-technical-plan/2-scenario-implementation/` 中包含场景时序图
 - `logos/resources/api/` 中包含 API 规格（OpenAPI YAML）
 - `logos-project.yaml` 中包含 `external_dependencies`（如有）