@guanlin4924/devflow-pi 0.1.0

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

@@ -0,0 +1,204 @@
+# 前端技术方案：{{功能名称}}
+
+## 一、功能概述
+
+{{简要描述功能和业务背景，2-3 句话}}
+
+### 1.1 当前执行切片
+
+- **Slice ID**：{{SL-001}}
+- **切片名称**：{{切片名称}}
+- **纳入范围**：{{FP/BR/BC 列表}}
+- **后置范围**：{{SL-002 等，仅作上下文}}
+- **切片门禁**：{{本切片通过标准}}
+
+## 二、需求基线衔接
+
+### 2.1 需求来源与功能点映射
+
+| 基线对象 | 名称/摘要 | 前端处理方式 |
+|----------|-----------|--------------|
+| FP-001 | {{功能点名称}} | {{新增/修改/影响/不涉及前端}} |
+| BR-001 | {{业务规则}} | {{前端展示/校验/交互承接方式}} |
+| BC-001 | {{边界场景}} | {{前端状态或提示承接方式}} |
+
+### 2.2 反向审视与用户拍板承接
+
+| CR ID | 维度 | 用户决策/状态 | 对前端方案的影响 |
+|-------|------|---------------|------------------|
+| CR-001 | {{冲突/复用/历史/过度工程/替代方案}} | {{已确认/待确认/不适用}} | {{方案如何承接；待确认则说明阻塞点}} |
+
+### 2.3 历史/里程碑依据
+
+| 来源 | 结论 | 对本方案的影响 |
+|------|------|----------------|
+| `.planning/milestones/...` | {{结论}} | {{影响}} |
+| `.planning/requirements/...` | {{结论}} | {{影响}} |
+| `.planning/lessons/...` | {{结论}} | {{影响}} |
+
+## 三、页面结构
+
+### 3.1 路由变更
+
+| 路径 | 页面组件 | 权限 | 说明 |
+|------|---------|------|------|
+| /xxx | XxxPage.vue | admin | 新增/修改 |
+
+### 3.2 组件树
+
+```mermaid
+graph TD
+    Page[页面组件] --> Header[头部]
+    Page --> Filter[筛选区]
+    Page --> Table[表格区]
+    Page --> Dialog[弹窗]
+    Table --> Col1[列:字段A]
+    Table --> Col2[列:字段B]
+    Table --> ColOp[列:操作]
+    ColOp --> BtnEdit[编辑按钮]
+    ColOp --> BtnDel[删除按钮]
+    Dialog --> Form[表单]
+    Form --> Field1[字段A]
+    Form --> Field2[字段B]
+```
+
+### 3.3 新增/修改组件
+
+| 组件名 | 状态 | 输入 Props | 输出 Events |
+|--------|------|-----------|------------|
+| XxxForm | 新增 | modelValue | @submit |
+
+## 四、交互流程
+
+### 4.1 用户操作流程
+
+```mermaid
+sequenceDiagram
+    User->>Page: 点击新增按钮
+    Page->>Dialog: 打开新增弹窗
+    User->>Form: 填写表单
+    User->>Form: 点击提交
+    Form->>API: POST /api/xxx
+    API-->>Form: 返回成功
+    Form->>Table: 刷新列表
+```
+
+### 4.2 状态管理
+
+| 状态 | 类型 | 说明 |
+|------|------|------|
+| loading | boolean | 加载态 |
+| list | Array | 列表数据 |
+| dialogVisible | boolean | 弹窗显隐 |
+
+## 五、接口依赖
+
+### 5.1 新增接口
+
+| 接口 | 方法 | 请求参数 | 响应 |
+|------|------|---------|------|
+| /api/xxx | POST | {name} | {id, name} |
+
+### 5.2 修改接口
+
+| 接口 | 变更点 | 兼容性 |
+|------|--------|--------|
+| /api/yyy | 响应新增字段 age | 向后兼容 |
+
+## 六、影响范围
+
+| 现有页面/组件 | 影响点 | 影响程度 |
+|-------------|--------|----------|
+| 页面A | 新增筛选条件 | 低 |
+| 组件B | 新增 props | 低 |
+
+## 七、前端规范影响
+
+### 7.1 已读取规则来源
+
+| 规则来源 | 是否存在 | 影响说明 |
+|----------|----------|----------|
+| `.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` | {{是/否}} | {{说明}} |
+| `AGENTS.md` / `CLAUDE.md` | {{是/否}} | {{说明}} |
+
+### 7.2 适用设计系统与组件规范
+
+| 场景 | 适用规范 | 对本功能的约束 |
+|------|----------|----------------|
+| {{页面/组件/表单/表格/弹窗/按钮/菜单/权限}} | {{规范文件或章节}} | {{组件选择、布局、文案、交互、样式约束}} |
+
+### 7.3 设计输入来源分层
+
+| 来源类型 | 来源文件/章节 | 是否作为实现依据 | 处理方式 |
+|----------|---------------|------------------|----------|
+| 设计稿事实 | {{UI-SPEC 章节或设计稿}} | 是 | {{进入组件样式、变量、布局实现}} |
+| 现有项目规范 | {{现有代码/.context/spec/design/tokens/project-tokens.md}} | 是 | {{复用变量、组件、样式模式}} |
+| 推荐参考 | {{.context/spec/design/recommendations 或 ui-ux-pro-max 查询结果}} | 否 | {{仅进入风险、测试门禁或待确认事项}} |
+
+说明：UI-SPEC 中标记为“推荐 - 待拍板”的内容，未经用户确认不得作为组件 props、样式变量或实现常量直接落地。
+
+### 7.4 技术栈插槽
+
+| 插槽 | 是否加载 | 触发依据 | 对本功能的约束 |
+|------|----------|----------|----------------|
+| Common Web | 是 | 所有前端项目 | {{通用页面、状态、交互、响应式、可访问性约束}} |
+| 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 推荐如何补充，但不覆盖项目规则}} |
+| ui-ux-pro-max | {{是/否}} | {{是否需要动态查询}} | {{查询命令、摘要、是否存在待确认项}} |
+| 未覆盖框架 | {{框架名或无}} | {{触发依据}} | {{按 Common Web 处理并标记待扩展}} |
+
+### 7.5 状态与交互门禁
+
+| 状态/交互 | 要求 | 验证方式 |
+|-----------|------|----------|
+| Loading | {{要求}} | {{验证方式}} |
+| Empty | {{要求}} | {{验证方式}} |
+| Error | {{要求}} | {{验证方式}} |
+| Permission | {{要求}} | {{验证方式}} |
+| Disabled | {{要求}} | {{验证方式}} |
+| Duplicate Submit | {{要求}} | {{验证方式}} |
+| Responsive | {{要求}} | {{验证方式}} |
+| Accessibility | {{要求}} | {{验证方式}} |
+
+### 7.6 状态管理与 API 调用约束
+
+| 项目 | 规则 | 对本功能的影响 |
+|------|------|----------------|
+| API Client | {{规则}} | {{影响}} |
+| State / Store | {{规则}} | {{影响}} |
+| Cache | {{规则}} | {{影响}} |
+| Validation | {{规则}} | {{影响}} |
+| Enum / Format | {{规则}} | {{影响}} |
+
+### 7.7 相关经验教训
+
+| 教训ID/来源 | 内容摘要 | 本功能规避方式 |
+|-------------|----------|----------------|
+| {{L001/文档路径}} | {{摘要}} | {{如何避免}} |
+
+### 7.8 工具链与验证门禁
+
+| 门禁 | 命令/工具 | 通过标准 |
+|------|-----------|----------|
+| Typecheck | {{命令}} | {{通过标准}} |
+| Lint | {{命令}} | {{通过标准}} |
+| Unit/Component Test | {{命令}} | {{通过标准}} |
+| E2E/Browser Test | {{命令}} | {{通过标准}} |
+| Build | {{命令}} | {{通过标准}} |
+| Screenshot/Visual Check | {{命令或方式}} | {{通过标准}} |
+| Accessibility Check | {{命令或方式}} | {{通过标准}} |
+
+## 八、待确认事项
+
+1. [ ] 确认 UI 设计稿
+2. [ ] 确认接口返回格式

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

