@miniidealab/openlogos 0.9.23 → 0.9.25

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`（如有）

package/skills/test-writer/SKILL.md

@@ -5,18 +5,19 @@
 ## 触发条件
 
 - 用户要求设计测试用例或测试方案
-- 用户提到 "Phase 3 Step 3"、"Step 3a"、"测试先行"、"测试设计"
+- 用户提到 "Phase 3 Step 4a"、"Step 4a"、"测试先行"、"测试设计"
 - 已有场景时序图，需要在写代码前设计测试
 - 用户指定某个场景编号（如 S01）需要设计测试
 
 ## 前置依赖
 
 - `logos/resources/prd/3-technical-plan/2-scenario-implementation/` 中包含场景时序图（**必需**）
+- `logos/resources/prd/3-technical-plan/3-deployment/` 中包含部署方案（如项目需要部署则必需）
 - `logos/resources/api/` 中包含 API 规格（有则读取，无则跳过——非 API 项目可能没有）
 - `logos/resources/database/` 中包含 DB DDL（有则读取，无则跳过）
 - `logos/resources/prd/1-product-requirements/` 中包含需求文档（用于追溯验收条件）
 
-**不可跳过**：无论项目类型如何，Step 3a（本 Skill）都必须执行。
+**不可跳过**：无论项目类型如何，Step 4a（本 Skill）都必须执行。若部署方案声明需要部署，本 Skill 必须一并设计部署后冒烟测试。
 
 ## 核心能力
 
@@ -25,7 +26,8 @@
 3. 从业务规则和 EX 异常用例中的单点错误处理提取单元测试用例
 4. 从时序图 Step 序列提取场景测试用例（主路径）
 5. 从 EX 异常用例提取场景测试用例（异常路径）
-6. 从 Phase 1/2 验收条件反向校验测试覆盖完整性
+6. 从部署方案提取 smoke 测试用例（仅需要部署的项目）
+7. 从 Phase 1/2 验收条件反向校验测试覆盖完整性
 
 ## 执行步骤
 
@@ -34,6 +36,7 @@
 读取以下文件建立完整上下文：
 
 - 场景时序图（`logos/resources/prd/3-technical-plan/2-scenario-implementation/`）
+- 部署方案（`logos/resources/prd/3-technical-plan/3-deployment/`）—— 如果项目需要部署
 - API YAML（`logos/resources/api/`）—— 如果存在
 - DB DDL（`logos/resources/database/`）—— 如果存在
 - Phase 1 需求文档（验收条件）
@@ -132,6 +135,32 @@
 
 **判断标准**：如果该用例在 CI 无头环境中无法稳定运行并自动断言结果，就应加 `[manual]`。
 
+#### 3d: 部署后冒烟测试（需要部署时）
+
+当部署方案存在且声明需要部署时，必须设计 smoke 测试用例。冒烟测试验证“部署后的环境是否可用”，不替代 UT/ST/API 编排测试。
+
+从部署方案中提取以下用例：
+
+- 健康检查：服务进程、HTTP health endpoint、CLI version 或桌面应用启动检查
+- 核心入口：主页、登录页、主 API、主命令
+- 数据库迁移：关键表/字段存在、迁移版本正确、初始化数据可读
+- 静态资源：前端 bundle、图片、CSS、字体或下载资源可访问
+- 配置与密钥：必要环境变量存在且没有使用测试占位值
+- 关键链路：最小可用用户路径，例如登录、创建一条核心记录、读取结果
+- 日志与监控：部署后没有阻断性错误
+
+**每个 smoke 用例格式**：
+
+| 字段 | 说明 |
+|------|------|
+| ID | `SMOKE-{模块}-{序号}`，如 `SMOKE-core-01` |
+| 描述 | 验证什么部署后行为 |
+| 来源 | 部署方案章节或检查项 |
+| 目标环境 | local / staging / production |
+| 前置条件 | 部署完成、迁移完成、必要配置存在 |
+| 操作 | 执行的命令、请求或访问动作 |
+| 预期结果 | 返回码、页面状态、日志、数据库状态 |
+
 ### Step 4: 覆盖度校验
 
 反向校验测试用例是否覆盖了所有关键约束：
@@ -141,6 +170,7 @@
 - [ ] 每个 EX 异常用例至少对应 1 个 ST 用例
 - [ ] API 每个 `required` 字段至少 1 个 UT 用例
 - [ ] DB 每个 `UNIQUE` / `CHECK` 约束至少 1 个 UT 用例
+- [ ] 如需要部署，部署方案中的每个部署后检查项至少对应 1 个 SMOKE 用例
 
 如有未覆盖项，补充用例或向用户说明理由。
 
@@ -165,13 +195,13 @@
 
 ### Step 6: 输出测试用例规格文档
 
-按场景输出 Markdown 格式的测试用例规格文档。
+按场景输出 Markdown 格式的测试用例规格文档。若需要部署，同时输出 smoke 测试用例规格文档。
 
 ### Step 7: 引导后续操作
 
 根据项目类型引导用户进入下一步：
 
-- **涉及 API** → 「继续进入 Step 3b 设计 API 编排测试？」
+- **涉及 API** → 「继续进入 Step 4b 设计 API 编排测试？」
 - **不涉及 API** → 「测试设计已完成，建议进入代码生成：对我说『按 S01 的规格帮我实现』」
 
 ## 输出规范
@@ -180,7 +210,9 @@
 - **存放位置**：`logos/resources/test/`
 - **命名规则**：`<module>-{场景编号}-test-cases.md`（如 `core-S01-test-cases.md`；从 `logos-project.yaml` 的 `modules[]` 读取当前模块，默认为 `core`）
 - 每个文件包含：单元测试用例（按来源分组）+ 场景测试用例（主路径 + 异常路径）
-- 用例 ID 全局唯一：`UT-{场景编号}-{序号}` / `ST-{场景编号}-{序号}`
+- **Smoke 存放位置**：`logos/resources/test/smoke/`
+- **Smoke 命名规则**：`<module>-smoke-test-cases.md`
+- 用例 ID 全局唯一：`UT-{场景编号}-{序号}` / `ST-{场景编号}-{序号}` / `SMOKE-{module}-{序号}`
 
 ### 文档结构模板
 
@@ -235,6 +267,32 @@
 | S01-AC-03 | 异常：项目已初始化 — 显示错误提示 | ST-S01-03, UT-S01-05 |
 ```
 
