@guanlin4924/devflow-pi 0.1.0

package/plugins/devflow-requirements/skills/workflow-requirement-baseline/assets/baseline-template.md

@@ -0,0 +1,281 @@
+# 需求基线：{{功能名称}}
+
+## 一、需求来源
+
+- **来源类型**：{{PRD / 会议纪要 / 用户描述 / 其他}}
+- **来源文件/说明**：{{来源}}
+- **生成时间**：{{日期}}
+- **项目上下文**：`.planning/PROJECT.md`
+- **项目导航**：`.planning/navigation/INDEX.md`
+- **功能名称**：{{功能名称}}
+- **功能目录名**：{{功能名，用于 .planning/features/{功能名}/}}
+- **下游输出目录**：`.planning/features/{{功能名}}/`
+
+## 二、需求整理摘要
+
+### 2.1 背景与目标
+
+{{背景与目标}}
+
+### 2.2 涉及角色
+
+| 角色 | 说明 | 来源 |
+|------|------|------|
+| {{角色}} | {{说明}} | {{来源}} |
+
+### 2.3 涉及页面/模块
+
+| 页面/模块 | 类型 | 说明 | 来源 |
+|-----------|------|------|------|
+| {{页面或模块}} | {{新增/修改/影响}} | {{说明}} | {{来源}} |
+
+## 三、当前功能切片
+
+> 下游 skill 默认只消费当前功能切片，以及 `depends_on` 引用的历史 FP/BR/BC 详情。全量历史需求仍保留在后续章节中，不能被默认为本轮范围。
+
+- **当前功能名**：{{功能名}}
+- **本轮范围说明**：{{本轮新增/修改/影响范围摘要}}
+- **是否触发大需求分片**：{{是/否；触发原因或未触发原因}}
+- **当前执行切片**：{{SL-001 / SL-002 ...}} — {{切片名称}}
+
+### 3.0 切片计划
+
+| Slice ID | 名称 | 业务结果 | 纳入 FP/BR/BC | 依赖 | 入口/链路 | 排除/后置 | 门禁 |
+|----------|------|----------|---------------|------|-----------|-----------|------|
+| SL-001 | {{切片名称}} | {{用户/业务可验证结果}} | {{FP/BR/BC}} | {{无/SL-xxx}} | {{入口 -> 写入 -> 读取}} | {{不包含内容}} | {{验收锚点}} |
+
+### 3.0a 当前执行切片范围
+
+| 类型 | ID | 名称/说明 | 本轮关系 | 状态 | Slice |
+|------|----|-----------|----------|------|-------|
+| FP | FP-001 | {{功能点名称}} | {{新增/修改/影响}} | {{明确/待确认/推断，待确认}} | SL-001 |
+| BR | BR-001 | {{规则说明}} | {{新增/修改/影响}} | {{明确/待确认}} | SL-001 |
+| BC | BC-001 | {{场景说明}} | {{新增/修改/影响}} | {{明确/待确认}} | SL-001 |
+
+### 3.0b 后置切片（仅作上下文，不进入本轮下游实现）
+
+| Slice ID | 名称 | FP/BR/BC | 后置原因 | 依赖 | 进入条件 | 门禁 |
+|----------|------|----------|----------|------|----------|------|
+| SL-002 | {{切片名称}} | {{FP/BR/BC}} | {{原因}} | {{SL-001/用户拍板/外部条件}} | {{SL-001 门禁通过/用户拍板/依赖完成}} | {{验收锚点}} |
+
+### 3.0c 分片覆盖守恒
+
+| 检查项 | 计数/结果 | 说明 |
+|--------|-----------|------|
+| 原始需求条目总数 | {{N}} | 必须全部映射到 FP/BR/BC/Q/OUT/DUP |
+| 当前功能 FP 总数 | {{N}} | active + deferred + out-of-scope 必须等于该值 |
+| Active FP 数 | {{N}} | 当前执行切片 |
+| Deferred FP 数 | {{N}} | 后置切片，必须有进入条件 |
+| Out-of-scope FP/条目数 | {{N}} | 必须有来源和原因 |
+| 守恒结论 | {{通过/不通过}} | {{如不通过，审查结论不得通过}} |
+
+### 3.1 当前 FP/BR/BC
+
+| 类型 | ID | 名称/说明 | 本轮关系 | 状态 |
+|------|----|-----------|----------|------|
+| FP | FP-001 | {{功能点名称}} | {{新增/修改/影响}} | {{明确/待确认/推断，待确认}} |
+| BR | BR-001 | {{规则说明}} | {{新增/修改/影响}} | {{明确/待确认}} |
+| BC | BC-001 | {{场景说明}} | {{新增/修改/影响}} | {{明确/待确认}} |
+
+### 3.2 跨功能依赖
+
+| 依赖对象 | 关系 | 原因 | 下游读取要求 |
+|----------|------|------|--------------|
+| FP-003 | {{前置依赖/修改/复用/兼容/替换/影响}} | {{为什么当前功能依赖该历史项}} | {{下游需要同时读取的历史详情或约束}} |
+
+## 四、功能点拆解
+
+| 功能点ID | 功能点 | 类型 | 状态 | 优先级 | 来源 |
+|----------|--------|------|------|--------|------|
+| FP-001 | {{功能点名称}} | {{新增/修改/影响}} | {{明确/待确认/推断，待确认}} | {{P0/P1/P2}} | {{来源段落}} |
+
+## 五、原始需求追溯
+
+| 原始条目ID | 来源位置 | 原始内容摘要 | 映射类型 | 映射对象 | 处理说明 |
+|------------|----------|--------------|----------|----------|----------|
+| SRC-001 | {{来源章节/段落/会议纪要条目}} | {{原始需求摘要}} | {{功能点/业务规则/边界场景/范围外/待确认}} | {{FP-001/BR-001/BC-001/Q-001/范围项}} | {{处理说明}} |
+
+## 六、功能点详情
+
+### FP-001 {{功能点名称}}
+
+- **类型**：{{新增/修改/影响}}
+- **状态**：{{明确/待确认/推断，待确认}}
+- **优先级**：{{P0/P1/P2}}
+- **来源**：{{来源段落/章节；若为推断则写“推断，待确认”}}
+- **涉及角色**：{{角色}}
+- **入口/触发**：{{入口或触发条件}}
+- **前置条件**：{{前置条件}}
+- **需求描述**：{{需求描述}}
+- **主流程**：
+  1. {{步骤1}}
+  2. {{步骤2}}
+- **业务规则**：
+  - {{规则}}
+- **数据要求**：
+  - {{字段/数据/格式/存储/筛选/导出要求}}
+- **边界场景**：
+  - {{边界场景及处理方式}}
+- **关联已有模块**：{{历史模块或待确认}}
+- **待确认问题**：
+  - {{问题，若无则写“无”}}
+
+## 七、业务规则汇总
+
+| 规则ID | 关联功能点 | 规则说明 | 来源 | 状态 |
+|--------|------------|----------|------|------|
+| BR-001 | FP-001 | {{规则说明}} | {{来源}} | {{明确/待确认}} |
+
+## 八、边界场景汇总
+
+| 场景ID | 关联功能点 | 场景 | 处理方式 | 状态 |
+|--------|------------|------|----------|------|
+| BC-001 | FP-001 | {{场景}} | {{处理方式}} | {{明确/待确认}} |
+
+## 九、与历史功能/里程碑的关联
+
+### 9.1 已搜索历史来源
+
+| 来源类型 | 路径/范围 | 结论 |
+|----------|-----------|------|
+| 里程碑 | `.planning/milestones/...` | {{相关/无相关/不存在/未扫描原因}} |
+| 历史需求基线 | `.planning/requirements/...` | {{相关/无相关/不存在/未扫描原因}} |
+| 经验教训 | `.planning/lessons/...` | {{相关/无相关/不存在/未扫描原因}} |
+| 阶段上下文 | `.planning/*/CONTEXT.md` | {{相关/无相关/不存在/未扫描原因}} |
+| Legacy/项目规则历史 | `features/` / `.context/lessons/` / `.context/workflow/` | {{如存在则记录；不存在则写“不适用”}} |
+
+### 9.2 关联历史功能/里程碑
+
+| 历史功能/模块 | 关联功能点 | 关系 | 影响说明 | 兼容性要求 |
+|---------------|------------|------|----------|------------|
+| {{历史功能}} | FP-001 | {{新增/修改/替换/影响}} | {{影响说明}} | {{兼容性}} |
+
+## 十、代码现实对照
+
+> 只记录需求层面的当前行为、差异和影响。不写实现方案、DDL、API 设计、字段设计或代码任务。
+
+| 关联项 | 相关模块/文件 | 源码证据 | 当前行为 | 比差结论 | 需求影响 |
+|--------|---------------|----------|----------|----------|----------|
+| FP-001 | `{{path}}` | `{{path:line}}` | {{只描述源码现状}} | {{已存在且一致/已存在但冲突/不存在/未完成源码比差（审查不通过）}} | {{可复用/需要用户确认/需下游 tech-spec 评估}} |
+
+### 10.1 Navigation 更新提示
+
+| 发现 | 影响 | 建议 |
+|------|------|------|
+| {{navigation 与源码不一致时记录；无则写“无”}} | {{影响范围}} | {{交给 workflow-update-navigation 或后续审计处理}} |
+
+## 十一、下游输入契约
+
+统一使用以下功能目录，后续 skill 不得重新生成不同目录名：
+
+- **功能名**：{{功能名}}
+- **输出目录**：`.planning/features/{{功能名}}/`
+- **当前功能切片**：读取本文档“当前功能切片”中的当前 FP/BR/BC。
+- **当前执行切片**：读取本文档“3.0a 当前执行切片范围”。非当前切片只能作为依赖上下文，不得生成实现任务。
+- **跨功能依赖**：读取 `depends_on` 引用的历史 FP/BR/BC 详情，不得只读当前 FP 而忽略依赖项。
+
+### 11.1 给功能点梳理
+
+- 读取本文档的当前功能切片、`depends_on` 引用详情、功能点详情、业务规则、边界场景。
+- 输出必须带当前 `Slice ID`，且只展开当前执行切片。
+- 输出 `.planning/features/{{功能名}}/功能点梳理.md`。
+
+### 11.1a 给测试指导书
+
+- 读取 `.planning/features/{{功能名}}/功能点梳理.md`（主要输入）和本文档的 FP/BR/BC/CR 关联。
+- 同时读取 `.planning/PROJECT.md`。
+- 此步骤为可选，不阻塞下游门禁。
+- 输出 `.planning/features/{{功能名}}/测试指导书.md`。
+
+### 11.2 给前端技术方案
+
+- 读取 `.planning/features/{{功能名}}/功能点梳理.md` 中的页面/组件/字段/交互拆解。
+- 只为当前执行切片生成前端方案；后置切片只列为依赖或后续范围。
+- 读取本文档的当前功能切片、跨功能依赖、涉及页面/模块、入口/触发、主流程、边界场景、数据要求。
+- 同时读取 `.planning/navigation/INDEX.md` → 筛选前端类型代码库 → 加载对应 navigation 文件。
+- 输出 `.planning/features/{{功能名}}/前端技术方案.md`。
+
+### 11.3 给后端技术方案
+
+- 读取 `.planning/features/{{功能名}}/功能点梳理.md` 中的 API/服务节点和逻辑维度。
+- 只为当前执行切片生成后端方案；共享能力若服务于后置切片，必须有当前切片可验证门禁。
+- 读取本文档的当前功能切片、跨功能依赖、业务规则、数据要求、与历史功能/里程碑的关联、兼容性要求、边界场景、代码现实对照。
+- 同时读取 `.planning/navigation/INDEX.md` → 筛选后端/服务类型代码库 → 加载对应 navigation 文件。
+- 输出 `.planning/features/{{功能名}}/后端技术方案.md`。
+
+### 11.4 给变更清单
+
+- 读取本文档的功能点、业务规则、边界场景、反向审视与用户拍板。
+- 同时读取 `.planning/features/{{功能名}}/前端技术方案.md` 和 `.planning/features/{{功能名}}/后端技术方案.md`。
+- 变更任务必须标注 `Slice ID`；不得生成后置切片的实现任务。
+- 输出 `.planning/features/{{功能名}}/变更清单.md`。
+
+### 11.5 给测试验收
+
+- 每个功能点 ID 都应可映射为验收点。
+- `待确认` 项不得作为最终验收标准，需先确认或降级为风险。
+
+## 十二、待确认事项
+
+| 问题ID | 关联功能点 | 问题 | 影响 | 当前处理 |
+|--------|------------|------|------|----------|
+| Q-001 | FP-001 | {{问题}} | {{影响范围}} | {{非阻塞待确认/阻塞未确认（审查不通过）；来源：来源段落或推断，待确认}} |
+
+## 十三、反向审视与用户拍板
+
+| 审视ID | 维度 | 关联对象 | 证据 | 选项/待决策 | 用户决策/状态 | 对基线的影响 |
+|--------|------|----------|------|-------------|----------------|--------------|
+| CR-001 | {{C1冲突/C2复用/C3历史/C4过度工程/C5替代方案}} | {{FP-001/BR-001/BC-001/范围项/下游契约}} | {{代码/历史/需求证据；若无发现写明已检查范围}} | {{选项A/选项B/待确认问题}} | {{用户选择/待确认/无发现}} | {{更新或保留的需求项}} |
+
+### 13.1 冲突识别
+
+{{记录新需求与当前项目上下文的冲突；无冲突时写明检查范围和无冲突结论}}
+
+### 13.2 复用机会
+
+{{记录现有业务能力、依赖库、项目模式的复用判断；需要用户选择时记录选项}}
+
+### 13.3 历史教训与既有方案
+
+{{记录已搜索的历史目录/文档，以及相关历史决策或无相关历史的证据}}
+
+### 13.4 过度工程审查
+
+{{记录未明确要求、偏未来扩展、复杂度过高的候选项及用户处理意见}}
+
+### 13.5 替代方案与不做基线
+
+{{记录核心功能的当前方案、可选简化方案、不做/延期基线，以及用户选择理由}}
+
+## 十四、澄清与变更记录
+
+| 记录ID | 来源问题/回答 | 影响对象 | 变更类型 | 变更说明 |
+|--------|---------------|----------|----------|----------|
+| CL-001 | {{Q-001 / 用户回答摘要}} | {{FP-001/BR-001/BC-001/范围项/下游契约}} | {{确认/修正/新增/缩小范围/扩大范围/冲突处理}} | {{更新了什么，以及为什么更新}} |
+
+## 十五、范围控制
+
+### 15.1 明确不包含
+
+| 内容 | 原因 | 来源 |
+|------|------|------|
+| {{不包含内容}} | {{原因}} | {{来源}} |
+
+### 15.2 暂不处理
+
+| 内容 | 原因 | 后续建议 |
+|------|------|----------|
+| {{暂不处理内容}} | {{原因}} | {{建议}} |
+
+## 十六、需求审查结果
+
+| 检查项 | 结果 | 说明 |
+|--------|------|------|
+| 原始需求覆盖 | {{通过/有缺口}} | {{说明}} |
+| 功能点可开发性 | {{通过/有缺口}} | {{说明}} |
+| 功能点可测试性 | {{通过/有缺口}} | {{说明}} |
+| 历史影响检查 | {{通过/有缺口}} | {{说明}} |
+| 反向审视 | {{通过/有待拍板}} | {{冲突/复用/历史/过度工程/替代方案检查结果}} |
+| 下游输入完整性 | {{通过/有缺口}} | {{说明}} |
+| 大需求分片审查 | {{通过/有缺口}} | {{是否触发分片、当前 active slice、是否存在范围走私/依赖雾化}} |
+| 分片覆盖守恒 | {{通过/有缺口}} | {{原始条目、FP/BR/BC、active/deferred/out-of-scope 计数是否对齐}} |