@@ -0,0 +1,58 @@
+# 被影响方探索指引（前端）
+
+在完成主功能方（需求直接对应的页面/组件）的代码探索后，**必须**对需求基线中"关联历史功能/模块"表格（baseline 第8.2节）列出的每个受影响的前端页面/组件，执行以下探索。探索产出直接填入输出文档的"影响范围"章节和组件树。
+
+## 核心原则
+
+- **先读懂现有组件，再设计新组件**：不知道 `blind-box.vue` 现在的 props/emits/methods/API 调用，就无法正确决定从哪里切分、哪些保留哪些抽离。
+- **被影响组件和新增组件同等重要**：支付相关的现有 API 封装、地址选择组件、必中卡组件等被影响方必须和新增组件一样被完整阅读。
+- **探索产出必须来自代码**：组件树、状态流、API 调用方式必须来自实际读取的源码。
+
+## 探索清单
+
+对于每个受影响的前端页面/组件，按以下步骤执行：
+
+### 步骤1：定位关键文件
+
+优先使用 `.planning/code-index/` 定位候选 route/page/component/store/API symbols，以及 `routes_to`、`imports`、`calls` 关系；然后回读 `evidence_path:evidence_line` 附近源码。code-index 不存在或过期时，再按下表的目录约定和 `rg` 兜底。
+
+| 层级 | 定位方式 | 最少读取 |
+|------|----------|----------|
+| 页面入口 | `src/pages/{page}/` 下的 .vue 文件 | template 结构、script setup 中的核心逻辑 |
+| 业务组件 | `src/components/fan-superstar/{module}/` 下的 .vue 文件 | **完整读取** props/emits 定义、data/reactive 状态、computed、methods |
+| API 调用 | `src/api/` 或 `src/components/fan-superstar/service/` 下的 .js/.ts 文件 | 现有方法签名、请求参数、响应结构 |
+| 路由配置 | `src/pages.json` 或 `src/router/` | 现有路由路径、参数、meta |
+| 状态管理 | `src/hooks/` 或 `src/store/` | 现有 reactive/ref 状态结构和共享 hook |
+| 样式系统 | UnoCSS 配置、scss 变量文件 | 现有原子类命名规则和色值变量 |
+
+**底线**：每个被影响组件至少读取 3 个文件（组件源码 + API 文件 + 父/入口组件），不能仅靠组件名、navigation 或 code-index 摘要推断。
+
+### 步骤2：回答三个问题
+
+| 问题 | 产出 | 填入模板章节 |
+|------|------|-------------|
+| 现有组件长什么样？ | 现有 props/emits/data/computed/methods 的结构化清单 | 影响范围章节中"现有文件"的描述 |
+| 现有数据怎么流动？ | 组件间的父子关系、API 调用链、状态共享方式 | 组件树和交互流程 |
+| 现有交互怎么触发？ | 现有的 @click/@change/watch/onLoad 等事件绑定 | 交互流程的现状部分 |
+
+### 步骤3：判断复用/重构/新增边界
+
+对每个被影响组件，明确以下决策：
+
+| 决策类型 | 说明 | 示例 |
+|----------|------|------|
+| 保留不动 | 组件现有逻辑和模板不受影响 | 闲鱼模式下的获取兑奖码流程 |
+| 新增分支 | 组件内部按 `participateMode` 或其他条件渲染不同模板 | `blind-box.vue` 按模式显示不同内容 |
+| 抽离重构 | 部分现有逻辑提取到新组件，原组件变为组合入口 | 现金支付卡片独立为 `blind-box-cash-card.vue` |
+| 新增组件 | 新增独立 .vue 组件 | `blind-box-pay-confirm.vue` 支付确认弹窗 |
+| 扩展 API | 现有 API 文件新增方法 | `service/mall.js` 新增 `createPayOrder` |
+
+## 探索产出检查（Phase 2 完成前必须全部通过）
+
+- [ ] 是否对每个受影响的现有页面/组件都执行了步骤1~3？
+- [ ] 是否列出了每个受影响组件的**现有** props/emits/methods/API 调用？
+- [ ] 是否明确了每个受影响组件是"保留"、"分支"、"抽离"还是"新增"？
+- [ ] 是否实际读取了 .vue 组件源码和 .js API 文件（不是仅靠文件名推断）？
+- [ ] 若 `.planning/code-index/` 存在，是否记录了用于定位的 symbol/relation evidence？
+
+**此检查不通过，不得进入 Phase 3（生成文档）。**

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/references/component-patterns.md

