@guanlin4924/devflow-pi 0.1.93 → 0.1.94

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. 将所有来自推荐源且影响实现的候选值写入“待确认事项”

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

@@ -8,7 +8,7 @@
 
 **设计来源**: {设计稿路径/截图说明}
 **解析日期**: {日期}
-**上游依赖**: `.planning/features/{功能名}/功能点梳理.md`
+**上游依赖**: `.devflow/planning/features/{功能名}/功能点梳理.md`
 
 ---
 
@@ -111,8 +111,8 @@
 | 来源类型 | 来源文件/依据 | 是否可直接用于实现 | 说明 |
 |----------|---------------|--------------------|------|
 | 设计稿事实 | {截图/Figma/蓝湖/用户已确认设计描述} | 是 | {明确来自设计稿的颜色、字号、间距、圆角、阴影等} |
-| 现有项目规范 | {现有代码变量/组件库/.context/spec/design/tokens/project-tokens.md} | 是 | {与现有变量或组件规则对齐的 token} |
-| 推荐 - 待拍板 | {.context/spec/design/recommendations 或 ui-ux-pro-max 查询结果} | 否 | {仅作为候选方案，需写入待确认事项} |
+| 现有项目规范 | {现有代码变量/组件库/.devflow/context/spec/design/tokens/project-tokens.md} | 是 | {与现有变量或组件规则对齐的 token} |
+| 推荐 - 待拍板 | {.devflow/context/spec/design/recommendations 或 ui-ux-pro-max 查询结果} | 否 | {仅作为候选方案，需写入待确认事项} |
 
 合并优先级：用户拍板/设计稿事实/需求基线 > 现有代码与项目 token > 项目级已确认 token > 推荐 - 待拍板。
 

package/plugins/devflow-implementation/agents/implementation-worker.md

@@ -19,7 +19,7 @@ autoloadSkills:
 Implement only the assigned plan slice. Do not re-plan the feature, compare alternatives, or explore unrelated modules. Read only the approved files, their immediate dependencies, and the focused tests needed for this slice. Preserve unrelated work and report deviations instead of silently expanding scope.
 
 Before any protected source access, read the project's required code-index evidence
