@miniidealab/openlogos 0.9.23 → 0.9.25

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,13 +156,18 @@ 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,
         "tasks_checked": 2,
         "tasks_total": 5,
-        "delta_count": 1
+        "delta_count": 1,
+        "deployment_required": false,
+        "smoke_required": false,
+        "deployment_reason": "文档-only 提案，不需要发布运行产物",
+        "deployment_decision_source": "proposal",
+        "deployment_decision_conflict": false
       },
       "suggestion": "继续为 add-refund 产出 delta 文件，完成后明确授权执行 openlogos merge add-refund"
     }
@@ -184,16 +210,21 @@ 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 |
 | `modules[].active_change.tasks_checked` | number | 是 | 已勾选任务数 |
 | `modules[].active_change.tasks_total` | number | 是 | 总任务数 |
 | `modules[].active_change.delta_count` | number | 是 | deltas 目录下的文件数 |
+| `modules[].active_change.deployment_required` | boolean \| null | 是 | 活跃提案是否需要部署；无法判断时为 null |
+| `modules[].active_change.smoke_required` | boolean \| null | 是 | 活跃提案是否需要部署后 smoke；无法判断时为 null |
+| `modules[].active_change.deployment_reason` | string \| null | 是 | 来自 `proposal.md` 的部署原因或兼容推断说明 |
+| `modules[].active_change.deployment_decision_source` | string | 是 | `"proposal"` \| `"tasks"` \| `"module-default"` \| `"legacy-fallback"`，表示部署决策来源 |
+| `modules[].active_change.deployment_decision_conflict` | boolean | 是 | `proposal.md` 与 `[deploy]` section 是否冲突 |
 | `modules[].suggestion` | string | 是 | 针对该模块的下一步建议（本地化文本） |
 | `active_proposals` | array | 是 | 活跃变更提案列表 |
 | `active_proposals[].name` | string | 是 | 提案目录名 |
@@ -306,7 +337,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 +411,7 @@ openlogos verify --format json  # JSON 格式
 }
 ```
 
-### 5.1 错误码
+### 6.1 错误码
 
 | 错误码 | 说明 |
 |--------|------|
@@ -332,18 +421,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 +451,7 @@ openlogos module list --format json  # JSON 格式
 }
 ```
 
-### 6.3 字段说明
+### 7.3 字段说明
 
 | 字段 | 类型 | 必填 | 说明 |
 |------|------|------|------|
@@ -375,7 +464,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)
 
 ## 可选目录

package/spec/logos-project.md

@@ -18,6 +18,7 @@
 | `tech_stack` | object | 是 | 技术栈描述 |
 | `scenario_counter` | object | 否 | 全局场景编号计数器（多模块项目必填） |
 | `modules` | array | 否 | 模块注册表（多模块项目必填） |
+| `deployment_gates` | object | 否 | Initial 阶段 launch 前的部署与 smoke 门禁声明 |
 | `scenarios` | array | 否 | 场景清单（单一真相来源，Phase 3-1 前写入） |
 | `resource_index` | array | 是 | 资源索引列表 |
 | `conventions` | array | 否 | 项目约定 |
@@ -41,6 +42,8 @@
 | `hosting` | 部署平台 | "Cloudflare Pages" |
 | `database` | 数据库 | "Supabase (PostgreSQL)" |
 | `auth` | 认证方案 | "Supabase Auth" |
+| `deployment` | 部署形态或发布方式 | "Docker Compose on VPS" |
+| `smoke` | 冒烟测试命令或策略 | "npm run smoke" |
 
 ### external_dependencies
 
@@ -84,6 +87,7 @@
 | `name` | string | 是 | 模块名称（中文或英文均可） |
 | `lifecycle` | string | 是 | 模块生命周期：`initial`（初始开发阶段，关注 phase 推进）或 `launched`（迭代开发阶段，关注变更提案） |
 | `skip_phases` | array | 否 | 声明本模块不需要的阶段，phase 检测时跳过对应目录。由 `architecture-designer` Skill 在技术选型后填写。 |
+| `deployment_required` | boolean | 否 | 是否需要部署执行门禁。软件项目默认 true；纯文档、纯库或明确无需部署的模块可设为 false。 |
 
 `skip_phases` 允许值：
 
@@ -92,6 +96,9 @@
 | `api` | `logos/resources/api/` | 无 HTTP API 的项目（桌面应用、CLI 工具、前端库） |
 | `database` | `logos/resources/database/` | 无数据库的项目（纯计算工具、无状态 CLI） |
 | `scenario` | `logos/resources/scenario/` | 无 API 编排测试的项目（通常与 `api` 同时跳过） |
