@guanlin4924/devflow-pi 0.1.0

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

@@ -0,0 +1,119 @@
+# 项目历史分析指引
+
+## 加载顺序
+
+1. `.planning/PROJECT.md` — 项目上下文和已上线能力
+2. `.planning/navigation/INDEX.md` — 代码库注册表（Codebase Registry），从中识别与需求相关的代码库
+3. `.planning/navigation/{name}.md` — 加载 INDEX.md 中标识的相关代码库的导航文件
+4. `.planning/milestones/` — 归档的里程碑记录，是本工作流的主要历史口径
+5. `.planning/requirements/` — 已确认或历史需求基线
+6. `.planning/lessons/` — 跨里程碑经验教训
+7. `.planning/*/CONTEXT.md` — 之前阶段的决策记录
+8. `features/`、`.context/lessons/`、`.context/workflow/` — 仅当目标项目存在时作为兼容历史或项目规则来源，不作为默认历史口径
+
+## 对比分析要点
+
+### 入口分诊证据复用
+
+- 如果 `.planning/requirements/{功能名}/入口分诊.md` 存在，先读取其中的"已实现/重叠检查"和"历史拒绝/范围检查"。
+- 分诊结果只能作为 Phase 4/4.5 的优先证据入口，不能替代源码比差。
+- 当分诊结论为 `already_done`、`wontfix` 或 `ready_for_human` 时，baseline 不应继续生成通过状态，除非用户明确改变范围或推翻历史决策。
+- 分诊已搜索的来源必须并入 baseline 的搜索来源记录，避免重复声明"未发现历史"。
+
+### 功能重叠检测
+- 本次需求功能是否已存在于 milestones 中？
+- 是修改还是全新功能？
+- 历史功能中有无类似的流程可复用？
+
+### 影响分析
+- 本次需求会修改哪些历史功能的流程？
+- 影响的范围是什么（字段变更/逻辑调整/接口修改）？
+- 是否需要兼容旧数据？
+
+### 遗漏检测
+- 历史功能中是否有本次需求需要配套的场景？
+  - 例如：新增 XX 管理 → 是否需要在日志/权限/通知中体现？
+  - 例如：新增 XX 页面 → 是否需要考虑菜单/路由/权限配置？
+- 项目导航中是否存在相关前端页面、组件、后端模块、服务、模型或接口？
+- 本次需求是否影响导航中记录的入口、命令、组件约定或分层约定？
+
+### 历史口径映射
+
+- outbound-call 中的 `features/*.spec.md` 对应本工作流里的 `.planning/milestones/`、`.planning/requirements/baseline.md` 和阶段 `CONTEXT.md`。
+- outbound-call 中的 `.context/lessons/README.md` 对应本工作流里的 `.planning/lessons/README.md`；如果目标项目同时存在 `.context/lessons/`，将其标为项目规则/遗留经验来源。
+- 输出时必须写清楚实际搜索了哪些目录或文件，不能只写"未发现历史"。
+
+## 三级递进审查
+
+项目历史分析不是一次性检查，而是三级递进。每一级无发现时进入下一级，有发现时触发需求回洗。
+
+### Level 1: 导航 Call Chain Map 对照（结构层）
+
+**输入**：FP + 导航文件的 API Modules / Route-Component Map / Data Flow 表
+
+**操作**：
+1. 对每个涉及已有代码的 FP，从导航 Call Chain Map 中提取受影响的文件清单：
+   - 前端：受影响的路由、页面组件、composable、API 模块
+   - 后端：受影响的 handler、service、repository、DAO
+2. 判断调用链重叠类型：在现有调用链上扩展（修改已有方法） vs 新建独立调用链
+3. 契约影响预判：如果修改已有查询参数、接口签名、响应结构或组件输入，检查 Call Chain Map 中是否有其他调用方
+4. 如果 navigation 没有候选路径，必须用需求关键词、API 路径、页面名、字段名、状态名通过 `rg` 查实际源码。navigation 只能引导查找，不能单独证明"无相关代码"。
+
+**输出**：每个 FP 的受影响文件清单 + 调用链重叠类型
+
+- **找到候选调用链或既有模块** → 必须进入 Level 2
+- **仍找不到候选源码路径，且 FP 是明确全新、无既有模块重叠** → 记录搜索范围和"未找到候选路径"，可跳过 Level 2
+- **仍找不到候选源码路径，但 FP 是修改、影响或疑似重叠已有模块** → 记录 `code_reality_missing`，不得审查通过
+
+### Level 2: 源码逻辑侵入（逻辑层）
+
+**触发条件**：Level 1 找到候选调用链、既有模块、相似接口、相似页面、相似服务、相似模型，或当前 FP 声称要修改/影响已有能力。
+
+**操作**：侵入到调用链末端的源码，逐项比差：
+1. 读 model/domain/schema → 需求字段是否已存在？
+2. 读 DAO/repository/query → 筛选条件是否已支持？
+3. 读 service/engine/job → 校验/计算/状态机/异步规则是否已有？
+4. 读 response/view model/type → 前端是否已经拿到相关数据？
+5. 读 router/handler/API module → 是否有类似接口可以复用？
+
+**比差结果分三类**：
+
+| 结果 | 含义 | 后续动作 |
+|------|------|---------|
+| 已存在且一致 | 代码已有此能力 | 触发 Level 3：范围是否可缩小？ |
+| 已存在但冲突 | 命名/类型/逻辑不一致 | 触发 Level 3：修改现有还是新建？兼容性？ |
+| 不存在 | 确认是全新能力缺口 | 记录需求缺口和下游 tech-spec 评估点，进入下一 FP |
+
+**没有足够源码证据完成比差时** → 记录 `code_reality_missing`，不得审查通过
+
+### Level 3: 需求回洗 + 定向重问
+
+**触发条件**：Level 2 发现"已存在且一致"或"已存在但冲突"
+
+**操作**：
+1. 将 Level 2 的比差结果转换为定向问题，每条问题带源码证据（文件路径 + 行号 + 当前逻辑）
+2. 重新审视原始需求：用户是否知道现状？知道后是否调整范围？
+3. 更新受影响的 FP、BR、BC，记录到 `澄清与变更记录`
+
+**问题格式**：
+```
+FP-005 涉及 user_dao.go:36 的 GetUserListParam 已有 CooperationTypes 筛选字段。
+需求提到的"新增合作类型筛选"是直接用这个字段、还是要新增不同的筛选维度？
+```
+
+**规则**：
+- 每个比差发现必须绑定到具体 FP-ID
+- 问题必须带源码证据，不能泛泛问
+- 用户回答后立即更新受影响的 FP/BR/BC/范围项
+- 不得自行选择方案
+
+---
+
+## 输出要求
+
+每次分析后，在 baseline.md 中明确记录：
+- 与历史功能的关联关系（新增/修改/影响）
+- 兼容性要求
+- 关联到的项目导航文件和模块路径
+- **三级递进审查结果**：Level 1 受影响的调用链文件清单、Level 2 源码比差结论、Level 3 回洗决策
+- 已搜索的里程碑、需求基线、lesson 或 legacy history 来源

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