package/plugins/devflow-requirements/skills/workflow-requirement-baseline/references/antipatterns.md

@@ -0,0 +1,69 @@
+# Requirement Challenge Antipatterns
+
+Use this file when running challenge review or final review. It captures behaviors that make requirement review look complete while leaving real decisions unresolved.
+
+## Decision Ownership
+
+Wrong:
+
+- Choosing a conflict option for the user because it looks simpler.
+- Writing "建议采用 A" before the user asks for advice.
+- Treating "OK", "嗯", or "可以" as a reason for a scope, reuse, or alternative-path decision.
+
+Required:
+
+- Present materially different options with tradeoffs.
+- Ask the user to choose when the decision changes scope, semantics, ownership, cost, compatibility, or long-term maintenance.
+- Record the user-provided decision or reason. If the answer is not substantive, keep the item pending.
+
+## Challenge Review Skips
+
+Wrong:
+
+- Writing "未发现问题" without saying what was checked.
+- Leaving alternative-path review empty for a P0 or expensive feature.
+- Claiming there is no historical precedent without searching the project's planning history.
+
+Required:
+
+- For each challenge dimension, write either a finding, a no-finding statement with searched evidence, or a pending decision.
+- For P0 or expensive feature points, include current path, simpler/defer path when possible, and do-nothing/defer baseline.
+- If alternatives are impossible, record the hard constraints and ask the user to confirm their source.
+
+## History Source Mismatch
+
+Wrong:
+
+- Assuming the project keeps outbound-call style `features/*.spec.md` history.
+- Treating `.context/lessons/README.md` as the only source of historical product or requirement decisions.
+- Ignoring milestone artifacts because their filenames differ from spec documents.
+
+Required:
+
+- Use this workflow's primary history model first: `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and `.planning/*/CONTEXT.md`.
+- Treat `features/`, `.context/lessons/`, and `.context/workflow/` as optional legacy or project-rule evidence when present.
+- Record exactly which history sources were checked.
+
+## Implementation Leakage
+
+Wrong:
+
+- Turning requirement review into API design, DDL, task breakdown, or code instructions.
+- Hiding an unresolved requirement decision inside a technical workaround.
+
+Required:
+
+- Keep requirement review at the level of scope, behavior, rules, boundaries, priority, compatibility, and downstream contracts.
+- Push technical implementation details to frontend/backend tech-spec and change-plan skills.
+
+## Pipeline Leakage
+
+Wrong:
+
+- Letting a pending conflict, reuse decision, over-engineering decision, or alternative-path reason flow into technical planning as confirmed scope.
+- Dropping challenge decisions from downstream documents.
+
+Required:
+
+- Mark unresolved challenge items as blockers when they affect scope, semantics, ownership, compatibility, or effort.
+- Downstream skills must read `反向审视与用户拍板` and either consume confirmed decisions or stop/record pending blockers.