-files in the exact order listed by INDEX_GATE (typically `.planning/code-index/INDEX.md`
+files in the exact order listed by INDEX_GATE (typically `.devflow/planning/code-index/INDEX.md`
 followed by the ordered files named by the gate). Do not attempt `grep`, `rg`, or source
 reads first: each subagent has its own evidence session and cannot inherit the parent's
 observations. If the gate lists different files, follow that list exactly.
@@ -28,4 +28,4 @@ If the execution contract is missing, ambiguous, or contradicted by the code, st
 
 For a task whose frozen `test-bindings.json` marks `test_mode: tdd_required`, use the Core tool in this exact order: `devflow_tdd_evidence(action="prepare")` before changing declared production paths; create/change the test and record `red`; implement; record `green`; then record `regression`. Do not mark the task done if any phase is missing or fails. The tool may write only its own Core-owned TDD evidence record; this exception does not authorize edits to any other Devflow control-plane file.
 
-Return `STATUS`, changed files, validation evidence, and one escalation/blocker if needed. Never edit `.planning/STATE.md`, `.planning/artifacts/index.yaml`, workflow definitions, or checkpoint decisions; the parent session owns those through Devflow tools.
+Return `STATUS`, changed files, validation evidence, and one escalation/blocker if needed. Never edit `.devflow/planning/STATE.md`, `.devflow/planning/artifacts/index.yaml`, workflow definitions, or checkpoint decisions; the parent session owns those through Devflow tools.

package/plugins/devflow-implementation/skills/workflow-bug-fix/SKILL.md

@@ -29,7 +29,7 @@ Required outputs:
 - Root-cause diagnosis containing the fields in `references/root-cause-ladder.md`.
 - Code and/or workflow-artifact repair consistent with that diagnosis.
 - Verification evidence and a context-sync result.
-- A lesson under `.context/lessons/` when the finding is reusable; if the directory or index is absent, record that limitation and do not fail solely for its absence.
+- A lesson under `.devflow/context/lessons/` when the finding is reusable; if the directory or index is absent, record that limitation and do not fail solely for its absence.
 
 Read references only at their designated phase. [references/INDEX.md](references/INDEX.md) is the routing contract; it is not optional.
 
@@ -37,7 +37,7 @@ Read references only at their designated phase. [references/INDEX.md](references
 
 1. Find the first broken layer and stop root-cause traversal there. Do not call a downstream symptom the root cause.
 2. Before classifying the cause, read `references/first-principles.md` and `references/adversarial-review.md`.
-3. Any source-level claim based on `.planning/code-index/` requires source readback at its evidence path and line. Navigation or index summaries alone are insufficient.
+3. Any source-level claim based on `.devflow/planning/code-index/` requires source readback at its evidence path and line. Navigation or index summaries alone are insufficient.
 4. `requirement-gap`, `breakdown-gap`, `spec-gap`, and `change-list-gap` require documentation repair before code repair. `implementation-bug` and `regression` do not require speculative document rewrites.
 5. Keep the repair scoped to the violated invariant. Do not slip in unrelated refactors or new feature scope.
 6. Complete verification and `workflow-context-sync --after-bugfix` before declaring success, unless the user explicitly approves an exception and its residual risk is recorded.
@@ -46,12 +46,12 @@ Read references only at their designated phase. [references/INDEX.md](references
 
 Load only what exists and is relevant, in this order:
 
-1. `.planning/STATE.md` for the active feature and phase.
-2. `.planning/requirements/baseline.md`.
-3. `.planning/features/{功能名}/功能点梳理.md`.
-4. `.planning/features/{功能名}/前端技术方案.md` and `后端技术方案.md`.
-5. `.planning/features/{功能名}/*变更清单.md`.
-6. `.planning/code-index/` and then evidence source files, when source tracing is needed.
+1. `.devflow/planning/STATE.md` for the active feature and phase.
+2. `.devflow/planning/requirements/baseline.md`.
+3. `.devflow/planning/features/{功能名}/功能点梳理.md`.
+4. `.devflow/planning/features/{功能名}/前端技术方案.md` and `后端技术方案.md`.
+5. `.devflow/planning/features/{功能名}/*变更清单.md`.
+6. `.devflow/planning/code-index/` and then evidence source files, when source tracing is needed.
 
 If an upstream artifact is absent, record it as evidence for the corresponding gap rather than silently skipping it.
 
@@ -104,7 +104,7 @@ Gate: verification demonstrates the original reproduction is fixed and the ident
 ## Phase 5 — Preserve Knowledge and Synchronize Context
 
 1. Read `references/lesson-format.md`. Write a lesson when the finding is reusable beyond this single line fix; otherwise record why no lesson is needed.
-2. If `.context/lessons/README.md` exists, append the lesson to its index. If it does not exist, retain the lesson file and report that no index was available.
+2. If `.devflow/context/lessons/README.md` exists, append the lesson to its index. If it does not exist, retain the lesson file and report that no index was available.
 3. Run `workflow-context-sync --after-bugfix`.
    - Ordinary implementation repairs refresh code-index and run validate/audit.
    - Changes to routes, API clients, handlers, jobs, service boundaries, toolchain, or manifests may require a Medium sync with navigation/spec/toolchain updates.

package/plugins/devflow-implementation/skills/workflow-bug-fix/references/lesson-format.md

@@ -2,7 +2,7 @@
 
 Write a lesson when the cause, invariant, boundary defense, or regression pattern is likely to prevent future work from repeating the failure. Do not create one for a self-evident isolated typo unless project rules require it.
 
-Write `.context/lessons/{YYYY-MM-DD}-{slug}.md`:
+Write `.devflow/context/lessons/{YYYY-MM-DD}-{slug}.md`:
 
 ```markdown
 # {Bug title}
@@ -25,4 +25,4 @@ Write `.context/lessons/{YYYY-MM-DD}-{slug}.md`:
 - **Rule for future work**: {reusable guidance}
 ```
 
-If `.context/lessons/README.md` exists, add a concise linked entry. If it does not exist, do not fail the bug fix; retain the lesson file and report that the index was unavailable.
+If `.devflow/context/lessons/README.md` exists, add a concise linked entry. If it does not exist, do not fail the bug fix; retain the lesson file and report that the index was unavailable.

package/plugins/devflow-implementation/skills/workflow-bug-fix/references/root-cause-ladder.md

@@ -13,7 +13,7 @@ Inspect in order and stop at the first broken layer. Earlier applicable layers m
 
 ## Evidence Details
 
-- Use `.planning/code-index/` to locate symbols, callers, imports, reads/writes, and tests when present; read the cited source evidence before asserting a fact.
+- Use `.devflow/planning/code-index/` to locate symbols, callers, imports, reads/writes, and tests when present; read the cited source evidence before asserting a fact.
 - If code-index is missing, stale, or has no result, use navigation and targeted source inspection, and say that machine relation facts were unavailable.
 - For implementation analysis, check completed change-list tasks, boundary/error handling, and obvious omissions such as type errors, logic reversal, or missed validation.
 - For regression analysis, run `git log --oneline -10 -- <relevant-file>` from the owning repository and inspect the relevant diff.