+| `deployment` | 部署执行与 smoke 门禁 | 纯文档、无需发布运行环境的模块 |
+
+> `deployment` skip 只跳过部署执行与 smoke 门禁，不跳过部署方案设计。Initial 软件项目仍应说明为什么不需要部署。
 
 示例：
 
@@ -111,6 +118,27 @@ modules:
     skip_phases: [api, database, scenario]   # 纯 CLI 工具：无数据库，无 HTTP API
 ```
 
+### deployment_gates
+
+`deployment_gates` 用于声明 Initial 阶段 launch 前的部署门禁要求。字段可由 `deployment-designer` Skill 写入，供 `status` / `launch` 判断。
+
+```yaml
+deployment_gates:
+  core:
+    deployment_required: true
+    smoke_required: true
+    environments:
+      - staging
+```
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `deployment_required` | boolean | 是 | 是否需要部署执行 |
+| `smoke_required` | boolean | 是 | 是否需要部署后冒烟测试 |
+| `environments` | array | 否 | 需要覆盖的部署环境 |
+
+若未声明 `deployment_gates`，软件模块默认需要部署方案；部署执行和 smoke 门禁由模块的 `deployment_required` 与部署方案内容共同决定。
+
 ### resource_index
 
 数组，每个元素描述一个关键资源文件：
@@ -140,7 +168,9 @@ modules:
 |------|-------------|------|
 | Phase 3-1 场景建模 | `logos/resources/prd/3-technical-plan/2-scenario-implementation/<module>-SXX-*.md` | `core-S01-user-register.md` |
 | Phase 3-2 API 设计 | `logos/resources/api/SXX-*.yaml` 或 `SXX-*.yml` | `S01-user-register.yaml` |
-| Phase 3-3a 测试用例 | `logos/resources/test/<module>-SXX-*.md` | `core-S01-test-cases.md` |
+| Phase 3-3 部署方案 | `logos/resources/prd/3-technical-plan/3-deployment/<module>-01-deployment-plan.md` | `core-01-deployment-plan.md` |
+| Phase 3-4a 测试用例 | `logos/resources/test/<module>-SXX-*.md` | `core-S01-test-cases.md` |
+| Phase 3-4a 冒烟测试 | `logos/resources/test/smoke/<module>-smoke-test-cases.md` | `core-smoke-test-cases.md` |
 
 **完成判断规则**：只有 `scenarios` 中每个 `id` 在对应阶段都存在匹配文件，该阶段才视为完成。若 `scenarios` 字段缺失，则降级为旧的"目录有文件即完成"逻辑（向后兼容）。
 
@@ -163,6 +193,8 @@ tech_stack:
   database: "Supabase (PostgreSQL)"
   auth: "Supabase Auth"
   payment: "Paddle"
+  deployment: "Vercel + Supabase"
+  smoke: "npm run smoke"
 
 scenario_counter:
   next_id: 6
@@ -175,6 +207,13 @@ modules:
     name: 支付模块
     lifecycle: initial
 
+deployment_gates:
+  core:
+    deployment_required: true
+    smoke_required: true
+    environments:
+      - staging
+
 external_dependencies:
   - name: "邮件服务"
     provider: "SendGrid"
@@ -203,6 +242,10 @@ resource_index:
     desc: 数据库完整 Schema。涉及表结构、字段设计、RLS 策略时必读。
   - path: logos/resources/scenario/user-auth.json
     desc: 用户认证场景的 API 编排。涉及认证流程验收时必读。
+  - path: logos/resources/prd/3-technical-plan/3-deployment/core-01-deployment-plan.md
+    desc: 核心模块部署方案。涉及部署拓扑、发布命令、回滚策略和 smoke 验证时必读。
+  - path: logos/resources/test/smoke/core-smoke-test-cases.md
+    desc: 核心模块部署后冒烟测试用例。涉及 openlogos smoke 或 launch 前门禁时必读。
 
 conventions:
   - "所有 API 路径以 /api/ 开头"

package/spec/logos.config.schema.json

@@ -53,9 +53,33 @@
           "default": "logos/resources/verify/test-results.jsonl",
           "description": "测试结果 JSONL 文件路径（相对项目根目录）"
         },
-        "test_command": {
+        "pre_run_command": {
           "type": "string",
           "description": "测试命令（可选）。配置后 openlogos verify 会先执行此命令再读取结果"
+        },
+        "test_command": {
+          "type": "string",
+          "description": "旧字段，保留兼容。建议使用 pre_run_command"
+        }
+      }
+    },
+    "smoke": {
+      "type": "object",
+      "description": "部署后冒烟测试配置（可选）。配置 openlogos smoke 的行为。",
+      "properties": {
+        "command": {
+          "type": "string",
+          "description": "冒烟测试命令。openlogos smoke 会先执行此命令再读取结果"
+        },
+        "result_path": {
+          "type": "string",
+          "default": "logos/resources/verify/smoke-results.jsonl",
+          "description": "冒烟测试结果 JSONL 文件路径（相对项目根目录）"
+        },
+        "report_path": {
+          "type": "string",
+          "default": "logos/resources/verify/smoke-report.md",
+          "description": "冒烟测试报告输出路径（相对项目根目录）"
         }
       }
     },
@@ -158,7 +182,13 @@
         }
       },
       "verify": {
-        "result_path": "logos/resources/verify/test-results.jsonl"
+        "result_path": "logos/resources/verify/test-results.jsonl",
+        "pre_run_command": "npm test"
+      },
+      "smoke": {
+        "command": "npm run smoke",
+        "result_path": "logos/resources/verify/smoke-results.jsonl",
+        "report_path": "logos/resources/verify/smoke-report.md"
       }
     }
   ]

package/spec/tasks-spec.md

@@ -18,8 +18,14 @@ tasks.md 使用带标记的 section 组织任务，每个 section 对应提案
 ## [code] 代码实现
 - [ ] 实现 src/xxx 中的业务逻辑
 - [ ] 编写对应测试
+
+## [deploy] 部署任务
+- [ ] 按部署方案部署到 staging
+- [ ] 确认迁移、配置、服务启动和回滚预案
 ```
 