package/plugins/devflow-requirements/skills/workflow-requirement-baseline/references/challenge-review-guide.md

@@ -0,0 +1,158 @@
+# Challenge Review Guide
+
+Use this guide after feature point decomposition and before final clarification.
+
+The goal is to challenge the requirement against code reality and simplicity without producing a technical solution. Every challenge item must be tied to concrete source material, project context, or an explicit inference marked `推断，待确认`.
+
+## Boundaries
+
+Do:
+
+- Identify conflicts between the requested behavior and the current project context.
+- Identify existing capabilities that may cover all or part of the request.
+- Identify historical lessons, previous feature decisions, or abandoned approaches.
+- Identify over-engineering candidates that are not clearly requested.
+- Ask the user to choose between materially different requirement directions.
+
+Do not:
+
+- Judge product or business value.
+- Write implementation plans, DDL, API designs, code tasks, or roadmap items.
+- Recommend one option as the answer unless the user explicitly asks for advice.
+- Treat an inferred improvement as confirmed scope.
+
+## Challenge Dimensions
+
+## Entry Triage Carry-Forward
+
+If `.planning/requirements/{功能名}/入口分诊.md` exists, start challenge review from its findings:
+
+- Duplicate or already-done evidence feeds C1 and C2.
+- Prior rejection / out-of-scope evidence feeds C3 and may block baseline until the user explicitly reverses it.
+- Partial overlap evidence feeds C2 and C5-lite.
+- `ready_for_human`, `already_done`, and `wontfix` routes are challenge findings, not neutral notes.
+
+Do not repeat the same shallow search unless the evidence is stale or Phase 4 requires source-level line evidence.
+
+## Review Depth
+
+Choose the review depth before applying dimensions:
+
+| Depth | When to use | Required dimensions |
+|-------|-------------|---------------------|
+| `light` | Single text, display, copy, layout, or isolated low-risk behavior change with no new persistence, permission, status, or API contract | C1, C2, C4 |
+| `standard` | New interface, new status, new permission, new data write, or extension of existing behavior without high-risk data domains | C1, C2, C4, C5-lite |
+| `strict` | Cross frontend/backend change, multiple modules, historical data compatibility, task scheduling, money/payment, permissions, data migration, audit, or high-cost P0 scope | C1, C2, C3, C4, C5 |
+
+Default to `standard` when unsure. If the feature modifies existing code or overlaps with an existing module, `standard` must include C5-lite even if the change seems small.
+
+C5-lite asks only:
+
+```text
+Is there an obvious reuse, extension, or lower-cost path compared with creating a separate capability?
+```
+
+If C5-lite finds a real alternative that changes scope, semantics, ownership, or long-term maintenance, escalate that item to full C5 and ask the user to decide.
+
+### C1. Current-State Conflict
+
+Check whether any feature point conflicts with the current project context.
+
+Common conflict types:
+
+- Naming or convention conflicts.
+- Existing ownership or responsibility conflicts.
+- Architecture conflicts, such as sync vs async, single transaction vs eventual consistency.
+- Data model conflicts.
+- Workflow conflicts.
+- Permission, tenant, or data boundary conflicts.
+
+When found, record:
+
+- Affected `FP-*`, `BR-*`, or `BC-*`.
+- Requested behavior.
+- Current-state evidence.
+- Impact if unresolved.
+- Two or more mutually exclusive options when a user decision is needed.
+
+### C2. Reuse Opportunity
+
+Check three reuse layers before treating a capability as new:
+
+1. Business capability: service, repository, job, module, page, workflow, or integration already does similar work.
+2. Library or dependency: an installed dependency already supports the needed capability.
+3. Project pattern: naming, layering, error handling, validation, permission, data model, or workflow pattern already exists.
+
+If any layer overlaps, record a reuse decision:
+
+- Reuse existing capability.
+- Extend existing capability.
+- Create a separate capability.
+- Defer the overlapping part.
+
+Do not silently choose. The user must decide when the choice changes scope, semantics, ownership, or long-term maintenance cost.
+
+### C3. Historical Lesson And Prior Work
+
+Search available history before claiming there is no precedent:
+
+- Primary workflow history: `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and `.planning/*/CONTEXT.md`.
+- Optional legacy/project-rule history when present: `features/`, `.context/lessons/README.md`, `.context/workflow/`, root `AGENTS.md`, and root `CLAUDE.md`.
+
+Do not assume outbound-call style `features/*.spec.md` exists. This workflow's normal long-term memory is milestone/planning based.
+
+Record what was searched. If a related prior decision exists, record:
+
+- Prior artifact path.
+- What was tried or decided.
+- Why it matters now.
+- Whether the current requirement avoids or repeats the same issue.
+
+### C4. Over-Engineering Candidate
+
+Mark a feature point as an over-engineering candidate when any condition applies:
+
+- The source material does not explicitly ask for it.
+- The reason is mainly future extensibility or "might need later".
+- It has much higher implementation or testing cost than the rest of the requirement.
+- It introduces an abstraction, configuration surface, or data model that is broader than current confirmed scope.
+
+Ask the user to decide:
+
+- Keep as P0 with a concrete reason.
+- Downgrade to P1/P2.
+- Move to future consideration.
+- Remove from scope.
+
+### C5. Alternative Path And Do-Nothing Baseline
+
+For P0, important, or expensive feature points, compare at least:
+
+- Current requested path.
+- A simpler alternative path when one exists.
+- Do-nothing or defer baseline.
+
+If alternatives are ruled out by hard constraints, confirm the constraints and their source. Record the user-provided reason in the baseline.
+If no P0 or expensive feature point exists, record that C5 was checked and why it is not applicable.
+
+## Clarification Rules
+
+- Ask only challenge questions that affect scope, feasibility, priority, downstream contracts, or long-term maintenance.
+- Ask one question at a time and follow the baseline clarification question protocol.
+- Decisions that affect scope, feasibility, priority, downstream contracts, or long-term maintenance must be asked and answered before the baseline can pass review.
+- If a user answer changes scope, feature points, rules, boundary cases, or output directory, update the affected items before continuing.
+- Do not accept vague approval as a decision reason. A substantive answer names the selected option, priority/scope decision, constraint source, or rationale that should be preserved for downstream work.
+
+## Baseline Recording
+
+Every challenge item must be recorded in the baseline under `反向审视与用户拍板`.
+
+Minimum fields:
+
+- Challenge ID: `CR-001`, `CR-002`, ...
+- Dimension: `C1` / `C2` / `C3` / `C4` / `C5`
+- Affected item: `FP-*`, `BR-*`, `BC-*`, scope item, or downstream contract.
+- Evidence.
+- Options or decision needed.
+- User decision or current pending status.
+- Baseline impact.

package/plugins/devflow-requirements/skills/workflow-requirement-baseline/references/decomposition-guide.md

@@ -0,0 +1,115 @@
+# Requirement Decomposition Guide
+
+Use this guide before asking clarification questions. Raw requirements are often fragmented; first normalize and split them into feature points.
+
+## Structuring Buckets
+
+Extract raw content into:
+
+- Background / goal: why this change exists
+- User roles: who uses or is affected by it
+- Pages / modules: where it appears
+- User actions: what users do
+- Data fields: fields shown, entered, imported, exported, stored, searched, or calculated
+- Business rules: calculations, validation, state transitions, eligibility, limits
+- Permission rules: who can view, create, edit, delete, approve, export
+- State changes: status values, lifecycle changes, old/new data handling
+- Exception and boundary cases: empty data, timeout, duplicate action, invalid input, permission denied
+- Non-functional requirements: performance, audit, security, compatibility, data volume
+- Open questions: anything unclear from the source
+
+## Feature Point Rules
+
+A feature point is a capability that can be developed and verified independently.
+
+## FP / BR / BC Classification
+
+Use this priority when classifying requirement content:
+
+1. **FP (Feature Point)**: a user-visible or system capability with an entry, trigger, owner, and independently verifiable outcome.
+2. **BR (Business Rule)**: a rule that constrains or defines how an FP behaves, such as scope, validation, calculation, eligibility, permission range, status transition, or compatibility rule.
+3. **BC (Boundary Case)**: an exception, edge, failure, empty, timeout, duplicate, permission-denied, partial-success, or old-data scenario and its expected handling.
+
+Do not promote every rule or boundary into an FP. Promote only when it has an independent entry, operation, configuration surface, or acceptance target.
+
+Common classification:
+
+| Requirement sentence | Classification |
+|----------------------|----------------|
+| "用户可以导出报表" | FP: report export capability |
+| "导出字段与当前筛选结果一致" | BR: constrains export behavior |
+| "无数据时导出空文件并提示" | BC: empty-data handling |
+| "管理员可以配置导出字段" | FP: independent configuration capability |
+| "仅管理员可导出" | BR: permission rule for an FP |
+| "无权限点击导出时提示无权限" | BC: permission-denied handling |
+
+Mixed example:
+
+```text
+Requirement: "管理员可以查看所有团队的报告"
+
+FP-008: 管理员全局报告查看能力
+  Reason: independent user-visible capability with entry and acceptance target.
+
+BR-012: 管理员可查看范围 = 下级团队 + 平级团队 / 全部团队（按用户确认）
+  Reason: constrains FP-008 behavior.
+
+BC-009: 管理员所属范围无数据时展示空白报告提示
+  Reason: edge-state handling for FP-008.
+```
+
+Split when:
+
+- One paragraph describes multiple actions
+- UI entry, backend rule, permission, export, audit, or notification can be tested independently
+- A rule affects existing data or historical flows
+- A field participates in display, storage, filtering, export, or statistics differently
+
+Merge when:
+
+- Two descriptions are just wording variants of the same behavior
+- A UI detail cannot be verified without the parent feature and has no separate rule
+
+Keep independent feature points for:
+
+- Permission control
+- Data import/export
+- Audit log / operation record
+- Notification / message
+- Compatibility with historical data
+- Status migration
+- Statistics/reporting
+- Error and retry behavior
+
+## Feature Point Schema
+
+Each feature point should have:
+
+- ID: `FP-001`
+- Name
+- Source: source paragraph, section, or summary
+- Type: `新增`, `修改`, or `影响`
+- Priority: `P0`, `P1`, or `P2`
+- Description
+- User role
+- Entry / trigger
+- Precondition
+- Main flow
+- Business rules
+- Data requirements
+- Boundary cases
+- Related existing module
+- Status: `明确`, `待确认`, or `推断，待确认`
+- Open questions
+
+## Traceability
+
+Every raw requirement sentence should be traceable to:
+
+- A feature point
+- A business rule
+- A boundary case
+- An out-of-scope item
+- A pending question
+
+Do not silently drop raw requirement content.