@guanlin4924/devflow-pi 0.1.93 → 0.1.95

package/plugins/devflow-design/skills/workflow-feature-breakdown/SKILL.md

@@ -12,15 +12,15 @@ argument-hint: <功能名> [--auto]
 user-invocable: true
 pattern: generator+reviewer
 inputs:
-- .planning/requirements/baseline.md
-- .planning/features/{功能名}/UI-SPEC.md
-- .planning/PROJECT.md
-- .planning/navigation/INDEX.md
-- .planning/navigation/*.md
-- .planning/milestones/
-- .planning/requirements/
-- .planning/lessons/README.md
-output: .planning/features/{功能名}/功能点梳理.md
+- .devflow/planning/requirements/baseline.md
+- .devflow/planning/features/{功能名}/UI-SPEC.md
+- .devflow/planning/PROJECT.md
+- .devflow/planning/navigation/INDEX.md
+- .devflow/planning/navigation/*.md
+- .devflow/planning/milestones/
+- .devflow/planning/requirements/
+- .devflow/planning/lessons/README.md
+output: .devflow/planning/features/{功能名}/功能点梳理.md
 allowed-tools:
 - Read
 - Write
@@ -38,15 +38,15 @@ This skill consumes the requirement baseline and creates a test-readable feature
 
 Always create or update:
 
-- `.planning/features/{功能名}/功能点梳理.md`
-- `.planning/features/{功能名}/功能点梳理.meta.json` — structured metadata (fp_count, dimension_counts, page_count). Schema in `feature-development.yaml` under `steps[feature-breakdown].meta_output.fields`.
+- `.devflow/planning/features/{功能名}/功能点梳理.md`
+- `.devflow/planning/features/{功能名}/功能点梳理.meta.json` — structured metadata (fp_count, dimension_counts, page_count). Schema in `feature-development.yaml` under `steps[feature-breakdown].meta_output.fields`.
 
 Do not create by default:
 
-- `.planning/features/{功能名}/前端技术方案.md`
-- `.planning/features/{功能名}/后端技术方案.md`
-- `.planning/features/{功能名}/变更清单.md`
-- `.planning/requirements/baseline.md`
+- `.devflow/planning/features/{功能名}/前端技术方案.md`
+- `.devflow/planning/features/{功能名}/后端技术方案.md`
+- `.devflow/planning/features/{功能名}/变更清单.md`
+- `.devflow/planning/requirements/baseline.md`
 
 ## Argument Handling
 
@@ -58,11 +58,11 @@ Parse `$ARGUMENTS` before reading files:
 The canonical output directory must come from the baseline when available:
 
 ```text
-.planning/features/{功能名}/
+.devflow/planning/features/{功能名}/
 ```
 
 Do not invent another directory name from the project name, PRD title, or module name.
-If an older baseline still points to `features/{功能名}/`, treat it as a legacy path and prefer `.planning/features/{功能名}/` for new output unless the user explicitly requests legacy compatibility.
+If an older baseline still points to `features/{功能名}/`, treat it as a legacy path and prefer `.devflow/planning/features/{功能名}/` for new output unless the user explicitly requests legacy compatibility.
 
 ## Resource Loading
 
@@ -82,14 +82,14 @@ Load bundled resources only when needed:
 
 Read:
 
-1. `.planning/requirements/baseline.md`
-2. `.planning/PROJECT.md` if present
-3. `.planning/navigation/INDEX.md` if present
-4. `.planning/navigation/INDEX.md` — identify relevant codebases from the Codebase Registry, then load their navigation files (`{name}.md`)
-5. `.planning/code-index/` when present and the feature breakdown needs existing route/component/API/data-flow relation facts
-6. `.planning/milestones/` only when baseline historical impact references prior milestones
-7. `.planning/requirements/` and `.planning/lessons/` only when baseline historical impact or challenge review references them
-8. `.context/lessons/README.md` when present; load only lesson files whose title or summary matches current FP/BR/BC keywords
+1. `.devflow/planning/requirements/baseline.md`
+2. `.devflow/planning/PROJECT.md` if present
+3. `.devflow/planning/navigation/INDEX.md` if present
+4. `.devflow/planning/navigation/INDEX.md` — identify relevant codebases from the Codebase Registry, then load their navigation files (`{name}.md`)
+5. `.devflow/planning/code-index/` when present and the feature breakdown needs existing route/component/API/data-flow relation facts
+6. `.devflow/planning/milestones/` only when baseline historical impact references prior milestones
+7. `.devflow/planning/requirements/` and `.devflow/planning/lessons/` only when baseline historical impact or challenge review references them
+8. `.devflow/context/lessons/README.md` when present; load only lesson files whose title or summary matches current FP/BR/BC keywords
 
 The baseline is the source of truth. Use its:
 
@@ -126,9 +126,9 @@ Baseline section mapping:
 
 History model rule:
 
-- Use `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and phase `CONTEXT.md` as primary history.
-- Treat `features/` or `.context/lessons/` as optional legacy/project-rule sources only when present and referenced by the baseline.
-- Treat matching `.context/lessons/` files as regression guards for review. They do not expand scope by themselves, but any current FP touching the same seam must carry the lesson as a constraint or explain why it is not applicable.
+- Use `.devflow/planning/milestones/`, `.devflow/planning/requirements/`, `.devflow/planning/lessons/`, and phase `CONTEXT.md` as primary history.
+- Treat `features/` or `.devflow/context/lessons/` as optional legacy/project-rule sources only when present and referenced by the baseline.
+- Treat matching `.devflow/context/lessons/` files as regression guards for review. They do not expand scope by themselves, but any current FP touching the same seam must carry the lesson as a constraint or explain why it is not applicable.
 
 Current slice rule:
 
@@ -284,7 +284,7 @@ If stopping because a user answer changes baseline-level requirements, report:
 
 Read `assets/output-template.md`.
 
-Create `.planning/features/{功能名}/` if needed and write `.planning/features/{功能名}/功能点梳理.md`.
+Create `.devflow/planning/features/{功能名}/` if needed and write `.devflow/planning/features/{功能名}/功能点梳理.md`.
 
 The document must include:
 
@@ -321,7 +321,7 @@ The document must include:
 | 重叠嗅探 | 梳理的功能是否会与某个已有功能形成"两套并存"？ |
 | 历史嗅探 | `features/` 中是否有类似功能曾被做过？ |
 
-若 `.planning/code-index/` 存在，复用/冲突/重叠嗅探应优先查询 symbols/relations，再回读源码 evidence；缺失或过期时再用 navigation 和 `rg` 兜底。
+若 `.devflow/planning/code-index/` 存在，复用/冲突/重叠嗅探应优先查询 symbols/relations，再回读源码 evidence；缺失或过期时再用 navigation 和 `rg` 兜底。
 
 ### 7.2a 链路完整性审查（MANDATORY）
 

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

@@ -2,10 +2,10 @@
 
 ## 一、来源信息
 
-- **需求基线**：`.planning/requirements/baseline.md`
+- **需求基线**：`.devflow/planning/requirements/baseline.md`
 - **功能名称**：{{功能名称}}
 - **功能名**：{{功能名}}
-- **输出目录**：`.planning/features/{{功能名}}/`
+- **输出目录**：`.devflow/planning/features/{{功能名}}/`
 - **生成时间**：{{日期}}
 - **当前执行切片**：{{SL-001}} — {{切片名称}}
 

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

@@ -12,31 +12,31 @@ argument-hint: <功能名>
 user-invocable: true
 pattern: generator+tool-wrapper
 inputs:
-- .planning/features/{功能名}/功能点梳理.md
-- .planning/features/{功能名}/UI-SPEC.md
-- .planning/features/{功能名}/architecture-brief.md
-- .planning/features/{功能名}/architecture-brief.meta.json
-- .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（如存在）
+- .devflow/planning/features/{功能名}/功能点梳理.md
+- .devflow/planning/features/{功能名}/UI-SPEC.md
+- .devflow/planning/features/{功能名}/architecture-brief.md
+- .devflow/planning/features/{功能名}/architecture-brief.meta.json
+- .devflow/planning/requirements/baseline.md
+- .devflow/planning/PROJECT.md
+- .devflow/planning/navigation/INDEX.md
+- .devflow/planning/rules/INDEX.md
+- .devflow/planning/execution-contract.md
+- .devflow/planning/toolchain.md
+- .devflow/planning/lessons/README.md
+- .devflow/context/spec/index.md
+- .devflow/context/spec/stacks/
+- .devflow/context/spec/frontend/index.md
+- .devflow/context/spec/frontend/
+- .devflow/context/spec/design/
+- .devflow/context/workflow/
+- .devflow/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/
+- .devflow/planning/milestones/
 - references/affected-module-exploration.md
-output: .planning/features/{功能名}/前端技术方案.md
+output: .devflow/planning/features/{功能名}/前端技术方案.md
 allowed-tools:
 - Read
 - Write
@@ -51,7 +51,7 @@ allowed-tools:
 
 ## 需求追溯硬约束
 
-读取 `.planning/requirements/{feature}/traceability.json`。每个页面、状态流、缓存/竞态处理和接口调用必须列出 `覆盖 REQ: REQ-*`；API 调用必须写请求参数、响应消费、错误处理和行为语义，不能只列响应字段或视觉改动。
+读取 `.devflow/planning/requirements/{feature}/traceability.json`。每个页面、状态流、缓存/竞态处理和接口调用必须列出 `覆盖 REQ: REQ-*`；API 调用必须写请求参数、响应消费、错误处理和行为语义，不能只列响应字段或视觉改动。
 
 根据需求基线和前端现有代码，生成前端技术方案文档。
 
@@ -63,25 +63,25 @@ allowed-tools:
 
 ### 第一阶段：理解需求
 
-1. 读取 `.planning/requirements/baseline.md` 理解需求
-2. 读取 `.planning/PROJECT.md` 了解项目上下文
+1. 读取 `.devflow/planning/requirements/baseline.md` 理解需求
+2. 读取 `.devflow/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` 查询结果只能补充实现注意点、风险、测试门禁或待确认事项。
+4. 读取 `references/project-rule-contract.md`，按 Spec Read Contract 发现并加载目标项目的前端规则包：`.devflow/planning/rules/INDEX.md` → `.devflow/context/spec/index.md` → 命中的 stack spec → 命中的 frontend codebase spec → navigation → code-index（如存在且需要关系事实）→ 源码
+5. 若 `.devflow/context/spec/design/index.md` 不存在，先调用 `devflow_design_rule(args=[])` 安装共享设计规则包；若仍不存在，记录“未发现设计规则包”并继续。
+6. 若存在 `.devflow/context/spec/design/index.md`，读取设计规则入口。只把用户拍板、设计稿事实、现有项目规范、项目级已确认 token 作为实现依据；`.devflow/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. 读取 `.planning/features/{功能名}/architecture-brief.md` 和 `.meta.json`，在文档开头记录消费的 `brief_revision`、`graph_revision` 和 `static_context_snapshot_revision`。只有 `comparison_status=confirmed` 的架构选择可改变请求编排、缓存、轮询或异步交互；未确认/未决项必须保留为风险或待确认事项。
+9. 读取 `.devflow/planning/features/{功能名}/architecture-brief.md` 和 `.meta.json`，在文档开头记录消费的 `brief_revision`、`graph_revision` 和 `static_context_snapshot_revision`。只有 `comparison_status=confirmed` 的架构选择可改变请求编排、缓存、轮询或异步交互；未确认/未决项必须保留为风险或待确认事项。
 10. 若 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`
+2. 按 `references/project-rule-contract.md` 的顺序读取项目规则包，优先使用 `.devflow/planning/rules/INDEX.md` 和 `.devflow/context/spec/index.md` 匹配 stack/codebase spec，兼容 `.devflow/context/spec/frontend/`、`.devflow/context/spec/design/`、`.devflow/context/workflow/`、`.devflow/context/lessons/` 和根目录 `AGENTS.md` / `CLAUDE.md`
+3. 若 `.devflow/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 调用次数、并发数、请求瀑布、是否存在冗余或可合并的请求；识别已有防抖/节流/缓存/竞态处理策略
@@ -90,11 +90,11 @@ allowed-tools:
 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 场景补充查询：
+12. 如 `.devflow/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
+    python3 .devflow/context/spec/design/tools/ui-ux-pro-max/scripts/search.py "layout form table accessibility performance" --stack react
+    python3 .devflow/context/spec/design/tools/ui-ux-pro-max/scripts/search.py "accessibility loading error duplicate submit" --domain ux
+    python3 .devflow/context/spec/design/tools/ui-ux-pro-max/scripts/search.py "aria focus keyboard semantic form" --domain web
     ```
     查询结果不得覆盖项目规则和已确认 UI-SPEC；与项目现状冲突时写入风险或待确认事项。
 
@@ -156,12 +156,12 @@ allowed-tools:
 
 **门禁**：每个界面/组件必须有 seam 决策记录（复用/扩展/新建），否则不得进入 Phase 3。
 
-1. 创建 `.planning/features/{功能名}/` 目录
+1. 创建 `.devflow/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/{功能名}/`.
+If an older baseline still points to root `features/{功能名}/`, treat that as a legacy read path. New frontend tech-spec output stays under `.devflow/planning/features/{功能名}/`.
 
 ### 第四阶段：用户确认
 
@@ -171,7 +171,7 @@ If an older baseline still points to root `features/{功能名}/`, treat that as
 
 ### 第五阶段：结构化元数据
 
-完成后写入 `.planning/features/{功能名}/前端技术方案.meta.json`，字段定义见 `feature-development.yaml` 中 `steps[frontend-tech-spec].meta_output.fields`：`route_count`, `component_count`, `api_count`, `api_gaps_count`。
+完成后写入 `.devflow/planning/features/{功能名}/前端技术方案.meta.json`，字段定义见 `feature-development.yaml` 中 `steps[frontend-tech-spec].meta_output.fields`：`route_count`, `component_count`, `api_count`, `api_gaps_count`。
 
 同时必须从 `architecture-brief.meta.json` 原样复制：`brief_revision → architecture_brief_revision`、`graph_revision → architecture_graph_revision`、`static_context_snapshot_revision → architecture_static_context_snapshot_revision`、`comparison_status → architecture_comparison_status`。不得凭记忆填写或改写这些值。
 
@@ -184,13 +184,13 @@ If an older baseline still points to root `features/{功能名}/`, treat that as
 3. 状态管理描述新增 Store/state 的结构
 4. 接口依赖标注请求/响应格式
 5. 影响范围标注受影响的现有页面和组件
-6. 若目标项目存在 `.planning/rules/` 或 `.context/spec/`，前端方案必须列出适用设计/组件/交互规范、相关经验教训、工具链要求、测试策略和审查门禁
+6. 若目标项目存在 `.devflow/planning/rules/` 或 `.devflow/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` 推荐。推荐项未经用户确认不得进入实现任务。
+11. 与历史相关的判断优先来自 `.devflow/planning/milestones/`、`.devflow/planning/requirements/`、`.devflow/planning/lessons/` 和阶段 `CONTEXT.md`；`features/` 或 `.devflow/context/lessons/` 只作为目标项目存在时的兼容来源
+12. 设计规则优先级为：用户拍板/设计稿事实/需求基线 > 现有代码与项目 token > `.devflow/context/spec/design/tokens/project-tokens.md` > `.devflow/context/spec/design/recommendations/` 与 `ui-ux-pro-max` 推荐。推荐项未经用户确认不得进入实现任务。
 
 ## 强制审查门禁（MANDATORY — 不可跳过）
 
@@ -198,7 +198,7 @@ If an older baseline still points to root `features/{功能名}/`, treat that as
 
 - [ ] 每个不确定的组件选择、路由设计、状态处理是否已向用户确认？（禁止猜测）
 - [ ] `references/affected-module-exploration.md` 的探索产出检查是否全部通过？（现有 props/emits/methods/API 调用清单、保留/分支/抽离/新增决策）**若不通过，必须先补充代码探索，不得继续写文档。**
-- [ ] 若 `.planning/code-index/` 存在，受影响页面/组件/API/store 的关系定位是否已查询 code-index 并回读源码 evidence？若未使用，是否说明缺失或过期原因？
+- [ ] 若 `.devflow/planning/code-index/` 存在，受影响页面/组件/API/store 的关系定位是否已查询 code-index 并回读源码 evidence？若未使用，是否说明缺失或过期原因？
 - [ ] 方案影响的现有页面/组件是否已描述其**现状**？（先描述现状，再分析影响）
 - [ ] loading/empty/error/permission/disabled/duplicate/responsive 等状态是否均已覆盖或标记待确认？
 - [ ] 若存在 `SL-*`，方案是否只覆盖当前执行切片，且后置切片未进入实现范围？
@@ -226,7 +226,7 @@ If an older baseline still points to root `features/{功能名}/`, treat that as
 
 - [ ] 方案包含：功能要点、影响范围、路由设计、组件拆分、数据流、状态处理、风险点
 - [ ] 不含后端 DDL、后端代码任务
-- [ ] 若存在 `.planning/rules/` 或 `.context/spec/`，适用规范已列出
+- [ ] 若存在 `.devflow/planning/rules/` 或 `.devflow/context/spec/`，适用规范已列出
 - [ ] 审查结论已写入方案末尾
 
 **审查结论不通过时不得报告 "Step 3b 完成"。**

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

@@ -32,9 +32,9 @@
 
 | 来源 | 结论 | 对本方案的影响 |
 |------|------|----------------|
-| `.planning/milestones/...` | {{结论}} | {{影响}} |
-| `.planning/requirements/...` | {{结论}} | {{影响}} |
-| `.planning/lessons/...` | {{结论}} | {{影响}} |
+| `.devflow/planning/milestones/...` | {{结论}} | {{影响}} |
+| `.devflow/planning/requirements/...` | {{结论}} | {{影响}} |
+| `.devflow/planning/lessons/...` | {{结论}} | {{影响}} |
 
 ## 三、页面结构
 
@@ -118,15 +118,15 @@ sequenceDiagram
 
 | 规则来源 | 是否存在 | 影响说明 |
 |----------|----------|----------|
-| `.planning/rules/INDEX.md` | {{是/否}} | {{说明}} |
-| `.planning/execution-contract.md` | {{是/否}} | {{说明}} |
-| `.planning/toolchain.md` | {{是/否}} | {{说明}} |
-| `.planning/lessons/README.md` | {{是/否}} | {{说明}} |
-| `.context/spec/frontend/index.md` | {{是/否}} | {{说明}} |
-| `.context/spec/frontend/` | {{是/否}} | {{说明}} |
-| `.context/spec/design/` | {{是/否}} | {{说明}} |
-| `.context/workflow/` | {{是/否}} | {{说明}} |
-| `.context/lessons/README.md` | {{是/否}} | {{说明}} |
+| `.devflow/planning/rules/INDEX.md` | {{是/否}} | {{说明}} |
+| `.devflow/planning/execution-contract.md` | {{是/否}} | {{说明}} |
+| `.devflow/planning/toolchain.md` | {{是/否}} | {{说明}} |
+| `.devflow/planning/lessons/README.md` | {{是/否}} | {{说明}} |
+| `.devflow/context/spec/frontend/index.md` | {{是/否}} | {{说明}} |
+| `.devflow/context/spec/frontend/` | {{是/否}} | {{说明}} |
+| `.devflow/context/spec/design/` | {{是/否}} | {{说明}} |
+| `.devflow/context/workflow/` | {{是/否}} | {{说明}} |
+| `.devflow/context/lessons/README.md` | {{是/否}} | {{说明}} |
 | `AGENTS.md` / `CLAUDE.md` | {{是/否}} | {{说明}} |
 
 ### 7.2 适用设计系统与组件规范
@@ -140,8 +140,8 @@ sequenceDiagram
 | 来源类型 | 来源文件/章节 | 是否作为实现依据 | 处理方式 |
 |----------|---------------|------------------|----------|
 | 设计稿事实 | {{UI-SPEC 章节或设计稿}} | 是 | {{进入组件样式、变量、布局实现}} |
-| 现有项目规范 | {{现有代码/.context/spec/design/tokens/project-tokens.md}} | 是 | {{复用变量、组件、样式模式}} |
-| 推荐参考 | {{.context/spec/design/recommendations 或 ui-ux-pro-max 查询结果}} | 否 | {{仅进入风险、测试门禁或待确认事项}} |
+| 现有项目规范 | {{现有代码/.devflow/context/spec/design/tokens/project-tokens.md}} | 是 | {{复用变量、组件、样式模式}} |
+| 推荐参考 | {{.devflow/context/spec/design/recommendations 或 ui-ux-pro-max 查询结果}} | 否 | {{仅进入风险、测试门禁或待确认事项}} |
 
 说明：UI-SPEC 中标记为“推荐 - 待拍板”的内容，未经用户确认不得作为组件 props、样式变量或实现常量直接落地。
 
@@ -153,7 +153,7 @@ sequenceDiagram
 | React | {{是/否}} | {{package.json/入口文件}} | {{hooks/state/query/component 约束}} |
 | Next.js | {{是/否}} | {{next.config/app/pages}} | {{server/client component、data fetching、cache、hydration 约束}} |
 | Vue | {{是/否}} | {{vue 依赖/.vue 文件}} | {{SFC、Composition API、Pinia/router/composable 约束}} |
-| Design Recommendations | {{是/否}} | `.context/spec/design/index.md` | {{UX/accessibility/responsive/stack 推荐如何补充，但不覆盖项目规则}} |
+| Design Recommendations | {{是/否}} | `.devflow/context/spec/design/index.md` | {{UX/accessibility/responsive/stack 推荐如何补充，但不覆盖项目规则}} |
 | ui-ux-pro-max | {{是/否}} | {{是否需要动态查询}} | {{查询命令、摘要、是否存在待确认项}} |
 | 未覆盖框架 | {{框架名或无}} | {{触发依据}} | {{按 Common Web 处理并标记待扩展}} |
 

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/references/affected-module-exploration.md

@@ -14,7 +14,7 @@
 
 ### 步骤1：定位关键文件
 
-优先使用 `.planning/code-index/` 定位候选 route/page/component/store/API symbols，以及 `routes_to`、`imports`、`calls` 关系；然后回读 `evidence_path:evidence_line` 附近源码。code-index 不存在或过期时，再按下表的目录约定和 `rg` 兜底。
+优先使用 `.devflow/planning/code-index/` 定位候选 route/page/component/store/API symbols，以及 `routes_to`、`imports`、`calls` 关系；然后回读 `evidence_path:evidence_line` 附近源码。code-index 不存在或过期时，再按下表的目录约定和 `rg` 兜底。
 
 | 层级 | 定位方式 | 最少读取 |
 |------|----------|----------|
@@ -53,6 +53,6 @@
 - [ ] 是否列出了每个受影响组件的**现有** props/emits/methods/API 调用？
 - [ ] 是否明确了每个受影响组件是"保留"、"分支"、"抽离"还是"新增"？
 - [ ] 是否实际读取了 .vue 组件源码和 .js API 文件（不是仅靠文件名推断）？
-- [ ] 若 `.planning/code-index/` 存在，是否记录了用于定位的 symbol/relation evidence？
+- [ ] 若 `.devflow/planning/code-index/` 存在，是否记录了用于定位的 symbol/relation evidence？
 
 **此检查不通过，不得进入 Phase 3（生成文档）。**

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/references/project-rule-contract.md

@@ -6,39 +6,39 @@ Use this contract when generating frontend technical plans. A project rule packa
 
 Look for rule sources in the target project, in this order:
 
-1. `.planning/rules/INDEX.md`
-2. `.planning/execution-contract.md`
-3. `.planning/toolchain.md`
-4. `.planning/lessons/README.md`
-5. `.planning/milestones/`
-6. `.planning/requirements/`
-7. `.context/spec/index.md`
-8. matching `.context/spec/stacks/{stack_key}.md`
-9. matching `.context/spec/frontend/{codebase}.md`
-10. `.context/spec/frontend/index.md`
-11. `.context/spec/frontend/`
-12. `.context/spec/design/`
-13. `.planning/code-index/` when source-level route/component/API/data-flow relation facts are needed
-14. `.context/workflow/tdd.md`
-15. `.context/workflow/verification.md`
-16. `.context/workflow/checklist.md`
-17. `.context/lessons/README.md`
+1. `.devflow/planning/rules/INDEX.md`
+2. `.devflow/planning/execution-contract.md`
+3. `.devflow/planning/toolchain.md`
+4. `.devflow/planning/lessons/README.md`
+5. `.devflow/planning/milestones/`
+6. `.devflow/planning/requirements/`
+7. `.devflow/context/spec/index.md`
+8. matching `.devflow/context/spec/stacks/{stack_key}.md`
+9. matching `.devflow/context/spec/frontend/{codebase}.md`
+10. `.devflow/context/spec/frontend/index.md`
+11. `.devflow/context/spec/frontend/`
+12. `.devflow/context/spec/design/`
+13. `.devflow/planning/code-index/` when source-level route/component/API/data-flow relation facts are needed
+14. `.devflow/context/workflow/tdd.md`
+15. `.devflow/context/workflow/verification.md`
+16. `.devflow/context/workflow/checklist.md`
+17. `.devflow/context/lessons/README.md`
 18. root `AGENTS.md`, `CLAUDE.md`, or equivalent project instruction files
 
 If none exist, explicitly write `未发现项目规则包` and continue with code exploration and conservative assumptions.
 
 History rule:
 
-- Use `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and phase `CONTEXT.md` files as the primary history model.
-- Treat `.context/lessons/` and `features/` as compatible legacy/project-rule evidence only when present in the target project.
+- Use `.devflow/planning/milestones/`, `.devflow/planning/requirements/`, `.devflow/planning/lessons/`, and phase `CONTEXT.md` files as the primary history model.
+- Treat `.devflow/context/lessons/` and `features/` as compatible legacy/project-rule evidence only when present in the target project.
 - Do not require outbound-call style history files.
 
 Design rule loading:
 
-- If `.context/spec/design/index.md` is missing, call `devflow_design_rule(args=[])` from the target repository, then re-check `.context/spec/design/index.md`.
-- If `.context/spec/design/index.md` exists, read it before individual design files.
-- Treat `.context/spec/design/tokens/project-tokens.md` as project-level confirmed tokens only when it explicitly marks values as confirmed.
-- Treat `.context/spec/design/recommendations/` and `.context/spec/design/tools/ui-ux-pro-max/` as recommendation sources, not authoritative project facts.
+- If `.devflow/context/spec/design/index.md` is missing, call `devflow_design_rule(args=[])` from the target repository, then re-check `.devflow/context/spec/design/index.md`.
+- If `.devflow/context/spec/design/index.md` exists, read it before individual design files.
+- Treat `.devflow/context/spec/design/tokens/project-tokens.md` as project-level confirmed tokens only when it explicitly marks values as confirmed.
+- Treat `.devflow/context/spec/design/recommendations/` and `.devflow/context/spec/design/tools/ui-ux-pro-max/` as recommendation sources, not authoritative project facts.
 - Recommendation sources can fill UX, accessibility, responsive, component and stack guidance gaps, but conflicts with design material, code, baseline decisions or project tokens must become risks or pending questions.
 
 ## Stack Slot Loading
@@ -60,8 +60,8 @@ Project-specific rules override stack slot defaults. Stack slots fill gaps only
 Extract only frontend-relevant rules:
 
 - Technology stack, framework, router, module boundaries, and package manager.
-- Matching stack spec and codebase spec from `.context/spec/index.md` when available.
-- Code-index symbols/relations for affected routes, pages, components, stores, API clients, imports and calls when `.planning/code-index/` exists.
+- Matching stack spec and codebase spec from `.devflow/context/spec/index.md` when available.
+- Code-index symbols/relations for affected routes, pages, components, stores, API clients, imports and calls when `.devflow/planning/code-index/` exists.
 - Design system, UI library, component hierarchy, reusable component rules, icon rules, and style/theming rules.
 - Confirmed design tokens separately from recommendation-only UI/UX guidance.
 - Page, route, layout, permission, menu, tab, dialog, form, table, empty state, loading state, error state, and confirmation interaction rules.

package/plugins/devflow-design/skills/workflow-integration-verify/SKILL.md

@@ -25,8 +25,8 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 
 ## 产出位置
 
-- `.planning/features/{功能名}/integration-report.md`
-- `.planning/features/{功能名}/integration-report.meta.json`
+- `.devflow/planning/features/{功能名}/integration-report.md`
+- `.devflow/planning/features/{功能名}/integration-report.meta.json`
 
 `integration-report.meta.json` 必须包含：
 
@@ -45,13 +45,13 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 
 ## 输入
 
-- `.planning/features/{功能名}/api-contract.md` — **API 签名唯一权威源**
-- `.planning/features/{功能名}/api-call-guide.md` — Track A 产出的调用指南
-- `.planning/features/{功能名}/前端技术方案.md` — Track B 产出的前端方案
-- `.planning/features/{功能名}/后端技术方案.md` — Track A 产出的后端方案
-- `.planning/features/{功能名}/api-supplement-requests.md` —（可选）Track B 提交的 API 补充需求
-- `.planning/code-index/`（如存在）— 用于抽查 API route/handler、frontend API calls、imports/calls 关系，并回读源码 evidence
-- `.planning/requirements/{feature}/traceability.json` — 原子 REQ 的唯一追溯源
+- `.devflow/planning/features/{功能名}/api-contract.md` — **API 签名唯一权威源**
+- `.devflow/planning/features/{功能名}/api-call-guide.md` — Track A 产出的调用指南
+- `.devflow/planning/features/{功能名}/前端技术方案.md` — Track B 产出的前端方案
+- `.devflow/planning/features/{功能名}/后端技术方案.md` — Track A 产出的后端方案
+- `.devflow/planning/features/{功能名}/api-supplement-requests.md` —（可选）Track B 提交的 API 补充需求
+- `.devflow/planning/code-index/`（如存在）— 用于抽查 API route/handler、frontend API calls、imports/calls 关系，并回读源码 evidence
+- `.devflow/planning/requirements/{feature}/traceability.json` — 原子 REQ 的唯一追溯源
 
 ## 核心原则
 
@@ -59,7 +59,7 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 2. **逐 API 验证** — 每个 API 检验：后端方案中的实现 ↔ API 契约 ↔ 前端调用方式
 3. **不匹配分级** — 标记不匹配项的严重级别（阻塞 / 非阻塞）
 4. **以 api-contract.md 为准** — 前后端方案与契约不一致时，以契约为准
-5. **源码事实必须有 evidence** — 当 `.planning/code-index/` 存在且验证涉及已实现代码时，先查 Symbol/Relation，再回读 `evidence_path:evidence_line`；不得只凭 Markdown navigation 或 relation 摘要判断实现一致性
+5. **源码事实必须有 evidence** — 当 `.devflow/planning/code-index/` 存在且验证涉及已实现代码时，先查 Symbol/Relation，再回读 `evidence_path:evidence_line`；不得只凭 Markdown navigation 或 relation 摘要判断实现一致性
 
 ## 验证流程
 
@@ -79,7 +79,7 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 - API 参数和响应签名
 - 与 API 契约的差异
 
-若 `.planning/code-index/` 存在，按 endpoint、handler、controller/service 名称查询后端 symbols 和 `routes_to` / `calls` / reads/writes 关系，读取源码 evidence 后抽查实现位置是否与方案和契约一致。
+若 `.devflow/planning/code-index/` 存在，按 endpoint、handler、controller/service 名称查询后端 symbols 和 `routes_to` / `calls` / reads/writes 关系，读取源码 evidence 后抽查实现位置是否与方案和契约一致。
 
 逐项对比：后端方案中的 API 描述是否与契约一致？
 
@@ -94,7 +94,7 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 - 调用步骤中的请求示例
 - 预期的响应结构
 
-若 `.planning/code-index/` 存在，按 endpoint、API client 方法、页面/组件名查询前端 symbols 和 `imports` / `calls` 关系，读取源码 evidence 后抽查调用方式是否与契约一致。
+若 `.devflow/planning/code-index/` 存在，按 endpoint、API client 方法、页面/组件名查询前端 symbols 和 `imports` / `calls` 关系，读取源码 evidence 后抽查调用方式是否与契约一致。
 
 逐项对比：前端调用的 API 是否与契约一致？
 
@@ -113,7 +113,7 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 
 1. 将后端、前端、UI、API 契约中的设计项写入 `traceability.json.designs`，每项以 `requirements: ["REQ-…"]` 回指来源。
 2. 所有 API 类型设计必须在 `contract` 中同时写 `request`、`response`、`errors`、`behavior`；禁止只对齐响应字段。
-3. 执行 `python3 <workflow-orchestrator>/scripts/traceability_check.py --file .planning/requirements/{feature}/traceability.json --stage design`。
+3. 执行 `python3 <workflow-orchestrator>/scripts/traceability_check.py --file .devflow/planning/requirements/{feature}/traceability.json --stage design`。
 4. 结果不为 passed 时，`merge_gate_status` 必须为 failed，`blocking_issue_count` 必须大于 0，回到对应方案修复；不得进入变更清单。
 
 ## 产出模板

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

@@ -12,15 +12,15 @@ argument-hint: <功能名> [@设计稿路径] [--auto]
 user-invocable: true
 pattern: generator+reviewer
 inputs:
-- .planning/requirements/baseline.md
-- .planning/PROJECT.md
-- .planning/navigation/INDEX.md
-- .planning/rules/INDEX.md
-- .context/spec/frontend/index.md
-- .context/spec/frontend/
-- .context/spec/design/
+- .devflow/planning/requirements/baseline.md
+- .devflow/planning/PROJECT.md
+- .devflow/planning/navigation/INDEX.md
+- .devflow/planning/rules/INDEX.md
+- .devflow/context/spec/frontend/index.md
+- .devflow/context/spec/frontend/
+- .devflow/context/spec/design/
 - references/affected-module-exploration.md
-output: .planning/features/{功能名}/UI-SPEC.md
+output: .devflow/planning/features/{功能名}/UI-SPEC.md
 allowed-tools:
 - Read
 - Write
@@ -79,31 +79,31 @@ UI-SPEC 不写代码细节（那是前端技术方案的事），但必须把 UI
 
 ### 第二阶段：理解产品上下文
 
-1. 读取 `.planning/requirements/baseline.md`，提取：
+1. 读取 `.devflow/planning/requirements/baseline.md`，提取：
    - 涉及的页面/弹窗/区域列表
    - 与 UI 相关的用户拍板决策（布局偏好、交互方式、组件选择）
    - `反向审视与用户拍板` 中影响 UI 的决策
-2. 读取 `.planning/PROJECT.md` 了解前端代码库位置
-3. 按 `.planning/rules/INDEX.md` 加载前端规范（`.context/spec/frontend/`、`.context/spec/design/`）
-4. 若 `.context/spec/design/index.md` 不存在，先通过 OMP 运行时安装共享设计规则包：
+2. 读取 `.devflow/planning/PROJECT.md` 了解前端代码库位置
+3. 按 `.devflow/planning/rules/INDEX.md` 加载前端规范（`.devflow/context/spec/frontend/`、`.devflow/context/spec/design/`）
+4. 若 `.devflow/context/spec/design/index.md` 不存在，先通过 OMP 运行时安装共享设计规则包：
    ```text
    devflow_design_rule(args=[])
    ```
-   安装后重新检查 `.context/spec/design/index.md`。如果仍不存在，记录“未发现设计规则包”，继续使用设计稿和现有代码保守分析。
-5. 若存在 `.context/spec/design/index.md`，必须读取该入口，并按入口说明加载：
-   - 项目已确认 token：`.context/spec/design/tokens/project-tokens.md`
-   - 通用设计推荐：`.context/spec/design/recommendations/`
-   - 动态推荐工具：`.context/spec/design/tools/ui-ux-pro-max/scripts/search.py`
+   安装后重新检查 `.devflow/context/spec/design/index.md`。如果仍不存在，记录“未发现设计规则包”，继续使用设计稿和现有代码保守分析。
+5. 若存在 `.devflow/context/spec/design/index.md`，必须读取该入口，并按入口说明加载：
+   - 项目已确认 token：`.devflow/context/spec/design/tokens/project-tokens.md`
+   - 通用设计推荐：`.devflow/context/spec/design/recommendations/`
+   - 动态推荐工具：`.devflow/context/spec/design/tools/ui-ux-pro-max/scripts/search.py`
 6. 在以下情况调用 `ui-ux-pro-max` 动态推荐工具补充设计参考：
    - 无设计稿，但需求需要页面风格、配色、字体、布局建议
    - 设计稿未覆盖颜色、字体、间距、圆角、阴影、响应式、可访问性或状态细节
    - 需要按产品类型/行业/风格生成候选设计系统
    推荐命令示例：
    ```bash
-   python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "<产品类型> <行业> <风格关键词>" --design-system -p "<功能名>" --format markdown
-   python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "loading error accessibility responsive" --domain ux
+   python3 .devflow/context/spec/design/tools/ui-ux-pro-max/scripts/search.py "<产品类型> <行业> <风格关键词>" --design-system -p "<功能名>" --format markdown
+   python3 .devflow/context/spec/design/tools/ui-ux-pro-max/scripts/search.py "loading error accessibility responsive" --domain ux
    ```
-7. 设计结论合并优先级必须为：用户拍板/设计稿事实/需求基线 > 现有代码与项目 token > `.context/spec/design/tokens/project-tokens.md` > `ui-ux-pro-max` 推荐。推荐结果只能作为“推荐 - 待拍板”，不得覆盖设计稿事实或现有项目规范。
+7. 设计结论合并优先级必须为：用户拍板/设计稿事实/需求基线 > 现有代码与项目 token > `.devflow/context/spec/design/tokens/project-tokens.md` > `ui-ux-pro-max` 推荐。推荐结果只能作为“推荐 - 待拍板”，不得覆盖设计稿事实或现有项目规范。
 
 ### 第三阶段：设计解析
 
@@ -150,8 +150,8 @@ UI-SPEC 不写代码细节（那是前端技术方案的事），但必须把 UI
 设计 Token 必须分来源输出：
 
 - **设计稿事实**：来自截图/Figma/蓝湖/用户已确认设计描述，可作为下游实现依据。
-- **现有项目规范**：来自现有代码、组件库或 `.context/spec/design/tokens/project-tokens.md`，可作为下游实现依据。
-- **推荐 - 待拍板**：来自 `.context/spec/design/recommendations/` 或 `ui-ux-pro-max` 动态查询，只能进入待确认事项，用户确认前不得被前端技术方案当作已确认实现值。
+- **现有项目规范**：来自现有代码、组件库或 `.devflow/context/spec/design/tokens/project-tokens.md`，可作为下游实现依据。
+- **推荐 - 待拍板**：来自 `.devflow/context/spec/design/recommendations/` 或 `ui-ux-pro-max` 动态查询，只能进入待确认事项，用户确认前不得被前端技术方案当作已确认实现值。
 
 #### 3.4 交互流程
 
@@ -200,7 +200,7 @@ UI-SPEC 不写代码细节（那是前端技术方案的事），但必须把 UI
 
 ### 第五阶段：生成 UI-SPEC.md
 
-1. 创建/确认 `.planning/features/{功能名}/` 目录
+1. 创建/确认 `.devflow/planning/features/{功能名}/` 目录
 2. 读取 `assets/ui-spec-template.md` 模板
 3. 按模板结构填充所有章节，并在设计 Token 与交互章节中标明来源：设计稿事实 / 现有项目规范 / 推荐 - 待拍板
 4. 将所有来自推荐源且影响实现的候选值写入“待确认事项”