Product Lifecycle Orchestrator v2.3

一句话：Product Lifecycle Orchestrator 是一个产品开发生命周期编排 skill。用户直接说需求，AI 先做意图识别，再由 ./orchestrator 手动 CLI 或内置流程推进后续 Phase。

v2.3 新增：PRD/UED/ARCH/Test human docs 之后生成 .lifecycle/specs/ 下的 Product/UED/Tech/Test Specs，并生成 lifecycle_graph.json 支撑影响分析和测试覆盖。resume 现在继承 checkpoint 原始 intent；Phase 12 先暂停等待开发，再在 resume 时执行 gate。

核心能力：

当前入口

Product Lifecycle Orchestrator 的 skill 名称是 product-lifecycle-orchestrator，手动 CLI 入口是 ./orchestrator。

• ./orchestrator run --user-input "<输入>" — 启动编排，默认自动识别 intent
• ./orchestrator run --intent <intent> --user-input "<输入>" — 强制指定 intent
• ./orchestrator run --from-phase <phase-id> — 从指定阶段开始
• ./orchestrator resume --from-phase <phase-id> [--user-input "<输入>"] — 恢复执行（可选更新用户输入上下文）
• ./orchestrator status — 查看状态
• ./orchestrator cancel — 取消流程
• ./orchestrator rollback --list — 列出所有回滚点
• ./orchestrator rollback --rollback-point-id <id> — 回滚到指定点

快速开始

Phase 0 — 意图识别（必须，每次调用的第一步）

模型行为：

1. 读取用户输入
2. 默认调用 ./orchestrator run --user-input "<用户输入>"，由 orchestrator 自动识别 intent
3. Orchestrator 自动执行 Phase 序列
4. 遇到暂停节点时，orchestrator 会通知模型

意图类型：

示例：

# 用户: "我想做一个产品"
./orchestrator run --user-input "我想做一个产品"

# 用户: "需求变了，要加支付功能"
./orchestrator run --user-input "需求变了，要加支付功能"

# 用户: "修了个 bug"
./orchestrator run --user-input "修了个 bug"

Phase 1-12 — 自动执行

Orchestrator 会自动执行以下 Phase 序列，模型不需要手动调用每个命令：

交互节点处理

当 orchestrator 遇到交互节点时，会暂停并写入 .lifecycle/notification.json：

{
  "type": "pause_for_user",
  "phase_id": "phase-3-draft-prd",
  "phase_name": "AI 协作 PRD 起草",
  "message": "Phase AI 协作 PRD 起草 paused",
  "detail": "等待用户审核 PRD 草案，补充 [❓待确认] 标注处",
  "timestamp": "2026-04-16T12:34:56Z",
  "actions": [
    "完成用户交互后，运行: ./orchestrator resume --from-phase phase-3-draft-prd",
    "取消流程: ./orchestrator cancel"
  ]
}

模型行为：

1. Orchestrator 打印通知到 stdout（模型直接可见）
2. 预期交互暂停返回 exit code 0，模型通过 checkpoint status: paused 和 .lifecycle/notification.json 判断仍需继续处理
3. 模型读取通知，执行交互任务（如生成 PRD 草案、回答访谈问题）
4. 模型调用 ./orchestrator resume --from-phase <phase-id>
5. Orchestrator 继续执行后续 Phase

失败处理

当验证失败时，orchestrator 会暂停并通知模型，通知文件包含 validator 的完整诊断信息：

{
  "type": "validation_failed",
  "phase_id": "phase-4-product-spec",
  "phase_name": "Product Spec 生成与验证",
  "message": "Phase Product Spec 生成与验证 failed",
  "detail": "Document validation failed",
  "score": 42,
  "threshold": 70,
  "issues": [
    {"field": "产品愿景", "message": "缺少「产品愿景」章节", "severity": "error"},
    {"field": "非功能需求", "message": "非功能需求缺少具体量化指标", "severity": "warning"},
    {"field": "范围边界", "message": "范围边界章节缺少明确的 In/Out Scope 说明", "severity": "warning"}
  ],
  "suggestions": [
    "非功能需求应包含可量化指标，如「API 响应时间 < 200ms」",
    "范围边界应明确列出「本阶段包含」和「本阶段不包含」的内容"
  ],
  "timestamp": "2026-04-16T12:45:00Z",
  "actions": [
    "修复问题后，运行: ./orchestrator resume --from-phase phase-4-product-spec"
  ]
}

模型行为：