+### Smoke 文档结构模板
+
+```markdown
+# {module}: 部署后冒烟测试用例
+
+## 一、冒烟测试范围
+
+| 环境 | 覆盖范围 | 说明 |
+|------|----------|------|
+| staging | 健康检查、核心 API、迁移检查 | launch 前必跑 |
+
+## 二、冒烟测试用例
+
+| ID | 描述 | 来源 | 目标环境 | 前置条件 | 操作 | 预期结果 |
+|----|------|------|----------|----------|------|----------|
+| SMOKE-core-01 | 健康检查接口可访问 | 部署方案：部署后检查 | staging | 服务已部署 | GET /health | 200 OK |
+
+## 三、覆盖度校验
+
+- [x] 健康检查：已覆盖
+- [x] 核心入口：已覆盖
+- [x] 数据库迁移：已覆盖
+- [x] 静态资源：已覆盖
+- [x] 关键链路：已覆盖
+```
+
 ## 用例 ID 合约
 
 用例 ID（`UT-S01-01`、`ST-S01-01`）是设计文档与运行时的**绑定合约**：
@@ -242,13 +300,14 @@
 - 在 test-cases.md 中定义的 ID，必须在生成的测试代码中被原样使用
 - 测试代码的 reporter 会把每个用例的 ID 和运行结果写入 JSONL 文件
 - `openlogos verify` 通过 ID 将运行结果映射回测试用例规格，自动判定验收
-- 修改用例 ID 时必须同步修改测试代码中的 ID
+- `SMOKE-*` 由 smoke 测试脚本写入 `smoke-results.jsonl`，供 `openlogos smoke` 判定
+- 修改用例 ID 时必须同步修改对应测试代码或 smoke 脚本中的 ID
 
 详细的 JSONL 格式定义和各语言 reporter 代码模板见 `logos/spec/test-results.md`。
 
 ## 实践经验
 