@@ -0,0 +1,76 @@
+# 需求澄清提问指南
+
+## 核心理念
+
+你是思考伙伴，不是面试官。帮助用户发现和表达他们真正需要的功能。
+
+## 提问前置条件
+
+不要一接收需求就泛泛提问。
+
+先完成最低限度的事实准备：
+
+1. 已读取项目上下文和 navigation registry
+2. 已处理 PRD 中可见图片；无法识别的图片已按 `critical_image` / `supporting_image` / `decorative_image` 分类并说明原因。无法判断用途时默认 `supporting_image` 且标 `推断，待确认`
+3. 已根据 navigation registry 做轻量代码路由扫描；navigation 只作为文件索引，不能作为行为结论的唯一依据
+4. 已形成代码路由摘要：可能相关模块、候选源码路径、映射到这些路径的需求词、需要 Phase 4 深查的问题
+5. 已将问题绑定到来源、现有模块、候选 FP/BR/BC/CR，或图片阻塞点
+
+如果只读了 `.planning/navigation/*.md` 或只做了 Phase 1.5 轻量路由扫描，不得声称“当前系统已支持/不支持某能力”。只能说“可能相关”，并在 Phase 4 Level 2 下钻源码后再产出行为结论。
+
+在 Phase 2 之前，只允许问会阻塞需求理解的输入澄清问题，例如 `critical_image` 无法识别、核心业务目标缺失、需求明显指向多个现有模块但无法判断边界。
+
+Phase 5 的 Review/Challenge 提问必须围绕具体 FP/BR/BC/CR 或已有模块证据。
+
+## 提问节奏
+
+- 先生成按优先级排序的问题队列，但每次只问一个问题。
+- 每个问题按 `Q1`、`Q2`、`Q3` 编号；歧义追问使用 `Q2.1` 这类后缀。
+- 每个问题前加一行 `已发现：...`，说明来自源码、需求来源或审查发现的具体依据；不要只引用 navigation 摘要作为行为事实。
+- 先合并同类问题，再提问，确保一个回答尽量解决一个明确缺口。
+- 获取用户回答后，先复查该回答是否影响之前已整理的需求、功能点、业务规则、边界场景、范围控制或下游契约。
+- 如果回答影响之前内容，先更新对应需求项并记录变更，再继续问下一个问题。
+- 非阻塞问题写入待确认事项，不打断用户。
+- 阻塞问题必须提问并获得答案；不能仅写入待确认事项后继续标记基线通过。
+
+## 回答后复查
+
+每个回答都要分类：
+
+- 确认原需求
+- 修正原需求
+- 新增需求
+- 缩小范围
+- 扩大范围
+- 与之前内容冲突
+
+如果是修正、新增、缩小、扩大或冲突，必须更新受影响的 FP/BR/BC/范围项。不要只把回答追加到待确认事项。
+
+## 提问类型
+
+### 理解需求
+- "已发现：当前后台已有 `ProjectService` 和项目列表入口，但需求未说明使用者范围。\n\nQ1: FP-001 的主要使用者是哪个角色？"
+- "已发现：现有执行记录只保留运行结果，需求提到留痕但未说明业务目的。\n\nQ2: FP-002 解决的业务问题是减少人工处理，还是补齐数据留痕？"
+
+### 深入细节
+- "已发现：需求中的 X 在现有模块里没有同名字段或枚举。\n\nQ3: FP-003 中提到的 X 具体是指什么？能举个例子吗？"
+- "已发现：当前相关接口只返回成功状态，未看到失败状态映射。\n\nQ4: FP-004 的成功和失败情况分别怎么处理？"
+- "已发现：现有列表仅展示名称和状态，需求提到导出但没有字段清单。\n\nQ5: FP-005 涉及哪些展示、存储、筛选或导出字段？"
+
+### 边界场景
+- "已发现：现有页面对空数据使用 Ant Design Empty，但该需求未说明文案。\n\nQ6: FP-006 数据为空时应该展示什么？"
+- "已发现：当前相关接口失败会展示通用错误提示，需求未说明是否允许重试。\n\nQ7: FP-006 接口超时或失败时用户看到什么？是否允许重试？"
+- "已发现：现有服务没有频率限制或幂等记录。\n\nQ8: FP-007 操作频率有没有限制？"
+- "已发现：当前权限不足的入口处理方式在不同页面不一致。\n\nQ9: FP-008 权限不足时隐藏入口还是展示无权限提示？"
+
+### 历史对比
+- "已发现：现有 XX 模块已有相似流程，但入口和数据范围不同。\n\nQ10: FP-009 跟现有 XX 模块是什么关系？"
+- "已发现：需求描述既像新增入口，也像扩展现有功能。\n\nQ11: FP-009 是修改现有功能还是全新添加？"
+- "已发现：现有表中已有历史记录，需求未说明迁移或兼容策略。\n\nQ12: FP-010 是否需要兼容旧数据？"
+
+## 回避行为
+- ❌ 按照清单机械提问
+- ❌ 使用"利益相关者""成功标准"等术语
+- ❌ 匆匆提问跳到输出
+- ❌ 接受模糊答案不追问
+- ❌ 没有功能点 ID 的泛泛提问

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