+`[deploy]` section 只能在 `openlogos verify` 通过后执行，且必须由人类明确确认后发起。AI 不得因为 `[deploy]` 任务存在而自动执行部署。
+
 ### Section 标记
 
 Section 标题格式为 `## [<tag>] <描述>`，其中 `<tag>` 为小写英文标识符：
@@ -28,27 +34,66 @@ Section 标题格式为 `## [<tag>] <描述>`，其中 `<tag>` 为小写英文
 |------|------|------|
 | `[delta]` | delta-writing | delta 文档产出任务。该 section 全部勾选 → 可进入 ready-to-merge |
 | `[code]` | coding | 代码实现任务。该 section 全部勾选 → coding 阶段完成 |
+| `[deploy]` | deployment | 部署执行任务。只在 verify PASS 后展示，必须人类确认后执行 |
 
 ### 规则
 
-1. **`[delta]` section 只列 delta 任务**：每条任务必须对应一个 delta 文件的产出，不得混入代码任务
-2. **`[code]` section 只列代码任务**：直接修改 `src/`、`test/` 等源文件的任务，不得混入 delta 任务
-3. **两个 section 均为可选**：
+1. **`[delta]` section 只列 delta 任务**：每条任务必须对应一个 delta 文件的产出，不得混入代码或部署任务
+2. **`[code]` section 只列代码任务**：直接修改 `src/`、`test/` 等源文件的任务，不得混入 delta 或部署任务
+3. **`[deploy]` section 只列部署任务**：部署、迁移、发布、重启、配置检查、回滚准备等任务写入此 section，不得混入代码实现任务
+4. **三个 section 均为可选**：
    - 纯代码提案（无规格变更）：只有 `[code]` section，无 `[delta]` section
    - 纯规格提案（无代码实现）：只有 `[delta]` section，无 `[code]` section
-4. **Section 内可有子标题**：用于分组，不影响 CLI 解析（CLI 只识别 `## [tag]` 级别的 section 边界）
-5. **Section 顺序**：建议 `[delta]` 在前，`[code]` 在后，与流程顺序一致
+   - 不需要部署的提案：不得创建 `[deploy]` section
+5. **部署决策一致性**：`proposal.md` 声明无需部署时不得存在 `[deploy]` section；声明需要部署时必须存在 `[deploy]` section
+6. **Section 内可有子标题**：用于分组，不影响 CLI 解析（CLI 只识别 `## [tag]` 级别的 section 边界）
+7. **Section 顺序**：建议 `[delta]` 在前，`[code]` 居中，`[deploy]` 最后，与流程顺序一致
 
 ## 状态判断规则
 
 CLI 的 `detectProposalStep()` 按以下规则判断各阶段是否完成：
 