@@ -0,0 +1,42 @@
+# 前端组件模式参考
+
+## 页面结构模式
+
+### 后台标准页面
+```
+Page
+├── PageHeader（标题 + 操作按钮）
+├── FilterBar（筛选条件）
+├── DataTable（数据列表）
+└── Dialog/Modal（新增/编辑/详情弹窗）
+```
+
+### 表单页面
+```
+FormPage
+├── PageHeader
+├── Form（表单项）
+└── Footer（提交/取消按钮）
+```
+
+## 状态管理模式
+
+### 列表页 Store
+```javascript
+state: {
+  list: [],
+  total: 0,
+  loading: false,
+  filters: {},
+  pagination: { page: 1, pageSize: 20 }
+}
+```
+
+### 详情/表单 Store
+```javascript
+state: {
+  detail: null,
+  loading: false,
+  submitting: false
+}
+```

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

@@ -0,0 +1,28 @@
+# 前端技术方案编写规范
+
+## 模板结构要求
+
+每次生成必须包含以下章节：
+1. 功能概述
+2. 页面结构（路由 + 组件树）
+3. 交互流程（用户操作 + 状态流转）
+4. 接口依赖（新增 + 修改）
+5. 影响范围
+6. 前端规范影响（规则来源 + 技术栈插槽 + 状态门禁 + 工具链验证）
+7. 待确认事项
+
+## 描述规则
+
+- 组件名使用 PascalCase
+- 路由路径使用 kebab-case
+- 接口路径使用小写 + 斜杠
+- 状态字段使用 camelCase
+
+## 质量要求
+
+- 所有新增组件必须有 Props/Events 说明
+- 所有接口必须有请求/响应格式
+- 交互流程必须包含成功和失败两条路径
+- 影响范围必须列出现有页面/组件的变更点
+- 前端规范影响必须说明已加载的技术栈插槽，至少包含 Common Web；识别到 React、Next.js、Vue 时加载对应插槽
+- 项目本地规则优先于技术栈插槽，插槽只补充项目未定义的默认规则

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/references/frontend-stack-slots/common-web.md

