@guanlin4924/devflow-pi 0.1.0

package/plugins/devflow-design/skills/workflow-feature-breakdown/assets/output-template.md

@@ -0,0 +1,139 @@
+# 功能点梳理：{{功能名称}}
+
+## 一、来源信息
+
+- **需求基线**：`.planning/requirements/baseline.md`
+- **功能名称**：{{功能名称}}
+- **功能名**：{{功能名}}
+- **输出目录**：`.planning/features/{{功能名}}/`
+- **生成时间**：{{日期}}
+- **当前执行切片**：{{SL-001}} — {{切片名称}}
+
+## 二、范围摘要
+
+### 2.0 当前功能切片
+
+> 默认只展开当前功能切片。`depends_on` 仅作为历史上下文、复用、兼容或约束来源，除非当前切片明确修改/影响它，否则不生成独立节点。
+
+- **当前功能名**：{{功能名}}
+- **本轮范围说明**：{{本轮新增/修改/影响范围摘要}}
+- **当前执行切片**：{{SL-001}} — {{切片名称}}
+
+| 类型 | ID | 名称/说明 | 本轮关系 | 展开处理 |
+|------|----|-----------|----------|----------|
+| FP | FP-001 | {{功能点名称}} | {{新增/修改/影响}} | {{展开为章节路径}} |
+| BR | BR-001 | {{规则说明}} | {{新增/修改/影响}} | {{承接到逻辑/规则节点}} |
+| BC | BC-001 | {{场景说明}} | {{新增/修改/影响}} | {{承接到边界/异常节点}} |
+
+### 2.0a 跨功能依赖承接
+
+| 依赖对象 | 关系 | 在本轮中的作用 | 输出处理 |
+|----------|------|----------------|----------|
+| FP-003 | {{前置依赖/修改/复用/兼容/替换/影响}} | {{为什么需要读取该历史项}} | {{仅作上下文/承接为兼容约束/当前切片明确修改所以展开}} |
+
+### 2.1 已纳入功能点
+
+| 功能点ID | 功能点 | 类型 | 状态 | 优先级 | 输出位置 |
+|----------|--------|------|------|--------|----------|
+| FP-001 | {{功能点名称}} | {{新增/修改/影响}} | {{明确/待确认/推断，待确认}} | {{P0/P1/P2}} | {{章节路径}} |
+
+### 2.2 已纳入规则与边界
+
+| ID | 类型 | 关联功能点 | 说明 | 输出位置 |
+|----|------|------------|------|----------|
+| BR-001 | 业务规则 | FP-001 | {{规则说明}} | {{章节路径}} |
+| BC-001 | 边界场景 | FP-001 | {{场景说明}} | {{章节路径}} |
+
+### 2.3 不纳入/暂不处理
+
+| 内容 | 原因 | 来源 |
+|------|------|------|
+| {{范围外内容}} | {{原因}} | {{来源}} |
+| {{后置切片内容}} | 后置切片，非当前执行范围 | {{SL-002 / baseline 3.0b}} |
+
+### 2.4 反向审视与用户拍板承接
+
+| CR ID | 维度 | 用户决策/状态 | 输出处理 |
+|-------|------|---------------|----------|
+| CR-001 | {{冲突/复用/历史/过度工程/替代方案}} | {{已确认/待确认/不适用}} | {{对应章节/不展开/待确认}} |
+
+## 三、功能点三维梳理
+
+### 3.0 关键链路骨架
+
+> 先确认每个 FP 的触发、写入、读取、状态、异常和验收锚点，再展开样式/功能/逻辑节点。高风险链路必须有矩阵，避免长文档掩盖断裂点。
+
+| Slice | FP | 结果 | 触发/入口 | 写入/状态变化 | 读取/下游消费 | 异常/幂等 | 涉及代码库 | 验收锚点 |
+|-------|----|------|-----------|----------------|----------------|-----------|------------|----------|
+| SL-001 | FP-001 | {{业务结果}} | {{页面/接口/命令/回调/消息}} | {{表/状态/消息}} | {{页面/API/任务/端}} | {{重复/失败/延迟/权限}} | {{codebase}} | {{可验证路径}} |
+
+### 3.0a 高风险链路矩阵
+
+| 链路类型 | 关联 FP | 必查项 | 输出处理 | 缺口/结论 |
+|----------|---------|--------|----------|-----------|
+| {{通知/异步/迁移/字段替换/记录模型/权限菜单/外部幂等/列表展示}} | FP-001 | {{写入点、读取点、seed、调用方矩阵等}} | {{对应章节/待确认/不适用}} | {{通过/阻塞/非阻塞}} |
+
+### 3.1 后台
+
+- {{页面或模块}}
+  - {{页面区域}}
+    - {{组件/字段/按钮/表格列/弹窗}} ({{FP/BR/BC ID}}{{，CR ID 如适用}})
+      - 样式
+        - {{文案、位置、组件类型、展示格式、空状态或 UI待确认}}
+      - 功能
+        - {{操作、系统响应、校验、权限、加载、异常、边界}}
+      - 逻辑
+        - {{仅写有来源的规则、计算、数据来源、状态流转；无则省略}}
+
+### 3.2 C端
+
+- {{页面或流程}}
+  - {{页面区域/流程节点}}
+    - {{组件/操作/状态}} ({{FP/BR/BC ID}}{{，CR ID 如适用}})
+      - 样式
+        - {{文案、位置、组件类型、展示格式、空状态或 UI待确认}}
+      - 功能
+        - {{操作路径、授权、提交、取消、超时、失败、重试}}
+      - 逻辑
+        - {{仅写有来源的规则、计算、数据来源、状态流转；无则省略}}
+
+### 3.3 API/服务
+
+- {{服务能力或任务}}
+  - {{触发方式/接口/任务节点}} ({{FP/BR/BC ID}}{{，CR ID 如适用}})
+    - 样式
+      - 不适用：非 UI 能力
+    - 功能
+      - {{触发、输入校验、输出、幂等、异常、重试}}
+    - 逻辑
+      - {{业务规则、状态变更、数据来源、兼容性}}
+
+## 四、待确认事项
+
+| 问题ID | 分类 | 关联对象 | 问题 | 影响 | 当前处理 |
+|--------|------|----------|------|------|----------|
+| Q-001 | {{阻塞待确认/非阻塞待确认/UI待确认/枚举待确认/接口/数据待确认}} | {{FP/BR/BC/组件}} | {{问题}} | {{影响}} | {{已标注待确认/需回到 workflow-requirement-baseline}} |
+
+## 五、追溯关系
+
+| 输出章节 | 关联 FP | 关联 BR | 关联 BC | 关联 CR | 来源说明 |
+|----------|---------|---------|---------|---------|----------|
+| {{章节路径}} | FP-001 | BR-001 | BC-001 | CR-001 | {{baseline 来源段落/章节}} |
+
+## 六、自查结果
+
+| 检查项 | 结果 | 说明 |
+|--------|------|------|
+| 输出目录一致 | {{通过/有问题}} | {{说明}} |
+| FP 覆盖完整 | {{通过/有问题}} | {{说明}} |
+| 反向审视承接 | {{通过/有问题}} | {{说明}} |
+| 样式/功能完整 | {{通过/有问题}} | {{说明}} |
+| 逻辑均有来源 | {{通过/有问题}} | {{说明}} |
+| 权限规则正确 | {{通过/有问题}} | {{说明}} |
+| 只读/编辑未误推断 | {{通过/有问题}} | {{说明}} |
+| 枚举/状态值明确 | {{通过/有问题}} | {{说明}} |
+| 异常/边界覆盖 | {{通过/有问题}} | {{说明}} |
+| 链路骨架完整 | {{通过/有问题}} | {{说明}} |
+| 高风险链路门禁 | {{通过/有问题}} | {{说明}} |
+| 切片范围一致 | {{通过/有问题}} | {{说明}} |
+| 未包含技术方案内容 | {{通过/有问题}} | {{说明}} |

