@miniidealab/openlogos 0.9.22 → 0.9.24

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,9 @@ 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
 
 ## Document Edit Verification
 [Fixed locale-specific paragraph — re-read from disk after Markdown/text spec edits]
@@ -44,19 +47,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 +115,9 @@ 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. After editing Markdown / text specs, re-read from disk and show excerpts to the user (see 「文档修改后的验证」生成段)
 
 ### 生成时机
 

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,30 @@ project-root/
 ## 变更原因
 [为什么要做这个变更？来源于哪个需求/反馈/Bug？]
 
+## 变更类型
+[需求级 / 设计级 / 接口级 / 代码级]
+
 ## 变更范围
 - 影响的需求文档：[列表]
 - 影响的功能规格：[列表]
 - 影响的业务场景：[列表]
 - 影响的 API：[列表]
 - 影响的 DB 表：[列表]
+- 影响的编排测试：[列表]
+
+## 部署影响
+- 是否需要部署：是 / 否
+- 部署原因：[说明为什么需要或不需要部署]
+- 影响环境：[本地 / 测试 / 预发 / 生产 / 无]
+- 是否涉及数据迁移：是 / 否
+- 是否需要回滚预案：是 / 否
 
 ## 变更概述
 [用 1-3 段话概述具体改什么]
 ```
 
+`## 部署影响` 是人工审核依据。CLI 的部署状态判断以 `tasks.md` 的 `[deploy]` section 和提案目录标记文件为准，不解析自由文本作为唯一依据。
+
 ### tasks.md
 
 实现任务清单，使用结构化 section 格式，每个 section 对应提案流程中的一个阶段。完整格式规范见 `spec/tasks-spec.md`。
@@ -72,15 +86,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 +123,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 +176,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）【人类确认点】
+   └── 部署完成后运行 openlogos smoke
+   └── openlogos smoke 读取 smoke 结果并生成 logos/resources/verify/smoke-report.md
+   └── 冒烟通过写入 SMOKE_PASS
+   └── 冒烟失败写入 SMOKE_FAIL
+   └── SMOKE_PASS 后才能归档提案；Initial 阶段还必须通过该门禁后才能 openlogos launch
+
+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 +208,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 +218,11 @@ Delta 文件的目录结构映射主文档目录：
 
 | 变更类型 | 最少需要更新 | 说明 |
 |---------|------------|------|
-| 需求级变更 | 全链路 | 需求变了，所有下游都可能受影响 |
-| 设计级变更 | 原型 + 场景 + API/DB + 编排 + 代码 | 需求不变，实现方案调整 |
-| 接口级变更 | API/DB + 编排 + 代码 | 设计不变，接口细节调整 |
-| 代码级修复 | 代码 + 重新验收 | Bug 修复，不涉及设计变更 |
+| 需求级变更 | 全链路 + 部署影响分析 | 需求变了，所有下游都可能受影响 |
+| 设计级变更 | 原型 + 场景 + API/DB + 编排 + 代码 + 部署影响分析 | 需求不变，实现方案调整 |
+| 接口级变更 | API/DB + 编排 + 代码 + 部署影响分析 | 设计不变，接口细节调整 |
+| 部署级变更 | 部署方案 + smoke 用例 + `[deploy]` 任务 | 发布平台、环境变量、迁移、回滚、健康检查变化 |
+| 代码级修复 | 代码 + 重新验收 + 部署影响分析 | Bug 修复，不涉及设计变更时仍需判断是否需要重新部署 |
 
 ## Git 集成
 
@@ -199,9 +239,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 +261,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 +275,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 命令

package/spec/cli-json-output.md

@@ -4,7 +4,7 @@
 
 ## 1. 概述
 
-OpenLogos CLI 的 `status`、`next`、`verify`、`detect` 四个命令支持 `--format json` 参数，输出结构化 JSON 供外部工具（如 RunLogos）以编程方式消费。
+OpenLogos CLI 的 `status`、`next`、`verify`、`smoke`、`detect` 五类命令支持 `--format json` 参数，输出结构化 JSON 供外部工具（如 RunLogos）以编程方式消费。
 
 ### 1.1 通用约定
 