@@ -0,0 +1,53 @@
+# Common Web Frontend Stack Slot
+
+This slot applies to all browser-based frontend work, regardless of framework.
+
+## Applies When
+
+Use this slot for HTML, CSS, JavaScript, TypeScript, React, Vue, Angular, Svelte, Next, Nuxt, and mobile WebView projects.
+
+Always load this slot before framework-specific slots.
+
+## Planning Rules
+
+- Identify the user-visible entry: route, page, panel, dialog, tab, drawer, or embedded widget.
+- Preserve existing layout, component, naming, request, state, and style conventions.
+- Do not introduce a new UI library, state manager, router, CSS framework, icon library, test runner, or data-fetching library unless explicitly required.
+- Prefer existing components and patterns before creating new abstractions.
+- Every user-facing control must have loading, disabled, permission, error, and success behavior when applicable.
+- Every list or table must define empty state, loading state, error state, pagination or infinite-scroll behavior, and row operation permissions.
+- Every form must define validation source, submit behavior, duplicate-submit protection, cancel/reset behavior, and error display.
+- Every API dependency must define request parameters, response shape, error handling, and compatibility with existing callers.
+
+## Interaction States
+
+Record these states in the technical plan:
+
+- Loading.
+- Empty.
+- Error.
+- Success.
+- Permission denied or hidden actions.
+- Disabled/read-only.
+- Duplicate submit.
+- Optimistic update or rollback, when applicable.
+- Unsaved changes, when applicable.
+
+## Responsive And Accessibility
+
+- Record required viewport classes or breakpoints when the project has them.
+- Do not hide essential controls on small screens unless the requirement says so.
+- Controls must have accessible names, focus behavior, keyboard reachability, and visible disabled/loading state.
+- Text must not overflow buttons, labels, cards, table cells, dialogs, or sidebars.
+
+## Verification Gates
+
+Use project commands when available. Otherwise record missing commands as pending.
+
+- Typecheck or equivalent.
+- Lint or equivalent.
+- Unit/component tests when the project has a test setup.
+- Build.
+- Browser verification for changed routes or interactive flows.
+- Screenshot or visual check for layout-sensitive changes.
+- Accessibility check when the project has tooling or the feature affects forms, dialogs, menus, keyboard navigation, or permissions.

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/references/frontend-stack-slots/next.md