-- **测试用例是设计文档，不是代码**：本 Skill 产出的是 Markdown 格式的测试用例规格，具体的测试代码在 Step 4 代码生成阶段由 AI 基于此规格实现
+- **测试用例是设计文档，不是代码**：本 Skill 产出的是 Markdown 格式的测试用例规格，具体的测试代码在 Step 5 代码生成阶段由 AI 基于此规格实现
 - **先单元后场景**：单元测试用例覆盖单个函数的正确性，场景测试覆盖跨模块串联——先确保积木正确，再验证积木拼接
 - **不要遗漏 DB 约束**：很多 Bug 来自数据库层面的约束违反，DB 约束是单元测试用例的重要来源
 - **场景测试关注数据传递**：Step 间的数据传递（前一步输出 → 后一步输入）是最容易出错的地方

package/spec/agents-md.md

@@ -27,6 +27,10 @@ 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. All generated test code must include an OpenLogos reporter
+7. Deployment is a human confirmation point; AI must not deploy without explicit authorization
+8. If deployment is required, smoke tests must be designed with the test plan and run via `openlogos smoke` after deployment
+9. For launched-project change proposals, deployment and smoke decisions must be made at proposal level. A module-level deployment gate is only a default and must not force deploy/smoke for a proposal that explicitly does not require deployment.
 
 ## Document Edit Verification
 [Fixed locale-specific paragraph — re-read from disk after Markdown/text spec edits]
@@ -44,19 +48,26 @@ Phase detection logic:
 - design exists but `3-technical-plan/1-architecture/` is empty → suggest Phase 3 Step 0 (architecture-designer)
 - architecture exists but `3-technical-plan/2-scenario-implementation/` is empty → suggest Phase 3 Step 1 (scenario-architect)
 - scenarios exist but `logos/resources/api/` is empty → suggest Phase 3 Step 2 (api-designer + db-designer)
-- API exists but `logos/resources/test/` is empty → suggest Phase 3 Step 3a (test-writer)
-- test cases exist but `logos/resources/scenario/` is empty → suggest Phase 3 Step 3b (test-orchestrator, API projects only)
-- All above exist → suggest Phase 3 Step 4 (code generation)
-- code generated but `logos/resources/verify/` is empty → suggest Phase 3 Step 5 (run tests then `openlogos verify`)
-
-Step 4 execution rules (large tasks):
+- API/DB exists but `3-technical-plan/3-deployment/` is empty → suggest Phase 3 Step 3 (deployment-designer)
+- deployment plan exists but `logos/resources/test/` is empty → suggest Phase 3 Step 4a (test-writer)
+- test cases exist but `logos/resources/scenario/` is empty → suggest Phase 3 Step 4b (test-orchestrator, API projects only)
+- orchestration tests exist but `logos/resources/implementation/` is empty → suggest Phase 3 Step 5 (code-implementor)
+- code generated but `logos/resources/verify/acceptance-report.md` is missing or verify has not passed → suggest Phase 3 Step 6 (`openlogos verify`)
+- verify passed but deployment is required and `deployment-report.md` is missing → suggest Phase 3 Step 7 (deployment-executor, human confirmation required)
+- deployment done but `smoke-report.md` / `SMOKE_PASS` is missing → suggest Phase 3 Step 8 (`openlogos smoke`)
+- smoke passed → suggest `openlogos launch`
+
+Step 5 execution rules (large tasks):
 1. Large implementation can be split by scenario/module, but each batch must be closed-loop
 2. Each batch must include business code + UT/ST test code + OpenLogos reporter
 3. Before generating code, list the UT/ST case IDs covered in this batch and keep IDs aligned with `logos/resources/test/*.md`
 4. Do not postpone all tests to the final batch
 