@@ -21,10 +21,10 @@ OpenLogos CLI 的 `status`、`next`、`verify`、`detect` 四个命令支持 `--
 
 ```jsonc
 {
-  "command": "<command-name>",   // "status" | "next" | "verify" | "detect" | "module list"
-  "version": "<cli-version>",   // CLI 版本号，如 "0.5.9"
-  "timestamp": "<ISO-8601>",    // 输出时间戳
-  "data": { ... }               // 命令特定的数据负载
+  "command": "<command-name>",   // "status" | "next" | "verify" | "smoke" | "detect" | "module list"
+  "version": "<cli-version>",
+  "timestamp": "<ISO-8601>",
+  "data": { ... }
 }
 ```
 
@@ -106,8 +106,29 @@ openlogos status --format json  # JSON 格式
       "done": false,
       "skipped": false,
       "files": []
+    },
+    {
+      "key": "phase.3-3-deployment",
+      "label": "Phase 3-3 · 部署方案",
+      "done": true,
+      "skipped": false,
+      "files": ["core-01-deployment-plan.md"]
+    },
+    {
+      "key": "phase.3-7-deploy",
+      "label": "Phase 3-7 · 部署执行",
+      "done": false,
+      "skipped": false,
+      "files": []
+    },
+    {
+      "key": "phase.3-8-smoke",
+      "label": "Phase 3-8 · 部署冒烟测试（smoke）",
+      "done": false,
+      "skipped": false,
+      "files": []
     }
-    // ... 所有 10 个 phase
+    // ... 所有 phase
   ],
   "modules": [                      // 模块注册表（来自 logos-project.yaml）
     {
@@ -135,7 +156,7 @@ openlogos status --format json  # JSON 格式
       "phase_progress": null,
       "active_change": {            // 当前活跃变更提案
         "slug": "add-refund",
-        "proposal_step": "delta-writing",  // "writing"|"delta-writing"|"ready-to-merge"|"merge-generated"|"coding"
+        "proposal_step": "delta-writing",  // 见 proposal_step 枚举
         "proposal_step_label": "撰写 Delta",
         "has_proposal": true,
         "has_tasks": true,
@@ -184,10 +205,10 @@ openlogos status --format json  # JSON 格式
 | `modules[].phase_progress` | object \| null | 是 | 各阶段进度 map（key = phase key）；`launched` 模块为 null |
 | `modules[].phase_progress[key].done` | boolean | 是 | 该阶段是否已完成 |
 | `modules[].phase_progress[key].skipped` | boolean | 是 | 该阶段是否被跳过 |
-| `modules[].phase_progress[key].scenario_coverage` | object \| undefined | 否 | 仅场景类阶段（`phase.3-1`、`phase.3-3a`）存在 |
+| `modules[].phase_progress[key].scenario_coverage` | object \| undefined | 否 | 仅场景类阶段（`phase.3-1`、`phase.3-4a`）存在 |
 | `modules[].active_change` | object \| null | 是 | 当前活跃变更提案；`initial` 模块或无活跃提案时为 null |
 | `modules[].active_change.slug` | string | 是 | 提案 slug |
-| `modules[].active_change.proposal_step` | string | 是 | 提案阶段：`"writing"` \| `"delta-writing"` \| `"ready-to-merge"` \| `"merge-generated"` \| `"coding"`；`"implementing"` / `"in-progress"` 为旧版本兼容值 |
+| `modules[].active_change.proposal_step` | string | 是 | 提案阶段：`"writing"` \| `"delta-writing"` \| `"ready-to-merge"` \| `"merge-generated"` \| `"coding"` \| `"ready-to-verify"` \| `"verify-passed"` \| `"verify-failed"` \| `"ready-to-deploy"` \| `"deploy-done"` \| `"ready-to-smoke"` \| `"smoke-passed"` \| `"smoke-failed"`；`"implementing"` / `"in-progress"` 为旧版本兼容值 |
 | `modules[].active_change.proposal_step_label` | string | 是 | 提案阶段本地化标签 |
 | `modules[].active_change.has_proposal` | boolean | 是 | 是否存在 proposal.md |
 | `modules[].active_change.has_tasks` | boolean | 是 | 是否存在 tasks.md |
@@ -306,7 +327,65 @@ openlogos verify --format json  # JSON 格式
 
 ---
 
-## 5. 错误处理
+## 5. `openlogos smoke --format json`
+
+冒烟测试用于验收部署后的目标环境是否可用，不并入 `openlogos verify`。
+
+### 5.1 用法
+
+```bash
+openlogos smoke                # 人类可读格式
+openlogos smoke --format json  # JSON 格式
+openlogos smoke --env staging
+openlogos smoke --env production --format json
+```
+
+### 5.2 JSON Schema（data 部分）
+
+```jsonc
+{
+  "environment": "staging",             // smoke 目标环境；未指定时为 null
+  "summary": {
+    "defined_count": 5,                 // 定义的 smoke 用例数
+    "executed_count": 5,                // 已执行 smoke 用例数
+    "passed_count": 5,
+    "failed_count": 0,
+    "skipped_count": 0,
+    "uncovered_count": 0,
+    "coverage_pct": 100,
+    "pass_rate_pct": 100
+  },
+  "gate": {
+    "result": "PASS",                  // "PASS" | "FAIL"
+    "reason": null                     // 失败原因分类
+  },
+  "failed_cases": [],
+  "uncovered_cases": [],
+  "skipped_cases": [],
+  "report_path": "logos/resources/verify/smoke-report.md",
+  "result_path": "logos/resources/verify/smoke-results.jsonl"
+}
+```
+
+### 5.3 字段说明
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `environment` | string \| null | 是 | 目标环境，由 `--env` 指定 |
+| `summary.defined_count` | number | 是 | smoke 用例规格中定义的用例数 |
+| `summary.executed_count` | number | 是 | smoke 结果中实际执行的用例数 |
+| `gate.result` | string | 是 | `PASS` 或 `FAIL` |
+| `gate.reason` | string \| null | 是 | 失败原因，如 `failed_cases` / `incomplete_coverage` |
+| `failed_cases` | array | 是 | 失败 smoke 用例 |
+| `uncovered_cases` | array | 是 | 未覆盖 smoke 用例 ID |
+| `report_path` | string | 是 | smoke 报告路径 |
+| `result_path` | string | 是 | smoke 结果路径 |
+
+`openlogos smoke` 与 `openlogos verify` 共享 JSONL 结果思想，但读取的是 `smoke.result_path`，默认 `logos/resources/verify/smoke-results.jsonl`。冒烟测试用例建议存放在 `logos/resources/test/smoke/`。
+
+---
+
+## 6. 错误处理
 
 当命令因错误退出时（如项目未初始化、找不到文件等），JSON 模式下输出错误 JSON 到 **stderr** 并以非零退出码退出：
 
@@ -322,7 +401,7 @@ openlogos verify --format json  # JSON 格式
 }
 ```
 