package/plugins/devflow-design/skills/workflow-feature-breakdown/references/bug-rules.md

@@ -0,0 +1,12 @@
+# 核心规避规则（来自真实 Bug）
+
+1. **权限控制统一为"不显示"** — 无权限时按钮不显示，而非置灰
+2. **只读字段不可推断为可编辑** — baseline 未说明可编辑的字段默认为只读
+3. **计算规则必须有原文依据** — 金额正负、余额计算等必须来自 baseline 或 baseline 记录的来源材料
+4. **同名字段在不同页面定义可能不同** — 不能跨页面复用
+5. **baseline 记录的评审结论必须严格遵循** — 优先级最高
+6. **下拉选项必须列出具体枚举值** — 不能写"系统枚举"
+7. **功能模块按前后台分类组织** — C端归C端，后台归后台
+8. **待确认不能写成事实** — baseline 待确认项只能进入待确认区或节点内标记，不能当作已确认规则
+9. **范围外内容不生成节点** — baseline 范围控制中明确不包含或暂不处理的内容，不得展开为功能点
+10. **回答影响基线时停止** — 用户补充若改变 FP/BR/BC/范围/输出目录，应回到 workflow-requirement-baseline 更新 baseline

package/plugins/devflow-design/skills/workflow-feature-breakdown/references/exception-checklist.md