-Ready-to-use prompt for Step 4 batch execution:
-`Please execute Phase 3 Step 4 for this scope. If the task is large, split into batches, but each batch must deliver: (1) business code, (2) matching UT/ST test code, (3) OpenLogos reporter writing to logos/resources/verify/test-results.jsonl. Before outputting code, list the UT/ST IDs covered in this batch.`
+Deployment rules:
+1. AI must not run deployment commands unless the user explicitly authorizes deployment
+2. AI must read `logos/resources/prd/3-technical-plan/3-deployment/` before deployment
+3. Deployment completion must be followed by `openlogos smoke`
+4. Initial modules can be launched only after verify, deployment, and smoke gates pass, unless explicitly marked as not requiring deployment
 
 ## Active Skills
 [根据 `logos.config.json` 的 `aiTool` 字段动态生成]
@@ -105,7 +116,19 @@ AGENTS.md 的内容从以下文件中自动提取：
 4. All code changes must have corresponding API orchestration tests
 5. Use the Delta change workflow for iterations
 6. All generated test code must include an OpenLogos reporter (see spec/test-results.md)
-7. After editing Markdown / text specs, re-read from disk and show excerpts to the user (see 「文档修改后的验证」生成段)
+7. Deployment is a human confirmation point; AI must not deploy without explicit authorization
+8. If deployment is required, smoke tests must be designed and run via `openlogos smoke` after deployment
+9. For launched-project change proposals, deployment and smoke decisions must be made at proposal level. A module-level deployment gate is only a default and must not force deploy/smoke for a proposal that explicitly does not require deployment.
+10. After editing Markdown / text specs, re-read from disk and show excerpts to the user (see 「文档修改后的验证」生成段)
+
+### 提案级部署门禁生成规则
+
+AGENTS.md / CLAUDE.md 的变更管理段必须强调：
+- `proposal.md` 的 `## 部署影响` 是活跃提案的部署决策入口。
+- 不需要部署的提案不得创建 `[deploy]` section。
+- verify PASS 且无需部署时，应提醒用户明确授权执行 `openlogos archive <slug>`。
+- 只有提案级需要部署时，才在 verify PASS 后提醒用户明确授权部署。
+- 只有提案级需要 smoke 且部署完成后，才提醒用户明确授权执行 `openlogos smoke`。
 
 ### 生成时机
 

package/spec/change-management.md

@@ -7,10 +7,11 @@
 ## 核心原则
 
 1. **不直接修改主文档**：每次变更先在 `logos/changes/` 中创建提案
-2. **影响分析先行**：在 `proposal.md` 中明确变更范围
+2. **影响分析先行**：在 `proposal.md` 中明确变更范围和部署影响
 3. **按需传播**：不是每次都全链路更新，只更新受影响的环节
-4. **归档留痕**：变更完成后归档，保留完整历史
-5. **guard 互斥**：同一时间只允许一个活动提案；存在活动 guard 时，必须阻止新的 `openlogos change`
+4. **部署可追溯**：需要部署的提案必须产出部署 delta、部署任务和冒烟测试方案
+5. **归档留痕**：变更完成后归档，保留完整历史
+6. **guard 互斥**：同一时间只允许一个活动提案；存在活动 guard 时，必须阻止新的 `openlogos change`
 
 ## 目录结构
 
@@ -47,17 +48,36 @@ project-root/
 ## 变更原因
 [为什么要做这个变更？来源于哪个需求/反馈/Bug？]
 
+## 变更类型
+[需求级 / 设计级 / 接口级 / 代码级]
+
 ## 变更范围
 - 影响的需求文档：[列表]
 - 影响的功能规格：[列表]
 - 影响的业务场景：[列表]
 - 影响的 API：[列表]
 - 影响的 DB 表：[列表]