-### 5.1 错误码
+### 6.1 错误码
 
 | 错误码 | 说明 |
 |--------|------|
@@ -332,18 +411,18 @@ openlogos verify --format json  # JSON 格式
 
 ---
 
-## 6. `openlogos module list --format json`
+## 7. `openlogos module list --format json`
 
 列出项目中注册的所有模块及其生命周期状态。
 
-### 6.1 用法
+### 7.1 用法
 
 ```bash
 openlogos module list                # 人类可读格式
 openlogos module list --format json  # JSON 格式
 ```
 
-### 6.2 JSON Schema（data 部分）
+### 7.2 JSON Schema（data 部分）
 
 ```jsonc
 {
@@ -362,7 +441,7 @@ openlogos module list --format json  # JSON 格式
 }
 ```
 
-### 6.3 字段说明
+### 7.3 字段说明
 
 | 字段 | 类型 | 必填 | 说明 |
 |------|------|------|------|
@@ -375,7 +454,7 @@ openlogos module list --format json  # JSON 格式
 
 ---
 
-## 7. 完整用法示例
+## 8. 完整用法示例
 
 ```bash
 # 获取项目状态（机器可读）

package/spec/directory-convention.md

@@ -22,13 +22,15 @@ project-root/
 │   │   │   │   └── 2-page-design/         # Phase 2: 页面设计 + HTML 原型
 │   │   │   └── 3-technical-plan/
 │   │   │       ├── 1-architecture/        # Phase 3: 架构与技术选型
-│   │   │       └── 2-scenario-implementation/  # Phase 3: 场景实现文档
+│   │   │       ├── 2-scenario-implementation/  # Phase 3: 场景实现文档
+│   │   │       └── 3-deployment/          # Phase 3: 部署方案 + 冒烟测试方案
 │   │   ├── api/                           # Phase 3: OpenAPI YAML
 │   │   ├── database/                      # Phase 3: SQL DDL
 │   │   ├── test/                          # Phase 3: 测试用例规格（Markdown）
+│   │   │   └── smoke/                     # Phase 3: 部署后冒烟测试用例（Markdown，可选）
 │   │   ├── scenario/                      # Phase 3: API 编排测试（JSON）
-│   │   ├── implementation/                # Phase 3-4: 代码实现清单（Markdown）
-│   │   └── verify/                        # Phase 3: 测试验收结果（JSONL + 报告）
+│   │   ├── implementation/                # Phase 3: 代码实现清单（Markdown）
+│   │   └── verify/                        # Phase 3: 验收、部署、冒烟结果（JSONL + 报告）
 │   │
 │   └── changes/                # 变更提案工作区
 │       ├── {change-name}/      # 进行中的变更提案
@@ -57,14 +59,16 @@ OpenLogos 方法论的统一入口。包含配置文件、研发资源文档和
 | `prd/1-product-requirements/` | Phase 1: WHY | 需求文档、用户故事、竞品分析 |
 | `prd/2-product-design/1-feature-specs/` | Phase 2: WHAT | 功能规格、信息架构、设计规范 |
 | `prd/2-product-design/2-page-design/` | Phase 2: WHAT | 页面设计文档 + HTML 原型 |
-| `prd/3-technical-plan/1-architecture/` | Phase 3: HOW | 整体架构、技术选型 |
+| `prd/3-technical-plan/1-architecture/` | Phase 3: HOW | 整体架构、技术选型、部署约束 |
 | `prd/3-technical-plan/2-scenario-implementation/` | Phase 3: HOW | 业务场景文档（时序图 + 步骤说明） |
+| `prd/3-technical-plan/3-deployment/` | Phase 3: HOW | 部署方案、环境配置、回滚策略、冒烟测试方案 |
 | `api/` | Phase 3: HOW | OpenAPI YAML 规格文件 |
 | `database/` | Phase 3: HOW | SQL DDL 设计文件 |
 | `test/` | Phase 3: HOW | 单元测试 + 场景测试用例规格（Markdown） |
+| `test/smoke/` | Phase 3: HOW | 部署后冒烟测试用例规格（Markdown，仅需部署的项目） |
 | `scenario/` | Phase 3: HOW | API 编排测试用例（JSON，仅 API 项目） |
-| `implementation/` | Phase 3-4: HOW | 代码实现清单（Markdown），标记代码实现阶段完成 |
-| `verify/` | Phase 3: HOW | 测试运行结果（JSONL）+ 验收报告（Markdown） |
+| `implementation/` | Phase 3: HOW | 代码实现清单（Markdown），标记代码实现阶段完成 |
+| `verify/` | Phase 3: HOW | 测试验收、部署执行、冒烟测试结果（JSONL + 报告） |
 
 ### logos/changes/
 
@@ -104,6 +108,21 @@ OpenLogos 方法论的统一入口。包含配置文件、研发资源文档和
 - 使用 Markdown 格式，包含单元测试和场景测试的用例设计
 - 每个文件对应一个场景编号，覆盖该场景的所有测试层级
 
+### 部署方案文件
+
+- 部署方案默认文件名：`core-01-deployment-plan.md`
+- 命名格式：`<module>-{序号}-deployment-plan.md`
+- 存放位置：`logos/resources/prd/3-technical-plan/3-deployment/`
+- 内容至少包含：目标环境、部署拓扑、环境变量、构建命令、发布命令、数据迁移、回滚策略、部署后检查、冒烟测试方案
+
+### 冒烟测试用例文件
+
+- 冒烟测试用例默认文件名：`core-smoke-test-cases.md`
+- 命名格式：`<module>-smoke-test-cases.md`
+- 存放位置：`logos/resources/test/smoke/`
+- 用例 ID 建议使用 `SMOKE-{module}-{序号}`，例如 `SMOKE-core-01`
+- 冒烟测试只验证部署后的环境可用性，不替代 `UT-*` / `ST-*` 用例
+
 ### 场景文件
 
 - 按场景分文件：`user-auth.json`、`payment-flow.json`
@@ -113,6 +132,9 @@ OpenLogos 方法论的统一入口。包含配置文件、研发资源文档和
 
 - 测试结果：`test-results.jsonl`（JSONL 格式，每行一个用例结果）
 - 验收报告：`acceptance-report.md`（由 `openlogos verify` 自动生成）
+- 部署报告：`deployment-report.md`（部署执行完成后生成）
+- 冒烟结果：`smoke-results.jsonl`（JSONL 格式，每行一个冒烟用例结果）
+- 冒烟报告：`smoke-report.md`（由 `openlogos smoke` 自动生成）
 - 详细格式定义见 [test-results.md](./test-results.md)
 
 ## 可选目录