@@ -0,0 +1,31 @@
+# 异常场景检查清单
+
+## 用户主动操作
+- [ ] 用户取消操作如何处理
+- [ ] 用户退出页面如何处理
+- [ ] 用户重复操作如何处理
+
+## 系统超时
+- [ ] 支付超时如何处理
+- [ ] 接口超时如何处理
+- [ ] 回调超时如何处理
+
+## 数据异常
+- [ ] 余额不足如何处理
+- [ ] 参数错误如何处理
+- [ ] 数据不一致如何处理
+
+## 第三方异常
+- [ ] 回调失败如何重试
+- [ ] 状态不一致如何同步
+- [ ] 主动查询机制
+
+## 绕过场景
+- [ ] 站外支付如何识别
+- [ ] 跳过中间环节如何处理
+
+## 输出标注规则
+- [ ] baseline 已明确的异常场景写入对应节点的功能维度
+- [ ] baseline 未明确但测试必须关注的异常，写入待确认事项
+- [ ] 缺少重试、补偿、幂等、告警规则时，标记为接口/数据待确认或非阻塞待确认
+- [ ] 不要自行补充重试次数、超时时长、补偿策略等业务规则

package/plugins/devflow-design/skills/workflow-feature-breakdown/references/trace-integrity-guide.md