+- 影响的编排测试：[列表]
+
+## 部署影响
+- 是否需要部署：是 / 否
+- 部署原因：[说明为什么需要或不需要部署]
+- 影响环境：[本地 / 测试 / 预发 / 生产 / 无]
+- 是否涉及数据迁移：是 / 否
+- 是否需要回滚预案：是 / 否
 
 ## 变更概述
 [用 1-3 段话概述具体改什么]
 ```
 
+`## 部署影响` 是人工审核依据。CLI 的部署状态判断以 `tasks.md` 的 `[deploy]` section 和提案目录标记文件为准，不解析自由文本作为唯一依据。
+
+`## 部署影响` 同时也是提案级部署决策入口。CLI 应从该章节解析结构化决策，并与 `tasks.md` 的 `[deploy]` section 交叉校验：
+- `是否需要部署：否` 时，不得创建 `[deploy]` section；verify PASS 后下一步为 archive。
+- `是否需要部署：是` 时，必须创建 `[deploy]` section，并在 delta 阶段补齐部署方案影响；verify PASS 后下一步为人类确认部署。
+- `是否需要 smoke：是` 只在已部署后生效；smoke 仍由 `openlogos smoke` 独立执行。
+- 旧提案缺少结构化部署影响时，CLI 可回退到 `[deploy]` section 与模块级默认值，但必须标注兼容来源。
+
 ### tasks.md
 
 实现任务清单，使用结构化 section 格式，每个 section 对应提案流程中的一个阶段。完整格式规范见 `spec/tasks-spec.md`。
@@ -72,15 +92,21 @@ project-root/
 ## [code] 代码实现
 - [ ] 实现 src/xxx 中的业务逻辑
 - [ ] 编写对应测试
+
+## [deploy] 部署任务
+- [ ] 按部署方案部署到 staging
+- [ ] 确认迁移、配置、服务启动和回滚预案
 ```
 
 Section 标记规则：
 - `## [delta]` — delta 文档产出任务，该 section 全部勾选后可进入 `ready-to-merge`
 - `## [code]` — 代码实现任务，直接修改源文件，不产出 delta
+- `## [deploy]` — 部署执行任务，只能在 verify PASS 后、人类明确确认后执行
 - 纯代码提案可只有 `[code]` section（无 `[delta]`），CLI 会直接跳过 delta-writing 阶段
+- 不需要部署的提案不得创建 `[deploy]` section
 - 旧格式（无 section 标记）向后兼容，降级为全局勾选判断
 
-> **注意**：`openlogos verify` 是独立的 CLI 操作节点，不应写入 tasks.md 作为可勾选任务。verify 由面板的 verify 步骤触发，tasks.md 只追踪实现任务。
+> **注意**：`openlogos verify` 和 `openlogos smoke` 是独立 CLI 操作节点，不应写入 tasks.md 作为可勾选任务。tasks.md 只追踪 delta、代码和部署执行任务。
 
 ### deltas/ 目录
 
@@ -103,14 +129,18 @@ Delta 文件的目录结构映射主文档目录：
 - `deltas/database/` → 对应 `logos/resources/database/` 的变更
 - `deltas/scenario/` → 对应 `logos/resources/scenario/` 的变更
 - `deltas/test/` → 对应 `logos/resources/test/` 的变更
+- `deltas/spec/` → 对应项目根目录 `spec/` 的方法论规范变更
+- `deltas/skills/` → 对应 `logos/skills/` 的 Skill 文档变更
+
+部署方案 delta 使用 `deltas/prd/3-technical-plan/3-deployment/`，合并目标为 `logos/resources/prd/3-technical-plan/3-deployment/`。
 
-`openlogos merge` 会递归扫描上述目录，保留子目录映射。例如 `deltas/prd/2-product-design/1-feature-specs/foo.md` 会合并到 `logos/resources/prd/2-product-design/1-feature-specs/foo.md`。
+`openlogos merge` 会递归扫描上述目录，保留子目录映射。例如 `deltas/prd/3-technical-plan/3-deployment/core-01-deployment-plan.md` 会合并到 `logos/resources/prd/3-technical-plan/3-deployment/core-01-deployment-plan.md`。
 
 ## 变更工作流
 