1. 读取 .lifecycle/notification.json，获取 score、issues、suggestions
2. 针对每条 severity: "error" 的 issue 优先修复（缺失章节）
3. 针对 severity: "warning" 的 issue 补充内容深度（量化指标、步骤数量等）
4. 参考 suggestions 了解具体改进方向
5. 修复完成后调用 ./orchestrator resume --from-phase <phase-id>
6. Orchestrator 重试该 Phase

意图解析

当用户输入匹配到多个意图时，orchestrator 仅使用优先级最高的单一意图执行。例如 "修了个 bug，顺便想调整下需求" 会匹配 bug-fix 和 prd-change，但只执行优先级更高的 bug-fix 流程。

注意：复合意图（同时处理多个 intent）暂未实现。如需处理多种变更，请分别执行。

命令速查

# 启动编排
./orchestrator run --intent <intent> --user-input "<输入>"

# 恢复执行
./orchestrator resume --from-phase <phase-id> [--user-input "<输入>"]

# 查看状态
./orchestrator status

# 取消流程
./orchestrator cancel

# 回滚管理
./orchestrator rollback --list
./orchestrator rollback --rollback-point-id <id>

工作流示例

示例 1：新产品流程

# 1. 用户: "我想做一个产品"
./orchestrator run --intent new-product --user-input "我想做一个产品"

# 2. Orchestrator 自动执行 Phase 1 的 analyze_solution 命令
#    扫描项目代码、生成方案、写入 .lifecycle/solution.json
#    然后暂停在 Phase 1（交互节点）

# 3. 用户选择方案

# 4. 用户选择方案
#    模型更新 .lifecycle/solution.json

# 5. 模型调用 resume
./orchestrator resume --from-phase phase-1-analyze-solution

# 6. Orchestrator 执行 Phase 2 (自动)
#    创建文档结构...

# 7. Orchestrator 暂停在 Phase 3
#    通知: "等待用户审核 PRD 草案"

# 8. 模型生成 PRD 草案
#    写入 Docs/product/PRD.md

# 9. 模型调用 resume
./orchestrator resume --from-phase phase-3-draft-prd

# 10. Orchestrator 执行 Phase 4 (自动)
#     验证 PRD...

# 11. Orchestrator 暂停在 Phase 5
#     通知: "等待用户审核 UED 草案"

# 12. 用户审核 UED，模型写入 Docs/product/UED.md

# 13. 模型调用 resume
./orchestrator resume --from-phase phase-5-draft-ued

# ... 继续执行 Phase 6-12

示例 2：PRD 变更流程

前提：项目已完成初始化（至少跑过一次 new-product 流程，phase-2-init 已完成）。

# 1. 用户: "需求变了，要加支付功能"
./orchestrator run --intent prd-change --user-input "需求变了，要加支付功能"

# 2. Orchestrator 先执行 Phase 1 Impact Report，再暂停在 Phase 3（交互）
#    通知: "等待用户修改 PRD"

# 3. 用户修改 PRD
#    更新 Docs/product/PRD.md

# 4. 模型调用 resume
./orchestrator resume --from-phase phase-3-draft-prd

# 5. Orchestrator 自动执行 Phase 4 → 5 → 6 → 7 → 8 → 9 → 10 → 11 → 12
#    Phase 4: 验证 PRD 并生成 Product Spec
#    Phase 5-8: 更新 UED/Tech 文档与 Specs
#    Phase 9-10: 更新 Lifecycle Graph、Test Spec 和测试大纲
#    Phase 11-12: 更新迭代计划并进入执行 gate

附录 — PHASES 定义

完整的 Phase 定义见 scripts/core/phases.py，包含：

• Phase ID、名称、描述
• 是否自动执行（auto=True/False）
• 前置步骤依赖
• 对应的命令
• 产物验证规则
• 失败处理策略
• 交互节点描述

技术细节

Checkpoint 文件格式

.lifecycle/checkpoint.json：

{
  "version": "2.3",
  "project_name": "xxx",
  "created_at": "2026-04-16T12:00:00Z",
  "updated_at": "2026-04-16T12:34:56Z",
  "current_phase": "phase-4-product-spec",
  "status": "in_progress",
  "completed_phases": ["phase-0-intent", "phase-1-analyze-solution", "phase-2-init"],
  "phase_data": {
    "phase-4-product-spec": {
      "started_at": "...",
      "completed_at": "...",
      "score": 85
    }
  },
  "intent": "new-product",
  "user_input": "我想做一个...",
  "metadata": {}
}

通知文件格式

.lifecycle/notification.json：

{
  "type": "pause_for_user" | "validation_failed" | "dod_failed" | "error",
  "phase_