@@ -0,0 +1,153 @@
+# 链路完整性防失真指南
+
+Use this reference when a feature spans multiple pages, services, codebases, async jobs, old-system migration, or field/source replacement. The goal is to keep the feature breakdown test-readable without letting long UI trees hide broken execution chains.
+
+This is a project-level guardrail, not a business-feature rulebook. Lessons from past features can trigger these checks, but this file must describe reusable failure modes and review gates rather than naming one historical feature as the default pattern.
+
+## 1. Critical Trace Card
+
+Write one short card for every FP before leaf-node expansion:
+
+| 字段 | 要求 |
+|------|------|
+| 结果 | 用户或业务最终得到什么 |
+| 触发 | 谁/什么事件启动链路 |
+| 入口 | 页面、接口、命令、回调、菜单、消息或调用方 |
+| 写入 | 被创建/更新的表、状态、缓存或消息 |
+| 读取 | 哪个页面、接口、任务或端消费该数据 |
+| 状态 | 关键状态流转、可见性、权限或归属变化 |
+| 异常 | 重复、失败、延迟、缺失、并发时如何处理 |
+| 范围 | 涉及代码库和明确不做项 |
+| 验收 | 一个可验证的用户路径或系统断言 |
+
+If a card has no clear write/read pair or no test anchor, mark the FP as high risk and create a pending item.
+
+## 2. High-Risk Chain Matrices
+
+### A. Notification / Message / Homepage Entry
+
+Use when the feature says notification, message center, workbench/homepage entry, unread count, or jump link.
+
+Required checks:
+
+- Producer event and dedupe key.
+- Real write target: table/model/API used by the visible consumer, not the semantic name guessed from wording.
+- Consumer path: frontend list/count API and its filters.
+- Jump path and permission/menu availability.
+- Empty/no-op case: when no message should be produced.
+
+Review fails if the document says "send notification" but does not identify the visible consumer's read model.
+
+### B. Async / Scheduled / Callback / Polling
+
+Use when plans, jobs, callbacks, polling, external platform status, delayed sync, model analysis, or retries exist.
+
+Required checks:
+
+- Creation entry.
+- Command/job class.
+- Command registration.
+- Database or scheduler seed.
+- Runtime trigger frequency and enabled status.
+- Idempotency key.
+- Monitoring/status field.
+- Recovery behavior for partial failure.
+
+Review fails if code command creation is covered but scheduler seed or enabled runtime is not mentioned.
+
+### C. Migration From Old System
+
+Use when moving old pages, services, OpenAPI bridges, configs, or runtime behavior into the current system.
+
+Required checks:
+
+- Old entry route and caller context parameters.
+- Old page's primary data table/model.
+- Old filter fields and operation buttons.
+- New route, new data model, and compatibility redirects.
+- Runtime dependency policy: old runtime allowed/disallowed; true external platform seam allowed/disallowed.
+- Data migration boundary: which configuration/history/runtime records move and which do not.
+
+Review fails if the output recreates a page by menu name but omits old entry parameters or old operation semantics.
+
+### D. Field / Contract Replacement
+
+Use when a new field or config source replaces an old one.
+
+Required checks:
+
+- Caller matrix: every page, dialog, batch action, backend API, cron job, and mobile/API caller that can trigger the business action.
+- Frontend control and validation.
+- API request DTO and server validation.
+- Persistence and snapshot fields.
+- Execution-time source of truth.
+- Old field downgrade/removal: validation, hints, required flags, request params, and fallback behavior.
+
+Review fails if only the new page is covered while existing callers can still use the old contract.
+
+### E. Record / Plan / Task Object Taxonomy
+
+Use when the feature mentions plan, target, job, record, call record, task, callback, or history.
+
+Required checks:
+
+- Define each object in business terms.
+- Define which table stores each object.
+- Define when an object may be created.
+- Define which pages query which object.
+- Define binding fields between objects.
+- Confirm placeholders do not pollute business records.
+
+Review fails if platform job records and CRM business records are collapsed into one table without an explicit rule.
+
+### F. Permission / Menu / Route Reachability
+
+Use for new pages, homepage/message direct links, dynamic menus, auth-center integration, or hidden routes.
+
+Required checks:
+
+- Page component path.
+- Dynamic menu/auth-center record.
+- Permission code or visibility rule.
+- Direct entry behavior when menu sync is delayed.
+- Route component normalization or fallback if the project uses dynamic components.
+
+Review fails if an entry is visible but route reachability depends on unverified menu data.
+
+### G. External Call / Model Analysis Idempotency
+
+Use for third-party APIs, platform polling, recording download, transcript fetch, model calls, or callbacks.
+
+Required checks:
+
+- Local short-circuit fields before external calls.
+- Idempotency key and status.
+- Retry and cooldown policy.
+- Preserve existing local data on partial external response.
+- Separate platform sync from model analysis when both are side effects.
+
+Review fails if repeated callback/poll/analyze can overwrite existing data or repeat costly external calls without a local missing-field trigger.
+
+### H. List Display Contract
+
+Use when a table column or card displays derived, summarized, permission-filtered, or AI-generated information.
+
+Required checks:
+
+- Stable display field exposed by backend.
+- Source raw fields and transformation owner.
+- Empty/failed/unauthorized display.
+- Sorting/filtering field if different from display field.
+
+Review fails if frontend is expected to choose among raw fields for a named business display such as "分析结果", "业务摘要", or other derived presentation fields.
+
+## 3. Scope Pressure Rule
+
+When the current slice has more than 8 FPs or a migration FP with many secondary pages:
+
+- Keep the trace skeleton concise and mandatory.
+- Expand P0 user-facing and execution-chain nodes first.
+- Mark broad secondary CRUD/config pages as `范围占位` unless baseline explicitly requires full CRUD detail now.
+- Put optional styling detail into `UI待确认` or `非阻塞待确认`; do not let it crowd out chain gates.
+
+The review should prefer a shorter document with complete chains over a long document with many field nodes but missing seams.

package/plugins/devflow-design/skills/workflow-feature-breakdown/references/writing-guide.md