-> **核心原则**：`openlogos merge`、`openlogos verify`、`openlogos archive` 和 `git push` 是人类确认点。AI 可提醒、解释、准备命令；未经用户明确授权不得执行。用户以明确请求或 slash command 授权时，AI 可以代为执行。不得在"顺手完成流程"、"按流程走完"等隐式场景中自动触发。
+> **核心原则**：`openlogos merge`、`openlogos verify`、部署执行、`openlogos smoke`、`openlogos archive` 和 `git push` 是人类确认点。AI 可提醒、解释、准备命令；未经用户明确授权不得执行。用户以明确请求或 slash command 授权时，AI 可以代为执行。不得在“顺手完成流程”“按流程走完”等隐式场景中自动触发。
 >
-> **规格驱动代码**：代码实现必须在规格合并进主文档（Step 6）之后才能开始，不允许基于 delta 草稿直接写代码。
+> **规格驱动代码**：代码实现必须在规格合并进主文档之后才能开始，不允许基于 delta 草稿直接写代码。
 
 ```
 1. 创建变更提案（CLI）
@@ -152,14 +182,29 @@ Delta 文件的目录结构映射主文档目录：
    └── 验收通过（PASS）→ 继续步骤 9
    └── 验收失败（FAIL）→ 修复代码后重新运行，不需要重走 merge 流程
 
-9. 归档变更（CLI）【人类确认点】
+9. 部署执行（如需要）【人类确认点】
+   └── 仅当 VERIFY_PASS 存在、提案级 `是否需要部署：是` 且 tasks.md 有 [deploy] section 时进入
+   └── 用户必须明确授权 AI 执行部署
+   └── AI 必须读取合并后的部署方案文档和 [deploy] section
+   └── 部署完成后生成 logos/resources/verify/deployment-report.md
+   └── 部署完成后写入 logos/changes/{slug}/DEPLOY_DONE
+   └── 部署失败时不得写入 DEPLOY_DONE，应输出失败点和回滚建议
+
+10. 运行部署后冒烟测试（CLI）【人类确认点】
+   └── 仅当提案级 `是否需要 smoke：是` 且 DEPLOY_DONE 存在时运行 openlogos smoke
+   └── openlogos smoke 读取 smoke 结果并生成 logos/resources/verify/smoke-report.md
+   └── 冒烟通过写入 SMOKE_PASS
+   └── 冒烟失败写入 SMOKE_FAIL
+   └── SMOKE_PASS 后才能归档提案；无需 smoke 的提案在部署完成后可归档
+
+11. 归档变更（CLI）【人类确认点】
    └── openlogos archive {slug}
    └── 将 logos/changes/{slug}/ 移入 logos/changes/archive/
    └── 若当前 guard 指向该提案，则删除 logos/.openlogos-guard
    └── 归档完成后，AI 自动 commit 归档变更（告知用户，无需确认）
    └── commit message 格式：chore({slug}): archive change proposal
 
-10. 推送到远端（Git）【人类确认点】
+12. 推送到远端（Git）【人类确认点】
     └── AI 提示用户确认是否执行 git push
     └── 用户明确授权后，AI 执行 git push
     └── 未获授权不得自动推送
@@ -169,9 +214,9 @@ Delta 文件的目录结构映射主文档目录：
 
 | 变更类型 | commit 策略 |
 |---------|------------|
-| 需求级 / 设计级变更 | 至少 3 个 commit：规格（Step 6）+ 代码（Step 7）+ 归档（Step 9） |
-| 接口级变更 | 至少 2 个 commit：规格+代码合并（Step 6-7）+ 归档（Step 9） |
-| 代码级修复 | 至少 2 个 commit：代码（Step 7）+ 归档（Step 9） |
+| 需求级 / 设计级变更 | 至少 3 个 commit：规格（Step 6）+ 代码（Step 7）+ 归档（Step 11） |
+| 接口级变更 | 至少 2 个 commit：规格+代码合并（Step 6-7）+ 归档（Step 11） |
+| 代码级修复 | 至少 2 个 commit：代码（Step 7）+ 归档（Step 11） |
 
 ## 变更传播规则
 
@@ -179,10 +224,20 @@ Delta 文件的目录结构映射主文档目录：
 
 | 变更类型 | 最少需要更新 | 说明 |
 |---------|------------|------|
-| 需求级变更 | 全链路 | 需求变了，所有下游都可能受影响 |
-| 设计级变更 | 原型 + 场景 + API/DB + 编排 + 代码 | 需求不变，实现方案调整 |
-| 接口级变更 | API/DB + 编排 + 代码 | 设计不变，接口细节调整 |
-| 代码级修复 | 代码 + 重新验收 | Bug 修复，不涉及设计变更 |
+| 需求级变更 | 全链路 + 部署影响分析 | 需求变了，所有下游都可能受影响 |
+| 设计级变更 | 原型 + 场景 + API/DB + 编排 + 代码 + 部署影响分析 | 需求不变，实现方案调整 |
+| 接口级变更 | API/DB + 编排 + 代码 + 部署影响分析 | 设计不变，接口细节调整 |
+| 部署级变更 | 部署方案 + smoke 用例 + `[deploy]` 任务 | 发布平台、环境变量、迁移、回滚、健康检查变化 |
+| 代码级修复 | 代码 + 重新验收 + 部署影响分析 | Bug 修复，不涉及设计变更时仍需判断是否需要重新部署 |
+
+## 提案级部署决策优先级
+
+部署与 smoke 的判断顺序如下：
+1. 活跃提案存在时，优先读取 `proposal.md` 的 `## 部署影响`。
+2. `tasks.md` 的 `[deploy]` section 是部署执行任务的结构化证据，必须与 `proposal.md` 一致。
+3. `logos-project.yaml` 的模块级 `deployment_required` / `smoke_required` 是 Initial 阶段和历史提案的默认值，不得覆盖活跃提案的明确决策。
+4. 文档-only 或规格-only 提案声明无需部署时，即使模块默认需要部署，verify PASS 后也直接建议 archive。
+5. 部署决策缺失或冲突时，CLI 应输出警告，并采用保守策略：不自动部署，等待用户修正提案。
 
 ## Git 集成
 