-| tasks.md 格式 | `[delta]` section 状态 | 判断结果 |
-|---|---|---|
-| 有 `[delta]` section | 全部勾选 | → `ready-to-merge` |
-| 有 `[delta]` section | 未全部勾选 | → `delta-writing` |
-| 无 `[delta]` section（纯代码提案） | — | → `ready-to-merge`（直接跳过） |
-| 旧格式（无任何 section 标记） | — | → 降级为全局 `allTasksChecked` 判断（向后兼容） |
+| tasks.md / 标记状态 | 判断结果 |
+|---|---|
+| 提案模板未填写完整 | → `writing` |
+| 有 `[delta]` section 且未全部勾选 | → `delta-writing` |
+| 有 `[delta]` section 且全部勾选，且未生成 MERGE_PROMPT | → `ready-to-merge` |
+| 已生成 `MERGE_PROMPT.md` / `MERGE_PROMPT_GENERATED`，但未写入 `SPEC_MERGED` | → `merge-generated` |
+| `SPEC_MERGED` 存在，且 `[code]` section 未全部勾选 | → `coding` |
+| `SPEC_MERGED` 存在，且无 `[code]` section 或 `[code]` 全部勾选 | → `ready-to-verify` |
+| `VERIFY_FAIL` 存在 | → `verify-failed` |
+| `VERIFY_PASS` 存在，提案级无需部署，且无 `[deploy]` section | → `verify-passed` |
+| `VERIFY_PASS` 存在，提案级需要部署，且 `[deploy]` section 存在但 `DEPLOY_DONE` 不存在或 `[deploy]` 未全勾 | → `ready-to-deploy` |
+| `DEPLOY_DONE` 存在、`[deploy]` 全部勾选，且提案级无需 smoke | → `deploy-done` |
+| `DEPLOY_DONE` 存在、`[deploy]` 全部勾选，且提案级需要 smoke，但 `SMOKE_PASS` / `SMOKE_FAIL` 均不存在 | → `ready-to-smoke` |
+| `SMOKE_FAIL` 存在 | → `smoke-failed` |
+| `SMOKE_PASS` 存在 | → `smoke-passed` |
+
+优先级规则：
+
+1. `VERIFY_FAIL` 高于 `VERIFY_PASS`、`DEPLOY_DONE` 和 `SMOKE_PASS`
+2. `SMOKE_FAIL` 高于 `SMOKE_PASS`
+3. 活跃提案的 `proposal.md` 部署决策高于模块级 `deployment_required` / `smoke_required`
+4. 重新运行 `openlogos verify` 且失败时，必须清理过期的 `VERIFY_PASS`、`DEPLOY_DONE`、`SMOKE_PASS`、`SMOKE_FAIL`
+5. 重新部署时，必须清理过期的 `SMOKE_PASS` / `SMOKE_FAIL`
+
+## 部署与冒烟测试设计要求
+
+当提案 `proposal.md` 的部署影响为“需要部署”时：
+
+- `change-writer` 必须创建 `[deploy]` section
+- delta-writing 阶段必须产出部署方案 delta，通常位于 `deltas/prd/3-technical-plan/3-deployment/`
+- 测试设计阶段必须一并设计部署冒烟测试，建议写入 `logos/resources/test/smoke/<module>-smoke-test-cases.md`
+- 部署完成后仅在提案级 `是否需要 smoke：是` 时运行 `openlogos smoke`
+- smoke 通过后才能 archive；无需 smoke 的提案在部署完成后可 archive
+
+当提案 `proposal.md` 的部署影响为“不需要部署”时：
+
+- 不得创建 `[deploy]` section
+- 不产出部署方案 delta，除非本次变更正在修改部署规则本身
+- verify PASS 后直接进入 `verify-passed`，下一步为 `openlogos archive <slug>`
+
+冒烟测试不写入 `[deploy]` section 作为可勾选任务。`[deploy]` 只表示部署执行完成；冒烟测试由 `openlogos smoke` 命令独立管理。
 
 ## 向后兼容
 

package/spec/test-results.md

@@ -125,7 +125,7 @@ reporter 在写入前应确保 `logos/resources/verify/` 目录存在（`mkdir -
 
 ### 分批闭环执行约定（大任务）
 
-当 Phase 3 Step 4 采用“分批生成”时，reporter 仍按一次完整测试运行的口径输出结果，并遵循以下约束：
+当 Phase 3 Step 5 采用“分批生成”时，reporter 仍按一次完整测试运行的口径输出结果，并遵循以下约束：
 
 1. **用例 ID 对齐**：每一批开始前先声明本批覆盖的 `UT-xx` / `ST-xx`，测试代码中写入的 `id` 必须与 `logos/resources/test/*.md` 完全一致
 2. **清空策略一致**：无论是否分批，执行“本批完整测试”前都必须先清空结果文件，避免混入旧批次数据
@@ -134,7 +134,7 @@ reporter 在写入前应确保 `logos/resources/verify/` 目录存在（`mkdir -
 
 ## AI 生成 reporter 代码模板
 
-以下是各语言的 reporter 参考实现。AI 在 Phase 3 Step 4（代码生成，由 `code-implementor` Skill 驱动）时，应根据项目的 `tech_stack` 选择对应语言的模板，嵌入到测试代码中。
+以下是各语言的 reporter 参考实现。AI 在 Phase 3 Step 5（代码生成，由 `code-implementor` Skill 驱动）时，应根据项目的 `tech_stack` 选择对应语言的模板，嵌入到测试代码中。
 
 ### 推荐：共享 reporter 文件模式