@@ -0,0 +1,40 @@
+# Next.js Frontend Stack Slot
+
+Use with `common-web.md` and `react.md`.
+
+## Detection
+
+Load this slot when the project has:
+
+- `next` dependency in `package.json`.
+- `next.config.*`.
+- `app/` or `pages/` routing.
+
+## Planning Rules
+
+- Identify router mode: App Router, Pages Router, or mixed.
+- For App Router, explicitly classify changed components as server components or client components.
+- Add `"use client"` only when client state, effects, event handlers, browser APIs, or client-only libraries are required.
+- Keep server-only data fetching and secrets out of client components.
+- Respect existing data-fetching and cache strategy: static, dynamic, revalidate, route handler, server action, API route, query client, or client fetch.
+- Record metadata, layout, loading, error, and not-found behavior when affected.
+- Preserve route segment conventions, colocated files, and existing folder naming.
+
+## Required Technical Plan Details
+
+- App Router vs Pages Router.
+- Route segments or pages affected.
+- Server/client component boundary.
+- Data fetching location and cache/revalidation behavior.
+- Loading/error/not-found files or component states.
+- Route handlers, server actions, or API routes if affected.
+- SEO metadata impact when user-facing pages change.
+
+## Verification Gates
+
+- Typecheck.
+- Lint.
+- Build.
+- Browser verification for affected routes.
+- Check server/client boundary risks.
+- Check hydration mismatch risk for dynamic data, dates, random values, browser-only APIs, and conditional rendering.

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/references/frontend-stack-slots/react.md

@@ -0,0 +1,41 @@
+# React Frontend Stack Slot
+
+Use with `common-web.md`.
+
+## Detection
+
+Load this slot when the project has:
+
+- `react` dependency in `package.json`.
+- React entry files such as `src/main.tsx`, `src/App.tsx`, `src/index.tsx`.
+- Vite, CRA, Remix, or another React-based setup.
+
+If the project is Next.js, load `next.md` in addition to this slot.
+
+## Planning Rules
+
+- Preserve existing component organization: pages/routes, feature modules, shared components, hooks, services, and stores.
+- Prefer function components and existing hook conventions.
+- Keep side effects in hooks or data-fetching utilities, not directly in render logic.
+- Avoid introducing global state when local component state or existing server/cache state is sufficient.
+- When global state is needed, use the project's existing store or query library.
+- For API calls, use the existing API client, query hook, mutation hook, interceptor, error handler, and cache invalidation pattern.
+- Memoization is a performance tool, not a default. Use it only for expensive derived values, stable callback contracts, or known rerender issues.
+
+## Required Technical Plan Details
+
+- Component tree and ownership.
+- Props and callback/event contracts.
+- Hook usage and side-effect boundaries.
+- State ownership: local state, query/cache state, or global store.
+- API query/mutation flow and cache invalidation.
+- Error boundary or fallback behavior if the project uses it.
+
+## Verification Gates
+
+- Typecheck.
+- Lint.
+- Unit/component tests for nontrivial logic or components when test setup exists.
+- Build.
+- Browser verification for changed routes.
+- Check React warnings in console when browser tooling is available.

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/references/frontend-stack-slots/vue.md