@@ -0,0 +1,92 @@
+# 三维描述规范
+
+## 样式维度
+描述元素视觉呈现和位置：
+- 文案内容、位置信息、组件类型、展示规则
+- 按钮："按钮文案显示为'新增'，位于页面头部右侧"
+- 输入框："字段标签显示为'订单编号'，占位符显示'请输入'"
+- 表格列："展示订单编号文本，支持复制"
+
+## 功能维度
+描述用户操作和系统响应，覆盖边界：
+- 交互行为、必填校验、格式校验、异常处理
+- 权限控制（无权限时按钮不显示）
+- 防重复提交（请求中按钮置灰）
+- 空数据状态
+
+## 逻辑维度
+描述计算规则和业务约束，仅当有明确业务规则时才写：
+- 计算公式、统计口径、状态联动、业务约束
+- 数据来源、条件判断
+
+## 细颗粒度拆分示例
+
+### 筛选区
+
+错误：把多个筛选条件聚合成一句。
+
+正确：
+
+```text
+- 筛选区
+  - 订单编号输入框
+    - 来源：FP-001
+    - 样式
+      - 字段标签显示为"订单编号"
+      - 输入框占位符显示"请输入订单编号"
+    - 功能
+      - 支持手动输入和粘贴
+      - 点击查询后按订单编号精准筛选
+    - 逻辑
+      - 查询字段来自 baseline 数据要求；无来源则标记待确认
+  - 订单状态下拉选择
+    - 来源：FP-001/BR-001
+    - 样式
+      - 下拉框默认显示"全部"
+    - 功能
+      - 可选项必须列出具体枚举；缺失时标记枚举待确认
+```
+
+### 表格列
+
+```text
+- 列表区
+  - 表格整体
+    - 来源：FP-002
+    - 样式
+      - 空数据时显示空状态文案；文案缺失时标记 UI待确认
+    - 功能
+      - 进入页面后加载列表
+      - 加载失败时提示并支持重试
+  - 列:订单编号
+    - 来源：FP-002
+    - 样式
+      - 展示订单编号文本
+    - 功能
+      - 只读展示，不可编辑
+    - 逻辑
+      - 数据来自订单号字段
+```
+
+### 弹窗表单
+
+```text
+- 新增/编辑弹窗
+  - 表单字段:活动名称
+    - 来源：FP-003/BR-002
+    - 样式
+      - 字段标签显示为"活动名称"
+      - 标注必填标记
+    - 功能
+      - 为空时提交阻断并提示
+      - 重复时提示名称已存在
+    - 逻辑
+      - 活动名称唯一性规则必须来自 baseline
+  - 按钮:确定
+    - 来源：FP-003
+    - 样式
+      - 按钮文案显示为"确定"
+    - 功能
+      - 请求中按钮置灰，防止重复提交
+      - 接口失败时弹窗不关闭并提示错误
+```

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: workflow-frontend-tech-spec
+description: "Use when a requirement baseline and UI specification need a frontend technical design covering routes, components, state, APIs, reuse, and risks."
+---
+
+## Legacy Command Metadata
+
+Original slash-command metadata retained only as workflow invocation guidance.
+
+```yaml
+argument-hint: <功能名>
+user-invocable: true
+pattern: generator+tool-wrapper
+inputs:
+- .planning/features/{功能名}/功能点梳理.md
+- .planning/features/{功能名}/UI-SPEC.md
+- .planning/requirements/baseline.md
+- .planning/PROJECT.md
+- .planning/navigation/INDEX.md
+- .planning/rules/INDEX.md
+- .planning/execution-contract.md
+- .planning/toolchain.md
+- .planning/lessons/README.md
+- .context/spec/index.md
+- .context/spec/stacks/
+- .context/spec/frontend/index.md
+- .context/spec/frontend/
+- .context/spec/design/
+- .context/workflow/
+- .context/lessons/README.md（如存在）
+- references/frontend-stack-slots/common-web.md
+- references/frontend-stack-slots/react.md
+- references/frontend-stack-slots/next.md
+- references/frontend-stack-slots/vue.md
+- .planning/milestones/
+- references/affected-module-exploration.md
+output: .planning/features/{功能名}/前端技术方案.md
+allowed-tools:
+- Read
+- Write
+- Edit
+- Bash
+- Grep
+- Glob
+- ask
+```
+
+# 前端技术方案生成器
+
+根据需求基线和前端现有代码，生成前端技术方案文档。
+
+## 核心原则
+
+**遇到不确定的地方，必须询问用户，不要自己做决定。**
+
+## 工作流程
+
+### 第一阶段：理解需求
+
+1. 读取 `.planning/requirements/baseline.md` 理解需求
+2. 读取 `.planning/PROJECT.md` 了解项目上下文
+3. 如果 baseline.md 不存在，询问用户提供需求
+4. 读取 `references/project-rule-contract.md`，按 Spec Read Contract 发现并加载目标项目的前端规则包：`.planning/rules/INDEX.md` → `.context/spec/index.md` → 命中的 stack spec → 命中的 frontend codebase spec → navigation → code-index（如存在且需要关系事实）→ 源码
+5. 若 `.context/spec/design/index.md` 不存在，先调用 `devflow_design_rule(args=[])` 安装共享设计规则包；若仍不存在，记录“未发现设计规则包”并继续。
+6. 若存在 `.context/spec/design/index.md`，读取设计规则入口。只把用户拍板、设计稿事实、现有项目规范、项目级已确认 token 作为实现依据；`.context/spec/design/recommendations/` 与 `ui-ux-pro-max` 查询结果只能补充实现注意点、风险、测试门禁或待确认事项。
+7. 按 `references/project-rule-contract.md` 的 Stack Slot Loading 规则加载前端技术栈插槽：始终读取 `common-web.md`，再按技术栈读取 React / Next.js / Vue 插槽
+8. 读取 baseline 的 `反向审视与用户拍板`、`待确认事项`、`下游输入契约`：
+   - 已确认的页面/交互/复用/替代方案决策必须进入前端方案
+   - 影响 scope、交互语义、组件归属、兼容性或实现成本的未确认项，不得被当成已确认需求
+   - 若未确认项阻塞前端方案，询问用户；`--auto` 或无法询问时写入待确认事项和风险
+9. 若 baseline 或 `功能点梳理.md` 包含 `SL-*` 切片计划，读取 `skill://workflow-pipeline/references/slice-safety-guide.md`，只为当前执行切片生成前端方案。后置切片只可作为依赖上下文或后续范围，不得生成路由、组件或 API 调用实现设计。
+
+### 第二阶段：探索现有前端代码
+
+1. **读取 PROJECT.md 的 Project Layout 章节**，确定前端代码所在目录
+2. 按 `references/project-rule-contract.md` 的顺序读取项目规则包，优先使用 `.planning/rules/INDEX.md` 和 `.context/spec/index.md` 匹配 stack/codebase spec，兼容 `.context/spec/frontend/`、`.context/spec/design/`、`.context/workflow/`、`.context/lessons/` 和根目录 `AGENTS.md` / `CLAUDE.md`
+3. 若 `.planning/code-index/` 存在，用 Symbol Index 和 Relation Graph 查询相关页面、路由、组件、store/hook、API client、imports/calls，并回读 `evidence_path:evidence_line`
+4. 识别前端项目结构（页面/组件/路由/Store）
+5. 查找 API 调用层的封装模式；优先使用 code-index 的 calls/imports/routes_to 关系，缺失时再按导航和源码兜底
+6. **分析接口调用压力**：梳理每个页面/操作的 API 调用次数、并发数、请求瀑布、是否存在冗余或可合并的请求；识别已有防抖/节流/缓存/竞态处理策略
+7. **分析接口安全**：检查 Token 存储位置与刷新机制、敏感字段是否暴露到前端、是否已有 CSRF/XSS 防护、请求签名/防重放机制
+8. 查找 UI 组件库、设计系统、样式方案、状态管理和权限控制模式
+9. 识别技术栈插槽：React、Next.js、Vue 或仅 Common Web，并记录未覆盖的框架为待确认/待扩展
+10. 检查三层复用机会：已有页面/组件/交互模式、已有依赖/库、项目设计系统或代码模式；与 baseline 的复用决策保持一致
+11. **执行被影响方探索**：读取 `references/affected-module-exploration.md`，对 baseline 第8.2节"关联历史功能/模块"表格列出的每个受影响的前端页面/组件，按清单逐项读取源码并产出：现有 props/emits/methods/API 调用清单、现有数据流和交互方式、保留/分支/抽离/新增决策。探索产出直接填入输出文档的"影响范围"章节和组件树。**探索产出检查不通过，不得进入 Phase 3。**
+12. 如 `.context/spec/design/tools/ui-ux-pro-max/scripts/search.py` 存在，可按当前技术栈和 UI 场景补充查询：
+    ```bash
+    python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "layout form table accessibility performance" --stack react
+    python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "accessibility loading error duplicate submit" --domain ux
+    python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "aria focus keyboard semantic form" --domain web
+    ```
+    查询结果不得覆盖项目规则和已确认 UI-SPEC；与项目现状冲突时写入风险或待确认事项。
+
+如果与 baseline 中的用户拍板结果冲突，停止并要求重新确认，不要自行改判。
+
+### 第二阶段.5 — 组件 Seam 评估
+
+在生成文档前，对每个 UI 功能点评估组件的 seam 位置和接口深度。
+
+### 第二阶段.6 — Slice Scope Guard
+
+如果输入包含当前执行切片：
+
+- 在文档开头写明 active `Slice ID`、切片名称、纳入 FP/BR/BC、后置 FP/BR/BC。
+- 路由、组件、状态、API 调用、权限入口只允许覆盖当前切片。
+- 共享组件或 API 封装若服务于后置切片，必须说明它在当前切片中的可验证用途；否则移到后续范围。
+- 若前端方案必须同时设计多个 slice 才能自洽，停止并要求回到 `workflow-requirement-baseline` 重新切片。
+
+**1. 组件 Seam 决策**
+
+对功能点梳理中的每个页面/组件节点，判断其来源：
+
+| 组件 | 来源 | 依据 | Seam 决策 |
+|------|------|------|----------|
+| 订单列表 | 已有 Table 组件 | 布局、列配置匹配 | 复用（封装列配置 Props） |
+| 订单详情 | 需新建 | 无现有组件匹配 | 新建独立组件 |
+
+判断标准：
+- **复用**：已有组件通过 Props 配置可覆盖需求，不改组件内部
+- **扩展**：已有组件需加新 Props/Slots，改接口不改实现深度
+- **新建**：无现有组件匹配，或现有组件改接口代价大于新建
+
+**2. 组件接口深度评估**
+
+对每个涉及新建或扩展的组件，评估其接口深度：
+
+| 组件 | 公开 Props | 公开 Events | 公开 Slots | 评估 |
+|------|-----------|------------|-----------|:----:|
+| OrderDetail | props: 3 (orderId, showHistory, editable) | events: 2 (close, save) | slots: 0 | ✅ 深（小接口） |
+| AdvancedFilter | props: 8 (fields, operators, logic, ...) | events: 5 | slots: 2 | ⚠️ 浅（接口膨胀，考虑拆分） |
+
+判断标准：
+- **深**：Props+Events+Slots ≤ 6，组件封装了复杂行为和状态
+- **浅**：Props+Events+Slots ≥ 8，组件几乎透传了所有细节
+- 浅组件的处理：是否可以把多个 Props 聚合成一个配置对象？
+
+**3. 记录 seam 决策**
+
+将评估结果写入方案文档的组件拆分章节：
+
+```markdown
+## 组件 Seam 决策
+
+| 组件 | 来源 | 公开接口数 | 评估 | 说明 |
+|------|------|:---------:|:----:|------|
+| OrderList | 复用 | props: 3 / events: 2 | ✅ 深 | 只需加 orderStatus 列配置 |
+| OrderDetail | 新建 | props: 3 / events: 2 | ✅ 深 | 保持小接口 |
+```
+
+**门禁**：每个界面/组件必须有 seam 决策记录（复用/扩展/新建），否则不得进入 Phase 3。
+
+1. 创建 `.planning/features/{功能名}/` 目录
+2. 读取 `assets/frontend-spec-template.md` 模板
+3. 按模板结构填充内容，并写入 `需求基线衔接`、`前端规范影响` 和 `技术栈插槽` 内容
+4. 在 `前端规范影响` 中明确区分“已确认实现依据”和“推荐参考/待确认”，禁止把 UI-SPEC 中的“推荐 - 待拍板”作为组件 props、样式变量或实现常量直接落地。
+
+If an older baseline still points to root `features/{功能名}/`, treat that as a legacy read path. New frontend tech-spec output stays under `.planning/features/{功能名}/`.
+
+### 第四阶段：用户确认
+
+1. 展示生成的文档
+2. 询问是否需要修改
+3. 迭代直到用户满意
+
+### 第五阶段：结构化元数据
+
+完成后写入 `.planning/features/{功能名}/前端技术方案.meta.json`，字段定义见 `feature-development.yaml` 中 `steps[frontend-tech-spec].meta_output.fields`：`route_count`, `component_count`, `api_count`, `api_gaps_count`。
+
+`api_gaps_count` 表示前端方案发现但 `api-contract.md` 未覆盖的接口缺口数量。若大于 0，必须由 `workflow-api-supplement` 处理并回写 API 契约后，才能进入 `integration-verify`。
+
+## 注意事项
+
+1. 组件树要有层级，父组件→子组件关系清晰
+2. 交互流程描述用户操作→页面响应→接口调用的完整链路
+3. 状态管理描述新增 Store/state 的结构
+4. 接口依赖标注请求/响应格式
+5. 影响范围标注受影响的现有页面和组件
+6. 若目标项目存在 `.planning/rules/` 或 `.context/spec/`，前端方案必须列出适用设计/组件/交互规范、相关经验教训、工具链要求、测试策略和审查门禁
+7. 必须覆盖 loading、empty、error、permission、disabled、duplicate submit、responsive、accessibility 等用户可见状态；缺少来源时标记待确认
+8. 必须分析接口调用压力：每个用户操作触发几次 API 调用、并发请求数量、是否存在重复/冗余/可合并请求、是否需要防抖/节流/缓存、是否存在竞态条件
+9. 必须分析接口安全：Token 存储与刷新策略是否合规、敏感数据是否有暴露风险及脱敏方案、防重放/CSRF/XSS 措施是否到位、请求签名是否必要
+10. 项目本地规则优先级高于技术栈插槽；技术栈插槽只补充项目未定义的默认规则
+11. 与历史相关的判断优先来自 `.planning/milestones/`、`.planning/requirements/`、`.planning/lessons/` 和阶段 `CONTEXT.md`；`features/` 或 `.context/lessons/` 只作为目标项目存在时的兼容来源
+12. 设计规则优先级为：用户拍板/设计稿事实/需求基线 > 现有代码与项目 token > `.context/spec/design/tokens/project-tokens.md` > `.context/spec/design/recommendations/` 与 `ui-ux-pro-max` 推荐。推荐项未经用户确认不得进入实现任务。
+
+## 强制审查门禁（MANDATORY — 不可跳过）
+
+### 反问审查
+
+- [ ] 每个不确定的组件选择、路由设计、状态处理是否已向用户确认？（禁止猜测）
+- [ ] `references/affected-module-exploration.md` 的探索产出检查是否全部通过？（现有 props/emits/methods/API 调用清单、保留/分支/抽离/新增决策）**若不通过，必须先补充代码探索，不得继续写文档。**
+- [ ] 若 `.planning/code-index/` 存在，受影响页面/组件/API/store 的关系定位是否已查询 code-index 并回读源码 evidence？若未使用，是否说明缺失或过期原因？
+- [ ] 方案影响的现有页面/组件是否已描述其**现状**？（先描述现状，再分析影响）
+- [ ] loading/empty/error/permission/disabled/duplicate/responsive 等状态是否均已覆盖或标记待确认？
+- [ ] 若存在 `SL-*`，方案是否只覆盖当前执行切片，且后置切片未进入实现范围？
+
+### 调用压力审查
+
+- [ ] 每个页面/操作的 API 调用次数、并发数、请求瀑布是否已梳理？
+- [ ] 冗余/可合并请求是否已识别？防抖/节流/缓存/竞态处理策略是否已说明？
+
+### 安全审查
+
+- [ ] Token 管理（存储/刷新/过期）是否合规？
+- [ ] 敏感数据是否有前端暴露风险？脱敏策略是否明确？
+- [ ] 防重放、CSRF/XSS、请求签名等防护措施是否到位？
+
+### 反向对照审查（源自 spec-writer 模式）
+
+| 嗅探 | 检查 |
+|------|------|
+| 复用嗅探 | 组件/工具/hooks 是否已有现成可复用？ |
+| 冲突嗅探 | 路由/命名/组件层级是否与现有约定冲突？ |
+| 重叠嗅探 | 是否会与已有页面形成"两套并存"？ |
+
+### 产物完整性
+
+- [ ] 方案包含：功能要点、影响范围、路由设计、组件拆分、数据流、状态处理、风险点
+- [ ] 不含后端 DDL、后端代码任务
+- [ ] 若存在 `.planning/rules/` 或 `.context/spec/`，适用规范已列出
+- [ ] 审查结论已写入方案末尾
+
+**审查结论不通过时不得报告 "Step 3b 完成"。**