@guanlin4924/devflow-pi 0.1.0

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

@@ -0,0 +1,748 @@
+---
+name: workflow-requirement-baseline
+description: "Use after the mandatory requirement chain workflow-requirement-triage → workflow-wayfinder → workflow-domain-modeling → requirement-feasibility-review when raw requirements, PRDs, meeting notes, or feature requests need decomposition, conflict checks, and a unified baseline. Do not enter baseline before the feasibility review passes."
+---
+
+## Legacy Command Metadata
+
+Original slash-command metadata retained only as workflow invocation guidance.
+
+```yaml
+argument-hint: '[@需求文档.md]'
+user-invocable: true
+pattern: inversion+generator+reviewer
+inputs:
+- .planning/PROJECT.md
+- .planning/navigation/INDEX.md
+- .planning/navigation/*.md
+- .planning/milestones/
+- 原始需求文档/PRD/会议纪要/用户描述
+output: .planning/requirements/baseline.md
+phase-gate:
+  step1: 加载项目上下文和原始需求
+  step2: 需求整理：结构化原文信息
+  step3: 功能点拆解：生成稳定功能点 ID
+  step4: Reviewer：检查缺口、历史影响、可开发性和可测试性
+  step4.5: Challenge Review：冲突识别、复用机会、历史教训、过度工程和替代方案审视
+  step5: Inversion：只针对缺口和需要用户拍板的决策定向提问
+  step5.5: 回答影响复查：根据用户回答更新受影响需求项
+  step6: Generator：输出统一需求基线
+  step7: 最终审查：追溯、下游契约和范围控制检查
+resumable: true
+state-key: requirement-refine
+allowed-tools:
+- Read
+- Write
+- Bash
+- Grep
+- Glob
+- ask
+```
+
+# Requirement Discussion
+
+This skill receives raw requirements and turns them into a stable requirement baseline. Do not generate technical plans, change lists, code, roadmap, or implementation tasks.
+
+## Phase 0 — Requirement Main-Chain Gate
+
+Before Phase 1, check these mandatory upstream artifacts:
+
+- `.planning/requirements/{feature}/入口分诊.md` and `.meta.json`;
+- `.planning/requirements/{feature}/决策地图.md` and `.meta.json`;
+- `.planning/requirements/{feature}/领域模型记录.md` and `.meta.json`;
+- `.planning/requirements/{feature}/可实现性审查.md` and `.meta.json`.
+
+If any are missing, run the earliest missing main-chain step. Baseline must not become the first place where duplicate capability, fog, terminology ambiguity, or feasibility gaps are discovered.
+
+Route based on triage meta:
+
+| route | Required action |
+|-------|-----------------|
+| `ready_for_wayfinder` | Continue only after Wayfinder, domain modeling and feasibility review all pass; carry duplicate/reuse/history notes into Phase 4 and 4.5. |
+| `needs_info` | Ask the minimum blocking question recorded by triage. |
+| `ready_for_human` | Report the evidence and wait for user decision. |
+| `already_done` | Do not create a new baseline entry unless the user says this is a change on top of existing behavior. |
+| `wontfix` | Do not proceed unless the user explicitly reverses the prior out-of-scope decision. |
+
+Require `决策地图.meta.json.ready_for_baseline = true`, a valid domain-model record, and `可实现性审查.meta.json.status = ready_for_baseline` with `baseline_gate = pass`, `gap_count = 0`, and no critical findings. A Wayfinder Grilling ticket may invoke `workflow-demand-clarify`; demand clarification is not a bypass around this gate.
+
+When triage found partial overlap or prior rejection, preserve it as source material; do not re-run the same search later unless Phase 4 needs deeper code evidence.
+
+## 全局法则：对抗式审查
+
+**需求基线阶段就要植入攻击视角。不等到代码写完才做对抗式审查——需求本身就是第一道防线。**
+
+核心追问：**"如果我是攻击者/异常数据/极端场景，这个需求的哪条规则会被我利用？"**
+
+### 审查维度
+
+| 维度 | 在需求基线中的表现形式 | 示例 |
+|------|---------------------|------|
+| 输入攻击 | FP 的业务规则是否定义了字段上限？ | "用户可上传附件" → 大小上限？格式限制？ |
+| 时序攻击 | BC 是否覆盖了时间异常？ | 发布时间是未来/过去的文章如何处理？ |
+| 状态攻击 | 状态流转规则是否封闭？ | 是否允许从"已取消"直接跳到"已完成"？ |
+| 并发攻击 | 业务规则是否定义了幂等性？ | 双重点击提交 → 是否创建了重复记录？ |
+| 依赖攻击 | 外部依赖失败时的行为是否已定义？ | 支付回调超时 → 订单状态是什么？ |
+| 资源攻击 | 是否定义了资源上限？ | 批量操作一次最多多少条？导出最大行数？ |
+
+### 应用规则
+
+| 阶段 | 对抗式审查检查点 |
+|------|----------------|
+| Phase 2 需求结构化 | "异常和边界情况"bucket 中必须包含恶意输入/极端数据场景 |
+| Phase 3 功能点拆解 | BC（边界情况）必须覆盖资源上限、输入极端值、并发冲突 |
+| Phase 4 需求审查 | 检查基线是否只描述了"正常用户"的路径 |
+| Phase 7 最终审查 | 逐 FP 做对抗式反问：该 FP 的哪条规则可能被攻击？ |
+
+### 关键原则
+
+1. **不信任任何外部输入** — 如果 baseline 中某个操作接受外部数据但没有上限/校验定义，标记为 `BC-* 待补充`
+2. **不假定"用户不会那样做"** — 恶意用户就是会那样做。如果一条路径存在但没有防御规则，它就是攻击面
+3. **对抗式检查不增加 FP** — 不创建新的功能点，而是在已有 FP 的 BC（边界情况）和 BR（业务规则）中补全防御描述
+4. **遇到来自 demand-clarify 的"攻击面假设"** — 逐条转化为 BC 或 BR，不丢弃上游的攻击面预判
+
+## Outputs
+
+Always create or update:
+
+- `.planning/requirements/baseline.md` — unified requirement baseline
+- `.planning/requirements/baseline.meta.json` — structured metadata. Schema defined in `feature-development.yaml` under `steps[requirement-baseline].meta_output.fields`: `review_status`, `fp_count`, `br_count`, `bc_count`, `blocking_pending_count`, `critical_image_missing_count`, `challenge_pending_count`, `code_reality_missing_count`, `current_feature`, `depends_on_count`, plus optional `pending_items`, `risks`, and `key_decisions`.
+
+Do not create by default:
+
+- `.planning/features/{功能名}/功能点梳理.md`
+- `.planning/features/{功能名}/前端技术方案.md`
+- `.planning/features/{功能名}/后端技术方案.md`
+- `.planning/features/{功能名}/变更清单.md`
+
+## Argument Handling
+
+Parse `$ARGUMENTS` before Phase 1:
+
+- `@path/to/file.md`: load the referenced requirement document as the primary source.
+- Other text: treat as pasted requirement content or feature name context.
+
+If both a requirement document and pasted text are provided, use both and record them separately in the source summary.
+
+### 上游契约（与本技能串联的上游流程）
+
+当 `.planning/requirements/{feature}/入口分诊.md` 存在时（由 `workflow-requirement-triage` 生成）：
+
+1. 将分诊分类写入 `baseline.meta.json.requirement_type` 或需求来源摘要。
+2. 将 `related_code_paths` 作为 Phase 1.5/4 的优先检查入口，但不能直接当作行为结论。
+3. 将 `related_history_paths` 和 prior rejection 记录纳入 Phase 4.5 Challenge Review。
+4. 如果 `route` 不是 `ready_for_wayfinder`，按 Phase 0 路由停止或切换技能。
+
+当 `.planning/requirements/{feature}/决策地图.md` 存在时（由 `workflow-wayfinder` 生成）：
+
+1. 只有 `决策地图.meta.json.ready_for_baseline = true` 才可继续 baseline。
+2. Destination 和 Known Land 作为需求来源。
+3. 读取 `.planning/requirements/{feature}/wayfinder/WF-*.md` 中 `status=resolved` 的 ticket；其 Findings / Answer 转为 FP/BR/BC 或 `反向审视与用户拍板` 记录。
+4. Open ticket 只能进入待确认或后置探索，不能伪装成已确认需求。
+
+当 `.planning/requirements/{feature}/需求澄清记录.md` 存在时（由 `workflow-demand-clarify` 生成）：
+
+1. 优先以 **需求澄清记录.md** 的场景清单和分级任务单作为原始需求来源
+2. 将决策日志中的 L1-L4 决策结论转化为 `key_decisions` 元数据
+3. 核心确定区内容直接进入 FP 功能点拆解
+4. 假设验证区内容进入 BR（业务规则），标记为"待上线验证"
+5. 不需要再对用户做"场景反讲"等基础澄清——这些已经在 demand-clarify 阶段完成
+
+当 `.planning/requirements/{feature}/领域模型记录.md` 或 `.planning/CONTEXT.md` 存在时（由 `workflow-domain-modeling` 维护）：
+
+1. `.planning/CONTEXT.md` 只作为纯词汇表读取，不从中读取需求追溯。
+2. 使用已确认术语写 FP/BR/BC 名称，避免同义多词。
+3. 从 `领域模型记录.md` 读取术语冲突、边缘案例压力测试和追溯信息，并纳入 Phase 4/7 审查。
+4. ADR 只作为需求决策证据，不展开技术方案。
+
+当 `.planning/requirements/{feature}/可实现性审查.md` 存在时（由 `requirement-feasibility-review` 维护）：
+
+1. 仅消费其中 `SOURCE_FACT`、`CONFIRMED_DECISION` 和已接受实现方向；不得把 `DERIVED_QUESTION` 或 `ASSUMPTION` 写入 baseline。
+2. 将审查已确认的范围排除、外部能力边界、入口门禁和存量兼容规则转化为 FP/BR/BC。
+3. 若 review meta 未通过，不得用 baseline 阶段的追问绕过；回到审查或 Wayfinder ticket 解决。
+
+## Existing Baseline Update Policy
+
+**叠加原则：baseline.md 是需求的累积目录，不是单功能快照。每次新增需求时，在已有内容上追加，不覆盖。**
+
+If `.planning/requirements/baseline.md` already exists:
+
+1. Read it before restructuring new input. Understand ALL existing features, not just the current one.
+2. **Preserve all confirmed `FP-*`, `BR-*`, `BC-*` from previous features.** Do not delete, renumber, or silently drop them.
+3. Add new feature points with IDs that continue from the last used number (e.g., if last FP is FP-015, new ones start at FP-016).
+4. Update existing feature points only when the new input explicitly changes them. Record the reason in `澄清与变更记录`.
+5. If a feature point is replaced or moved out of scope, mark it as `已废弃` or `已移出范围` rather than silently deleting it.
+6. The baseline must represent the **union** of all features ever baselined — it is the project's single source of truth for requirements.
+7. Do not regenerate from scratch. Start from the existing file and append.
+
+## Feature Name And Directory Rule
+
+Each new requirement gets its own stable `{功能名}`. **This is additive — a new feature does not overwrite the name or directory of previous features.**
+
+1. Prefer an explicit feature name from `$ARGUMENTS`.
+2. Otherwise use the requirement document title or the clearest feature title in the raw requirement.
+3. Keep it short, stable, and safe as a path segment.
+4. Once written to baseline, do not change it in later clarification unless the user explicitly renames the feature.
+5. If the feature name changes, record the old name, new name, reason, and downstream directory impact in `澄清与变更记录`.
+6. The canonical downstream output directory is `.planning/features/{功能名}/`. Multiple features → multiple directories.
+7. Legacy root `features/{功能名}/` may be read as historical evidence only; new workflow outputs must not use it.
+8. When baseline already has features, the new `{功能名}` must be distinct from existing ones unless the user explicitly says it's an iteration on the same feature.
+
+## Pattern
+
+This skill follows the Google Cloud Tech ADK skill pattern split:
+
+- **Inversion**: interview the user only after raw requirements have been decomposed and gaps are known.
+- **Generator**: fill `assets/baseline-template.md`.
+- **Reviewer**: review decomposed requirements against `references/requirement-review-checklist.md`.
+
+Load bundled resources only when needed:
+
+- Read `references/decomposition-guide.md` before decomposing requirements.
+- Read `skill://workflow-pipeline/references/slice-safety-guide.md` before Phase 3.1 and whenever the requirement may be oversized.
+- Read `references/project-context-guide.md` before checking historical impact（含三级递进审查：Call Chain Map 对照 → 源码逻辑侵入 → 需求回洗）.
+- Read `references/challenge-review-guide.md` before challenge review and user decision questions.
+- Read `references/antipatterns.md` before challenge review and final review.
+- Read `references/questioning.md` before asking clarification questions.
+- Read `references/requirement-review-checklist.md` before the review gate.
+- Read `assets/baseline-template.md` before writing `baseline.md`.
+
+## Phase 1 — Context And Requirement Intake
+
+Load available project context:
+
+1. `.planning/PROJECT.md`
+2. `.planning/navigation/INDEX.md`
+3. `.planning/navigation/INDEX.md` for the Codebase Registry — identify which codebases are relevant to the requirement
+4. Load the navigation files (`.planning/navigation/{name}.md`) for each relevant codebase from the registry
+5. If `.planning/code-index/` exists, note that `code-index-query` must be used for Phase 1.5 routing and Phase 4 source-reality checks
+6. `.planning/milestones/`
+7. `.planning/requirements/`
+8. `.planning/lessons/`
+9. `.planning/*/CONTEXT.md`
+
+History model rule:
+
+- This workflow's primary historical artifacts are milestone and planning artifacts, not outbound-call style `features/*.spec.md` files.
+- Use `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and `.planning/*/CONTEXT.md` first.
+- If `features/`, `.context/lessons/`, or `.context/workflow/` exist in the target project, treat them as optional legacy/project-rule evidence and record that distinction.
+
+Then collect this requirement input:
+
+- PRD / feature document
+- pasted requirement text
+- meeting notes
+- user description
+
+If no requirement is provided, ask for it. Do not proceed without raw requirement content.
+
+Completion gate: project context is loaded or explicitly missing, and raw requirement content is available.
+
+## Phase 1.5 — PRD Media And Code Routing Scan
+
+Before structuring requirements or asking clarification questions, ground the input in visible artifacts and current code reality.
+
+### 1.5.1 PRD image processing
+
+If the PRD, pasted requirement, meeting notes, or user message contains image references, process every image before Phase 2:
+
+- Image references include `http://...` / `https://...` image URLs, Markdown images, attached screenshots/designs, and local image paths.
+- Use the available image-capable tools to access and inspect each image.
+- Convert the visible content into text notes: flowcharts, page screenshots, prototypes, tables, field labels, buttons, status names, and any visible constraints.
+- Treat extracted image notes as requirement source material and record them in the source summary.
+- Classify each image by its role:
+  - `critical_image`: nearby text says the image contains the primary flow, page prototype, field list, state machine, or required decision path.
+  - `supporting_image`: the image supplements wording but the requirement is still understandable from text.
+  - `decorative_image`: logo, cover, illustration, or other non-requirement image.
+- If an image cannot be accessed, authenticated, decoded, or read clearly, classify it from nearby text and mark the classification `推断，待确认`.
+- If nearby text does not reveal the image role, default to `supporting_image`, not `critical_image`.
+- A missing `critical_image` blocks a passed baseline until the user describes it or provides an accessible replacement. A missing `supporting_image` may be recorded as non-blocking pending with impact. A `decorative_image` may be skipped with a note.
+
+Use this wording pattern when blocked by an image:
+
+```text
+我尝试查看 PRD 中的图片「{image_ref}」，但无法识别内容（原因：{reason}）。这张图会影响需求理解，请描述图片中的页面/流程/字段，或提供一个可访问的替代链接。
+```
+
+### 1.5.2 需求类型路由
+
+在代码路由扫描之前，先判断当前需求的类型。只做标记，不做分支切换。
+
+根据 WHY 确认后的信息判断需求属于以下哪种（或混合）类型：
+
+| 类型 | 识别特征 | 后续 Phase 策略 |
+|------|---------|----------------|
+| **A. 用户功能** | 有明确的用户、有界面/交互/可感知的输出 | 标准流程 |
+| **B. 技术/平台能力** | 用户感知间接，核心是系统能力（API、算法、基础设施） | 下移界面相关检查，聚焦接口契约 |
+| **C. WHO 模糊** | 连给谁用、解决谁的问题都不确定 | 需要退回 demand-clarify 先澄清用户群 |
+| **D. 系统性改造** | 跨多个模块/触点的整体改动 | Phase 3.5 模块边界检查优先级提升 |
+| **E. 删减/简化** | 目标是减少复杂度而非增加功能 | 略过 Phase 2 需求整理，直接审计现状 |
+
+**混合类型**：一个需求可能同时涉及多种类型（如 A+D 混合）。标记为主类型+副类型（如 `A+D`），后续 Phase 按主类型流程推进，在 Phase 3.5 和 Phase 4 兼顾副类型的检查项。
+
+写入 `.planning/requirements/baseline.meta.json` 的 `requirement_type` 字段。
+
+### 1.5.3 Code routing scan before questions
+
+Before asking the user any clarification question, produce an internal code routing summary from project artifacts:
+
+1. Use `.planning/navigation/INDEX.md` to identify relevant codebases.
+2. Read the relevant navigation files (`.planning/navigation/BACKEND.md`, `.planning/navigation/FRONTEND.md`, or other registered codebase files).
+3. Treat navigation as a routing index only. It helps find files quickly, but it is not sufficient evidence for requirement conclusions.
+4. If `.planning/code-index/` exists, use `code-index-query` with requirement concepts to find candidate routes/pages/services/models/tests/resources. Treat these as routing candidates only.
+5. Confirm likely related source paths exist by listing directories or opening only top-level file structure, imports, class/function names, route declarations, comments, and short module headers.
+6. Do not inspect function bodies, branch logic, data flow, SQL/query details, permission checks, or state transitions in Phase 1.5. Those are Phase 4 Level 2 responsibilities.
+7. Do not conclude "already supported", "not supported", or "conflicting" in Phase 1.5. Only record "possibly related" modules and why they should be checked later.
+8. Record:
+   - possibly related modules, routes, pages, services, models, engines, or jobs
+   - source paths to inspect in Phase 4
+   - code-index symbol/relation ids when used
+   - if code-index exists but is missing, stale, or has no useful hits, record the fallback reason
+   - requirement terms that mapped to those paths
+   - concrete unknowns that require user clarification before decomposition
+
+Do not hard-code Go-style directories such as `internal/domain`, `internal/service`, or `internal/web`. Use the project navigation registry first to find candidate files, then only perform light routing checks here.
+
+Completion gate: all referenced images are summarized, skipped, or explicitly blocked by role; requirement type is classified and recorded; and a code routing summary exists without behavior conclusions.
+
+## Clarification Question Protocol
+
+This protocol applies before any user-facing clarification question in this skill, including early intake questions and Phase 5 review/challenge questions.
+
+- Number questions sequentially as `Q1`, `Q2`, `Q3` within the current requirement discussion.
+- Ask exactly one question at a time. Do not present a questionnaire unless the user explicitly asks for batch questions.
+- Every question must include a short "已发现" context line from source material, code routing scan, or review finding.
+- Ask concrete questions tied to a source section, existing module, or `FP-*`/`BR-*`/`BC-*`/`CR-*` candidate. Do not ask generic checklist questions.
+- If the user answer is ambiguous, ask a follow-up with the same question number plus suffix, e.g. `Q2.1`.
+- Capture the user's priority or attitude when it affects scope: must-have, nice-to-have, later, avoid, risky, or blocked.
+- Do not skip blocking questions. If a missing answer blocks a reliable baseline, ask it before generating a passed baseline.
+
+Clarification questions are not review findings:
+
+- **Clarification question**: fills missing user intent or source ambiguity before or during decomposition.
+- **Review/challenge question**: comes from Phase 4 / Phase 4.5 evidence, must cite the affected `FP-*`, `BR-*`, `BC-*`, `CR-*`, existing module, or artifact conflict.
+
+Question format:
+
+```text
+已发现：{one concise code/source/review finding}
+
+Q{n}: {one concrete question}
+```
+
+## Phase 2 — Requirement Structuring
+
+Read `references/decomposition-guide.md`.
+
+Before asking follow-up questions, restructure the raw requirement into these buckets:
+
+- Background / goal
+- User roles
+- Pages / modules
+- User actions
+- Data fields
+- Business rules
+- Permission rules
+- State changes
+- Exception and boundary cases — **必须包含恶意输入/极端数据/资源耗尽场景**（巨型输入、未来时间戳、非法状态跳转、并发冲突、重入递归）。如果原始需求完全没有提及，在该 bucket 中标注"未覆盖，需下游补充"
+- Non-functional requirements
+- Explicit open questions
+
+Do not add assumptions as facts. Mark inferred items as `推断，待确认`.
+
+Completion gate: raw requirement has been normalized into structured buckets.
+
+## Phase 3 — Feature Point Decomposition
+
+Convert the structured requirement into feature points.
+
+Rules:
+
+- Apply `references/decomposition-guide.md` FP / BR / BC classification before assigning IDs. Mixed requirement sentences must be split into capability (FP), rule (BR), and boundary handling (BC) instead of being stored as one overloaded FP.
+- If baseline already exists, assign IDs that **continue from the last used FP number** (e.g., last existing FP is FP-015 → new ones start at FP-016). Never renumber or reuse old IDs.
+- If this is the first baseline, start from FP-001.
+- One feature point should describe one testable user/business capability.
+- Split mixed descriptions into separate feature points.
+- Merge duplicate wording that describes the same capability.
+- Keep cross-cutting requirements such as permission, export, audit log, notification, compatibility, and data migration as independent feature points when they can be built or tested separately.
+
+Each feature point must include:
+
+- ID
+- Name
+- Source excerpt or source section
+- Type: `新增` / `修改` / `影响`
+- Priority: `P0` / `P1` / `P2`, based on source priority or inferred from user-visible/business criticality
+- Description
+- User role
+- Entry / trigger
+- Precondition
+- Main flow
+- Business rules
+- Data requirements
+- Boundary cases
+- Related existing module
+- Status: `明确` / `待确认` / `推断，待确认`
+- Open questions
+
+Completion gate: all raw requirement content is mapped to feature points or explicitly marked as ignored/out of scope.
+
+## Phase 3.1 — Large Requirement Slice Plan
+
+Read `skill://workflow-pipeline/references/slice-safety-guide.md`.
+
+After FP/BR/BC decomposition and before module-boundary checks, decide whether the current requirement is oversized. Use the guide's oversize triggers: FP count, affected codebases, high-risk chains, migration/runtime scope, contract replacement, projected document length, and reviewability.
+
+If no trigger applies:
+
+- Record `slicing_required = false`.
+- Treat the whole current feature as `SL-001`.
+- Still write a one-row slice plan so downstream artifacts have a stable active slice ID.
+
+If any trigger applies:
+
+- Create a slice plan with `SL-*` IDs.
+- Assign every current FP to exactly one primary slice.
+- Assign BR/BC ownership or references per slice.
+- Define dependencies and gates for each slice.
+- Mark only the first executable slice as the active downstream slice unless the user explicitly asks to plan another slice.
+- Move non-active slice FP/BR/BC to "deferred current-feature slices" for downstream context only.
+- If a reliable slice plan cannot be produced from current information, ask one blocking question or mark baseline review as failed.
+
+Anti-smuggling rule:
+
+- Shared setup may be a foundation slice only if it has its own observable gate. Otherwise it belongs to the first slice that needs it.
+- Do not create "frontend slice" and "backend slice" from one user outcome. Slice by business outcome and chain closure.
+
+Completion gate:
+
+- [ ] Slice plan exists, even if it is a single-slice plan
+- [ ] Active slice ID is identified
+- [ ] Every current FP has exactly one primary slice
+- [ ] Every slice has outcome, dependencies, exclusions, and gate
+- [ ] Deferred slices are not part of the active downstream implementation scope
+- [ ] Coverage conservation passes: every source row maps to FP/BR/BC/Q/OUT/DUP; active + deferred + out-of-scope FP count equals total current-feature FP; every deferred item has reason, dependency, re-entry condition, and gate
+
+## Phase 3.5 — 模块边界检查
+
+目标：在进入审查前预判每个 FP 的模块边界和接口深度，让下游 tech-spec 能直接使用这些信息。
+
+### 对每个新增或修改的 FP 执行以下检查
+
+**1. 预估接口签名**
+
+| FP | 候选接口签名 | 入口数 | 评估 |
+|----|------------|:------:|:----:|
+| FP-001 | OrderWorkflow.process(orderId, action) | 1 | ✅ 单入口 |
+| FP-002 | Order.export() + Order.batchDelete() | 2 | ⚠️ 多入口，考虑聚合 |
+
+如果入口多于 1 个，标记为"浅模块风险"，下游 tech-spec 需关注是否应聚合。
+
+**2. Deletion Test**
+
+假装删掉这个 FP 对应的模块，复杂度去哪了？
+
+- **消失** → 大概率是深模块（复杂度在模块内部，删了就没了）
+- **分散到 N 个调用方** → 可能是浅模块（复杂度分散在各调用者中）
+- **不确定** → 标记为"需下游 tech-spec 评估"
+
+**3. 关联模块标记**
+
+| FP | 关联已有模块 | 交互方式 | 是否新建模块 |
+|----|------------|---------|:-----------:|
+| FP-001 | OrderService | 扩展现有接口 | ❌ 扩展 |
+| FP-003 | 无 | 全新功能 | ✅ 新建 |
+
+### 输出
+
+在 FP 详情中增加两个字段：
+
+```yaml
+seam_type: "新建" | "扩展" | "修改"
+module_depth: "深" | "浅（需下游关注）" | "待评估"
+```
+
+写入 `.planning/requirements/baseline.md` 中每个 FP 的描述末尾。
+
+### 完成门禁
+
+- [ ] 每个新建/修改的 FP 已有 seam_type 标记
+- [ ] 每个新建/修改的 FP 有 module_depth 初步评估
+- [ ] 浅模块或待评估的 FP 已在备注中说明原因，供 Phase 4 审查和下游 tech-spec 使用
+
+## Phase 4 — Requirement Review（三级递进审查）
+
+Read:
+
+- `references/project-context-guide.md`（含三级递进审查方法）
+- `references/requirement-review-checklist.md`
+
+### 4.1 基础审查
+
+Review the decomposed feature points for:
+
+- Missing roles, entries, flows, fields, rules, permissions, boundary cases
+- Frontend/backend/test readiness
+- Ambiguous ownership between frontend and backend
+- **对抗式审查**：逐 FP 检查 BC（边界情况）是否覆盖了以下攻击视角：
+  - 输入攻击：字段有无上限/格式/注入防护定义？
+  - 时序攻击：时间异常（未来/过去/时区错误）是否在边界情况中？
+  - 状态攻击：状态流转是否封闭？有无非法跳转路径？
+  - 并发攻击：是否定义了幂等/去重/锁机制？
+  - 资源攻击：批量/导出/上传是否定义了最大限制？
+  - 依赖攻击：外部服务失败时行为是否已定义？
+  - 如有缺失，标记为 BC-* 待补充，不视为审查通过
+
+### 4.2 三级递进审查（项目历史影响）
+
+按 `project-context-guide.md` 的三级递进方法执行：
+
+**Level 1: 导航 Call Chain Map 对照（结构层）**
+- 对每个涉及已有代码的 FP，从导航文件的 API Modules / Route-Component Map 提取受影响文件清单
+- 若 `.planning/code-index/` 存在，必须通过 `code-index-query` 用需求关键词、API 路径、页面名、字段名、状态名、表/配置/资源名查询 Symbol Index 和 Relation Graph，补充 navigation 未覆盖的调用方、被调用方、入口和数据流候选
+- 调用链重叠类型判断：扩展已有 vs 新建分支
+- 契约影响预判：修改已有接口时检查其他调用方
+- 导航无候选时，先通过 `code-index-query` 查 code-index；仍无候选时，再用需求关键词、API 路径、页面名、字段名、状态名通过 `rg` 查实际源码。navigation 不能作为"无相关代码"的唯一证据
+- **找到候选调用链或既有模块 → 必须进入 Level 2**
+- **仍找不到候选源码路径**：
+  - 若该 FP 是明确全新且无已有模块重叠，记录已搜索范围和"未找到候选路径"，可不做 Level 2
+  - 若该 FP 修改、影响或疑似重叠已有模块，记录 `code_reality_missing`，审查结论不得为 `通过`
+
+**Level 2: 源码逻辑侵入（逻辑层）**
+- 侵入调用链末端源码：读 domain 结构体 / DAO 参数 / service 逻辑 / VO 结构体 / handler 路由
+- 若 Level 1 使用了 code-index，优先读取 relation 的 `evidence_path:evidence_line`，再按源码上下文扩展阅读；不得只凭 Markdown 或 relation 摘要下结论
+- 逐项比差：已存在且一致 / 已存在但冲突 / 不存在
+- 每条比差结论带源码证据（文件路径 + 行号）
+- Source inspection output must use this template only:
+
+```markdown
+- 关联项：FP-xxx / BR-xxx / BC-xxx
+- 源码证据：path:line
+- 当前行为：只描述已读源码中的现状
+- 比差结论：已存在且一致 / 已存在但冲突 / 不存在
+- 需求影响：可复用 / 需要用户确认 / 需下游 tech-spec 评估
+```
+
+- Do not write implementation plans, new API shapes, new fields, DDL, code tasks, class/function changes, or migration steps in Level 2 notes. If such content appears, delete it before continuing.
+- **比差结论为已存在且一致/已存在但冲突 → 进入 Level 3**
+- **比差结论为不存在 → 记录需求缺口和下游 tech-spec 评估点，该 FP 可继续审查**
+
+**Level 3: 需求回洗 + 定向重问**
+- 将比差发现转为定向问题，带源码证据 + 互斥选项
+- 用户回答后更新受影响的 FP/BR/BC/范围项
+- 记录到 `澄清与变更记录`
+- 不得自行选择方案，必须用户拍板
+
+Produce an internal gap list grouped by feature point. Do not generate baseline yet.
+
+Completion gate: every feature point has review status `通过` or has open questions.
+
+## Phase 4.5 — Challenge Review
+
+Read:
+
+- `references/challenge-review-guide.md`
+- `references/antipatterns.md`
+
+Review the decomposed feature points against project reality and simplicity:
+
+0. **Review depth**: choose `light`, `standard`, or `strict` using `references/challenge-review-guide.md`.
+   - `light`: run C1/C2/C4.
+   - `standard`: run C1/C2/C4 plus C5-lite. Use this by default and whenever existing code is modified or overlapped.
+   - `strict`: run C1-C5 full review.
+1. **Current-state conflict**: identify conflicts between requested behavior and current project context.
+2. **Reuse opportunity**: check existing business capability, installed libraries, and project patterns before treating a capability as new.
+3. **Historical lesson and prior work**: search available milestone, requirement, lesson, and project-rule history before claiming there is no precedent.
+4. **Over-engineering candidate**: flag scope that is not explicitly requested, is future-oriented, or is disproportionately expensive.
+5. **Alternative path and do-nothing baseline**: for standard review run C5-lite; for strict review or when C5-lite finds a real alternative, compare the requested path with a simpler path and the baseline of not doing it now.
+
+Rules:
+
+- Tie every challenge item to `FP-*`, `BR-*`, `BC-*`, a scope item, or the downstream contract.
+- Present mutually exclusive options when a user decision changes scope, semantics, ownership, or long-term maintenance.
+- Do not recommend one option unless the user explicitly asks for advice.
+- In interactive mode, ask for a substantive answer when a challenge decision affects scope, semantics, ownership, compatibility, or implementation cost. Do not treat "OK" or vague confirmation as a decision reason.
+- For P0 or expensive feature points, C5 alternative-path review must produce either a user-provided reason, a pending reason, or confirmed hard constraints. It must not be empty.
+- Historical review must name the planning/milestone sources searched. Do not claim "无历史" from memory.
+- Record challenge results under baseline `反向审视与用户拍板`.
+
+Completion gate: every challenge dimension has either a recorded finding or a recorded no-finding statement with evidence searched. Pending challenge decisions that affect scope, semantics, ownership, compatibility, implementation cost, or downstream contracts block a passed baseline until answered.
+
+## Phase 5 — Targeted Clarification
+
+Use `ask` only for gaps or challenge decisions that block development, testing, technical planning, scope control, or downstream contracts.
+
+Question rules:
+
+- Follow `Clarification Question Protocol` for numbering, one-question-at-a-time cadence, code/source context, and ambiguity follow-up.
+- Build a prioritized clarification queue, but ask only one question at a time.
+- Before asking, merge duplicate or related questions so each answer can resolve the widest useful gap.
+- After receiving each answer, review whether it changes any previously structured bucket, feature point, business rule, boundary case, historical impact, scope item, or downstream contract.
+- If the answer changes previous requirements, update the affected items immediately before asking the next question.
+- Record each accepted answer and requirement update in the baseline `澄清与变更记录`.
+- For non-blocking warnings, write pending questions into the baseline instead of interrupting the user.
+- Blocking questions must be answered before a baseline can receive review conclusion `通过`.
+- For challenge decisions, ask the user to choose among concrete options or provide the missing reason/constraint. Do not ask generic "is this ok?" questions.
+
+Do not ask generic checklist questions. Ask questions tied to specific feature point IDs:
+
+```text
+FP-003 导出文件字段和格式：导出字段以列表当前展示字段为准，还是需要额外字段？
+```
+
+If the user cannot answer a blocking question, keep the item in `待确认事项`, mark the baseline review conclusion as not passed, and stop before downstream handoff. If the question is non-blocking, keep it in `待确认事项` and continue with impact clearly recorded.
+
+Completion gate: blocking questions are answered. Non-blocking questions may be recorded as pending with impact and current handling.
+
+## Phase 5.5 — Answer Impact Review
+
+After every user answer in Phase 5:
+
+1. Classify the answer as confirmation, correction, new requirement, scope reduction, scope expansion, or contradiction.
+2. Re-check affected previous content, including structured buckets, feature points, rules, boundary cases, historical impact, scope control, and downstream read contract.
+3. Update affected feature points in place while preserving stable IDs. Create a new feature point only when the answer introduces an independently testable capability.
+4. If an answer invalidates a previous feature point or rule, mark the old item as changed or out of scope instead of silently deleting it.
+5. Re-run the requirement review for affected items before asking the next question.
+6. Record what changed, why it changed, and which answer caused it in `澄清与变更记录`.
+
+## Phase 6 — Generate Baseline
+
+**叠加模式（baseline 已存在）**：
+
+1. Read existing `.planning/requirements/baseline.md` as the base.
+2. Append new feature points after the existing ones. Keep all old FP-*, BR-*, BC-* intact.
+3. Update `需求来源` to add the new source entry.
+4. Update `当前功能切片` to list only the current feature's FP/BR/BC IDs, active `SL-*`, deferred slices, and any `depends_on` historical references.
+5. Add new entries to `原始需求追溯表` for the new feature only.
+6. Append to `业务规则` and `边界情况` only if the new feature introduces rules/cases not already covered.
+7. Update `与历史功能/里程碑的关联` to note the new feature's impact on existing modules.
+8. Update `代码现实对照` with source-backed current behavior and difference conclusions for the current feature.
+9. Append to `澄清与变更记录` with the new session's changes.
+10. Update `下游输入契约` to include the new feature's frontend/backend/test contracts and active slice constraints.
+11. Keep the `{功能名}` section for the **current** feature, but preserve all prior features' data.
+
+**新建模式（baseline 不存在）**：
+
+Read `assets/baseline-template.md`.
+
+Generate `.planning/requirements/baseline.md` with:
+
+- Requirement source summary
+- Feature name and canonical output directory, using one stable `{功能名}` for all downstream `.planning/features/{功能名}/...` outputs
+- Structured requirement summary
+- Current feature slice with current FP/BR/BC IDs
+- Slice plan with active `SL-*`, deferred slices, dependencies, and gates
+- Cross-feature `depends_on` references for historical FP/BR/BC needed by the current feature
+- Raw requirement traceability table
+- Feature point list
+- Per-feature-point details
+- Business rules
+- Boundary cases
+- Historical impact
+- Code reality comparison table with source-backed current behavior and difference conclusions
+- Challenge review results and user decisions
+- Frontend/backend/test input contract (功能点梳理为上游，测试指导书为可选下游)
+- Pending questions
+- Clarification and change log
+- Review result
+
+Create `.planning/requirements/` if needed.
+
+Do not create synonym duplicate sections such as `需求来源汇总` or `历史影响` when the template section is named `需求来源` or `与历史功能/里程碑的关联`.
+
+Write `.planning/requirements/baseline.meta.json` with the fields required by the workflow YAML. `review_status` must be `passed` only when the baseline review conclusion is `通过`; otherwise use `failed`. Count blocking items explicitly:
+
+- `blocking_pending_count`: unanswered clarification items that block reliable baseline or downstream handoff
+- `critical_image_missing_count`: missing or unclear `critical_image` items
+- `challenge_pending_count`: unanswered CR decisions affecting scope, semantics, ownership, compatibility, implementation cost, or downstream contracts
+- `code_reality_missing_count`: required code reality comparisons that were not completed
+
+Completion gate: baseline and baseline.meta.json are written and contain no unresolved template placeholders. If updating an existing baseline, ALL prior feature points are still present.
+
+## Phase 7 — Final Review Gate (MANDATORY — do not skip)
+
+**审查方法论来自 spec-writer 的"苏格拉底式反问 + 反向对照"模式。必须逐条执行，不得跳过。**
+
+### 7.1 反问审查（苏格拉底式）
+
+对每个 FP 问自己三个问题，发现缺失时回 Phase 5 向用户定向提问：
+
+- **WHY 确认**：这个 FP 要解决的业务问题是否已说清？用户的目标和优先级是否已确认？
+- **WHAT 确认**：功能边界是否清晰？必做 vs 可后做已区分？
+- **边界确认**：异常/空数据/并发/权限边界是否已覆盖或标记待确认？
+
+### 7.1.5 跨层一致性检查
+
+不在反问审查里各层单独问，而是查**层与层之间的一致性**。不要在 Phase 7 为了查这个问题去问用户——Phase 7 只做检查不做追问，缺口记录到审查结论。每个 FP 检查以下四个维度：
+
+| 层 | 检查 | 一致性要求 |
+|----|------|-----------|
+| WHY ↔ WHAT | WHY 的问题陈述中列出的痛点，在 WHAT 里是否都有对应的 FP 去解决？ | 无遗漏，无无关 FP |
+| WHAT ↔ HOW | WHAT 里的每个 FP，HOW 里是否有对应实现逻辑？ | 100% 覆盖 |
+| WHAT ↔ 衡量 | WHAT 里的每个核心 FP，衡量指标能否验证其效果？ | 痛点→FP→指标一条线 |
+| HOW ↔ 衡量 | HOW 的实现输出是否能被衡量指标采集到数据？ | 可观测，有埋点或日志 |
+
+如果发现缺口，记录在审查结论中，不追问用户（Phase 7 只检查，缺口留到 Phase 5 或下一轮）。
+
+### 7.2 对抗式审查（需求级）
+
+**逐 FP 从攻击者视角审视：不检查代码是否正确，而是检查需求本身是否定义了防御。**
+
+对每个 FP 追问：
+
+| 攻击视角 | 检查问题 | 缺失时的处理 |
+|---------|---------|------------|
+| 输入攻击 | 接受用户/外部输入的字段是否有上限/格式校验定义？ | 标记 BC-* 待补充 |
+| 时序攻击 | 依赖时间戳排序/过滤的逻辑是否覆盖了未来/过期时间？ | 标记 BC-* 待补充 |
+| 状态攻击 | 状态流转规则是否封闭？能否从非相邻状态直接跳转？ | 标记 BR-* 待补充 |
+| 并发攻击 | 写入操作是否定义了幂等/去重规则？ | 标记 BR-* 待补充 |
+| 资源攻击 | 批量操作/文件上传/导出是否定义了资源上限？ | 标记 BC-* 待补充 |
+| 依赖攻击 | 外部服务调用失败/超时/返回异常格式时，需求中行为定义了吗？ | 标记 BC-* 待补充 |
+
+审查结论：如果某个 FP 在 3 个以上攻击视角缺失 BC/BR 定义，该 FP 的审查结论不得为"通过"。
+
+### 7.3 反向对照审查（代码库对照）
+
+复用 Phase 4 的三级递进审查结果，逐 FP 复验：
+
+| 嗅探 | 检查 | 数据来源 |
+|------|------|---------|
+| 复用嗅探 | 现有模块/接口/组件是否已经做了类似的事？ | Phase 4 Level 2 源码比差结果 |
+| 冲突嗅探 | 命名、流程、数据模型是否与现有约定矛盾？ | Phase 4 Level 1 调用链契约分析 + Level 2 源码比差 |
+| 重叠嗅探 | 是否会与某个已有功能形成"两套并存"？ | Phase 4 Level 1 调用链重叠类型 |
+| 历史嗅探 | 是否有类似功能曾被做过、废弃过、或刻意回避过？ | Phase 4 Level 2 源码检查 + milestones/lessons 搜索 |
+
+发现冲突时，必须列出互斥选项 + 代价，让用户拍板。禁止自行选择。
+
+**如果 Phase 4 未做 Level 2 源码侵入**，Phase 7 需要补做：对每个涉及已有模块的 FP，侵入调用链末端源码做比差后再下审查结论。
+
+### 7.4 产物完整性检查
+
+```markdown
+- [ ] 每个原始需求映射到 FP-*/BR-*/BC-* 或 out-of-scope
+- [ ] 追溯表完整，来源→FP 映射可验证
+- [ ] 分片覆盖守恒：原始条目、FP/BR/BC、active/deferred/out-of-scope 计数可对齐，无消失项
+- [ ] 每个 FP 有 ID/描述/流程/规则/边界/类型/优先级/状态
+- [ ] 当前功能切片只包含本轮 FP/BR/BC，并列出必要的 `depends_on` 历史依赖
+- [ ] 切片计划存在，当前 active slice 明确，后置 slice 未进入本轮下游实现范围
+- [ ] 代码现实对照只包含源码现状、比差结论和需求影响，不含实现方案
+- [ ] Challenge Review 结果已记录，待确认项绑定到 FP-ID
+- [ ] 不存在阻塞待确认、缺失 critical 图片、或影响范围/契约但未拍板的 CR 决策
+- [ ] 所有 FP 已通过 7.2 对抗式审查 — 每个 FP 在 3 个或更少的攻击视角缺失 BC/BR
+- [ ] 下游契约（前端/后端/测试）已就绪
+- [ ] 不含技术方案、DDL、代码任务
+```
+
+### 7.5 审查结论
+
+在 baseline.md 末尾写入审查结论（通过 / 不通过 + 未通过项）。
+
+审查结论必须为 `不通过` when:
+
+- Any blocking clarification question remains unanswered.
+- A `critical_image` is missing or unclear.
+- A Challenge Review decision affects scope, semantics, ownership, compatibility, implementation cost, or downstream contracts and is not answered.
+- Code reality comparison required for an existing-module impact was not completed.
+- Coverage conservation fails: any source row, FP, BR, BC, deferred item, or out-of-scope item lacks an explicit disposition.
+
+**Do not report "Step 2 complete" to the pipeline until 审查结论 = 通过.**