@@ -0,0 +1,41 @@
+# Vue Frontend Stack Slot
+
+Use with `common-web.md`.
+
+## Detection
+
+Load this slot when the project has:
+
+- `vue` dependency in `package.json`.
+- `vite.config.*` with Vue plugin, `vue.config.*`, or Nuxt-specific files.
+- `.vue` single-file components.
+
+If the project is Nuxt, use this slot plus a future Nuxt-specific slot when available.
+
+## Planning Rules
+
+- Preserve existing single-file component structure and naming.
+- Prefer Composition API when the project uses it; do not mix Options API and Composition API without a local precedent.
+- Put reusable logic in existing composable patterns.
+- Use existing router, route guard, permission, and layout conventions.
+- Use the existing store pattern, such as Pinia or Vuex, only when local component state is insufficient.
+- For API calls, use the existing request client, composable, interceptor, error handler, and loading pattern.
+- Keep computed values pure and side effects in watchers, lifecycle hooks, or explicit handlers.
+
+## Required Technical Plan Details
+
+- Routes/views affected.
+- Component tree and SFC ownership.
+- Props, emits, slots, and v-model contracts.
+- Composables used or added.
+- Store modules/state affected.
+- API flow and error handling.
+- Permission and route guard impact.
+
+## Verification Gates
+
+- Typecheck (`vue-tsc` or project equivalent) when available.
+- Lint.
+- Unit/component tests when the project has a test setup.
+- Build.
+- Browser verification for changed routes and dialogs.

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

@@ -0,0 +1,95 @@
+# Project Rule Package Contract
+
+Use this contract when generating frontend technical plans. A project rule package is the project-specific source of truth for how frontend work should be designed, implemented, tested, and reviewed.
+
+## Discovery Order
+
+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`
+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.
+- 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.
+- 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
+
+Load frontend stack slots after project rule discovery:
+
+1. Always read `references/frontend-stack-slots/common-web.md`.
+2. Detect the framework from `package.json`, config files, and entry files.
+3. Read the matching framework slots:
+   - React: `references/frontend-stack-slots/react.md`
+   - Next.js: `references/frontend-stack-slots/react.md` and `references/frontend-stack-slots/next.md`
+   - Vue: `references/frontend-stack-slots/vue.md`
+4. If the framework is unknown or unsupported, use only `common-web.md` and record the missing stack slot as a pending improvement.
+
+Project-specific rules override stack slot defaults. Stack slots fill gaps only when the project does not define a stronger local rule.
+
+## What To Extract
+
+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.
+- 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.
+- State management, API client, cache, request/response transform, validation, enum, i18n, and date/number formatting rules.
+- Accessibility, keyboard interaction, responsive layout, browser compatibility, and performance constraints.
+- Required code generation, type generation, API schema sync, mock data, Storybook, visual regression, browser automation, or build commands.
+- Unit, component, E2E, screenshot, accessibility, and manual verification expectations.
+- Review checklist and historical lessons that apply to this feature.
+- Confirmed requirement challenge decisions from baseline `反向审视与用户拍板`.
+- Pending baseline decisions that block frontend planning.
+
+Do not copy the entire rule source. Summarize the rules that affect the current feature.
+
+## Frontend Plan Output
+
+The frontend technical plan must include a `前端规范影响` section with:
+
+- Rule sources read.
+- Stack slots loaded.
+- Baseline challenge decisions consumed and pending blockers.
+- Affected pages, routes, components, stores, API clients, and styles.
+- Code-index evidence used or the reason it was unavailable.
+- Applicable design system and component rules.
+- Which design inputs are confirmed implementation sources and which are recommendation-only references.
+- Interaction states that must be implemented.
+- Related lessons.
+- Toolchain and generated artifact requirements.
+- Test and browser verification strategy.
+- Review gates.
+
+If a rule conflicts with the requested behavior, design material, or existing code, record it as a risk or pending question. Do not silently choose between conflicting rules.