@@ -0,0 +1,115 @@
+# Requirement Review Checklist
+
+Use this checklist after feature point decomposition and before writing the baseline.
+
+## Severity
+
+- `blocker`: cannot produce a reliable baseline without clarification
+- `warning`: baseline can proceed but downstream technical docs may need follow-up
+- `info`: useful improvement, not blocking
+
+## Checklist
+
+### Coverage
+
+- Every raw requirement maps to a feature point, rule, boundary case, out-of-scope item, or pending question.
+- The baseline includes a raw requirement traceability table.
+- The baseline includes a current feature slice listing only this round's FP/BR/BC IDs.
+- Cross-feature dependencies are listed in `depends_on` when current scope relies on historical FP/BR/BC behavior.
+- Feature point IDs are stable and unique.
+- Feature points include type and priority.
+- Duplicates are merged.
+- Mixed requirements are split.
+- Every feature point, business rule, boundary case, dependency, and pending question has a source reference or is explicitly marked `推断，待确认`.
+
+### Clarity
+
+- Each feature point has a clear actor, entry, action, expected result, and status.
+- Inferred items are marked `推断，待确认`.
+- Pending questions are concrete and tied to feature point IDs.
+- Clarification answers are applied to affected existing items before new questions are asked.
+- Requirement changes caused by clarification are recorded in `澄清与变更记录`.
+
+### Business Rules
+
+- Required fields, validation, calculation, status, eligibility, and limits are recorded.
+- Historical data handling is recorded when data structure or status changes.
+- Import/export fields and formats are explicit when import/export appears.
+
+### Boundary Cases
+
+- Empty data
+- Invalid input
+- Duplicate operation
+- Permission denied
+- Interface timeout/failure
+- Partial success/failure
+- Large data volume
+- Old data compatibility
+
+### Project Impact（三级递进审查）
+
+#### Level 1: 导航 Call Chain Map 对照（结构层）
+
+- [ ] 每个涉及已有代码的 FP，已从导航 Call Chain Map 提取受影响的文件清单：
+  - 前端：受影响的路由、页面组件、composable、API 模块
+  - 后端：受影响的 handler、service、repository、DAO
+- [ ] 如果 `.planning/code-index/` 存在，已通过 `code-index-query` 查询需求关键词、API 路径、页面名、字段名、状态名、表/配置/资源名，并记录使用到的 symbol/relation id
+- [ ] 调用链重叠类型已判断：扩展已有调用链 vs 新建独立调用链
+- [ ] 契约影响已预判：修改已有接口/参数时，已检查 Call Chain Map 中的其他调用方
+- [ ] 受影响的调用链文件、路由、API 路径已写回 FP 的"关联已有模块"
+- [ ] 如果 code-index 缺失、过期或无有效命中，已记录 fallback 原因和实际搜索范围
+
+#### Level 2: 源码逻辑侵入（逻辑层）
+
+Level 1 无明显冲突时启动；Level 1 有发现的 FP 必须过 Level 2。
+
+- [ ] 对每个关联到已有调用链的 FP，已读源码做比差：
+  - model/domain/schema → 字段是否已存在
+  - DAO/repository/query → 筛选/排序是否已支持
+  - service/engine/job → 校验/计算/状态机/异步逻辑是否已有
+  - response/view model/type → 前端数据是否已拿到
+  - router/handler/API module → 是否有类似接口可复用
+- [ ] 比差结果已分类：已存在且一致 / 已存在但冲突 / 不存在
+- [ ] 比差结论已记录，每条带源码证据（文件路径 + 行号 + 当前行为）
+- [ ] 使用 code-index relation 的结论，已回读 `evidence_path:evidence_line` 附近源码；未仅凭 Markdown 或 relation 摘要下结论
+- [ ] 代码现实对照表只包含源码现状、比差结论、需求影响，不包含实现方案、DDL、API 设计、字段设计或代码任务
+
+#### Level 3: 需求回洗
+
+Level 2 发现"已存在且一致"或"已存在但冲突"时启动。
+
+- [ ] 比差发现已转为定向问题，每条带源码证据 + 具体选项
+- [ ] 用户回答后，受影响的 FP/BR/BC/范围项已更新
+- [ ] 回洗结果已记录到 `澄清与变更记录`
+
+#### 通用
+
+- Historical feature overlap is classified as new, modify, replace, or affect.
+- Compatibility requirements are recorded.
+- Reuse opportunities are checked across business capability, installed library, and project pattern layers.
+- Historical lessons or prior work are searched using the workflow history model first: `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and `.planning/*/CONTEXT.md`.
+- Legacy history such as `features/` or `.context/lessons/` is used only when present and is labeled as legacy/project-rule evidence.
+- The searched sources are recorded before claiming no related history.
+
+### Challenge Review
+
+- Over-engineering candidates are recorded or explicitly marked as not found.
+- Important or expensive feature points include alternative-path rationale or a recorded pending decision.
+- When alternatives are ruled out, the hard constraints and their source are recorded.
+- User decisions are recorded for scope, reuse, priority, and alternative-path choices.
+- Vague confirmations are not treated as decision rationale when a scope, reuse, priority, or alternative-path decision needs a reason.
+- Challenge results appear in `反向审视与用户拍板`.
+
+### Downstream Readiness
+
+- One canonical feature name and `.planning/features/{功能名}/` output directory are defined.
+- Current feature slice and `depends_on` are sufficient for downstream skills to load current scope plus required historical context.
+- Frontend has enough information to identify pages, interactions, states, and API dependencies.
+- Backend has enough information to identify data, services, interfaces, rules, and risks.
+- Test has enough information to write acceptance cases.
+
+### Scope Control
+
+- Out-of-scope items are explicit.
+- No implementation plan, code task, database DDL, or roadmap is included.

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

@@ -0,0 +1,204 @@
+---
+name: workflow-requirement-triage
+description: "Use as the lightweight first step for a new request, bug report, PRD, or feature idea. Classify the request, check shallow duplicate and prior out-of-scope/rejected decisions, then route a viable request into workflow-wayfinder; do not perform deep requirement validation or route directly to baseline."
+---
+
+# Workflow: Requirement Triage（需求入口分诊）
+
+在需求主链开始时，只判断：这个需求是否应该继续、是否已经实现、是否曾被拒绝。正常需求一律进入 `workflow-wayfinder`，由后续领域建模和可实现性审查决定是否可进入基线。
+
+## Outputs
+
+Always create or update:
+
+- `.planning/requirements/{功能名}/入口分诊.md`
+- `.planning/requirements/{功能名}/入口分诊.meta.json`
+
+`入口分诊.meta.json` minimum fields:
+
+```json
+{
+  "feature_name": "",
+  "status": "checked | routed | blocked | superseded",
+  "request_type": "bug | enhancement | change | refactor | research | unknown",
+  "route": "ready_for_wayfinder | needs_info | ready_for_human | already_done | wontfix",
+  "route_reason": "",
+  "duplicate_count": 0,
+  "prior_rejection_count": 0,
+  "blocking_question": "",
+  "next_skill": "workflow-requirement-baseline | workflow-demand-clarify | workflow-wayfinder | none",
+  "searched_sources": [],
+  "related_code_paths": [],
+  "related_history_paths": []
+}
+```
+
+## State Machine
+
+Triage is a hard entry gate. It may be marked complete in the orchestrator only when:
+
+- `status = routed`
+- `route = ready_for_wayfinder`
+
+Other routes stop normal workflow advancement until the requested human answer, clarification, wayfinding, or explicit override changes the route.
+
+Allowed states:
+
+| status | Meaning | May advance to baseline |
+|--------|---------|-------------------------|
+| `checked` | Triage report was written, but route has not been accepted or is still being evaluated | No |
+| `routed` | Route is accepted and next step is known | Yes, only when route is `ready_for_wayfinder` |
+| `blocked` | A missing answer or external action blocks route selection | No |
+| `superseded` | A newer triage report or user override replaced this one | No |
+
+Route handling:
+
+| route | Required behavior |
+|-------|-------------------|
+| `ready_for_wayfinder` | Set `status=routed`, `next_skill=workflow-wayfinder`, then the workflow may complete this step. |
+| `needs_info` | Set `status=blocked`, write exactly one `blocking_question`. |
+| `ready_for_human` | Set `status=blocked`, report why the request cannot be agent-routed. |
+| `already_done` | Set `status=blocked`, point to existing capability evidence; baseline only continues if the user reframes this as a change. |
+| `wontfix` | Set `status=blocked`, point to prior rejection/out-of-scope evidence; baseline only continues if the user explicitly reverses it. |
+
+If the user overrides a blocked route, update the same meta file with the override reason. Do not leave two active triage conclusions for one feature.
+
+Prefer deterministic route updates:
+
+```bash
+devflow_skill_script(script="orchestrator-update-triage", args=["--feature", "{功能名}", "--route", "ready_for_wayfinder", "--reason", "{reason}", "--write", "--json"])
+```
+
+## Phase 1 — Intake And Naming
+
+1. Parse the user's request, PRD, meeting note, issue text, or pasted description.
+2. Pick a short stable `{功能名}` path segment. If no reliable name can be inferred, use the clearest noun phrase and mark it `推断，待确认`.
+3. Classify request type:
+   - `bug`: observed behavior differs from expected behavior.
+   - `enhancement`: new user/business capability.
+   - `change`: adjustment to an existing capability.
+   - `refactor`: internal simplification or architecture change with no intended external behavior change.
+   - `research`: only asks for investigation or decision support.
+   - `unknown`: insufficient input.
+
+If the input lacks actor, desired outcome, or concrete change, do not ask a long questionnaire. Record the gap and route to `needs_info` only when the topic itself cannot be understood; otherwise let Wayfinder create the appropriate Grilling ticket.
+
+## Phase 2 — Existing Capability Check
+
+Search by domain concept, not just exact words.
+
+Required sources:
+
+1. `.planning/requirements/baseline.md`
+2. `.planning/features/`
+3. `.planning/milestones/`
+4. `.planning/lessons/`
+5. `.planning/*/CONTEXT.md`
+6. `.planning/navigation/INDEX.md` and relevant navigation files
+7. `code-index-query` against `.planning/code-index/` when present, for shallow symbol/entrypoint/resource candidate lookup
+8. Actual source files only enough to confirm whether a likely capability exists
+
+Search strategy:
+
+- Extract 3-8 domain concepts from the request: object names, statuses, actions, roles, reports, APIs, pages, scheduled jobs, fields.
+- For each concept, search Chinese terms, known synonyms, route/API names, table/model names, and status names.
+- If code-index exists, use `code-index-query` to search symbols/relations first and treat results as shallow candidates only.
+- If navigation points to likely source paths, open concise entry points and line ranges sufficient to establish current behavior.
+- Record every searched source. Do not claim "未发现" from memory.
+
+Depth limit:
+
+- Read names, routes, menu entries, API declarations, models, enum/status constants, comments, and short surrounding line ranges.
+- Do not perform full call-chain analysis, SQL/data-flow comparison, permission proof, or business-rule diff here. Those belong to `workflow-requirement-baseline` Phase 4.
+- If confirming current behavior would require deep inspection, record `需 baseline 源码比差` and route based on the shallow evidence.
+
+Result categories:
+
+| Category | Meaning | Route |
+|----------|---------|-------|
+| 已实现且一致 | Current behavior already satisfies the request | `already_done` |
+| 已实现但用户可能不知道 | Capability exists but may be hidden, permission-limited, or named differently | `ready_for_human` |
+| 部分重叠 | Existing behavior covers part of request | `ready_for_baseline` with reuse note |
+| 冲突 | Existing behavior contradicts requested behavior | `ready_for_baseline` with conflict note |
+| 未发现 | No reliable overlap after searched sources | Continue triage |
+
+## Phase 3 — Prior Rejection / Out-Of-Scope Check
+
+Search for prior decisions that intentionally avoided this request.
+
+Required sources:
+
+- `.planning/requirements/baseline.md`
+- `.planning/features/**/需求梳理.md`
+- `.planning/features/**/需求澄清记录.md`
+- `.planning/features/**/PROGRESS.md`
+- `.planning/milestones/`
+- `.planning/lessons/`
+- `.planning/*/CONTEXT.md`
+- `.out-of-scope/` if present
+
+Treat these as prior rejection signals:
+
+- `wontfix`
+- `out of scope` / `移出范围` / `暂不做` / `不做`
+- `废弃`
+- `后续再说` when the current request repeats the same reason
+- historical decision that chose the opposite business rule
+
+If found, route:
+
+- `wontfix` when the current request exactly repeats a still-valid rejection.
+- `ready_for_human` when the user may intentionally be reversing a prior decision.
+- `ready_for_baseline` when the prior decision is related but not blocking; record it as context.
+
+## Phase 4 — Scale And Fog Routing
+
+For every viable new or changed requirement, route to `workflow-wayfinder`. Do not decide that a request is “ready for baseline” here. Wayfinder owns fog/ticket decomposition; domain modeling owns terms and ownership; feasibility review owns the baseline gate. A focused clarification question may occur later as a Wayfinder Grilling ticket.
+
+## Phase 5 — Write Triage Report
+
+`入口分诊.md` structure:
+
+```markdown
+# 入口分诊：{功能名}
+
+## 原始输入
+{source summary}
+
+## 分类
+- 类型：{request_type}
+- 推荐路由：{route}
+- 下一技能：{next_skill}
+
+## 已实现/重叠检查
+| 概念 | 搜索范围 | 发现 | 证据 | 结论 |
+|------|----------|------|------|------|
+
+## 历史拒绝/范围检查
+| 关键词 | 搜索范围 | 历史记录 | 影响 |
+|--------|----------|----------|------|
+
+## 路由理由
+{why this route is chosen}
+
+## 待用户确认
+{only blocking or decision-changing questions}
+```
+
+## User Question Rule
+
+Ask at most one question, only when route cannot be decided without it. If the next reasonable step is clear, do not ask; write the route and proceed.
+
+## Completion Rule
+
+Only tell `workflow-orchestrator` to complete `requirement-triage` after writing:
+
+```json
+{
+  "status": "routed",
+  "route": "ready_for_wayfinder",
+  "next_skill": "workflow-wayfinder"
+}
+```
+
+For every other route, stop after writing the report and explain the next action.