@@ -199,9 +254,9 @@ AI 在以下三个节点自动提交（告知用户，无需确认）：
 |------|-------------------|---------|
 | merge 完成后（Step 6） | `docs({slug}): merge spec deltas` | logos/resources/ 下的规格文档变更 |
 | 代码实现完成后（Step 7） | `feat/fix({slug}): implement changes` | 业务代码 + 测试代码 |
-| archive 完成后（Step 9） | `chore({slug}): archive change proposal` | logos/changes/archive/ 归档文件 |
+| archive 完成后（Step 11） | `chore({slug}): archive change proposal` | logos/changes/archive/ 归档文件 |
 
-push 是独立的人类确认点（Step 10），AI 必须等待用户明确授权后才执行。
+push 是独立的人类确认点（Step 12），AI 必须等待用户明确授权后才执行。
 
 ## MERGE_PROMPT.md 文件规范
 
@@ -221,7 +276,7 @@ push 是独立的人类确认点（Step 10），AI 必须等待用户明确授
 
 ### 1. {delta-relative-path}
 - Delta 文件：`logos/changes/{slug}/deltas/{category}/{relative-file}`
-- 目标目录：`logos/resources/{category}/{relative-dir}/`
+- 目标目录：`{target-dir}/`
 - 操作：读取 delta 中的 ADDED / MODIFIED / REMOVED 标记，合并到目标目录中对应的主文档
 
 ## 执行要求
@@ -235,7 +290,7 @@ push 是独立的人类确认点（Step 10），AI 必须等待用户明确授
 8. 所有变更合并完成后，自动执行 git commit（告知用户，无需确认）：
    `git add -A && git commit -m "docs({slug}): merge spec deltas"`
 9. 写入 `logos/changes/{slug}/SPEC_MERGED`
-   然后提示用户：按更新后的规格实现代码，代码完成后运行 `openlogos verify` 验收，验收通过后明确授权执行 `openlogos archive {slug}`。
+   然后提示用户：按更新后的规格实现代码；代码完成后运行 `openlogos verify`；如有 `[deploy]` section，验收通过后由用户明确授权部署，再运行 `openlogos smoke`；最后明确授权执行 `openlogos archive {slug}`。
 ```
 
 ## CLI 命令