diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md
index 0ba1c9f..14851f1 100644
--- a/.claude/CLAUDE.md
+++ b/.claude/CLAUDE.md
@@ -35,7 +35,7 @@ devpace 分为两个独立层次，**产品层不得依赖开发层**：
## 开发守则
-1. **概念模型始终完整**：BR→PF→CR 价值链从第一天就存在，不可省略任何环节。内容可为空但结构必须完整
+1. **概念模型始终完整**：Opportunity→Epic→BR→PF→CR 价值链从第一天就存在，不可省略任何环节。内容可为空但结构必须完整
2. **Markdown 是唯一格式**：消费者是 LLM + 人类，不使用 YAML/JSON 作为状态文件格式
3. **Schema 是契约**：`knowledge/_schema/` 中的格式定义是强约束，Skill 输出必须符合 Schema
4. **plugin.json 必须与文件系统同步**：新增/删除 Skill 后立即更新 `.claude-plugin/plugin.json`
@@ -60,14 +60,13 @@ devpace 分为两个独立层次，**产品层不得依赖开发层**：
| 质量门系统 | `docs/design/design.md §6` | Gate 1/2/3 定义 |
| 变更管理 | `docs/design/design.md §7` | 设计原则、四种场景、操作流程 |
| BizDevOps 理论 | `knowledge/theory.md` | 方法论参考（/pace-theory 运行时数据源） |
-| 需求场景 S1-S12 | `docs/planning/requirements.md` | 验收标准 |
-| 功能需求 F1-F3、非功能需求 NF1-NF10 | `docs/planning/requirements.md` | 特性规格与质量约束 |
+| 需求场景 S1-S42 | `docs/planning/requirements.md` | 验收标准 |
+| 功能需求 F1-F12、非功能需求 NF1-NF11 | `docs/planning/requirements.md` | 特性规格与质量约束 |
| 战略规划 | `docs/planning/roadmap.md` | 阶段、里程碑、任务定义 |
| 操作跟踪 | `docs/planning/progress.md` | 当前任务状态、会话历史、变更记录 |
| 运行时行为规则 | `rules/devpace-rules.md` | 插件加载后 Claude 的行为 |
| 文件格式契约 | `knowledge/_schema/*.md` | state/project/CR 的字段定义 |
| 度量指标定义 | `knowledge/metrics.md` | 指标名称、计算方式、用途 |
-| 组件开发基础原则（新手首读） | `knowledge/dev-principles.md` | 跨组件通用的 10 条第一性原理 |
### 开发规范索引（.claude/rules/，自动加载）
diff --git a/README.md b/README.md
index 1964d9c..8e36728 100644
--- a/README.md
+++ b/README.md
@@ -34,11 +34,10 @@ Next session, Claude reports: "Last time we stopped at auth module, continue?"
## Full Development Lifecycle
```
- Goal Features Code Changes Quality Ship
-You define ──→ Plan together ──→ Claude codes ──→ Auto + You ──→ Optional auto
- │ │ │ │
- pace-plan pace-dev pace-review pace-release
- pace-change pace-feedback
+Opportunity ──→ Epic ──→ Requirements ──→ Features ──→ Code Changes ──→ Quality ──→ Ship
+ │ │ │ │ │ │ │
+ pace-biz pace-biz pace-biz pace-plan pace-dev pace-review pace-release
+ pace-change pace-feedback
```
Requirements can change anytime — `/pace-change` auto-analyzes impact, adjusts the plan, and waits for your confirmation.
@@ -83,38 +82,23 @@ After installing, type `/pace-` in Claude Code. If devpace is loaded, you'll see
## Commands
-### Daily Use
+Most of the time you don't need commands — saying "help me implement X" equals `/pace-dev`, "where are we" equals `/pace-status`.
+
+### Start Here (5 commands cover 90% of daily work)
| Command | Purpose |
|---------|---------|
-| `/pace-init` | First-time setup (once, supports `--from PRD` for auto feature tree) |
-| `/pace-dev` | Start coding |
-| `/pace-status` | Check progress |
+| `/pace-init` | First-time setup (once) |
+| `/pace-dev` | Start coding — or just say "help me implement X" |
+| `/pace-status` | Check progress — or say "where are we" |
| `/pace-review` | Approve changes |
| `/pace-next` | Not sure what's next? Get AI recommendations |
-### When Requirements Change or a Cycle Completes
-
-| Command | When to use |
-|---------|------------|
-| `/pace-change` | Add requirements, pause, change scope, reprioritize |
-| `/pace-plan` | Cycle done, plan the next one |
-| `/pace-retro` | Review how things went |
+### More Commands
-### Specialized Features (Optional)
+As your project grows, devpace offers change management, iteration planning, business alignment, release orchestration, and more. See [User Guide](docs/user-guide.md) for all 19 commands.
-| Command | Scenario |
-|---------|----------|
-| `/pace-test` | Requirements-traceable test management |
-| `/pace-guard` | Risk fabric: Pre-flight scan + Runtime monitoring + Trend analysis + Graduated response |
-| `/pace-release` | Release orchestration: Changelog + Version bump + Git Tag + GitHub Release |
-| `/pace-sync` | External tool bridge: sync task state ↔ GitHub Issues (labels + comments) |
-| `/pace-role` | Switch perspective (PM / Tester / Ops / etc.) |
-| `/pace-theory` | Learn the methodology behind devpace |
-| `/pace-feedback` | Collect post-launch feedback |
-| `/pace-trace` | View full reasoning trace of AI decisions |
-
-Most of the time you don't need commands — saying "help me implement X" equals `/pace-dev`, "where are we" equals `/pace-status`.
+Quick reference: `/pace-change` (requirements changed) · `/pace-plan` (plan iterations) · `/pace-retro` (review metrics) · `/pace-biz` (business planning) · `/pace-release` (ship it)
## Core Capabilities
@@ -124,6 +108,8 @@ Most of the time you don't need commands — saying "help me implement X" equals
|-----------|-------------|
| Requirement changes | Add features, pause, change scope — auto impact analysis, orderly adjustment, Claude won't change the plan unilaterally |
| Complexity awareness | Auto-assesses task complexity, small changes fast-track, large changes full process, complexity drift auto-detected |
+| Technical debt management | `tech-debt` CR type + iteration capacity reservation + trend tracking |
+| Architecture decisions | `/pace-trace arch` manages cross-CR Architecture Decision Records (ADR) |
### Quality & Traceability
@@ -132,6 +118,7 @@ Most of the time you don't need commands — saying "help me implement X" equals
| Quality gates | Code quality + requirement consistency auto-check + adversarial review, human approval cannot be skipped |
| Goal traceability | From business goals to code changes, always traceable |
| Test verification | Requirements-driven — strategy generation, coverage analysis, AI acceptance verification, change impact regression |
+| Semantic drift detection | Continuous monitoring of code-requirement alignment during development, Review includes semantic consistency score |
### Development Rhythm
@@ -142,7 +129,8 @@ Most of the time you don't need commands — saying "help me implement X" equals
| Progressive autonomy | Assisted / Standard / Autonomous — more guidance for new users, less for experienced ones |
| DORA proxy metrics | Deploy frequency / Lead time / Failure rate / MTTR proxy values, Elite~Low benchmarks + trend comparison |
| CI/CD awareness | Auto-detects CI tool type, Gate 4 auto-queries CI status, zero config |
-| Risk fabric | Pre-flight 5-dimension risk scan + Runtime monitoring + Graduated autonomous response (High requires human confirmation) |
+| Risk fabric | OWASP-aware security scanning + Pre-flight 5-dimension risk scan + Runtime monitoring + Graduated autonomous response (High requires human confirmation) |
+| Delivery prediction | AI-powered iteration delivery probability forecasting, bottleneck identification, and risk early warning |
| Cross-project insights | High-confidence insights exportable/importable to other projects, reducing redundant learning |
## Workflow
diff --git a/README_zh.md b/README_zh.md
index da554bd..38e2cf2 100644
--- a/README_zh.md
+++ b/README_zh.md
@@ -34,11 +34,10 @@
## 覆盖完整研发生命周期
```
- 目标 功能 代码变更 质量 发布
-你来定义 ──→ 一起规划 ──→ Claude 写代码 ──→ 自动+你审批 ──→ 可选自动
- │ │ │ │
- pace-plan pace-dev pace-review pace-release
- pace-change pace-feedback
+机会 ──→ 专题 ──→ 需求 ──→ 功能 ──→ 代码变更 ──→ 质量 ──→ 发布
+ │ │ │ │ │ │ │
+pace-biz pace-biz pace-biz pace-plan pace-dev pace-review pace-release
+ pace-change pace-feedback
```
需求随时可变——`/pace-change` 自动分析影响、调整计划、等你确认。
@@ -83,38 +82,23 @@ claude --plugin-dir /path/to/devpace
## 命令
-### 日常使用
+大多数时候不需要敲命令——说"帮我实现 X"等于 `/pace-dev`，说"做到哪了"等于 `/pace-status`。
+
+### 从这里开始（5 个命令覆盖 90% 日常工作）
| 命令 | 作用 |
|------|------|
-| `/pace-init` | 首次初始化（只需一次，支持 `--from PRD` 自动分解功能树） |
-| `/pace-dev` | 开始写代码 |
-| `/pace-status` | 看进度 |
-| `/pace-review` | 审批变更 |
-| `/pace-next` | 不确定做什么时，看 AI 推荐的下一步 |
-
-### 需求变了或一轮做完时
+| `/pace-init` | 首次初始化（只需一次） |
+| `/pace-dev` | 开始写代码——或者直接说"帮我实现 X" |
+| `/pace-status` | 看进度——或者说"做到哪了" |
+| `/pace-review` | 审批变更 |
+| `/pace-next` | 不确定做什么时，看 AI 推荐的下一步 |
-| 命令 | 什么时候用 |
-|------|----------|
-| `/pace-change` | 加需求、暂停、改范围、调优先级 |
-| `/pace-plan` | 一轮做完了，规划下一轮 |
-| `/pace-retro` | 复盘做得怎么样 |
+### 更多命令
-### 专项功能（可选，不使用时不受影响）
+随着项目发展，devpace 提供变更管理、迭代规划、业务对齐、发布编排等更多能力。查看[用户指南](docs/user-guide_zh.md)了解全部 19 个命令。
-| 命令 | 场景 |
-|------|------|
-| `/pace-test` | 需求追溯驱动的测试管理 |
-| `/pace-guard` | 风险织网：Pre-flight 扫描 + Runtime 监控 + 趋势分析 + 分级响应 |
-| `/pace-release` | 发布编排：Changelog + 版本 bump + Git Tag + GitHub Release |
-| `/pace-sync` | 外部工具桥接：任务状态 ↔ GitHub Issues 同步（标签 + 评论） |
-| `/pace-role` | 切换视角（产品经理/测试/运维等） |
-| `/pace-theory` | 了解背后的方法论 |
-| `/pace-feedback` | 收集上线后反馈 |
-| `/pace-trace` | 查看 AI 决策的完整推理轨迹 |
-
-大多数时候不需要敲命令——说"帮我实现 X"等于 `/pace-dev`，说"做到哪了"等于 `/pace-status`。
+常用：`/pace-change`（需求变了）· `/pace-plan`（规划迭代）· `/pace-retro`（复盘度量）· `/pace-biz`（业务规划）· `/pace-release`（发布）
## 核心能力
@@ -124,6 +108,8 @@ claude --plugin-dir /path/to/devpace
|------|------|
| 需求变更 | 加功能、暂停、改范围——自动分析影响，有序调整，Claude 不擅自改计划 |
| 复杂度感知 | 自动评估任务复杂度，小变更快速通过、大变更完整流程，复杂度漂移自动检测 |
+| 技术债务管理 | `tech-debt` CR 类型 + 迭代容量预留 + 趋势追踪 |
+| 架构决策记录 | `/pace-trace arch` 管理跨 CR 的 ADR（Architecture Decision Record） |
### 质量与追溯
@@ -132,6 +118,7 @@ claude --plugin-dir /path/to/devpace
| 质量门禁 | 代码质量 + 需求一致性自动检查 + 对抗审查，人类审批不可跳过 |
| 目标追溯 | 从业务目标到代码变更，始终可追溯 |
| 测试验证 | 需求追溯驱动——策略生成、覆盖率分析、AI 验收验证、变更影响回归 |
+| 语义漂移检测 | 开发过程中持续监控代码与需求的对齐度，Review 包含语义一致性评分 |
### 研发节奏
@@ -142,7 +129,8 @@ claude --plugin-dir /path/to/devpace
| 渐进自主性 | 辅助/标准/自主三级——新用户多引导，熟练用户少干预 |
| DORA 代理度量 | 部署频率/前置时间/失败率/MTTR 代理值，Elite~Low 基准分级 + 趋势对比 |
| CI/CD 感知 | 自动检测 CI 工具类型，Gate 4 自动查询 CI 状态，零配置即用 |
-| 风险织网 | Pre-flight 5 维风险扫描 + Runtime 实时监控 + 分级自主响应（High 必须人类确认） |
+| 风险织网 | OWASP 安全扫描 + Pre-flight 5 维风险扫描 + Runtime 实时监控 + 分级自主响应（High 必须人类确认） |
+| 交付预测 | AI 预测迭代交付概率、识别瓶颈、发出风险预警 |
| 跨项目经验 | 高置信度经验可导出/导入到其他项目，减少重复学习 |
## 工作流程
diff --git a/docs/design/design.md b/docs/design/design.md
index 92a9f2f..86aa89e 100644
--- a/docs/design/design.md
+++ b/docs/design/design.md
@@ -32,9 +32,9 @@ Phase 0 ─────→ Phase 1 ─────→ Phase 2A/2B ────
│ deployed → rolled_back（回滚路径） │
└────────────────────────────────────────────────────┘
-横切：/pace-role（视角切换）· /pace-theory（理论参考）· /pace-status（任意阶段查询）· /pace-trace（决策轨迹）· /pace-guard（风险管理）
+横切：/pace-role（视角切换）· /pace-theory（理论参考）· /pace-status（任意阶段查询）· /pace-trace（决策轨迹）· /pace-guard（风险管理）· /pace-next（全局导航）
-价值交付链路：OBJ → BR → PF → CR → merged（→ released，可选）
+价值交付链路：Opportunity → Epic → BR → PF → CR → merged（→ released，可选）（OBJ 关联 Epic）
溯源标记： / — 区分用户输入与 Claude 推断（HTML 注释，日常不可见）
四个闭环：业务闭环(人类主导) → 产品闭环(人机协作) → 技术闭环(Claude 自治) → 运维闭环(人机协作，可选)
状态机：created → developing → verifying → in_review → approved → merged → released（可选）（任意⇄paused）
@@ -133,26 +133,31 @@ vision.md 定义了三层护城河，设计优先级据此排列：
| 概念 | BizDevOps 定义 | 在本 Plugin 中的体现 |
|------|----------|-------------------|
-| **作业对象** | 价值交付链路上的基本单元 | BR（业务需求）→ PF（产品功能）→ CR（变更请求） |
+| **作业对象** | 价值交付链路上的基本单元 | Opportunity（业务机会）→ Epic（专题）→ BR（业务需求）→ PF（产品功能）→ CR（变更请求） |
| **作业空间** | 角色协作的功能区域 | 当前简化为单项目单开发者，未来扩展多项目时启用 |
| **作业规则** | 流程、规范、约束 | knowledge/_schema/ 中的 workflow.md（状态机）+ checks.md（质量检查），项目可在 .devpace/rules/ 中覆盖 |
### 价值交付链路
-devpace 使用四类作业对象构成价值交付链路：
+devpace 使用五类作业对象构成价值交付链路：
```
-OBJ (业务目标) →1:N→ BR (业务需求) →1:N→ PF (产品功能) →1:N→ CR (变更请求)
- 人类定义 人类定义 人机协作 Claude 创建
+Opportunity (业务机会) →评估→ Epic (专题) →1:N→ BR (业务需求) →1:N→ PF (产品功能) →1:N→ CR (变更请求)
+ Claude 捕获 人机协作 人机协作 人机协作 Claude 创建
+ ↑
+ OBJ (业务目标)
+ 人类定义
```
-**双向追溯**：正向确保技术工作锚定业务价值，反向确保技术工作可追溯到业务目的。**溯源标记**增加第三维度——区分用户输入与 Claude 推断的内容，支持跨会话信任和纠正检测。
+**双向追溯**：正向确保技术工作锚定业务价值，反向确保技术工作可追溯到业务目的。**溯源标记**增加第三维度——区分用户输入与 Claude 推断的内容，支持跨会话信任和纠正检测。**Epic 层增加了业务规划域的可追溯性——从 CR 可以追溯到 Epic 和 Opportunity，验证每一行代码都有业务来源。**
| 实体 | 存储位置 | 创建者 | 状态管理 |
|------|---------|--------|---------|
| OBJ | project.md 业务目标 section | 人类 | MoS checkbox |
-| BR | project.md 业务目标 section | 人类 | 功能完成度隐含 |
-| PF | project.md 价值功能树 | 人机协作 | emoji 标记（🔄✅⏳⏸️） |
+| Opportunity | opportunities.md | Claude 捕获/人类 | 评估中→已采纳/已搁置/已拒绝 |
+| Epic | epics/EPIC-xxx.md（始终独立） | 人机协作 | 规划中→进行中→已完成→已搁置 |
+| BR | project.md 树视图（溢出后 requirements/BR-xxx.md） | 人机协作 | 基于 PF 完成度自动计算 |
+| PF | project.md 价值功能树（溢出后 features/PF-xxx.md） | 人机协作 | emoji 标记 |
| CR | backlog/CR-xxx.md | Claude 自动 | 7 状态状态机 |
**扩展实体**（可选，渐进启用）：
@@ -195,7 +200,9 @@ OBJ (业务目标) →1:N→ BR (业务需求) →1:N→ PF (产品功能)
| 概念 | 初始形态（轻量） | 丰富后形态 | 存储位置演变 |
|------|-----------------|-----------|------------|
-| BR（业务需求） | state.md 一行："目标：实现用户认证系统" | 带 MoS 指标、验收标准的完整描述 | state.md → project.md 业务目标 section |
+| Opportunity（业务机会） | 一句话描述 + 来源 | 评估结论 + 去向（Epic） + 详细来源 | 始终在 opportunities.md |
+| Epic（专题） | 标题 + OBJ 关联 + 背景 | 完整 MoS + BR 列表 + 完成度 + 时间框架 | 始终在 epics/EPIC-xxx.md |
+| BR（业务需求） | project.md 一行（标题 + 标签） | 带业务上下文、成功标准、PF 列表 | project.md 内联 → **requirements/BR-xxx.md**（溢出） |
| PF（产品功能） | CR 文件的 `功能:` 字段 + state.md 功能概览行 | 功能分组视图 + 用户故事 + 验收标准 + 边界定义、依赖关系、完成进度 | CR + state.md → project.md 功能视图 + 功能规格 → **features/PF-xxx.md**（溢出） |
| CR（变更请求） | backlog/CR-*.md 基础信息 + 意图（用户原话） | 意图完整填充、质量检查记录、review 历史、关联信息 | 始终在 backlog/CR-*.md |
@@ -210,7 +217,7 @@ OBJ (业务目标) →1:N→ BR (业务需求) →1:N→ PF (产品功能)
随迭代丰富为：
```
-业务目标 + MoS（project.md）→ 功能树（project.md）→ PF 详情（features/ 溢出后）→ CR（backlog/）→ 代码（Git）
+业务机会（opportunities.md）→ 专题 + MoS（epics/）→ 业务目标 + MoS（project.md）→ 功能树（project.md）→ PF 详情（features/ 溢出后）→ BR 详情（requirements/ 溢出后）→ CR（backlog/）→ 代码（Git）
```
**文件结构：/pace-init 创建完整目录，内容从最小开始**：
@@ -220,6 +227,9 @@ OBJ (业务目标) →1:N→ BR (业务需求) →1:N→ PF (产品功能)
.devpace/
├── state.md # 含业务目标行 + 功能概览（5-8 行）
├── project.md # 初始仅含基础业务目标和功能列表
+├── opportunities.md # 业务机会看板（/pace-biz 时填充，可选）
+├── epics/ # Epic 专题文件（/pace-biz 时填充，可选）
+├── requirements/ # BR 溢出文件（信息量增长后自动溢出，可选）
├── backlog/ # CR 文件随推进创建
├── iterations/ # 目录预创建，有迭代节奏需求时填充内容
├── rules/ # 目录预创建，项目特有质量规则时填充
@@ -612,7 +622,7 @@ checks.md 支持两种检查类型：**命令检查**（bash 执行）和**意
| 文件 | 职责 | 消费者 |
|------|------|--------|
-| project.md | 业务全景（OBJ→BR→PF→CR 价值树） | /pace-plan, /pace-change, /pace-status |
+| project.md | 业务全景（OBJ→Epic→BR→PF→CR 价值树） | /pace-plan, /pace-change, /pace-status |
| state.md | 恢复锚点（当前状态 + 下一步） | 会话开始, §6 中断恢复 |
| context.md | 技术约定（编码规范、项目约定、架构约束） | 推进模式, /pace-dev |
@@ -845,18 +855,22 @@ target-project/.devpace/
| /pace-trace | 任意时刻，§5 深入层 | 决策轨迹查询（只读） | ✅ | ✅ 已实现 |
| pace-pulse | 推进模式中，§10 | 节奏心跳检查（Claude 自动） | ❌ | ✅ 已实现 |
| /pace-guard | Phase 0-4 跨阶段，§18 | 风险管理：scan/monitor/trends/report/resolve | ✅ | ✅ 已实现 |
+| /pace-next | 任意时刻，§19 | 全局导航：跨域信号推荐下一步 | ✅ | ✅ 已实现 |
+| /pace-test | Phase 2B，§20 | 测试策略：验收/回归/影响分析 | ✅ | ✅ 已实现 |
+| /pace-sync | 任意时刻，§21 | 外部工具同步（GitHub/Linear/Jira） | ✅ | ✅ 已实现 |
+| /pace-biz | Phase 0+，§22 | 业务规划：discover/import/infer/epic/decompose/align/view | ✅ | ✅ 已实现 |
| pace-learn | merged 后，§11 | 即时知识积累（Claude 自动） | ❌ | ✅ 已实现 |
**Agents**（角色分离）：
| Agent | 路由 Skill | 视角 | 工具权限 |
|-------|-----------|------|---------|
-| pace-pm | /pace-plan | 产品经理 | Read, Glob, Grep, AskUserQuestion |
-| pace-engineer | /pace-dev | 工程师 | Read, Write, Edit, Bash, Glob, Grep |
+| pace-pm | /pace-plan, /pace-change, /pace-biz | 产品经理 | Read, Glob, Grep, AskUserQuestion |
+| pace-engineer | /pace-dev, /pace-test | 工程师 | Read, Write, Edit, Bash, Glob, Grep |
| pace-analyst | /pace-retro | 分析师 | Read, Glob, Grep, Bash |
**说明**：
-- 13 个用户 Skill + 2 个内部 Skill + 3 个 Agent = 完整角色分离体系
+- 18 个用户可调 Skill（含 3 个仅手动触发）+ 1 个内部 Skill（pace-pulse）+ 3 个 Agent = 完整角色分离体系
- Skill→Agent 路由通过 `context: fork` + `agent` 字段实现
- Phase 1（会话开始）和 Phase 5（会话结束）不对应 Skill，由 rules 自动驱动
- §10-§12 实现 Claude 主动管理行为，§13-§16 实现角色意识与生命周期扩展
@@ -868,7 +882,7 @@ target-project/.devpace/
| 关系 | 说明 | 实现载体 |
|------|------|---------|
-| 交付链 → 追溯树 | OBJ→BR→PF→CR 分解关系的可视化 | project.md 价值功能树 |
+| 交付链 → 追溯树 | OBJ→Epic→BR→PF→CR 分解关系的可视化 | project.md 价值功能树 |
| 状态机 → 质量检查 | 状态转换由质量检查把关 | Gate 1/2/3 |
| 状态机 → 变更管理 | paused 状态是变更管理的核心机制 | CR 的 paused 状态 |
| 状态机 → Release | merged→released 由 Release 关闭触发 | §14 + /pace-release |
diff --git a/docs/design/skill-dependencies.md b/docs/design/skill-dependencies.md
index 7bc3d4b..10408e3 100644
--- a/docs/design/skill-dependencies.md
+++ b/docs/design/skill-dependencies.md
@@ -59,40 +59,39 @@
| 触发机制 | `post-cr-update.mjs:43` 输出 `pace-learn knowledge extraction` 步骤 |
| 位置 | `hooks/post-cr-update.mjs:42-43` |
-### pace-dev → pace-guard（L/XL 预检 + procedures 内联）
+### pace-dev → pace-guard（L/XL 预检 + Schema 契约）
| 属性 | 值 |
|------|-----|
-| 耦合类型 | **代码内联**（直接引用 procedures 文件路径）+ 数据格式依赖 |
-| 风险等级 | **高** |
-| 位置 | `skills/pace-dev/dev-procedures-intent.md:206`（"扫描规则详见 `skills/pace-guard/guard-procedures-scan.md`"） |
-| 描述 | pace-dev 在意图检查点直接读取 pace-guard 的内部 procedures 文件执行 L/XL CR 风险扫描 |
-| 影响 | 重命名/重构 `guard-procedures-scan.md` 会直接破坏 pace-dev |
+| 耦合类型 | **Schema 契约**（通过 risk-format.md 接口）+ 命令委托 |
+| 风险等级 | **低**（已解耦） |
+| 位置 | `skills/pace-dev/dev-procedures-intent.md:206`（引用 `knowledge/_schema/risk-format.md` 风险预评估章节，或委托 `/pace-guard scan`） |
+| 描述 | pace-dev 通过共享 Schema 定义输出格式，不再直接引用 pace-guard 内部 procedures 文件 |
+| 影响 | 修改 guard-procedures 内部实现不影响 pace-dev（只要 risk-format.md 契约不变） |
| 反向感知 | `skills/pace-guard/SKILL.md:2`（NOT 声明排除触发混淆） |
-### pace-dev → pace-test（procedures 内联 + 命令建议）
+### pace-dev → pace-test（Schema 契约 + 命令委托）
| 属性 | 值 |
|------|-----|
-| 耦合类型 | **代码内联** + 命令建议 + 数据文件共享 |
-| 风险等级 | **高** |
-| 内联位置 | `skills/pace-dev/dev-procedures-developing.md:146`（"按 `test-procedures-strategy-gen.md` §3 执行 strategy 生成流程"） |
+| 耦合类型 | **Schema 契约**（通过 test-strategy-format.md 接口）+ 命令委托 + 数据文件共享 |
+| 风险等级 | **低**（已解耦） |
+| 契约位置 | `skills/pace-dev/dev-procedures-developing.md:146`（引用 `knowledge/_schema/test-strategy-format.md`，或委托 `/pace-test strategy`） |
| 命令建议 | `dev-procedures-developing.md:135`（`/pace-test generate`）、`:171`（`/pace-test dryrun 1`）、`dev-procedures-gate.md:17`（`/pace-test generate`） |
| 共享数据 | `.devpace/rules/test-strategy.md`、`.devpace/rules/checks.md` |
-| 影响 | 重命名/重构 `test-procedures-strategy-gen.md` 会直接破坏 pace-dev 的自动 strategy 生成 |
+| 影响 | 修改 test-procedures 内部实现不影响 pace-dev（只要 test-strategy-format.md 契约不变） |
-### pace-review → pace-test accept（深度格式依赖）
+### pace-review → pace-test accept（共享契约）
| 属性 | 值 |
|------|-----|
-| 耦合类型 | **数据格式依赖（深度结构依赖）** |
-| 风险等级 | **很高** |
+| 耦合类型 | **共享 Schema 契约**（通过 accept-report-contract.md 接口） |
+| 风险等级 | **中**（已从"很高"降级——格式变更通过契约文件协调） |
+| 契约文件 | `knowledge/_schema/accept-report-contract.md`（生产方和消费方的共享接口） |
| 声明位置 | `skills/pace-test/SKILL.md:19`（"pace-review Gate 2：可消费 /pace-test accept 的验收映射报告"） |
-| 消费逻辑 | `skills/pace-review/review-procedures-gate.md:84-88`（对抗审查联动 accept 弱覆盖区域） |
-| 结构化消费 | `skills/pace-review/review-procedures-gate.md:160-178`（独立章节，精确定义提取字段） |
-| 模板嵌入 | `review-procedures-gate.md:197-201`（M 级）、`:239-243`（L/XL 级）摘要模板内嵌 accept 字段 |
-| 依赖字段 | 通过率、验证级别分布(L1/L2/L3)、预言审查(有效/弱/虚假覆盖)、置信度(High/Medium/Low)、自审计 |
-| 影响 | pace-test accept 输出格式变更将直接破坏 pace-review 的摘要模板 |
+| 消费逻辑 | `skills/pace-review/review-procedures-gate.md`（引用 accept-report-contract.md 提取规则） |
+| 模板嵌入 | `review-procedures-gate.md` 摘要模板的 accept 字段按契约定义的格式填充 |
+| 影响 | 变更 accept 输出格式时修改 accept-report-contract.md，双方同步适配 |
### pace-review → pace-learn（打回信息数据流）
@@ -114,15 +113,15 @@
## §2 计划与变更管理
-### pace-change → pace-plan adjust（代码内联）
+### pace-change → pace-plan adjust（命令委托）
| 属性 | 值 |
|------|-----|
-| 耦合类型 | **代码内联**（最高风险耦合） |
-| 风险等级 | **高** |
+| 耦合类型 | **命令委托**（通过 `/pace-plan adjust` 委托 + iteration-format.md 契约） |
+| 风险等级 | **低**（已解耦） |
| 位置 | `skills/pace-change/change-procedures-types.md:85` |
-| 描述 | "用户确认 → 内联执行 /pace-plan adjust 的逻辑（读取 adjust-procedures.md），无需用户手动切换命令" |
-| 影响 | 修改 `pace-plan/adjust-procedures.md` 时必须同步检查 pace-change 的内联引用 |
+| 描述 | "用户确认 → 委托 `/pace-plan adjust` 执行，迭代写入规则见 iteration-format.md" |
+| 影响 | 修改 adjust-procedures.md 内部实现不影响 pace-change（只要 iteration-format.md 契约不变） |
### pace-change → pace-dev / pace-sync（流转建议）
@@ -215,10 +214,11 @@
|---------|--------|
| pace-dev (CR 状态转换逻辑) | pace-review, post-cr-update Hook, sync-push Hook, pace-pulse |
| pace-dev (Gate 检查逻辑) | pace-test (dryrun 对照表), pre-tool-use Hook |
-| pace-guard `guard-procedures-scan.md` | **pace-dev**（直接引用此文件路径执行 L/XL 扫描） |
-| pace-test `test-procedures-strategy-gen.md` | **pace-dev**（直接引用此文件路径执行 strategy 生成） |
-| pace-test accept (输出格式) | **pace-review**（摘要模板内嵌 accept 字段，深度格式依赖） |
-| pace-plan `adjust-procedures.md` | **pace-change**（内联执行此逻辑） |
+| pace-guard `guard-procedures-scan.md` | 无直接依赖方（pace-dev 已改引用 risk-format.md 契约） |
+| pace-test `test-procedures-strategy-gen.md` | 无直接依赖方（pace-dev 已改引用 test-strategy-format.md 契约） |
+| pace-test accept (输出格式) | **accept-report-contract.md**（变更格式时需同步更新契约文件） |
+| pace-plan `adjust-procedures.md` | 无直接依赖方（pace-change 已改为委托 `/pace-plan adjust`） |
+| **accept-report-contract.md** | **pace-test accept**（生产方）+ **pace-review**（消费方） |
| pace-learn (写入管道格式) | pace-retro (学习请求格式), post-cr-update Hook |
| pace-retro (迭代传递清单格式) | pace-plan next (消费传递清单) |
| pace-next 命令映射表 | 新增/重命名任何 Skill 命令时 |
diff --git a/docs/design/vision.md b/docs/design/vision.md
index 979b9c2..1303215 100644
--- a/docs/design/vision.md
+++ b/docs/design/vision.md
@@ -114,6 +114,8 @@
## 业务目标
+> OBJ 可标注产品维度属性：类型（business/product/tech）+ 时间维度（短期/中期/长期）。详见 `knowledge/_schema/project-format.md` "业务目标"章节。
+
### MVP 阶段（1-2 周）
| ID | 目标 | 成效指标（MoS） | 验证方式 |
diff --git a/docs/features/pace-biz.md b/docs/features/pace-biz.md
new file mode 100644
index 0000000..df3267e
--- /dev/null
+++ b/docs/features/pace-biz.md
@@ -0,0 +1,156 @@
+# Business Planning (`/pace-biz`)
+
+devpace has always managed the flow from product features (PF) down to code changes (CR), but the upstream question — *where do these features come from?* — was left outside the system. Business opportunities were captured in scattered notes, epics lived in external tools, and the link between strategic objectives and day-to-day development was implicit at best. `/pace-biz` closes this gap by bringing structured business planning into the same value chain, so that every line of code can be traced back to a business opportunity.
+
+## Quick Start
+
+```
+1. /pace-biz opportunity "Enterprise clients need SSO" → Capture opportunity → OPP-001 created
+2. /pace-biz epic OPP-001 "Enterprise Authentication" → Create epic → EPIC-001 with OBJ alignment
+3. /pace-biz decompose EPIC-001 → Break down → BRs and PFs generated
+```
+
+Or let Claude guide you interactively:
+
+```
+You: /pace-biz
+Claude: [Recommends next action based on project context]
+ Or choose: opportunity / epic / decompose / align / view / discover / import / infer
+```
+
+Start from a vague idea:
+
+```
+4. /pace-biz discover "I want to build a task management tool" → Multi-turn discovery → Full candidate tree
+5. /pace-biz import meeting-notes.md → Extract requirements → Merge into tree
+6. /pace-biz infer → Scan codebase → Gap report
+```
+
+## Workflow
+
+### `opportunity` — Capture Business Opportunities
+
+Business opportunities are the raw inputs to the planning process — market signals, customer feedback, stakeholder requests, or competitive observations. `/pace-biz opportunity` captures them with structured metadata so nothing falls through the cracks.
+
+Each opportunity receives:
+- **Auto-numbered ID** (OPP-001, OPP-002, ...)
+- **Source classification** — customer feedback, market research, stakeholder request, competitive analysis, technical debt, or internal initiative
+- **Initial assessment** — Claude suggests relevance to existing OBJs and potential impact level
+- **Persisted record** — Written to `.devpace/opportunities.md` with creation date and status (new / evaluating / accepted / declined / deferred)
+
+Multiple opportunities can reference the same strategic objective, building a natural demand signal for prioritization.
+
+### `epic` — Create Strategic Epics
+
+Epics are the bridge between raw opportunities and actionable business requirements. `/pace-biz epic` creates a structured epic that groups related work under a clear business intent.
+
+An epic includes:
+- **OBJ alignment** — Which strategic objectives does this epic serve? Claude suggests mappings based on the epic description and linked opportunities
+- **Measures of Success (MoS)** — Concrete, verifiable outcomes that define "done" at the business level
+- **Scope boundary** — What is in scope and what is explicitly excluded
+- **Independent file** — Each epic is stored as `epics/EPIC-xxx.md` for traceability and cross-referencing
+
+Epics can be created from an existing opportunity (`/pace-biz epic OPP-001 "title"`) or directly (`/pace-biz epic "title"`). When created from an opportunity, the link is recorded in both directions.
+
+### `decompose` — Break Down into Deliverables
+
+Decomposition is where strategic intent meets execution planning. `/pace-biz decompose` supports two decomposition paths:
+
+1. **Epic → BR** — Break an epic into business requirements, each representing a distinct business capability or outcome
+2. **BR → PF** — Break a business requirement into product features, each deliverable in one or two iterations
+
+Claude analyzes the parent entity and suggests a decomposition plan — number of children, proposed titles, scope for each. The user reviews, adjusts, and confirms before any files are created. Decomposition respects the existing value chain: new BRs link back to their epic, new PFs link back to their BR.
+
+### `align` — Strategic Alignment Check
+
+As the project grows, it is easy for the business plan to drift. `/pace-biz align` performs a health check across the entire upstream value chain:
+
+| Check | What it detects |
+|-------|-----------------|
+| **OBJ coverage** | Strategic objectives with no epics or BRs mapped to them |
+| **Orphan detection** | Epics, BRs, or PFs that are not linked to any upstream entity |
+| **MoS completeness** | Epics or BRs missing measurable success criteria |
+| **Decomposition gaps** | Epics with no BRs, or BRs with no PFs |
+| **Staleness** | Opportunities stuck in "new" status beyond a configurable threshold |
+
+The output is a concise alignment report with specific recommendations for each issue found.
+
+### `view` — Business Panorama
+
+`/pace-biz view` renders the full value stream from opportunities down to CRs, giving a bird's-eye view of how business intent flows through the system:
+
+```
+OPP-001 "Enterprise SSO demand"
+ └─ EPIC-001 "Enterprise Authentication" [OBJ-1]
+ ├─ BR-003 "SSO Integration"
+ │ ├─ PF-007 "SAML Provider" → CR-012 (developing)
+ │ └─ PF-008 "OIDC Provider" → CR-013 (created)
+ └─ BR-004 "Session Management"
+ └─ PF-009 "Token Lifecycle" → CR-014 (created)
+```
+
+Filters are available by OBJ, epic, status, or depth level. When called without filters, the full tree is displayed with status indicators.
+
+### `discover` — Interactive Requirements Discovery
+
+When starting from a vague idea — "I want to build a smart customer service system" — `/pace-biz discover` launches a guided multi-turn conversation that progressively shapes the idea into a structured value chain.
+
+The process unfolds in stages:
+1. **Goal framing** (1-2 rounds) — What problem are we solving? Who are the users?
+2. **Feature brainstorming** (2-4 rounds) — What must users be able to do? What happens in edge cases?
+3. **Boundary definition** (1-2 rounds) — What is explicitly out of scope? What constraints exist?
+4. **Validation** (1 round) — Review the structured candidate tree (OPP → Epic → BR → PF) and adjust
+
+Session state is persisted to `.devpace/scope-discovery.md`, so discovery can span multiple conversations. Once confirmed, all candidates are written to the appropriate `.devpace/` files and the temporary session file is removed.
+
+### `import` — Multi-Source Document Import
+
+Teams accumulate requirements in many places — meeting notes, user feedback surveys, competitor analyses, technical debt lists. `/pace-biz import` reads these documents, extracts requirement entities, and merges them into the existing feature tree.
+
+Supported source types (auto-detected):
+- **Meeting minutes** — action items become BR/PF candidates
+- **User feedback** — pain points become BRs, feature requests become PFs
+- **Competitor analysis** — gap features become PF candidates
+- **Technical debt lists** — debt items become PFs tagged as technical debt
+- **Issue exports** (CSV/JSON) — issues map to PF/CR candidates
+- **PRD / API specs** — same parsing as `/pace-init --from`
+
+Each extracted entity is classified as NEW, DUPLICATE, ENRICHMENT, or CONFLICT relative to the existing tree. The user reviews a diff-style merge plan before any files are written. Import operates at the OPP/Epic/BR/PF level — it does not create CRs.
+
+### `infer` — Codebase Feature Inference
+
+For legacy projects or projects that outgrew their documentation, `/pace-biz infer` scans the codebase and reverse-engineers a feature map:
+
+- **Structure analysis** — directories, routes, API endpoints, data models, UI components
+- **Signal mining** — TODO/FIXME density, README vs code drift, package scripts
+- **Git-enhanced analysis** (when available) — file hotspots, co-change coupling, contributor distribution
+
+The output is a three-part gap report:
+1. **Untracked features** — code exists but the feature tree has no corresponding PF
+2. **Unimplemented features** — feature tree has PFs but no code exists
+3. **Technical debt** — high TODO/FIXME concentration areas
+
+Users select which items to add to the feature tree. Technical debt PFs are suffixed with "(technical debt)" for easy filtering.
+
+## Backward Compatibility
+
+Projects initialized before `/pace-biz` was introduced — those without `opportunities.md`, `epics/`, or upstream BR linkage — continue to work without any changes. The existing PF → CR flow is unaffected. `/pace-biz` capabilities become available incrementally: capture your first opportunity or create your first epic whenever you are ready, and the value chain extends upward naturally.
+
+## Integration with Other Commands
+
+| Command | Relationship |
+|---------|-------------|
+| `/pace-init` | Initializes the `.devpace/` structure. After `/pace-biz` is available, `pace-init` can optionally scaffold `opportunities.md` and `epics/` directory. |
+| `/pace-change` | Handles PF-level requirement changes. `/pace-biz` operates upstream — creating the BRs and PFs that `/pace-change` later manages. |
+| `/pace-plan` | Plans iterations by selecting PFs. `/pace-biz decompose` produces the PFs that feed into `/pace-plan next`. |
+| `/pace-status` | Reflects the full project state. With `/pace-biz` data present, status views can include upstream context (epic progress, OBJ coverage). |
+| `/pace-trace` | Traces value chain connections. `/pace-biz` enriches traceability by adding the OPP → EPIC → BR layers above the existing BR → PF → CR chain. |
+
+## Related Resources
+
+- [epic-format.md](../../knowledge/_schema/epic-format.md) — Epic file schema
+- [br-format.md](../../knowledge/_schema/br-format.md) — Business requirement file schema
+- [opportunity-format.md](../../knowledge/_schema/opportunity-format.md) — Opportunity record schema
+- [skills/pace-biz/](../../skills/pace-biz/) — Operational procedures
+- [devpace-rules.md](../../rules/devpace-rules.md) — Runtime behavior rules
+- [User Guide](../user-guide.md) — Quick reference for all commands
diff --git a/docs/features/pace-biz_zh.md b/docs/features/pace-biz_zh.md
new file mode 100644
index 0000000..2b60713
--- /dev/null
+++ b/docs/features/pace-biz_zh.md
@@ -0,0 +1,156 @@
+# 业务规划（`/pace-biz`）
+
+devpace 一直管理着从产品功能（PF）到代码变更（CR）的交付流程，但上游的问题——*这些功能从何而来？*——始终游离在体系之外。业务机会散落在各种笔记中，专题（Epic）活在外部工具里，战略目标与日常开发之间的关联只能靠默契维系。`/pace-biz` 补上了这一环，将结构化的业务规划纳入同一条价值链，让每一行代码都能追溯到它背后的业务机会。
+
+## 快速上手
+
+```
+1. /pace-biz opportunity "企业客户需要 SSO" → 捕获机会 → OPP-001 创建
+2. /pace-biz epic OPP-001 "企业级认证" → 创建专题 → EPIC-001 关联 OBJ
+3. /pace-biz decompose EPIC-001 → 分解需求 → 生成 BR 和 PF
+```
+
+或者让 Claude 交互式引导：
+
+```
+你： /pace-biz
+Claude：[根据项目上下文推荐下一步操作]
+ 或选择：opportunity / epic / decompose / align / view / discover / import / infer
+```
+
+从模糊想法开始：
+
+```
+4. /pace-biz discover "我想做一个任务管理工具" → 多轮对话发现 → 完整候选树
+5. /pace-biz import 会议纪要.md → 提取需求 → 合并到功能树
+6. /pace-biz infer → 扫描代码库 → 差距报告
+```
+
+## 子命令
+
+### `opportunity` — 捕获业务机会
+
+业务机会是规划流程的原始输入——市场信号、客户反馈、利益相关者请求或竞争观察。`/pace-biz opportunity` 用结构化元数据捕获它们，确保没有遗漏。
+
+每个机会包含：
+- **自动编号**（OPP-001、OPP-002……）
+- **来源分类** — 客户反馈、市场调研、利益相关者请求、竞争分析、技术债务、内部倡议
+- **初步评估** — Claude 建议与现有 OBJ 的关联度和潜在影响级别
+- **持久化记录** — 写入 `.devpace/opportunities.md`，含创建日期和状态（new / evaluating / accepted / declined / deferred）
+
+多个机会可以指向同一战略目标，自然形成需求优先级的信号积累。
+
+### `epic` — 创建战略专题
+
+专题是原始机会与可执行业务需求之间的桥梁。`/pace-biz epic` 创建结构化专题，将相关工作归入清晰的业务意图之下。
+
+专题包含：
+- **OBJ 对齐** — 服务于哪些战略目标？Claude 根据专题描述和关联机会建议映射
+- **成功度量（MoS）** — 具体的、可验证的业务级完成标准
+- **范围边界** — 明确纳入和排除的内容
+- **独立文件** — 每个专题存储为 `epics/EPIC-xxx.md`，支持追溯和交叉引用
+
+专题可从现有机会创建（`/pace-biz epic OPP-001 "标题"`）或直接创建（`/pace-biz epic "标题"`）。从机会创建时，双向链接自动记录。
+
+### `decompose` — 分解为可交付项
+
+分解是战略意图与执行规划的交汇点。`/pace-biz decompose` 支持两条分解路径：
+
+1. **Epic → BR** — 将专题分解为业务需求，每个代表一项独立的业务能力或成果
+2. **BR → PF** — 将业务需求分解为产品功能，每个可在一到两个迭代内交付
+
+Claude 分析父级实体并建议分解方案——子项数量、建议标题、各自范围。用户审查、调整并确认后才创建文件。分解遵循现有价值链：新 BR 链接回所属专题，新 PF 链接回所属 BR。
+
+### `align` — 战略对齐检查
+
+随着项目增长，业务规划容易偏移。`/pace-biz align` 对整个上游价值链做健康检查：
+
+| 检查项 | 检测内容 |
+|--------|---------|
+| **OBJ 覆盖率** | 没有专题或 BR 映射的战略目标 |
+| **孤立实体** | 未链接到任何上游实体的专题、BR 或 PF |
+| **MoS 完整性** | 缺少可度量成功标准的专题或 BR |
+| **分解空白** | 没有 BR 的专题，或没有 PF 的 BR |
+| **停滞检测** | 长时间停留在"new"状态的机会 |
+
+输出为简洁的对齐报告，针对每个发现的问题给出具体建议。
+
+### `view` — 业务全景视图
+
+`/pace-biz view` 渲染从机会到 CR 的完整价值流，鸟瞰业务意图如何贯穿整个系统：
+
+```
+OPP-001 "企业 SSO 需求"
+ └─ EPIC-001 "企业级认证" [OBJ-1]
+ ├─ BR-003 "SSO 集成"
+ │ ├─ PF-007 "SAML 提供商" → CR-012 (developing)
+ │ └─ PF-008 "OIDC 提供商" → CR-013 (created)
+ └─ BR-004 "会话管理"
+ └─ PF-009 "Token 生命周期" → CR-014 (created)
+```
+
+支持按 OBJ、专题、状态或层级深度过滤。无过滤条件时展示完整树状结构及状态指示。
+
+### `discover` — 交互式需求发现
+
+当只有一个模糊想法——"我想做一个智能客服系统"——`/pace-biz discover` 启动多轮引导对话，逐步将想法塑造为结构化的价值链。
+
+流程分阶段展开：
+1. **目标框定**（1-2 轮）——要解决什么问题？目标用户是谁？
+2. **功能头脑风暴**（2-4 轮）——用户必须能做什么？异常情况怎么办？
+3. **边界定义**（1-2 轮）——明确不做什么？有什么约束？
+4. **验证确认**（1 轮）——审查结构化候选树（OPP→Epic→BR→PF），调整后写入
+
+会话状态持久化到 `.devpace/scope-discovery.md`，发现过程可跨多次对话。确认后所有候选写入对应 `.devpace/` 文件，临时会话文件删除。
+
+### `import` — 多源文档导入
+
+团队在很多地方积累需求——会议纪要、用户反馈调研、竞品分析、技术债务清单。`/pace-biz import` 读取这些文档，提取需求实体，合并到现有功能树。
+
+支持的源类型（自动检测）：
+- **会议纪要** — Action Items 转为 BR/PF 候选
+- **用户反馈** — 痛点转为 BR，功能请求转为 PF
+- **竞品分析** — 差距功能转为 PF 候选
+- **技术债务清单** — 债务项转为 PF（标记技术债务）
+- **Issue 导出**（CSV/JSON）— Issues 映射为 PF/CR 候选
+- **PRD / API 规格** — 同 `/pace-init --from` 的解析规则
+
+每个提取的实体按 NEW/DUPLICATE/ENRICHMENT/CONFLICT 分类。用户审查 diff 格式的合并计划后才写入文件。import 在 OPP/Epic/BR/PF 层面操作——不创建 CR。
+
+### `infer` — 代码库功能推断
+
+对于遗留项目或文档滞后的项目，`/pace-biz infer` 扫描代码库，反向推导功能地图：
+
+- **结构分析** — 目录、路由、API 端点、数据模型、UI 组件
+- **信号挖掘** — TODO/FIXME 密度、README 与代码漂移、构建脚本
+- **Git 增强分析**（可用时）— 文件热点、共变耦合、贡献者分布
+
+输出为三段式差距报告：
+1. **未追踪功能** — 代码存在但功能树中无对应 PF
+2. **未实现功能** — 功能树有 PF 但无代码实现
+3. **技术债务** — TODO/FIXME 高密度区域
+
+用户选择哪些项纳入功能树。技术债务 PF 附"（技术债务）"后缀，便于过滤。
+
+## 向后兼容
+
+在 `/pace-biz` 引入之前初始化的项目——没有 `opportunities.md`、`epics/` 目录或上游 BR 链接——继续正常工作，不受任何影响。现有的 PF → CR 流程完全不变。`/pace-biz` 的能力渐进式可用：在你准备好时捕获第一个机会或创建第一个专题，价值链自然向上延伸。
+
+## 与其他命令的集成
+
+| 命令 | 与 `/pace-biz` 的关系 |
+|------|---------------------|
+| `/pace-init` | 初始化 `.devpace/` 结构。`/pace-biz` 可用后，`pace-init` 可选择性地创建 `opportunities.md` 和 `epics/` 目录。 |
+| `/pace-change` | 处理 PF 级需求变更。`/pace-biz` 在上游操作——创建 BR 和 PF，由 `/pace-change` 后续管理。 |
+| `/pace-plan` | 通过选择 PF 规划迭代。`/pace-biz decompose` 产出的 PF 直接进入 `/pace-plan next` 的候选池。 |
+| `/pace-status` | 展示完整项目状态。有 `/pace-biz` 数据时，状态视图可包含上游上下文（专题进度、OBJ 覆盖率）。 |
+| `/pace-trace` | 追溯价值链连接。`/pace-biz` 在现有 BR → PF → CR 链之上增加 OPP → EPIC → BR 层级，丰富追溯能力。 |
+
+## 相关资源
+
+- [epic-format.md](../../knowledge/_schema/epic-format.md) — 专题文件 schema
+- [br-format.md](../../knowledge/_schema/br-format.md) — 业务需求文件 schema
+- [opportunity-format.md](../../knowledge/_schema/opportunity-format.md) — 机会记录 schema
+- [skills/pace-biz/](../../skills/pace-biz/) — 操作规程
+- [devpace-rules.md](../../rules/devpace-rules.md) — 运行时行为规则
+- [用户指南](../user-guide.md) — 所有命令快速参考
diff --git a/docs/features/pace-feedback.md b/docs/features/pace-feedback.md
index 8523e27..d48e33e 100644
--- a/docs/features/pace-feedback.md
+++ b/docs/features/pace-feedback.md
@@ -8,8 +8,10 @@ Every piece of feedback receives a unique **FB-ID** for full lifecycle tracking
```
1. /pace-feedback report "API 500 errors in /checkout" → Emergency channel → Create hotfix CR
-2. /pace-feedback "search is too slow" → Classify → Improvement pool
-3. /pace-feedback → Guided collection → Two-round dialog
+2. /pace-feedback incident open "全站不可用" → Create incident record (P0) + timeline
+3. /pace-feedback incident close INCIDENT-001 → Close incident + generate postmortem
+4. /pace-feedback "search is too slow" → Classify → Improvement pool
+5. /pace-feedback → Guided collection → Two-round dialog
```
Or use the emergency hotline:
@@ -111,6 +113,49 @@ After successful completion, delete `.devpace/backlog/FEEDBACK-DRAFT.md` to prep
| **New Requirement** | Feature requests, stakeholder input | "Need bulk import", "Support SSO", "Add export to PDF" |
| **Inbox** | Ambiguous signals, deferred items | "Something feels off", "Users complaining (details unclear)", "Monitor this behavior" |
+## Incident Management
+
+The `incident` subcommand series provides structured incident lifecycle management — severity grading (P0-P3), timeline tracking, and postmortem generation — complementing the existing `report` emergency channel.
+
+### Subcommands
+
+| Subcommand | Description |
+|------------|------------|
+| `incident open ` | Create an incident record with severity assessment and timeline initialization |
+| `incident close ` | Close an incident and generate a postmortem template |
+| `incident timeline ` | View the incident timeline (read-only) |
+| `incident list [--open]` | List all incidents, optionally filtered to open only |
+
+### Severity Grading
+
+Incidents are graded using the same severity matrix as hotfix assessment, mapped to incident levels:
+
+| Severity | Incident Level | Response | Example |
+|----------|---------------|----------|---------|
+| critical | P0 | Immediate response, all work paused | Site-wide outage, data loss |
+| major | P1 | Respond within 1 hour | Core feature unavailable, severe performance degradation |
+| minor | P2 | Respond same day | Non-core feature issue, UI error |
+| trivial | P3 | Next iteration | UX polish, copy issues |
+
+### Workflow: report + incident
+
+`incident open` and `report` can be used together for full coverage:
+
+1. `incident open` creates the structured incident record (timeline, severity, tracking)
+2. `report` creates the corresponding Hotfix CR for the actual fix
+3. After CR is merged, `incident close` closes the incident and generates a postmortem
+
+### Postmortem
+
+When closing an incident, a postmortem template is automatically generated covering:
+- **Impact summary**: Duration and scope
+- **Root cause**: (to be filled)
+- **Fix measures**: Summary of associated CR fixes
+- **Prevention measures**: (to be filled)
+- **Lessons learned**: (to be filled)
+
+Incident records are stored in `.devpace/incidents/INCIDENT-NNN.md`. See `incident-format.md` for the full schema.
+
## Key Features
### Unique Feedback ID (FB-ID) Tracking
@@ -357,8 +402,9 @@ Claude: Classification: Inbox (ambiguous, non-urgent)
- [User Guide — /pace-feedback section](../user-guide.md) — Quick reference and command syntax
- [Design Document — Feedback Loop Integration](../design/design.md) — Architecture and closed-loop design principles
-- [skills/pace-feedback/](../../skills/pace-feedback/) — Operational procedures (5 split files: common, intake, trace, hotfix, analysis)
+- [skills/pace-feedback/](../../skills/pace-feedback/) — Operational procedures (6 split files: common, intake, trace, hotfix, analysis, incident)
- [fb-format.md](../../knowledge/_schema/fb-format.md) — Feedback record schema with FB-ID structure
+- [incident-format.md](../../knowledge/_schema/incident-format.md) — Incident record schema with INCIDENT-NNN structure
- [feedback-status.md](../../knowledge/_schema/feedback-status.md) — Feedback lifecycle state definitions
- [metrics.md](../../knowledge/metrics.md) — Feedback management metrics definitions (resolution time, recurring rate, improvement adoption)
- [devpace-rules.md](../../rules/devpace-rules.md) — Runtime behavior rules for feedback processing
diff --git a/docs/features/pace-feedback_zh.md b/docs/features/pace-feedback_zh.md
index 5dd68ab..c388d24 100644
--- a/docs/features/pace-feedback_zh.md
+++ b/docs/features/pace-feedback_zh.md
@@ -7,9 +7,11 @@
## 快速上手
```
-1. /pace-feedback report "支付接口 500 错误" → 紧急通道 → 创建 hotfix CR
-2. /pace-feedback "搜索结果不准确" → 分类 → 改进建议池
-3. /pace-feedback → 渐进式两轮引导收集
+1. /pace-feedback report "支付接口 500 错误" → 紧急通道 → 创建 hotfix CR
+2. /pace-feedback incident open "全站不可用" → 创建事件记录（P0）+ 时间线
+3. /pace-feedback incident close INCIDENT-001 → 关闭事件 + 生成 postmortem
+4. /pace-feedback "搜索结果不准确" → 分类 → 改进建议池
+5. /pace-feedback → 渐进式两轮引导收集
```
紧急通道用法：
@@ -62,6 +64,66 @@ Claude: [紧急通道] 严重度：critical | 关联：用户认证（PF-03）
处理完成后删除 `.devpace/backlog/FEEDBACK-DRAFT.md`。
+## 事件管理（Incident Management）
+
+`incident` 子命令系列提供结构化事件生命周期管理——严重度分级（P0-P3）、时间线追踪和事后复盘（Postmortem），补全现有 `report` 紧急通道的运维闭环。
+
+### 子命令
+
+| 子命令 | 说明 |
+|--------|------|
+| `incident open <描述>` | 创建事件记录（严重度评估 + 时间线初始化） |
+| `incident close ` | 关闭事件 + 生成 postmortem 模板 |
+| `incident timeline ` | 查看事件时间线（只读） |
+| `incident list [--open]` | 列出所有事件，可筛选仅显示未关闭事件 |
+
+### 严重度分级
+
+复用 hotfix 严重度矩阵，映射为事件等级：
+
+| 严重度 | 事件等级 | 响应要求 | 示例 |
+|--------|---------|---------|------|
+| critical | P0 | 立即响应，所有工作暂停 | 全站不可用、数据丢失 |
+| major | P1 | 1 小时内响应 | 核心功能不可用、性能严重降级 |
+| minor | P2 | 当日响应 | 非核心功能异常、UI 错误 |
+| trivial | P3 | 下个迭代处理 | 体验优化、文案问题 |
+
+### 工作流：report + incident 并行
+
+`incident open` 和 `report` 可并行使用，实现完整覆盖：
+
+1. `incident open` 创建结构化事件记录（时间线、严重度、追踪）
+2. `report` 创建对应的 Hotfix CR 用于实际修复
+3. CR merged 后，`incident close` 关闭事件并生成 postmortem
+
+### Postmortem（事后复盘）
+
+关闭事件时自动生成 postmortem 模板，涵盖：
+- **影响摘要**：持续时间、影响范围
+- **根本原因**：（待填写）
+- **修复措施**：关联 CR 修复摘要
+- **预防措施**：（待填写）
+- **经验教训**：（待填写）
+
+事件记录存储在 `.devpace/incidents/INCIDENT-NNN.md`，完整格式定义见 `incident-format.md`。
+
+### 使用示例
+
+```
+你: /pace-feedback incident open "支付网关超时，全站交易中断"
+Claude: [INCIDENT-003] 事件已创建
+ 严重度：P0（critical → 立即响应）
+ 状态：open
+ 时间线：2026-03-08T14:30:00 事件创建
+ 建议立即 /pace-feedback report 创建 Hotfix CR。
+
+你: /pace-feedback incident close INCIDENT-003
+Claude: [INCIDENT-003] 事件已关闭
+ 持续时间：2 小时 15 分
+ 关联 CR：CR-067（已 merged）
+ Postmortem 模板已生成，请填写根本原因和预防措施。
+```
+
## 核心特性
### FB-ID 全链路追踪
@@ -165,6 +227,7 @@ Claude: 已恢复。上次收集到：症状=接口超时、影响=部分用户
- [User Guide — /pace-feedback](../user-guide.md) — 参数速查
- [英文版本](./pace-feedback.md) — English version
-- [skills/pace-feedback/](../../skills/pace-feedback/) — Skill 实现和详细规程
+- [skills/pace-feedback/](../../skills/pace-feedback/) — Skill 实现和详细规程（6 个分拆文件：common、intake、trace、hotfix、analysis、incident）
+- [incident-format.md](../../knowledge/_schema/incident-format.md) — 事件记录格式定义
- [devpace-rules.md §14](../../rules/devpace-rules.md) — 条件生效规则
- [metrics.md](../../knowledge/metrics.md) — 度量指标定义
diff --git a/docs/features/pace-next.md b/docs/features/pace-next.md
index 91ef41d..7307643 100644
--- a/docs/features/pace-next.md
+++ b/docs/features/pace-next.md
@@ -9,13 +9,15 @@ Where `/pace-status` answers "where are we?", `/pace-next` answers "where should
## Quick Start
```
-1. /pace-next --> Top-1 recommendation (3 lines: suggestion + reason + action)
-2. /pace-next detail --> Top-3 candidates (up to 8 lines)
-3. /pace-next why --> Expand reasoning chain (2-5 lines: signal scan, priority comparison, alternatives)
-4. /pace-trace next --> Full signal collection and traversal trace
+1. /pace-next --> Top-1 recommendation (3 lines: suggestion + reason + action)
+2. /pace-next detail --> Top-3 candidates (up to 8 lines)
+3. /pace-next why --> Expand reasoning chain (2-5 lines: signal scan, priority comparison, alternatives)
+4. /pace-next journey --> Full workflow journey from current state to goal (auto-selects template)
+5. /pace-next journey hotfix --> Journey with a specific template
+6. /pace-trace next --> Full signal collection and traversal trace
```
-The default output is designed to answer "what should I do next?" in under three seconds of reading time. Use `detail` when you want alternatives, and `why` when you want to understand the reasoning.
+The default output is designed to answer "what should I do next?" in under three seconds of reading time. Use `detail` when you want alternatives, `why` when you want to understand the reasoning, and `journey` when you want to see the full path ahead.
## Core Features
@@ -115,6 +117,41 @@ Candidates (by priority):
When only one signal fires, the candidates section is omitted.
+### Journey Mode
+
+`/pace-next journey` shifts from "what is the single next action?" to "what is the full path from here to the goal?" It renders a step-by-step journey view showing completed steps, the current position, and remaining steps -- all advisory, with no automatic execution.
+
+**Templates:**
+
+| Template | Journey Path | Use Case |
+|----------|-------------|----------|
+| `new-feature` | biz discover → decompose → plan next → dev → review → merged | Deliver a feature from scratch |
+| `iteration` | plan next → [dev → review → merged]* → plan close → retro | Full iteration cycle |
+| `hotfix` | feedback report → dev → review → release deploy | Emergency fix |
+| `release` | release create → deploy → verify → close | Standard release |
+| `onboarding` | init → dev (first feature) → review → merged | First-time user experience |
+
+When no template name is provided, journey auto-selects based on project state (e.g., new project with no CRs → `onboarding`; active iteration → `iteration`).
+
+**Example output:**
+
+```
+Journey: iteration — complete the current iteration cycle
+
+✅ Plan iteration — 3 features scoped
+✅ Dev PF-001 — "OAuth integration" merged
+👉 Dev PF-002 — say "implement [feature name]" or /pace-dev
+⏳ Review — /pace-review
+⏳ Iteration retro — /pace-retro
+
+Progress: 2/5 steps complete
+```
+
+**Key rules:**
+- Advisory only -- shows the path, never auto-executes any Skill
+- Stateless -- no journey state file is persisted; the view is dynamically derived from `.devpace/` on every call
+- Complementary to default mode -- journey shows the full map, default mode recommends the single next step
+
## Output Examples
### Default -- Quick Recommendation
@@ -206,6 +243,7 @@ All signal definitions, grouping, and role reordering rules are maintained in `k
- [SKILL.md](../../skills/pace-next/SKILL.md) -- Skill definition, input/output, and high-level flow
- [next-procedures.md](../../skills/pace-next/next-procedures.md) -- Detailed decision algorithm, output formats, and role adaptation rules
+- [next-procedures-journey.md](../../skills/pace-next/next-procedures-journey.md) -- Journey orchestration templates, auto-selection logic, and output format
- [signal-priority.md](../../knowledge/signal-priority.md) -- Signal definitions and priority groups (SSOT)
- [signal-collection.md](../../knowledge/signal-collection.md) -- Shared signal collection procedures
- [User Guide](../user-guide.md) -- Quick reference for all commands
diff --git a/docs/features/pace-next_zh.md b/docs/features/pace-next_zh.md
index 3dd591e..4d5a9aa 100644
--- a/docs/features/pace-next_zh.md
+++ b/docs/features/pace-next_zh.md
@@ -9,13 +9,15 @@
## 快速上手
```
-1. /pace-next --> 最高优先级 1 条建议（建议 + 原因 + 操作，3 行）
-2. /pace-next detail --> top-3 候选列表（最多 8 行）
-3. /pace-next why --> 展开推理链（2-5 行：信号扫描、优先级对比、备选方案）
-4. /pace-trace next --> 查看完整信号采集和遍历过程
+1. /pace-next --> 最高优先级 1 条建议（建议 + 原因 + 操作，3 行）
+2. /pace-next detail --> top-3 候选列表（最多 8 行）
+3. /pace-next why --> 展开推理链（2-5 行：信号扫描、优先级对比、备选方案）
+4. /pace-next journey --> 完整工作流旅程：从当前状态到目标的分步引导（自动选择模板）
+5. /pace-next journey hotfix --> 指定模板的旅程视图
+6. /pace-trace next --> 查看完整信号采集和遍历过程
```
-默认输出 3 秒内可读完。需要备选方案时用 `detail`，想了解推理逻辑时用 `why`。
+默认输出 3 秒内可读完。需要备选方案时用 `detail`，想了解推理逻辑时用 `why`，想看完整路径时用 `journey`。
## 核心特性
@@ -115,6 +117,41 @@ top-1 成为建议，其余在 `detail` 模式中展示。
仅 1 条命中时不展示候选段。
+### 旅程模式
+
+`/pace-next journey` 从"下一步做什么"升级为"从当前到目标的完整路径"。渲染分步旅程视图，标记已完成步骤、当前位置和待做步骤——纯建议性，不自动执行任何操作。
+
+**旅程模板**：
+
+| 模板 | 编排路径 | 适用场景 |
+|------|---------|---------|
+| `new-feature` | biz discover → decompose → plan next → dev → review → merged | 从零开始交付一个功能 |
+| `iteration` | plan next → [dev → review → merged]* → plan close → retro | 完整迭代循环 |
+| `hotfix` | feedback report → dev → review → release deploy | 紧急修复 |
+| `release` | release create → deploy → verify → close | 标准发布 |
+| `onboarding` | init → dev(第一个功能) → review → merged | 新用户首次体验 |
+
+不指定模板名时，根据项目状态自动选择（例如：无 CR 的新项目 → `onboarding`；有活跃迭代 → `iteration`）。
+
+**输出示例**：
+
+```
+旅程：iteration — 完成当前迭代循环
+
+✅ 规划迭代 — 纳入 3 个功能点
+✅ 开发 PF-001 — "OAuth 集成"已合并
+👉 开发 PF-002 — 说"帮我实现 [功能名]"或 /pace-dev
+⏳ 审批 — /pace-review
+⏳ 迭代回顾 — /pace-retro
+
+进度：2/5 步完成
+```
+
+**核心规则**：
+- **只展示不执行**——展示路径，不自动触发任何 Skill
+- **无状态文件**——不持久化旅程状态，每次调用从 `.devpace/` 动态推断
+- **与默认模式互补**——journey 展示全局路径，默认模式推荐单步行动
+
## 使用场景
### 场景 1：开始新会话——先做什么？
@@ -186,6 +223,7 @@ Claude: 💡 建议：MoS 达成率 82%——回顾业务成效指标
- [SKILL.md](../../skills/pace-next/SKILL.md) — Skill 定义、输入/输出和高层流程
- [next-procedures.md](../../skills/pace-next/next-procedures.md) — 详细决策算法、输出格式和角色适配规则
+- [next-procedures-journey.md](../../skills/pace-next/next-procedures-journey.md) — 旅程编排模板、自动选择逻辑和输出格式
- [signal-priority.md](../../knowledge/signal-priority.md) — 信号定义和优先级分组（SSOT）
- [signal-collection.md](../../knowledge/signal-collection.md) — 共享信号采集规程
- [User Guide](../user-guide_zh.md) — 所有命令的快速参考
diff --git a/docs/features/pace-sync.md b/docs/features/pace-sync.md
index 59c87d1..8df38d4 100644
--- a/docs/features/pace-sync.md
+++ b/docs/features/pace-sync.md
@@ -139,6 +139,30 @@ Reads all association records, compares devpace vs external state, and outputs a
| CR-005 | #18 | merged | open | ❌ push | 02-24 15:00 |
```
+### `ci status`
+
+View recent CI/CD run status for the current branch.
+
+**Syntax**: `/pace-sync ci status`
+
+Queries GitHub Actions via `gh run list` and presents the last 5 runs with pass/fail summary. Can serve as an enhanced data source for Gate 4 CI checks. See [sync-procedures-ci.md](../../skills/pace-sync/sync-procedures-ci.md) for detailed steps.
+
+### `ci trigger`
+
+Manually trigger a GitHub Actions workflow.
+
+**Syntax**: `/pace-sync ci trigger [workflow-name]`
+
+Without arguments, lists available workflows. With a workflow name, triggers it on the current branch (with user confirmation). See [sync-procedures-ci.md](../../skills/pace-sync/sync-procedures-ci.md) for detailed steps.
+
+### `ci logs`
+
+View log summary for a specific CI run.
+
+**Syntax**: `/pace-sync ci logs [run-id]`
+
+Displays failed step logs by default. Without a run-id, automatically selects the most recent run. See [sync-procedures-ci.md](../../skills/pace-sync/sync-procedures-ci.md) for detailed steps.
+
## State Mapping
devpace CR states map to GitHub labels (e.g., `developing` → `in-progress`, `merged` → close Issue + `done`). The full mapping table is defined in [sync-mapping-format.md](../../knowledge/_schema/sync-mapping-format.md) (schema authority) and [sync-adapter-github.md](../../skills/pace-sync/sync-adapter-github.md) (GitHub-specific operations).
@@ -240,6 +264,7 @@ Traditional integrations map "field A → field B" mechanically. devpace takes a
┌──────────────────────────────────────┐
│ pace-sync Skill Layer │
│ setup/link/push/pull/unlink/create/ │
+│ ci status/ci trigger/ci logs/ │
├──────────────────────────────────────┤
│ Operation Orchestration │
│ sync-procedures-*.md │
diff --git a/docs/features/pace-sync_zh.md b/docs/features/pace-sync_zh.md
index c3f9d06..72feb42 100644
--- a/docs/features/pace-sync_zh.md
+++ b/docs/features/pace-sync_zh.md
@@ -119,6 +119,30 @@ CR-003 状态不一致：
| CR-005 | #18 | merged | open | ❌ 需推送 | 02-24 15:00 |
```
+### `ci status`
+
+查看当前分支最近的 CI/CD 运行状态。
+
+**语法**：`/pace-sync ci status`
+
+通过 `gh run list` 查询 GitHub Actions，展示最近 5 次运行及通过率摘要。可作为 Gate 4 CI 检查的增强数据源。详细步骤见 [sync-procedures-ci.md](../../skills/pace-sync/sync-procedures-ci.md)。
+
+### `ci trigger`
+
+手动触发 GitHub Actions workflow。
+
+**语法**：`/pace-sync ci trigger [workflow 名]`
+
+无参数时列出可用 workflow。指定 workflow 名时在当前分支上触发（需用户确认）。详细步骤见 [sync-procedures-ci.md](../../skills/pace-sync/sync-procedures-ci.md)。
+
+### `ci logs`
+
+查看指定 CI 运行的日志摘要。
+
+**语法**：`/pace-sync ci logs [run-id]`
+
+默认显示失败步骤日志。不指定 run-id 时自动选取最近一次运行。详细步骤见 [sync-procedures-ci.md](../../skills/pace-sync/sync-procedures-ci.md)。
+
## 状态映射
devpace CR 状态与 GitHub 标签对应（如 `developing` → `in-progress`，`merged` → 关闭 Issue + `done`）。完整映射表定义于 [sync-mapping-format.md](../../knowledge/_schema/sync-mapping-format.md)（Schema 权威源）和 [sync-adapter-github.md](../../skills/pace-sync/sync-adapter-github.md)（GitHub 特有操作）。
@@ -220,7 +244,7 @@ Claude: | CR | 外部链接 | devpace | 外部状态 | 一致 | 最
┌──────────────────────────────────────────┐
│ pace-sync Skill 层 │
│ setup / link / push / pull / unlink / │
-│ create / status │
+│ create / status / ci │
├──────────────────────────────────────────┤
│ 语义桥接层（核心价值） │
│ 意图映射 + 冲突检测 + 适配器路由 │
diff --git a/docs/planning/progress.md b/docs/planning/progress.md
index 619ac82..3d93c5d 100644
--- a/docs/planning/progress.md
+++ b/docs/planning/progress.md
@@ -18,15 +18,15 @@
| 维度 | 值 |
|------|---|
-| 版本 | **v1.6.1** Quality Evaluation & Developer Experience（已发布 2026-03-07） |
-| 当前阶段 | **Phase 18 ✅ 完成**（M18.1 ✅ M18.2 ✅ M18.3 ✅） |
-| 当前里程碑 | Phase 18 全部完成，Phase 19 待开始 |
-| 任务进度 | **116/120**（T120 ✅，T108-T111 待做） |
-| 场景覆盖 | 34/34 用户场景 · 72/72 功能需求 |
-| 基础设施 | LICENSE ✅ · README ✅ · CONTRIBUTING ✅ · CHANGELOG ✅ · 用户指南 ✅ · 示例项目 ✅ · Hook Node.js ✅ · Agent 角色 ✅ · Model Tiering ✅ · CSO 审计 ✅ · 迁移验证 ✅ · Agent Memory ✅ · Async Hook ✅ · prompt Hook ✅ · Output Style ✅ · skill-creator 三层评估 ✅ · 18/18 Skill eval 覆盖 ✅ |
+| 版本 | **v1.6.2** + BR 上游域建模（feature 分支，未发布） |
+| 当前阶段 | **Phase 23 ✅ 完成**（M23.1-M23.4 全部关闭）→ **Phase 24 待开始** |
+| 当前里程碑 | Phase 23 完成，Phase 24 M24.1（devpace-cadence MVP）待开始 |
+| 任务进度 | **127/131**（T129-T131 ✅，T122 待做，T108-T111 待做） |
+| 场景覆盖 | 42/42 用户场景（S35-S42 验收通过）· 90/90 功能需求 |
+| 基础设施 | LICENSE ✅ · README ✅ · CONTRIBUTING ✅ · CHANGELOG ✅ · 用户指南 ✅ · 示例项目 ✅ · Hook Node.js ✅ · Agent 角色 ✅ · Model Tiering ✅ · CSO 审计 ✅ · 迁移验证 ✅ · Agent Memory ✅ · Async Hook ✅ · prompt Hook ✅ · Output Style ✅ · skill-creator 三层评估 ✅ · 19/19 Skill eval 覆盖 ✅ |
| 阻塞项 | 无 |
-| 下一步 | 1) Phase 19 智能推送 2) 聚合平台注册 |
-| 最后更新 | 2026-03-07 |
+| 下一步 | 1) Phase 24 devpace-cadence MVP（独立仓库） 2) Phase 19 智能推送 3) T122 pace-biz 实战验证 |
+| 最后更新 | 2026-03-08 |
## 当前任务
@@ -163,6 +163,10 @@
| | **Phase 18 — 外部同步 MVP** | | | | |
| T106 | pace-sync 产品优化 16 项（Wave 1-4） | M18.2 | OBJ-1, OBJ-12, F11.1-F11.14 | ✅ 完成 | 13 文件 310 行增量。Wave 1：C1 标签预创建 + A1 语义 Comment + B1 unlink + B2 dry-run。Wave 2：D1 status 同步摘要 + D3 change 同步提醒 + B3 create 子命令 + B4 Gate 同步规程。Wave 3：D4 教学触发 + D5 pulse 同步滞后信号 + C2 限流保护 + C3 Issue 状态检查 + A2 副产物非前置三阶段。Wave 4：A3 入站轮询架构设计。Roadmap Phase 18/19/20 修订 + design §19 更新 + 附录 B 架构图追加。223 pytest + markdownlint + 层隔离全通过 |
| T107 | M18.3 Hook + Rules + 语义同步集成 | M18.3 | OBJ-1, OBJ-12, F11.8, F11.13 | ✅ 完成 | 7 文件变更：utils.mjs 缓存工具（+readSyncStateCache/updateSyncStateCache）+ sync-push.mjs 重写（缓存比对+merged 指令分级）+ post-cr-update.mjs 7 步管道对齐 §11（+条件第 7 步外部同步）+ test_hooks.py（sync-push 注册+TC-HK-16）+ rules §16 三处文案精炼 + feature docs 双层保障 section。224 pytest + markdownlint + 层隔离 + plugin 加载全通过 |
+| | **Phase 21 — BR 上游业务规划域** | | | | |
+| T121 | BR 上游域建模：Schema + Skill + 增强 + 文档 | M21.1-M21.4 | OBJ-1, OBJ-4, OBJ-6, S35-S39, F12.1-F12.11 | ✅ 完成 | M21.1-M21.5 全部完成。28 文件 +1180 行。S35-S39 验收通过。特性文档双语+eval 覆盖 |
+| T122 | Phase 21 后续：pace-biz 实战验证 | M21.4 | OBJ-1, OBJ-9, S35-S39 | 待做 | 端到端场景验证（user-guide 已更新） |
+| T123 | pace-biz 需求阶段增强：discover/import/infer | M21.5 | OBJ-1, OBJ-4, OBJ-6, S40-S42, F12.12-F12.17 | ✅ 完成 | 3 procedures + SKILL.md + rules/knowledge + 特性文档双语 + 规划文档 + eval。S40-S42 验收通过 |
| T108 | Phase 19 M19.1 智能推送 + Gate 同步 | M19.1 | OBJ-1, OBJ-12, F11.12 | 待做 | auto-create+auto-link + Gate Comment/Label + 教学+pulse |
| T109 | Phase 19 M19.2 Issue 生命周期 | M19.2 | OBJ-12, F11.11 | 待做 | create 端到端 + PR 关联 + 治理集成 |
| T110 | Phase 19 M19.3 多平台预研 | M19.3 | OBJ-17 | 待做 | Linear 原型适配器 |
@@ -170,6 +174,16 @@
| | **产品层跟踪优化** | | | | |
| T112 | P1 组：PF 溢出模式 + 反向追溯 + 业务 pulse + 版本化 | -- | OBJ-1, OBJ-4, OBJ-6 | ✅ 完成 | A0-A3 详见变更记录 |
| T113 | P2 组：MoS 量化 + PF 依赖 + Release 业务影响 + 优先级 + 文档 | -- | OBJ-1, OBJ-5, OBJ-6, OBJ-9 | ✅ 完成 | B2-B8 详见变更记录 |
+| | **Phase 22 — 体验增强与紧耦合治理** | | | | |
+| T124 | Skill 间接口契约层：review↔test 输出格式 Schema 化 | M22.1 | OBJ-3, G2 | ✅ 完成 | accept-report-contract.md 共享契约 + review-procedures-gate.md 改引用契约 |
+| T125 | Skill 间接口契约层：dev↔guard/test/change↔plan 引用解耦 | M22.1 | OBJ-3, G2 | ✅ 完成 | 4 耦合点解耦：dev→guard(risk-format.md) + dev→test(test-strategy-format.md) + change→plan(委托/pace-plan) + skill-dependencies.md 更新 |
+| T126 | 首次推进引导 + 无命令体验增强 | M22.2 | OBJ-5, UX1, UX3 | ✅ 完成 | pace-init 情境化引导（有代码→infer，空项目→discover，有文档→dev）+ rules §3 无命令体验映射表 |
+| T127 | ADR 管理：pace-trace arch 子命令 | M22.3 | OBJ-4, G3 | ✅ 完成 | adr-format.md Schema + trace-procedures-arch.md + pace-trace SKILL.md 更新 |
+| T128 | 技术债务一等公民化 | M22.4 | OBJ-3, G4 | ✅ 完成 | cr-format tech-debt 类型 + project-format tech-debt-budget 配置 + retro 技术债务趋势段 |
+| | **Phase 23 — 预测与安全** | | | | |
+| T129 | pace-retro forecast 子命令 | M23.1 | OBJ-1, D1 | ✅ 完成 | retro-procedures-forecast.md（交付概率算法+瓶颈识别+风险预警）+ SKILL.md 更新 |
+| T130 | 安全维度深化 + Compact 恢复优化 | M23.2-M23.3 | OBJ-2, OBJ-3, G5, UX4 | ✅ 完成 | guard-procedures-scan.md 安全深度检查（Layer 1 关键词 + Layer 2 OWASP 6 类）+ pre-compact.sh 结构化恢复上下文 |
+| T131 | 语义漂移检测增强 | M23.4 | OBJ-3, D2 | ✅ 完成 | dev-procedures-developing.md 语义漂移检测（持续验收对齐）+ review-procedures-gate.md 语义一致性评分（🟢/🟡/🔴） |
| T114 | A4：6 个核心 Skill 特性文档 | -- | OBJ-9, OBJ-10 | ✅ 完成 | pace-dev(177 行) + pace-status(221 行) + pace-change(214 行) + pace-review(158 行) + pace-test(260 行) + pace-release(264 行)。共 1294 行。224 pytest + 83 markdownlint + 层隔离 + plugin 加载全通过 |
| | **pace-plan UX 优化与功能增强** | | | | |
| T115 | P0 组：空树引导 + 智能建议 | -- | OBJ-1, OBJ-8, S15, F3.5 | ✅ 完成 | E1 空功能树引导式规划（Step 3.1 降级分支）+ E2 Plan Proposal 智能建议（Step 3.6 改造为建议+确认模式） |
@@ -195,11 +209,15 @@
| D7 | pace-release 从"被动追踪"演进为"主动编排" | 2026-02-22 | 开源生态调研 10 项目对标（Changesets/Release Please/git-cliff/Nx/release-it 等），devpace 拥有比 commit 消息更丰富的 CR 元数据 | design.md §14 重写 + release-format 增加 rolled_back + integrations-format 增加版本管理 |
| D8 | Risk Fabric 采用"专属入口 + 嵌入式智能"双路径 | 2026-02-25 | 用户痛点"AI 不够主动"——需要预判→监控→趋势完整闭环；风险状态机独立于 CR 状态机（不增加 CR 复杂度） | 新增 /pace-guard Skill + risk-format Schema + 3 处嵌入集成 + Rules §10 风险感知 |
| D9 | PF 溢出模式（Overflow Pattern）+ BR/OBJ 保持内联 | 2026-02-26 | PF 信息量增长后 project.md 职责混乱（全景图+详细说明书）；BR（2-5 个/项目）和 OBJ（1-3 个）信息量不足以支撑独立文件 | pf-format.md 新 Schema + project-format 溢出规则 + /pace-status trace 反向追溯 + design §3 存储演变第三阶段 |
+| D10 | BR 上游域建模：Epic 始终独立文件 + BR 溢出模式 + Opportunity 独立看板 + /pace-biz 统一入口 | 2026-03-07 | BR 上游空白（仅 ID+一行标题）无法兑现"业务→技术端到端追溯"承诺。Epic 内容量大（MoS+背景+BR 列表=10-30 行）值得始终独立；BR 类 PF 溢出模式平衡轻量与丰富；Opportunity 操作性追踪不污染战略全景图 | 3 新 Schema + /pace-biz（8 子命令）+ 9 Skill 增强 + S16/S17 信号 |
+| D11 | BizDevOps 审查 v2 战略方向："深度优于广度 + 契约优于内联 + 验证优于新增"。不新增 Skill，所有改进通过扩展现有 Skill 子命令实现。Skill 间紧耦合是最大维护性风险，Phase 22 最高优先级 | 2026-03-08 | 19 Skills 已到认知极限。skill-dependencies.md 揭示高风险耦合（review↔test、dev↔guard）。Phase 22-24 规划遵循"不膨胀"原则 | Phase 22-24 战略规划 + G2 紧耦合治理为 P0 |
## 变更记录
| 日期 | 变更 | 原因 |
|------|------|------|
+| 2026-03-08 | BizDevOps 全生命周期审查 v2 落地（Phase A）：Phase 21 全部完成（M21.4+M21.5 关闭，S35-S42 验收通过）。审查文档存档（docs/plans/bizdevops-review-v2.md）。新增 Phase 22-24 战略规划（体验增强+紧耦合治理→预测与安全→可视化与企业级）。新增 T124-T131 任务。358 pytest 全通过 | BizDevOps 全生命周期审查：6 缺口（G1-G6）+ 5 UX 改进 + 5 差异化创新 |
+| 2026-03-07 | Phase 21 BR 上游业务规划域建模：3 新 Schema（epic-format/br-format/opportunity-format）+ /pace-biz Skill（8 子命令 + 8 procedures）+ project-format 增强（愿景/战略/OBJ 产品维度/Epic 链接/BR 溢出）+ theory §3/§12 + design §3 概念模型重构 + 9 个 Skill 增强 + S16/S17 信号 + devpace-rules 更新 + 特性文档双语 + requirements S35-S42 F12 + roadmap Phase 21 + eval 覆盖。28 文件 +1180 行，346 pytest 全通过 | BR 上游空白无法兑现端到端追溯核心承诺 |
| 2026-03-07 | v1.6.1 发布（Quality Evaluation & Developer Experience）：CHANGELOG v1.6.1 + 版本号更新（state-format/state.md 模板/plugin.json/marketplace.json）+ 迁移链更新（v1.6.0→v1.6.1 §5）+ 测试修复（*-workspace/ 排除：conftest helper + 3 测试 + markdownlint ignores + validate-all.sh grep --exclude-dir + init-procedures-core.md 尾部空行 MD012）。CI release workflow 通过，GitHub Release + tar.gz 创建成功 | v1.6.1 patch 发布——14 commit 累积变更（评估基础设施+pace-init 优化+Hook 性能） |
| 2026-03-07 | 会话结束 | -- |
| 2026-02-28 | T120 /pace-next 深度优化 18 项（功能×6 + 体验×7 + 架构×5）：架构基础——signal-priority.md 统一信号权威源（5 组 16 级 SSOT，替代三处独立矩阵）+ signal-collection.md 共享采集规程（9 数据源+价值链上下文采集+缓存机制设计）。核心重写——next-procedures.md 完全重构（分组优先级+风险信号 S2/S6+价值链模板+多 CR 排序+时间维度 S7+同步滞后 S11+经验标签匹配 8 类+why 推理链+角色重排序+session-start 去重）。SKILL.md 增加 why 参数+三层透明输出。联动更新——status-procedures-overview.md 改为引用 signal-priority.md SSOT（候选计数引导）+ devpace-rules.md §0 速查追加导航行+§11 第 5 步 merged 回路建议+全局导航集成段落（推/拉定位+去重+session-end 建议）。文档——特性文档双语（pace-next.md+pace-next_zh.md）+ requirements.md S27 验收 5/5 + F8.4-F8.7 新增。8 文件变更+4 文件新建。227 pytest + 157 markdownlint + 层隔离 + plugin 加载全通过 | /pace-next 深度分析方案实施——S27 验收标准全部勾选+SSOT 修复+价值链感知升级 |
@@ -289,25 +307,39 @@
> 保留最近 5 条，超出时删除最旧记录。
+### 2026-03-08 — BizDevOps 全生命周期审查 v2（Phase A 立即）
+
+- **完成**：Phase 21 全部关闭（M21.4+M21.5 ✅，S35-S42 验收通过）。审查文档存档 docs/plans/bizdevops-review-v2.md（7 部分：覆盖矩阵+缺口分析 G1-G6+UX 分析 UX1-UX5+差异化建议 D1-D5+优先级路线图+战略建议+风险）。新增 Phase 22-24 战略规划到 roadmap.md。新增 T124-T131 任务。D11 战略决策记录。358 pytest 全通过
+- **决策**：D11 "深度优于广度+契约优于内联+验证优于新增"。不新增 Skill，Skill 间紧耦合是 P0 治理目标
+- **未完成**：Phase B-D 待后续阶段实施
+- **下次建议**：1) Phase 22 M22.1 Skill 间接口契约层 2) Phase 19 智能推送 3) T122 pace-biz 实战验证
+
+### 2026-03-07 — Phase 21 BR 上游业务规划域建模
+
+- **完成**：Phase 21 M21.1-M21.3 全部完成。新增 3 Schema + /pace-biz Skill（8 子命令 + 8 procedures）+ 9 个 Skill 增强 + 特性文档双语 + eval 覆盖。28 文件 +1180 行。346 pytest 全通过
+- **决策**：Epic 始终独立文件 + BR 溢出模式 + Opportunity 独立看板 + 双路径保持
+- **未完成**：无（M21.4-M21.5 在后续会话完成）
+- **下次建议**：Phase 22 或 Phase 19
+
### 2026-03-07 — v1.6.1 发布
-- **完成**：v1.6.1 patch 发布。CHANGELOG 编写 + 版本号更新（state-format L52/L57 + state.md 模板 + plugin.json + marketplace.json）+ 迁移链更新（init-procedures-migration.md §5 新增 v1.6.0→v1.6.1）+ 测试修复 5 处（conftest `_is_workspace_path` helper + test_layer_separation/test_naming_conventions/test_template_placeholders 排除 workspace + markdownlint ignores + validate-all.sh grep --exclude-dir + init-procedures-core.md 尾部空行）。`bash scripts/bump-version.sh 1.6.1` + `bash scripts/validate-all.sh` 全绿 + git tag v1.6.1 + push origin main + push tag。CI Release workflow 两 job 全通过（Pre-release Validation 12s + Create Release 6s），GitHub Release 含 devpace-1.6.1.tar.gz
+- **完成**：v1.6.1 patch 发布。CHANGELOG + 版本号更新 + 迁移链 + 测试修复。CI Release workflow 通过
- **未完成**：无
-- **下次建议**：1) Phase 19 智能推送 2) 聚合平台注册
+- **下次建议**：Phase 19 智能推送
### 2026-02-26 — T107 M18.3 Hook+Rules+语义同步集成
-- **完成**：7 文件变更。utils.mjs +缓存工具（readSyncStateCache/updateSyncStateCache）+ sync-push.mjs 重写（缓存比对+merged 指令分级）+ post-cr-update.mjs 7 步管道对齐 §11（+条件第 7 步）+ test_hooks.py（sync-push 注册+TC-HK-16）+ rules §16 三处文案 + feature docs 双层保障。M18.3 完成，Phase 18 全部关闭
-- **决策**：状态缓存采用纯文本 `.devpace/.sync-state-cache`（不入 git），与 pulse-counter 的 `.pulse-count` 先例一致
+- **完成**：7 文件变更。sync-push.mjs 缓存比对 + post-cr-update.mjs 7 步管道 + rules §16 精炼。M18.3 完成，Phase 18 全部关闭
+- **决策**：状态缓存纯文本 `.devpace/.sync-state-cache`
- **未完成**：无
-- **下次建议**：1) v1.5.0 版本发布 2) Phase 19 智能推送 3) 聚合平台注册
+- **下次建议**：版本发布 / Phase 19
### 2026-02-26 — /pace-init 综合优化 14 项
-- **完成**：14 项优化实施（OPT-1~8 优化 + NEW-1~6 新增）。3 文件重写：SKILL.md（生命周期感知 3 阶段 + 4 新子命令 + --from 增强 + full 分阶段 + CLAUDE.md 合并 + 引导优化）+ init-procedures.md（信号检测算法 + 阶段策略 + 工具链精准检测 4 技术栈 + 迁移框架 + context.md 阈值调优 + 6 新规程）+ claude-md-devpace.md 模板标记。223 pytest + markdownlint + 层隔离 + plugin 加载全通过
-- **决策**：生命周期检测采用信号组合判定（git commit/tags/部署配置/源文件数），不暴露阶段标签给用户
+- **完成**：SKILL.md 生命周期感知 3 阶段 + 4 新子命令 + init-procedures 重写。223 pytest 全通过
+- **决策**：生命周期检测采用信号组合判定
- **未完成**：无
-- **下次建议**：1) M18.3 Hook+语义集成 2) 版本发布 3) Phase 19
+- **下次建议**：M18.3 Hook 集成
## 遗留事项
diff --git a/docs/planning/requirements.md b/docs/planning/requirements.md
index e5e336b..0a80cc9 100644
--- a/docs/planning/requirements.md
+++ b/docs/planning/requirements.md
@@ -569,6 +569,121 @@
| F11.13 | merged 自动 push 闭环 | S34 | P1 |
| F11.14 | 轮询式入站感知（会话开始拉取外部变更） | — | P3 |
+### S35：业务机会捕获
+
+**角色**：产品经理/业务方
+**场景**：收到客户反馈、竞品动态或内部洞察，想记录下来以便后续评估
+**期望**：快速记录机会到看板，自动分类来源
+
+**验收标准**：
+- [x] `/pace-biz opportunity` 创建 OPP 条目到 opportunities.md
+- [x] 自动推断来源类型（用户反馈/竞品观察/技术发现/市场趋势/内部洞察）
+- [x] 支持后续评估和转化为 Epic
+
+### S36：专题创建与管理
+
+**角色**：产品经理
+**场景**：评估业务机会后决定立项，需要创建专题（Epic）组织相关需求
+**期望**：从 Opportunity 转化或直接创建 Epic，定义成效指标
+
+**验收标准**：
+- [x] `/pace-biz epic` 创建 epics/EPIC-xxx.md 独立文件
+- [x] 关联 OBJ 和 Opportunity（如有）
+- [x] 引导定义背景和 MoS
+- [x] 自动更新 project.md 价值功能树
+
+### S37：需求分解
+
+**角色**：产品经理/开发者
+**场景**：已有 Epic 或 BR，需要分解为更细粒度的需求或功能
+**期望**：Claude 建议分解方案，用户确认后自动创建
+
+**验收标准**：
+- [x] `/pace-biz decompose EPIC-xxx` 分解 Epic 为 BR 列表
+- [x] `/pace-biz decompose BR-xxx` 分解 BR 为 PF 列表
+- [x] Claude 提供建议分解方案（含优先级建议）
+- [x] 用户确认后自动更新所有关联文件
+
+### S38：战略对齐检查
+
+**角色**：产品经理/业务方
+**场景**：想检查当前需求是否覆盖所有业务目标，有没有孤立的需求
+**期望**：生成对齐度报告，发现覆盖缺口和孤立实体
+
+**验收标准**：
+- [x] `/pace-biz align` 只读分析 OBJ→Epic→BR 对齐度
+- [x] 报告 OBJ 覆盖率、孤立实体、MoS 完整性
+- [x] 向后兼容（无 Epic 时检查 OBJ→BR 对齐）
+
+### S39：业务全景查看
+
+**角色**：所有角色
+**场景**：想快速了解从业务机会到开发进度的完整价值流
+**期望**：一目了然地看到 OPP→EPIC→BR→PF→CR 全景
+
+**验收标准**：
+- [x] `/pace-biz view` 展示完整价值流视图
+- [x] 统计各层实体数量和状态分布
+- [x] 向后兼容（无 Epic/Opportunity 时退化为 OBJ→BR→PF→CR 视图）
+
+### S40：探索式需求发现
+
+**角色**：产品经理、开发者
+**场景**：只有一个模糊想法（"我想做一个智能客服系统"），需要从零开始交互式梳理需求
+**期望**：通过多轮对话引导，产出结构化的 OPP→Epic→BR→PF 候选树
+
+**验收标准**：
+- [x] `/pace-biz discover` 启动多轮引导对话（目标→头脑风暴→边界→确认）
+- [x] 中间状态持久化到 scope-discovery.md，支持跨会话继续
+- [x] 确认后写入 .devpace/（OPP + Epic + BR + PF）
+- [x] 降级模式：无 .devpace/ 时输出到控制台
+
+### S41：多源需求导入
+
+**角色**：产品经理、开发者
+**场景**：散落在会议纪要、用户反馈、竞品分析中的需求，需要批量提取并整合到功能树
+**期望**：读取文档 → 自动分类提取 → 去重合并 → 用户确认后写入
+
+**验收标准**：
+- [x] `/pace-biz import` 接受文件路径/目录，自动检测源类型
+- [x] 合并分析：NEW/DUPLICATE/ENRICHMENT/CONFLICT 四分类
+- [x] 用户确认后增量写入 project.md 功能树
+- [x] 降级模式：project.md 为桩时跳过合并分析
+
+### S42：代码库需求推断
+
+**角色**：开发者
+**场景**：遗留项目接入或功能树滞后，需要从代码反向推断已有功能和技术债务
+**期望**：扫描代码结构 + TODO 注释 + Git 信号，产出差距报告
+
+**验收标准**：
+- [x] `/pace-biz infer` 扫描源码目录、注释、Git 热点
+- [x] 三段式报告：未追踪功能 + 未实现功能 + 技术债务
+- [x] 用户选择后写入功能树，技术债务 PF 标记后缀
+- [x] 降级模式：无 Git 时退化为目录+注释扫描
+
+### F12：业务规划管理
+
+| ID | 功能 | 对应场景 | 优先级 |
+|----|------|---------|:------:|
+| F12.1 | /pace-biz opportunity：业务机会捕获 | S35 | P1 |
+| F12.2 | /pace-biz epic：专题创建与管理 | S36 | P1 |
+| F12.3 | /pace-biz decompose：需求分解（Epic→BR, BR→PF） | S37 | P1 |
+| F12.4 | /pace-biz align：战略对齐检查 | S38 | P2 |
+| F12.5 | /pace-biz view：业务全景视图 | S39 | P2 |
+| F12.6 | Epic 独立文件管理（epics/EPIC-xxx.md） | S36 | P1 |
+| F12.7 | BR 溢出模式（requirements/BR-xxx.md） | S37 | P1 |
+| F12.8 | Opportunity 看板（opportunities.md） | S35 | P1 |
+| F12.9 | project.md 愿景/战略上下文 section | S36 | P2 |
+| F12.10 | OBJ 产品维度属性（business/product/tech） | S36 | P2 |
+| F12.11 | Epic/OPP 信号采集（S16/S17） | S35, S36 | P2 |
+| F12.12 | /pace-biz discover：交互式需求发现（多轮对话→候选树） | S40 | P1 |
+| F12.13 | /pace-biz import：多源文档导入（自动检测+合并分析） | S41 | P1 |
+| F12.14 | /pace-biz infer：代码库推断（结构分析+信号挖掘+差距报告） | S42 | P2 |
+| F12.15 | discover 会话持久化（scope-discovery.md 跨会话） | S40 | P1 |
+| F12.16 | import 源类型自动检测（会议纪要/反馈/竞品/技术债务/Issue） | S41 | P1 |
+| F12.17 | infer Git 增强分析（热点/共变/贡献者） | S42 | P2 |
+
## 非功能需求
| ID | 需求 | 标准 |
diff --git a/docs/planning/roadmap.md b/docs/planning/roadmap.md
index 146b37c..e7e7afd 100644
--- a/docs/planning/roadmap.md
+++ b/docs/planning/roadmap.md
@@ -39,6 +39,10 @@
| Phase 18 | 外部同步 MVP | 手动同步 + GitHub MVP（pace-sync setup/link/push/status） | ✅ 完成 |
| Phase 19 | 自动推送与多平台 | 自动推送 + 治理集成 + Linear/Jira 扩展 | 待开始 |
| Phase 20 | 双向同步与 AI 冲突 | 入站事件 + 冲突检测 + AI 解决 | 待开始 |
+| Phase 21 | BR 上游业务规划域 | Opportunity/Epic/BR 溢出 + /pace-biz Skill + 端到端追溯 | ✅ 完成 |
+| Phase 22 | 体验增强与紧耦合治理 | Skill 间接口契约 + ADR 管理 + 技术债务一等公民 + 首推引导 | ✅ 完成 |
+| Phase 23 | 预测与安全 | 预测性项目管理 + 安全维度 + Compact 恢复 + 语义漂移检测 | ✅ 完成 |
+| Phase 24 | 可视化与企业级 | devpace-cadence MVP + 多项目组合管理 | 待开始 |
---
@@ -573,12 +577,118 @@
---
+## Phase 21：BR 上游业务规划域
+
+**目标**：补齐 BR 上游的业务规划域——从业务机会到专题（Epic）到业务需求的完整价值流建模，实现端到端追溯。
+
+**对应 OBJ**：OBJ-1, OBJ-4, OBJ-6
+
+### 里程碑
+
+| # | 里程碑 | 状态 | 产出 |
+|---|--------|------|------|
+| M21.1 | 概念模型和 Schema 基础 | ✅ 完成 | epic-format.md + br-format.md + opportunity-format.md + project-format.md 增强 + theory.md/design.md §3 更新 |
+| M21.2 | 核心 Skill 和增强 | ✅ 完成 | /pace-biz（8 子命令）+ pace-init/change/status/plan 增强 |
+| M21.3 | 追溯和信号 | ✅ 完成 | pace-trace/retro/next/dev/release 增强 + S16/S17 信号 |
+| M21.4 | 文档和测试 | ✅ 完成 | 特性文档双语 + requirements S35-S42 验收 + roadmap + eval 覆盖 |
+| M21.5 | 需求阶段增强（discover/import/infer） | ✅ 完成 | 3 个新子命令 procedures + SKILL.md 更新 + 信号/规则/文档同步 |
+
+---
+
+## Phase 22：体验增强与紧耦合治理
+
+**目标**：解耦 Skill 间紧耦合（接口契约层）、新增 ADR 管理、技术债务一等公民化、首次推进引导增强。
+
+**对应 OBJ**：OBJ-1, OBJ-3, OBJ-4, OBJ-5
+
+**前置条件**：Phase 21 完成
+
+### 里程碑
+
+| # | 里程碑 | 状态 | 产出 |
+|---|--------|------|------|
+| M22.1 | Skill 间接口契约层 | ✅ 完成 | accept-report-contract.md + risk-format/test-strategy-format 契约引用 + 命令委托模式 + skill-dependencies.md 风险降级 |
+| M22.2 | 首次推进引导 + 无命令体验 | ✅ 完成 | pace-init 情境化引导（有代码/空项目/有文档）+ rules §3 无命令体验映射表 |
+| M22.3 | ADR 管理 | ✅ 完成 | pace-trace arch 子命令 + adr-format.md Schema + trace-procedures-arch.md |
+| M22.4 | 技术债务一等公民化 | ✅ 完成 | cr-format tech-debt 类型 + project-format tech-debt-budget 配置 + retro 技术债务趋势段 |
+
+### 任务定义
+
+| 任务 | 关联里程碑 | 关联条目 |
+|------|----------|---------|
+| 接口契约层设计：review↔test 输出格式 Schema 化 | M22.1 | OBJ-3, G2 |
+| 接口契约层设计：dev↔guard/test procedures 引用解耦 | M22.1 | OBJ-3, G2 |
+| 接口契约层设计：change↔plan 逻辑分离 | M22.1 | OBJ-4, G2 |
+| pace-init 完成后衔接引导（自动触发 pace-biz infer） | M22.2 | OBJ-5, UX3 |
+| 自然语言触发覆盖面扩展 | M22.2 | OBJ-5, UX1 |
+| pace-trace arch 子命令 + adr-format Schema | M22.3 | OBJ-4, G3 |
+| CR type tech-debt 扩展 + pace-plan 容量预留 | M22.4 | OBJ-3, G4 |
+| pace-retro 技术债务趋势指标 | M22.4 | OBJ-3, G4 |
+
+---
+
+## Phase 23：预测与安全
+
+**目标**：AI 驱动的预测性项目管理、安全维度增强、Compact 恢复优化、语义级漂移检测。
+
+**对应 OBJ**：OBJ-1, OBJ-2, OBJ-3
+
+**前置条件**：Phase 22 完成
+
+### 里程碑
+
+| # | 里程碑 | 状态 | 产出 |
+|---|--------|------|------|
+| M23.1 | 预测性项目管理 | ✅ 完成 | retro-procedures-forecast.md（交付概率算法+瓶颈识别+风险预警+概率分级） |
+| M23.2 | 安全维度深化 | ✅ 完成 | guard-procedures-scan.md 安全深度检查（Layer 1 关键词扩展 + Layer 2 OWASP 6 类模式扫描） |
+| M23.3 | Compact 恢复优化 | ✅ 完成 | pre-compact.sh 结构化恢复上下文（IR-1~5 + 当前状态 + 活跃 CR + 行动清单） |
+| M23.4 | 语义漂移检测 | ✅ 完成 | dev-procedures 语义漂移检测（持续验收对齐）+ review-procedures 语义一致性评分（M/L/XL 摘要模板） |
+
+### 任务定义
+
+| 任务 | 关联里程碑 | 关联条目 |
+|------|----------|---------|
+| pace-retro forecast 子命令（历史模式→交付概率） | M23.1 | OBJ-1, D1 |
+| pace-guard scan 安全维度（第 6 维） | M23.2 | OBJ-3, G5 |
+| PreCompact Hook 状态快照增强 | M23.3 | OBJ-2, UX4 |
+| compact 后最小恢复上下文（IR-1~5 + 当前 CR + 下一步） | M23.3 | OBJ-2, UX4 |
+| pace-dev 持续语义漂移检测 | M23.4 | OBJ-3, D2 |
+| pace-review 语义一致性评分 | M23.4 | OBJ-3, D2 |
+
+---
+
+## Phase 24：可视化与企业级
+
+**目标**：devpace-cadence 可视化平台 MVP、多项目组合管理基础。
+
+**对应 OBJ**：OBJ-9, OBJ-16
+
+**前置条件**：Phase 23 完成
+
+### 里程碑
+
+| # | 里程碑 | 状态 | 产出 |
+|---|--------|------|------|
+| M24.1 | devpace-cadence MVP | 待开始 | 独立 Next.js 应用（价值链追溯图 + 看板 + 仪表盘） |
+| M24.2 | 多项目组合管理 | 待开始 | pace-portfolio 或 pace-sync 扩展（跨项目 insights + 统一 DORA 仪表盘） |
+
+### 任务定义
+
+| 任务 | 关联里程碑 | 关联条目 |
+|------|----------|---------|
+| devpace-cadence 核心实现（ReactFlow 价值链图 + Recharts 仪表盘） | M24.1 | OBJ-9, D3 |
+| 多项目 insights 库 + 依赖声明 | M24.2 | OBJ-16, D4 |
+
+---
+
## 变更记录
> 操作级变更记录已移至 [progress.md](progress.md)。此处仅保留战略级变更。
| 日期 | 变更 | 原因 |
|------|------|------|
+| 2026-03-08 | Phase 21 完成（M21.1-M21.5 全部关闭，S35-S42 验收通过）。新增 Phase 22-24：体验增强与紧耦合治理（M22.1-M22.4）+ 预测与安全（M23.1-M23.4）+ 可视化与企业级（M24.1-M24.2） | BizDevOps 全生命周期审查 v2：6 项缺口（G1-G6）+ 5 项 UX 改进 + 5 项差异化创新 |
+| 2026-03-07 | 新增 Phase 21：BR 上游业务规划域（M21.1-M21.4）。Opportunity/Epic/BR 溢出概念模型 + /pace-biz Skill + 全价值链增强 | BR 上游空白导致无法兑现端到端追溯承诺 |
| 2026-02-26 | pace-plan UX 优化 11 项增强（E1-E11）：P0 空树引导+智能建议、P1 adjust+auto-retro+启发式+衔接+速度、P2 分组+风险+回顾直联+health。不新增 Phase，产品层优化模式 | UX 原则 P1-P7 对齐审计，11 个用户旅程断点修复 |
| 2026-02-25 | Phase 18 里程碑扩展（M18.2+M18.3 新增 C1/B1/B2/A1/D2/D1 内容）；Phase 19 重组为智能推送+Issue 生命周期+多平台预研；Phase 20 重组为轮询入站+冲突解决+多平台正式（pull 从 Phase 19 移入，webhook 约束明确） | pace-sync 产品优化分析 |
| 2026-02-25 | 新增 Phase 18-20：外部工具同步（M18.1-M18.3, M19.1-M19.3, M20.1-M20.3） | v1.5.0 External Tool Semantic Bridge，语义级双向桥接 |
diff --git a/docs/plans/bizdevops-review-v2.md b/docs/plans/bizdevops-review-v2.md
new file mode 100644
index 0000000..9beba42
--- /dev/null
+++ b/docs/plans/bizdevops-review-v2.md
@@ -0,0 +1,299 @@
+# devpace BizDevOps 全生命周期审查与改进方案（v2 — 基于最新项目状态）
+
+## Context
+
+devpace 是一个 Claude Code Plugin，经过 21 个 Phase 迭代（18 完成，Phase 21 进行中，Phase 19/20 待开始），构建了 19 个 Skills、3 个 Agents、18+ 个 Schemas、14 个 Hooks。Phase 21 正在补齐 Biz 域的上游建模（Opportunity→Epic→BR），新增了 pace-biz Skill（8 个子命令 + 8 个 procedures）和 3 个 Schema（opportunity-format、epic-format、br-format）。同时，独立的可视化平台 `devpace-cadence`（Next.js Web 应用）已完成设计方案。
+
+用户要求从 BizDevOps 专家视角进行系统审查，并参照华为 CodeArts ALM 等企业级 ALM 工具的价值流设计，识别覆盖缺口和体验短板，提出改进方案。
+
+---
+
+## 第一部分：最新 BizDevOps 覆盖矩阵
+
+### 1.1 实体关系现状（价值链六层）
+
+```
+Opportunity(OPP) ──采纳──→ Epic(EPIC) ──分解──→ BR ──细化──→ PF ──实现──→ CR ──发布──→ Release
+ [Schema ✅] [Schema ✅] [Schema ✅] [Schema ✅] [Schema ✅] [Schema ✅]
+ [Skill ✅] [Skill ✅] [Skill ✅] [Skill ✅] [Skill ✅] [Skill ✅]
+ pace-biz pace-biz pace-biz pace-dev pace-dev pace-release
+ opportunity epic decompose (自动创建PF) (状态机) (14子命令)
+
+横向支撑：OBJ(业务目标) ✅ | MoS(成效指标) ✅ | 迭代 ✅ | 风险 ✅ | 度量 ✅ | 经验 ✅
+```
+
+### 1.2 三域评分（基于最新实现）
+
+| 域 | 评分 | 说明 |
+|----|:----:|------|
+| **Biz 域** | **6/10** | Schema 完整且设计优秀（OPP/EPIC/BR），pace-biz Skill 已定义 8 子命令 + 8 procedures，但 S35-S42 验收标准全部未打勾（验证待完成）。与上次审查（3/10）大幅提升 |
+| **Dev 域** | **9/10** | 完整：pace-init/dev/test/guard/review 全部实现并验证 |
+| **Ops 域** | **7.5/10** | pace-release 完整，pace-sync GitHub MVP 已完成（Phase 19/20 待扩展） |
+| **Observe 域** | **9/10** | pace-status/next/pulse/retro/trace 全部完整 |
+| **Knowledge 域** | **8.5/10** | pace-learn/theory 完整，devpace-cadence 可视化平台已设计 |
+
+### 1.3 对标 CodeArts ALM 实体覆盖（用户 promt.md 分析的更新）
+
+| CodeArts 概念 | devpace 覆盖 | 最新状态 | 差距评估 |
+|--------------|:------------:|---------|---------|
+| 业务机会 | **已建模** | OPP Schema + pace-biz opportunity | 待验证 |
+| 专题（Epic） | **已建模** | EPIC Schema + pace-biz epic（含 MoS） | 待验证 |
+| 业务需求（BR） | **已建模** | BR Schema + 溢出模式 + 优先级 + 成功标准 | 待验证（不再是"空壳"） |
+| 产品特性（PF） | 较好 | 完整字段体系 + 溢出模式 | 已验证 |
+| 业务目标 | 较好 | OBJ + MoS checkbox | 已验证 |
+| 愿景 | **已增强** | project-format.md 结构化（目标用户+核心问题+差异化+成功图景） | 不再是一行 blockquote |
+| 战略上下文 | **已新增** | project-format.md 战略上下文 section（核心假设+外部约束） | 渐进填充 |
+| 成功标准 | **已扩展** | MoS 覆盖 OBJ + **新增 Epic 级 MoS** + BR 级成功标准 | 三层 MoS |
+| 需求工作流 | **已改善** | BR→PF 有 pace-biz decompose；PF→CR 有状态机 | 但 BR 自身无独立状态机（状态由下游 PF 聚合计算） |
+| 版本规划 | 较好 | Release 完整 | 已验证 |
+| 日常需求 | **有路径** | `/pace-change add`（快速路径，跳过 OPP/EPIC） | 已设计但需验证 |
+| 业务线/产品线 | 无 | 刻意不建模（单项目 Claude Code 场景不需要） | **合理省略** |
+| 投资组合 | 无 | 不建模 | **合理省略**（单人场景） |
+| 产品目标 | 间接 | 通过 OBJ→Epic→BR→PF 间接关联 | 可接受 |
+| 战略/策略 | 间接 | 被 OBJ + 战略上下文隐含 | 可接受 |
+
+---
+
+## 第二部分：系统性缺口分析（按严重程度排序）
+
+### G1 [严重: 高] pace-biz 实现验证缺口
+
+**现状**：pace-biz 的 8 个子命令 + 8 个 procedures + 3 个 Schema 已全部定义，但 S35-S42 的验收标准（requirements.md）全部未打勾。这意味着 Biz 域的实际运行时行为尚未被端到端验证。
+
+**风险**：
+- Schema 定义优秀但实际执行时可能有边界条件问题
+- pace-biz 与下游 Skill（pace-change、pace-plan、pace-dev）的衔接未验证
+- 价值功能树中 Epic→BR→PF 的渐进溢出模式未验证
+
+**建议**：这是当前最高优先级——完成 Phase 21 M21.4（文档+eval）和 M21.5（discover/import/infer 验证），然后逐条打勾 S35-S42。
+
+### G2 [严重: 高] Skill 间紧耦合风险
+
+**新发现**：`docs/design/skill-dependencies.md` 揭示了多处高风险耦合：
+
+| 耦合关系 | 风险等级 | 问题 |
+|---------|:--------:|------|
+| pace-review → pace-test accept | **很高** | review 摘要模板内嵌 accept 输出字段，格式变更直接破坏 |
+| pace-dev → pace-guard scan | **高** | dev 直接引用 guard 的 procedures 文件路径 |
+| pace-dev → pace-test strategy-gen | **高** | dev 直接引用 test 的 procedures 文件路径 |
+| pace-change → pace-plan adjust | **高** | change 内联执行 plan 的逻辑 |
+
+**影响**：任何单个 Skill 的重构都可能级联破坏其他 Skill。这在 19 个 Skill 规模下是严重的维护性风险。
+
+**建议**：
+- **短期**：将高风险耦合点的格式定义抽取为共享 Schema（类似 cr-format.md 的契约模式）
+- **中期**：考虑引入"接口契约"层——Skill 间通过 Schema 定义的数据格式通信，而非直接引用 procedures 文件路径
+- **立即**：在 skill-dependencies.md 中标注的 "§5 变更影响矩阵" 作为每次修改前的必查清单
+
+### G3 [严重: 中] 架构决策记录（ADR）缺失
+
+**现状**：context.md 记录技术约定（"怎么写代码"），CR 事件表记录单 CR 决策。但跨 CR 的架构级决策（"为什么选 PostgreSQL"、"为什么微服务架构"）没有独立管理。
+
+**影响**：跨会话时 Claude 可能做出矛盾的架构选择。技术债务根源不可追溯。
+
+**建议**：扩展 pace-trace 增加 `arch` 子命令 + 新增 `decisions/ADR-NNN.md` Schema。不需要新 Skill，在 pace-trace 内扩展即可（符合"深度优于广度"原则）。
+
+### G4 [严重: 中] 技术债务非一等公民
+
+**现状**：pace-biz infer 可推断技术债务，pace-guard 可扫描风险，但技术债务没有独立状态机和偿还计划。
+
+**建议**：
+- CR type 增加 `tech-debt`（cr-format.md 已有 type 枚举，扩展即可）
+- pace-plan 增加迭代容量预留配置（project.md 配置 section 添加 `tech-debt-budget: 20%`）
+- pace-retro 增加技术债务趋势指标
+
+### G5 [严重: 中] 安全维度（DevSecOps）薄弱
+
+**现状**：checks-format.md 有"安全检查推荐表"，但安全不是系统化管理维度。
+
+**建议**：pace-guard scan 增加"安全"维度（第 6 维）。不需要新 Skill。
+
+### G6 [严重: 低] BR 缺少独立状态机
+
+**现状**：BR 状态由下游 PF 聚合计算（"所有 PF 完成→BR 完成"），但没有独立的状态转换（如"BR 评审中→BR 已确认→BR 开发中"）。这意味着 BR→PF 的转化过程无显式工作流。
+
+**对标**：CodeArts ALM 的需求工作流有独立的 "需求→评审→开发→验证→关闭" 工作流。
+
+**评估**：在 Claude Code 单人场景下，BR 的独立工作流可能过重。当前的聚合计算模式是合理的极简设计。但如果 devpace 要面向团队场景（devpace-cadence 可视化平台暗示这一方向），BR 独立工作流将变得必要。
+
+**建议**：P3 优先级。当前设计已够用，未来面向团队场景时再评估。
+
+---
+
+## 第三部分：用户体验流畅性分析
+
+### UX1 [影响: 高] 命令认知过载
+
+**数据**：19 Skills × 平均 6 子命令 ≈ 60+ 入口。pace-release 14 子命令、pace-test 10 子命令、pace-change 9 子命令。
+
+**已有缓解**：pace-next 推荐下一步、rules §15 渐进教学、空参数智能引导、渐进暴露设计。
+
+**改进方向**：
+- 强化"无命令体验"——扩展自然语言触发覆盖面
+- pace-biz 空参引导已设计良好（扫描项目上下文→个性化推荐），建议作为模式推广到其他 Skill
+- 评估是否需要 "pace-help" 或在 pace-status 中集成命令推荐
+
+### UX2 [影响: 高] 探索→推进模式切换摩擦
+
+**问题**：`context: fork` 创建新 Agent 上下文，探索阶段发现需要重建。
+
+**已有缓解**：T118 上下文继承、Agent memory 持久化。
+
+**改进方向**：
+- S/M 复杂度 CR 提供"快速模式"（不 fork）
+- 探索模式关键发现写入 CR "探索笔记" section
+- fork 时自动注入探索摘要
+
+### UX3 [影响: 中] 新用户上手断点
+
+**问题**：pace-init 完成后"然后呢？"不明确。
+
+**改进方向**：
+- pace-init 完成后自动触发 pace-biz infer（已有代码的项目）
+- state.md 初始生成时包含推荐下一步
+- 第一次 /pace-dev 增加新手引导
+
+### UX4 [影响: 中] 长会话上下文压力
+
+**问题**：550 行 rules + 126 个 procedures 在 compact 后可能退化。
+
+**改进方向**：
+- PreCompact Hook 增强：保存关键状态快照
+- compact 后注入最小恢复上下文（IR-1~5 + 当前 CR + 下一步）
+
+### UX5 [影响: 中→低] 度量可视化受限
+
+**问题**：dashboard.md 纯文本表格表现力有限。
+
+**已有方案**：devpace-cadence Web 应用（ReactFlow 价值链图 + Recharts 仪表盘）将系统性解决此问题。
+
+**短期改进**：pace-retro 输出增加 Mermaid 趋势图。
+
+---
+
+## 第四部分：差异化创新建议
+
+### D1 [杀手级] AI 驱动的预测性项目管理
+
+**概念**：基于历史 CR 周期、Gate 通过率、变更频率、风险趋势、insights.md 经验，AI 预测迭代交付概率和瓶颈。
+
+**为何杀手级**：传统工具用统计学（燃尽图），devpace 可做"因果推断"——Claude 理解代码复杂度和需求耦合度。
+
+**实施**：扩展 pace-retro 增加 `forecast` 子命令（不新增 Skill），输出：
+- 迭代交付概率（基于当前进度 + 历史模式）
+- 预测瓶颈（基于 CR 滞留时间 + 依赖关系）
+- 风险预警（基于 pace-guard 趋势 + insights 模式）
+
+### D2 [杀手级] 语义级代码-需求持续一致性检测
+
+**概念**：不只 Gate 2 的一次性比对，而是持续监控代码变更是否偏离需求语义。
+
+**实施**：增强 pace-dev 漂移检测 + pace-review 增加"语义一致性评分"。不需要新 Skill。
+
+### D3 [强差异化] devpace-cadence 可视化平台
+
+**已规划**：独立 Next.js 应用，从 Git 仓库拉取 `.devpace/` 数据，提供价值链追溯图 + 看板 + 仪表盘。
+
+**战略价值**：
+- 让非开发角色（PM/QA/管理层）无需 Claude Code 即可查看研发状态
+- 多项目支持为 pace-portfolio 奠定基础
+- 角色视图复用 pace-role 的 5 角色维度
+
+### D4 [强差异化] 多项目组合管理
+
+**概念**：跨项目的全局 insights 库、依赖声明、统一 DORA 仪表盘。
+
+**基础**：devpace-cadence 的多项目支持 + pace-learn export/import。
+
+**实施**：待 devpace-cadence 成熟后，在 Plugin 侧新增 pace-portfolio Skill 或扩展 pace-sync。
+
+### D5 [中等差异化] 自然语言工作流编排
+
+**概念**：用户自然语言定义自动化工作流，devpace 自动编排执行。
+
+**实施**：长期目标，扩展 project.md 配置 section 增加自动化流程定义。
+
+---
+
+## 第五部分：优先级路线图
+
+### 立即（Phase 21 剩余）
+
+| 项目 | 内容 | 对应缺口 |
+|------|------|---------|
+| M21.4 完成 | 文档 + eval 验证 | G1 |
+| M21.5 完成 | discover/import/infer 端到端验证 | G1 |
+| S35-S42 打勾 | pace-biz 全部验收标准验证 | G1 |
+
+### Phase 22: 体验增强 + 紧耦合治理
+
+| 里程碑 | 内容 | 优先级 | 对应缺口 |
+|--------|------|:------:|---------|
+| M22.1 | Skill 间接口契约层设计（解耦 pace-review↔pace-test、pace-dev↔pace-guard 等） | P0 | G2 |
+| M22.2 | 首次推进引导 + 无命令体验增强 | P1 | UX1, UX3 |
+| M22.3 | ADR 管理（pace-trace arch 子命令 + decisions/ Schema） | P1 | G3 |
+| M22.4 | 技术债务一等公民化（CR type 扩展 + pace-plan 容量预留） | P1 | G4 |
+
+### Phase 23: 预测与安全
+
+| 里程碑 | 内容 | 优先级 | 对应缺口 |
+|--------|------|:------:|---------|
+| M23.1 | pace-retro forecast 子命令（预测性项目管理） | P1 | D1 |
+| M23.2 | 安全维度增强（pace-guard 第 6 维） | P1 | G5 |
+| M23.3 | Compact 恢复优化 | P1 | UX4 |
+| M23.4 | 语义级漂移检测增强 | P1 | D2 |
+
+### Phase 24+: 可视化与企业级
+
+| 里程碑 | 内容 | 优先级 | 对应缺口 |
+|--------|------|:------:|---------|
+| devpace-cadence MVP | 独立仓库实现 | P1 | D3, UX5 |
+| 多项目组合管理 | pace-portfolio 或 pace-sync 扩展 | P2 | D4 |
+| BR 独立工作流 | 面向团队场景评估 | P3 | G6 |
+
+---
+
+## 第六部分：三条核心战略建议
+
+### 1. 深度优于广度
+
+19 Skills 已到认知极限。本方案中**没有新增任何 Skill**——所有改进都通过扩展现有 Skill 子命令实现（ADR→pace-trace arch；forecast→pace-retro forecast；安全→pace-guard 第 6 维）。这是刻意的设计选择。
+
+### 2. 契约优于内联
+
+skill-dependencies.md 揭示的紧耦合是最大的维护性风险。Skill 间应通过 Schema 定义的数据契约通信，而非直接引用内部 procedures 文件路径。这是 Phase 22 的最高优先级。
+
+### 3. 验证优于新增
+
+Phase 21 的 pace-biz + 3 个 Schema 设计质量很高，但验收标准全部未打勾。当前最有价值的工作不是新增功能，而是**完成验证并在真实项目中跑通 OPP→EPIC→BR→PF→CR 全链路**。
+
+---
+
+## 第七部分：风险
+
+| 风险 | 严重度 | 缓解 |
+|------|:------:|------|
+| Skill 间紧耦合导致级联故障 | 高 | Phase 22 接口契约层（G2） |
+| 规则过载 compact 后退化 | 高 | Phase 23 规则分层加载 |
+| pace-biz 设计未经真实项目验证 | 高 | 立即完成 S35-S42 验证 |
+| 复杂度膨胀（60+ 子命令） | 中 | 不新增 Skill，强化无命令体验 |
+| Claude Code 原生 session persistence | 中 | 加速向预测+智能层迁移 |
+
+## 验证方法
+
+1. **Biz 域验证**：在 1 个真实项目中跑通 `pace-biz opportunity → epic → decompose → /pace-dev → /pace-review → /pace-release` 全链路
+2. **紧耦合验证**：修改 pace-test accept 输出格式，验证 pace-review 是否破坏
+3. **回归验证**：`bash scripts/validate-all.sh` + `pytest tests/static/ -v`
+4. **竞争力对比**：与 Linear AI、CodeArts ALM 做特性矩阵对比
+
+## 关键文件
+
+- `docs/design/skill-dependencies.md` — **新增**：Skill 间耦合关系（变更影响矩阵必查）
+- `docs/plans/devpace-cadence-design.md` — **新增**：可视化平台设计方案
+- `skills/pace-biz/SKILL.md` — **新增**：Biz 域统一入口
+- `knowledge/_schema/opportunity-format.md` — **新增**：OPP Schema
+- `knowledge/_schema/epic-format.md` — **新增**：EPIC Schema
+- `knowledge/_schema/br-format.md` — **新增**：BR Schema
+- `knowledge/_schema/project-format.md` — **更新**：价值功能树增加 Epic→BR 链接格式
+- `docs/planning/requirements.md` — S35-S42 验收标准（待打勾）
+- `rules/devpace-rules.md` — 运行时行为规则
diff --git a/docs/plans/devpace-bizdevops-lifecycle-review-plan.md b/docs/plans/devpace-bizdevops-lifecycle-review-plan.md
new file mode 100644
index 0000000..ae53b1c
--- /dev/null
+++ b/docs/plans/devpace-bizdevops-lifecycle-review-plan.md
@@ -0,0 +1,404 @@
+# devpace BizDevOps 全生命周期审查与重构方案
+
+## Context
+
+devpace 是一个 Claude Code Plugin，目标是为 AI 辅助开发提供完整的 BizDevOps 研发节奏管理。当前项目非常成熟（127/131 任务完成，42/42 场景覆盖），拥有 19 个 Skills、3 个 Agent、~113 个 procedures 文件、19 个 schema 文件。
+
+本方案从**宏观到微观、整体到局部、粗粒度到细粒度**四个维度审查 devpace，并按 P0-P3 优先级提供分层重构方案，目标是让 devpace 成为世界上最优秀的 BizDevOps 全生命周期 AI 工具。
+
+---
+
+## Part I: 宏观审查 — BizDevOps 生命周期完整性
+
+### 1.1 生命周期覆盖矩阵
+
+| BizDevOps 阶段 | 子活动 | 覆盖 Skill | 覆盖度 | 评估 |
+|---------------|--------|-----------|--------|------|
+| **业务机会** | 机会捕获、评估、采纳 | pace-biz opportunity | FULL | 完整 |
+| **战略对齐** | OBJ 关联、MoS 追踪 | pace-biz align | FULL | 完整 |
+| **需求发现** | 交互式探索、文档导入、代码推断 | pace-biz discover/import/infer | FULL | 完整 |
+| **需求分解** | Epic->BR->PF 分解 | pace-biz decompose | FULL | 完整 |
+| **迭代规划** | 规划/关闭/调整/健康度 | pace-plan | FULL | 完整 |
+| **开发执行** | CR 创建/编码/测试/质量门 | pace-dev | FULL | 完整 |
+| **代码审查** | Gate 3 审批准备 | pace-review | FULL | 完整 |
+| **测试验证** | 策略/覆盖/验收/影响分析 | pace-test | FULL | 完整 |
+| **需求变更** | 插入/暂停/恢复/修改/批量 | pace-change | FULL | 完整 |
+| **风险管理** | 扫描/监控/趋势/报告 | pace-guard | FULL | 完整 |
+| **发布管理** | 创建/部署/验证/关闭/回滚 | pace-release | FULL | 完整 |
+| **运维反馈** | 反馈收集/事件追溯/热修 | pace-feedback | FULL | 完整 |
+| **度量回顾** | 迭代回顾/DORA/趋势/预测 | pace-retro | FULL | 完整 |
+| **外部集成** | GitHub/Linear/Jira 同步 | pace-sync | PARTIAL | Phase 19-20 待完成 |
+| **知识沉淀** | 经验提取/知识库管理 | pace-learn | FULL | 完整 |
+| **决策审计** | AI 决策轨迹/ADR | pace-trace | FULL | 完整 |
+| **--- 以下为缺口 ---** | | | | |
+| **架构设计** | 技术方案设计、架构评审 | 无专属 Skill | GAP | 见 1.2-G1 |
+| **持续集成** | CI 配置、构建自动化、流水线管理 | 仅 Gate 查询 | GAP | 见 1.2-G2 |
+| **环境管理** | dev/staging/prod 环境、特性开关 | 无 | GAP | 见 1.2-G3 |
+| **事件管理** | 严重性分级、升级、事后复盘 | pace-feedback 部分覆盖 | PARTIAL | 见 1.2-G4 |
+| **项目 Onboarding** | 新成员引导、项目知识传递 | 无 | GAP | 见 1.2-G5 |
+
+### 1.2 生命周期缺口分析
+
+**G1: 架构设计活动缺失**
+
+pace-trace 支持 ADR（架构决策记录），但这是事后记录。在开发前的"技术方案设计"环节没有对应 Skill。当用户面对 L/XL 复杂度的 PF 时，从"需求分解完成"到"开始编码"之间缺少一个结构化的技术设计步骤。
+
+- 影响：L/XL CR 的质量门通过率可能较低（因为缺少前置技术设计）
+- 建议：在 pace-dev 的 L/XL 流程中嵌入"技术方案"步骤，或新增 `/pace-design` Skill
+
+**G2: CI/CD 管理能力薄弱**
+
+当前 CI/CD 能力限于 Gate 4 的状态查询（checks-format.md 中的 ci-status-cmd）。无法管理流水线配置、触发构建、查看构建日志。
+
+- 影响：Release 流程依赖用户手动管理 CI/CD
+- 建议：中长期通过 MCP Server 或 pace-sync 扩展支持 CI/CD 操作
+
+**G3: 环境管理缺失**
+
+没有管理开发/测试/生产环境差异的能力，也没有特性开关（feature flag）管理。
+
+- 影响：Release 验证步骤缺少环境上下文
+- 建议：作为 pace-release 的子命令扩展（`/pace-release env`），或长期独立 Skill
+
+**G4: 事件管理不完整**
+
+pace-feedback 覆盖了反馈收集和热修复路径，但缺少结构化的事件管理：严重性分级（P0-P4）、升级链、值班轮转、事后复盘（postmortem）。
+
+- 影响：对需要 Ops 成熟度的专业团队吸引力不足
+- 建议：扩展 pace-feedback 增加 `incident` 子命令系列
+
+**G5: 项目 Onboarding 缺失**
+
+pace-init 创建项目骨架，pace-theory 解释方法论，但没有"引导新用户完成第一个完整 BizDevOps 循环"的结构化体验。
+
+- 影响：新用户转化率低，学习曲线陡峭
+- 建议：P0 优先级，见 Part V 重构方案
+
+### 1.3 四大反馈闭环完整性
+
+| 闭环 | 路径 | 完整度 | 断点 |
+|------|------|--------|------|
+| 业务闭环 | OBJ -> Epic -> BR -> MoS 达成 -> 回顾 | 95% | MoS 自动评估依赖人工输入 |
+| 产品闭环 | BR -> PF -> 迭代 -> 回顾 -> 改进 | 98% | pace-retro accept 到下一迭代的衔接靠信号间接完成 |
+| 技术闭环 | CR created -> merged (状态机) | 100% | 完整 |
+| 运维闭环 | Release -> 部署 -> 反馈 -> Defect CR | 90% | 缺少结构化事件管理和 postmortem |
+
+---
+
+## Part II: 中观审查 — Skill 架构与互联
+
+### 2.1 Skill 分组与粒度评估
+
+**当前分组**（来自 devpace-rules.md 0）：
+
+| 层级 | Skills | 评估 |
+|------|--------|------|
+| 核心（5） | init, dev, status, review, next | 合理，覆盖最小闭环 |
+| 业务（1） | biz (8 子命令) | 子命令过多，是最大的单一 Skill |
+| 进阶（6） | change, plan, retro, guard, sync, role | 合理，各自职责清晰 |
+| 专项（4） | release, test, feedback, theory, trace | release 子命令最多(15 procedures) |
+| 系统（2） | pulse, learn | 合理，自动调用无需用户关注 |
+
+**粒度问题**：
+
+| 问题 | 涉及 Skill | 分析 |
+|------|-----------|------|
+| pace-biz 过于庞大 | pace-biz | 8 个子命令跨越 opportunity/epic/decompose/align/view/discover/import/infer，功能跨度大 |
+| pace-release 过于庞大 | pace-release | 15 个 procedures 文件，子命令含 create/deploy/verify/close/full/status/changelog/version/tag/notes/branch/rollback |
+| pace-status 子命令丰富但分层合理 | pace-status | 9 个 procedures 但层次清晰（L1/L2/L3），可接受 |
+| pace-theory 和 pace-trace 有概念重叠 | pace-theory, pace-trace | theory 解释"是什么"，trace 追溯"为什么这样做"，目标不同但用户可能混淆 |
+
+**建议**：
+- pace-biz：保持合并但改善 sub-routing，在 §0 速查中更清晰地区分"创建型"和"分析型"子命令
+- pace-release：考虑拆分为 `pace-release`（生命周期）+ `pace-changelog`（文档生成），但复杂度增加，暂不推荐
+- pace-theory + pace-trace：保持独立，但在帮助文本和 description 中更清晰地区分
+
+### 2.2 Skill 互联拓扑分析
+
+```
+ pace-biz
+ / | \
+ opportunity epic decompose
+ \ | /
+ pace-plan -------- pace-change
+ | |
+ pace-dev ---------- pace-guard
+ / | \ |
+ Gate1 Gate2 pace-test |
+ | |
+ pace-review |
+ | |
+ [人类审批] |
+ | |
+ merged ---------- pace-learn
+ | |
+ pace-release --- pace-sync
+ |
+ pace-feedback
+ |
+ pace-retro
+
+横切: pace-status, pace-next, pace-role, pace-trace, pace-theory, pace-pulse
+```
+
+### 2.3 互联断层清单
+
+**断层 D1: pace-biz decompose -> pace-plan 引导不一致**
+- SKILL.md 推荐流程：`discover -> decompose -> /pace-plan next`
+- decompose 实际输出引导：`-> /pace-change add 或 /pace-dev`
+- 修复：统一 decompose 的输出引导，增加到 `/pace-plan next` 的引导
+- 涉及文件：`skills/pace-biz/biz-procedures-decompose.md`
+
+**断层 D2: pace-plan -> pace-dev 迭代绑定弱**
+- pace-plan 规划了迭代并选择 PF，但 pace-dev 按单个功能描述或 CR 编号工作
+- 迭代中 PF 的优先顺序仅通过 pace-next 信号间接传递（S13）
+- 缺少"按迭代计划优先级自动推进下一 PF"的直接路径
+- 修复：在 pace-dev merged 后的引导中，如果迭代内有未开始 PF，直接推荐迭代中最高优先级的 PF
+- 涉及文件：`skills/pace-dev/dev-procedures-postmerge.md`、`knowledge/signal-priority.md`
+
+**断层 D3: pace-retro -> pace-plan 回顾到规划的衔接**
+- pace-retro 生成回顾报告和改进建议，但到下一迭代规划(pace-plan next)时需要用户手动关联
+- 修复：pace-plan next 的规划流程中显式引用上一迭代 retro 的关键建议
+- 涉及文件：`skills/pace-plan/plan-procedures.md`
+
+**断层 D4: pace-guard scan 与 pace-dev 的触发门槛**
+- S/M CR 仅在 insights.md 有匹配 pattern 时触发风险扫描
+- 新项目 insights.md 为空，S/M CR 的风险扫描永远不会被自动触发
+- 修复：新项目首 N 个 CR 默认触发基础扫描，或首次 Guard 扫描由 init 完成后的引导触发
+- 涉及文件：`skills/pace-guard/guard-procedures-common.md`、`skills/pace-dev/dev-procedures-gate.md`
+
+**断层 D5: pace-feedback -> pace-change 的反馈转需求路径**
+- pace-feedback 创建 Defect/Hotfix CR 后，如果反馈表明需要新功能而非修缺陷，转到 pace-change add 的路径不够显式
+- 修复：pace-feedback intake 步骤增加"功能请求"类型判断，自动路由到 pace-change add
+- 涉及文件：`skills/pace-feedback/feedback-procedures-intake.md`
+
+### 2.4 信号系统缺口
+
+当前 S1-S20 信号覆盖全面，但缺少以下场景：
+
+| 编号 | 缺失信号 | 场景 | 建议优先级 |
+|------|---------|------|-----------|
+| S21 | 跨 CR 依赖阻塞 | CR-A 被 CR-B 阻塞且 CR-B 长期未推进 | P1 |
+| S22 | 技术债积压 | tech-debt CR 数量或占比超阈值 | P2 |
+| S23 | 知识库健康度 | insights.md 引用命中率 < 50% | P2 |
+| S24 | 首次完整循环 | 用户从未完成过 init->dev->review->merged 完整循环 | P0 |
+| S25 | 长期休眠项目 | .devpace/ 存在但 30+ 天无活动 | P2 |
+
+---
+
+## Part III: 微观审查 — 用户操作流畅性
+
+### 3.1 新用户首次体验（First-Time UX）
+
+**当前流程**：
+```
+用户安装 Plugin -> /pace-init -> 生成 .devpace/ ->
+"说'帮我做 [功能名]'开始第一个功能..." -> ???
+```
+
+**问题**：
+1. 初始化后的"空白页"——用户不确定下一步做什么
+2. 从 README 的 19 个命令列表到"只需说自然语言"的认知跳跃过大
+3. 没有引导式的 onboarding tour
+4. 第一次使用 pace-dev 时用户不理解为什么会创建 BR/PF/CR 三层结构
+
+**改进方案**（P0 优先级）：
+- 新增 `S24 首次完整循环` 信号，在 session-start 检测到用户从未完成过完整循环时，触发引导式 onboarding
+- Onboarding 不是新 Skill，而是 pace-pulse session-start 的增强：检测到"新项目 + 0 个 merged CR"时，输出简化版的下一步引导
+- README 精简：首页只保留核心 5 命令 + 30 秒体验，完整列表链接到 user-guide
+
+### 3.2 日常开发流程（Daily UX）
+
+**当前流程**：
+```
+会话开始 -> 1 句话状态 -> "帮我做 X" -> pace-dev 推进 ->
+Gate 1/2 -> pace-review -> Gate 3 人类审批 -> merged ->
+下一步引导
+```
+
+**问题**：
+1. Gate 3 高频审批摩擦——连续做 5-6 个 S 复杂度 PF 时，每个都要审批
+2. 批量审批虽有设计（§2），但触发条件苛刻（2+ CR 同时 in_review）
+3. 推进模式中"探索中继续"的模式切换对用户不透明
+
+**改进方案**（P1 优先级）：
+- "连续推进模式"：用户说"连续做"或"批量推进"时，pace-dev 在 S 复杂度 CR 满足简化审批条件时不立即审批，而是推进到下一个 PF，最后统一展示批量审批列表
+- 涉及文件：`skills/pace-dev/SKILL.md`（新增 `--batch` 参数）、`rules/devpace-rules.md §2`（放宽批量审批触发条件）
+
+### 3.3 认知负荷分析
+
+| 维度 | 当前状态 | 问题 | 改进 |
+|------|---------|------|------|
+| 命令数量 | 19 Skill + ~83 子命令 | 信息过载 | 分层暴露：核心 5 -> 进阶 -> 专项 |
+| 价值链层级 | OPP->Epic->BR->PF->CR->Release | 对小项目过重 | "轻量模式"：小项目隐藏 OPP/Epic 层 |
+| 模式切换 | 探索/推进隐式切换 | 用户不知当前模式 | status 行显示当前模式标识 |
+| 术语体系 | BR/PF/CR/Gate/MoS 等 | 对非产品经理背景的开发者陌生 | 自然语言优先，术语仅在 tree/detail 视图暴露 |
+
+### 3.4 错误恢复与容错
+
+**当前容错设计**：
+- Gate 失败自修复（最多 2 次）
+- 文件损坏降级处理（pace-change degraded mode）
+- 中断恢复（state.md 锚点）
+- 验收失败回退到 developing
+
+**缺口**：
+- 用户误操作的"撤销"能力有限——pace-change undo 只针对需求变更，pace-dev 没有"撤销上一次合并"的能力
+- 会话中途 Claude 出错（幻觉）时的恢复机制依赖用户主动发现
+
+---
+
+## Part IV: 竞争力差异化分析
+
+### 4.1 devpace 独特定位
+
+| 维度 | 传统工具 (Jira/Linear/GitHub Projects) | 通用 AI 编码 (Cursor/Copilot Workspace) | devpace |
+|------|--------------------------------------|---------------------------------------|---------|
+| 业务到代码追溯 | 手动关联 | 无 | **自动**（OBJ->BR->PF->CR） |
+| 变更管理 | 手动调整看板 | 无 | **一等公民**，影响分析+有序调整 |
+| 质量门 | CI/CD 外挂 | 无 | **内嵌**，4 级 Gate 自动执行 |
+| 跨会话连续性 | N/A | 有限 | **完整**（state.md 锚点） |
+| 度量与回顾 | 需额外配置 | 无 | **内建** DORA + 迭代回顾 |
+| 自然语言交互 | 有限（AI 辅助搜索） | 代码层面 | **全流程**自然语言驱动 |
+| AI 决策透明度 | N/A | 无 | **完整审计**（pace-trace） |
+
+### 4.2 护城河强化方向
+
+**当前三层护城河**：入口层（跨会话） -> 差异化层（变更管理） -> 护城河层（完整价值链+度量+合规）
+
+**强化建议**：
+
+| 方向 | 措施 | 目的 |
+|------|------|------|
+| **智能编排** | 引入"旅程模板"，自动编排多 Skill 流程 | 从"工具集"升级为"智能工作流平台" |
+| **预测能力** | 强化 pace-retro forecast + pace-guard trends | 从"被动管理"升级为"主动预测" |
+| **生态集成** | 完成 Phase 19-20 外部同步 + CI/CD 深度集成 | 从"独立工具"升级为"研发中枢" |
+| **团队适配** | 多用户状态隔离 + 角色权限 + 共享仪表盘 | 从"个人工具"升级为"团队平台" |
+| **可视化** | Phase 24 devpace-cadence Next.js 仪表盘 | 从"CLI 工具"升级为"可视化平台" |
+
+### 4.3 与"世界最优秀"的差距
+
+对标 BizDevOps 领域最佳实践，devpace 的主要差距：
+
+1. **编排智能不足**：19 个 Skill 是独立的，缺少跨 Skill 的智能编排能力。用户需要自己知道"下一步该用哪个命令"，虽然 pace-next 提供建议，但缺少"一键执行推荐"
+2. **小项目体验过重**：概念模型（6 层价值链）对个人小项目来说认知成本过高
+3. **大项目性能未验证**：50+ CR 场景下的 backlog 遍历、信号采集性能未经实战验证
+4. **多人协作空白**：完全面向"1 人 + Claude"，无法支持 2+ 人共享 .devpace/
+5. **可视化缺失**：纯 CLI 交互，无法提供全局鸟瞰视图
+
+---
+
+## Part V: 分层重构方案
+
+### P0: 即刻改进（1-2 周，不改架构）
+
+| 编号 | 改进项 | 涉及文件 | 预期效果 |
+|------|--------|---------|---------|
+| P0-1 | **新用户 Onboarding 引导** | `skills/pace-pulse/pulse-procedures-session-start.md` | 新项目首次会话自动引导用户完成"init -> 第一个功能 -> review -> merged"完整闭环 |
+| P0-2 | **修复 D1: biz decompose 输出引导** | `skills/pace-biz/biz-procedures-decompose.md` | 统一 decompose 输出引导到 `/pace-plan next`，消除路径歧义 |
+| P0-3 | **修复 D2: merged 后迭代优先级推荐** | `skills/pace-dev/dev-procedures-postmerge.md` | merged 后如果迭代内有未开始 PF，直接推荐最高优先级 PF |
+| P0-4 | **README 精简** | `README.md`、`README_zh.md` | 首页只保留核心 5 命令 + 30 秒体验，降低新用户信息过载 |
+| P0-5 | **修复 D4: 新项目风险扫描兜底** | `skills/pace-guard/guard-procedures-common.md` | 新项目（insights.md 为空）的首 3 个 CR 默认触发基础风险扫描 |
+| P0-6 | **修复 D5: feedback 功能请求路由** | `skills/pace-feedback/feedback-procedures-intake.md` | 增加"功能请求"类型判断，自动路由到 pace-change add |
+
+### P1: 体验升级（3-4 周，小幅架构调整）
+
+| 编号 | 改进项 | 涉及文件 | 预期效果 |
+|------|--------|---------|---------|
+| P1-1 | **连续推进模式（batch dev）** | `skills/pace-dev/SKILL.md`、`dev-procedures-common.md`、`rules/devpace-rules.md §2` | 用户说"连续做"时批量推进 S 复杂度 PF，最后统一审批 |
+| P1-2 | **修复 D3: retro -> plan 衔接** | `skills/pace-plan/plan-procedures.md` | 规划新迭代时自动引用上一迭代回顾的关键建议 |
+| P1-3 | **轻量模式（lite mode）** | `skills/pace-init/SKILL.md`、`init-procedures-core.md`、`knowledge/_schema/project-format.md` | 小项目初始化时隐藏 OPP/Epic 层，project.md 只含 OBJ->PF->CR 三层 |
+| P1-4 | **信号系统补全** | `knowledge/signal-priority.md`、`knowledge/signal-collection.md` | 新增 S21(依赖阻塞)、S22(技术债积压)、S24(首次循环引导) |
+| P1-5 | **模式状态可见** | `rules/devpace-rules.md §1/§2` | session-start 和推进模式切换时，在输出中明确标识当前模式 |
+| P1-6 | **pace-biz 子命令分组优化** | `skills/pace-biz/SKILL.md` | 将 8 个子命令分为"创建型"(opportunity/epic/decompose)和"分析型"(align/view/discover/import/infer) |
+
+### P2: 结构增强（1-2 月，中度架构调整）
+
+| 编号 | 改进项 | 涉及范围 | 预期效果 |
+|------|--------|---------|---------|
+| P2-1 | **智能旅程编排器（Journey Orchestrator）** | 新增 `skills/pace-journey/` 或整合到 `pace-next` | 提供"旅程模板"：`/pace-next journey new-feature` 自动编排 biz->plan->dev->review->release 完整流程，每步完成后自动推进到下一步 |
+| P2-2 | **事件管理增强** | 扩展 `skills/pace-feedback/` | 增加 `incident` 子命令系列：severity 分级、escalation、postmortem 模板 |
+| P2-3 | **架构设计步骤** | 扩展 `skills/pace-dev/` 或新增 `skills/pace-design/` | L/XL CR 开发前增加"技术方案"步骤，含方案选择、ADR 记录、依赖分析 |
+| P2-4 | **信号快照缓存** | `knowledge/signal-collection.md`、相关 Skill procedures | 实现信号采集结果的会话级缓存，避免同一会话重复扫描 |
+| P2-5 | **大型项目性能优化** | `knowledge/_schema/state-format.md`、各 Skill 的 backlog 扫描逻辑 | backlog 索引机制：state.md 维护 CR 摘要索引，避免逐文件遍历 |
+
+### P3: 长期演进（3+ 月，重大架构变革）
+
+| 编号 | 改进项 | 涉及范围 | 预期效果 |
+|------|--------|---------|---------|
+| P3-1 | **多用户协作支持** | state.md 分离为 per-user + shared、合并策略 | 支持 2+ 人共享 .devpace/，通过 Git 自然协作 |
+| P3-2 | **可视化仪表盘** | Phase 24 devpace-cadence Next.js | 从 CLI 到 Web UI，提供全局鸟瞰 |
+| P3-3 | **CI/CD 深度集成** | MCP Server 或 pace-sync 扩展 | 触发构建、查看日志、管理部署环境 |
+| P3-4 | **智能自主性升级** | 新的 autonomy-level 框架 | Claude 根据项目成熟度和用户信任度自动调整自主级别 |
+| P3-5 | **插件生态** | Plugin 扩展机制 | 允许第三方为 devpace 编写领域扩展（安全审计、合规检查等） |
+
+---
+
+## Part VI: 核心架构重构 — 智能旅程编排器（P2-1 详设）
+
+这是本次重构的**核心架构级提案**，将 devpace 从"工具集"升级为"智能工作流平台"。
+
+### 6.1 问题本质
+
+19 个 Skill 各自优秀，但用户需要**自己知道**下一步该用哪个。虽然 pace-next 提供建议，但：
+- pace-next 只推荐"1 件事"，不提供完整的工作流视图
+- 用户需要手动执行推荐的命令
+- 没有"一键走完整个流程"的能力
+
+### 6.2 方案设计
+
+**不新增 Skill**，而是增强 `/pace-next` 增加 `journey` 子命令：
+
+```
+/pace-next journey <模板名> [--auto]
+```
+
+**内置旅程模板**：
+
+| 模板 | 编排流程 | 适用场景 |
+|------|---------|---------|
+| `new-feature` | biz discover -> decompose -> plan next -> dev -> review -> merged | 从零开始交付一个功能 |
+| `iteration` | plan next -> [dev -> review -> merged]* -> plan close -> retro | 完整迭代循环 |
+| `hotfix` | feedback report -> dev(hotfix) -> review -> release deploy | 紧急修复 |
+| `release` | release create -> deploy -> verify -> close | 标准发布 |
+| `onboarding` | init -> dev(第一个功能) -> review -> merged | 新用户首次体验 |
+
+**`--auto` 模式**：每步完成后自动推进到下一步（S 复杂度），L/XL 在每步前暂停确认。
+
+### 6.3 为什么是 pace-next 而非新 Skill
+
+1. pace-next 已有全局信号采集能力，是最佳的编排锚点
+2. 不增加 Skill 数量，降低用户认知负荷
+3. `journey` 是 pace-next 的自然扩展——从"推荐下一步"到"编排完整旅程"
+4. 复用 signal-priority.md 的优先级逻辑
+
+---
+
+## Part VII: 验证方案
+
+### 7.1 P0 验证
+
+1. 新建测试项目，使用 `/pace-init` 初始化
+2. 验证 session-start 是否触发 onboarding 引导
+3. 使用 `/pace-biz decompose` 验证输出引导是否指向 `/pace-plan next`
+4. 完成一个 CR merged，验证 postmerge 引导是否推荐迭代内下一 PF
+5. 在新项目上创建 S 复杂度 CR，验证是否触发基础风险扫描
+
+### 7.2 P1 验证
+
+1. 连续推进 3 个 S 复杂度 PF，验证批量审批流程
+2. 使用 lite mode 初始化小项目，验证 project.md 只含 OBJ->PF->CR
+3. 创建互相依赖的 2 个 CR，验证 S21 信号是否触发
+
+### 7.3 P2 验证
+
+1. `/pace-next journey new-feature` 端到端测试：从 biz discover 到 merged
+2. `/pace-next journey onboarding` 新用户体验测试
+3. 50+ CR 项目的信号采集性能基准测试
+
+### 7.4 自动化验证
+
+扩展 `tests/static/` 测试套件：
+- `test_journey_templates.py`：验证旅程模板定义完整性
+- `test_signal_coverage.py`：验证新增信号的采集和消费正确性
+- `test_skill_interconnections.py`：验证 D1-D5 断层修复后的引导路径一致性
diff --git a/docs/user-guide.md b/docs/user-guide.md
index 6d6cba5..afd7cc2 100644
--- a/docs/user-guide.md
+++ b/docs/user-guide.md
@@ -70,19 +70,19 @@ You can also use `/pace-init full` to complete the full setup at once (business
### Traceability Chain
-devpace organizes work into a traceable chain:
+devpace organizes work into a 6-layer traceable chain:
```
-Goal → Feature → Task → Code
-You define goals You plan features Claude auto-creates Claude writes code
+Opportunity → Epic → Requirement → Feature → Task → Code
+You spot You plan Decompose Plan together Claude creates Claude codes
```
-- **You define** goals and features (in natural language)
+- **You define** opportunities, epics, and features (in natural language)
- **Claude auto-creates** tasks and maintains traceability throughout
-- **Bidirectional traceability**: from goals to code, and from code back to goals
+- **Bidirectional traceability**: from business opportunities to code, and from code back to goals
> **Internal terminology reference** (you don't need to memorize these — Claude won't use them in conversation either):
-> Goal = OBJ/BR (Business Goal/Requirement), Feature = PF (Product Feature), Task = CR (Change Request)
+> Opportunity = OPP, Epic = EPIC, Requirement = BR (Business Requirement), Feature = PF (Product Feature), Task = CR (Change Request)
### You Don't Need to Learn Any Terminology
@@ -95,11 +95,25 @@ devpace uses a precise internal concept model, but everything in conversation is
| "准备好了吗" (= "Is it ready") | Checks quality gate status |
| "加一个导出功能" (= "Add an export feature") | Recognizes a requirement change, runs impact analysis |
+### BizDevOps Coverage
+
+devpace covers the full BizDevOps spectrum across six domains:
+
+| Domain | Score | Key Capabilities |
+|--------|:-----:|-----------------|
+| **Biz** (Business Planning) | **8/10** | `/pace-biz` 8 subcommands: opportunity, epic, decompose, align, view, discover, import, infer |
+| **Product** (Product Management) | **9/10** | `/pace-plan` with adjust/health, `/pace-change` full lifecycle, `/pace-next` recommendations |
+| **Dev** (Development) | **9.5/10** | `/pace-dev` autonomous coding, ADR management, tech debt tracking, OWASP security scanning, semantic drift detection |
+| **Ops** (Operations) | **7.5/10** | `/pace-release` full orchestration, `/pace-sync` external tool bridge, CI/CD awareness |
+| **Observe** (Observability) | **9.5/10** | `/pace-retro` DORA metrics + forecasting, `/pace-pulse` rhythm monitoring, `/pace-guard` risk fabric |
+| **Knowledge** (Knowledge Management) | **8.5/10** | `/pace-learn` cross-project insights, `/pace-theory` methodology reference, experience extraction |
+
---
## Command Reference
> **Core commands** (daily use): `/pace-init`, `/pace-dev`, `/pace-status`, `/pace-review`, `/pace-next`
+> **Business commands** (upstream planning): `/pace-biz`
> **Advanced commands** (when needed): `/pace-change`, `/pace-plan`, `/pace-retro`, `/pace-guard`
> **Specialized commands** (optional): `/pace-test`, `/pace-release`, `/pace-sync`, `/pace-feedback`, `/pace-role`, `/pace-theory`, `/pace-trace`
@@ -110,6 +124,7 @@ devpace uses a precise internal concept model, but everything in conversation is
**Arguments**:
- `name` — Optional, project name. Claude asks if omitted.
- `full` — Optional. Runs full setup (business goals, feature list, iteration plan, quality checks).
+- `--lite` — Optional. Lightweight mode: skips OPP/Epic/BR layers, project.md contains only OBJ→PF→CR three-layer structure, suitable for personal small projects.
**Behavior**:
- **Default**: Creates minimal `.devpace/` (state + project stub + backlog + rules). Only asks for project name and description. After init, previews "what happens next" to orient you.
@@ -128,6 +143,7 @@ devpace uses a precise internal concept model, but everything in conversation is
- `feature description` — Start working on the specified feature (natural language matching)
- `#N` — Jump directly to CR by number (e.g., `#3` → CR-003)
- `--last` — Resume the most recently worked-on CR
+- `--batch` — Continuous advance mode: batch-advance multiple S-complexity PFs in the iteration, unified review at the end
**Behavior**:
@@ -202,6 +218,8 @@ devpace uses a precise internal concept model, but everything in conversation is
**Arguments**:
- *(empty)* — 1 recommendation (≤3 lines)
- `detail` — Expanded candidate list (≤8 lines)
+- `why` — Expanded reasoning chain (2-5 lines: signal scan + priority comparison + role influence + alternatives)
+- `journey [template]` — Full workflow path: step-by-step guide from current state to goal. Templates: `new-feature` (default), `iteration`, `hotfix`, `release`, `onboarding`
**Behavior**: Synthesizes multi-dimensional signals (in_review CRs, developing CRs, unverified deployments, iteration completion, retro cycles, backlog status, etc.) and recommends next actions via a 12-level priority matrix.
@@ -232,6 +250,37 @@ devpace uses a precise internal concept model, but everything in conversation is
---
+### `/pace-biz [subcommand] [args]`
+
+**When to use**: Upstream business planning — capture opportunities, create epics, decompose requirements, or discover needs.
+
+**Arguments**:
+
+| Argument | Description |
+|----------|-------------|
+| `opportunity ` | Capture a business opportunity |
+| `epic [OPP-xxx] ` | Create an Epic from an opportunity or directly |
+| `decompose ` | Break down Epic→BR or BR→PF |
+| `align` | Strategic alignment health check (read-only) |
+| `view` | Business panorama view (read-only) |
+| `discover ` | Interactive multi-turn requirements discovery from a vague idea |
+| `import ...` | Extract requirements from documents (meeting notes, feedback, competitor analysis) |
+| `infer` | Infer untracked features and technical debt from codebase |
+| *(empty)* | Context-aware recommendation |
+
+**Recommended workflows**:
+
+```
+Full business path: opportunity → epic → decompose → /pace-dev
+Exploratory discovery: discover → decompose → /pace-plan next
+Document import: import → align → /pace-plan next
+Codebase inference: infer → align → /pace-dev
+```
+
+See [Business Planning feature docs](features/pace-biz.md) for details.
+
+---
+
### `/pace-change [type] [#N|--last|--dry-run] [description]`
**When to use**: Requirements change mid-work.
@@ -271,6 +320,7 @@ See the [Requirement Changes](#requirement-changes) section for details.
- `history` — Cross-iteration trend overview (3+ iterations)
- `mid` — Mid-iteration lightweight check (no dashboard update)
- `accept` — Confirm suggested actions from last retrospective (MoS updates, etc.)
+- `forecast` — Delivery prediction: probability, bottleneck identification, risk alerts
**Report contents**:
- **Action summary** (~10 lines): key metrics + trends + concerns + highlights + recommendations
@@ -444,7 +494,7 @@ You can pass Gate 2 without running accept — but changes with accept have stro
| Argument | Action |
|----------|--------|
-| `scan [CR-ID]` | Pre-flight risk scan — 5-dimension assessment (historical lessons / dependency impact / architecture compatibility / scope complexity / security sensitivity) |
+| `scan [CR-ID]` | Pre-flight risk scan — 5-dimension assessment with OWASP-aware security scanning (historical lessons / dependency impact / architecture compatibility / scope complexity / security: Layer 1 keyword + Layer 2 OWASP pattern) |
| `monitor [CR-ID]` | Summarizes real-time risk status for a CR (mitigated / pending / new) |
| `trends [iteration-ID]` | Cross-CR trend analysis (by category, recurring risk identification, improvement suggestions) |
| `report` | Project-level risk dashboard (grouped by PF, sorted by severity, overall risk score) |
@@ -476,6 +526,10 @@ You can pass Gate 2 without running accept — but changes with accept have stro
**Arguments**:
- `report ` — **Emergency channel**: skips triage, enters production incident branch with accelerated path evaluation (hotfix/critical only)
+- `incident open ` — Create incident record (severity assessment + timeline initialization)
+- `incident close ` — Close incident + generate postmortem template
+- `incident timeline ` — View incident timeline
+- `incident list` — List all incidents (supports `--open` filter)
- `` — Classified and routed (production incident / defect / improvement / new requirement / inbox)
- *(empty)* — Progressive two-round guided collection (essential info first, details only when severity ≥ major)
@@ -497,9 +551,10 @@ You can pass Gate 2 without running accept — but changes with accept have stro
**Arguments**:
- `keyword` — Query the reasoning trace for a specific decision (e.g., "why rejected", "Gate 2")
+- `arch [title|ADR-NNN|list|supersede]` — Architecture Decision Records management
- *(empty)* — Shows the most recent decision trace
-**Behavior**: Reads task event tables, checkpoint markers, and traceability tags to reconstruct the complete reasoning process behind Gate/intent/change decisions.
+**Behavior**: Reads task event tables, checkpoint markers, and traceability tags to reconstruct the complete reasoning process behind Gate/intent/change decisions. Also manages Architecture Decision Records (ADR) for cross-CR architectural decisions.
**Read-only**: Does not modify any state files.
@@ -523,6 +578,9 @@ You can pass Gate 2 without running accept — but changes with accept have stro
| `unlink` | `CR-ID` | Remove association between CR and external entity |
| `create` | `CR-ID` | Create external Issue from CR metadata and auto-link |
| `pull` | `CR-ID` | Check external state and prompt to update (lightweight MVP) |
+| `ci status` | — | View CI/CD run status for the current branch |
+| `ci trigger` | `[workflow]` | Manually trigger a GitHub Actions workflow |
+| `ci logs` | `[run-id]` | View log summary for a specified run |
| `status` | — | View sync status and external links |
No arguments defaults to `status`. `--dry-run` previews actions without executing.
@@ -718,6 +776,7 @@ Claude runs automatically, fixes failures and retries. Doesn't bother you.
- Integration tests pass
- Intent consistency check (does the code match the plan?)
+- Semantic consistency score (how well code aligns with acceptance criteria — rated High/Medium/Low)
- No unexpected side effects
Also automatic. Claude fixes issues before advancing.
diff --git a/docs/user-guide_zh.md b/docs/user-guide_zh.md
index 9896354..8ad1b5a 100644
--- a/docs/user-guide_zh.md
+++ b/docs/user-guide_zh.md
@@ -68,19 +68,19 @@ devpace 不要求你预先规划所有内容。初始化只创建最小骨架，
### 追溯链
-devpace 把工作组织成可追溯的链条：
+devpace 把工作组织成 6 层可追溯的链条：
```
-目标 → 功能 → 任务 → 代码
-你定义目标 你规划功能 Claude 自动创建 Claude 写代码
+机会 → 专题 → 需求 → 功能 → 任务 → 代码
+你发现机会 你规划专题 一起分解 一起规划 Claude 自动创建 Claude 写代码
```
-- **你定义**目标和功能（用自然语言）
+- **你定义**机会、专题和功能（用自然语言）
- **Claude 自动创建**任务，并在工作过程中维护追溯关系
-- **双向追溯**：从目标追到代码，从代码追回目标
+- **双向追溯**：从业务机会追到代码，从代码追回目标
> **内部术语参考**（你不需要记这些，Claude 对话中也不会使用）：
-> 目标 = OBJ/BR（Business Goal/Requirement）、功能 = PF（Product Feature）、任务 = CR（Change Request）
+> 机会 = OPP、专题 = EPIC、需求 = BR（Business Requirement）、功能 = PF（Product Feature）、任务 = CR（Change Request）
### 你不需要学任何术语
@@ -93,11 +93,25 @@ devpace 内部使用精确的概念模型，但对话中一切都是自然语言
| "准备好了吗" | 检查质量门状态 |
| "加一个导出功能" | 识别为需求变更，执行影响分析 |
+### BizDevOps 覆盖度
+
+devpace 覆盖完整的 BizDevOps 全域六大维度：
+
+| 维度 | 评分 | 关键能力 |
+|------|:----:|---------|
+| **Biz**（业务规划） | **8/10** | `/pace-biz` 8 子命令：opportunity、epic、decompose、align、view、discover、import、infer |
+| **Product**（产品管理） | **9/10** | `/pace-plan` adjust/health、`/pace-change` 全生命周期、`/pace-next` 智能推荐 |
+| **Dev**（开发） | **9.5/10** | `/pace-dev` 自主编码、ADR 管理、技术债务追踪、OWASP 安全扫描、语义漂移检测 |
+| **Ops**（运维） | **7.5/10** | `/pace-release` 完整编排、`/pace-sync` 外部工具桥接、CI/CD 感知 |
+| **Observe**（观测） | **9.5/10** | `/pace-retro` DORA 度量 + 预测、`/pace-pulse` 节奏监控、`/pace-guard` 风险织网 |
+| **Knowledge**（知识管理） | **8.5/10** | `/pace-learn` 跨项目经验、`/pace-theory` 方法论参考、经验自动沉淀 |
+
---
## 命令参考
> **核心命令**（日常使用）：`/pace-init`、`/pace-dev`、`/pace-status`、`/pace-review`、`/pace-next`
+> **业务命令**（上游规划）：`/pace-biz`
> **进阶命令**（需要时用）：`/pace-change`、`/pace-plan`、`/pace-retro`、`/pace-guard`
> **专项命令**（可选）：`/pace-test`、`/pace-release`、`/pace-sync`、`/pace-feedback`、`/pace-role`、`/pace-theory`、`/pace-trace`
@@ -108,6 +122,7 @@ devpace 内部使用精确的概念模型，但对话中一切都是自然语言
**参数**：
- `name` — 可选，项目名称。省略时 Claude 会询问。
- `full` — 可选。执行完整设置（业务目标、功能列表、迭代计划、质量检查）。
+- `--lite` — 可选。轻量模式：跳过 OPP/Epic/BR 层，project.md 只含 OBJ→PF→CR 三层结构，适合个人小项目。
**功能**：
- **默认**：创建最小 `.devpace/`（state + project 存根 + backlog + rules）。只问项目名称和描述。初始化后会预览"接下来会发生什么"，帮助你了解下一步。
@@ -126,6 +141,7 @@ devpace 内部使用精确的概念模型，但对话中一切都是自然语言
- `功能描述` — 开始处理指定功能（自然语言匹配）
- `#N` — 按编号直接跳转到指定 CR（如 `#3` → CR-003）
- `--last` — 恢复上一个操作过的 CR
+- `--batch` — 连续推进模式：批量推进迭代内多个 S 复杂度 PF，最后统一审批
**功能**：
@@ -200,6 +216,8 @@ devpace 内部使用精确的概念模型，但对话中一切都是自然语言
**参数**：
- *（空）* — 1 条建议（≤3 行）
- `detail` — 展开候选列表（≤8 行）
+- `why` — 展开推理链（2-5 行：信号扫描 + 优先级对比 + 角色影响 + 备选）
+- `journey [模板名]` — 展示完整工作流路径：从当前状态到目标的分步引导。模板：`new-feature`（默认）、`iteration`、`hotfix`、`release`、`onboarding`
**功能**：综合多维信号（in_review CR、developing CR、未验证部署、迭代完成度、retro 周期、backlog 状态等），按 12 级优先级矩阵推荐下一步行动。
@@ -230,6 +248,37 @@ devpace 内部使用精确的概念模型，但对话中一切都是自然语言
---
+### `/pace-biz [subcommand] [args]`
+
+**何时使用**：上游业务规划——捕获机会、创建专题、分解需求、发现需求。
+
+**参数**：
+
+| 参数 | 说明 |
+|------|------|
+| `opportunity <描述>` | 捕获业务机会 |
+| `epic [OPP-xxx] <描述>` | 从机会转化或直接创建专题 |
+| `decompose ` | 分解 Epic→BR 或 BR→PF |
+| `align` | 战略对齐健康检查（只读） |
+| `view` | 业务全景视图（只读） |
+| `discover <描述>` | 交互式多轮需求发现，从模糊想法出发 |
+| `import <路径>...` | 从文档提取需求（会议纪要、反馈、竞品分析） |
+| `infer` | 从代码库推断未追踪功能和技术债务 |
+| （空） | 上下文感知推荐 |
+
+**推荐流程**：
+
+```
+完整业务路径： opportunity → epic → decompose → /pace-dev
+探索式发现： discover → decompose → /pace-plan next
+多源导入： import <文档> → align → /pace-plan next
+代码库推断： infer → align → /pace-dev
+```
+
+详见[业务规划特性文档](features/pace-biz_zh.md)。
+
+---
+
### `/pace-change [type] [#N|--last|--dry-run] [description]`
**何时使用**：工作进行中需求发生变化。
@@ -269,6 +318,7 @@ devpace 内部使用精确的概念模型，但对话中一切都是自然语言
- `history` — 跨迭代趋势概览（需 3+ 迭代数据）
- `mid` — 迭代中期轻量检查（不更新仪表盘）
- `accept` — 确认上次回顾建议的操作（MoS 更新等）
+- `forecast` — 交付预测：概率预估、瓶颈识别、风险预警
**报告内容**：
- **行动摘要**（~10 行）：关键指标 + 趋势 + 关注点 + 亮点 + 建议
@@ -435,7 +485,7 @@ Gate 2 检查"代码是否与计划一致"。accept 在此基础上提供更精
| 参数 | 动作 |
|------|------|
-| `scan [CR编号]` | Pre-flight 风险扫描——5 维评估（历史教训/依赖影响/架构兼容性/范围复杂度/安全敏感度） |
+| `scan [CR编号]` | Pre-flight 风险扫描——5 维评估 + OWASP 安全扫描（历史教训/依赖影响/架构兼容性/范围复杂度/安全：Layer 1 关键词 + Layer 2 OWASP 模式） |
| `monitor [CR编号]` | 汇总当前 CR 的实时风险状态（已缓解/待处理/新增） |
| `trends [迭代ID]` | 跨 CR 趋势分析（按类别统计、重复风险识别、改进建议） |
| `report` | 项目级风险仪表盘（按 PF 分组、按等级排序、总体风险评分） |
@@ -466,9 +516,13 @@ Gate 2 检查"代码是否与计划一致"。accept 在此基础上提供更精
**何时使用**：收到用户反馈、发现 bug、或需要报告生产问题。
**参数**：
-- `report <描述>` — 直接报告一个生产问题（跳过分诊）
-- `<反馈描述>` — 分类后路由（缺陷/改进/新需求/生产事件）
-- *（空）* — 引导式收集（询问问题类型、影响和紧急程度）
+- `report <描述>` — **紧急通道**：跳过分诊，进入生产事件分支并启用加速路径评估（仅 hotfix/critical）
+- `incident open <描述>` — 创建事件记录（严重度评估 + 时间线初始化）
+- `incident close ` — 关闭事件 + 生成 postmortem 模板
+- `incident timeline ` — 查看事件时间线
+- `incident list` — 列出所有事件（支持 `--open` 筛选）
+- `<反馈描述>` — 分类后路由（生产事件/缺陷/改进/新需求/记录待定）
+- *（空）* — 渐进式两轮引导收集（先收集必要信息，严重度 ≥ major 时再补充细节）
**功能**：
1. 分类反馈（生产事件/缺陷/改进/新需求）
@@ -484,9 +538,10 @@ Gate 2 检查"代码是否与计划一致"。accept 在此基础上提供更精
**参数**：
- `关键词` — 查询特定决策的推理轨迹（如"为什么打回"、"Gate 2"）
+- `arch [标题|ADR-NNN|list|supersede]` — 架构决策记录（ADR）管理
- *（空）* — 展示最近的决策轨迹
-**功能**：读取任务事件表、checkpoint 标记和溯源标记，重建 Gate/意图/变更等决策的完整推理过程。
+**功能**：读取任务事件表、checkpoint 标记和溯源标记，重建 Gate/意图/变更等决策的完整推理过程。同时管理跨 CR 的架构决策记录（ADR）。
**只读**：不修改任何状态文件。
@@ -510,6 +565,9 @@ Gate 2 检查"代码是否与计划一致"。accept 在此基础上提供更精
| `unlink` | `CR-ID` | 解除 CR 与外部实体的关联 |
| `create` | `CR-ID` | 从 CR 元数据创建外部 Issue 并自动关联 |
| `pull` | `CR-ID` | 检查外部状态并提示更新（轻量 MVP） |
+| `ci status` | — | 查看当前分支的 CI/CD 运行状态 |
+| `ci trigger` | `[workflow]` | 手动触发 GitHub Actions workflow |
+| `ci logs` | `[run-id]` | 查看指定运行的日志摘要 |
| `status` | — | 查看同步状态和外部链接 |
无参数时默认 `status`。`--dry-run` 预览操作但不实际执行。
@@ -702,6 +760,7 @@ Claude 自动运行，修复失败并重试。不会打扰你。
- 集成测试通过
- 意图一致性检查（代码是否与计划匹配？）
+- 语义一致性评分（代码与验收标准的对齐度——分为高/中/低三级）
- 无意外副作用
同样自动执行。Claude 在推进前修复问题。
diff --git a/hooks/pre-compact.sh b/hooks/pre-compact.sh
index fa80337..43c339a 100755
--- a/hooks/pre-compact.sh
+++ b/hooks/pre-compact.sh
@@ -1,17 +1,52 @@
#!/bin/bash
-# devpace PreCompact hook — remind to save state before context compression
+# devpace PreCompact hook — save state snapshot and inject recovery context
#
-# Purpose: Before Claude auto-compacts (context ~95%), output a reminder
-# to ensure state.md and CR files reflect the latest progress.
-# This preserves cross-session continuity (OBJ-1).
+# Purpose: Before Claude auto-compacts (context ~95%), output structured
+# recovery context that will survive compression, ensuring continuity.
+# Enhances cross-session continuity (OBJ-1) and long-session stability (UX4).
#
# Advisory hook (exit 0), not blocking.
PROJECT_DIR="${CLAUDE_PROJECT_DIR:-.}"
STATE_FILE="${PROJECT_DIR}/.devpace/state.md"
+DEVPACE_DIR="${PROJECT_DIR}/.devpace"
+if [ ! -f "$STATE_FILE" ]; then
+ exit 0
+fi
+
+# Extract key context for post-compact recovery
+echo "devpace:pre-compact === DEVPACE RECOVERY CONTEXT (preserve after compact) ==="
+
+# 1. Iron Rules reminder
+echo "devpace:pre-compact IR-1: state.md 是唯一会话锚点 | IR-2: 先读后写 | IR-3: 质量门不可跳过 | IR-4: 变更走流程 | IR-5: 产出可追溯"
+
+# 2. Current state summary (extract from state.md)
if [ -f "$STATE_FILE" ]; then
- echo "devpace:pre-compact Context compression imminent. Ensure state.md and any active CR files reflect current progress before compacting. Key items: 1) Update state.md '进行中' and '下一步' 2) Git commit any uncommitted changes 3) Update CR event table if in advance mode."
+ # Extract 进行中 and 下一步 from state.md
+ CURRENT=$(grep -m1 "进行中\|developing\|verifying\|in_review" "$STATE_FILE" 2>/dev/null || echo "")
+ NEXT_STEP=$(grep -m1 "下一步" "$STATE_FILE" 2>/dev/null || echo "")
+ if [ -n "$CURRENT" ]; then
+ echo "devpace:pre-compact Current: $CURRENT"
+ fi
+ if [ -n "$NEXT_STEP" ]; then
+ echo "devpace:pre-compact Next: $NEXT_STEP"
+ fi
fi
+# 3. Active CR detection
+if [ -d "${DEVPACE_DIR}/backlog" ]; then
+ ACTIVE_CRS=$(grep -rl "developing\|verifying\|in_review" "${DEVPACE_DIR}/backlog/" 2>/dev/null | head -3)
+ if [ -n "$ACTIVE_CRS" ]; then
+ for cr in $ACTIVE_CRS; do
+ CR_NAME=$(basename "$cr" .md)
+ CR_STATUS=$(grep -m1 "状态" "$cr" 2>/dev/null | head -1)
+ echo "devpace:pre-compact Active CR: $CR_NAME — $CR_STATUS"
+ done
+ fi
+fi
+
+echo "devpace:pre-compact Action: 1) Read .devpace/state.md to restore full context 2) Resume active CR 3) Git commit any uncommitted changes"
+echo "devpace:pre-compact === END RECOVERY CONTEXT ==="
+
exit 0
diff --git a/knowledge/_schema/accept-report-contract.md b/knowledge/_schema/accept-report-contract.md
new file mode 100644
index 0000000..10130c4
--- /dev/null
+++ b/knowledge/_schema/accept-report-contract.md
@@ -0,0 +1,86 @@
+# accept 报告数据契约
+
+> **职责**：定义 `/pace-test accept` 验收验证报告的输出格式契约。此文件是 pace-test（生产方）和 pace-review（消费方）之间的共享接口。
+>
+> **修改此文件时**：必须同时检查生产方（`verify-procedures.md` Step 4）和消费方（`review-procedures-gate.md` accept 消费章节）是否需要适配。
+
+## §0 速查卡片
+
+| 属性 | 值 |
+|------|-----|
+| 生产方 | `/pace-test accept`（verify-procedures.md Step 4） |
+| 消费方 | `/pace-review`（review-procedures-gate.md accept 消费章节） |
+| 写入位置 | CR 文件"验证证据" section |
+| 触发标题 | `## 验收验证报告` |
+
+## 报告结构
+
+### 必选段
+
+#### 逐条验证结果表
+
+```markdown
+| # | 验收断言 | 状态 | 验证级别 | 证据 |
+|---|---------|------|---------|------|
+| A1 | [断言内容] | ✅ 通过 | L1 动态 | [证据摘要] |
+| A2 | [断言内容] | ✅ 通过 | L2 静态 🟢 | [证据摘要] |
+| A3 | [断言内容] | ❌ 未通过 | L2 静态 | [证据摘要] |
+| A4 | [断言内容] | ⚠️ 需人工 | L3 | [原因] |
+```
+
+**状态枚举**：`✅ 通过` | `❌ 未通过` | `⚠️ 需人工`
+
+**验证级别枚举**：`L1 动态` | `L1+ 浏览器` | `L2 静态` | `L2 静态 🟢/🟡/🟠`（置信度） | `L3`
+
+#### 汇总段
+
+```markdown
+- 通过：N / M
+- 未通过：X（[未通过断言列表]）
+- 需人工验证：Y
+- 验证覆盖率：(N+X) / M = Z%（排除 L3 不可验证项）
+```
+
+### 可选段（条件输出）
+
+#### 测试预言审查（有 test-strategy.md 且有已覆盖条目时）
+
+```markdown
+| 验收条件 | 映射测试 | 预言判定 | 说明 |
+|---------|---------|---------|------|
+| [条件] | [测试名] | ✅ 有效覆盖 | — |
+| [条件] | [测试名] | ⚠️ 弱覆盖 | [原因] |
+| [条件] | [测试名] | ❌ 虚假覆盖 | [原因] |
+```
+
+**预言判定枚举**：`✅ 有效覆盖` | `⚠️ 弱覆盖` | `❌ 虚假覆盖`
+
+#### 合理化自审计（有命中合理化模式时）
+
+```markdown
+| # | 验收断言 | 审计结果 | 说明 |
+|---|---------|---------|------|
+| A1 | [断言] | ✅ 无风险 | — |
+| A3 | [断言] | ⚠️ R1 命中 | [修正说明] |
+
+**审计结论**：N 条通过审计，M 条命中合理化模式（已修正）
+```
+
+## 消费方提取规则
+
+消费方（pace-review）从 accept 报告提取以下汇总数据用于 Review 摘要：
+
+| 提取项 | 来源 | 摘要格式 |
+|--------|------|---------|
+| 通过率 | 汇总段 | `通过率：N/M` |
+| 未通过列表 | 汇总段 | `未通过：[列表]` |
+| 验证级别分布 | 逐条表统计 | `L1 动态 X · L2 静态 Y · L3 需人工 Z` |
+| 预言审查 | 测试预言表统计 | `有效覆盖 A · 弱覆盖 B · 虚假覆盖 C` |
+| 置信度分布 | L2 条目统计 | `🟢High P · 🟡Medium Q · 🟠Low R` |
+| 自审计 | 审计结论行 | `M 条命中合理化模式（已修正）` |
+
+**消费原则**：
+- 紧凑优先：摘要仅显示汇总数据（1-3 行），不复制完整报告
+- 风险聚焦：未通过项或弱覆盖 → 在"风险点"段追加
+- 不重复验证：消费已有报告，不重新执行验收
+- 无报告时静默跳过：不显示、不提示
diff --git a/knowledge/_schema/adr-format.md b/knowledge/_schema/adr-format.md
new file mode 100644
index 0000000..6c83b00
--- /dev/null
+++ b/knowledge/_schema/adr-format.md
@@ -0,0 +1,82 @@
+# ADR（架构决策记录）格式
+
+> **职责**：定义架构决策记录的文件格式。ADR 记录跨 CR 的架构级决策，防止跨会话时 Claude 做出矛盾的架构选择。
+
+## §0 速查卡片
+
+| 属性 | 值 |
+|------|-----|
+| 文件位置 | `.devpace/decisions/ADR-NNN.md` |
+| 创建方式 | `/pace-trace arch` 或 Claude 自动识别 |
+| 编号规则 | 三位数递增（ADR-001, ADR-002...） |
+| 状态枚举 | `proposed` → `accepted` → `superseded` / `deprecated` |
+
+## 文件结构
+
+```markdown
+# ADR-NNN: [决策标题]
+
+- **状态**：[proposed | accepted | superseded | deprecated]
+- **日期**：[YYYY-MM-DD]
+- **决策者**：[Human / Claude / 协商]
+- **关联 CR**：[CR-xxx（如有）]
+- **被取代**：[ADR-xxx（仅 superseded 时填写）]
+
+## 上下文
+
+[描述面临的技术问题或架构选择背景]
+
+## 决策
+
+[描述最终选择的方案]
+
+## 理由
+
+[为什么选择这个方案，考虑了哪些替代方案]
+
+## 影响
+
+- **正面**：[预期收益]
+- **负面**：[已知代价或风险]
+- **影响范围**：[受影响的组件/模块]
+
+## 替代方案
+
+[列出考虑过但未采用的方案及其排除理由]
+```
+
+## 字段规则
+
+| 字段 | 必填 | 说明 |
+|------|:----:|------|
+| 标题 | 是 | 简洁描述决策（如"选择 PostgreSQL 作为主数据库"） |
+| 状态 | 是 | 初始为 `proposed`，确认后转 `accepted` |
+| 日期 | 是 | 创建日期 |
+| 决策者 | 是 | 标注 Human / Claude / 协商 |
+| 关联 CR | 否 | 触发此决策的 CR |
+| 上下文 | 是 | 问题背景 |
+| 决策 | 是 | 具体方案 |
+| 理由 | 是 | 选择依据 |
+| 影响 | 否 | 正面/负面/范围 |
+| 替代方案 | 否 | 排除的方案 |
+
+## 目录约定
+
+```
+.devpace/
+└── decisions/
+ ├── ADR-001.md
+ ├── ADR-002.md
+ └── ...
+```
+
+## 自动识别触发条件
+
+Claude 在开发过程中遇到以下情形时，应建议创建 ADR：
+
+- 技术栈选型（数据库、框架、语言等）
+- 架构模式选择（微服务 vs 单体、事件驱动 vs 同步等）
+- 关键 API 设计决策
+- 重大重构方向
+- 安全架构决策
+- 性能优化策略选择
diff --git a/knowledge/_schema/br-format.md b/knowledge/_schema/br-format.md
new file mode 100644
index 0000000..7b795c7
--- /dev/null
+++ b/knowledge/_schema/br-format.md
@@ -0,0 +1,146 @@
+# 业务需求文件格式契约
+
+> **职责**：定义 BR 溢出后独立文件 `requirements/BR-xxx.md` 的结构。溢出触发时 Claude 自动创建此文件。
+
+## §0 速查卡片
+
+```
+文件名：BR-xxx.md（xxx 为 BR 编号，三位补零）
+目录：.devpace/requirements/
+创建时机：溢出触发（关联 3+ PF | 业务上下文 >5 行 | 经历 /pace-change modify）
+溢出模式：与 PF 溢出模式类似——初始在 project.md 树视图内联，丰富后溢出为独立文件
+内联格式：BR-001：[需求名] `P0` `进行中` → PF-001 → CR-001 🔄
+溢出格式：[BR-001：需求名](requirements/BR-001.md) `P0` → PF-001, PF-002
+内容：Epic 关联 + 状态 + 来源 + 优先级 + 业务上下文 + 成功标准 + PF 列表
+向后兼容：无 requirements/ 目录的项目不受影响——BR 始终可为 project.md 内联一行
+容错：BR 文件丢失时从 project.md 树视图 + PF/CR 文件重建
+```
+
+## 溢出触发条件
+
+当以下任一条件满足时，Claude 自动将 BR 从 project.md 内联溢出为独立文件：
+
+| 条件 | 检测方式 | 说明 |
+|------|---------|------|
+| 关联 3+ 个 PF | 计算价值功能树中该 BR 下的 PF 数 | 信息量足以支撑独立文件 |
+| 业务上下文超过 ~5 行 | 计算 BR 相关描述行数 | 需要详细的业务背景 |
+| 经历过 `/pace-change modify` | 检查变更记录中该 BR 的 modify 记录 | 变更历史需要版本化追踪 |
+
+**溢出是单向的**——一旦溢出不回退。project.md 树视图始终是入口。
+
+## 溢出执行步骤
+
+1. 创建 `.devpace/requirements/` 目录（如不存在）
+2. 创建 `requirements/BR-xxx.md`，按下方文件结构填充
+3. project.md 价值功能树中该 BR 行改为链接格式：`[BR-xxx：名称](requirements/BR-xxx.md)`
+
+## 内联格式（project.md 树视图）
+
+未溢出时 BR 在树视图中为纯文本行：
+
+```markdown
+BR-001：[业务需求名] `P0` `进行中` → PF-001 → CR-001 🔄
+```
+
+字段：
+- BR 编号 + 名称
+- 优先级标签：`` `P0` `` / `` `P1` `` / `` `P2` ``（无优先级时省略）
+- 状态标签：`` `进行中` `` / `` `待开始` `` / `` `已完成` `` / `` `暂停` ``（仅非默认时显示）
+- PF 引用：`→ PF-xxx`（多个用逗号分隔）
+- CR 引用：`→ CR-xxx [emoji]`（PF 下的 CR）
+
+## 溢出格式（requirements/BR-xxx.md）
+
+```markdown
+# BR-xxx：[业务需求名称]
+
+- **Epic**：[EPIC-xxx（专题名称）]（可选——有 Epic 时填写）
+- **OBJ**：OBJ-x（[目标描述]）
+- **状态**：[待开始 | 进行中 | 已完成 | 暂停]
+- **来源**：[OPP-xxx | 日常需求]（可选——Claude 推断）
+- **优先级**：[P0 | P1 | P2 | —]
+
+## 业务上下文
+
+[2-3 句话：为什么需要这个，解决什么业务问题]
+
+## 成功标准
+
+- [业务结果层面的标准 1]
+- [业务结果层面的标准 2]
+
+## 产品功能
+
+| PF | 标题 | 状态 | CR 数 | 完成度 |
+|----|------|------|:-----:|:------:|
+| PF-001 | [功能名] | 完成 | 1 | 1/1 |
+| PF-002 | [功能名] | 进行中 | 2 | 0/2 |
+```
+
+## 字段说明
+
+| 字段 | 核心/渐进 | 来源 | 说明 |
+|------|:---------:|------|------|
+| 标题 | 核心 | 人类提供 | BR 编号 + 需求名称 |
+| Epic 关联 | 核心(有 Epic 时) | Claude 自动关联 | Epic ID + 名称；无 Epic 时 BR 直挂 OBJ |
+| OBJ 关联 | 核心 | Claude 自动关联 | 业务目标 ID + 描述 |
+| 状态 | 核心(自动) | Claude 基于 PF 完成度计算 | 见下方状态计算规则 |
+| 来源 | 渐进 | Claude 推断 | OPP-ID（Opportunity 转化）或"日常需求" |
+| 优先级 | 渐进 | /pace-plan 或用户指定 | `P0`（必须）/ `P1`（应该）/ `P2`（最好）/ `—`（未评估） |
+| 业务上下文 | 渐进 | 人类讨论或 Claude 捕获 | 溢出后必须有（溢出说明信息量已足够） |
+| 成功标准 | 渐进 | /pace-biz 或 BR 讨论时 | 业务结果层面（非实现正确性） |
+| PF 列表 | 核心(自动) | PF 创建时 Claude 自动关联 | 含状态、CR 数、完成度 |
+
+### 状态计算规则
+
+| 条件 | BR 状态 |
+|------|--------|
+| 所有 PF 的所有 CR 均 merged/released | 已完成 |
+| 至少一个 PF 有进行中的 CR（developing/verifying/in_review） | 进行中 |
+| 所有 PF 均待开始或无 PF | 待开始 |
+| 所有 PF 均暂停或 BR 被显式暂停 | 暂停 |
+
+### BR 成功标准 vs PF 验收标准
+
+| 层面 | 位置 | 示例 | 评估时机 |
+|------|------|------|---------|
+| BR 成功标准（业务结果） | BR 文件 | "用户可以通过至少一种方式完成登录" | /pace-retro |
+| PF 验收标准（实现正确性） | PF 文件或 project.md 功能规格 | "邮箱+密码，密码>=8位" | Gate 2 |
+| CR 验收条件（代码正确性） | CR 文件意图 section | "支持 bcrypt 哈希，8+ 字符" | Gate 2 |
+
+## 优先级定义
+
+| 级别 | 含义 | 说明 |
+|------|------|------|
+| P0 | 必须做 | 阻塞核心业务目标 |
+| P1 | 应该做 | 重要但非阻塞 |
+| P2 | 最好做 | 改善体验但可延后 |
+| — | 未评估 | 尚未讨论优先级 |
+
+## 命名规则
+
+- 文件名：`BR-001.md`、`BR-002.md`...（三位补零自增）
+- ID 自增：扫描 project.md 价值功能树中现有 BR 编号的最大值 +1
+- 目录不存在时自动创建
+
+## 更新时机
+
+| 事件 | 更新内容 |
+|------|---------|
+| PF 创建/删除 | PF 列表表格 |
+| PF/CR 状态变更 | PF 状态 + 完成度 + BR 状态重新计算 |
+| /pace-change modify BR | 业务上下文 + 成功标准 |
+| /pace-change pause BR | 状态 → 暂停 |
+| /pace-change resume BR | 状态恢复 |
+| /pace-biz decompose | PF 列表更新 |
+| /pace-plan 分配优先级 | 优先级字段 |
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| BR 文件丢失 | 从 project.md 树视图 + PF/CR 文件重建 |
+| requirements/ 目录不存在 | 溢出时自动创建 |
+| project.md 链接指向不存在的 BR 文件 | 按"BR 文件丢失"处理 |
+| BR 文件与 project.md 树视图状态不一致 | 以 BR 文件为准（更详细），同步更新树视图 |
+| PF 列表与实际 PF 不一致 | 以 PF 文件/project.md 功能规格为准重建 |
diff --git a/knowledge/_schema/cr-format.md b/knowledge/_schema/cr-format.md
index e2920e8..005d9b0 100644
--- a/knowledge/_schema/cr-format.md
+++ b/knowledge/_schema/cr-format.md
@@ -27,7 +27,7 @@
- **ID**：CR-xxx
- **类型**：[feature | defect | hotfix]（默认 feature，可省略）
- **严重度**：[critical | major | minor | trivial]（仅 defect/hotfix 填写）
-- **产品功能**：[PF 标题]（[PF-ID]）→ [BR 标题]（[BR-ID]）
+- **产品功能**：[PF 标题]（[PF-ID]）→ [BR 标题]（[BR-ID]）→ [Epic 标题]（[EPIC-ID]）
- **应用**：[应用名称]
- **分支**：[feature/branch-name]
- **状态**：[created | developing | verifying | in_review | approved | merged | released]
@@ -46,9 +46,24 @@
- **用户原话**：[用户的原始请求]
- **范围**：[做什么 / 不做什么]
- **验收条件**：[怎样算完成]
-- **方案**：[采取什么方案，为什么]
+- **方案**：[采取什么方案，为什么]（详见下方"方案字段"章节）
- **约束**：[边界条件、假设、限制]
+### 方案字段（L/XL CR 必填，S/M 可选）
+
+L/XL CR 经过技术方案评审（见 `skills/pace-dev/dev-procedures-intent.md` 技术方案评审章节）后填充：
+- **选定方案**：[方案名 + 1 行描述]
+- **备选方案**：[方案 B 名 + 为何未选]
+- **决策理由**：[1-2 行选定理由]
+- **关联 ADR**：[ADR-NNN]（如有）
+
+S/M CR 可直接填写 1 行实现思路。
+
+规则：
+- L/XL 进入 developing 前必须填充（技术方案评审步骤自动写入）
+- S/M 无方案字段不报错（向后兼容）
+- 方案评审流程详见 `skills/pace-dev/dev-procedures-intent.md`
+
### 验收条件格式（复杂度自适应）
验收条件格式根据 CR 复杂度自动选择，降低简单 CR 的负担，提升复杂 CR 的精度：
@@ -177,11 +192,13 @@ CR 意图 section 使用溯源标记区分用户输入与 Claude 推断。溯源
| feature | 新功能或增强（默认） | 正常迭代中的产品功能开发 |
| defect | 缺陷修复 | 已发布功能发现的问题，通常由 /pace-feedback 创建 |
| hotfix | 紧急修复 | 生产环境紧急问题，可走加速路径（跳过部分门禁） |
+| tech-debt | 技术债务偿还 | 重构、性能优化、依赖升级等非功能性改进 |
类型规则：
- `feature` 是默认值，现有无 type 字段的 CR 自动视为 feature（向后兼容）
- `defect` 和 `hotfix` 必须填写 severity 字段
- `hotfix` 可走加速路径：created → developing → verifying → merged（跳过 in_review，但仍需事后审批记录）
+- `tech-debt` 走标准路径，但迭代规划时可计入技术债务预算（见 project-format.md 配置章节）
### 严重度
diff --git a/knowledge/_schema/epic-format.md b/knowledge/_schema/epic-format.md
new file mode 100644
index 0000000..a19860b
--- /dev/null
+++ b/knowledge/_schema/epic-format.md
@@ -0,0 +1,125 @@
+# Epic 文件格式契约
+
+> **职责**：定义 Epic 独立文件 `epics/EPIC-xxx.md` 的结构。/pace-biz epic 创建时遵循此格式。
+
+## §0 速查卡片
+
+```
+文件名：EPIC-xxx.md（xxx 为自增数字，三位补零）
+目录：.devpace/epics/
+创建时机：/pace-biz epic（从 Opportunity 转化或直接创建）
+始终独立文件：Epic 不内联在 project.md 中，始终有独立文件
+内容：OBJ 关联 + 状态 + 来源 + 时间框架 + 背景 + MoS + BR 列表
+project.md 保留：价值功能树中 Epic 行用 Markdown 链接指向文件
+向后兼容：无 epics/ 目录的项目不受影响——BR 直挂 OBJ（现有行为不变）
+容错：Epic 文件丢失时从 project.md 树视图 + BR 文件重建
+```
+
+## 文件结构
+
+```markdown
+# EPIC-xxx：[专题名称]
+
+- **OBJ**：OBJ-x（[目标描述]）
+- **状态**：[规划中 | 进行中 | 已完成 | 已搁置]
+- **来源**：[OPP-xxx（[描述]）]（可选——首次 /pace-biz 时填充）
+- **时间框架**：[Iter-x]（可选——首次 /pace-plan 时填充）
+
+## 背景
+
+[2-3 句话：为什么做这个专题，要解决什么问题]
+
+## 成效指标（MoS）
+
+- [ ] [指标 1]（目标：[值]）
+- [ ] [指标 2]
+
+## 业务需求
+
+| BR | 标题 | 优先级 | 状态 | PF 数 | 完成度 |
+|----|------|:------:|------|:-----:|:------:|
+| BR-001 | [需求名] | P0 | 进行中 | 2 | 1/2 |
+| BR-002 | [需求名] | P1 | 待开始 | 0 | — |
+```
+
+## 字段说明
+
+| 字段 | 核心/渐进 | 来源 | 说明 |
+|------|:---------:|------|------|
+| 标题 | 核心 | /pace-biz epic 创建时 | EPIC 编号 + 专题名称 |
+| OBJ 关联 | 核心 | 创建时 Claude 关联 | 业务目标 ID + 描述 |
+| 状态 | 核心 | Claude 自动维护 | 基于 BR 完成度聚合计算 |
+| 来源 | 渐进 | Claude 推断 | 关联 OPP-ID（从 Opportunity 转化时） |
+| 时间框架 | 渐进 | /pace-plan 或讨论排期时 | 迭代 ID |
+| 背景 | 核心 | 人类提供 | 2-3 句话说明专题原因 |
+| MoS | 渐进 | 人类定义或 /pace-biz 引导 | 专题级成效指标 |
+| BR 列表 | 核心(自动) | BR 创建时 Claude 自动关联 | 含优先级、状态、PF 数、完成度 |
+
+### 状态计算规则
+
+| 条件 | Epic 状态 |
+|------|----------|
+| 所有 BR 的 PF 均已完成（全部 CR merged/released） | 已完成 |
+| 至少一个 BR 有进行中的 PF（有 developing/verifying/in_review CR） | 进行中 |
+| 所有 BR 均 `待开始` 或 Epic 刚创建 | 规划中 |
+| 所有 BR 均 `暂停` 或 Epic 被显式搁置 | 已搁置 |
+
+### BR 列表字段说明
+
+| 列 | 说明 |
+|----|------|
+| BR | BR 编号（如溢出则为链接） |
+| 标题 | BR 名称 |
+| 优先级 | `P0` / `P1` / `P2` / `—`（未评估） |
+| 状态 | `待开始` / `进行中` / `已完成` / `暂停` |
+| PF 数 | 关联的 PF 总数 |
+| 完成度 | 已完成 PF 数 / PF 总数（无 PF 时显示 `—`） |
+
+## 命名规则
+
+- 文件名：`EPIC-001.md`、`EPIC-002.md`...（三位补零自增）
+- ID 自增：扫描 `.devpace/epics/` 中现有 Epic 文件的最大编号 +1
+- 目录不存在时自动创建
+
+## project.md 中的引用格式
+
+价值功能树中 Epic 行始终使用 Markdown 链接：
+
+```markdown
+OBJ-001（[目标名]）
+├── [EPIC-001：专题名](epics/EPIC-001.md)
+│ ├── BR-001：需求名 `P0` `进行中` → PF-001 → CR-001 🔄
+│ └── [BR-002：需求名](requirements/BR-002.md) `P1` → PF-002, PF-003
+└── [EPIC-002：专题名](epics/EPIC-002.md)
+ └── BR-003：需求名 `P0` → PF-004 → CR-003 ✅
+```
+
+**无 Epic 时**：BR 直接挂在 OBJ 下（与当前行为一致，向后兼容）：
+
+```markdown
+OBJ-001（[目标名]）
+├── BR-001：需求名
+│ └── PF-001：功能名 → CR-001 🔄
+```
+
+## 更新时机
+
+| 事件 | 更新内容 |
+|------|---------|
+| BR 创建/删除 | BR 列表表格 |
+| BR 状态变更 | BR 列表表格 + Epic 状态重新计算 |
+| PF/CR 状态变更 | BR 完成度 + Epic 状态重新计算 |
+| /pace-change pause Epic | 状态 → 已搁置 |
+| /pace-change resume Epic | 状态恢复 |
+| /pace-plan 分配时间框架 | 时间框架字段 |
+| /pace-retro 评估 MoS | MoS checkbox |
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| Epic 文件丢失 | 从 project.md 树视图 + BR 文件中的 Epic 关联字段重建 |
+| epics/ 目录不存在 | /pace-biz epic 时自动创建 |
+| project.md 链接指向不存在的 Epic 文件 | 按"Epic 文件丢失"处理 |
+| Epic 文件与 project.md 树视图状态不一致 | 以 Epic 文件为准（更详细），同步更新树视图 |
+| BR 列表与实际 BR 文件不一致 | 以 BR 文件和 project.md 树视图为准重建 |
diff --git a/knowledge/_schema/incident-format.md b/knowledge/_schema/incident-format.md
new file mode 100644
index 0000000..8724d23
--- /dev/null
+++ b/knowledge/_schema/incident-format.md
@@ -0,0 +1,95 @@
+# 事件记录格式定义
+
+> **职责**：定义 `.devpace/incidents/INCIDENT-NNN.md` 的文件格式。
+
+## §0 速查卡片
+
+| 维度 | 值 |
+|------|---|
+| 文件位置 | `.devpace/incidents/INCIDENT-NNN.md` |
+| 编号规则 | 扫描目录最大编号 +1，3 位补零 |
+| 状态流转 | open → investigating → mitigated → closed |
+| 写入方 | pace-feedback incident open/close |
+
+## 必需字段
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| 标题 | 字符串 | 事件简述 |
+| 严重度 | P0/P1/P2/P3 | 事件等级 |
+| 状态 | open/investigating/mitigated/closed | 当前状态 |
+| 影响范围 | 字符串 | 受影响的用户/功能/模块 |
+| 开始时间 | ISO 8601 | 事件发现时间 |
+| 关联 CR | 列表 | 相关 Hotfix/Defect CR 编号 |
+
+## 可选字段
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| 结束时间 | ISO 8601 | 事件关闭时间（closed 时填充） |
+| Postmortem | 结构化文本 | 事后复盘（closed 时生成模板） |
+
+## 时间线格式
+
+时间线是事件文件内嵌的表格，每行记录一个事件节点。
+
+## 文件结构
+
+```markdown
+# INCIDENT-NNN：[标题]
+
+- **严重度**：[P0 | P1 | P2 | P3]
+- **状态**：[open | investigating | mitigated | closed]
+- **影响范围**：[描述]
+- **开始时间**：[YYYY-MM-DDTHH:MM:SS]
+- **结束时间**：[YYYY-MM-DDTHH:MM:SS | —]
+- **关联 CR**：[CR-xxx, CR-yyy | 无]
+
+## 时间线
+
+| 时间 | 事件 |
+|------|------|
+| [ISO 8601] | 事件创建 |
+
+## Postmortem
+
+（事件关闭后由 incident close 生成模板）
+```
+
+## 状态机
+
+```
+open ──→ investigating ──→ mitigated ──→ closed
+ │ │ ↑
+ │ └───────────────────────────┘
+ └──→ closed（轻微事件可直接关闭）
+```
+
+### 转换规则
+
+| 转换 | 触发者 | 条件 |
+|------|--------|------|
+| open → investigating | Claude 或人类 | 开始调查 |
+| open → closed | Claude 或人类 | 轻微事件直接关闭 |
+| investigating → mitigated | Claude 或人类 | 影响已缓解但根因未修复 |
+| investigating → closed | Claude 或人类 | 根因已修复 |
+| mitigated → closed | Claude 或人类 | 根因已修复、Postmortem 完成 |
+
+**约束**：closed 是终态，不可回退。每次状态变更必须在时间线追加一行。
+
+## 编号规则
+
+- 文件名格式：`INCIDENT-NNN.md`，NNN 为三位数字，从 001 开始递增
+- 存储目录：`.devpace/incidents/`
+- 编号规则：取 `.devpace/incidents/` 目录下现有 `INCIDENT-*.md` 文件的最大编号 +1
+- 目录不存在时由 `incident open` 自动创建
+- 编号不复用：即使事件已 closed，其编号不回收
+
+## 更新时机
+
+| 操作 | 触发场景 | 动作 |
+|------|---------|------|
+| 创建 | incident open | 新建 INCIDENT-NNN.md，状态 open |
+| 时间线追加 | 状态变更、关键事件发生 | 时间线表格追加行 |
+| 状态更新 | incident close 或手动更新 | 更新头部状态 + 时间线追加行 |
+| Postmortem 生成 | incident close | 填充 Postmortem section 模板 |
diff --git a/knowledge/_schema/opportunity-format.md b/knowledge/_schema/opportunity-format.md
new file mode 100644
index 0000000..26d46e1
--- /dev/null
+++ b/knowledge/_schema/opportunity-format.md
@@ -0,0 +1,107 @@
+# 业务机会文件格式契约
+
+> **职责**：定义 opportunities.md 的结构。/pace-biz opportunity 创建时遵循此格式。
+
+## §0 速查卡片
+
+```
+文件名：opportunities.md（单文件，所有机会集中管理）
+目录：.devpace/
+创建时机：首次 /pace-biz opportunity 或 /pace-init full 时创建
+格式：段落式（每个 Opportunity 一个二级标题 + 列表字段）
+状态流转：评估中 → 已采纳/已搁置/已拒绝
+来源类型：用户反馈 | 竞品观察 | 技术发现 | 市场趋势 | 内部洞察
+不在 project.md 中：业务机会看板独立于战略全景图
+向后兼容：无 opportunities.md 的项目不受影响
+容错：文件丢失时创建空文件
+```
+
+## 文件结构
+
+```markdown
+# 业务机会
+
+## OPP-001：[机会描述]
+- **来源**：[来源类型]（[详细信息]）
+- **状态**：[评估中 | 已采纳 | 已搁置 | 已拒绝]
+- **日期**：[YYYY-MM-DD]
+
+## OPP-002：[机会描述]
+- **来源**：[来源类型]（[详细信息]）
+- **状态**：已采纳 → EPIC-001
+- **日期**：[YYYY-MM-DD]
+```
+
+## 字段说明
+
+| 字段 | 核心/渐进 | 来源 | 说明 |
+|------|:---------:|------|------|
+| ID（OPP-xxx） | 核心 | Claude 自增 | 三位补零自增编号 |
+| 描述（二级标题） | 核心 | 人类提供或 Claude 捕获 | 简洁描述业务机会 |
+| 来源（类型+详情） | 核心 | Claude 推断类型，人类补详情 | 见下方来源类型枚举 |
+| 状态 | 核心 | Claude 维护 | 见下方状态定义 |
+| 日期 | 核心 | Claude 自动 | 创建日期 |
+
+### 来源类型枚举
+
+| 类型 | 含义 | 示例 |
+|------|------|------|
+| 用户反馈 | 来自真实用户的反馈或投诉 | 用户反馈（客户 A，2026-03-01） |
+| 竞品观察 | 竞争对手的功能或策略 | 竞品观察（竞品 X 上线实时协作） |
+| 技术发现 | 技术研究或实验中发现的机会 | 技术发现（新 API 可提升 3x 性能） |
+| 市场趋势 | 行业趋势和市场变化 | 市场趋势（AI 辅助开发需求增长） |
+| 内部洞察 | 团队内部讨论和洞察 | 内部洞察（架构重构可解锁新能力） |
+
+### 状态定义
+
+| 状态 | 含义 | 转换条件 |
+|------|------|---------|
+| 评估中 | 新捕获，待分析 | 初始状态 |
+| 已采纳 | 转化为 Epic | /pace-biz epic 评估通过，格式：`已采纳 → EPIC-xxx` |
+| 已搁置 | 暂时不处理 | 用户决定延后 |
+| 已拒绝 | 不符合战略方向 | 用户决定不做 |
+
+**状态规则**：
+- `已采纳` 时必须关联 Epic ID：`已采纳 → EPIC-xxx`
+- `已搁置` 和 `已拒绝` 可恢复为 `评估中`
+- 状态变更由 Claude 在 /pace-biz 操作时自动维护
+
+## 命名规则
+
+- ID：`OPP-001`、`OPP-002`...（三位补零自增）
+- ID 自增：扫描 opportunities.md 中现有 OPP 编号的最大值 +1
+
+## 设计决策
+
+### 为何不使用表格
+
+表格无法承载变长内容（来源详情因类型不同长度差异大）。段落格式更灵活，每个 Opportunity 一个二级标题 + 列表字段。
+
+### 为何不在 project.md 中
+
+- opportunities.md 是操作性追踪文件，持续增长
+- project.md 是战略全景图，应保持简洁
+- 机会状态变化频繁，不应污染战略视图
+
+### 刻意省略的字段
+
+- **Impact/Effort**：评估阶段的产出，不是录入字段。评估在 /pace-biz 中发生，结果体现为状态变化（采纳→创建 Epic）
+- **优先级**：机会不需要优先级——评估后要么采纳（进入 Epic 管理）要么搁置/拒绝
+
+## 更新时机
+
+| 事件 | 更新内容 |
+|------|---------|
+| /pace-biz opportunity | 新增 OPP 条目 |
+| /pace-biz epic（从 OPP 转化） | OPP 状态 → `已采纳 → EPIC-xxx` |
+| 用户决定搁置/拒绝 | OPP 状态变更 |
+| /pace-biz view | 只读——不修改文件 |
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| opportunities.md 不存在 | /pace-biz opportunity 时自动创建（含标题行） |
+| OPP 编号不连续 | 基于最大编号 +1 继续编号，不填补空缺 |
+| 状态值不合法 | 视为"评估中"（保守假设） |
+| 引用的 EPIC 不存在 | 保留引用但在 /pace-biz view 时标记警告 |
diff --git a/knowledge/_schema/pf-format.md b/knowledge/_schema/pf-format.md
index 0dd4d47..1dc67fd 100644
--- a/knowledge/_schema/pf-format.md
+++ b/knowledge/_schema/pf-format.md
@@ -39,7 +39,7 @@ project.md 保留：树视图行 + [详情] 链接，功能规格 section 中该
```markdown
# PF-xxx：[产品功能名称]
-- **BR**：[BR 名称]（[BR-ID]）→ [OBJ-ID]
+- **BR**：[BR 名称]（[BR-ID]）→ [Epic 名称]（[EPIC-ID]）→ [OBJ-ID]
- **状态**：[进行中 | 全部 CR 完成 | 已发布 | 暂停]
- **用户故事**：[作为...，我希望...]
@@ -76,7 +76,7 @@ project.md 保留：树视图行 + [详情] 链接，功能规格 section 中该
| 字段 | 必填 | 来源 | 说明 |
|------|------|------|------|
| 标题 | 是 | project.md PF 行 | PF 编号 + 名称 |
-| BR 关联 | 是 | project.md 价值功能树 | BR 名称和 ID + OBJ ID |
+| BR 关联 | 是 | project.md 价值功能树 | BR 名称和 ID + Epic ID（如有）+ OBJ ID |
| 状态 | 是 | 计算得出 | 基于关联 CR 状态聚合 |
| 用户故事 | 否 | project.md PF 行括号内容 | 首个 CR 创建时填充 |
| 验收标准 | 否 | project.md 功能规格迁移 | 带 checkbox 和 history 注释 |
diff --git a/knowledge/_schema/project-format.md b/knowledge/_schema/project-format.md
index 9ee38f8..abc7fe5 100644
--- a/knowledge/_schema/project-format.md
+++ b/knowledge/_schema/project-format.md
@@ -5,17 +5,22 @@
## §0 速查卡片
```
-project.md 是项目的业务全景图
-完整版包含：配置（可选）+ 愿景 + 业务目标 + 成效指标 + 实施路径 + 范围 + 原则 + 价值功能树（+功能规格）
+project.md 是项目的战略全景图 + 导航地图
+完整版包含：配置（可选）+ 愿景 + 战略上下文 + 业务目标（含产品维度）+ 成效指标 + 实施路径 + 范围 + 原则 + 价值功能树（Epic→BR→PF→CR）
配置：自主级别（辅助/标准/自主，默认标准）— 控制 Claude 在推进模式中的自主程度
+模式：完整（默认）或 lite（OBJ→PF→CR，跳过 OPP/Epic/BR，适合个人小项目）
最小版（v0.4.0 init）：项目名 + 描述 + 空桩（随开发自然生长）
+愿景：目标用户 + 核心问题 + 差异化 + 成功图景（首次 /pace-biz 或 /pace-init full 时填充）
+战略上下文：核心假设 + 外部约束（首次 /pace-biz 或讨论战略时填充）
范围：做什么 / 不做什么（首次 /pace-change 或范围讨论时填充）
原则：项目级技术/产品原则（首次 /pace-retro 或技术讨论时积累）
PF 可选丰富：用户故事(首个 CR) + 验收标准(verifying) + 边界(变更管理)
PF 溢出：功能规格 >15 行 | 关联 3+ CR | 经历 modify → 自动溢出到 features/PF-xxx.md，树视图保留链接
-价值功能树：OBJ → BR → PF → CR 的完整链路
+BR 溢出：关联 3+ PF | 业务上下文 >5 行 | 经历 modify → 自动溢出到 requirements/BR-xxx.md，树视图保留链接
+价值功能树：OBJ → Epic → BR → PF → CR 的完整链路（Epic 始终用链接指向独立文件）
CR 状态用 emoji：🔄 进行中 | ✅ 完成 | ⏳ 待开始 | 🚀 已发布
Release 标记：📦 待发布 | 🚀 已发布
+业务机会看板在独立的 opportunities.md 中（不在 project.md）
```
## 最小状态（v0.4.0 渐进式初始化）
@@ -27,6 +32,14 @@ Release 标记：📦 待发布 | 🚀 已发布
> [一句话项目定位]
+## 愿景
+
+（首次 /pace-biz 或 /pace-init full 时填充）
+
+## 战略上下文
+
+（首次 /pace-biz 或讨论战略时填充）
+
## 业务目标
（随开发自然生长 — 首次 /pace-retro 或讨论业务目标时引导定义）
@@ -49,6 +62,8 @@ Release 标记：📦 待发布 | 🚀 已发布
```
桩文件中的占位文字在以下时机被替换为实际内容：
+- **愿景**：首次 `/pace-biz` 或 `/pace-init full` 时引导定义
+- **战略上下文**：首次 `/pace-biz` 或讨论战略时填充
- **价值功能树**：首个 CR 创建时，Claude 自动推断 PF 并回填
- **业务目标**：首次 `/pace-retro` 或用户主动讨论业务目标时引导定义
- **实施路径**：首次 `/pace-plan` 时规划
@@ -85,6 +100,7 @@ Claude 在更新 project.md 时，如果发现是桩状态（含占位文字）
- 字段不存在时默认"标准"（向后兼容）
- 用户可随时修改，修改后即时生效（下一个 CR 生效）
- Claude 不自动修改此字段——仅用户主动调整
+- **智能建议**：pace-pulse 每 5 个 CR merged 后自动评估 Gate 通过率和打回率，建议级别调整（需用户确认）
#### preferred-role（可选）
@@ -106,21 +122,100 @@ Claude 在更新 project.md 时，如果发现是桩状态（含占位文字）
- 会话启动时读取此字段作为初始角色（优先级低于显式 `/pace-role` 设置）
- Claude 不自动修改此字段——仅用户通过 `/pace-role set-default` 调整
+#### tech-debt-budget（可选）
+
+```markdown
+- **技术债务预算**：[0-100]%（默认：20%）
+```
+
+| 属性 | 说明 |
+|------|------|
+| 含义 | 每个迭代预留给 tech-debt 类型 CR 的容量百分比 |
+| 默认值 | 20%（字段不存在时） |
+| 消费方 | `/pace-plan`（迭代规划时预留容量）、`/pace-retro`（技术债务趋势指标） |
+| 修改方式 | 用户手动编辑 project.md 或通过 `/pace-plan adjust` |
+
+规则：
+- 字段不存在时默认 20%（向后兼容）
+- `/pace-plan` 在计算迭代容量时，将总容量 × tech-debt-budget% 作为 tech-debt CR 预留容量
+- Claude 在 `/pace-biz infer` 发现大量技术债务时，可建议用户提高此预算
+
+#### mode（可选）
+
+```markdown
+- **模式**：[lite]
+```
+
+| 值 | 含义 |
+|---|------|
+| （缺省） | 完整模式（OPP→Epic→BR→PF→CR） |
+| `lite` | 轻量模式（OBJ→PF→CR，跳过 OPP/Epic/BR） |
+
+规则：
+- 字段不存在时默认完整模式（向后兼容）
+- 通过 `/pace-init --lite` 设置
+- lite 模式下价值功能树跳过 Epic/BR 层，PF 直接挂在 OBJ 下
+- 首次通过 `/pace-biz` 创建 Epic/BR 时自动升级为完整模式（移除 `mode: lite` 标记）
+- Claude 不自动修改此字段——仅用户通过 `/pace-init` 参数或 `/pace-biz` 触发升级
+
+### 1.6 愿景（可选，渐进填充）
+
+```markdown
+## 愿景
+
+- **目标用户**：[谁会用这个产品]
+- **核心问题**：[他们的什么痛点]
+- **差异化**：[为什么选你而不是替代方案]（首次 /pace-biz 时填充）
+- **成功图景**：[做成了是什么样]（首次 /pace-retro 时填充）
+```
+
+填充时机：首次 `/pace-biz` 或 `/pace-init full` 时引导填充。愿景帮助 Claude 在后续决策中保持方向一致性。
+
+规则：
+- 字段为空时保持空值或占位文字，不影响任何功能
+- Claude 不自动推断愿景内容——愿景必须来自人类
+- 向后兼容：无愿景 section 时保持现有一行 blockquote 格式
+
+### 1.7 战略上下文（可选，渐进填充）
+
+```markdown
+## 战略上下文
+
+**核心假设**：
+- [假设 1]（[待验证 | 已验证 | 已推翻]）
+
+**外部约束**：
+- [约束 1]
+```
+
+填充时机：首次 `/pace-biz` 或讨论战略时填充。战略上下文帮助 Claude 理解决策约束和不确定性。
+
+规则：
+- 核心假设的状态由人类维护（`待验证` / `已验证` / `已推翻`）
+- Claude 可在 /pace-retro 时建议更新假设状态，但需人类确认
+- 字段为空时不影响任何功能（向后兼容）
+
### 2. 业务目标
```markdown
## 业务目标
-**当前目标**：[目标 ID] — [目标描述]
+### OBJ-1：[目标描述]（[business | product | tech]，[短期 | 中期 | 长期]）
**成效指标（MoS）**：
- [ ] [指标 1]
-- [ ] [指标 2]（当前：[测量值] → 进度 [N]%）
+- [ ] [指标 2]（目标：[值]，当前：[值] → 进度 [N]%）
- [x] [指标 3]
```
成效指标用 checkbox，达成时勾选。
+**OBJ 产品维度属性**：每个 OBJ 可标注类型和时间维度：
+- **类型**：`business`（业务目标）/ `product`（产品目标）/ `tech`（技术目标）
+- **时间维度**：`短期`（当前迭代）/ `中期`（2-3 迭代）/ `长期`（季度+）
+- 这些属性为可选标注——缺失时不影响功能（向后兼容）
+- 多个 OBJ 时每个 OBJ 用三级标题（`### OBJ-N：...`）
+
**量化进度标注（可选）**：对连续性指标（如"响应时间 < 200ms"、"部署频率 ≥ 1 次/周"），可在括号内追加当前测量值和进度百分比。此标注由 `/pace-retro` 在有 dashboard.md 数据时自动计算并建议追加（需用户确认），二值指标（如"首个 CR 全流程走通"）保持简单 checkbox。
### 3. 实施路径
@@ -163,20 +258,49 @@ Claude 在更新 project.md 时，如果发现是桩状态（含占位文字）
```markdown
## 价值功能树
-OBJ-xxx（[目标名]）
+OBJ-001（[目标名]）
+├── [EPIC-001：专题名](epics/EPIC-001.md)
+│ ├── BR-001：需求名 `P0` `进行中` → PF-001 → CR-001 🔄
+│ └── [BR-002：需求名](requirements/BR-002.md) `P1` → PF-002, PF-003
+└── [EPIC-002：专题名](epics/EPIC-002.md)
+ └── BR-003：需求名 `P0` → PF-004 → CR-003 ✅
+```
+
+**无 Epic 时**（向后兼容）：BR 直接挂在 OBJ 下，与当前行为一致：
+```markdown
+OBJ-001（[目标名]）
├── BR-001：[业务需求名]
│ ├── PF-001：[产品功能名] ✅ → [详情](features/PF-001.md)
│ └── PF-002：[产品功能名] → (待创建 CR)
-└── BR-002：[业务需求名]
- └── PF-003：[产品功能名] → CR-002 ⏳
```
+**Epic 行格式**：始终使用 Markdown 链接指向独立文件：
+```markdown
+[EPIC-xxx：专题名](epics/EPIC-xxx.md)
+```
+
+**BR 行格式**（两种，与 PF 溢出模式类似）：
+
+未溢出：
+```
+BR-xxx：[需求名] `P0` `进行中` → PF-001 → CR-001 🔄
+```
+
+已溢出：
+```
+[BR-xxx：需求名](requirements/BR-xxx.md) `P1` → PF-002, PF-003
+```
+
+BR 行的标签说明：
+- 优先级标签：`P0` / `P1` / `P2`（无优先级时省略）
+- 状态标签：仅非默认时显示，如 `暂停`
+
PF 溢出后的树视图格式（已溢出的 PF 用 `[详情]` 链接替代 CR 列表）：
```markdown
PF-xxx：[产品功能名] [状态] → [详情](features/PF-xxx.md)
```
`[详情](features/PF-xxx.md)` 是实际的 Markdown 链接，在 IDE 中可点击跳转到 PF 文件。
-未溢出的 PF 保持原格式（直接列出 CR）。两种格式可在同一棵树中共存。
+未溢出的 PF 保持原格式（直接列出 CR）。三种溢出格式（Epic链接、BR溢出、PF溢出）可在同一棵树中共存。
CR 状态标记：
- `🔄` — 进行中
@@ -191,11 +315,17 @@ CR 状态标记：
Claude 每次写入或更新价值功能树时，确保格式一致性：
-- 有关联 CR 的 PF 行：`PF-xxx：[名称] → CR-yyy [emoji]`（多个 CR 用逗号空格分隔：`→ CR-001 ✅, CR-003 🔄`）
-- 无 CR 的 PF 行：`PF-xxx：[名称] → (待创建 CR)` 或 `PF-xxx：[名称] ⏳`（规划阶段）
-- 已溢出 PF 行：`PF-xxx：[名称] [状态] → [详情](features/PF-xxx.md)`
+```
+Epic 行： [EPIC-xxx：名称](epics/EPIC-xxx.md) — 始终链接，不内联
+未溢出 BR 行： BR-xxx：[名称] `Px` → PF-xxx → CR-yyy 🔄 — 纯文本
+已溢出 BR 行： [BR-xxx：名称](requirements/BR-xxx.md) `Px` — 溢出后用链接
+PF 行（有 CR）： PF-xxx：[名称] → CR-yyy 🔄 — 多 CR 逗号分隔
+PF 行（无 CR）： PF-xxx：[名称] → (待创建 CR) — 规划阶段
+已溢出 PF 行： PF-xxx：[名称] [状态] → [详情](features/PF-xxx.md) — 溢出后用链接
+```
CR 创建时：在 PF 行追加 CR 引用。CR 状态变更时：更新对应 emoji。
+Epic/BR 创建时：在树中追加对应行。Epic 状态变更时：更新 Epic 文件（不在树中标记状态）。
Release 标记（价值功能树下方，可选）：
```markdown
@@ -254,7 +384,7 @@ PF-001：用户认证（作为用户，我希望能安全登录）→ CR-001
- PF 经历过 `/pace-change modify`
**溢出后 project.md 变化**：
-1. 价值功能树中该 PF 行改为：`PF-xxx：[名称] [状态] → [详情](features/PF-xxx.md)`
+1. 价值功能树中该 PF 行改为链接格式（见功能树格式校验规则中的"已溢出 PF 行"）
2. 功能规格 section 中该 PF 段落移除（如 section 变为空则移除整个 section）
**规则**：
@@ -279,6 +409,24 @@ PF-001：用户认证（作为用户，我希望能安全登录）→ CR-001
溢出后 history 注释迁移到 PF 文件中，`git log features/PF-xxx.md` 提供完整文件级历史。
+### BR 溢出模式（Overflow Pattern）
+
+当 BR 信息量增长到一定规模时，自动溢出为独立文件 `requirements/BR-xxx.md`，project.md 保留树视图和链接。
+
+**触发条件**（满足任一）：
+- BR 关联 3+ 个 PF
+- 业务上下文超过 ~5 行
+- BR 经历过 `/pace-change modify`
+
+**溢出后 project.md 变化**：
+1. 价值功能树中该 BR 行改为链接格式（见功能树格式校验规则中的"已溢出 BR 行"）
+
+**规则**：
+- 溢出是自动、零摩擦的（对齐 P1 零摩擦原则）
+- 溢出是单向的——一旦溢出不回退
+- 无 `requirements/` 目录的项目不受影响（完全向后兼容）
+- BR 文件格式契约见 `knowledge/_schema/br-format.md`
+
## 溯源标记
project.md 中 Claude 自动生成的内容使用 HTML 注释标记来源，区分用户输入与 Claude 推断。标记不影响 Markdown 渲染，仅在深入层（/pace-trace 或 --detail）时可见。
@@ -314,7 +462,11 @@ project.md 中 Claude 自动生成的内容使用 HTML 注释标记来源，区
## 更新时机
+- 愿景在 `/pace-biz` 或 `/pace-init full` 时引导填充（人类内容，Claude 不自动推断）
+- 战略上下文在 `/pace-biz` 或讨论战略时填充，假设状态由人类维护
- 价值功能树在 CR 创建/状态变更时由 Claude 自动更新
+- Epic 创建时在树中追加 Epic 链接行，Epic 文件独立管理
+- BR 创建时在树中追加 BR 行，溢出触发后改为链接格式
- 业务目标和成效指标由人类维护
- 实施路径的 Step 状态在对应阶段完成时更新
- 发布记录在 Release 创建/状态变更时自动更新（有 Release 流程时）
@@ -322,4 +474,5 @@ project.md 中 Claude 自动生成的内容使用 HTML 注释标记来源，区
- 项目原则在 `/pace-retro` 或技术/产品决策讨论后更新
- 功能规格在 PF 相关 CR 进入 verifying 或 /pace-change 涉及该 PF 时更新
- PF 溢出触发时，功能规格段落迁移到 `features/PF-xxx.md`，树视图更新为链接格式
+- BR 溢出触发时，树视图 BR 行改为链接格式
- 偏好角色在用户通过 `/pace-role set-default` 设置时更新
diff --git a/knowledge/_schema/state-format.md b/knowledge/_schema/state-format.md
index d419fc3..daab114 100644
--- a/knowledge/_schema/state-format.md
+++ b/knowledge/_schema/state-format.md
@@ -8,20 +8,22 @@
state.md 是会话启动的唯一必读文件
总行数 ≤ 15 行（按复杂度自适应：简单 5-8 / 中等 10-12 / 复杂 13-15）
必含：目标摘要 + 当前工作 + 下一步
-可选：迭代行（有 iterations/ 时）、关键决策（中等+）、风险关注（复杂）、发布状态（有 Release 时）
+可选：专题行（有 epics/ 时）、迭代行（有 iterations/ 时）、关键决策（中等+）、风险关注（复杂）、发布状态（有 Release 时）
不包含：完整 CR 列表、度量数据、质量检查详情
-最小状态（v0.8.0 init）：仅目标摘要 + 当前工作 + 下一步，无迭代行
+最小状态（v0.8.0 init）：仅目标摘要 + 当前工作 + 下一步，无专题行/迭代行
```
## 必需内容
-### 头部 blockquote（1-2 行）
+### 头部 blockquote（1-3 行）
```markdown
> 目标：[业务目标简述] → 成效指标：[关键 MoS]
+> 专题：[活跃 Epic 数] 进行中 | [完成 Epic 数] 已完成
> 迭代：[迭代 ID]（[迭代目标]）| 进度：M/N 产品功能已完成
```
+专题行为可选——无 Epic 时不显示（向后兼容）。有 Epic 时显示活跃和已完成的 Epic 计数。
迭代行为可选——最小初始化时不含迭代行，首次 `/pace-plan` 后添加。目标行中 MoS 可为空（显示为 `成效指标：（待定义）`）。
### 当前工作（列表）
@@ -64,7 +66,7 @@ Claude 下次会话应该做什么的建议。人类可以修改此字段来指
记录已向用户解释过的系统行为，用于渐进教学去重（同一行为终身只教一次）。
-合法标记值：`cr`（自动创建 CR）、`gate1`（Gate 1 质量检查）、`review`（等待 review）、`change`（变更意图检测）、`tree`（功能树更新）、`merge`（merged 连锁更新）、`accept`（AI 验收验证）、`opt-in-explained`（推进模式 opt-in 确认已解释过）、`context_generated`（context.md 自动生成）、`discover_retro`（功能发现：/pace-retro）、`discover_change`（功能发现：/pace-change）、`discover_plan`（功能发现：/pace-plan）、`discover_release`（功能发现：/pace-release）、`discover_feedback_report`（功能发现：/pace-feedback report）、`first_merged`（首个 CR merged 回顾）。
+合法标记值：`cr`（自动创建 CR）、`gate1`（Gate 1 质量检查）、`review`（等待 review）、`change`（变更意图检测）、`tree`（功能树更新）、`merge`（merged 连锁更新）、`accept`（AI 验收验证）、`opt-in-explained`（推进模式 opt-in 确认已解释过）、`context_generated`（context.md 自动生成）、`discover_retro`（功能发现：/pace-retro）、`discover_change`（功能发现：/pace-change）、`discover_plan`（功能发现：/pace-plan）、`discover_release`（功能发现：/pace-release）、`discover_feedback_report`（功能发现：/pace-feedback report）、`first_merged`（首个 CR merged 回顾）、`discover_scope`（功能发现：/pace-biz discover 探索式需求发现）、`import_requirements`（功能发现：/pace-biz import 多源需求导入）。
- 标记缺失时等同于"全部未教"（向后兼容新老项目）
- Claude 在首次触发对应行为时检查标记，已存在则跳过教学
diff --git a/knowledge/signal-collection.md b/knowledge/signal-collection.md
index f1f122a..4479a22 100644
--- a/knowledge/signal-collection.md
+++ b/knowledge/signal-collection.md
@@ -8,15 +8,17 @@
| # | 数据源 | 读取内容 | 消费信号 |
|:-:|--------|---------|---------|
-| 1 | `.devpace/backlog/*.md` | 所有 CR 的状态字段、类型字段 | S1/S3/S4/S9/S10/S13/S15 |
+| 1 | `.devpace/backlog/*.md` | 所有 CR 的状态字段、类型字段、blocked_by 字段 | S1/S3/S4/S9/S10/S13/S15/S21/S22/S24 |
| 2 | `.devpace/state.md` | 当前工作、下一步、进行中摘要 | S3（上下文连续性） |
| 3 | `.devpace/releases/*.md` | Release 状态字段 | S5 |
| 4 | `.devpace/risks/*.md` | 风险严重度、状态字段 | S2/S6 |
| 5 | `.devpace/iterations/current.md` | PF 完成率、周期字段、变更记录 | S7/S8/S14 |
| 6 | `.devpace/metrics/dashboard.md` | 最近更新日期 | S9 |
-| 7 | `.devpace/project.md` | MoS checkbox、PF 列表、BR 列表 | S12/S13（价值链上下文） |
+| 7 | `.devpace/project.md` | MoS checkbox、PF 列表、BR 列表、Epic 链接、范围 section | S12/S13/S16/S17/S18/S19（价值链上下文+发现信号） |
| 8 | `.devpace/integrations/sync-mapping.md` | CR 关联映射、最后同步时间 | S11 |
| 9 | `.devpace/metrics/insights.md` | 经验 pattern（可选增强） | 经验增强（Step 4） |
+| 10 | `.devpace/epics/*.md` | Epic 状态、MoS、BR 列表、完成度 | S16（Epic 进度信号） |
+| 11 | `.devpace/opportunities.md` | Opportunity 状态 | S17（未处理机会信号） |
## 读取策略
@@ -33,20 +35,49 @@
|--------|------|------|
| CR → PF 映射 | CR 文件中的功能关联字段 | 建议模板附加 PF 名称 |
| PF → BR 映射 | project.md 功能树中 PF 的父 BR | 建议模板附加 BR 名称（Biz/PM 角色） |
+| BR → Epic 映射 | project.md 功能树中 BR 的父 Epic（如有） | 建议模板附加 Epic 信息（Biz 角色） |
| BR → OBJ 映射 | project.md 功能树中 BR 的父 OBJ | 建议模板附加 OBJ 信息（Biz 角色） |
+| Epic → OPP 映射 | Epic 文件中的来源字段 | 建议模板附加 Opportunity 追溯（Biz 角色） |
-**角色差异化**：Dev 仅采集 CR→PF 层 | PM 采集到 PF+迭代层 | Biz 采集到 PF+BR+OBJ 层。
+**角色差异化**：Dev 仅采集 CR→PF 层 | PM 采集到 PF+BR+迭代层 | Biz 采集到 PF+BR+Epic+OBJ+OPP 层。
-## 信号快照缓存（中期优化）
+## 信号快照缓存
-当 pace-pulse 执行后，可将信号快照写入 `.devpace/.signal-cache`：
+### 写入方
+
+pace-pulse 执行信号采集后，将结果写入 `.devpace/.signal-cache`：
```
-# .signal-cache format (plain text)
+# .signal-cache (plain text, auto-generated)
timestamp:
-triggered: S1(count=2), S8(rate=85%)
+cr_summary: total=N, developing=N, in_review=N, merged=N, paused=N
+triggered: S1(count=2), S8(rate=85%), S13(pf=PF-003)
+top_signal: S1
+risk_summary: open=N, high=N
```
-pace-next 检测到新鲜快照（< 5 分钟）时可直接读取，避免重复扫描。快照超期或不存在时正常执行完整采集。
+**写入时机**：
+- pace-pulse session-start 完成信号检测后
+- pace-pulse core 周期性检查完成后
+
+### 读取方
+
+pace-next 和 pace-status 在执行信号采集前，先检查缓存：
+
+1. 检查 `.devpace/.signal-cache` 是否存在
+2. 存在 → 读取 `timestamp` 字段，计算距当前时间的差值
+3. 差值 < 5 分钟 → **命中缓存**，直接使用 `triggered` 和 `top_signal` 字段，跳过完整采集
+4. 差值 ≥ 5 分钟 或文件不存在 → **缓存过期**，执行完整采集流程
+
+### 缓存失效
+
+以下事件使缓存立即失效（消费方忽略缓存，重新采集）：
+- CR 状态变更（merged/paused/created 等）后，pace-dev 会写入新的 CR 文件，时间戳自然超过缓存
+- 用户手动删除 `.signal-cache`
+- **不主动删除缓存**——依靠 TTL（5 分钟）自然过期
+
+### 容错
-**当前阶段**：各 Skill 独立执行采集步骤（引用本文件的读取规则），缓存机制待后续实现。
+- `.signal-cache` 格式错误或字段缺失 → 视为过期，执行完整采集
+- `.signal-cache` 不在 .gitignore 中（每次写入覆盖，无需版本控制）
+- 缓存仅是性能优化，不是正确性依赖——任何异常都 fallback 到完整采集
diff --git a/knowledge/signal-priority.md b/knowledge/signal-priority.md
index f8e0eca..956d714 100644
--- a/knowledge/signal-priority.md
+++ b/knowledge/signal-priority.md
@@ -4,7 +4,7 @@
## §0 速查卡片
-**优先级分组**：Blocking → In Progress → Delivery → Strategic → Growth → Idle
+**优先级分组**：Blocking → In Progress → Delivery → Strategic → Growth（含 Epic/OPP/discover 信号）→ Idle
**引用方式**：各 Skill 按"可见信号子集"列选择性暴露。修改任何信号的条件或编号时，同步检查三个消费方。
@@ -49,12 +49,19 @@
| S13 | 功能未开始 | `project.md` 有 PF 无对应 CR | "功能 [PF 名] 还没开始——是 [BR 名] 的关键组成" | → 说"帮我实现 [PF 名]" | ✅ |
| S14 | 规划新迭代 | 上一迭代已关闭 + `current.md` 不存在 | "上一迭代已结束——规划新迭代" | → /pace-plan | ❌ |
| S15 | 全部完成 | `backlog/` 全部 CR 为 merged 或 released | "所有任务完成——开始新功能或回顾" | 自然语言 | ✅ |
+| S16 | Epic 需分解 | `epics/` 中有 `规划中` 状态 Epic 且 BR 列表为空 | "专题 [Epic 名] 已创建但还没分解为需求" | → /pace-biz decompose [EPIC] | ❌ |
+| S17 | 未评估机会 | `opportunities.md` 中有 `评估中` 状态 Opportunity > 0 | "有 N 个业务机会待评估" | → /pace-biz epic [OPP] | ❌ |
+| S18 | 功能树稀疏 | `project.md` PF 数量 < 3 且项目创建 > 7 天 | "功能树还很稀疏，建议探索需求或从文档导入" | → /pace-biz discover 或 /pace-biz import | ❌ |
+| S19 | 范围未定义 | `project.md` "范围" section 为桩或不存在 | "项目范围尚未定义，建议通过需求发现明确边界" | → /pace-biz discover | ❌ |
+| S21 | 跨 CR 依赖阻塞 | `backlog/` 中 CR-A `blocked_by` 字段指向 CR-B 且 CR-B 状态非 merged/developing 超 3 天（`blocked_by` 字段存在时才检测） | "[CR-A] 被 [CR-B] 阻塞且 [CR-B] 已 N 天未推进" | → /pace-dev #B 或 /pace-change reprioritize | ❌ |
+| S22 | 技术债积压 | `backlog/` 中 `tech-debt` 类型 CR 占比 > 30% 或数量 > 5 | "技术债务 CR 占比偏高（N%），建议安排偿还" | → /pace-plan adjust | ❌ |
+| S24 | 首次循环引导 | `backlog/` 中无 merged 状态 CR 且存在 ≥1 个 developing CR | "第一个功能正在进行中——完成后 /pace-review 审批即可体验完整循环" | 自然语言 | ❌ |
### Idle（无信号）
| ID | 信号 | 条件 | 建议模板 | 命令引导 | status-subset |
|:--:|------|------|---------|---------|:------------:|
-| S16 | 无信号 | 无任何信号命中 | "当前无紧急事项，可以自由探索或规划新目标" | 自然语言 | ❌ |
+| S20 | 无信号 | 无任何信号命中 | "当前无紧急事项，可以自由探索或规划新目标" | 自然语言 | ❌ |
## 角色重排序规则
@@ -76,7 +83,7 @@ S3-S15 范围内，以下角色可在组内重排序（提升最多 1 个组级
| 消费方 | 可见子集 | 引用方式 |
|--------|---------|---------|
-| pace-next | 全部 S1-S16 | 从高到低遍历，取首个命中；detail 模式取 top-3 |
+| pace-next | 全部 S1-S24 | 从高到低遍历，取首个命中；detail 模式取 top-3 |
| pace-status 概览 | `status-subset = ✅` 的信号（S1/S3/S5/S8/S9/S13/S15） | 取 top-1，追加"（详情 → /pace-next）" |
| pace-pulse session-start | 全部（独立阈值版本，见 pulse-procedures-session-start.md） | 分层摘要 ≤3 行 |
diff --git a/knowledge/theory.md b/knowledge/theory.md
index 28cb11a..b0a9898 100644
--- a/knowledge/theory.md
+++ b/knowledge/theory.md
@@ -83,10 +83,27 @@ BizDevOps 核心主张：**概念模型是一切的基础**——没有统一的
作业对象是价值交付链路上的基本单元，随时间发生状态迁移和流转。
+### 3.0a 业务机会（Opportunity）
+
+- **定义**：外部或内部信号中识别到的潜在业务价值点
+- **来源**：用户反馈、竞品观察、技术发现、市场趋势、内部洞察
+- **特点**：是原始输入信号，需要经过评估才能转化为具体的 Epic 或 BR
+- **核心观点**：业务机会是价值链的最上游——它连接了外部世界（客户、市场、技术变化）和内部规划（Epic、BR）。不是所有机会都值得追踪，但被捕获的机会提供了需求的源头追溯
+
+### 3.0b 专题（Epic）
+
+- **定义**：为实现某个业务目标而组织的一组相关业务需求的集合
+- **来源**：业务机会评估、战略规划、业务目标分解
+- **特点**：
+ - 比单个 BR 粒度更大，通常跨多个迭代
+ - 有自己的成效指标（MoS），用于衡量专题级别的业务成果
+ - 是"拥抱不确定性"的载体——专题用 MoS 衡量成果而非固定范围
+- **核心观点**：专题是连接"业务目标"和"具体需求"的中间层。一个业务目标可以分解为多个专题，每个专题聚焦一个业务主题
+
### 3.1 业务需求（BR - Business Requirement）
- **定义**：从业务视角提出的需求，描述"业务上要什么"
-- **来源**：业务机会、市场分析、用户反馈、战略规划
+- **来源**：Epic 分解、业务机会、日常需求（快速注入）
- **特点**：面向业务目标，由业务团队/产品经理提出
- **核心观点**：业务需求来源于业务机会，是产品和交付团队为了抓住业务机会而采取的具体行动
@@ -124,13 +141,13 @@ BizDevOps 核心主张：**概念模型是一切的基础**——没有统一的
### 对象间的分解关系
```
-BR（业务需求）—— 1:N ——→ PF（产品功能）—— 1:N ——→ CR（变更请求）—— N:1 ——→ Release（发布）
- │
- ↓
- Application（应用）
+Opportunity（业务机会）—— 评估 ——→ Epic（专题）—— 1:N ——→ BR（业务需求）—— 1:N ——→ PF（产品功能）—— 1:N ——→ CR（变更请求）—— N:1 ——→ Release（发布）
+ │ │
+ ↑ ↓
+ OBJ（业务目标） Application（应用）
```
-一个 BR 可分解为多个 PF；一个 PF 可分解为多个 CR（当涉及多个应用时）；多个 CR 可组合为一次 Release。
+业务机会经评估可转化为 Epic；一个 Epic 可分解为多个 BR；一个 BR 可分解为多个 PF；一个 PF 可分解为多个 CR（当涉及多个应用时）；多个 CR 可组合为一次 Release。日常需求可跳过 Opportunity/Epic 直接创建 BR。
---
@@ -454,7 +471,9 @@ BizDevOps 通过"专题模式"明确表态：**变更不是异常，是常态。
| BizDevOps 概念 | 概念层级 | devpace 实现 | 对应文件 |
|---------------|---------|-------------|---------|
| **作业对象** | | | |
-| 业务需求（BR） | 对象 | BR 节点（project.md 价值追溯树顶层） | `.devpace/project.md` |
+| 业务机会（Opportunity） | 对象 | opportunities.md 段落条目 | `.devpace/opportunities.md` |
+| 专题（Epic） | 对象 | EPIC-xxx.md 独立文件（有 MoS、BR 列表、生命周期） | `.devpace/epics/EPIC-*.md` |
+| 业务需求（BR） | 对象 | BR 节点（project.md 树视图内联，溢出后 requirements/BR-xxx.md） | `.devpace/project.md`, `.devpace/requirements/BR-*.md` |
| 产品功能（PF） | 对象 | PF 节点（project.md 中层） | `.devpace/project.md` |
| 变更请求（CR） | 对象 | CR-xxx.md 文件（type:feature/defect/hotfix） | `.devpace/backlog/CR-*.md` |
| 发布（Release） | 对象 | REL-xxx.md 文件（staging→deployed→verified→closed） | `.devpace/releases/REL-*.md` |
@@ -468,7 +487,7 @@ BizDevOps 通过"专题模式"明确表态：**变更不是异常，是常态。
| 门禁 | 规则 | 质量检查 checkbox | `.devpace/rules/checks.md` |
| 配置化规则 | 规则 | 项目自定义 checks.md | `.devpace/rules/checks.md` |
| **价值链路** | | | |
-| 端到端追溯 | 链路 | BR→PF→CR→Release 价值追溯树 | `.devpace/project.md` |
+| 端到端追溯 | 链路 | OPP→Epic→BR→PF→CR→Release 价值追溯树 | `.devpace/project.md` |
| 双向追溯 | 链路 | project.md 树状视图 | `.devpace/project.md` |
| 缺陷追溯 | 链路 | defect CR 根因分析→引入 CR→预防措施 | defect CR 根因分析 section |
| **角色模型** | | | |
diff --git a/promt.md b/promt.md
new file mode 100644
index 0000000..fb31b97
--- /dev/null
+++ b/promt.md
@@ -0,0 +1,272 @@
+对/Users/jinhuasu/Project_Workspace/Anker-Projects/ml-platform-research/llm-platform-solution/claude-code-forge/devpace/skills/pace-init/SKILL.md 这个skill的token效率进行评估
+
+/Users/jinhuasu/Project_Workspace/Anker-Projects/ml-platform-research/llm-platform-solution/claude-code-forge/devpace/tests/scenarios 是怎么来的，适合将这些以场景测试为种子喂给 skill-creator吗
+
+
+
+ 核心原则：所有 18 个 Skill 都应有完整的三层评估用例（trigger + behavioral + full cycle），优化点在于何时执行什么级别，而非为谁准备什么级别。
+
+
+
+
+ 设计要点
+
+ - 跨 Skill 交叉污染：每个 trigger eval 的 10 条负面测试包含兄弟 Skill 的典型查询（如 pace-dev 负面测试包含 pace-change 的"加需求"）
+ - 共享断言模式：引用 SA-01~SA-06 避免重复定义（state_updated、cr_lifecycle、natural_language、p2_progressive、git_committed、schema_compliant）
+ - 场景覆盖：每个 Skill 覆盖正常流程、边界条件（空参数、未初始化项目）、错误恢复（rejection、interrupted review）
+
+ 下一步
+
+ 用 /skill-creator 逐 Skill 运行评估（Phase A.3-A.4），优化 description 和行为。剩余 12 Skill 按相同模式扩展（Phase A.5）。
+
+
+ /skill-creator 对/Users/jinhuasu/Project_Workspace/Anker-Projects/ml-platform-research/llm-platform-solution/claude-code-forge/devpace/skills/pace-init/SKILL.md
+ 这个skill的token效率进行评估
+
+ /skill-creator
+ 为这个skill：/Users/jinhuasu/Project_Workspace/Anker-Projects/ml-platform-research/llm-platform-solution/claude-code-forge/devpace/skills/pace-init/SKILL.md，添加更为丰富的评估
+
+
+────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
+❯ /skill-creator
+ 为这个skill：/Users/jinhuasu/Project_Workspace/Anker-Projects/ml-platform-research/llm-platform-solution/claude-code-forge/devpace/skills/pace-init/SKILL.md，建立全面深入的测试与评估
+
+ devpace作为bizdevops全生命周期各种活动的管理器，从业务、需求、迭代、开发、测试、发布等，目前的最新的实现中devpace都有对应的skills覆盖，作为一个bizdevops专家，你从devpace提供的skills是否完整、流畅地提供给最终用户使用，以便这些用户可以使用devpace完成基于AI的bizdevops全生命周期活动进行审查。
+ 审查可以从宏观到微观、从整体到局部，从粗粒度到细粒度。最终提供提供改进方案，让devpace成为世界上最优秀、最受访问的bizdevops全生命周期活动的AI工具
+
+
+ devpace作为bizdevops全生命周期各种活动的管理器，需要分析devpace在
+ 业务需求（BR - Business Requirement）和 产品需求/产品功能（PF - Product Feature），如下截图所示的
+ 业务规划、客户诉求、市场洞察、产品和技术规划，战略/策略、愿景、业务目标、产品目标。devpace是否建立了这个阶段清晰的转换和信息关联。
+ 请你在充分理解当前devpace实现现状的基础上为建立优秀的方案，你如果不清晰我要表达的意图请跟我确认
+
+ devpace项目还需要做什么优化和功能增强，才能有效的建立起
+
+CodeArts
+ALM
+
+
+ 截图展示了两个子域（业务规划 + 产品规划）之间的转换链路。我逐一标注 devpace 的覆盖情况：
+
+ 业务规划子域 产品规划子域
+
+ 输入源 ──────────────────→ 业务机会 ────────→ 专题 ──────→ 业务需求 ──────→ 产品特性
+ ┌───────────┐ ❌ ❌ ⚠️ (空壳) ✅(较好)
+ │ 业务规划 │ ❌ 无建模 无漏斗 无实体 仅一行标题 有完整字段
+ │ 客户诉求 │ ❌ 无建模 无来源追溯 无分组能力 无来源/优先级 用户故事/验收标准
+ │ 市场洞察 │ ❌ 无建模 无转化路径 无成功标准关联 无状态 有溢出模式
+ │ 产品技术规划│ ❌ 无建模
+ └───────────┘
+
+
+
+
+ 组织层：
+ 业务线 ❌ → 战略/策略 ❌ → 业务目标 ✅(OBJ) ←对齐→ 产品目标 ❌ ← 愿景 ⚠️ (一行) ← 产品线 ❌
+
+ 管理层：
+ 投资组合 ❌ 成功标准 ✅(MoS,仅关联OBJ) 需求工作流 ⚠️ (CR有,BR→PF无) 版本规划 ✅
+
+ ┌──────────┬──────────────────────────────┐
+ │ 阶段 │ 能力 │
+ ├──────────┼──────────────────────────────┤
+ │ 需求管理 │ 需求采集、追踪、变更控制 │
+ ├──────────┼──────────────────────────────┤
+ │ 项目规划 │ 迭代规划、资源分配、里程碑 │
+ ├──────────┼──────────────────────────────┤
+ │ 开发管理 │ 代码管理、分支策略、构建集成 │
+ ├──────────┼──────────────────────────────┤
+ │ 测试管理 │ 测试用例、执行、缺陷追踪 │
+ ├──────────┼──────────────────────────────┤
+ │ 发布管理 │ 部署流水线、版本控制、审批流 │
+ ├──────────┼──────────────────────────────┤
+ │ 运维反馈 │ 监控、事件管理、反馈闭环 │
+ └──────────┴──────────────────────────────┘
+
+ ┌─────────────────┬────────────────────────────┐
+ │ 传统 ALM 概念 │ devpace 对应 │
+ ├─────────────────┼────────────────────────────┤
+ │ Epic / Feature │ BR（Business Requirement） │
+ ├─────────────────┼────────────────────────────┤
+ │ User Story │ PF（Product Feature） │
+ ├─────────────────┼────────────────────────────┤
+ │ Task / Sub-task │ CR（Change Request） │
+ ├─────────────────┼────────────────────────────┤
+ │ 需求→代码追溯 │ BR→PF→CR 价值链 │
+ ├─────────────────┼────────────────────────────┤
+ │ 质量门禁 │ Gate 1/2/3 │
+ ├─────────────────┼────────────────────────────┤
+ │ 状态工作流 │ CR 状态机 │
+ └─────────────────┴────────────────────────────┘
+
+
+
+
+如下的问题，导致devpace这个项目无法兑现服务bizdevops全生命周期活动的承诺。我认为应该覆盖从 BR 向上几乎是空白的部分。
+问题说明：
+ 关键断裂点
+ 截图的价值流：
+ 业务规划/客户诉求/市场洞察 → 业务机会 → 专题 → 业务需求 → 产品特性 → 版本规划
+
+ devpace 的实现：
+ [完全空白] ─────────────────→ BR(一行标题) → PF(较完善) → CR(非常完善)
+ ↑
+ 断裂点：BR 是"空壳"
+
+另外截图中的概念并不是全部必须，比如：业务线，产品线， 投资组合是否不用考虑，对于其他的概念模型，你需要分析或者设计最为合适的实体关系图，这些实体关系图是设计skill覆盖价值流的关键
+ ┌───────────────────┬────────────────┬──────────────────────────────────────────────────┐
+ │ 截图中的概念 │ devpace 覆盖度 │ 现状说明 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 业务线 │ 无 │ 不存在此概念 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 战略/策略 │ 无 │ 不存在，被 OBJ 隐含 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 业务目标 │ 较好 │ 已建模为 OBJ，有 MoS checkbox │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 日常需求 │ 无 │ 不存在从日常需求到 BR 的转化路径 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 业务机会 │ 无 │ 不存在"业务机会→专题→BR"的漏斗 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 专题（Epic） │ 无 │ 不存在独立概念，BR 勉强对应但缺乏结构 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 投资组合 │ 无 │ 不存在 BR/专题间的优先级排序和资源分配 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 成功标准 │ 较好 │ MoS 覆盖，但仅关联 OBJ，不关联专题 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 产品线 │ 无 │ 不存在此概念 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 愿景 │ 弱 │ project.md 一句话 blockquote，无结构化字段 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 产品目标 │ 无 │ 不存在独立概念，通过 OBJ→BR→PF 间接关联 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 业务需求/产品特性 │ 极弱→较好 │ BR 仅一行标题（极弱）；PF 有完整字段体系（较好） │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 需求工作流 │ 部分 │ PF→CR 有状态机，但 BR→PF 无显式工作流 │
+ ├───────────────────┼────────────────┼──────────────────────────────────────────────────┤
+ │ 版本规划 │ 较好 │ Release 生命周期完善 │
+ └───────────────────┴────────────────┴──────────────────────────────────────────────────┘
+
+
+
+
+
+
+
+
+devpace作为bizdevops全生命周期各种活动的管理器，从业务、需求、迭代、开发、测试、发布等，目前的最新的实现中devpace都有对应的skills覆盖，作为一个bizdevops专家，在充分理解devpace项目的最新状态和产品愿意用户价值基础上，你从devpace提供的skills是否完整、流畅地提供给最终用户使用，以便这些用户可以使用devpace完成基于AI的bizdevops全生命周期活动进行审查。审查可以从宏观到微观、从整体到局部，从粗粒度到细粒度。最终提供提供改进方案，让devpace成为世界上最优秀、最受访问的bizdevops全生命周期活动的AI工具
+
+基于这个要求，给出符合要求的重构方案。
+你对我意图和要求如果有不明确必须跟我确认，不要自己猜测
+
+
+第一部分：现状评估
+
+ 1.1 BizDevOps 三域覆盖矩阵
+
+ ┌───────────┬────────────────────┬────────────────────────────────┬─────────────────────────────────┬──────┐
+ │ 域 │ 阶段 │ 对应 Skill │ 覆盖状态 │ 评分 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Biz │ 业务机会识别 │ pace-biz opportunity │ Schema 已定义，Skill 待实现 │ 3/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Biz │ 专题规划 │ pace-biz epic │ Schema 已定义，Skill 待实现 │ 3/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Biz │ 需求分解 │ pace-biz decompose │ Schema 已定义，Skill 待实现 │ 3/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Biz │ 战略对齐 │ pace-biz align │ Schema 已定义，Skill 待实现 │ 3/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Biz │ 需求发现/导入/推断 │ pace-biz discover/import/infer │ Schema 已定义，Skill 待实现 │ 3/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Product │ 迭代规划 │ pace-plan │ 核心完成，adjust/health 待完善 │ 7/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Product │ 变更管理 │ pace-change（9 子命令） │ 完整 │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Product │ 角色视角 │ pace-role（5 角色） │ 完整 │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Dev │ 项目初始化 │ pace-init │ 完整（含 monorepo/迁移/模板） │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Dev │ CR 推进 │ pace-dev │ 完整（状态机 7+1 态，Gate 1-3） │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Dev │ 代码审查 │ pace-review（opus） │ 完整（对抗审查+业务追溯） │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Dev │ 测试策略 │ pace-test（10 子命令） │ 完整（策略+覆盖+AI 验收） │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Dev │ 风险管理 │ pace-guard（5 子命令） │ 完整（预检+监控+趋势） │ 8/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Ops │ 发布管理 │ pace-release（14 子命令） │ 完整（含 rollback/branch/tag） │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Ops │ 外部同步 │ pace-sync（GitHub MVP） │ 部分（Linear/Jira 待扩展） │ 6/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Ops │ 反馈收集 │ pace-feedback │ 完整（defect/hotfix CR 闭环） │ 8/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Observe │ 状态查询 │ pace-status（9 子命令） │ 完整（L1-L3 分级） │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Observe │ 导航推荐 │ pace-next（16 信号组） │ 完整 │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Observe │ 节奏脉搏 │ pace-pulse（自动触发） │ 完整 │ 8/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Observe │ 回顾度量 │ pace-retro（DORA 代理指标） │ 完整 │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Observe │ 决策轨迹 │ pace-trace（三层渐进透明） │ 完整 │ 9/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Knowledge │ 经验积累 │ pace-learn（纠正即学习） │ 完整 │ 8/10 │
+ ├───────────┼────────────────────┼────────────────────────────────┼─────────────────────────────────┼──────┤
+ │ Knowledge │ 理论参考 │ pace-theory（15 子命令） │ 完整 │ 9/10 │
+ └───────────┴────────────────────┴────────────────────────────────┴─────────────────────────────────┴──────┘
+
+ ┌──────────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
+ │ 域 │ 评分 │ 说明 │
+ ├──────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
+ │ Biz 域 │ 6/10 │ Schema 完整且设计优秀（OPP/EPIC/BR），pace-biz Skill 已定义 8 子命令 + 8 procedures，但 S35-S42 验收标准全部未打勾（验证待完成）。与上次审查（3/10）大幅提升 │
+ ├──────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
+ │ Dev 域 │ 9/10 │ 完整：pace-init/dev/test/guard/review 全部实现并验证 │
+ ├──────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
+ │ Ops 域 │ 7.5/10 │ pace-release 完整，pace-sync GitHub MVP 已完成（Phase 19/20 待扩展） │
+ ├──────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
+ │ Observe 域 │ 9/10 │ pace-status/next/pulse/retro/trace 全部完整 │
+ ├──────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
+ │ Knowledge 域 │ 8.5/10 │ pace-learn/theory 完整，devpace-cadence 可视化平台已设计
+
+
+
+ bizdevops-review-v2.md │
+
+
+一块探讨一下，pace-biz 这个
+
+
+ Part IV: 竞争力差异化分析
+
+ 4.1 devpace 独特定位
+
+ ┌────────────────┬────────────────────────────────────────┬─────────────────────────────────────────┬─────────────────────────────┐
+ │ 维度 │ 传统工具 (Jira/Linear/GitHub Projects) │ 通用 AI 编码 (Cursor/Copilot Workspace) │ devpace │
+ ├────────────────┼────────────────────────────────────────┼─────────────────────────────────────────┼─────────────────────────────┤
+ │ 业务到代码追溯 │ 手动关联 │ 无 │ 自动（OBJ->BR->PF->CR） │
+ ├────────────────┼────────────────────────────────────────┼─────────────────────────────────────────┼─────────────────────────────┤
+ │ 变更管理 │ 手动调整看板 │ 无 │ 一等公民，影响分析+有序调整 │
+ ├────────────────┼────────────────────────────────────────┼─────────────────────────────────────────┼─────────────────────────────┤
+ │ 质量门 │ CI/CD 外挂 │ 无 │ 内嵌，4 级 Gate 自动执行 │
+ ├────────────────┼────────────────────────────────────────┼─────────────────────────────────────────┼─────────────────────────────┤
+ │ 跨会话连续性 │ N/A │ 有限 │ 完整（state.md 锚点） │
+ ├────────────────┼────────────────────────────────────────┼─────────────────────────────────────────┼─────────────────────────────┤
+ │ 度量与回顾 │ 需额外配置 │ 无 │ 内建 DORA + 迭代回顾 │
+ ├────────────────┼────────────────────────────────────────┼─────────────────────────────────────────┼─────────────────────────────┤
+ │ 自然语言交互 │ 有限（AI 辅助搜索） │ 代码层面 │ 全流程自然语言驱动 │
+ ├────────────────┼────────────────────────────────────────┼─────────────────────────────────────────┼─────────────────────────────┤
+ │ AI 决策透明度 │ N/A │ 无 │ 完整审计（pace-trace） │
+ └────────────────┴────────────────────────────────────────┴─────────────────────────────────────────┴─────────────────────────────┘
+
+
+ ┌──────────┬──────────────────────────────────────────────┬──────────────────────────────────┐
+ │ 方向 │ 措施 │ 目的 │
+ ├──────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
+ │ 智能编排 │ 引入"旅程模板"，自动编排多 Skill 流程 │ 从"工具集"升级为"智能工作流平台" │
+ ├──────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
+ │ 预测能力 │ 强化 pace-retro forecast + pace-guard trends │ 从"被动管理"升级为"主动预测" │
+ ├──────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
+ │ 生态集成 │ 完成 Phase 19-20 外部同步 + CI/CD 深度集成 │ 从"独立工具"升级为"研发中枢" │
+ ├──────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
+ │ 团队适配 │ 多用户状态隔离 + 角色权限 + 共享仪表盘 │ 从"个人工具"升级为"团队平台" │
+ ├──────────┼──────────────────────────────────────────────┼──────────────────────────────────┤
+ │ 可视化 │ Phase 24 devpace-cadence Next.js 仪表盘 │ 从"CLI 工具"升级为"可视化平台" │
+ └──────────┴──────────────────────────────────────────────┴──────────────────────────────────┘
diff --git a/rules/devpace-rules.md b/rules/devpace-rules.md
index be947de..a190b64 100644
--- a/rules/devpace-rules.md
+++ b/rules/devpace-rules.md
@@ -38,17 +38,21 @@
质量：命令+意图+对抗→自修复→Gate 3 人类审批（IR-2）（§2, §14）
可选：Release/集成/同步——目录或文件存在时生效（§14, §16）| 反馈——.devpace/ 存在即可用，releases/ 启用完整追溯（§14）| 渐进教学——首次触发附 1 句（§15）
PF 溢出：功能规格>15行|3+CR|modify → 自动迁移到 features/PF-xxx.md（§11 连锁更新 + dev-procedures-postmerge.md）
+BR 溢出：3+PF|业务上下文>5行|modify → 自动迁移到 requirements/BR-xxx.md
+Epic：始终独立文件 epics/EPIC-xxx.md · 价值功能树用链接引用 · 无 Epic 时 BR 直挂 OBJ（向后兼容）
+Opportunity：独立看板 opportunities.md · 评估中→已采纳/已搁置/已拒绝 · 采纳后关联 Epic
### 命令分层
| 层级 | 命令 |
|------|------|
| 核心 | /pace-init · /pace-dev · /pace-status · /pace-review · /pace-next |
+| 业务 | /pace-biz（opportunity · epic · decompose · align · view · discover · import · infer） |
| 进阶 | /pace-change · /pace-plan · /pace-retro · /pace-guard · /pace-sync · /pace-role |
| 专项 | /pace-release · /pace-test · /pace-feedback · /pace-theory · /pace-trace |
| 系统 | pace-learn（自动+手动） · pace-pulse — Claude 自动调用 |
-子命令详见各 SKILL.md（权威源）。pace-change 子命令：add · pause · resume · reprioritize · modify · batch · undo · history · apply。
+子命令详见各 SKILL.md（权威源）。pace-biz 子命令：opportunity · epic · decompose · align · view · discover · import · infer。pace-change 子命令：add · pause · resume · reprioritize · modify · batch · undo · history · apply。pace-feedback 子命令：incident open · close · timeline · list。pace-sync 子命令：ci status · ci trigger · ci logs。
### .devpace/ 加载优先级
会话开始=state.md | 推进=CR+workflow+checks | 变更=project+CR | 发布=releases+config | 测试=CR+checks+strategy
@@ -59,6 +63,8 @@ PF 溢出：功能规格>15行|3+CR|modify → 自动迁移到 features/PF-xxx.m
1. 检查项目根目录是否存在 `.devpace/state.md`
2. 存在 → 读取并校验（见 §8 容错规则），用 **1 句自然语言** 报告当前状态和建议
+ - 如有 `developing` 或 `verifying` CR → 在报告中附加模式标识 `[推进中]`（如："[推进中] 上次停在认证模块，继续？"）
+ - 无进行中 CR → 在报告中附加模式标识 `[探索]`（如："[探索] 所有任务已完成，自由探索或规划新目标"）
3. 不存在 → 正常工作，不强制初始化（用户需要时可运行 `/pace-init`）
4. **节奏健康度检测**（state.md 存在时额外执行）：读取 dashboard.md + backlog/ + current.md → 按信号优先级输出分层摘要（最高 1 条完整建议 + 其余触发信号精简列表，≤3 行）。信号定义详见 `skills/pace-pulse/pulse-procedures-session-start.md`（权威源）。无触发时静默
5. 等待用户指令（不自作主张开始工作）
@@ -100,6 +106,8 @@ PF 溢出：功能规格>15行|3+CR|modify → 自动迁移到 features/PF-xxx.m
- 用户说明确修改意图 + **已标记 `opt-in-explained`** → 1 行内联提示后自动 opt-in：`"管理这次开发，开始做 [X]。"`（不等待确认）
- Claude 开始写入或修改项目代码文件 + **本会话已 opt-in** → 自动进入
+**模式切换通知**：从探索切换到推进时，输出 1 行标识——`[探索 → 推进] 开始推进 [PF/CR 名称]`。从推进回到探索（CR merged 或用户退出）时，输出——`[推进 → 探索] [CR 标题] 已完成，回到自由探索`。
+
### 推进行为（按自主级别分化）
**上下文加载**（进入推进模式时）：
@@ -141,6 +149,8 @@ PF 溢出：功能规格>15行|3+CR|modify → 自动迁移到 features/PF-xxx.m
- 用户说"逐个看" → 按常规流程逐个进入 in_review
- 不满足简化审批条件的 CR 不纳入批量提示
+**连续推进模式**：`/pace-dev --batch` 启用。S 复杂度 CR 的 Gate 3 延迟到批量统一审批，L/XL 仍即时审批。详见 `skills/pace-dev/dev-procedures-common.md` 连续推进模式章节。
+
merged 后连锁更新（人类批准后必须执行）：见 §11 第 1 步（5 项连锁更新）。
退出：会话结束，或用户明确切换话题。
@@ -180,6 +190,22 @@ merged 后连锁更新（人类批准后必须执行）：见 §11 第 1 步（5
- 用户问"所有命令""完整命令列表" → 展示完整 3 层（核心 / 进阶 / 专项）
- 不主动推荐用户没触发过的命令层级
+### 无命令体验
+
+用户无需知道命令名，自然语言即可触发所有能力：
+
+| 用户说的 | 触发的能力 |
+|---------|-----------|
+| "我想做一个..." | /pace-biz discover（交互式需求发现） |
+| "帮我做 [功能名]" | /pace-dev（自动创建 CR 并推进） |
+| "这里有份需求文档" | /pace-biz import（多源导入） |
+| "看看现在什么情况" | /pace-status（进度概览） |
+| "为什么选了这个方案" | /pace-trace（决策追溯） |
+| "这个技术方案记录一下" | /pace-trace arch（ADR 架构决策记录） |
+| "代码里有哪些功能还没追踪" | /pace-biz infer（代码推断） |
+
+**原则**：Skill description 中的触发关键词是匹配依据。无命令体验不替代命令——用户显式用命令时，直接路由到对应 Skill。
+
## §4 自动创建变更请求
> **核心**：自动创建 CR 并关联 PF，对用户只说"开始做 X"，不提文件创建。
@@ -311,6 +337,7 @@ Claude 在推进模式中主动监控研发节奏，检测异常信号并输出
- **触发**：每 5 个 checkpoint 或 30 分钟未切换 CR → 自动调用 `pace-pulse`
- **约束**：不打断（附加在 checkpoint 后）| 无信号时静默。去重、配额和冷却规则详见 `skills/pace-pulse/pulse-procedures-core.md` 严重度升级与去重优化章节（权威源）
- **Snooze 唤醒**：在特定节点检测延后变更的触发条件，满足时非打断式提醒。检测时机和规则见 `skills/pace-pulse/pulse-procedures-snooze.md`（权威源）
+- **智能自主性建议**：每 5 个 CR merged 后，pace-pulse 根据 Gate 通过率和打回率建议调整自主级别。建议需用户确认，不自动变更。详见 `skills/pace-pulse/pulse-procedures-core.md` 自主级别评估章节
### 风险感知（`.devpace/risks/` 存在时生效）
diff --git a/skills/pace-biz/SKILL.md b/skills/pace-biz/SKILL.md
new file mode 100644
index 0000000..16ca23e
--- /dev/null
+++ b/skills/pace-biz/SKILL.md
@@ -0,0 +1,191 @@
+---
+description: Use when user says "业务机会", "专题", "Epic", "分解需求", "战略对齐", "业务全景", "业务规划", "需求发现", "头脑风暴", "brainstorm", "导入需求", "从文档导入", "代码分析需求", "技术债务盘点", "discover", "import", "infer", "pace-biz", or wants to create opportunities/Epics, decompose requirements, discover/import/infer features. NOT for implementation (/pace-dev), existing item changes (/pace-change), or iteration planning (/pace-plan).
+allowed-tools: AskUserQuestion, Write, Read, Edit, Glob, Bash, Grep
+argument-hint: "[opportunity|epic|decompose|align|view|discover|import|infer] [EPIC-xxx|BR-xxx] <描述|路径>"
+context: fork
+agent: pace-pm
+---
+
+# /pace-biz — 业务规划域统一入口
+
+管理从业务机会到专题（Epic）到业务需求（BR）的上游价值链。覆盖 Opportunity 捕获、Epic 创建与管理、需求分解、战略对齐检查和业务全景展示。
+
+## 与现有机制的关系
+
+- `/pace-biz`：业务规划域（Opportunity→Epic→BR 的**创建和分解**）
+- `/pace-change`：需求变更域（已有 BR/PF/Epic 的**变更**——add/pause/resume/modify）
+- `/pace-plan`：迭代规划域（PF/CR 的**排期**）
+- `/pace-init`：项目初始化（首次 Vision/Strategy/OBJ 引导）
+- `/pace-init full`：**项目不存在时**，从 0 到 1 建立 .devpace/ + OBJ + 功能树 + 迭代计划（一站式初始化）
+- `/pace-biz discover`：**项目已存在时**，从模糊想法探索新的 OPP→Epic→BR→PF（增量扩展）
+- `/pace-status`：开发状态（CR/PF **开发进度**视图）
+- 协同场景：`/pace-biz discover` 探索需求 → `decompose` 细化 → `/pace-dev` 开始开发
+- 协同场景：`/pace-biz import` 导入文档需求 → `align` 检查对齐 → `/pace-plan` 排期
+- 协同场景：`/pace-biz decompose` 分解出 BR → `/pace-change add` 快速补充 PF → `/pace-dev` 开始开发
+
+## 推荐使用流程
+
+```
+完整业务路径： opportunity → epic → decompose → /pace-dev
+探索式发现： discover → decompose → /pace-plan next
+多源导入： import <文档> → align → /pace-plan next
+代码库推断： infer → align → /pace-dev
+战略对齐检查： align（只读分析）
+业务全景： view（只读展示）
+直接创建 Epic： epic（跳过 Opportunity）
+日常需求注入： /pace-change add（跳过 Opportunity/Epic，走快速路径）
+```
+
+## 输入
+
+$ARGUMENTS：
+
+### 子命令
+
+**创建型**（产出新实体）：
+- `opportunity <描述>` → 捕获业务机会到 opportunities.md
+- `epic [OPP-xxx] <描述>` → 从 Opportunity 转化或直接创建 Epic
+- `decompose ` → 分解 Epic→BR 或 BR→PF
+
+**发现型**（探索和导入需求）：
+- `discover <描述>` → 交互式需求发现，从模糊想法产出 OPP→Epic→BR→PF 候选树
+- `import <路径>...` → 从文档批量提取需求实体，合并到功能树
+- `infer` → 从代码库推断未追踪功能和技术债务
+
+**分析型**（只读查看和检查）：
+- `align` → 检查 OBJ→Epic→BR 战略对齐度，发现孤立实体
+- `view` → 业务全景视图（OPP→EPIC→BR 流）
+
+### 空参数
+
+- （空）→ 智能引导——扫描项目上下文（未处理 Opportunity、活跃 Epic、孤立 BR），给出个性化推荐
+
+## 执行路由表
+
+| 子命令 | 读取 | 写入 | procedures 文件 |
+|--------|------|------|----------------|
+| opportunity | project.md, opportunities.md | opportunities.md | biz-procedures-opportunity.md |
+| epic | opportunities.md, project.md | epics/EPIC-xxx.md, project.md, opportunities.md | biz-procedures-epic.md |
+| decompose | epics/EPIC-xxx.md 或 requirements/BR-xxx.md, project.md | project.md, epics/, requirements/ | biz-procedures-decompose.md |
+| align | project.md, epics/, requirements/, opportunities.md | （只读） | biz-procedures-align.md |
+| view | project.md, epics/, requirements/, opportunities.md | （只读） | biz-procedures-view.md |
+| discover | state.md, project.md, opportunities.md | opportunities.md, epics/, project.md, scope-discovery.md | biz-procedures-discover.md |
+| import | project.md, insights.md | project.md, epics/, requirements/ | biz-procedures-import.md |
+| infer | project.md, src/ | project.md | biz-procedures-infer.md |
+| （空参） | state.md, project.md, opportunities.md | （只读） | 内联智能引导 |
+
+## 流程
+
+### 所有子命令的公共前置
+
+1. 读取 state.md 和 project.md 确认项目上下文
+2. 确认 .devpace/ 已初始化（未初始化时引导 /pace-init）
+3. 读取 project.md 配置 section 的 `mode` 字段（缺省 = 完整模式，`lite` = 轻量模式）
+4. 按子命令路由到对应 procedures 文件（各 procedure 内部根据 mode 调整行为）
+
+### 空参数引导
+
+当用户无参数调用 `/pace-biz` 时：
+
+1. 读取 project.md 的 `mode` 字段判断模式
+2. **完整模式**（默认）：
+ - 扫描 opportunities.md 中 `评估中` 的 Opportunity 数量
+ - 扫描 epics/ 中 `进行中` 和 `规划中` 的 Epic 数量
+ - 扫描 project.md 树视图中未关联 Epic 的"孤立" BR 数量
+ - 推荐优先级：未评估 Opportunity > 规划中 Epic 需分解 > 战略对齐
+ - 附完整子命令列表
+3. **lite 模式**：
+ - 扫描 project.md 树视图中 OBJ 下的 PF 数量和状态
+ - 推荐：discover（探索新功能）> import/infer（导入/推断）> align（对齐检查）
+ - 隐藏 opportunity/epic/decompose（Epic→BR 路径），仅展示 lite 兼容子命令
+ - 提示：如需 OPP/Epic/BR 能力，可通过 `/pace-init --upgrade-mode` 升级到完整模式
+
+## 输出
+
+### 所有子命令的通用输出原则
+
+- **渐进暴露**：默认输出简洁摘要，`--detail` 展示完整信息
+- **操作确认**：写入操作前展示变更预览，用户确认后执行
+- **追溯链**：每次创建实体时展示其在价值链中的位置
+
+### opportunity 输出
+
+```
+已捕获业务机会：OPP-xxx — [描述]
+来源：[类型]（[详情]）
+状态：评估中
+→ 下一步：/pace-biz epic OPP-xxx 评估并转化为 Epic
+```
+
+### epic 输出
+
+```
+已创建专题：EPIC-xxx — [名称]
+关联：OBJ-x（[目标]）← OPP-xxx（如有）
+MoS：[指标列表]
+→ 下一步：/pace-biz decompose EPIC-xxx 分解为业务需求
+```
+
+### decompose 输出
+
+```
+已分解 [EPIC-xxx|BR-xxx]：
+├── BR-001：[名称] P0
+├── BR-002：[名称] P1
+└── BR-003：[名称] P2
+→ 下一步：/pace-change add 补充 PF 或 /pace-dev 开始开发
+```
+
+### align 输出
+
+```
+战略对齐度报告：
+- OBJ 覆盖率：N/M OBJ 有 Epic 覆盖
+- 孤立实体：[列表]
+- 对齐建议：[建议]
+```
+
+### view 输出
+
+```
+业务全景：
+OPP-001（评估中）
+OPP-002 → EPIC-001（进行中）
+ ├── BR-001 → PF-001 → CR-001 🔄
+ └── BR-002 → PF-002（待开始）
+OPP-003 → EPIC-002（规划中）
+```
+
+### discover 输出
+
+```
+已从发现会话创建：
+- 1 个业务机会（OPP-xxx）
+- 1 个专题（EPIC-xxx）
+- N 个业务需求（BR-xxx ~ BR-xxx）
+- M 个产品功能（PF-xxx ~ PF-xxx）
+→ /pace-biz decompose EPIC-xxx 继续细化
+→ /pace-plan next 排入迭代
+```
+
+### import 输出
+
+```
+导入完成（来自 N 个文件）：
+- 新增：X 个 BR + Y 个 PF
+- 丰富：Z 个已有实体
+- 跳过：W 个重复项
+→ /pace-biz align 检查战略对齐度
+→ /pace-plan next 排入迭代
+```
+
+### infer 输出
+
+```
+代码库推断完成：
+- 新增追踪：X 个产品功能
+- 技术债务：Y 个待处理项
+- 未实现确认：Z 个功能状态已更新
+→ /pace-biz align 检查战略对齐度
+→ /pace-dev 开始处理优先项
+```
diff --git a/skills/pace-biz/biz-procedures-align.md b/skills/pace-biz/biz-procedures-align.md
new file mode 100644
index 0000000..d7b004c
--- /dev/null
+++ b/skills/pace-biz/biz-procedures-align.md
@@ -0,0 +1,82 @@
+# align 子命令 procedures
+
+> **职责**：检查 OBJ→Epic→BR 战略对齐度，发现孤立实体和覆盖缺口。
+
+## 触发
+
+`/pace-biz align` 或用户想检查战略对齐。
+
+## 步骤
+
+### Step 0：模式检查
+
+读取 project.md 的 `mode` 字段。若为 `lite`：
+
+- 跳过 Step 2.2 中 Epic 相关检查（孤立 BR、空 Epic、未处理 Opportunity）
+- 跳过 Step 2.3 中 Epic 级 MoS 检查
+- 对齐检查简化为：OBJ 覆盖率（OBJ→PF）+ 孤立 PF 检测 + OBJ 级 MoS 完整性 + 价值链完整性（OBJ→PF→CR）
+
+### Step 1：采集实体数据
+
+读取以下文件：
+1. `project.md` — OBJ 列表、价值功能树（Epic→BR→PF→CR 关系）
+2. `epics/` — 所有 Epic 文件（状态、MoS、BR 列表）
+3. `requirements/` — 溢出的 BR 文件（如有）
+4. `opportunities.md` — 未处理的 Opportunity（如有）
+
+### Step 2：分析对齐度
+
+执行以下检查：
+
+#### 2.1 OBJ 覆盖率
+
+- 每个 OBJ 是否至少有一个 Epic 或 BR？
+- 没有 Epic/BR 的 OBJ 标记为"未覆盖"
+
+#### 2.2 孤立实体检测
+
+- BR 未关联任何 Epic 也未直接挂 OBJ → 孤立 BR
+- PF 未关联任何 BR → 孤立 PF
+- Epic 中 BR 列表为空 → 空 Epic（需分解）
+- Opportunity 状态长期为"评估中" → 未处理的机会
+
+#### 2.3 MoS 完整性
+
+- OBJ 有 MoS 定义？
+- Epic 有 MoS 定义？
+- MoS 与 BR/PF 完成度的对应关系是否合理？
+
+#### 2.4 价值链完整性
+
+- 检查每条从 OBJ 到 CR 的链路是否连续
+- 标记断裂点（如 BR→PF 为空）
+
+### Step 3：生成对齐报告
+
+```
+战略对齐度报告
+══════════════
+
+OBJ 覆盖率：[N/M] OBJ 有 Epic/BR 覆盖
+├── OBJ-1（[名称]）：[N] Epic, [M] BR — [覆盖/未覆盖]
+└── OBJ-2（[名称]）：[N] Epic, [M] BR — [覆盖/未覆盖]
+
+孤立实体：
+├── 孤立 BR：[列表]（未关联 Epic 或 OBJ）
+├── 空 Epic：[列表]（无 BR，需分解）
+└── 未处理机会：[列表]（评估中 Opportunity）
+
+MoS 完整性：
+├── OBJ 级 MoS：[N/M] 已定义
+└── Epic 级 MoS：[N/M] 已定义
+
+建议：
+1. [具体对齐建议]
+2. [具体对齐建议]
+```
+
+## 注意
+
+- 此子命令为**只读分析**，不修改任何文件
+- 无 Epic 和 Opportunity 时简化报告（只检查 OBJ→BR→PF→CR 链路）
+- 向后兼容：旧项目无 Epic 层时仍能生成有意义的对齐报告
diff --git a/skills/pace-biz/biz-procedures-decompose.md b/skills/pace-biz/biz-procedures-decompose.md
new file mode 100644
index 0000000..15ffbd5
--- /dev/null
+++ b/skills/pace-biz/biz-procedures-decompose.md
@@ -0,0 +1,109 @@
+# decompose 子命令 procedures
+
+> **职责**：分解 Epic→BR 或 BR→PF，填充价值链中间层。
+
+## 触发
+
+`/pace-biz decompose ` 或用户要分解专题/需求。
+
+## 步骤
+
+### Step 0：模式检查
+
+读取 project.md 的 `mode` 字段。若为 `lite`：
+
+- `EPIC-xxx` 参数 → 提示"轻量模式无 Epic 层"，终止
+- `BR-xxx` 参数 → 提示"轻量模式无 BR 层，PF 直接挂在 OBJ 下"，终止
+- 无参数 → 提示"轻量模式下建议使用 `/pace-change add` 添加 PF，或 `/pace-init --upgrade-mode` 升级"，终止
+
+> lite 模式价值链为 OBJ→PF→CR，没有 Epic/BR 层可分解。
+
+### Step 1：确定分解目标
+
+根据参数判断分解方向：
+- `EPIC-xxx` → Epic→BR 分解
+- `BR-xxx` → BR→PF 分解
+- 无参数 → 列出可分解的 Epic/BR，引导选择
+
+### Epic→BR 分解路径
+
+#### Step 2E：读取 Epic 信息
+
+1. 读取 `epics/EPIC-xxx.md`
+2. 确认状态为 `规划中` 或 `进行中`（`已搁置` 需先 resume）
+3. 读取 Epic 背景和 MoS
+
+#### Step 3E：引导需求分解
+
+向用户展示 Epic 背景和 MoS，然后引导分解：
+
+1. 基于 Epic 背景，Claude 建议 BR 分解方案（2-5 个 BR）
+2. 每个 BR 包含：名称 + 优先级建议 + 一句话描述
+3. 用户确认/调整分解方案
+
+#### Step 4E：创建 BR 条目
+
+对每个确认的 BR：
+
+1. 在 project.md 价值功能树中，在对应 Epic 下追加 BR 行：
+ ```
+ BR-xxx：[名称] `Px`
+ ```
+2. BR 编号自增（扫描 project.md 树中最大 BR 编号 +1）
+3. 更新 Epic 文件的"业务需求"表格
+
+#### Step 5E：更新 Epic 状态
+
+如果 Epic 当前为 `规划中` 且有了 BR → 状态改为 `进行中`
+
+### BR→PF 分解路径
+
+#### Step 2P：读取 BR 信息
+
+1. 从 project.md 树视图或 `requirements/BR-xxx.md` 读取 BR 信息
+2. 读取关联 Epic 和 OBJ 上下文
+
+#### Step 3P：引导功能分解
+
+向用户展示 BR 上下文，然后引导分解：
+
+1. 基于 BR 描述，Claude 建议 PF 分解方案（1-3 个 PF）
+2. 每个 PF 包含：名称 + 用户故事建议
+3. 用户确认/调整分解方案
+
+#### Step 4P：创建 PF 条目
+
+对每个确认的 PF：
+
+1. 在 project.md 价值功能树中，在对应 BR 下追加 PF 行：
+ ```
+ PF-xxx：[名称]（[用户故事]）→ (待创建 CR)
+ ```
+2. PF 编号自增（扫描 project.md 树中最大 PF 编号 +1）
+
+#### Step 5P：更新 BR 状态
+
+如果 BR 有溢出文件 → 更新 `requirements/BR-xxx.md` 的 PF 列表
+
+### 公共结束步骤
+
+#### Step 6：输出分解结果
+
+```
+已分解 [EPIC-xxx|BR-xxx]：
+├── [BR|PF]-001：[名称] [优先级]
+├── [BR|PF]-002：[名称] [优先级]
+└── [BR|PF]-003：[名称] [优先级]
+
+价值链：OBJ-x → EPIC-xxx → BR-xxx → PF-xxx
+→ 下一步：/pace-plan next 规划迭代 | 继续分解：/pace-biz decompose [编号]
+```
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| EPIC/BR 编号不存在 | 提示无效编号，列出可用选项 |
+| Epic 状态为"已搁置" | 提示需先 /pace-change resume |
+| 已有 BR/PF 的重复分解 | 展示现有分解，询问是否追加 |
+| project.md 无树结构 | 创建树结构后执行分解 |
diff --git a/skills/pace-biz/biz-procedures-discover.md b/skills/pace-biz/biz-procedures-discover.md
new file mode 100644
index 0000000..08401fd
--- /dev/null
+++ b/skills/pace-biz/biz-procedures-discover.md
@@ -0,0 +1,164 @@
+# discover 子命令 procedures
+
+> **职责**：交互式探索需求发现——从模糊想法出发，通过多轮对话引导产出 OPP→Epic→BR→PF 候选树。
+
+## 触发
+
+`/pace-biz discover <描述>` 或用户表达模糊需求想法（"我想做一个..."、"有没有可能..."、"头脑风暴一下"）。
+
+## 与 decompose 的区别
+
+- **discover**：从零开始的全链路探索，输入是模糊想法，输出是 OPP→Epic→BR→PF 候选树
+- **decompose**：已有实体的单层精确拆解，输入是 EPIC-xxx 或 BR-xxx，输出是下一层子实体
+
+## 步骤
+
+### Step 0：上下文加载与模式检查
+
+1. 读取 `.devpace/state.md` + `project.md` + `opportunities.md`（不存在则跳过）
+2. 读取 project.md 的 `mode` 字段，记录当前模式（`lite` 或完整）
+3. **空项目检测**：若 project.md 不存在或仅为桩文件（无 OBJ 定义），引导先初始化：
+ > 项目尚未初始化业务目标。建议先运行 `/pace-init full` 一站式建立项目结构，再通过 discover 探索新需求。
+ - 用户坚持继续 → 正常进入 Step 1（discover 降级模式会在 Step 5 输出到控制台）
+4. 检查是否有进行中的发现会话：`.devpace/scope-discovery.md`
+ - 存在 → 读取并提示用户："上次探索到 [阶段]，继续还是重新开始？"
+ - 不存在 → 开始新会话
+
+**lite 模式适配**：后续 Step 1-5 中，所有 OPP/Epic/BR 层跳过：
+- Step 1：OBJ 候选照常映射，不创建 OPP
+- Step 2：功能头脑风暴直接产出 PF 候选（跳过 BR 分组）
+- Step 4：候选树展示为 `OBJ→PF` 结构（无 OPP/Epic/BR 层）
+- Step 5：仅写入 PF 到 project.md 价值功能树对应 OBJ 下，不创建 OPP/Epic/BR 文件
+
+### Step 1：目标框定（1-2 轮 AskUserQuestion）
+
+从用户输入中提取核心意图，通过追问补充关键信息：
+
+**第 1 轮**（若用户已给出描述则跳过）：
+- "要解决什么问题？目标用户是谁？"
+
+**第 2 轮**（基于第 1 轮回答）：
+- "这个对用户来说有多紧迫？是锦上添花还是痛点？"
+- "有没有现有的替代方案？"
+
+**产出**：
+- OBJ 候选（映射到 project.md 已有 OBJ 或建议新 OBJ）
+- 目标用户画像（1-2 句话）
+
+**中间状态持久化**：写入 `.devpace/scope-discovery.md`：
+
+```markdown
+# 需求发现会话
+
+## 阶段：目标框定
+## 开始时间：[YYYY-MM-DD HH:mm]
+
+## 目标
+[用户描述的核心问题]
+
+## 用户画像
+[目标用户描述]
+
+## OBJ 候选
+- [OBJ 映射或新建议]
+```
+
+### Step 2：功能头脑风暴（2-4 轮）
+
+基于 Step 1 的目标，引导用户展开功能想象：
+
+**追问策略**（按轮次渐进深入）：
+
+| 轮次 | 问题方向 | 示例 |
+|------|---------|------|
+| 1 | 核心能力 | "用户必须能做什么？最基本的操作是什么？" |
+| 2 | 场景延伸 | "当 [场景] 发生时怎么办？有没有异常情况？" |
+| 3 | 边界探索 | "需要支持多少用户/数据量？有性能要求吗？" |
+| 4 | 差异化 | "和现有方案相比，最大的不同是什么？" |
+
+每轮回答后 Claude 实时整理为 BR→PF 候选分组，展示给用户确认方向。
+
+**产出**：BR→PF 候选列表（层级分组），追加到 `scope-discovery.md`。
+
+### Step 3：边界定义（1-2 轮）
+
+明确范围边界，防止后续范围蔓延：
+
+- "这个版本明确不做什么？"
+- "有什么技术约束或时间约束？"
+
+**产出**：范围"做/不做"清单，追加到 `scope-discovery.md`。
+
+### Step 4：验证与确认（1 轮）
+
+展示结构化摘要：
+
+```
+需求发现摘要：
+
+目标：[核心问题]
+用户：[目标用户]
+
+候选价值链：
+OBJ-x（[目标]）
+└── OPP-xxx：[机会描述]
+ └── EPIC-xxx：[专题名称]
+ ├── BR-xxx：[需求 1] P0
+ │ ├── PF-xxx：[功能 1a]
+ │ └── PF-xxx：[功能 1b]
+ └── BR-xxx：[需求 2] P1
+ └── PF-xxx：[功能 2a]
+
+范围：
+ 做：[清单]
+ 不做：[清单]
+
+确认后将写入 .devpace/，请检查并调整。
+```
+
+用户可以：调整层级关系、重新排优先级、删除不需要的候选、修改名称。
+
+### Step 5：写入 .devpace/
+
+确认后执行写入（复用现有子命令的创建逻辑）：
+
+1. **OPP**：按 biz-procedures-opportunity.md 的编号和格式写入 `opportunities.md`
+2. **Epic**：按 biz-procedures-epic.md 的格式创建 `epics/EPIC-xxx.md` + 更新 `project.md` 树
+3. **BR**：写入 `project.md` 价值功能树对应 Epic 下（编号自增）
+4. **PF**：写入 `project.md` 价值功能树对应 BR 下（编号自增）
+5. **范围**：写入 `project.md` "范围" section（做/不做清单）
+6. 所有内容标记溯源：``
+7. 触发 PF/BR 溢出检查（按 project-format.md 溢出规则）
+8. 删除 `scope-discovery.md`（发现会话完成）
+9. git commit
+
+### Step 6：下游引导
+
+```
+已从发现会话创建：
+- 1 个业务机会（OPP-xxx）
+- 1 个专题（EPIC-xxx）
+- N 个业务需求（BR-xxx ~ BR-xxx）
+- M 个产品功能（PF-xxx ~ PF-xxx）
+
+→ /pace-biz decompose EPIC-xxx 继续细化特定需求
+→ /pace-biz align 检查战略对齐度
+→ /pace-plan next 排入迭代
+```
+
+## 降级模式
+
+| 场景 | 行为 |
+|------|------|
+| .devpace/ 不存在 | 正常执行 Step 0-4（对话探索），Step 5 输出到控制台不写文件，结尾引导 `/pace-init` |
+| project.md 是桩 | 正常运行，Step 5 填充桩内容（愿景、范围等） |
+| 用户中途放弃 | scope-discovery.md 保留中间状态，下次可继续 |
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| 用户描述过于模糊（< 5 字） | 追加引导问题："能再详细说说吗？比如要解决什么问题？" |
+| scope-discovery.md 格式损坏 | 忽略已有内容，重新开始 |
+| OBJ 映射无匹配 | 建议创建新 OBJ 或跳过 OBJ 映射 |
+| 用户拒绝所有候选 | 尊重决定，删除 scope-discovery.md，不写入任何文件 |
diff --git a/skills/pace-biz/biz-procedures-epic.md b/skills/pace-biz/biz-procedures-epic.md
new file mode 100644
index 0000000..035a242
--- /dev/null
+++ b/skills/pace-biz/biz-procedures-epic.md
@@ -0,0 +1,112 @@
+# epic 子命令 procedures
+
+> **职责**：从 Opportunity 转化或直接创建 Epic，定义 MoS，更新价值功能树。
+
+## 触发
+
+`/pace-biz epic [OPP-xxx] <描述>` 或用户要创建一个专题/Epic。
+
+## 步骤
+
+### Step 0：模式检查
+
+读取 project.md 的 `mode` 字段。若为 `lite`：
+
+> **当前为轻量模式（OBJ→PF→CR），Epic 功能需要完整模式。**
+> - 升级到完整模式：`/pace-init --upgrade-mode`
+> - 或直接添加功能：`/pace-change add <描述>`
+
+终止后续步骤。
+
+### Step 1：确定来源
+
+- 有 `OPP-xxx` 参数 → 读取 opportunities.md 确认 OPP 存在且状态为 `评估中`
+- 无 OPP 参数 → 直接创建模式（来源字段留空或标注"直接创建"）
+
+### Step 2：确定 OBJ 关联
+
+1. 读取 project.md 业务目标 section，列出可用 OBJ
+2. 如果只有 1 个 OBJ → 自动关联
+3. 如果多个 OBJ → 询问用户选择
+4. 如果无 OBJ → 引导先定义业务目标（建议 /pace-init full）
+
+### Step 3：引导定义 Epic 内容
+
+向用户询问（如未在参数中提供）：
+
+1. **专题名称**：一句话描述这个专题
+2. **背景**：2-3 句话，为什么做这个专题
+3. **成效指标（MoS）**：如何衡量这个专题的成功？（可选——渐进填充）
+
+### Step 4：生成 EPIC 编号
+
+1. 扫描 `.devpace/epics/` 目录（不存在则创建）
+2. 取最大 EPIC 编号 +1
+3. 三位补零：`EPIC-001`、`EPIC-002`...
+
+### Step 5：创建 Epic 文件
+
+创建 `.devpace/epics/EPIC-xxx.md`，格式遵循 `knowledge/_schema/epic-format.md`：
+
+```markdown
+# EPIC-xxx：[专题名称]
+
+- **OBJ**：OBJ-x（[目标描述]）
+- **状态**：规划中
+- **来源**：OPP-xxx（[描述]）
+- **时间框架**：（首次 /pace-plan 时填充）
+
+## 背景
+
+[用户提供的背景]
+
+## 成效指标（MoS）
+
+- [ ] [指标 1]
+- [ ] [指标 2]
+
+## 业务需求
+
+| BR | 标题 | 优先级 | 状态 | PF 数 | 完成度 |
+|----|------|:------:|------|:-----:|:------:|
+```
+
+MoS 为空时写：
+```markdown
+## 成效指标（MoS）
+
+（待定义 — /pace-biz decompose 或讨论时填充）
+```
+
+### Step 6：更新 project.md 价值功能树
+
+在对应 OBJ 下追加 Epic 链接行：
+
+```markdown
+OBJ-x（[目标名]）
+├── ... (existing)
+└── [EPIC-xxx：专题名](epics/EPIC-xxx.md)
+```
+
+### Step 7：更新 opportunities.md（如从 OPP 转化）
+
+将对应 OPP 状态改为：`已采纳 → EPIC-xxx`
+
+### Step 8：输出确认
+
+```
+已创建专题：EPIC-xxx — [名称]
+关联：OBJ-x（[目标]）← OPP-xxx（如有）
+MoS：[指标列表] 或 （待定义）
+→ 下一步：/pace-biz decompose EPIC-xxx 分解为业务需求
+```
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| OPP-xxx 不存在 | 提示 OPP 编号无效，列出可用 OPP |
+| OPP 状态非"评估中" | 提示已处理，询问是否仍要创建 Epic |
+| epics/ 目录不存在 | 自动创建 |
+| project.md 无价值功能树 | 创建空树结构后追加 |
+| 无 OBJ | 引导 /pace-init full 或先定义 OBJ |
diff --git a/skills/pace-biz/biz-procedures-import.md b/skills/pace-biz/biz-procedures-import.md
new file mode 100644
index 0000000..2da06d1
--- /dev/null
+++ b/skills/pace-biz/biz-procedures-import.md
@@ -0,0 +1,154 @@
+# import 子命令 procedures
+
+> **职责**：从外部文档（会议纪要、用户反馈、竞品分析等）批量提取需求实体，合并到现有功能树。
+
+## 触发
+
+`/pace-biz import <路径>...` 或用户要从文档中导入需求（"把这份会议纪要的需求导入"、"从 PRD 里提取需求"）。
+
+## 与 init --from 的区别
+
+- **init --from**：项目初始化时使用，从零创建 project.md 功能树
+- **import**：项目已有功能树，增量追加新实体并执行合并分析（去重、冲突检测）
+
+## 步骤
+
+### Step 0：前置检查与模式检查
+
+1. 检查 `.devpace/` 存在（不存在 → 引导 `/pace-init`）
+2. 读取 `project.md` 现有功能树（获取已有实体列表用于合并分析）
+3. 读取 project.md 的 `mode` 字段，记录当前模式
+4. 读取 `metrics/insights.md`（如有，加载导入相关经验 pattern）
+
+**lite 模式适配**：
+- Step 2 实体提取：映射目标仅为 PF（跳过 OPP/Epic/BR 映射），用户故事和功能列表直接提取为 PF 候选
+- Step 3 合并分析：仅对比已有 PF 列表
+- Step 5 写入：PF 直接追加到 project.md 对应 OBJ 下，不创建 Epic/BR
+
+### Step 1：源文件摄入
+
+- **单文件**：`/pace-biz import meeting-notes.md` → 直接读取
+- **目录路径**：`/pace-biz import requirements/` → 扫描目录下所有 `.md`/`.txt` 文件
+- **多文件**：`/pace-biz import doc1.md doc2.md` → 依次读取，合并提取结果
+- 文件过多（>10）时先输出文件列表让用户筛选
+
+**源类型自动检测**：
+
+| 源类型 | 检测特征 | 提取映射 |
+|--------|---------|---------|
+| 会议纪要 | "会议"、"minutes"、"纪要"、日期标题格式 | Action Items → BR/PF 候选 |
+| 用户反馈 | "反馈"、"feedback"、评分模式、用户引用 | 痛点 → BR，功能请求 → PF |
+| 竞品分析 | "竞品"、"competitor"、"对比"、对比表格 | 差距功能 → PF 候选 |
+| 技术债务 | "TODO"、"FIXME"、"tech-debt"、"技术债" | 债务项 → PF 候选（标记技术债务） |
+| Issue 导出 | CSV/JSON 格式（含 title/label/status 字段） | Issues → PF/CR 候选 |
+| PRD / 功能规格 | 用户故事、功能列表、Features section | 同 init --from §1 解析规则 |
+| API 规格 | OpenAPI/Swagger 关键词 | 同 init --from §1 API 特殊处理 |
+
+### Step 2：实体提取
+
+对每个源文件，按检测到的源类型执行提取：
+
+**通用提取规则**（复用 init-procedures-from.md §1 映射表）：
+
+| 文档元素 | 映射目标 | 解析方法 |
+|---------|---------|---------|
+| 用户故事（As a... I want...） | BR（业务需求） | 模式匹配 + 语义分析 |
+| 功能列表 / Features | PF（产品功能）树 | 层级提取 |
+| API 端点列表 | PF（按资源分组） | 结构化解析 |
+| 优先级标记（P0/P1/Must/Should） | 优先级候选 | 标签提取 |
+
+**扩展提取规则**（import 特有）：
+
+| 文档元素 | 映射目标 | 解析方法 |
+|---------|---------|---------|
+| Action Items（会议纪要） | BR/PF 候选 | "决定"、"需要"、"TODO" 关键词 |
+| 用户痛点描述（反馈） | BR 候选 | 负面情感 + 功能关联 |
+| 功能请求（反馈） | PF 候选 | "希望"、"建议"、"能不能" |
+| 竞品差距功能（竞品分析） | PF 候选 | 对比表中我方缺失项 |
+| TODO/FIXME 注释 | PF 候选（技术债务） | 注释模式匹配 |
+
+每个提取的实体记录来源文件和行号，用于溯源。
+
+### Step 3：合并分析
+
+对比提取实体 vs 现有功能树，逐条分类：
+
+| 分类 | 条件 | 处理 |
+|------|------|------|
+| NEW | 无匹配 | 建议添加到功能树 |
+| DUPLICATE | 标题相似度 > 80% | 跳过并注明已有对应实体 |
+| ENRICHMENT | 匹配已有但补充了新信息（验收标准/用户故事） | 建议更新已有实体 |
+| CONFLICT | 与现有定义矛盾 | 标记待决，需用户裁定 |
+
+**相似度判断**：基于标题关键词重叠 + 语义相似度。模糊边界时倾向标记为 NEW（让用户决定）。
+
+### Step 4：用户确认
+
+展示合并计划（diff 格式）：
+
+```
+导入分析（来自 [文件名]）：
+
+NEW（新增 N 项）：
+ + BR-xxx：[名称]（来源：[文件名] L42）
+ + PF-xxx：[名称]（来源：[文件名] L58）
+
+DUPLICATE（已有 M 项）：
+ = [提取名称] ≈ PF-003（已存在，跳过）
+
+ENRICHMENT（丰富 K 项）：
+ ~ PF-002：追加验收标准 "[新标准]"
+
+CONFLICT（冲突 J 项）：
+ ! BR-001 现有定义 "[现有]" vs 导入 "[新]"
+
+逐条确认：accept all / reject all / 逐条选择
+```
+
+CONFLICT 项使用 AskUserQuestion 交互决定保留哪个版本。
+
+### Step 5：执行写入
+
+1. NEW 项：追加到 `project.md` 功能树对应位置
+ - BR 追加到对应 OBJ/Epic 下（无明确归属时追加到树末尾，标记"待归类"）
+ - PF 追加到对应 BR 下
+2. ENRICHMENT 项：更新 `project.md` 中对应 PF/BR 的描述或验收标准
+3. 编号自增（扫描现有最大编号 +1）
+4. 触发 PF/BR 溢出检查
+5. 所有内容标记溯源：``
+6. 若有迭代文件（`iterations/current.md`），追加变更记录
+7. git commit
+
+**不创建 CR**——import 只丰富功能树（OPP/Epic/BR/PF 级别），不涉及开发层。
+
+### Step 6：下游引导
+
+```
+导入完成（来自 [N 个文件]）：
+- 新增：X 个 BR + Y 个 PF
+- 丰富：Z 个已有实体
+- 跳过：W 个重复项
+
+→ /pace-biz align 检查新增内容的战略对齐度
+→ /pace-biz decompose [BR-xxx] 继续细化新增需求
+→ /pace-plan next 排入迭代
+```
+
+## 降级模式
+
+| 场景 | 行为 |
+|------|------|
+| .devpace/ 不存在 | 提示"项目未初始化"，引导 `/pace-init` 或 `/pace-init --from <路径>`（推荐） |
+| project.md 是桩 | 正常运行，跳过合并分析（无现有功能树可对比），直接写入 |
+| 源文件不存在 | 提示路径无效，列出当前目录文件供选择 |
+| 源文件为空 | 提示文件为空，跳过 |
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| 无法识别源类型 | 按通用文本处理，提取关键短语为 PF 候选 |
+| 提取结果为空 | 提示"未从文档中提取到明确的需求实体"，建议手动梳理 |
+| 大文件（>500 行） | 分段处理，每段提取后合并结果 |
+| 二进制文件 | 跳过并提示"不支持二进制文件" |
+| 编号冲突 | 重新扫描确认最大编号后分配 |
diff --git a/skills/pace-biz/biz-procedures-infer.md b/skills/pace-biz/biz-procedures-infer.md
new file mode 100644
index 0000000..66754e0
--- /dev/null
+++ b/skills/pace-biz/biz-procedures-infer.md
@@ -0,0 +1,169 @@
+# infer 子命令 procedures
+
+> **职责**：从当前代码库推断未追踪的功能和技术债务，补充到功能树。
+
+## 触发
+
+`/pace-biz infer` 或用户要从代码分析需求（"看看代码里有什么功能"、"技术债务盘点"、"哪些功能没追踪"）。
+
+## 与其他子命令的区别
+
+- **discover**：从模糊想法出发，通过对话引导产出候选
+- **import**：从文档提取需求实体
+- **infer**：从代码库反向推断已有功能和技术债务
+
+## 步骤
+
+### Step 0：前置检查与模式检查
+
+1. 检查 `.devpace/` 存在（不存在 → 引导 `/pace-init`）
+2. 读取 `project.md` 现有功能树（获取已追踪的 PF 列表）
+3. 读取 project.md 的 `mode` 字段，记录当前模式
+4. 检查 git 仓库状态：
+ - git 可用 → 完整分析（含 blame/hotspot）
+ - git 不可用 → 退化模式（纯目录结构 + 注释扫描）
+
+**lite 模式适配**：
+- Step 1 代码结构分析：模块直接映射为 PF 候选（跳过 BR 候选分组）
+- Step 3 差距分析：仅对比已有 PF 列表（无 BR 对比）
+- Step 5 写入：PF 直接追加到 project.md 对应 OBJ 下，技术债务归入"技术债务" PF 分组（非 BR）
+
+### Step 1：代码结构分析
+
+扫描源码目录，建立模块→功能映射：
+
+**源码根目录检测**（按优先级）：
+- `src/` → 标准源码目录
+- `app/` → Next.js / Rails 风格
+- `lib/` → 库项目
+- 项目根目录（排除配置文件后）
+
+**扫描规则**：
+
+| 检测目标 | 方法 | 映射 |
+|---------|------|------|
+| 目录结构 | 一级子目录 → 模块 | 模块 → PF 候选分组 |
+| 路由定义 | `routes/`、`@app.route`、`router.get` 等 | 路由 → API PF 候选 |
+| API 端点 | `@Controller`、`@api_view`、OpenAPI 定义 | 端点 → PF 候选 |
+| 数据模型 | `models/`、`@Entity`、`class.*Model` | 模型 → BR 候选（数据域） |
+| UI 组件 | `components/`、`pages/`、`views/` | 页面/组件 → PF 候选 |
+| CLI 命令 | `commands/`、`@click.command` | 命令 → PF 候选 |
+
+**排除目录**：`test/`、`__tests__`、`spec/`、`fixtures/`、`node_modules/`、`.devpace/`、`vendor/`、`dist/`、`build/`。
+
+### Step 2：信号挖掘
+
+在代码中搜索额外信号：
+
+**注释信号**：
+
+| 模式 | 信号类型 | 处理 |
+|------|---------|------|
+| `TODO`、`FIXME` | 技术债务 | → PF 候选（标记"技术债务"） |
+| `HACK`、`XXX`、`WORKAROUND` | 技术债务（高优） | → PF 候选（标记"技术债务-高优"） |
+| `#123`（Issue 引用） | 外部追踪 | 记录交叉参照（如有 tracker） |
+
+**项目配置信号**：
+
+| 来源 | 检测内容 | 映射 |
+|------|---------|------|
+| `package.json` scripts | 构建/测试/部署命令 | 运维能力 PF 候选 |
+| `Makefile` / `Taskfile` | 自动化任务 | 运维能力 PF 候选 |
+| `README.md` | 功能描述 section | 文档声明功能 vs 实际代码对比 |
+| `Dockerfile` / `docker-compose.yml` | 服务定义 | 部署架构信息 |
+
+**Git 增强信号**（git 可用时）：
+
+| 分析 | 方法 | 用途 |
+|------|------|------|
+| 热点文件 | `git log --since="30 days" --name-only` 统计变更频率 | 活跃开发区标记 |
+| 共变文件 | 同一 commit 中频繁一起出现的文件 | 耦合模块识别 |
+| 贡献者分布 | `git shortlog -sn` | 知识集中度风险 |
+
+### Step 3：差距分析
+
+对比推断功能 vs 现有功能树，分类：
+
+| 分类 | 条件 | 说明 |
+|------|------|------|
+| 未追踪 | 代码中存在功能模块，但功能树中无对应 PF | 建议补充追踪 |
+| 未实现 | 功能树中有 PF，但代码中无对应实现 | 确认是计划中还是遗漏 |
+| 技术债务 | TODO/FIXME 密集区域（>3 个/文件） | 建议纳入追踪 |
+| 文档漂移 | README 描述的功能与实际代码不匹配 | 提醒更新文档或功能树 |
+
+**匹配规则**：通过 PF 名称关键词与代码模块/文件名的语义关联判断。模糊匹配时列出供用户确认。
+
+### Step 4：报告与确认
+
+三段式输出：
+
+```
+代码库分析报告：
+
+1. 未追踪功能（代码有，功能树无）：
+ 模块 [auth/]：
+ + PF 候选：用户认证（routes: login, register, logout）
+ + PF 候选：权限管理（middleware: checkPermission）
+
+ 模块 [api/]：
+ + PF 候选：数据导出 API（endpoints: /export/csv, /export/json）
+
+2. 未实现功能（功能树有，代码无）：
+ ? PF-003：高级搜索 — 确认状态：计划中 / 已放弃 / 其他？
+
+3. 技术债务（TODO/FIXME 集中区域）：
+ ! src/utils/parser.js（8 个 TODO）— 纳入追踪？
+ ! src/db/migration.py（5 个 FIXME）— 纳入追踪？
+
+[Git 增强] 热点：src/core/engine.js（30天内 42 次变更）
+[Git 增强] 耦合：auth/ ↔ session/（经常一起改动）
+
+逐项选择：accept / skip / 调整分组
+```
+
+用户逐项选择后确认。
+
+### Step 5：写入 .devpace/
+
+1. 确认的"未追踪功能"：追加到 `project.md` 功能树
+ - 按模块分组归入对应 BR 下（无明确归属时创建新 BR 分组）
+ - PF 编号自增
+2. 确认的"技术债务"：追加到 `project.md` 功能树
+ - PF 名称附"（技术债务）"后缀
+ - 归入新建或已有的"技术债务" BR 分组下
+3. "未实现功能"用户确认为"已放弃"的 → 标记 PF 状态
+4. 所有内容标记溯源：``
+5. 触发 PF/BR 溢出检查
+6. git commit
+
+### Step 6：下游引导
+
+```
+代码库推断完成：
+- 新增追踪：X 个产品功能
+- 技术债务：Y 个待处理项
+- 未实现确认：Z 个功能状态已更新
+
+→ /pace-biz align 检查新增项的战略对齐度
+→ /pace-dev 开始处理优先项
+→ /pace-plan next 将新增项排入迭代
+```
+
+## 降级模式
+
+| 场景 | 行为 |
+|------|------|
+| .devpace/ 不存在 | 正常执行 Step 1-4（代码分析），Step 5 输出到控制台不写文件，结尾引导 `/pace-init` |
+| project.md 是桩 | 正常运行，Step 3 跳过差距分析（无功能树可对比），直接输出发现 |
+| 无 Git | 退化：跳过 Step 2 的 Git 增强信号（热点/共变/贡献者），其余正常 |
+| 无源码目录 | 提示"未检测到源码目录"，列出项目根目录结构供用户指定 |
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| 源码目录过大（>1000 文件） | 限制扫描深度为 3 层，提示用户可指定子目录 |
+| 无法识别项目类型 | 仅做目录结构分析 + TODO 扫描，跳过框架特定检测 |
+| Git 命令超时 | 降级到非 Git 模式，提示用户 |
+| 推断结果为空 | 提示"代码库结构简单或功能树已完整覆盖" |
+| 编号冲突 | 重新扫描确认最大编号后分配 |
diff --git a/skills/pace-biz/biz-procedures-opportunity.md b/skills/pace-biz/biz-procedures-opportunity.md
new file mode 100644
index 0000000..c3e689b
--- /dev/null
+++ b/skills/pace-biz/biz-procedures-opportunity.md
@@ -0,0 +1,76 @@
+# opportunity 子命令 procedures
+
+> **职责**：捕获业务机会到 opportunities.md。
+
+## 触发
+
+`/pace-biz opportunity <描述>` 或用户描述了一个业务机会/客户反馈/竞品动态。
+
+## 步骤
+
+### Step 0：模式检查
+
+读取 project.md 的 `mode` 字段。若为 `lite`：
+
+> **当前为轻量模式（OBJ→PF→CR），Opportunity 功能需要完整模式。**
+> - 升级到完整模式：`/pace-init --upgrade-mode`
+> - 或直接添加功能：`/pace-change add <描述>`
+
+终止后续步骤。
+
+### Step 1：解析来源
+
+从用户输入中推断来源类型：
+
+| 关键词 | 推断类型 |
+|--------|---------|
+| 用户说/客户反馈/用户反馈/投诉 | 用户反馈 |
+| 竞品/竞争对手/对手 | 竞品观察 |
+| 发现/技术/性能/可以用 | 技术发现 |
+| 趋势/市场/行业 | 市场趋势 |
+| 想到/觉得/内部/我们应该 | 内部洞察 |
+
+推断不确定时询问用户确认。
+
+### Step 2：生成 OPP 编号
+
+1. 读取 `.devpace/opportunities.md`（不存在则创建空文件）
+2. 扫描所有 `## OPP-xxx` 标题，取最大编号 +1
+3. 三位补零：`OPP-001`、`OPP-002`...
+
+### Step 3：写入 opportunities.md
+
+在文件末尾追加新条目：
+
+```markdown
+## OPP-xxx：[描述]
+- **来源**：[类型]（[详情]）
+- **状态**：评估中
+- **日期**：[YYYY-MM-DD]
+```
+
+文件不存在时先创建：
+
+```markdown
+# 业务机会
+
+## OPP-001：[描述]
+...
+```
+
+### Step 4：输出确认
+
+```
+已捕获业务机会：OPP-xxx — [描述]
+来源：[类型]（[详情]）
+状态：评估中
+→ 下一步：/pace-biz epic OPP-xxx 评估并转化为 Epic
+```
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| .devpace/ 不存在 | 引导 /pace-init |
+| opportunities.md 格式损坏 | 在文件末尾追加，不修复已有内容 |
+| 用户未提供描述 | 询问：请描述这个业务机会 |
diff --git a/skills/pace-biz/biz-procedures-view.md b/skills/pace-biz/biz-procedures-view.md
new file mode 100644
index 0000000..ed162c0
--- /dev/null
+++ b/skills/pace-biz/biz-procedures-view.md
@@ -0,0 +1,75 @@
+# view 子命令 procedures
+
+> **职责**：展示业务全景视图，从 Opportunity 到 CR 的完整价值流。
+
+## 触发
+
+`/pace-biz view` 或用户想看业务全景。
+
+## 步骤
+
+### Step 0：模式检查
+
+读取 project.md 的 `mode` 字段。若为 `lite`：
+
+- 跳过 opportunities.md 和 epics/ 采集
+- 视图简化为 `OBJ→PF→CR` 树（与 `/pace-status tree` 类似但保留业务全景统计）
+- 统计部分省略 Opportunity/Epic/BR 计数
+
+### Step 1：采集数据
+
+读取以下文件：
+1. `opportunities.md` — 所有 Opportunity 及其状态
+2. `epics/` — 所有 Epic 文件及其 BR 列表
+3. `project.md` — 价值功能树（BR→PF→CR 关系）
+4. `state.md` — 当前工作状态
+
+### Step 2：构建全景视图
+
+按以下层次组织数据：
+
+```
+业务全景（[项目名]）
+══════════════════
+
+[OBJ-1：目标名]
+├── [EPIC-001：专题名]（进行中）← OPP-001
+│ ├── BR-001：需求名 P0 进行中
+│ │ ├── PF-001 → CR-001 🔄
+│ │ └── PF-002 → (待创建 CR)
+│ └── BR-002：需求名 P1 待开始
+└── [EPIC-002：专题名]（规划中）← OPP-003
+ └── （待分解）
+
+[未关联 Epic 的 BR]（向后兼容路径）
+└── BR-003：需求名 → PF-003 → CR-002 ✅
+
+[未处理的业务机会]
+├── OPP-002（评估中）：竞品 X 上线实时协作
+└── OPP-004（已搁置）：内部工具整合
+
+[统计]
+├── Opportunity：N 总计（M 评估中 / K 已采纳 / L 已搁置）
+├── Epic：N 总计（M 进行中 / K 规划中 / L 已完成）
+├── BR：N 总计
+├── PF：N 总计（M 完成）
+└── CR：N 总计（M 活跃）
+```
+
+### Step 3：适配项目规模
+
+| 项目规模 | 展示策略 |
+|---------|---------|
+| 无 Epic/Opportunity | 简化为 OBJ→BR→PF→CR 树视图（与 /pace-status tree 类似） |
+| 1-3 Epic | 完整展示所有层级 |
+| 4+ Epic | 折叠已完成的 Epic，展开活跃的 |
+
+### Step 4：输出
+
+直接在终端输出格式化的全景视图。不写入文件。
+
+## 注意
+
+- 此子命令为**只读**，不修改任何文件
+- 与 `/pace-status` 的区别：/pace-status 聚焦 CR/PF 的**开发进度**；/pace-biz view 聚焦 OPP→EPIC→BR 的**业务规划**视角
+- 向后兼容：无 Epic/Opportunity 时退化为简单的 OBJ→BR→PF→CR 树视图
diff --git a/skills/pace-change/SKILL.md b/skills/pace-change/SKILL.md
index baffdc4..29a4fc3 100644
--- a/skills/pace-change/SKILL.md
+++ b/skills/pace-change/SKILL.md
@@ -12,9 +12,10 @@ agent: pace-pm
## 与现有机制的关系
-- `/pace-change`：PF 级需求变更（add/pause/resume/modify/reprioritize）
+- `/pace-change`：PF/BR/Epic 级需求变更（add/pause/resume/modify/reprioritize）
+- `/pace-biz`：业务规划域（Opportunity→Epic→BR 的**创建和分解**）
- `/pace-plan adjust`：迭代范围调整（哪些 PF 纳入/移出当前迭代）
-- 协同场景：`/pace-change add` 插入新 PF → 容量溢出 → 建议 `/pace-plan adjust`
+- 协同场景：`/pace-change add` 插入新 BR 或 PF → 容量溢出 → 建议 `/pace-plan adjust`
- `devpace-rules.md §9`：自动检测变更意图，共享同一套 procedures 文件
## 推荐使用流程
@@ -34,11 +35,11 @@ $ARGUMENTS：
### 核心子命令
-- `add <描述>` → 插入新需求
-- `pause <功能名>` → 暂停/砍掉某个功能
-- `resume <功能名>` → 恢复已暂停的功能
+- `add <描述>` → 插入新需求（支持 BR 级和 PF 级——自动检测粒度，或用 `add br <描述>` / `add pf <描述>` 显式指定）
+- `pause <名称>` → 暂停/砍掉（支持 Epic/BR/PF/CR 级——根据名称或 ID 自动匹配层级）
+- `resume <名称>` → 恢复已暂停的项目（支持 Epic/BR/PF/CR 级）
- `reprioritize <描述>` → 优先级调整
-- `modify <功能名> <变更描述>` → 修改已有需求
+- `modify <名称> <变更描述>` → 修改已有需求（支持 Epic/BR/PF 级）
### 扩展子命令
diff --git a/skills/pace-change/change-procedures-types.md b/skills/pace-change/change-procedures-types.md
index b5e877e..5e9ff4e 100644
--- a/skills/pace-change/change-procedures-types.md
+++ b/skills/pace-change/change-procedures-types.md
@@ -82,7 +82,7 @@
**add 后容量超出**：
1. 检测迭代容量（iterations/current.md PF 数 vs 历史速度）
2. 容量超出 → 直接询问用户："迭代容量已满，是否同时调整迭代范围？"
-3. 用户确认 → 内联执行 `/pace-plan adjust` 的逻辑（读取 adjust-procedures.md），无需用户手动切换命令
+3. 用户确认 → 委托 `/pace-plan adjust` 执行迭代范围调整（迭代文件写入规则见 `knowledge/_schema/iteration-format.md`），无需用户手动切换命令
4. 用户拒绝 → 仅记录容量告警到迭代变更记录
**pause 释放容量**：
diff --git a/skills/pace-dev/SKILL.md b/skills/pace-dev/SKILL.md
index 696210f..866d247 100644
--- a/skills/pace-dev/SKILL.md
+++ b/skills/pace-dev/SKILL.md
@@ -25,6 +25,7 @@ $ARGUMENTS：
- `<功能描述>` → 指定要推进的功能（自然语言匹配）
- `#` → 按 CR 编号直接定位（如 `#3` → CR-003）
- `--last` → 定位上一个操作过的 CR（从 state.md 或最近 git log 推断）
+- `--batch` → 连续推进模式：批量推进迭代内多个 S 复杂度 PF，最后统一审批
## 执行路由
diff --git a/skills/pace-dev/dev-procedures-common.md b/skills/pace-dev/dev-procedures-common.md
index 1e1986f..2f6819e 100644
--- a/skills/pace-dev/dev-procedures-common.md
+++ b/skills/pace-dev/dev-procedures-common.md
@@ -71,3 +71,43 @@ pace-dev 完成实现后（Gate 1 通过、代码已提交），**必须**向用
- 简单 CR（S）：1-2 行即可（文件列表 + 状态变化），省略"质量"行
- 标准/复杂 CR（M/L/XL）：完整 5 项，"质量"行浓缩 Gate 反思为 ≤20 字（如"无新技术债，核心路径测试充分"）
- 不透明动作禁令：写入 .devpace/ 的任何文件必须在摘要中列出——用户不应在不知情的情况下发现文件被修改
+
+## 连续推进模式（--batch）
+
+当用户使用 `--batch` 参数或说"连续做"/"批量推进"时，启用连续推进模式：
+
+### 进入条件
+
+1. 当前有活跃迭代（`iterations/current.md` 存在）
+2. 迭代内有 ≥2 个未开始的 PF
+
+### 执行流程
+
+1. 读取 `current.md`，按优先级排列未开始的 PF
+2. 对每个 PF 依次执行标准 pace-dev 流程（创建 CR → 开发 → Gate 1 → Gate 2）
+3. **Gate 3 延迟**：S 复杂度的 CR 通过 Gate 2 后不立即进入 Gate 3 审批，而是标记为 `batch_review_pending`（CR 状态仍为 `in_review`）
+4. L/XL 复杂度的 CR 仍立即进入 Gate 3 审批（不延迟）
+5. 每完成一个 PF 后，输出 1 行进度：`[N/M] PF-xxx 已完成 Gate 2，等待统一审批`
+
+### 批量审批
+
+所有 S 复杂度 PF 完成 Gate 2 后，一次性展示批量审批列表：
+
+```
+批量审批（共 N 个 S 复杂度变更）：
+1. CR-xxx：[标题] — Gate 2 ✅
+2. CR-xxx：[标题] — Gate 2 ✅
+3. CR-xxx：[标题] — Gate 2 ✅
+
+全部批准 | 逐个审批 | 取消
+```
+
+- "全部批准" → 全部标记为 merged，执行连锁更新
+- "逐个审批" → 退出 batch 模式，逐个走标准 Gate 3
+- 用户可选择性排除："批准除了 2 号"
+
+### 退出条件
+
+- 迭代内无更多未开始 PF
+- 用户说"停"/"够了"/"先到这"
+- 遇到 L/XL 复杂度 PF（完成该 PF 的 Gate 3 后询问是否继续 batch）
diff --git a/skills/pace-dev/dev-procedures-developing.md b/skills/pace-dev/dev-procedures-developing.md
index 97cc67f..d7054f6 100644
--- a/skills/pace-dev/dev-procedures-developing.md
+++ b/skills/pace-dev/dev-procedures-developing.md
@@ -143,7 +143,7 @@ CR 进入 developing 阶段时，自动检测是否需要生成测试策略—
- 在 created→developing 转换完成、意图检查点通过后：
1. 检查上述 3 个条件是否全部满足
2. 全部满足 → 输出 1 行提示："📝 检测到 PF 关联且无测试策略，自动生成中..."
- 3. 按 `test-procedures-strategy-gen.md` §3 执行 strategy 生成流程
+ 3. 自动生成测试策略文件（输出格式见 `knowledge/_schema/test-strategy-format.md`，或委托 `/pace-test strategy`）
4. 生成成功 → 输出"测试策略已生成（.devpace/rules/test-strategy.md），后续 coverage/accept/impact 将自动使用"
5. 继续正常的 developing 开发流程
- 条件不全满足 → 静默跳过，不提示
@@ -176,3 +176,42 @@ developing 阶段接近完成时，主动建议执行 dryrun 预检——在正
- **同一 CR 仅建议 1 次**：首次触发后在 CR 事件表备注 `[dryrun-suggested]`，后续不重复
- **不阻断**：纯建议，用户可忽略
- **与智能推荐互补**：pace-test 无参数运行时的智能推荐（§1.6）在 developing 状态也推荐 dryrun，此处是 pace-dev 侧的主动触达
+
+## 语义漂移检测（持续需求对齐）
+
+在 developing 阶段的 checkpoint 中，检测代码变更是否持续与验收标准语义对齐——补充意图漂移（"做了什么不该做的"）和复杂度漂移（"规模比预期大"）之外的第三维度："做的东西还是需求要的吗"。
+
+### 检测步骤
+
+每次 checkpoint（与意图/复杂度漂移检测同时执行），额外检查：
+
+1. 读取 CR 关联 PF 的验收标准列表（从 project.md 或 PF 溢出文件）
+2. 读取当前 CR 的 `git diff --stat` 获取变更文件和行数统计
+3. 对每个验收标准，评估当前代码变更是否有相关实现：
+ - **已覆盖**：变更文件中有直接实现该标准的代码
+ - **部分覆盖**：有相关代码但不完整
+ - **未触及**：尚无相关变更（可能是后续步骤）
+ - **偏离**：代码实现了标准未要求的功能，可能偏离需求
+
+### 触发条件
+
+同时满足以下条件时输出语义漂移提示：
+- CR 开发进度 ≥ 50%（L/XL 按步骤比例，S/M 按变更文件与预期比例）
+- 存在"偏离"分类的验收标准 ≥ 1 个
+- 或"未触及"分类的验收标准占比 > 50% 且进度 ≥ 70%
+
+### 提示格式
+
+```
+📊 语义对齐检查：N/M 验收标准已覆盖 · X 项部分覆盖 · Y 项未触及 · Z 项可能偏离
+偏离项：[验收标准描述] — 当前实现 [实际方向]
+→ 建议：确认需求理解或调整实现方向
+```
+
+### 规则
+
+- **不阻断**：纯提示，不影响开发流程
+- **轻量执行**：仅读取 PF 验收标准（3-10 条）和 git diff stat，不做深度代码分析
+- **S CR 跳过**：单文件 CR 验收标准通常明确，不需要中间检查
+- **与 Gate 2 互补**：Gate 2 做完整逐条比对，语义漂移检测是开发过程中的早期预警
+- **与 accept 协同**：语义漂移检测结果可作为后续 `/pace-test accept` 的优先级参考
diff --git a/skills/pace-dev/dev-procedures-intent.md b/skills/pace-dev/dev-procedures-intent.md
index caf634b..73a01e3 100644
--- a/skills/pace-dev/dev-procedures-intent.md
+++ b/skills/pace-dev/dev-procedures-intent.md
@@ -1,6 +1,6 @@
# 意图检查点与计划规程
-> **执行流程**：意图检查点 → 复杂度评估 → [S: 直接开工 | M: 可选计划 | L/XL: 执行计划 + 反思 + 方案确认] → 风险预扫描（条件） → 进入 developing
+> **执行流程**：意图检查点 → 复杂度评估 → [S: 直接开工 | M: 可选计划 | L/XL: 技术方案评审 → 执行计划 + 反思 + 方案确认] → 风险预扫描（条件） → 进入 developing
## Phase A：意图明确（始终执行）
@@ -123,6 +123,52 @@
- 升级建议不阻断——用户选择继续则按原复杂度推进
- 已完成的工作不丢失——升级后作为更完整计划的输入保留
+### 技术方案评审（L/XL 必须）
+
+在生成执行计划之前，先评审技术方案选型：
+
+**Step B0：方案分析**
+
+1. 基于意图检查点的范围和约束，Claude 提出 2-3 个备选技术方案
+2. 每个方案包含：
+ - **方案名称**：1 行描述
+ - **核心思路**：2-3 行说明实现路径
+ - **优势**：关键优点
+ - **劣势/风险**：主要缺点或技术风险
+3. 将方案对比写入 CR 文件的"方案"字段
+
+**Step B0.5：方案确认**
+
+展示方案对比，等待用户选择：
+
+```
+技术方案（[CR 标题]）：
+
+方案 A：[名称]
+ 思路：[实现路径]
+ 优势：[优点] | 劣势：[缺点]
+
+方案 B：[名称]
+ 思路：[实现路径]
+ 优势：[优点] | 劣势：[缺点]
+
+推荐方案 A，因为 [理由]。选哪个？
+```
+
+- 用户选择后 → 更新 CR 方案字段为选定方案
+- 用户说"都行/你定" → 采用推荐方案
+
+**ADR 自动触发**：如果方案涉及以下任一条件，自动建议创建 ADR（通过在 merged 后引导提醒，不阻断当前流程）：
+- 新引入依赖（框架/库）
+- 改变已有架构模式（如从同步改异步）
+- 影响 3+ 个模块的接口
+- 用户明确说"记录这个决策"
+
+**规则**：
+- **S/M CR 跳过本步骤**——直接进入执行计划生成
+- 方案评审与执行计划生成合并在同一个用户交互中展示（方案确认 → 立即生成执行计划），不增加额外交互轮次
+- 如果 CR 只有 1 个可行方案（如 bug 修复），标注"单一方案，无需对比"并跳过
+
### 执行计划生成（L/XL 必须）
复杂度 L/XL 的 CR 在意图检查点完成后，自动生成执行计划写入 CR 意图 section。
@@ -203,7 +249,7 @@ L/XL CR 的执行计划生成后，**必须主动展示并等待用户确认**
| S（多文件）/ M | insights.md 有匹配 defense pattern（置信度 ≥ 0.5） | 轻量扫描（仅历史教训维度） |
| L / XL | 必须触发 | 完整 5 维扫描 |
-扫描规则详见 `skills/pace-guard/guard-procedures-scan.md`。扫描结果写入 CR "风险预评估" section（格式见 `knowledge/_schema/cr-format.md`）。
+执行 5 维风险扫描（维度定义和输出格式见 `knowledge/_schema/risk-format.md` 风险预评估章节，或委托 `/pace-guard scan`）。扫描结果写入 CR "风险预评估" section（格式见 `knowledge/_schema/cr-format.md`）。
若综合风险等级为 High：
- 执行计划中增加对应防护步骤（如："增加 E2E 测试"、"架构审查"等具体动作）
diff --git a/skills/pace-dev/dev-procedures-postmerge.md b/skills/pace-dev/dev-procedures-postmerge.md
index 51d324f..3ea97f2 100644
--- a/skills/pace-dev/dev-procedures-postmerge.md
+++ b/skills/pace-dev/dev-procedures-postmerge.md
@@ -18,17 +18,48 @@
**执行规则**：检查 state.md 教学标记 → 未出现过 → 在自然时机直接执行功能的核心价值输出 → 更新标记。用户如果问"怎么手动触发"，再说明对应命令名称。
-## PF 溢出检查（Overflow Check）
+## 迭代内下一 PF 推荐（merged 后自动执行）
-CR 创建或状态变更（尤其是 merged）时，检查关联 PF 是否满足溢出条件，满足时自动创建独立文件。
+CR merged 后，在功能发现检查之后、关联链维护之前，自动检查迭代内是否有未开始的 PF：
+
+1. 读取 `.devpace/iterations/current.md` 确认当前迭代
+2. 从迭代文件中提取纳入的 PF 列表及优先级
+3. 扫描 `.devpace/backlog/` 确认每个 PF 是否有已创建的 CR
+4. 如果存在"纳入迭代但无 CR"的 PF：
+ - 按迭代文件中的优先级排序，取最高优先级 PF
+ - 在 merged 摘要末尾追加：`迭代进度：N/M 完成。下一个：[PF-xxx 名称]——说"开始做"继续推进`
+5. 如果迭代内所有 PF 都有 CR 且全部 merged → 追加：`迭代所有功能已完成——/pace-plan close 关闭迭代 | /pace-retro 回顾`
+6. 如果无当前迭代（`current.md` 不存在）→ 跳过本步骤
+
+**规则**：
+- 此推荐不替代 pace-next 的全局推荐，仅在 merged 摘要中追加 1 行
+- iterations/current.md 不存在时静默跳过，不报错
+
+## Epic→BR→PF 关联链维护
+
+CR 创建时，Claude 自动填充完整追溯链到 CR 文件的"产品功能"字段：
+
+```
+- **产品功能**：[PF 标题]（[PF-ID]）→ [BR 标题]（[BR-ID]）→ [Epic 标题]（[EPIC-ID]）
+```
+
+**查找逻辑**：
+1. 从 project.md 价值功能树定位 PF 所属的 BR
+2. 从 BR 所属的 Epic 行（如有）获取 Epic 信息
+3. 无 Epic 时省略 Epic 部分（向后兼容）：`[PF 标题]（[PF-ID]）→ [BR 标题]（[BR-ID]）`
+
+## PF 和 BR 溢出检查（Overflow Check）
+
+CR 创建或状态变更（尤其是 merged）时，检查关联 PF 和 BR 是否满足溢出条件，满足时自动创建独立文件。
### 检查时机
| 事件 | 检查行为 |
|------|---------|
-| CR 创建（新关联 PF） | 计算该 PF 关联的 CR 数（含本次），≥3 则触发 |
-| CR merged（§11 连锁更新时） | 综合检查三个条件 |
-| `/pace-change modify` 涉及 PF | 由 change-procedures-types.md 负责检查并触发 |
+| CR 创建（新关联 PF） | 计算该 PF 关联的 CR 数（含本次），≥3 则触发 PF 溢出 |
+| CR merged（§11 连锁更新时） | 综合检查 PF 和 BR 三个条件 |
+| `/pace-change modify` 涉及 PF 或 BR | 由 change-procedures-types.md 负责检查并触发 |
+| BR 关联 PF 新增（/pace-biz decompose） | 计算该 BR 关联的 PF 数，≥3 则触发 BR 溢出 |
### 溢出条件（满足任一）
@@ -48,9 +79,21 @@ CR 创建或状态变更（尤其是 merged）时，检查关联 PF 是否满足
- 价值功能树中该 PF 行追加 `→ [详情](features/PF-xxx.md)`
7. 在执行透明摘要中报告溢出："PF-xxx 信息已迁移到独立文件 features/PF-xxx.md"
+### BR 溢出条件（满足任一）
+
+溢出条件定义见 `knowledge/_schema/br-format.md` "溢出触发条件"章节（关联 3+ PF | 业务上下文 >5 行 | 经历 modify）。
+
+### BR 溢出执行步骤
+
+1. 创建 `.devpace/requirements/` 目录（如不存在）
+2. 从 project.md 价值功能树提取 BR 关联信息（Epic、OBJ、PF 列表）
+3. 聚合信息创建 `requirements/BR-xxx.md`
+4. 更新 project.md 价值功能树中该 BR 行为链接格式
+5. 在执行透明摘要中报告溢出："BR-xxx 信息已迁移到独立文件 requirements/BR-xxx.md"
+
### 规则
- **零摩擦**：溢出自动发生，不询问用户确认（对齐 P1 原则）
-- **幂等性**：已存在 `features/PF-xxx.md` 时不重复溢出，仅更新已有文件
-- **向后兼容**：无 `features/` 目录的项目不触发任何溢出逻辑
+- **幂等性**：已存在 `features/PF-xxx.md` 或 `requirements/BR-xxx.md` 时不重复溢出，仅更新已有文件
+- **向后兼容**：无 `features/` 或 `requirements/` 目录的项目不触发任何溢出逻辑
- **容错**：溢出失败（如文件写入异常）不阻断主流程，在摘要中标注失败原因
diff --git a/skills/pace-feedback/SKILL.md b/skills/pace-feedback/SKILL.md
index 9005c3f..b37c68b 100644
--- a/skills/pace-feedback/SKILL.md
+++ b/skills/pace-feedback/SKILL.md
@@ -1,7 +1,7 @@
---
-description: Use when user reports issues, shares feedback, or receives production alerts — "用户反馈", "线上问题", "生产问题", "告警", "改进建议", "新需求", "体验问题", "功能请求", "线上bug", "运维".
+description: Use when user reports issues, shares feedback, or receives production alerts — "用户反馈", "线上问题", "生产问题", "告警", "改进建议", "新需求", "体验问题", "功能请求", "线上bug", "运维", "事件", "incident", "故障", "P0", "P1", "严重故障", "postmortem", "事后复盘".
allowed-tools: AskUserQuestion, Write, Read, Edit, Glob, Bash
-argument-hint: "[report <问题描述>] 或 [反馈描述]"
+argument-hint: "[report <问题描述>] 或 [incident open/close/timeline/list] 或 [反馈描述]"
model: sonnet
disable-model-invocation: true
---
@@ -10,12 +10,16 @@ disable-model-invocation: true
> **可选功能**：用于系统化收集上线后反馈和处理生产事件。简单场景直接说"用户反馈了 X 问题"或"线上有个 bug"即可。
-收集上线后反馈和生产环境问题，关联到价值链（目标→功能→任务），闭合"交付→反馈→改进"循环和"部署→反馈→修复"循环。每条反馈分配唯一 FB-ID，全生命周期可追踪。
+收集上线后反馈和生产环境问题，关联到价值链（目标→Epic→功能→任务），闭合"交付→反馈→改进"循环和"部署→反馈→修复"循环。反馈可关联到 Epic 和 Opportunity（如来源为已有客户反馈）。每条反馈分配唯一 FB-ID，全生命周期可追踪。
## 输入
$ARGUMENTS：
- `report <问题描述>` → **紧急通道**：跳过分诊，自动进入"生产事件"分支并启用加速路径评估（仅 hotfix/critical 场景自动建议加速）
+- `incident open <描述>` → 创建事件记录（严重度评估 + 时间线初始化）
+- `incident close ` → 关闭事件 + 生成 postmortem 模板
+- `incident timeline ` → 查看事件时间线
+- `incident list` → 列出所有事件（支持 `--open` 筛选）
- `<反馈描述>` → 走分诊流程（分类后路由）
- （空）→ 引导式收集（渐进式两轮收集）
@@ -30,6 +34,16 @@ $ARGUMENTS：
| severity ≥ major 或 report 参数 | `feedback-procedures-hotfix.md` |
| 创建 defect/hotfix CR | `feedback-procedures-analysis.md` |
| Step 5 状态更新 | `feedback-procedures-status.md` |
+| incident open / close / timeline / list | `feedback-procedures-incident.md` |
+
+### incident 子命令执行路由
+
+| 子命令 | 读取 | 写入 | 规程文件 |
+|--------|------|------|---------|
+| incident open | state.md, backlog/, releases/ | incidents/INCIDENT-xxx.md | feedback-procedures-incident.md |
+| incident close | incidents/INCIDENT-xxx.md, backlog/ | incidents/INCIDENT-xxx.md | feedback-procedures-incident.md |
+| incident timeline | incidents/INCIDENT-xxx.md | （只读） | feedback-procedures-incident.md |
+| incident list | incidents/ | （只读） | feedback-procedures-incident.md |
### Step 0：草稿恢复检查
diff --git a/skills/pace-feedback/feedback-procedures-incident.md b/skills/pace-feedback/feedback-procedures-incident.md
new file mode 100644
index 0000000..792c36f
--- /dev/null
+++ b/skills/pace-feedback/feedback-procedures-incident.md
@@ -0,0 +1,88 @@
+# 事件管理规程
+
+> **职责**：结构化事件管理——创建、追踪、关闭和复盘。补全运维闭环。
+
+## 与 report/hotfix 的关系
+
+| 入口 | 定位 | 适用场景 |
+|------|------|---------|
+| `report` | 紧急通道，快速创建 Defect/Hotfix CR | 发现问题需要立即修复 |
+| `incident open` | 事件管理，结构化记录和追踪 | 需要分级响应、时间线追踪、事后复盘 |
+
+两者可并行使用：`incident open` 创建事件记录 → `report` 创建对应的 Hotfix CR → CR merged 后 `incident close` 关闭事件。
+
+## incident open
+
+### 严重度分级
+
+复用现有严重度矩阵（feedback-procedures-hotfix.md），映射为事件等级：
+
+| 严重度 | 事件等级 | 响应要求 | 示例 |
+|--------|---------|---------|------|
+| critical | P0 | 立即响应，所有工作暂停 | 全站不可用、数据丢失 |
+| major | P1 | 1 小时内响应 | 核心功能不可用、性能严重降级 |
+| minor | P2 | 当日响应 | 非核心功能异常、UI 错误 |
+| trivial | P3 | 下个迭代处理 | 体验优化、文案问题 |
+
+### 创建流程
+
+1. 评估严重度（复用 hotfix 严重度矩阵）
+2. 创建 `.devpace/incidents/` 目录（如不存在）
+3. 生成 `INCIDENT-NNN.md`，包含：
+ - 标题、严重度、状态（open）
+ - 影响范围描述
+ - 时间线（含创建时间）
+ - 关联 CR 列表（初始为空）
+4. P0/P1 事件 → 额外提醒："建议立即 `/pace-feedback report` 创建 Hotfix CR"
+5. 输出摘要
+
+### 事件文件格式
+
+```
+# INCIDENT-NNN：[标题]
+
+- **严重度**：P0/P1/P2/P3
+- **状态**：open / investigating / mitigated / closed
+- **影响范围**：[描述]
+- **开始时间**：[ISO 8601]
+- **关联 CR**：[CR 编号列表]
+
+## 时间线
+
+| 时间 | 事件 |
+|------|------|
+| [时间] | 事件创建 |
+
+## Postmortem
+
+（事件关闭后填充）
+```
+
+## incident close
+
+1. 读取事件文件，确认状态为 open/investigating/mitigated
+2. 更新状态为 closed，记录关闭时间
+3. 生成 Postmortem 模板（追加到事件文件 Postmortem section）：
+ - **影响摘要**：持续时间、影响范围
+ - **根本原因**：（待填写）
+ - **修复措施**：关联 CR 的修复摘要
+ - **预防措施**：（待填写）
+ - **经验教训**：（待填写）
+4. 提醒用户填写 Postmortem 的空白字段
+5. 如有关联 CR → 检查是否全部 merged，未全部 merged 则警告
+
+## incident timeline
+
+只读展示事件时间线，按时间倒序排列。
+
+## incident list
+
+列出 `.devpace/incidents/` 中所有事件。`--open` 只显示非 closed 状态的事件。
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| incidents/ 不存在 | open 时自动创建；list/timeline/close 报告无事件记录 |
+| INCIDENT 编号不存在 | 提示无效编号，列出可用选项 |
+| 关闭已关闭的事件 | 提示已关闭，展示 Postmortem |
diff --git a/skills/pace-feedback/feedback-procedures-intake.md b/skills/pace-feedback/feedback-procedures-intake.md
index 5bf12e1..14ebe36 100644
--- a/skills/pace-feedback/feedback-procedures-intake.md
+++ b/skills/pace-feedback/feedback-procedures-intake.md
@@ -30,3 +30,19 @@ Claude 自动从项目上下文补充：
- 读取最近的 Release（`.devpace/releases/`，降级模式跳过）确定最近部署时间
- 扫描 backlog/ 中最近 merged 的 CR，列出潜在引入源
- 读取 checks.md 确认是否有相关质量检查覆盖
+
+## 反馈类型分流
+
+在完成渐进式引导收集（第一轮）后、创建 CR 之前，根据用户描述判断反馈类型：
+
+| 类型 | 识别特征 | 处理路径 |
+|------|---------|---------|
+| 缺陷（Bug） | "白屏/报错/崩溃/数据丢失/无法使用" 等故障描述 | 继续 feedback 流程 → 创建 Defect CR |
+| 体验改进 | "太慢/不方便/想要更好的 X" 等改善诉求 | 继续 feedback 流程 → 创建 Improvement CR |
+| 功能请求 | "能不能加/希望有/需要一个新的 X" 等新功能诉求 | 路由到 `/pace-change add` 或 `/pace-biz discover` |
+
+**功能请求路由规则**：
+1. 识别到功能请求时，向用户确认："这看起来是一个新功能需求而非缺陷。建议通过需求管理流程处理——"
+2. 如果项目有 Epic 结构 → 推荐 `/pace-biz discover`
+3. 如果项目无 Epic 结构 → 推荐 `/pace-change add [功能描述]`
+4. 用户坚持按反馈处理 → 尊重用户选择，继续 feedback 流程
diff --git a/skills/pace-guard/SKILL.md b/skills/pace-guard/SKILL.md
index 08cba18..c8935c0 100644
--- a/skills/pace-guard/SKILL.md
+++ b/skills/pace-guard/SKILL.md
@@ -7,7 +7,7 @@ argument-hint: "[scan|monitor|trends|report|resolve] [CR编号] [--full|--brief|
# /pace-guard — 风险预判与管理
-统一管理开发全生命周期的风险：从编码前的 Pre-flight 扫描，到开发中的实时监控，再到跨迭代的趋势分析——让风险可见、可追踪、可解决。
+统一管理开发全生命周期的风险：从编码前的 Pre-flight 扫描，到开发中的实时监控，再到跨迭代的趋势分析——让风险可见、可追踪、可解决。风险评估覆盖 Epic 级别（Epic 范围风险影响其下所有 BR/PF/CR）。
## 子命令
diff --git a/skills/pace-guard/guard-procedures-common.md b/skills/pace-guard/guard-procedures-common.md
index e72ca70..b4e946a 100644
--- a/skills/pace-guard/guard-procedures-common.md
+++ b/skills/pace-guard/guard-procedures-common.md
@@ -53,6 +53,21 @@
**简要行统一风格**：`[子命令]：关键指标1 · 指标2 · 下一步/趋势`
+## 新项目风险扫描兜底
+
+当 `.devpace/insights.md` 不存在或内容为空（无 pattern 条目）时，对前 3 个 CR 自动触发基础风险扫描：
+
+**检测条件**（全部满足）：
+1. `.devpace/insights.md` 不存在或无 `## defense` / `## success` / `## improvement` 条目
+2. `.devpace/backlog/` 中 CR 文件总数 ≤ 3（含当前创建的）
+
+**触发行为**：
+- 满足条件时，无论 CR 复杂度（S/M/L/XL），均执行基础 3 维扫描（历史教训跳过，仅扫描：依赖影响、架构兼容性、安全敏感度）
+- 扫描结果正常写入 risks/ 文件（如发现风险）
+- 第 4 个 CR 起恢复正常触发逻辑（依赖 insights.md pattern 匹配）
+
+**教学触发**：首次兜底扫描时，附 1 句教学——"风险扫描帮你在编码前发现隐患。随着项目积累经验（insights.md），扫描会更精准。"
+
## 风险文件创建规则
1. 编号：扫描 `.devpace/risks/` 现有文件，取最大编号 +1（无文件从 001 开始）
diff --git a/skills/pace-guard/guard-procedures-scan.md b/skills/pace-guard/guard-procedures-scan.md
index cc4f6e2..95d4d78 100644
--- a/skills/pace-guard/guard-procedures-scan.md
+++ b/skills/pace-guard/guard-procedures-scan.md
@@ -10,7 +10,29 @@
| 依赖影响 | 改动文件的反向依赖链 | 代码文件 import/require/from 分析 |
| 架构兼容性 | 变更是否违反项目技术约定 | .devpace/context.md（如存在） |
| 范围复杂度 | 实际工作量 vs 预期 | CR 描述 + 项目文件树（Glob 扫描） |
-| 安全敏感度 | 涉及认证/授权/数据/加密 | 文件路径关键词（auth/crypto/secret/token/password/key/permission） |
+| 安全敏感度 | 涉及认证/授权/数据/加密/OWASP 风险模式 | 文件路径关键词 + 代码模式分析（见安全深度检查规则） |
+
+### 安全深度检查规则
+
+安全敏感度维度分两层检查：
+
+**Layer 1 — 路径关键词匹配**（所有复杂度）：
+- 文件路径包含：`auth`/`crypto`/`secret`/`token`/`password`/`key`/`permission`/`session`/`jwt`/`oauth`/`cors`/`csrf`/`sanitize`/`encrypt`/`decrypt`
+
+**Layer 2 — OWASP 风险模式扫描**（L/XL 或显式 `scan --full` 时）：
+
+| OWASP 分类 | 检测模式 | 严重度 |
+|-----------|---------|--------|
+| 注入（A03） | SQL 拼接、命令拼接、模板注入模式 | High |
+| 认证失效（A07） | 硬编码密钥、明文密码存储、无速率限制 | High |
+| 敏感数据暴露（A02） | API 密钥在代码中、日志输出敏感字段、无加密传输 | High |
+| 访问控制（A01） | 缺少权限检查的 API 路由、路径遍历风险 | Medium |
+| 安全配置（A05） | 调试模式开启、默认密码、过宽 CORS | Medium |
+| 依赖漏洞（A06） | 已知 CVE 的依赖版本（如有 lockfile 可检测） | Medium |
+
+**Layer 2 执行方式**：对 CR 涉及的代码文件执行 `git diff` → 对新增/修改行逐一匹配上述模式 → 命中时标注 OWASP 分类和严重度。
+
+**输出**：Layer 1 命中 → 标记 "安全敏感文件 N 个"。Layer 2 命中 → 标记具体 OWASP 分类和位置。
## 复杂度自适应（A1）
diff --git a/skills/pace-init/SKILL.md b/skills/pace-init/SKILL.md
index a2690d6..2a4c9de 100644
--- a/skills/pace-init/SKILL.md
+++ b/skills/pace-init/SKILL.md
@@ -1,7 +1,7 @@
---
description: Use when user says "初始化", "pace-init", "开始追踪", "初始化研发管理", "新项目", "项目管理", "set up devpace", "健康检查 devpace", "重置 devpace", "预览初始化", or wants to set up, verify, or reset project development tracking. NOT for current progress overview (use /pace-status) or starting development (use /pace-dev).
allowed-tools: AskUserQuestion, Write, Read, Edit, Glob, Bash
-argument-hint: "[项目名称] [full] [--from <路径>...] [--import-insights <路径>] [--verify [--fix]] [--dry-run] [--reset [--keep-insights]] [--export-template] [--from-template <路径>] [--interactive]"
+argument-hint: "[项目名称] [full] [--from <路径>...] [--import-insights <路径>] [--verify [--fix]] [--dry-run] [--reset [--keep-insights]] [--export-template] [--from-template <路径>] [--interactive] [--lite]"
model: sonnet
disable-model-invocation: true
hooks:
@@ -16,7 +16,7 @@ hooks:
# /pace-init — 初始化项目开发节奏管理
-从模板初始化当前项目的 `.devpace/` 目录。默认执行最小初始化（自动检测项目生命周期阶段，按阶段适配行为），`full` 执行分阶段完整流程，`--from` 从文档自动生成功能树。支持 `--verify`（健康检查）、`--reset`（重置）、`--dry-run`（预览）等子命令。
+从模板初始化当前项目的 `.devpace/` 目录。默认执行最小初始化（自动检测项目生命周期阶段，按阶段适配行为），`full` 执行分阶段完整流程（含愿景、战略上下文、OBJ 产品维度引导），`--from` 从文档自动生成功能树（支持 Epic 解析）。支持 `--verify`（健康检查）、`--reset`（重置）、`--dry-run`（预览）等子命令。
## 输入
@@ -32,6 +32,7 @@ $ARGUMENTS：可选。格式：
- `--from-template <路径>` — 从模板初始化
- `--import-insights <路径>` — 导入跨项目经验
- `--interactive` — 强制对话模式（覆盖自动检测行为）
+- `--lite` — 轻量模式：跳过 OPP/Epic/BR 层，project.md 只含 OBJ→PF→CR 三层结构，适合个人小项目
## 流程
@@ -65,6 +66,7 @@ $ARGUMENTS：可选。格式：
| `--export-template` / `--from-template` | `init-procedures-template.md` |
| （迁移触发时） | `init-procedures-migration.md` |
| （检测到 monorepo 信号时） | `init-procedures-monorepo.md` |
+| `--lite` | `init-procedures-core.md` + `init-procedures-lite.md` |
## 输出
@@ -72,4 +74,13 @@ $ARGUMENTS：可选。格式：
### 下一步引导（仅正常初始化和 `--full` 时）
-确认摘要后追加 1 句引导（§15 教学标记 `init_complete` 去重）："项目已就绪。说'帮我做 [功能名]'开始第一个功能，或 `/pace-plan` 规划迭代。"
+确认摘要后追加情境化引导（§15 教学标记 `init_complete` 去重）：
+
+| 项目状态 | 引导内容 |
+|---------|---------|
+| 有源代码（src/ 或主语言文件 >10 个） | "项目已就绪。建议先 `/pace-biz infer` 从代码推断已有功能和技术债务，再开始规划。" |
+| 有需求文档（--from 初始化，功能树已生成） | "项目已就绪。功能树已生成，说'帮我做 [功能名]'开始第一个功能，或 `/pace-plan` 规划迭代。" |
+| 空项目（无源代码、无需求文档） | "项目已就绪。说'我想做...'开始头脑风暴需求（`/pace-biz discover`），或直接说'帮我做 [功能名]'快速开始。" |
+| 通用（其他情况） | "项目已就绪。说'帮我做 [功能名]'开始第一个功能，`/pace-biz` 规划业务需求，或 `/pace-plan` 规划迭代。" |
+
+**检测规则**：使用 init-procedures-core.md 的信号检测结果（源文件数、git 信号）判定项目状态，不额外扫描。
diff --git a/skills/pace-init/init-procedures-full.md b/skills/pace-init/init-procedures-full.md
index 1bf7422..b76175a 100644
--- a/skills/pace-init/init-procedures-full.md
+++ b/skills/pace-init/init-procedures-full.md
@@ -89,12 +89,26 @@
### 阶段 2：业务（可选）
-使用 AskUserQuestion 询问："要现在定义业务目标和成效指标吗？可稍后 /pace-retro 补充。"
+使用 AskUserQuestion 询问："要现在定义业务愿景和目标吗？可稍后 /pace-biz 补充。"
用户选择"现在定义"→ 引导收集：
-1. 业务目标（OBJ）：项目的核心价值和成功标准
+
+**2a. 愿景（写入 project.md 愿景 section）**：
+1. 目标用户：谁会用这个产品？
+2. 核心问题：他们的什么痛点？
+3. 差异化：为什么选你而不是替代方案？（可选，可留空）
+4. 成功图景：做成了是什么样？（可选，可留空）
+
+**2b. 战略上下文（写入 project.md 战略上下文 section）**：
+1. 核心假设：这个项目基于什么关键假设？（可选）
+2. 外部约束：有什么不可改变的限制条件？（可选）
+
+**2c. 业务目标（OBJ）（写入 project.md 业务目标 section）**：
+1. 目标描述 + 类型（business/product/tech）+ 时间维度（短期/中期/长期）
2. 成效指标（MoS）：可衡量的指标列表
-3. 业务需求（BR）：高层需求分解
+3. 业务需求（BR）：高层需求分解（可选，可稍后 /pace-biz decompose）
+
+**2d. 创建 opportunities.md**：自动创建空的业务机会看板文件。
用户选择"稍后再说"→ 跳过，project.md 保持桩状态。
diff --git a/skills/pace-init/init-procedures-lite.md b/skills/pace-init/init-procedures-lite.md
new file mode 100644
index 0000000..bd12bdf
--- /dev/null
+++ b/skills/pace-init/init-procedures-lite.md
@@ -0,0 +1,48 @@
+# 轻量模式初始化规程
+
+> **职责**：`--lite` 参数时的初始化行为覆盖。在 core 流程之后执行。
+
+## 行为覆盖
+
+### project.md 结构简化
+
+轻量模式下 project.md 的价值功能树使用简化结构（跳过 OPP/Epic/BR 层）：
+
+```
+## 价值功能树
+
+OBJ-1：[目标名称]
+├── PF-001：[功能名]（[用户故事]）→ (待创建 CR)
+├── PF-002：[功能名]（[用户故事]）→ (待创建 CR)
+└── PF-003：[功能名]（[用户故事]）→ (待创建 CR)
+```
+
+### 跳过的组件
+
+轻量模式下**不创建**以下内容：
+- `opportunities.md`（Opportunity 看板）
+- `epics/` 目录（Epic 文件）
+- `requirements/` 目录（BR 溢出文件）
+- project.md 中的 Epic/BR 层级
+
+### project.md 标记
+
+在 project.md 顶部元数据中添加标记：
+```
+mode: lite
+```
+
+### 与完整模式的兼容
+
+- 轻量模式项目可随时升级为完整模式：`/pace-init --upgrade`（将 PF 归组到自动创建的 BR 下）
+- `/pace-biz` 在 lite 模式项目中仍可使用——首次创建 Epic/BR 时自动升级为完整模式
+- `/pace-dev`、`/pace-change`、`/pace-plan` 等核心命令在 lite 模式下正常工作（跳过 Epic/BR 相关逻辑）
+
+### 初始化引导调整
+
+轻量模式的初始化对话简化为：
+1. 项目名称确认
+2. "这个项目要做什么？"（1-2 句话 → Claude 推断 OBJ + PF）
+3. 确认功能列表 → 完成
+
+不询问 Vision、Strategy、MoS 等高级概念（这些在 full 模式中引导）。
diff --git a/skills/pace-next/SKILL.md b/skills/pace-next/SKILL.md
index 201bc21..ac8cd27 100644
--- a/skills/pace-next/SKILL.md
+++ b/skills/pace-next/SKILL.md
@@ -1,13 +1,13 @@
---
description: Use when user asks "下一步做什么", "接下来做什么", "该做什么", "什么最重要", "应该先做哪个", "最紧急", "优先级", "推荐做什么", "为什么推荐这个", "pace-next", or wants a recommendation for the most important next action across all domains. NOT for current progress overview (use /pace-status).
allowed-tools: Read, Glob, Grep
-argument-hint: "[detail|why]"
+argument-hint: "[detail|why|journey <模板名>]"
model: haiku
---
# /pace-next — 下一步导航
-跨域全局导航：综合 CR、迭代、Release、度量、风险等多维信号，推荐当前最该做的 1 件事。
+跨域全局导航：综合 CR、迭代、Release、度量、风险、Epic/Opportunity 等多维信号，推荐当前最该做的 1 件事。
## 输入
@@ -15,6 +15,9 @@ $ARGUMENTS：
- （空）→ 最高优先级 1 条建议（默认，≤ 3 行）
- `detail` → 展开候选列表（≤ 8 行，含 top-3 建议）
- `why` → 展开推理链（2-5 行，信号扫描 + 优先级对比 + 角色影响 + 备选）
+- `journey [模板名]` → 展示完整工作流路径：从当前状态到目标的分步引导
+ - 可选模板：`new-feature`（默认）、`iteration`、`hotfix`、`release`、`onboarding`
+ - 无模板名 → 根据当前项目状态自动选择最匹配的模板
## 执行路由
@@ -25,6 +28,7 @@ $ARGUMENTS：
| （空） | `next-procedures.md` + `next-procedures-output-default.md` |
| `detail` | `next-procedures.md` + `next-procedures-output-detail.md` |
| `why` | `next-procedures.md` + `next-procedures-output-why.md` |
+| `journey` | `next-procedures.md` + `next-procedures-journey.md` |
## 流程
@@ -48,8 +52,10 @@ $ARGUMENTS：
| `metrics/dashboard.md` | 最近更新日期 |
| `project.md` | MoS、PF/BR/OBJ 映射 |
| `integrations/sync-mapping.md` | 同步状态（存在时） |
+| `epics/*.md` | Epic 状态、BR 列表 |
+| `opportunities.md` | Opportunity 状态 |
-提取关键状态字段（不全量读取）。额外采集 CR→PF→BR 价值链映射。
+提取关键状态字段（不全量读取）。额外采集 CR→PF→BR→Epic→OPP 价值链映射。
### Step 3：优先级决策
@@ -61,8 +67,12 @@ $ARGUMENTS：
| In Progress | S3 继续开发（developing CR）· S4 恢复暂停（paused 阻塞解除） |
| Delivery | S5 Release 待验证 · S6 风险积压（open > 3）· S7 迭代紧迫（< 2 天且 < 50%）· S8 迭代接近完成（> 80%） |
| Strategic | S9 回顾提醒（> 7 天 + merged）· S10 缺陷占比（> 30%）· S11 同步滞后（> 24h）· S12 MoS 达成（> 80%） |
-| Growth | S13 功能未开始 · S14 规划新迭代 · S15 全部完成 |
-| Idle | S16 无信号 |
+| Growth | S13 功能未开始 · S14 规划新迭代 · S15 全部完成 · S16 Epic 需分解 · S17 未评估机会 · S18 功能树稀疏 · S19 范围未定义 · S21 依赖阻塞 · S22 技术债积压 · S24 首次循环引导 |
+| Idle | S20 无信号 |
+
+### Step 3b：旅程路径生成（仅 journey 模式）
+
+journey 模式跳过 Step 3 的信号优先级决策，改为按旅程模板生成分步路径。详见 `next-procedures-journey.md`。
### Step 4：经验增强
diff --git a/skills/pace-next/next-procedures-journey.md b/skills/pace-next/next-procedures-journey.md
new file mode 100644
index 0000000..af2bf8e
--- /dev/null
+++ b/skills/pace-next/next-procedures-journey.md
@@ -0,0 +1,69 @@
+# 旅程编排输出规程
+
+> **职责**：journey 子命令的路径生成和输出格式。建议性编排——展示路径、标识当前位置、引导下一步，但不自动执行。
+
+## 旅程模板定义
+
+| 模板 | 编排路径 | 适用场景 |
+|------|---------|---------|
+| `new-feature` | biz discover → decompose → plan next → dev → review → merged | 从零开始交付一个功能 |
+| `iteration` | plan next → [dev → review → merged]* → plan close → retro | 完整迭代循环 |
+| `hotfix` | feedback report → dev → review → release deploy | 紧急修复 |
+| `release` | release create → deploy → verify → close | 标准发布 |
+| `onboarding` | init → dev(第一个功能) → review → merged | 新用户首次体验 |
+
+## 自动模板选择（无模板名时）
+
+根据项目状态匹配：
+
+| 条件 | 选择模板 | 理由 |
+|------|---------|------|
+| backlog/ 无 CR 且无 merged 记录 | `onboarding` | 新项目首次体验 |
+| 有 deployed 未 verified Release | `release` | 发布流程待完成 |
+| 有 defect/hotfix 类型 developing CR | `hotfix` | 紧急修复进行中 |
+| 有活跃迭代（current.md 存在） | `iteration` | 迭代内持续推进 |
+| 其他 | `new-feature` | 默认起点 |
+
+## 路径生成逻辑
+
+### Step J1：确定当前位置
+
+扫描 `.devpace/` 状态，定位用户在旅程中的当前步骤：
+
+- 读取 state.md 当前工作
+- 读取 backlog/ CR 状态分布
+- 读取 iterations/current.md（如有）
+- 读取 releases/（如有）
+
+### Step J2：生成路径视图
+
+按模板的步骤顺序，标记每步的状态：
+
+| 标记 | 含义 |
+|------|------|
+| ✅ | 已完成 |
+| 👉 | 当前位置（下一步要做的） |
+| ⏳ | 待做 |
+| ⏭️ | 可选/按需 |
+
+### Step J3：输出
+
+```
+旅程：[模板名] — [1 句话目标]
+
+✅ 初始化 — 项目已就绪
+✅ 规划迭代 — 纳入 3 个功能点
+👉 开发 PF-002 — 说"帮我实现 [PF 名]"或 /pace-dev
+⏳ 审批 — /pace-review
+⏳ 迭代回顾 — /pace-retro
+
+进度：2/5 步完成
+```
+
+## 规则
+
+- **只展示不执行**：journey 是建议性的路径展示，不触发任何 Skill 执行
+- **动态更新**：每次调用 journey 都重新扫描状态，路径视图反映最新进度
+- **与默认模式互补**：journey 展示全局路径，默认模式推荐单步行动。用户可交替使用
+- **轻量输出**：路径视图 ≤ 10 行，不展示已完成步骤的详情
+- **无旅程状态文件**：不在 .devpace/ 中持久化旅程状态，完全从项目状态动态推断
diff --git a/skills/pace-next/next-procedures.md b/skills/pace-next/next-procedures.md
index bace5b1..0b2fc41 100644
--- a/skills/pace-next/next-procedures.md
+++ b/skills/pace-next/next-procedures.md
@@ -17,6 +17,8 @@
## Step 2：信号采集
+**缓存优先**：采集前先检查 `.devpace/.signal-cache`（规则见 `knowledge/signal-collection.md` 信号快照缓存章节）。缓存命中（< 5 分钟）→ 直接使用缓存中的 `triggered` 和 `top_signal`，跳过 Step 2 完整采集。缓存过期或不存在 → 执行以下完整采集步骤。
+
**读取策略**：
- 使用 Glob 扫描 `backlog/*.md`、`releases/*.md`、`risks/*.md`，再用 Grep 提取状态字段
- 文件不存在或目录为空时，相关信号视为"未命中"
diff --git a/skills/pace-plan/SKILL.md b/skills/pace-plan/SKILL.md
index 9372d52..02d469c 100644
--- a/skills/pace-plan/SKILL.md
+++ b/skills/pace-plan/SKILL.md
@@ -10,11 +10,12 @@ agent: pace-pm
管理迭代的关闭和新迭代的规划，补齐产品闭环中的"规划→执行→回顾"循环。
-## 与 /pace-change 的关系
+## 与相关命令的关系
-- `/pace-change`：PF 级需求变更（add/pause/resume/modify）
+- `/pace-change`：PF/BR/Epic 级需求变更（add/pause/resume/modify）
+- `/pace-biz`：业务规划域（Opportunity→Epic→BR 的创建和分解）
- `/pace-plan adjust`：迭代范围级调整（本迭代纳入/移出哪些 PF）
-- 典型协同：`/pace-change add` 插入新 PF 后容量超出 → 建议 `/pace-plan adjust` 调整迭代范围
+- 典型协同：`/pace-biz decompose` 分解出 BR/PF → `/pace-plan next` 纳入迭代 → `/pace-dev` 开始开发
## 输入
@@ -42,8 +43,8 @@ $ARGUMENTS：
### Step 1：评估当前迭代状态
1. 读取 `.devpace/iterations/current.md`（不存在则跳到 Step 3）
-2. 读取 `.devpace/project.md` 的价值功能树
-3. 汇总：PF 完成率（✅ 数 / 总数）、未完成 PF 列表及 CR 状态、变更记录条数
+2. 读取 `.devpace/project.md` 的价值功能树（有 Epic 时按 Epic 分组展示）
+3. 汇总：PF 完成率（✅ 数 / 总数）、未完成 PF 列表及 CR 状态、变更记录条数、Epic 完成度（如有）
4. 用 1-2 句话告知用户当前迭代进展
### Step 3：规划新迭代
diff --git a/skills/pace-plan/plan-procedures.md b/skills/pace-plan/plan-procedures.md
index 196a407..0c034df 100644
--- a/skills/pace-plan/plan-procedures.md
+++ b/skills/pace-plan/plan-procedures.md
@@ -69,10 +69,23 @@
### 3.6 回顾建议直联
+读取上一迭代回顾和最近经验，为新迭代规划提供参考：
+
+**迭代回顾建议**：
读取上一迭代 `iter-N.md`（N 为最新归档）的回顾 section（如有"下迭代建议"段）：
- 有建议 → 展示给用户："上一迭代回顾建议：[内容]"
- 无回顾 section 或无建议 → 静默跳过
+**近期经验 Pattern**：
+读取 `.devpace/metrics/insights.md`（不存在则跳过），提取最近 3 条 improvement 和 defense pattern：
+- 有匹配 → 在 Plan Proposal（Step 3.7）的工作量评估中标注："经验提示：[pattern 摘要]，建议候选 PF 排序时考虑"
+- 无匹配 → 静默跳过
+
+**回顾 accept 待办**：
+检查上一迭代 retro 输出中是否有未执行的 accept 建议（`iter-N.md` 中 `[ ]` 未勾选项）：
+- 有未执行项 → 提醒："上一迭代有 N 项回顾建议尚未执行：[摘要]。是否纳入本迭代？"
+- 全部已执行或无 accept 项 → 静默跳过
+
### 3.7 智能规划建议（Plan Proposal）
取代原有的逐项填空模式，Claude 先生成建议方案，用户确认或调整。
diff --git a/skills/pace-pulse/pulse-procedures-core.md b/skills/pace-pulse/pulse-procedures-core.md
index f766f16..894f767 100644
--- a/skills/pace-pulse/pulse-procedures-core.md
+++ b/skills/pace-pulse/pulse-procedures-core.md
@@ -120,3 +120,54 @@
### 信号冷却期
- 被忽略的信号（用户未执行建议命令）设置 3 个 checkpoint 冷却期
- 冷却期内不再触发同类信号（除非严重度升级）
+
+## 自主级别评估（每 5 个 CR merged 后触发）
+
+### 触发条件
+
+当 `.devpace/backlog/` 中 merged CR 数量达到 5 的倍数（5, 10, 15...）时触发评估。通过 state.md 教学标记中的 `autonomy_eval_at_N` 记录上次评估点，避免重复。
+
+### 评估维度
+
+读取 `.devpace/metrics/dashboard.md`（不存在则跳过评估）：
+
+| 指标 | 升级阈值（→ 更自主） | 降级阈值（→ 更辅助） |
+|------|---------------------|---------------------|
+| Gate 1 一次通过率 | > 80% | < 50% |
+| Gate 2 一次通过率 | > 70% | < 40% |
+| 打回率（rejected/total） | < 15% | > 40% |
+| 用户纠正频率（人工修改 CR 文件次数/总 CR） | < 10% | > 30% |
+
+### 决策逻辑
+
+| 当前级别 | 满足升级条件 | 满足降级条件 | 动作 |
+|---------|------------|------------|------|
+| 辅助 | 全部 4 项达标 | — | 建议升级到"标准" |
+| 标准 | 全部 4 项达标 | — | 建议升级到"自主" |
+| 标准 | — | 任意 2+ 项触发 | 建议降级到"辅助" |
+| 自主 | — | 任意 2+ 项触发 | 建议降级到"标准" |
+| 任意 | 不满足 | 不满足 | 维持当前级别，不输出 |
+
+### 输出格式
+
+建议升级时：
+```
+自主级别建议：当前"[级别]" → 建议升级到"[级别]"
+依据：Gate 通过率 N%、打回率 N%（连续 5 个 CR 表现稳定）
+确认升级？（升级后 Claude 在 [具体行为变化] 时会更自主）
+```
+
+建议降级时：
+```
+自主级别建议：当前"[级别]" → 建议调整到"[级别]"
+依据：近期打回率 N%、Gate 通过率 N%，建议增加引导
+确认调整？
+```
+
+### 规则
+
+- **只建议不自动**：所有级别变更必须用户确认
+- **静默优先**：维持当前级别时不输出任何内容
+- **最低频率**：每 5 个 merged CR 最多评估 1 次
+- 用户确认后 → 更新 project.md 的自主级别字段
+- 用户拒绝 → 记录 `autonomy_eval_at_N` 标记，下次 5 个 CR 后再评估
diff --git a/skills/pace-pulse/pulse-procedures-session-start.md b/skills/pace-pulse/pulse-procedures-session-start.md
index 4a9e60a..436a552 100644
--- a/skills/pace-pulse/pulse-procedures-session-start.md
+++ b/skills/pace-pulse/pulse-procedures-session-start.md
@@ -19,6 +19,7 @@
- `.devpace/metrics/dashboard.md` 的"最近更新"日期（**目录不存在时跳过**）
- `.devpace/backlog/` 中状态为 `in_review` 的 CR 数量
+- `.devpace/backlog/` 中状态为 `merged` 的 CR 数量（**目录不存在或无任何 merged CR 时视为 0，用于 onboarding 信号判定**）
- `.devpace/iterations/current.md`（**文件不存在时跳过迭代相关检测**）
## 信号优先级（分层摘要，≤3 行）
@@ -29,6 +30,7 @@
| 优先级 | 条件 | 提醒 |
|--------|------|------|
+| 0 | `.devpace/` 存在 + backlog/ 中 merged CR = 0（目录不存在或为空也视为 0） | "首次使用——试试说"帮我实现 [功能名]"开始第一个功能，或用 `/pace-biz discover` 从业务目标出发" |
| 1 | in_review CR > 0 | "有 N 个变更等待 review——`/pace-review`" |
| 2 | deployed 未 verified Release | "有未验证的 Release——`/pace-release verify`" |
| 3 | 迭代完成率 > 80% | "迭代接近完成——`/pace-plan next`" |
@@ -40,3 +42,7 @@
| 9 | dashboard.md 最近更新 > 14 天 + MoS 有未勾选项 | "距上次回顾已超 2 周——`/pace-retro`" |
| 10 | Snooze 条目触发条件满足（CR 事件表/迭代变更记录） | "之前延后的变更触发条件已满足（详情见 `pulse-procedures-snooze.md`）" |
| 11 | 用户对话含运维关键词 + pace-feedback 未在本会话使用 | "检测到生产问题描述——`/pace-feedback report`" |
+
+## 缓存写入
+
+信号检测完成后，将结果写入 `.devpace/.signal-cache`（格式见 `knowledge/signal-collection.md` 信号快照缓存章节）。写入失败时静默跳过，不影响信号输出。
diff --git a/skills/pace-release/SKILL.md b/skills/pace-release/SKILL.md
index f16cc9b..71f1280 100644
--- a/skills/pace-release/SKILL.md
+++ b/skills/pace-release/SKILL.md
@@ -29,7 +29,7 @@ $ARGUMENTS：
- `changelog` → 仅生成 CHANGELOG.md
- `version` → 仅更新版本文件
- `tag` → 仅创建 Git Tag / GitHub Release
-- `notes` → 生成面向用户的 Release Notes（按 BR/PF 组织，支持 `--role biz|ops|pm`）
+- `notes` → 生成面向用户的 Release Notes（按 Epic→BR→PF 组织，支持 `--role biz|ops|pm`）
- `branch` → 管理发布分支（创建 / PR / 合并）
- `rollback` → 记录回滚（deployed 状态下出现严重问题时）
- `status history` → 发布历史时间线（跨 Release 纵向视图 + DORA 趋势）
diff --git a/skills/pace-retro/SKILL.md b/skills/pace-retro/SKILL.md
index 7dc4a29..8009c1d 100644
--- a/skills/pace-retro/SKILL.md
+++ b/skills/pace-retro/SKILL.md
@@ -1,7 +1,7 @@
---
-description: Use when user says "回顾", "复盘", "度量", "retro", "总结", "数据分析", "DORA", "质量报告", "交付效率", "度量报告", "趋势", "中期检查", "对比", "pace-retro", or at iteration end when reviewing progress and metrics.
+description: Use when user says "回顾", "复盘", "度量", "retro", "总结", "数据分析", "DORA", "质量报告", "交付效率", "度量报告", "趋势", "中期检查", "对比", "预测", "forecast", "能按时交付吗", "交付概率", "瓶颈", "pace-retro", or at iteration end when reviewing progress and metrics.
allowed-tools: Read, Write, Edit, Glob, Bash
-argument-hint: "[update|focus <维度>|compare|history|mid|accept]"
+argument-hint: "[update|focus <维度>|compare|history|mid|accept|forecast]"
context: fork
agent: pace-analyst
---
@@ -35,11 +35,12 @@ agent: pace-analyst
$ARGUMENTS：
- （空）→ 当前迭代完整回顾
- `update` → 仅刷新度量数据，不生成报告（带变化反馈）
-- `focus <维度>` → 聚焦回顾：quality | delivery | dora | defects | value | knowledge
+- `focus <维度>` → 聚焦回顾：quality | delivery | dora | defects | value | knowledge | epic
- `compare` → 对比回顾：当前迭代 vs 上一迭代的关键指标 delta
- `history` → 趋势总览：跨 3+ 迭代的趋势线（基于 dashboard.md 历史快照）
- `mid` → 中期检查：轻量版回顾，不更新 dashboard 基准线
- `accept` → 确认回顾建议：执行 MoS 更新等上一次回顾建议的操作
+- `forecast` → 交付预测：基于历史模式预测迭代交付概率、识别瓶颈、发出风险预警
### 执行路由表
@@ -60,6 +61,7 @@ $ARGUMENTS：
| `history` | `retro-procedures-history.md`（自包含，不加载 common） | 跨迭代趋势 |
| `mid` | `retro-procedures-mid.md`（自包含，不加载 common） | 中期轻量检查 |
| `accept` | `retro-procedures-accept.md`（自包含，不加载 common） | 执行建议操作 |
+| `forecast` | `retro-procedures-forecast.md`（自包含，不加载 common） | 交付预测分析 |
**路由规则**：只读取路由表映射的 procedures 文件，不加载其他文件。compare/history/mid/accept 自包含，不加载 common。
diff --git a/skills/pace-retro/retro-procedures-forecast.md b/skills/pace-retro/retro-procedures-forecast.md
new file mode 100644
index 0000000..750dbe9
--- /dev/null
+++ b/skills/pace-retro/retro-procedures-forecast.md
@@ -0,0 +1,103 @@
+# 预测性项目管理规程
+
+> **职责**：/pace-retro forecast 子命令——基于历史数据和当前状态，预测迭代交付概率、识别瓶颈、发出风险预警。
+
+## §0 速查卡片
+
+| 输入 | 输出 | 数据源 |
+|------|------|--------|
+| `/pace-retro forecast` | 交付概率 + 瓶颈 + 风险预警 | dashboard.md + backlog/ + iterations/ + insights.md + risks/ |
+
+## 数据采集
+
+### Step 1: 收集历史模式
+
+1. **CR 周期数据**：从 dashboard.md 历史快照提取已完成 CR 的平均周期（created→merged 天数）
+2. **Gate 通过率**：Gate 1/2/3 首次通过率（从 CR 事件表统计）
+3. **变更频率**：当前迭代的 change 事件数量（iterations/current.md 变更记录）
+4. **风险趋势**：`.devpace/risks/` 中 open 状态风险数量和严重度分布
+5. **经验模式**：insights.md 中与当前 CR 类似的 defense/improvement pattern
+
+### Step 2: 评估当前状态
+
+1. **迭代进度**：已完成 PF 数 / 总 PF 数 = 功能完成率
+2. **时间进度**：已过天数 / 迭代总天数 = 时间消耗率
+3. **进行中 CR**：当前 developing/verifying/in_review 状态的 CR 数量和停留时间
+4. **阻塞 CR**：paused 或有未解决依赖的 CR
+
+## 预测算法
+
+### 交付概率计算
+
+```
+基础概率 = 功能完成率 / 时间消耗率
+
+调整因子：
+ - 进行中 CR 平均停留 > 历史均值 × 1.5 → -15%
+ - 有 High 风险未解决 → -20%
+ - 本迭代变更频率 > 历史均值 × 2 → -10%
+ - Gate 首次通过率 > 80% → +5%
+ - 有匹配的 defense pattern → -5%（历史教训预警）
+
+最终概率 = clamp(基础概率 × (1 + 调整因子之和), 5%, 95%)
+```
+
+### 概率分级
+
+| 概率 | 等级 | 标记 |
+|------|------|------|
+| ≥ 80% | 高信心 | 🟢 |
+| 50-79% | 中等风险 | 🟡 |
+| < 50% | 高风险 | 🔴 |
+
+### 瓶颈识别
+
+扫描以下瓶颈模式：
+
+| 模式 | 检测规则 | 建议 |
+|------|---------|------|
+| CR 滞留 | developing 停留 > 历史均值 × 2 | "CR-xxx 开发耗时异常，建议评估是否需要拆分" |
+| Gate 阻塞 | 同一 CR Gate 失败 ≥ 2 次 | "CR-xxx Gate N 反复失败，建议聚焦质量问题" |
+| 依赖阻塞 | CR 被 paused/blocked 且有下游依赖 | "CR-xxx 阻塞了 N 个下游 CR" |
+| 范围蔓延 | 迭代 PF 数 > 规划时 × 1.3 | "迭代范围增长 30%+，建议评估容量" |
+
+### 风险预警
+
+基于趋势数据发出预警：
+
+| 预警 | 触发条件 | 建议 |
+|------|---------|------|
+| 交付延迟 | 概率 < 50% 且时间消耗 > 60% | "/pace-plan adjust 调整范围" |
+| 质量下降 | Gate 通过率连续下降 | "聚焦代码质量，考虑增加审查" |
+| 技术债务积累 | tech-debt CR 连续 2 迭代超预算 | "提高 tech-debt-budget 或暂停新功能" |
+| 风险积压 | open High 风险 ≥ 3 | "/pace-guard report 查看详情并制定解决计划" |
+
+## 输出格式
+
+```markdown
+## 迭代交付预测
+
+**交付概率**：[🟢/🟡/🔴] [N]%
+**评估基础**：功能完成 X/Y · 时间消耗 A/B 天 · 进行中 CR Z 个
+
+### 调整因子
+| 因子 | 影响 | 说明 |
+|------|------|------|
+| [因子名] | [+/-N%] | [原因] |
+
+### 瓶颈（如有）
+1. [瓶颈描述] → 建议：[行动]
+
+### 风险预警（如有）
+- [⚠️ 预警描述] → [建议行动]
+
+### 建议
+- [最优先的 1-3 条行动建议]
+```
+
+## 规则
+
+- **只读**：forecast 不修改任何文件，仅输出分析报告
+- **数据不足时降级**：历史快照 < 2 条时，跳过趋势分析，仅基于当前状态评估
+- **不替代人类判断**：概率是参考值，标注"基于历史数据的 AI 预测，仅供参考"
+- **与 mid 互补**：mid 是轻量健康检查（不含预测），forecast 是深度预测分析
diff --git a/skills/pace-retro/retro-procedures.md b/skills/pace-retro/retro-procedures.md
index cba67fd..78afce5 100644
--- a/skills/pace-retro/retro-procedures.md
+++ b/skills/pace-retro/retro-procedures.md
@@ -108,6 +108,7 @@
| 条件段 | 出现条件 | 数据源 |
|--------|---------|--------|
| 风险趋势 | `.devpace/risks/` 存在 | 风险文件 + insights.md defense |
+| 技术债务趋势 | 存在 type:tech-debt CR | backlog/ tech-debt CR + project.md 预算配置 |
| 缺陷分析 | 存在 type:defect/hotfix CR | backlog/ defect CR |
| MoS 进展评估 | project.md 有 MoS | project.md + dashboard.md |
| DORA 代理度量 | `.devpace/releases/` 存在 | Release 文件 |
@@ -152,6 +153,36 @@
---
+## 技术债务趋势（存在 type:tech-debt CR 时）
+
+数据采集：
+1. `.devpace/backlog/` 中 type 为 `tech-debt` 的 CR 文件
+2. `dashboard.md` 历史快照中 tech-debt CR 数量
+3. `project.md` 配置中 `tech-debt-budget` 值（默认 20%）
+
+输出格式（追加到回顾报告中）：
+
+```
+## 技术债务趋势
+
+- 当前 tech-debt CR：{{N}} 个（完成 {{done}} · 进行中 {{wip}} · 待做 {{todo}}）
+- 债务预算使用率：{{actual}}% / {{budget}}%（{{over/under}} 预算）
+- 趋势：{{上升/下降/稳定}}（对比上迭代 {{prev}} 个）
+```
+
+趋势判定：
+- 当前 > 上迭代 × 1.2 = 上升（债务积累）
+- 当前 < 上迭代 × 0.8 = 下降（债务偿还有效）
+- 其他 = 稳定
+
+持久化规则：
+- tech-debt CR 数量和预算使用率写入 `dashboard.md` 历史快照
+- 连续 3 迭代超预算 → 在改进建议中追加"建议提高 tech-debt-budget 或加速偿还"
+
+条件渐进暴露：无 tech-debt 类型 CR 时，整个技术债务趋势段**静默跳过**。
+
+---
+
## 经验沉淀规则
diff --git a/skills/pace-review/SKILL.md b/skills/pace-review/SKILL.md
index acc83a6..54a0ca0 100644
--- a/skills/pace-review/SKILL.md
+++ b/skills/pace-review/SKILL.md
@@ -15,7 +15,7 @@ hooks:
# /pace-review — 生成 Review 摘要
-为到达 in_review 状态的变更请求生成人类可读的审核摘要。
+为到达 in_review 状态的变更请求生成人类可读的审核摘要。追溯链展示至 Epic 层（CR→PF→BR→Epic→OBJ）。
## 输入
diff --git a/skills/pace-review/review-procedures-gate.md b/skills/pace-review/review-procedures-gate.md
index 236d263..b64a94f 100644
--- a/skills/pace-review/review-procedures-gate.md
+++ b/skills/pace-review/review-procedures-gate.md
@@ -157,26 +157,49 @@ Gate 3 人类审批前，生成变更到验收条件的映射报告，降低审
- **与 Gate 2 互补**：Gate 2 逐条验收比对检查"做没做到"，累积 Diff 报告展示"怎么做到的"——两者互补
- **嵌入摘要**：报告作为 Review 摘要的一部分呈现给人类审批者，不独立输出
+## 语义一致性评分
+
+Review 摘要中自动计算代码变更与验收标准的语义对齐度。
+
+### 计算步骤
+
+1. 读取 CR 关联 PF 的验收标准列表
+2. 对每个验收标准，评估当前 CR 的代码变更是否有直接实现：
+ - 有对应代码变更（函数/文件/模块可关联到标准描述）→ 计为"已覆盖"
+ - 代码变更方向与标准描述不一致 → 标记为"偏离"
+3. 计算一致性评分：已覆盖 / 总标准数
+
+### 评分分级
+
+| 比例 | 等级 | 说明 |
+|------|------|------|
+| ≥ 80% 已覆盖且无偏离 | 🟢 高 | 代码实现与需求高度对齐 |
+| 50-79% 已覆盖或有少量偏离 | 🟡 中 | 部分对齐，需关注未覆盖项 |
+| < 50% 已覆盖或有多项偏离 | 🔴 低 | 可能存在需求理解偏差 |
+
+### 规则
+
+- **S CR 简化**：仅检查意图 section 的验收条件（通常 1-3 条），不需要 PF 级标准
+- **无 PF 关联时跳过**：不显示此段
+- **与 Gate 2 意图匹配互补**：意图匹配检查"做没做到"，语义一致性量化"做对了多少"
+- **偏离项突出**：有偏离时在摘要中列出具体标准和实际实现方向
+
+---
+
## accept 报告结构化消费
当 CR 验证证据 section 包含 `/pace-test accept` 的验收验证报告时，Review 摘要自动提取关键信号。
+**数据契约**：accept 报告的格式定义见 `knowledge/_schema/accept-report-contract.md`（生产方和消费方的共享接口）。
+
### 提取步骤
+按 `accept-report-contract.md` "消费方提取规则"执行：
+
1. 读取 CR 文件的"验证证据"section
-2. 如果包含"验收验证报告"标题 → 提取以下数据：
- - **逐条验证结果表**：统计通过/未通过/需人工数量 + 验证级别分布
- - **测试预言审查表**（如存在）：统计有效覆盖/弱覆盖/虚假覆盖数量
- - **合理化自审计**（如存在）：提取命中合理化模式的数量
- - **置信度数据**（如存在）：统计 L2 条目的 High/Medium/Low 分布
+2. 如果包含"验收验证报告"标题 → 按契约定义的提取项提取汇总数据
3. 如果"验证证据"不包含 accept 报告 → 跳过此 section（不显示、不提示）
-### 消费原则
-
-- **紧凑优先**：Review 摘要中仅显示汇总数据（1-3 行），不复制完整 accept 报告
-- **风险聚焦**：如有未通过项或弱覆盖 → 在"风险点"段追加相关信息
-- **不重复验证**：Review 消费已有的 accept 报告，不重新执行验收验证
-
## M 级：标准摘要格式
中等复杂度 CR 使用标准格式，包含意图匹配和对抗审查。
@@ -209,6 +232,8 @@ Gate 3 人类审批前，生成变更到验收条件的映射报告，降低审
**累积变更报告**：
[模块分组 + 验收条件映射，格式见上方]
+**语义一致性**：[🟢高/🟡中/🔴低] N/M 验收标准有直接代码实现 · 偏离项：[列表或"无"]
+
**质量检查状态**：
✅ [已通过的自动质量检查项]
⏳ 人类审批
@@ -251,6 +276,8 @@ Gate 3 人类审批前，生成变更到验收条件的映射报告，降低审
**累积变更报告**：
[模块分组 + 验收条件映射，格式见上方]
+**语义一致性**：[🟢高/🟡中/🔴低] N/M 验收标准有直接代码实现 · 偏离项：[列表或"无"]
+
**质量检查状态**：
✅ [已通过的自动质量检查项]
⏳ 人类审批
diff --git a/skills/pace-status/SKILL.md b/skills/pace-status/SKILL.md
index 9864d0a..3ce4840 100644
--- a/skills/pace-status/SKILL.md
+++ b/skills/pace-status/SKILL.md
@@ -29,7 +29,7 @@ $ARGUMENTS：
| `detail` | `status-procedures-detail.md` | 功能树格式 + 同步标记 + 角色适配 + 导航 |
| `trace <名称>` | `status-procedures-trace.md` | 匹配规则 + 3 种追溯格式 + 导航 |
| `metrics [类别]` | `status-procedures-metrics.md` | 实时快照（≠ pace-retro 回顾报告）+ 趋势箭头 + 类别聚焦 + 导航 |
-| `tree` | `status-procedures-tree.md` | 完整价值链格式 + 导航 |
+| `tree` | `status-procedures-tree.md` | 完整价值链格式（含 Epic 链接层）+ 导航 |
| `since <时间>` | `status-procedures-since.md` | 时间标记解析 + 数据采集 + 组合规则 |
| `chain` | `status-procedures-chain.md` | 价值链定位格式 + 导航 |
| `<关键词>` | `status-procedures-keyword.md` | 搜索逻辑 + fallback 引导 |
diff --git a/skills/pace-status/status-procedures-overview.md b/skills/pace-status/status-procedures-overview.md
index e4ff2c6..09a4ff9 100644
--- a/skills/pace-status/status-procedures-overview.md
+++ b/skills/pace-status/status-procedures-overview.md
@@ -18,6 +18,8 @@
## 建议下一步（概览末尾附加）
+**缓存优先**：概览信号采集前先检查 `.devpace/.signal-cache`（规则见 `knowledge/signal-collection.md`）。缓存命中（< 5 分钟）→ 使用缓存的 `top_signal` 字段作为建议行信号源。缓存过期 → 执行完整采集。
+
**定位**：/pace-next 的**轻量子集**——仅 top-1 信号 + 命令指引，不含推理。多信号竞争取最高优先级 1 条并追加候选计数。
**权威源**：`knowledge/signal-priority.md`。本表仅暴露 `status-subset = ✅` 的信号子集，编号和条件与权威源一致。
diff --git a/skills/pace-sync/SKILL.md b/skills/pace-sync/SKILL.md
index 54dafa1..e52bb53 100644
--- a/skills/pace-sync/SKILL.md
+++ b/skills/pace-sync/SKILL.md
@@ -1,5 +1,5 @@
---
-description: "Use when user wants to sync devpace state with external tools (GitHub/Linear/Jira), says '同步/sync/push/pull/关联 Issue/配置同步/setup/解除关联/unlink/创建 Issue/create/同步状态/status', or /pace-sync. NOT for internal devpace state changes (use /pace-dev) or release operations (use /pace-release)"
+description: "Use when user wants to sync devpace state with external tools (GitHub/Linear/Jira), says '同步/sync/push/pull/关联 Issue/配置同步/setup/解除关联/unlink/创建 Issue/create/同步状态/status/CI/构建/build/pipeline/workflow/GitHub Actions', or /pace-sync. NOT for internal devpace state changes (use /pace-dev) or release operations (use /pace-release)"
argument-hint: "[子命令] [参数]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion
model: sonnet
@@ -35,6 +35,9 @@ model: sonnet
| unlink | CR-ID | 解除 CR 与外部实体的关联 | ✅ |
| create | CR-ID | 从 CR 元数据创建外部 Issue 并自动关联 | ✅ |
| pull | CR-ID | 查询外部状态，提示用户是否更新 devpace（轻量 MVP） | ✅ |
+| ci status | — | 查看当前分支的 CI/CD 运行状态 | ✅ |
+| ci trigger | [workflow] | 手动触发 GitHub Actions workflow | ✅ |
+| ci logs | [run-id] | 查看指定运行的日志摘要 | ✅ |
| sync | [CR-ID] | 双向同步 | Phase 20 |
| resolve | CR-ID | 解决同步冲突 | Phase 20 |
| status | — | 查看所有 CR 的同步状态和外部链接 | ✅ |
@@ -56,6 +59,7 @@ model: sonnet
| `push --dry-run` | sync-procedures-push.md + sync-procedures-push-advanced.md |
| `pull` | sync-procedures-pull.md |
| `status` / `unlink` / （空） | sync-procedures-status.md |
+| `ci status` / `ci trigger` / `ci logs` | sync-procedures-ci.md |
| `sync` / `resolve` | Phase 20，暂不支持 |
Gate 结果同步（被动触发）：sync-procedures-push.md + sync-procedures-push-advanced.md
diff --git a/skills/pace-sync/sync-procedures-ci.md b/skills/pace-sync/sync-procedures-ci.md
new file mode 100644
index 0000000..3239ec8
--- /dev/null
+++ b/skills/pace-sync/sync-procedures-ci.md
@@ -0,0 +1,86 @@
+# CI/CD 集成规程
+
+> **职责**：通过 `gh` CLI 实现 GitHub Actions 的状态查询、触发和日志查看。
+
+## 前置检测
+
+所有 ci 子命令执行前：
+
+1. 检查 `gh` CLI 是否可用：`which gh`（不可用 → 提示安装 GitHub CLI）
+2. 检查 `gh auth status`（未认证 → 提示 `gh auth login`）
+3. 检查 `.github/workflows/` 目录是否存在（不存在 → 提示无 GitHub Actions 配置）
+
+## ci status
+
+查看当前分支最近的 CI 运行状态。
+
+**执行**：
+```bash
+gh run list --branch $(git branch --show-current) --limit 5
+```
+
+**输出格式**：
+```
+CI 状态（当前分支：main）：
+✅ Build & Test — 2 分钟前 — 通过
+❌ Deploy — 5 分钟前 — 失败（查看详情：gh run view ）
+⏳ Lint — 进行中
+
+最近 5 次运行中 4 次通过（80%）
+```
+
+**与 Gate 4 集成**：pace-dev Gate 4 可调用本规程的 status 逻辑替代原有的简单查询。在 status 输出末尾追加："Gate 4 CI 检查：[通过/失败]"。
+
+## ci trigger
+
+手动触发 GitHub Actions workflow。
+
+**执行**：
+1. 无参数 → 列出可用 workflow：`gh workflow list`
+2. 有参数 → 触发指定 workflow：`gh workflow run --ref $(git branch --show-current)`
+3. 触发后轮询状态（最多 3 次，间隔 10 秒）：`gh run list --workflow --limit 1`
+
+**输出格式**：
+```
+已触发 workflow：[名称]
+运行 ID：[id]
+状态：⏳ 进行中（预计 2 分钟）
+
+查看实时日志：gh run watch
+```
+
+**安全约束**：
+- 触发前确认："即将触发 [workflow 名] 在 [分支] 上运行。确认？"
+- 用户确认后才执行
+
+## ci logs
+
+查看指定运行的日志摘要。
+
+**执行**：
+1. 有 run-id → `gh run view --log-failed`（优先显示失败日志）
+2. 无 run-id → 取最近一次运行：`gh run list --limit 1` 后自动 view
+
+**输出格式**：
+```
+运行 #[id]：[workflow 名] — [状态]
+失败步骤：[step 名]
+错误摘要：[最后 10 行日志]
+
+完整日志：gh run view --log
+```
+
+## 容错
+
+| 异常 | 处理 |
+|------|------|
+| `gh` 未安装 | 提示："需要 GitHub CLI（gh）。安装：" |
+| 未认证 | 提示："运行 `gh auth login` 完成认证" |
+| 无 workflow | 提示："未找到 .github/workflows/，项目尚未配置 GitHub Actions" |
+| 非 GitHub 仓库 | 提示："当前项目不是 GitHub 仓库，ci 命令仅支持 GitHub Actions" |
+| 网络错误 | 提示具体错误，建议检查网络连接 |
+
+## 与现有能力的关系
+
+- **Gate 4**：现有 Gate 4 通过 `checks-format.md` 中的 `ci-status-cmd` 查询 CI 状态。ci status 提供更丰富的信息，可作为 Gate 4 的增强数据源
+- **pace-release deploy**：Release 部署步骤可在 deploy 后自动调用 ci status 确认部署 CI 是否通过
diff --git a/skills/pace-trace/SKILL.md b/skills/pace-trace/SKILL.md
index 74d44c7..5713120 100644
--- a/skills/pace-trace/SKILL.md
+++ b/skills/pace-trace/SKILL.md
@@ -1,7 +1,7 @@
---
-description: Use when user asks "why did devpace decide X", "追溯", "为什么这样做", "决策记录", "决策原因", wants to see AI decision trail, or says /pace-trace [CR] [gate/decision]
-allowed-tools: Read, Glob, Grep
-argument-hint: "[CR 名称或编号] [gate1 质量检查|gate2 集成验证|gate3 审批摘要|intent 意图推断|change 变更影响|risk 风险评估|autonomy 自主决策|timeline 决策时间线]"
+description: Use when user asks "why did devpace decide X", "追溯", "为什么这样做", "决策记录", "决策原因", "架构决策", "ADR", "技术选型", wants to see AI decision trail or manage architecture decisions, or says /pace-trace [CR] [gate/decision/arch]
+allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion
+argument-hint: "[CR 名称或编号] [gate1|gate2|gate3|intent|change|risk|autonomy|timeline|arch]"
model: haiku
---
@@ -15,7 +15,7 @@ model: haiku
|------|-----------|---------|
| `/pace-trace [CR] [type]` | "Claude 为什么这样判断？" | 单个决策的审计轨迹 |
| `/pace-trace [CR] timeline` | "这个 CR 经历了什么？" | CR 全生命周期决策时间线 |
-| `/pace-status trace ` | "这个目标完成到哪了？" | 价值链完成度（OBJ→BR→PF→CR） |
+| `/pace-status trace ` | "这个目标完成到哪了？" | 价值链完成度（OBJ→Epic→BR→PF→CR→OPP） |
| `/pace-theory why` | "devpace 为什么这样设计？" | 系统方法论解释 |
## 输入
@@ -40,6 +40,7 @@ model: haiku
| `gate1` / `gate2` / `gate3` | `trace-procedures-gates.md` | Gate 类型输出要点 + 导航建议 |
| `intent` / `change` / `risk` / `autonomy` | `trace-procedures-analysis.md` | 分析类输出调整 + 导航建议 |
| `timeline` | `trace-procedures-timeline.md`（自包含，不加载 common） | CR 全生命周期决策时间线 |
+| `arch` | `trace-procedures-arch.md`（自包含，不加载 common） | 架构决策记录（ADR）管理 |
| 无指定 | 查 CR 事件表最新 checkpoint 类型，匹配上述路由 | 先确定类型再加载对应文件 |
**路由规则**：只读取路由表映射的 procedures 文件，不加载其他文件。timeline 自包含，不加载 common。
diff --git a/skills/pace-trace/trace-procedures-arch.md b/skills/pace-trace/trace-procedures-arch.md
new file mode 100644
index 0000000..49a53f8
--- /dev/null
+++ b/skills/pace-trace/trace-procedures-arch.md
@@ -0,0 +1,83 @@
+# 架构决策记录规程
+
+> **职责**：/pace-trace arch 子命令——创建、查看和管理架构决策记录（ADR）。
+
+## §0 速查卡片
+
+| 操作 | 命令 | 说明 |
+|------|------|------|
+| 创建 ADR | `/pace-trace arch "决策标题"` | 交互式引导创建 ADR |
+| 查看 ADR | `/pace-trace arch ADR-NNN` | 查看指定 ADR |
+| 列出所有 | `/pace-trace arch list` | 列出所有 ADR 及状态 |
+| 取代 ADR | `/pace-trace arch supersede ADR-NNN` | 标记旧 ADR 为 superseded |
+
+## 从 pace-dev 自动触发
+
+当 L/XL CR 的技术方案评审（`dev-procedures-intent.md` Phase B0）满足 ADR 触发条件时：
+- pace-dev 在 merged 后的连锁更新中提醒："此 CR 涉及架构决策，建议 `/pace-trace arch` 记录"
+- 用户确认 → 进入标准 ADR 创建流程（预填 CR 编号和方案信息）
+- 用户跳过 → 在 CR 事件表标注"ADR 建议未采纳"
+
+## 创建流程
+
+### Step 1: 确定 ADR 编号
+
+1. 读取 `.devpace/decisions/` 目录
+2. 找到最大编号 → 新编号 = 最大 + 1
+3. 目录不存在 → 创建目录 + ADR-001
+
+### Step 2: 交互式引导
+
+引导用户填写以下信息（按 `knowledge/_schema/adr-format.md` 格式）：
+
+1. **决策标题**：从 $ARGUMENTS 获取，或询问
+2. **上下文**：面临什么技术问题？
+3. **决策**：选择了什么方案？
+4. **理由**：为什么选择这个？
+5. **替代方案**（可选）：考虑过哪些？
+
+### Step 3: 写入文件
+
+1. 按 adr-format.md 模板生成文件
+2. 状态设为 `accepted`（用户已确认决策）
+3. 如有关联 CR → 同时在 CR 事件表记录 `ADR-NNN created`
+
+### Step 4: 输出确认
+
+```
+已创建架构决策：ADR-NNN — [标题]
+状态：accepted
+位置：.devpace/decisions/ADR-NNN.md
+```
+
+## 查看流程
+
+1. 读取指定 ADR 文件
+2. 格式化输出（标题、状态、日期、摘要）
+3. 如 ADR 被取代 → 显示取代者链接
+
+## 列表流程
+
+1. 扫描 `.devpace/decisions/ADR-*.md`
+2. 提取每个 ADR 的标题和状态
+3. 表格输出：
+
+```
+| # | 标题 | 状态 | 日期 |
+|---|------|------|------|
+| ADR-001 | 选择 PostgreSQL | accepted | 2026-01-15 |
+| ADR-002 | 微服务架构 | superseded → ADR-005 | 2026-02-01 |
+```
+
+## 取代流程
+
+1. 读取目标 ADR
+2. 将状态改为 `superseded`
+3. 填写"被取代"字段 → 指向新 ADR
+4. 引导创建新 ADR（替代方案）
+
+## 规则
+
+- ADR 一旦 accepted，内容不可修改（只能 supersede 后创建新版本）
+- 目录不存在时自动创建（首次使用无门槛）
+- 与 `/pace-trace timeline` 互补：timeline 追踪 CR 级决策，arch 追踪架构级决策
diff --git a/tests/conftest.py b/tests/conftest.py
index e39a7ef..46dcc04 100644
--- a/tests/conftest.py
+++ b/tests/conftest.py
@@ -12,6 +12,7 @@
# ── Skill / Schema / Template inventories ──────────────────────────────────
SKILL_NAMES = [
+ "pace-biz",
"pace-change",
"pace-dev",
"pace-feedback",
@@ -32,7 +33,7 @@
"pace-trace",
]
-SCHEMA_FILES = ["checks-format.md", "context-format.md", "cr-format.md", "insights-format.md", "integrations-format.md", "iteration-format.md", "pf-format.md", "project-format.md", "release-format.md", "risk-format.md", "state-format.md", "sync-mapping-format.md", "test-baseline-format.md", "test-strategy-format.md"]
+SCHEMA_FILES = ["accept-report-contract.md", "adr-format.md", "br-format.md", "checks-format.md", "context-format.md", "cr-format.md", "epic-format.md", "incident-format.md", "insights-format.md", "integrations-format.md", "iteration-format.md", "opportunity-format.md", "pf-format.md", "project-format.md", "release-format.md", "risk-format.md", "state-format.md", "sync-mapping-format.md", "test-baseline-format.md", "test-strategy-format.md"]
# ── Eval directories (per-Skill under tests/evaluation/) ────────────────
EVAL_DIR = DEVPACE_ROOT / "tests" / "evaluation"
diff --git a/tests/evaluation/pace-biz/evals.json b/tests/evaluation/pace-biz/evals.json
new file mode 100644
index 0000000..cc4013e
--- /dev/null
+++ b/tests/evaluation/pace-biz/evals.json
@@ -0,0 +1,197 @@
+{
+ "skill_name": "pace-biz",
+ "description": "Behavioral evaluation for /pace-biz (13 scenarios, ~80 assertions)",
+ "evals": [
+ {
+ "id": 1, "name": "opportunity-capture",
+ "prompt": "有个客户反馈说导出功能太慢，经常超时，希望能优化",
+ "expected_output": "Captures the feedback as a business opportunity. Creates OPP entry with inferred source type (customer-feedback), writes to opportunities.md, and suggests next steps (create Epic or link to existing Epic).",
+ "files": [], "env": "ENV-BIZ-A",
+ "assertions": [
+ {"text": "Creates an OPP entry with unique ID (e.g. OPP-XXX)", "type": "file_check"},
+ {"text": "Infers source type as customer-feedback based on '客户反馈' keyword", "type": "behavior_check"},
+ {"text": "Writes opportunity record to opportunities.md", "type": "file_check"},
+ {"text": "OPP entry contains description capturing the core pain point", "type": "content_check"},
+ {"text": "OPP entry contains creation date", "type": "file_check"},
+ {"text": "Suggests next step: create Epic from this opportunity or link to existing Epic", "type": "output_check"},
+ {"text": "Output uses natural language, no raw internal IDs in user-facing text", "type": "output_check"}
+ ]
+ },
+ {
+ "id": 2, "name": "epic-from-opportunity",
+ "prompt": "/pace-biz epic OPP-001",
+ "expected_output": "Reads OPP-001 details, guides user through MoS (Measures of Success) definition, creates EPIC file linked to OPP-001, updates business hierarchy tree.",
+ "files": [], "env": "ENV-BIZ-B",
+ "assertions": [
+ {"text": "Reads OPP-001 from opportunities.md to understand context", "type": "behavior_check"},
+ {"text": "Guides user to define Measures of Success (MoS) for the Epic", "type": "behavior_check"},
+ {"text": "Creates EPIC file with unique ID (e.g. EPIC-XXX)", "type": "file_check"},
+ {"text": "EPIC file contains link/reference back to OPP-001", "type": "file_check"},
+ {"text": "EPIC file contains OBJ association if applicable", "type": "file_check"},
+ {"text": "Updates business hierarchy tree with new Epic entry", "type": "file_check"},
+ {"text": "Suggests next step: decompose Epic into BRs", "type": "output_check"}
+ ]
+ },
+ {
+ "id": 3, "name": "epic-direct",
+ "prompt": "我想创建一个专题来管理用户认证和授权",
+ "expected_output": "Creates Epic directly without requiring an existing Opportunity. Associates with relevant OBJ if identifiable, creates EPIC file, updates hierarchy.",
+ "files": [], "env": "ENV-BIZ-A",
+ "assertions": [
+ {"text": "Creates EPIC file without requiring a pre-existing OPP", "type": "file_check"},
+ {"text": "Attempts to associate Epic with relevant OBJ from vision/strategy", "type": "behavior_check"},
+ {"text": "EPIC file contains description of scope (authentication and authorization)", "type": "content_check"},
+ {"text": "EPIC file contains MoS section (may prompt user to define)", "type": "file_check"},
+ {"text": "Updates business hierarchy tree with new Epic", "type": "file_check"},
+ {"text": "Suggests next step: decompose into BRs or capture related opportunities", "type": "output_check"}
+ ]
+ },
+ {
+ "id": 4, "name": "decompose-epic-to-br",
+ "prompt": "/pace-biz decompose EPIC-001",
+ "expected_output": "Reads EPIC-001 details, suggests BR decomposition plan, waits for user confirmation, creates BR entries linked to the Epic.",
+ "files": [], "env": "ENV-BIZ-C",
+ "assertions": [
+ {"text": "Reads EPIC-001 to understand scope and MoS", "type": "behavior_check"},
+ {"text": "Proposes BR decomposition plan with rationale", "type": "output_check"},
+ {"text": "Waits for user confirmation before creating BRs", "type": "behavior_check"},
+ {"text": "Creates BR entries with unique IDs linked to EPIC-001", "type": "file_check"},
+ {"text": "Each BR has clear scope description and acceptance hints", "type": "content_check"},
+ {"text": "Updates business hierarchy tree showing EPIC->BR relationships", "type": "file_check"},
+ {"text": "Suggests next step: further decompose BRs into PFs", "type": "output_check"}
+ ]
+ },
+ {
+ "id": 5, "name": "decompose-br-to-pf",
+ "prompt": "/pace-biz decompose BR-001",
+ "expected_output": "Reads BR-001 details, suggests PF (Product Feature) decomposition, waits for user confirmation, creates PF entries that bridge business and development.",
+ "files": [], "env": "ENV-BIZ-D",
+ "assertions": [
+ {"text": "Reads BR-001 to understand business requirement scope", "type": "behavior_check"},
+ {"text": "Proposes PF decomposition plan mapping business needs to product features", "type": "output_check"},
+ {"text": "Waits for user confirmation before creating PFs", "type": "behavior_check"},
+ {"text": "Creates PF entries with unique IDs linked to BR-001", "type": "file_check"},
+ {"text": "Each PF contains acceptance criteria derived from BR", "type": "content_check"},
+ {"text": "Updates hierarchy tree showing BR->PF relationships", "type": "file_check"},
+ {"text": "Suggests next step: use /pace-dev or /pace-plan for implementation planning", "type": "output_check"},
+ {"text": "PF entries are compatible with existing devpace CR workflow", "type": "behavior_check"}
+ ]
+ },
+ {
+ "id": 6, "name": "align-check",
+ "prompt": "/pace-biz align",
+ "expected_output": "Performs read-only strategic alignment analysis. Reports OBJ coverage rate, identifies orphan entities (Epics without OBJ, BRs without Epic), and highlights misalignment risks.",
+ "files": [], "env": "ENV-BIZ-B",
+ "assertions": [
+ {"text": "Performs read-only analysis without modifying any files", "type": "behavior_check"},
+ {"text": "Reports OBJ coverage rate (which OBJs have Epics/BRs mapped)", "type": "output_check"},
+ {"text": "Identifies orphan Epics not linked to any OBJ", "type": "output_check"},
+ {"text": "Identifies orphan BRs not linked to any Epic", "type": "output_check"},
+ {"text": "Reports isolated entities (OPPs not converted to Epics)", "type": "output_check"},
+ {"text": "Provides actionable recommendations for alignment gaps", "type": "output_check"},
+ {"text": "No files are created or modified during analysis", "type": "file_check"}
+ ]
+ },
+ {
+ "id": 7, "name": "view-panorama",
+ "prompt": "/pace-biz view",
+ "expected_output": "Displays read-only business panorama showing full hierarchy: OPP->EPIC->BR->PF->CR with status indicators at each level.",
+ "files": [], "env": "ENV-BIZ-B",
+ "assertions": [
+ {"text": "Displays OPP->EPIC->BR->PF->CR hierarchy in structured format", "type": "output_check"},
+ {"text": "Each entity shows current status indicator", "type": "output_check"},
+ {"text": "Hierarchy is visually clear with indentation or tree structure", "type": "output_check"},
+ {"text": "Includes summary statistics (total counts per entity type)", "type": "output_check"},
+ {"text": "Read-only operation, no files modified", "type": "behavior_check"},
+ {"text": "Output uses natural language descriptions alongside entity IDs", "type": "output_check"}
+ ]
+ },
+ {
+ "id": 8, "name": "backward-compat",
+ "prompt": "/pace-biz view",
+ "expected_output": "When no Epic/Opportunity layer exists, gracefully falls back to showing existing PF->CR hierarchy. Does not error or require Epic/OPP setup.",
+ "files": [], "env": "ENV-BIZ-LEGACY",
+ "assertions": [
+ {"text": "Detects absence of Epic/Opportunity layer without error", "type": "behavior_check"},
+ {"text": "Falls back to displaying existing PF->CR hierarchy", "type": "output_check"},
+ {"text": "Does not require or force Epic/OPP creation", "type": "behavior_check"},
+ {"text": "Suggests /pace-biz opportunity or /pace-biz epic to enrich business context", "type": "output_check"},
+ {"text": "Existing devpace workflow remains fully functional", "type": "behavior_check"},
+ {"text": "No files are created or modified", "type": "file_check"}
+ ]
+ },
+ {
+ "id": 9, "name": "discover-interactive",
+ "prompt": "/pace-biz discover 我想做一个任务管理工具",
+ "expected_output": "Launches multi-turn interactive discovery. Asks goal framing questions, then brainstorms features, defines boundaries, and presents structured candidate tree for confirmation.",
+ "files": [], "env": "ENV-BIZ-A",
+ "assertions": [
+ {"text": "Asks goal-framing questions (problem, target users) in first round", "type": "behavior_check"},
+ {"text": "Progressively deepens with feature brainstorming questions", "type": "behavior_check"},
+ {"text": "Asks boundary definition questions (what is out of scope)", "type": "behavior_check"},
+ {"text": "Presents structured candidate tree (OPP->Epic->BR->PF) for confirmation", "type": "output_check"},
+ {"text": "Persists session state to scope-discovery.md during multi-turn conversation", "type": "file_check"},
+ {"text": "After confirmation, writes OPP/Epic/BR/PF to .devpace/ files", "type": "file_check"},
+ {"text": "Cleans up scope-discovery.md after successful completion", "type": "file_check"},
+ {"text": "Suggests next steps: decompose or /pace-plan next", "type": "output_check"}
+ ]
+ },
+ {
+ "id": 10, "name": "discover-degraded",
+ "prompt": "/pace-biz discover 做一个聊天机器人",
+ "expected_output": "Without .devpace/, runs discovery conversation normally but outputs to console instead of writing files. Guides user to /pace-init.",
+ "files": [], "env": "ENV-NO-DEVPACE",
+ "assertions": [
+ {"text": "Runs discovery conversation normally without .devpace/", "type": "behavior_check"},
+ {"text": "Outputs candidate tree to console, does not write files", "type": "behavior_check"},
+ {"text": "Guides user to run /pace-init first", "type": "output_check"},
+ {"text": "No files are created or modified", "type": "file_check"}
+ ]
+ },
+ {
+ "id": 11, "name": "import-documents",
+ "prompt": "/pace-biz import meeting-notes.md",
+ "expected_output": "Reads the document, auto-detects source type, extracts requirement entities, performs merge analysis against existing feature tree, and presents diff-style plan for confirmation.",
+ "files": [], "env": "ENV-BIZ-B",
+ "assertions": [
+ {"text": "Reads the specified file and detects source type", "type": "behavior_check"},
+ {"text": "Extracts requirement entities (BR/PF candidates) from document", "type": "behavior_check"},
+ {"text": "Performs merge analysis: classifies as NEW/DUPLICATE/ENRICHMENT/CONFLICT", "type": "output_check"},
+ {"text": "Presents diff-style merge plan for user confirmation", "type": "output_check"},
+ {"text": "After confirmation, writes new entities to project.md feature tree", "type": "file_check"},
+ {"text": "Marks imported content with source attribution comment", "type": "file_check"},
+ {"text": "Does not create CRs (import operates at BR/PF level only)", "type": "behavior_check"},
+ {"text": "Suggests /pace-biz align after import", "type": "output_check"}
+ ]
+ },
+ {
+ "id": 12, "name": "infer-codebase",
+ "prompt": "/pace-biz infer",
+ "expected_output": "Scans codebase structure, mines signals (TODO/FIXME, routes, models), compares against feature tree, and presents three-part gap report.",
+ "files": [], "env": "ENV-BIZ-CODE",
+ "assertions": [
+ {"text": "Scans source code directories for modules, routes, models, components", "type": "behavior_check"},
+ {"text": "Mines TODO/FIXME/HACK comments as technical debt signals", "type": "behavior_check"},
+ {"text": "Compares inferred features against existing feature tree", "type": "behavior_check"},
+ {"text": "Presents three-part report: untracked, unimplemented, technical debt", "type": "output_check"},
+ {"text": "Allows user to select which items to add to feature tree", "type": "behavior_check"},
+ {"text": "Technical debt PFs are suffixed with '(technical debt)' marker", "type": "content_check"},
+ {"text": "Marks inferred content with source attribution comment", "type": "file_check"},
+ {"text": "Suggests /pace-biz align after inference", "type": "output_check"}
+ ]
+ },
+ {
+ "id": 13, "name": "infer-no-git",
+ "prompt": "/pace-biz infer",
+ "expected_output": "Without git, degrades gracefully: skips blame/hotspot analysis, still performs directory structure and comment scanning.",
+ "files": [], "env": "ENV-BIZ-NOGIT",
+ "assertions": [
+ {"text": "Detects git is unavailable and degrades gracefully", "type": "behavior_check"},
+ {"text": "Skips git-enhanced analysis (hotspot, co-change, contributor)", "type": "behavior_check"},
+ {"text": "Still performs directory structure analysis and comment scanning", "type": "behavior_check"},
+ {"text": "Produces gap report without git-specific sections", "type": "output_check"},
+ {"text": "Does not error or abort due to missing git", "type": "behavior_check"}
+ ]
+ }
+ ]
+}
diff --git a/tests/evaluation/pace-biz/trigger-evals.json b/tests/evaluation/pace-biz/trigger-evals.json
new file mode 100644
index 0000000..8a196b7
--- /dev/null
+++ b/tests/evaluation/pace-biz/trigger-evals.json
@@ -0,0 +1,242 @@
+[
+ {
+ "id": 1,
+ "query": "有个客户反馈说导出功能太慢",
+ "should_trigger": true,
+ "rationale": "Customer feedback implies a business opportunity; 'opportunity' semantics match trigger keywords"
+ },
+ {
+ "id": 2,
+ "query": "我想创建一个专题来管理用户认证",
+ "should_trigger": true,
+ "rationale": "'创建专题' maps to Epic creation, a core pace-biz capability"
+ },
+ {
+ "id": 3,
+ "query": "把这个 Epic 分解成具体需求",
+ "should_trigger": true,
+ "rationale": "'Epic' and '分解' are explicit trigger keywords for decompose subcommand"
+ },
+ {
+ "id": 4,
+ "query": "检查一下战略对齐",
+ "should_trigger": true,
+ "rationale": "'战略对齐' directly maps to align subcommand trigger keywords"
+ },
+ {
+ "id": 5,
+ "query": "看看业务全景",
+ "should_trigger": true,
+ "rationale": "'业务全景' directly maps to view subcommand trigger keywords"
+ },
+ {
+ "id": 6,
+ "query": "/pace-biz opportunity 竞品上线新功能",
+ "should_trigger": true,
+ "rationale": "Direct slash command invocation with opportunity subcommand"
+ },
+ {
+ "id": 7,
+ "query": "/pace-biz epic OPP-001",
+ "should_trigger": true,
+ "rationale": "Direct slash command invocation with epic subcommand"
+ },
+ {
+ "id": 8,
+ "query": "/pace-biz decompose EPIC-001",
+ "should_trigger": true,
+ "rationale": "Direct slash command invocation with decompose subcommand"
+ },
+ {
+ "id": 9,
+ "query": "/pace-biz align",
+ "should_trigger": true,
+ "rationale": "Direct slash command invocation with align subcommand"
+ },
+ {
+ "id": 10,
+ "query": "/pace-biz view",
+ "should_trigger": true,
+ "rationale": "Direct slash command invocation with view subcommand"
+ },
+ {
+ "id": 11,
+ "query": "业务机会",
+ "should_trigger": true,
+ "rationale": "'业务机会' is a key trigger phrase for opportunity capture"
+ },
+ {
+ "id": 12,
+ "query": "业务规划",
+ "should_trigger": true,
+ "rationale": "'业务规划' is a key trigger phrase for business planning capabilities"
+ },
+ {
+ "id": 13,
+ "query": "pace-biz",
+ "should_trigger": true,
+ "rationale": "Direct skill name reference triggers the skill"
+ },
+ {
+ "id": 14,
+ "query": "帮我实现登录功能",
+ "should_trigger": false,
+ "rationale": "'实现' is a development keyword -> /pace-dev, not business planning"
+ },
+ {
+ "id": 15,
+ "query": "不做这个需求了",
+ "should_trigger": false,
+ "rationale": "'不做了' is a change management keyword -> /pace-change, not business planning"
+ },
+ {
+ "id": 16,
+ "query": "规划下一个迭代",
+ "should_trigger": false,
+ "rationale": "Iteration planning -> /pace-plan, not business-level planning"
+ },
+ {
+ "id": 17,
+ "query": "项目状态怎样",
+ "should_trigger": false,
+ "rationale": "Project status overview -> /pace-status, not business planning"
+ },
+ {
+ "id": 18,
+ "query": "回顾一下这个迭代",
+ "should_trigger": false,
+ "rationale": "Iteration retrospective -> /pace-retro, not business planning"
+ },
+ {
+ "id": 19,
+ "query": "开始做 CR-001",
+ "should_trigger": false,
+ "rationale": "'开始做' + CR reference -> /pace-dev, not business planning"
+ },
+ {
+ "id": 20,
+ "query": "初始化项目",
+ "should_trigger": false,
+ "rationale": "Project initialization -> /pace-init, not business planning"
+ },
+ {
+ "id": 21,
+ "query": "我想做一个智能客服系统",
+ "should_trigger": true,
+ "rationale": "'我想做一个...' is a vague idea that maps to discover subcommand for interactive requirements discovery"
+ },
+ {
+ "id": 22,
+ "query": "头脑风暴一下需求",
+ "should_trigger": true,
+ "rationale": "'头脑风暴' is a key trigger for discover subcommand"
+ },
+ {
+ "id": 23,
+ "query": "/pace-biz discover 任务管理工具",
+ "should_trigger": true,
+ "rationale": "Direct slash command invocation with discover subcommand"
+ },
+ {
+ "id": 24,
+ "query": "把会议纪要里的需求导入进来",
+ "should_trigger": true,
+ "rationale": "'导入需求' + '会议纪要' maps to import subcommand"
+ },
+ {
+ "id": 25,
+ "query": "/pace-biz import requirements.md",
+ "should_trigger": true,
+ "rationale": "Direct slash command invocation with import subcommand"
+ },
+ {
+ "id": 26,
+ "query": "从文档导入需求",
+ "should_trigger": true,
+ "rationale": "'从文档导入' is a key trigger for import subcommand"
+ },
+ {
+ "id": 27,
+ "query": "看看代码里有什么功能没追踪的",
+ "should_trigger": true,
+ "rationale": "'代码' + '功能' + '没追踪' maps to infer subcommand for codebase feature inference"
+ },
+ {
+ "id": 28,
+ "query": "/pace-biz infer",
+ "should_trigger": true,
+ "rationale": "Direct slash command invocation with infer subcommand"
+ },
+ {
+ "id": 29,
+ "query": "技术债务盘点",
+ "should_trigger": true,
+ "rationale": "'技术债务盘点' is a key trigger for infer subcommand"
+ },
+ {
+ "id": 30,
+ "query": "brainstorm 一下这个项目需要什么功能",
+ "should_trigger": true,
+ "rationale": "'brainstorm' is a key trigger for discover subcommand"
+ },
+ {
+ "id": 31,
+ "query": "需求发现",
+ "should_trigger": true,
+ "rationale": "'需求发现' is a key trigger phrase for discover subcommand"
+ },
+ {
+ "id": 32,
+ "query": "代码分析需求",
+ "should_trigger": true,
+ "rationale": "'代码分析需求' is a key trigger phrase for infer subcommand"
+ },
+ {
+ "id": 33,
+ "query": "初始化项目并建立完整功能树",
+ "should_trigger": false,
+ "rationale": "Full project initialization with feature tree -> /pace-init full, not pace-biz discover"
+ },
+ {
+ "id": 34,
+ "query": "加一个新功能到当前迭代",
+ "should_trigger": false,
+ "rationale": "Adding a feature to current iteration -> /pace-change add, not pace-biz opportunity"
+ },
+ {
+ "id": 35,
+ "query": "重新规划下个迭代的范围",
+ "should_trigger": false,
+ "rationale": "Iteration scope replanning -> /pace-plan adjust, not pace-biz"
+ },
+ {
+ "id": 36,
+ "query": "帮我看看项目进展",
+ "should_trigger": false,
+ "rationale": "Project progress overview -> /pace-status, not pace-biz view"
+ },
+ {
+ "id": 37,
+ "query": "分析这个 CR 的风险",
+ "should_trigger": false,
+ "rationale": "CR risk analysis -> /pace-guard scan, not pace-biz"
+ },
+ {
+ "id": 38,
+ "query": "回顾这个迭代的度量",
+ "should_trigger": false,
+ "rationale": "Iteration metrics review -> /pace-retro, not pace-biz"
+ },
+ {
+ "id": 39,
+ "query": "方法论是什么",
+ "should_trigger": false,
+ "rationale": "Methodology questions -> /pace-theory, not pace-biz"
+ },
+ {
+ "id": 40,
+ "query": "把这个 Epic 开始做",
+ "should_trigger": false,
+ "rationale": "'开始做' implies implementation -> /pace-dev, not pace-biz (planning != implementing)"
+ }
+]
diff --git a/tests/hooks/test_pace_dev_scope_check.mjs b/tests/hooks/test_pace_dev_scope_check.mjs
new file mode 100644
index 0000000..3ca40a4
--- /dev/null
+++ b/tests/hooks/test_pace_dev_scope_check.mjs
@@ -0,0 +1,359 @@
+/**
+ * Integration tests for hooks/pace-dev-scope-check.mjs
+ * Tests the hook by spawning it as a subprocess with simulated stdin JSON.
+ * Run: node --test tests/hooks/test_pace_dev_scope_check.mjs
+ */
+import { describe, it, beforeEach, afterEach } from 'node:test';
+import assert from 'node:assert/strict';
+import { spawn } from 'node:child_process';
+import { writeFileSync, mkdirSync, rmSync, existsSync } from 'node:fs';
+import { join } from 'node:path';
+import { tmpdir } from 'node:os';
+import { fileURLToPath } from 'node:url';
+import { dirname } from 'node:path';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+const HOOK_SCRIPT = join(__dirname, '..', '..', 'hooks', 'pace-dev-scope-check.mjs');
+
+// ── Test helpers ────────────────────────────────────────────────────
+
+function createTmpProject() {
+ const dir = join(tmpdir(), `devpace-scope-test-${Date.now()}-${Math.random().toString(36).slice(2)}`);
+ mkdirSync(join(dir, '.devpace', 'backlog'), { recursive: true });
+ return dir;
+}
+
+function cleanupDir(dir) {
+ if (existsSync(dir)) {
+ rmSync(dir, { recursive: true, force: true });
+ }
+}
+
+function runHook(stdinJson, projectDir) {
+ return new Promise((resolve) => {
+ const child = spawn('node', [HOOK_SCRIPT], {
+ env: { ...process.env, CLAUDE_PROJECT_DIR: projectDir },
+ stdio: ['pipe', 'pipe', 'pipe'],
+ });
+
+ let stdout = '';
+ let stderr = '';
+
+ child.stdout.on('data', (data) => { stdout += data.toString(); });
+ child.stderr.on('data', (data) => { stderr += data.toString(); });
+
+ child.on('close', (code) => {
+ resolve({ exitCode: code, stdout: stdout.trim(), stderr: stderr.trim() });
+ });
+
+ child.stdin.write(JSON.stringify(stdinJson));
+ child.stdin.end();
+ });
+}
+
+/**
+ * Create a CR file with scope-relevant content.
+ */
+function writeCr(projectDir, crId, content) {
+ const crPath = join(projectDir, '.devpace', 'backlog', `CR-${crId}.md`);
+ writeFileSync(crPath, content);
+ return crPath;
+}
+
+/**
+ * Write state.md with an active CR reference.
+ */
+function writeState(projectDir, crId) {
+ writeFileSync(
+ join(projectDir, '.devpace', 'state.md'),
+ `> 目标：测试项目\n\n- **进行中**：实现功能 → CR-${crId}\n\n下一步：继续\n`
+ );
+}
+
+// ── Tests: No .devpace → exit 0 ────────────────────────────────────
+
+describe('pace-dev-scope-check: no .devpace', () => {
+ it('exits 0 when .devpace/backlog does not exist', async () => {
+ const dir = join(tmpdir(), `no-devpace-scope-${Date.now()}`);
+ mkdirSync(dir, { recursive: true });
+ const result = await runHook({ tool_input: { file_path: '/foo.md' } }, dir);
+ assert.equal(result.exitCode, 0);
+ cleanupDir(dir);
+ });
+});
+
+// ── Tests: No file_path → exit 0 ───────────────────────────────────
+
+describe('pace-dev-scope-check: no file_path', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('exits 0 when tool input has no file_path', async () => {
+ const result = await runHook({ tool_input: {} }, projectDir);
+ assert.equal(result.exitCode, 0);
+ });
+
+ it('exits 0 for empty input', async () => {
+ const result = await runHook({}, projectDir);
+ assert.equal(result.exitCode, 0);
+ });
+});
+
+// ── Tests: Gate 3 — block automated approved state change ──────────
+
+describe('pace-dev-scope-check: Gate 3 enforcement', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('blocks state change to approved on CR file (exit 2)', async () => {
+ const crPath = writeCr(projectDir, '001', '# CR-001\n\n- **状态**：in_review\n');
+ const input = {
+ tool_input: {
+ file_path: crPath,
+ content: '# CR-001\n\n- **状态**：approved\n'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 2, `Expected exit 2 (Gate 3 block) but got ${result.exitCode}`);
+ assert.ok(result.stderr.includes('Gate 3'), 'Should mention Gate 3');
+ });
+
+ it('blocks Edit with new_string changing to approved (exit 2)', async () => {
+ const crPath = writeCr(projectDir, '002', '# CR-002\n\n- **状态**：in_review\n');
+ const input = {
+ tool_input: {
+ file_path: crPath,
+ old_string: '- **状态**：in_review',
+ new_string: '- **状态**：approved'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 2);
+ });
+
+ it('allows non-approved state change on CR file (exit 0)', async () => {
+ const crPath = writeCr(projectDir, '003', '# CR-003\n\n- **状态**：developing\n');
+ const input = {
+ tool_input: {
+ file_path: crPath,
+ content: '# CR-003\n\n- **状态**：verifying\n'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ });
+
+ it('allows content additions to CR without state change', async () => {
+ const crPath = writeCr(projectDir, '004', '# CR-004\n\n- **状态**：developing\n');
+ const input = {
+ tool_input: {
+ file_path: crPath,
+ content: '# CR-004\n\n- **状态**：developing\n\n## Notes\nAdded notes.\n'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ });
+});
+
+// ── Tests: .devpace/ management files → fast-path exit 0 ───────────
+
+describe('pace-dev-scope-check: .devpace fast-path', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('allows write to .devpace/state.md', async () => {
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, '.devpace', 'state.md'),
+ content: '> updated'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ });
+
+ it('allows write to .devpace/project.md', async () => {
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, '.devpace', 'project.md'),
+ content: '# Project'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ });
+});
+
+// ── Tests: No active CR → allow with info ──────────────────────────
+
+describe('pace-dev-scope-check: no active CR', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('allows file write when no state.md exists', async () => {
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'src', 'main.js'),
+ content: 'console.log("hi")'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(result.stdout.includes('scope-info'), 'Should output scope-info message');
+ });
+
+ it('allows file write when state.md has no active CR', async () => {
+ writeFileSync(
+ join(projectDir, '.devpace', 'state.md'),
+ '> 目标：测试\n\n- 当前工作：（无）\n'
+ );
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'src', 'main.js'),
+ content: 'console.log("hi")'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ });
+});
+
+// ── Tests: Scope validation with active CR ─────────────────────────
+
+describe('pace-dev-scope-check: scope validation', () => {
+ let projectDir;
+
+ beforeEach(() => {
+ projectDir = createTmpProject();
+ writeState(projectDir, '010');
+ });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('allows in-scope file (execution plan path match)', async () => {
+ writeCr(projectDir, '010',
+ '# CR-010\n\n- **状态**：developing\n\n## 执行计划\n\n**src/auth/login.js**：实现登录逻辑\n'
+ );
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'src', 'auth', 'login.js'),
+ content: 'module.exports = {}'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(!result.stdout.includes('scope-drift'), 'Should NOT warn about scope drift');
+ });
+
+ it('allows in-scope file (scope section path match)', async () => {
+ writeCr(projectDir, '010',
+ '# CR-010\n\n- **状态**：developing\n- **范围**：`hooks/` 目录下的所有文件\n\n## 执行计划\n'
+ );
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'hooks', 'some-hook.mjs'),
+ content: 'export default {}'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(!result.stdout.includes('scope-drift'), 'Should NOT warn about scope drift');
+ });
+
+ it('warns (advisory, exit 0) for out-of-scope file', async () => {
+ writeCr(projectDir, '010',
+ '# CR-010\n\n- **状态**：developing\n\n## 执行计划\n\n**src/auth/login.js**：实现登录逻辑\n'
+ );
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'docs', 'README.md'),
+ content: '# Docs'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0, 'Scope drift is advisory, should not block');
+ assert.ok(result.stdout.includes('scope-drift'), 'Should warn about scope drift');
+ });
+
+ it('allows all files when CR has no scope patterns yet', async () => {
+ writeCr(projectDir, '010',
+ '# CR-010\n\n- **状态**：developing\n\n## 意图\n\n概述：初步探索\n'
+ );
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'anywhere', 'file.txt'),
+ content: 'content'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(!result.stdout.includes('scope-drift'), 'No scope patterns → no drift warning');
+ });
+
+ it('warns for different file in same directory (startsWith needs prefix match)', async () => {
+ // matchesScope's same-directory check uses startsWith, which requires
+ // the target path to begin with the pattern's directory prefix.
+ // With absolute tmp paths vs relative patterns, this won't match.
+ writeCr(projectDir, '010',
+ '# CR-010\n\n- **状态**：developing\n\n## 执行计划\n\n**src/auth/login.js**：实现登录逻辑\n'
+ );
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'src', 'auth', 'register.js'),
+ content: 'module.exports = {}'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0, 'Should not block, only advisory');
+ assert.ok(result.stdout.includes('scope-drift'), 'Different file triggers scope-drift advisory');
+ });
+
+ it('allows file matching via includes (substring in path)', async () => {
+ writeCr(projectDir, '010',
+ '# CR-010\n\n- **状态**：developing\n\n## 执行计划\n\n**src/auth/**：认证模块目录\n'
+ );
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'src', 'auth', 'register.js'),
+ content: 'module.exports = {}'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(!result.stdout.includes('scope-drift'), 'Directory pattern should match via includes');
+ });
+});
+
+// ── Tests: Degraded state → allow ──────────────────────────────────
+
+describe('pace-dev-scope-check: degradation', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('allows when state.md references non-existent CR', async () => {
+ writeFileSync(
+ join(projectDir, '.devpace', 'state.md'),
+ '> 目标：测试\n\n- **进行中**：实现功能 → CR-999\n'
+ );
+ // CR-999.md does not exist
+ const input = {
+ tool_input: {
+ file_path: join(projectDir, 'src', 'main.js'),
+ content: 'code'
+ }
+ };
+ const result = await runHook(input, projectDir);
+ assert.equal(result.exitCode, 0);
+ });
+});
diff --git a/tests/hooks/test_post_tool_failure.mjs b/tests/hooks/test_post_tool_failure.mjs
new file mode 100644
index 0000000..2d48437
--- /dev/null
+++ b/tests/hooks/test_post_tool_failure.mjs
@@ -0,0 +1,161 @@
+/**
+ * Integration tests for hooks/post-tool-failure.mjs
+ * Tests the PostToolUseFailure hook by spawning it as a subprocess.
+ * Run: node --test tests/hooks/test_post_tool_failure.mjs
+ */
+import { describe, it, beforeEach, afterEach } from 'node:test';
+import assert from 'node:assert/strict';
+import { spawn } from 'node:child_process';
+import { writeFileSync, mkdirSync, rmSync, existsSync } from 'node:fs';
+import { join } from 'node:path';
+import { tmpdir } from 'node:os';
+import { fileURLToPath } from 'node:url';
+import { dirname } from 'node:path';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+const HOOK_SCRIPT = join(__dirname, '..', '..', 'hooks', 'post-tool-failure.mjs');
+
+// ── Test helpers ────────────────────────────────────────────────────
+
+function createTmpProject(advanceMode) {
+ const dir = join(tmpdir(), `devpace-failure-test-${Date.now()}-${Math.random().toString(36).slice(2)}`);
+ mkdirSync(join(dir, '.devpace', 'backlog'), { recursive: true });
+ if (advanceMode) {
+ writeFileSync(
+ join(dir, '.devpace', 'state.md'),
+ '> 目标：测试\n\n- **进行中**：开发中 → CR-001\n\n下一步：继续\n'
+ );
+ }
+ return dir;
+}
+
+function cleanupDir(dir) {
+ if (existsSync(dir)) {
+ rmSync(dir, { recursive: true, force: true });
+ }
+}
+
+function runHook(stdinJson, projectDir) {
+ return new Promise((resolve) => {
+ const child = spawn('node', [HOOK_SCRIPT], {
+ env: { ...process.env, CLAUDE_PROJECT_DIR: projectDir },
+ stdio: ['pipe', 'pipe', 'pipe'],
+ });
+
+ let stdout = '';
+ let stderr = '';
+
+ child.stdout.on('data', (data) => { stdout += data.toString(); });
+ child.stderr.on('data', (data) => { stderr += data.toString(); });
+
+ child.on('close', (code) => {
+ resolve({ exitCode: code, stdout: stdout.trim(), stderr: stderr.trim() });
+ });
+
+ child.stdin.write(JSON.stringify(stdinJson));
+ child.stdin.end();
+ });
+}
+
+// ── Tests: No .devpace → silent exit ───────────────────────────────
+
+describe('post-tool-failure: no .devpace', () => {
+ it('exits 0 silently when .devpace/backlog does not exist', async () => {
+ const dir = join(tmpdir(), `no-devpace-failure-${Date.now()}`);
+ mkdirSync(dir, { recursive: true });
+ const result = await runHook({ tool_input: { file_path: '/foo.md' } }, dir);
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ cleanupDir(dir);
+ });
+});
+
+// ── Tests: Not in advance mode → silent exit ───────────────────────
+
+describe('post-tool-failure: explore mode (not advance)', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(false); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('exits 0 silently when not in advance mode', async () => {
+ const crPath = join(projectDir, '.devpace', 'backlog', 'CR-001.md');
+ writeFileSync(crPath, '# CR-001\n\n- **状态**：developing\n');
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ });
+
+ it('exits 0 silently when state.md does not exist', async () => {
+ rmSync(join(projectDir, '.devpace', 'state.md'), { force: true });
+ const result = await runHook(
+ { tool_input: { file_path: join(projectDir, '.devpace', 'backlog', 'CR-001.md') } },
+ projectDir
+ );
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ });
+});
+
+// ── Tests: Advance mode + CR file failure → consistency advice ─────
+
+describe('post-tool-failure: advance mode + CR file', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(true); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('outputs consistency advice for CR file write failure', async () => {
+ const crPath = join(projectDir, '.devpace', 'backlog', 'CR-001.md');
+ writeFileSync(crPath, '# CR-001\n\n- **状态**：developing\n');
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(result.stdout.includes('tool-failure'), 'Should include tool-failure prefix');
+ assert.ok(result.stdout.includes('CR'), 'Should mention CR');
+ assert.ok(result.stdout.includes('consistency'), 'Should mention consistency check');
+ });
+});
+
+// ── Tests: Advance mode + .devpace/ file failure → state check ─────
+
+describe('post-tool-failure: advance mode + .devpace file', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(true); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('outputs state check advice for .devpace/ file failure', async () => {
+ const result = await runHook(
+ { tool_input: { file_path: join(projectDir, '.devpace', 'state.md') } },
+ projectDir
+ );
+ assert.equal(result.exitCode, 0);
+ assert.ok(result.stdout.includes('tool-failure'), 'Should include tool-failure prefix');
+ assert.ok(result.stdout.includes('state.md'), 'Should mention state.md');
+ });
+});
+
+// ── Tests: Advance mode + other file failure → silent ──────────────
+
+describe('post-tool-failure: advance mode + non-devpace file', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(true); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('exits 0 silently for non-.devpace file failure', async () => {
+ const result = await runHook(
+ { tool_input: { file_path: join(projectDir, 'src', 'main.js') } },
+ projectDir
+ );
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ });
+
+ it('exits 0 silently when file_path is empty', async () => {
+ const result = await runHook({ tool_input: {} }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ });
+});
diff --git a/tests/hooks/test_sync_push.mjs b/tests/hooks/test_sync_push.mjs
new file mode 100644
index 0000000..557419d
--- /dev/null
+++ b/tests/hooks/test_sync_push.mjs
@@ -0,0 +1,256 @@
+/**
+ * Integration tests for hooks/sync-push.mjs
+ * Tests the PostToolUse hook by spawning it as a subprocess with simulated stdin JSON.
+ * Run: node --test tests/hooks/test_sync_push.mjs
+ */
+import { describe, it, beforeEach, afterEach } from 'node:test';
+import assert from 'node:assert/strict';
+import { spawn } from 'node:child_process';
+import { writeFileSync, mkdirSync, rmSync, existsSync } from 'node:fs';
+import { join } from 'node:path';
+import { tmpdir } from 'node:os';
+import { fileURLToPath } from 'node:url';
+import { dirname } from 'node:path';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+const HOOK_SCRIPT = join(__dirname, '..', '..', 'hooks', 'sync-push.mjs');
+
+// ── Test helpers ────────────────────────────────────────────────────
+
+function createTmpProject() {
+ const dir = join(tmpdir(), `devpace-sync-test-${Date.now()}-${Math.random().toString(36).slice(2)}`);
+ mkdirSync(join(dir, '.devpace', 'backlog'), { recursive: true });
+ mkdirSync(join(dir, '.devpace', 'integrations'), { recursive: true });
+ return dir;
+}
+
+function cleanupDir(dir) {
+ if (existsSync(dir)) {
+ rmSync(dir, { recursive: true, force: true });
+ }
+}
+
+function runHook(stdinJson, projectDir) {
+ return new Promise((resolve) => {
+ const child = spawn('node', [HOOK_SCRIPT], {
+ env: { ...process.env, CLAUDE_PROJECT_DIR: projectDir },
+ stdio: ['pipe', 'pipe', 'pipe'],
+ });
+
+ let stdout = '';
+ let stderr = '';
+
+ child.stdout.on('data', (data) => { stdout += data.toString(); });
+ child.stderr.on('data', (data) => { stderr += data.toString(); });
+
+ child.on('close', (code) => {
+ resolve({ exitCode: code, stdout: stdout.trim(), stderr: stderr.trim() });
+ });
+
+ child.stdin.write(JSON.stringify(stdinJson));
+ child.stdin.end();
+ });
+}
+
+function writeCr(projectDir, crId, content) {
+ const crPath = join(projectDir, '.devpace', 'backlog', `CR-${crId}.md`);
+ writeFileSync(crPath, content);
+ return crPath;
+}
+
+function writeSyncMapping(projectDir, content) {
+ writeFileSync(
+ join(projectDir, '.devpace', 'integrations', 'sync-mapping.md'),
+ content || '# Sync Mapping\n\n| CR | External |\n|----|---------|\n| CR-001 | #123 |\n'
+ );
+}
+
+function writeSyncCache(projectDir, entries) {
+ mkdirSync(join(projectDir, '.devpace'), { recursive: true });
+ const lines = Object.entries(entries).map(([k, v]) => `${k}=${v}`).join('\n');
+ writeFileSync(join(projectDir, '.devpace', '.sync-state-cache'), lines + '\n');
+}
+
+// ── Tests: No .devpace → silent exit ───────────────────────────────
+
+describe('sync-push: no .devpace', () => {
+ it('exits 0 silently when .devpace/backlog does not exist', async () => {
+ const dir = join(tmpdir(), `no-devpace-sync-${Date.now()}`);
+ mkdirSync(dir, { recursive: true });
+ const result = await runHook({ tool_input: { file_path: '/foo.md' } }, dir);
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ cleanupDir(dir);
+ });
+});
+
+// ── Tests: Non-CR file → silent exit ───────────────────────────────
+
+describe('sync-push: non-CR file', () => {
+ let projectDir;
+
+ beforeEach(() => { projectDir = createTmpProject(); });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('exits 0 silently for non-CR file path', async () => {
+ const result = await runHook(
+ { tool_input: { file_path: join(projectDir, 'src', 'main.js') } },
+ projectDir
+ );
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ });
+
+ it('exits 0 silently for .devpace/state.md', async () => {
+ const result = await runHook(
+ { tool_input: { file_path: join(projectDir, '.devpace', 'state.md') } },
+ projectDir
+ );
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ });
+});
+
+// ── Tests: No sync-mapping → silent exit ───────────────────────────
+
+describe('sync-push: no sync-mapping', () => {
+ let projectDir;
+
+ beforeEach(() => {
+ projectDir = createTmpProject();
+ // Remove default integrations dir to simulate no sync-mapping
+ rmSync(join(projectDir, '.devpace', 'integrations'), { recursive: true, force: true });
+ });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('exits 0 silently when sync-mapping.md does not exist', async () => {
+ const crPath = writeCr(projectDir, '001', '# CR-001\n\n- **状态**：developing\n');
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ });
+});
+
+// ── Tests: Cache hit (state unchanged) → silent exit ───────────────
+
+describe('sync-push: cache hit (state unchanged)', () => {
+ let projectDir;
+
+ beforeEach(() => {
+ projectDir = createTmpProject();
+ writeSyncMapping(projectDir);
+ });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('exits 0 silently when CR state matches cached state', async () => {
+ const crPath = writeCr(projectDir, '001',
+ '# CR-001\n\n- **状态**：developing\n- **外部关联**：[Issue #123](https://example.com/123)\n'
+ );
+ writeSyncCache(projectDir, { 'CR-001': 'developing' });
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '', 'Should be silent when state unchanged');
+ });
+});
+
+// ── Tests: State transition to merged + external link → directive ──
+
+describe('sync-push: merged transition with external link', () => {
+ let projectDir;
+
+ beforeEach(() => {
+ projectDir = createTmpProject();
+ writeSyncMapping(projectDir);
+ });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('outputs directive message for merged state with external link', async () => {
+ const crPath = writeCr(projectDir, '001',
+ '# CR-001\n\n- **状态**：merged\n- **外部关联**：[Issue #123](https://github.com/org/repo/issues/123)\n'
+ );
+ writeSyncCache(projectDir, { 'CR-001': 'in_review' });
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(result.stdout.includes('sync-push'), 'Should include sync-push prefix');
+ assert.ok(result.stdout.includes('merged'), 'Should mention merged state');
+ assert.ok(result.stdout.includes('Issue #123'), 'Should include external link text');
+ assert.ok(result.stdout.includes('Auto-execute'), 'Should use directive language for merged');
+ });
+
+ it('outputs directive for new CR (no cached state) transitioning to merged', async () => {
+ const crPath = writeCr(projectDir, '002',
+ '# CR-002\n\n- **状态**：merged\n- **外部关联**：[Task ABC](https://linear.app/task/ABC)\n'
+ );
+ // No cache entry for CR-002
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(result.stdout.includes('sync-push'));
+ assert.ok(result.stdout.includes('merged'));
+ });
+});
+
+// ── Tests: Other state change + external link → advisory ───────────
+
+describe('sync-push: other state transitions with external link', () => {
+ let projectDir;
+
+ beforeEach(() => {
+ projectDir = createTmpProject();
+ writeSyncMapping(projectDir);
+ });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('outputs advisory for developing→verifying transition', async () => {
+ const crPath = writeCr(projectDir, '001',
+ '# CR-001\n\n- **状态**：verifying\n- **外部关联**：[Issue #1](https://example.com/1)\n'
+ );
+ writeSyncCache(projectDir, { 'CR-001': 'developing' });
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.ok(result.stdout.includes('sync-push'), 'Should include sync-push prefix');
+ assert.ok(result.stdout.includes('verifying'), 'Should mention new state');
+ assert.ok(result.stdout.includes('Consider'), 'Should use advisory language');
+ });
+});
+
+// ── Tests: No external link → silent exit ──────────────────────────
+
+describe('sync-push: no external link', () => {
+ let projectDir;
+
+ beforeEach(() => {
+ projectDir = createTmpProject();
+ writeSyncMapping(projectDir);
+ });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('exits 0 silently for state change without external link', async () => {
+ const crPath = writeCr(projectDir, '001',
+ '# CR-001\n\n- **状态**：merged\n'
+ );
+ writeSyncCache(projectDir, { 'CR-001': 'in_review' });
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '', 'Should be silent without external link');
+ });
+});
+
+// ── Tests: CR with no state field → silent exit ────────────────────
+
+describe('sync-push: no state field in CR', () => {
+ let projectDir;
+
+ beforeEach(() => {
+ projectDir = createTmpProject();
+ writeSyncMapping(projectDir);
+ });
+ afterEach(() => { cleanupDir(projectDir); });
+
+ it('exits 0 silently when CR has no state field', async () => {
+ const crPath = writeCr(projectDir, '001', '# CR-001\n\nNo state field here.\n');
+ const result = await runHook({ tool_input: { file_path: crPath } }, projectDir);
+ assert.equal(result.exitCode, 0);
+ assert.equal(result.stdout, '');
+ });
+});
diff --git a/tests/hooks/test_utils.mjs b/tests/hooks/test_utils.mjs
index 03308d8..8b0fb8e 100644
--- a/tests/hooks/test_utils.mjs
+++ b/tests/hooks/test_utils.mjs
@@ -16,7 +16,9 @@ import {
isDevpaceFile,
isAdvanceMode,
extractWriteContent,
- isStateChangeToApproved
+ isStateChangeToApproved,
+ readSyncStateCache,
+ updateSyncStateCache
} from '../../hooks/lib/utils.mjs';
// ── Test helpers ────────────────────────────────────────────────────
@@ -220,3 +222,100 @@ describe('isStateChangeToApproved', () => {
assert.equal(isStateChangeToApproved(undefined), false);
});
});
+
+// ── readSyncStateCache ──────────────────────────────────────────────
+
+describe('readSyncStateCache', () => {
+ let tmpDir;
+
+ it('returns empty Map when cache file does not exist', () => {
+ tmpDir = createTmpDir();
+ const cache = readSyncStateCache(tmpDir);
+ assert.equal(cache instanceof Map, true);
+ assert.equal(cache.size, 0);
+ cleanupDir(tmpDir);
+ });
+
+ it('parses CR-xxx=state entries correctly', () => {
+ tmpDir = createTmpDir();
+ mkdirSync(join(tmpDir, '.devpace'), { recursive: true });
+ writeFileSync(
+ join(tmpDir, '.devpace/.sync-state-cache'),
+ 'CR-001=developing\nCR-002=merged\nCR-003=in_review\n'
+ );
+ const cache = readSyncStateCache(tmpDir);
+ assert.equal(cache.size, 3);
+ assert.equal(cache.get('CR-001'), 'developing');
+ assert.equal(cache.get('CR-002'), 'merged');
+ assert.equal(cache.get('CR-003'), 'in_review');
+ cleanupDir(tmpDir);
+ });
+
+ it('skips blank lines', () => {
+ tmpDir = createTmpDir();
+ mkdirSync(join(tmpDir, '.devpace'), { recursive: true });
+ writeFileSync(
+ join(tmpDir, '.devpace/.sync-state-cache'),
+ 'CR-001=developing\n\n\nCR-002=merged\n'
+ );
+ const cache = readSyncStateCache(tmpDir);
+ assert.equal(cache.size, 2);
+ cleanupDir(tmpDir);
+ });
+
+ it('handles malformed lines gracefully', () => {
+ tmpDir = createTmpDir();
+ mkdirSync(join(tmpDir, '.devpace'), { recursive: true });
+ writeFileSync(
+ join(tmpDir, '.devpace/.sync-state-cache'),
+ 'CR-001=developing\nbadline\n=nokey\nCR-002=merged\n'
+ );
+ const cache = readSyncStateCache(tmpDir);
+ assert.equal(cache.get('CR-001'), 'developing');
+ assert.equal(cache.get('CR-002'), 'merged');
+ cleanupDir(tmpDir);
+ });
+});
+
+// ── updateSyncStateCache ────────────────────────────────────────────
+
+describe('updateSyncStateCache', () => {
+ let tmpDir;
+
+ it('creates cache file and .devpace/ directory if not exist', () => {
+ tmpDir = createTmpDir();
+ updateSyncStateCache(tmpDir, 'CR-001', 'developing');
+ const cache = readSyncStateCache(tmpDir);
+ assert.equal(cache.get('CR-001'), 'developing');
+ cleanupDir(tmpDir);
+ });
+
+ it('adds new entry to existing cache', () => {
+ tmpDir = createTmpDir();
+ mkdirSync(join(tmpDir, '.devpace'), { recursive: true });
+ writeFileSync(
+ join(tmpDir, '.devpace/.sync-state-cache'),
+ 'CR-001=developing\n'
+ );
+ updateSyncStateCache(tmpDir, 'CR-002', 'merged');
+ const cache = readSyncStateCache(tmpDir);
+ assert.equal(cache.size, 2);
+ assert.equal(cache.get('CR-001'), 'developing');
+ assert.equal(cache.get('CR-002'), 'merged');
+ cleanupDir(tmpDir);
+ });
+
+ it('updates existing entry', () => {
+ tmpDir = createTmpDir();
+ mkdirSync(join(tmpDir, '.devpace'), { recursive: true });
+ writeFileSync(
+ join(tmpDir, '.devpace/.sync-state-cache'),
+ 'CR-001=developing\n'
+ );
+ updateSyncStateCache(tmpDir, 'CR-001', 'merged');
+ const cache = readSyncStateCache(tmpDir);
+ assert.equal(cache.size, 1);
+ assert.equal(cache.get('CR-001'), 'merged');
+ cleanupDir(tmpDir);
+ });
+});
diff --git a/tests/static/test_cross_references.py b/tests/static/test_cross_references.py
index ebb643b..502c896 100644
--- a/tests/static/test_cross_references.py
+++ b/tests/static/test_cross_references.py
@@ -141,6 +141,36 @@ def test_tc_cr_08_rules_refs_have_path(self):
)
assert not bare_refs, f"Rules bare filename refs (need path prefix):\n" + "\n".join(bare_refs)
+ def test_tc_cr_09_value_tree_5_layer_entities(self):
+ """TC-CR-09: project-format.md value tree covers 5-layer entities (OBJ→Epic→BR→PF→CR)."""
+ pf = DEVPACE_ROOT / "knowledge" / "_schema" / "project-format.md"
+ content = pf.read_text(encoding="utf-8")
+ for entity in ["OBJ", "EPIC", "BR-", "PF-", "CR-"]:
+ assert entity in content, \
+ f"project-format.md value tree missing entity layer: {entity}"
+ # Check that Epic link format is documented
+ assert "epics/EPIC" in content, \
+ "project-format.md missing Epic link format documentation"
+ # Check that BR overflow format is documented
+ assert "requirements/BR" in content, \
+ "project-format.md missing BR overflow format documentation"
+
+ def test_tc_cr_10_epic_schema_refs_valid(self):
+ """TC-CR-10: epic-format.md references to project.md and BR are consistent."""
+ epic = DEVPACE_ROOT / "knowledge" / "_schema" / "epic-format.md"
+ content = epic.read_text(encoding="utf-8")
+ assert "OBJ" in content, "epic-format.md missing OBJ reference"
+ assert "BR-" in content or "BR" in content, "epic-format.md missing BR reference"
+ assert "project.md" in content, "epic-format.md missing project.md reference"
+
+ def test_tc_cr_11_br_schema_refs_valid(self):
+ """TC-CR-11: br-format.md references to Epic and PF are consistent."""
+ br = DEVPACE_ROOT / "knowledge" / "_schema" / "br-format.md"
+ content = br.read_text(encoding="utf-8")
+ assert "EPIC" in content or "Epic" in content, "br-format.md missing Epic reference"
+ assert "PF-" in content or "PF" in content, "br-format.md missing PF reference"
+ assert "project.md" in content, "br-format.md missing project.md reference"
+
def test_tc_cr_05_claude_md_template_synced_with_rules(self):
"""TC-CR-05: claude-md-devpace.md template contains key content or delegates to rules."""
template = DEVPACE_ROOT / "skills" / "pace-init" / "templates" / "claude-md-devpace.md"
diff --git a/tests/static/test_pace_init.py b/tests/static/test_pace_init.py
index d321e56..dc17f77 100644
--- a/tests/static/test_pace_init.py
+++ b/tests/static/test_pace_init.py
@@ -71,6 +71,7 @@ def _procedure_files():
"init-procedures-migration.md",
"init-procedures-monorepo.md",
"init-procedures-checks.md",
+ "init-procedures-lite.md",
]
# Routing table from SKILL.md: parameter -> procedure file(s)
diff --git a/tests/static/test_schema_compliance.py b/tests/static/test_schema_compliance.py
index 8a0a847..0ac50a1 100644
--- a/tests/static/test_schema_compliance.py
+++ b/tests/static/test_schema_compliance.py
@@ -120,3 +120,36 @@ def test_tc_sc_08_claude_md_template(self):
assert "输出" in content, "claude-md missing output control"
assert ".devpace/" in content, "claude-md missing .devpace file reference"
assert "state.md" in content, "claude-md missing state.md reference"
+
+ def test_tc_sc_09_epic_schema(self):
+ """TC-SC-09: epic-format.md has required sections and fields."""
+ content = (SCHEMA_DIR / "epic-format.md").read_text(encoding="utf-8")
+ assert _has_heading(content, "§0"), "epic-format.md missing §0 速查卡片"
+ assert _has_heading(content, "文件结构"), "epic-format.md missing '文件结构'"
+ assert _has_heading(content, "字段说明"), "epic-format.md missing '字段说明'"
+ assert _has_heading(content, "状态计算规则"), "epic-format.md missing '状态计算规则'"
+ assert _has_heading(content, "容错"), "epic-format.md missing '容错'"
+ for field in ["OBJ", "状态", "背景", "成效指标", "业务需求"]:
+ assert field in content, f"epic-format.md missing field: {field}"
+
+ def test_tc_sc_10_br_schema(self):
+ """TC-SC-10: br-format.md has required sections and fields."""
+ content = (SCHEMA_DIR / "br-format.md").read_text(encoding="utf-8")
+ assert _has_heading(content, "§0"), "br-format.md missing §0 速查卡片"
+ assert _has_heading(content, "溢出触发条件"), "br-format.md missing '溢出触发条件'"
+ assert _has_heading(content, "溢出格式"), "br-format.md missing '溢出格式'"
+ assert _has_heading(content, "状态计算规则"), "br-format.md missing '状态计算规则'"
+ assert _has_heading(content, "容错"), "br-format.md missing '容错'"
+ for field in ["Epic", "OBJ", "状态", "优先级", "产品功能"]:
+ assert field in content, f"br-format.md missing field: {field}"
+
+ def test_tc_sc_11_opportunity_schema(self):
+ """TC-SC-11: opportunity-format.md has required sections and fields."""
+ content = (SCHEMA_DIR / "opportunity-format.md").read_text(encoding="utf-8")
+ assert _has_heading(content, "§0"), "opportunity-format.md missing §0 速查卡片"
+ assert _has_heading(content, "文件结构"), "opportunity-format.md missing '文件结构'"
+ assert _has_heading(content, "来源类型枚举"), "opportunity-format.md missing '来源类型枚举'"
+ assert _has_heading(content, "状态定义"), "opportunity-format.md missing '状态定义'"
+ assert _has_heading(content, "容错"), "opportunity-format.md missing '容错'"
+ for source in ["用户反馈", "竞品观察", "技术发现", "市场趋势", "内部洞察"]:
+ assert source in content, f"opportunity-format.md missing source type: {source}"
diff --git a/tests/static/test_state_machine.py b/tests/static/test_state_machine.py
index c995f21..10897a6 100644
--- a/tests/static/test_state_machine.py
+++ b/tests/static/test_state_machine.py
@@ -67,6 +67,62 @@ def test_tc_sm_06_cr_schema_states_consistent(self):
f"cr-format.md missing state: {state}"
+EPIC_SCHEMA = DEVPACE_ROOT / "knowledge" / "_schema" / "epic-format.md"
+BR_SCHEMA = DEVPACE_ROOT / "knowledge" / "_schema" / "br-format.md"
+OPP_SCHEMA = DEVPACE_ROOT / "knowledge" / "_schema" / "opportunity-format.md"
+
+EPIC_STATES = ["规划中", "进行中", "已完成", "已搁置"]
+BR_STATES = ["待开始", "进行中", "已完成", "暂停"]
+OPP_STATES = ["评估中", "已采纳", "已搁置", "已拒绝"]
+
+
+@pytest.mark.static
+class TestEpicStateMachine:
+ def test_tc_esm_01_states_defined(self):
+ """TC-ESM-01: epic-format.md defines all 4 Epic states."""
+ content = EPIC_SCHEMA.read_text(encoding="utf-8")
+ missing = [s for s in EPIC_STATES if s not in content]
+ assert not missing, f"epic-format.md missing states: {missing}"
+
+ def test_tc_esm_02_state_calculation_rules(self):
+ """TC-ESM-02: epic-format.md has state calculation rules table."""
+ content = EPIC_SCHEMA.read_text(encoding="utf-8")
+ assert "状态计算规则" in content, "epic-format.md missing state calculation rules"
+ # Each state should appear in the rules table
+ for state in EPIC_STATES:
+ assert state in content, f"epic-format.md state calculation missing: {state}"
+
+
+@pytest.mark.static
+class TestBRStateMachine:
+ def test_tc_bsm_01_states_defined(self):
+ """TC-BSM-01: br-format.md defines all 4 BR states."""
+ content = BR_SCHEMA.read_text(encoding="utf-8")
+ missing = [s for s in BR_STATES if s not in content]
+ assert not missing, f"br-format.md missing states: {missing}"
+
+ def test_tc_bsm_02_state_calculation_rules(self):
+ """TC-BSM-02: br-format.md has state calculation rules table."""
+ content = BR_SCHEMA.read_text(encoding="utf-8")
+ assert "状态计算规则" in content, "br-format.md missing state calculation rules"
+
+
+@pytest.mark.static
+class TestOppStateMachine:
+ def test_tc_osm_01_states_defined(self):
+ """TC-OSM-01: opportunity-format.md defines all 4 Opportunity states."""
+ content = OPP_SCHEMA.read_text(encoding="utf-8")
+ missing = [s for s in OPP_STATES if s not in content]
+ assert not missing, f"opportunity-format.md missing states: {missing}"
+
+ def test_tc_osm_02_state_transitions(self):
+ """TC-OSM-02: opportunity-format.md defines state transitions."""
+ content = OPP_SCHEMA.read_text(encoding="utf-8")
+ assert "状态定义" in content, "opportunity-format.md missing state definitions"
+ assert "已采纳" in content and "EPIC" in content, \
+ "opportunity-format.md missing 已采纳→EPIC transition"
+
+
RELEASE_SCHEMA = DEVPACE_ROOT / "knowledge" / "_schema" / "release-format.md"
RELEASE_TEMPLATE = DEVPACE_ROOT / "skills" / "pace-init" / "templates" / "release.md"