diff --git a/.claude/agents/frontend-api-types.md b/.claude/agents/frontend-api-types.md
new file mode 100644
index 0000000..d54c618
--- /dev/null
+++ b/.claude/agents/frontend-api-types.md
@@ -0,0 +1,28 @@
+---
+name: frontend-api-types
+description: 前端 API 与类型定义专家。用于当前项目中的 src/api 层、types.ts、返回结构、Query/Form/VO/InfoVO 定义，以及前后端接口映射任务。
+---
+
+你负责当前前端项目中的 API 层和类型定义。
+
+## 核心原则
+
+1. 先看当前模块已有 `src/api/<module>/<business>`。
+2. API 路径、返回类型、命名风格与当前模块保持一致。
+3. 能明确写出类型时，不要偷懒用 `any`。
+4. 如果当前模块已有 `export default { ... }`，继续保持一致。
+
+## 重点关注
+
+- `Query`
+- `VO`
+- `Form`
+- `InfoVO`
+- `AxiosPromise<PageResult<T>>`
+- 详情接口与列表接口返回结构
+
+## 自检
+
+- API 路径是否与后端一致
+- 类型是否覆盖接口真实结构
+- 是否不必要地把类型写宽了
diff --git a/.claude/agents/frontend-crud-coding.md b/.claude/agents/frontend-crud-coding.md
new file mode 100644
index 0000000..0a07b4f
--- /dev/null
+++ b/.claude/agents/frontend-crud-coding.md
@@ -0,0 +1,18 @@
+---
+name: frontend-crud-coding
+description: 前端总入口。用于当前前端项目中的标准 CRUD 页面、新增 API/types、复杂列表页增强、树筛选、导入导出、权限按钮与弹窗表单等任务，并根据任务类型选择合适的前端子 agent。
+---
+
+你是当前前端项目的总入口 agent。
+
+先判断任务类型，再按下面规则处理：
+
+1. 如果是新增标准 CRUD 页面、补 `src/api`、`types.ts`、`index.vue`，优先使用 `frontend-crud-page.md`。
+2. 如果是修改已有列表页、增强导入导出、树筛选、更多菜单、状态切换，优先使用 `frontend-page-enhancement.md`。
+3. 如果只改接口层和类型定义，优先使用 `frontend-api-types.md`。
+
+通用要求：
+
+- 先读当前目录下最近似页面和 API，再动代码。
+- 冲突时优先相信当前项目真实页面，其次是公共组件和工具，再其次才是关联后端工程的 generator 模板。
+- 默认直接产出可落地代码，而不是只给抽象建议。
diff --git a/.claude/agents/frontend-crud-page.md b/.claude/agents/frontend-crud-page.md
new file mode 100644
index 0000000..e653b8f
--- /dev/null
+++ b/.claude/agents/frontend-crud-page.md
@@ -0,0 +1,37 @@
+---
+name: frontend-crud-page
+description: 前端标准 CRUD 页面专家。用于当前项目中的新建列表页、弹窗表单页、标准 API/types/index.vue 骨架，以及 generator 模板到项目风格的落地任务。
+---
+
+你负责当前前端项目中的标准 CRUD 页面实现。
+
+## 核心原则
+
+1. 先看当前模块最近似页面。
+2. 再参考关联后端工程中的 generator 模板。
+3. 默认同时维护：
+   `src/api/<module>/<business>/index.ts`
+   `src/api/<module>/<business>/types.ts`
+   `src/views/<module>/<business>/index.vue`
+
+## 页面规则
+
+- 页面优先使用 `<script setup name="Xxx" lang="ts">`
+- 标准结构通常包含：
+  搜索区、表格区、工具栏、分页、编辑弹窗
+- 常见状态：
+  `loading`、`showSearch`、`ids`、`single`、`multiple`、`total`
+- 查询与表单优先使用 `reactive<PageData<Form, Query>>({...})`
+
+## API / types 规则
+
+- 请求统一通过 `@/utils/request`
+- 同目录维护 `index.ts` 与 `types.ts`
+- 标准 CRUD 通常包含：列表、详情、新增、修改、删除
+- 列表接口通常返回 `AxiosPromise<PageResult<XxxVO>>`
+
+## 自检
+
+- API 路径是否与后端一致
+- `index.ts` 与 `types.ts` 是否同步补齐
+- 页面是否只是模板裸输出，如果是要继续补强到当前项目风格
diff --git a/.claude/agents/frontend-page-enhancement.md b/.claude/agents/frontend-page-enhancement.md
new file mode 100644
index 0000000..4c75989
--- /dev/null
+++ b/.claude/agents/frontend-page-enhancement.md
@@ -0,0 +1,27 @@
+---
+name: frontend-page-enhancement
+description: 复杂前端页面增强专家。用于修改当前项目中已经存在的列表页、树筛选页、带导入导出和更多菜单的页面，强调增量修改和保留现有交互能力。
+---
+
+你负责当前前端项目中已有页面的增强，不是重写页面。
+
+## 核心原则
+
+1. 优先阅读当前页面完整实现。
+2. 增量修改，不重写整页。
+3. 保留已有树筛选、导入导出、列显隐、更多菜单、状态切换、路由跳转、SCSS 页面壳。
+4. 不要把复杂页面退化成 generator 式基础列表页。
+
+## 常见任务
+
+- 调整工具栏和更多菜单
+- 增加筛选条件和日期范围
+- 增加导入导出能力
+- 增加状态切换、快捷操作、确认弹窗
+- 补复杂页面的小型子功能
+
+## 自检
+
+- 是否破坏了原页面结构和样式
+- 是否误删了已有权限控制或交互能力
+- 是否应该拆成子组件而不是继续堆主页面
diff --git a/.codex/skills/frontend-crud-coding/SKILL.md b/.codex/skills/frontend-crud-coding/SKILL.md
new file mode 100644
index 0000000..3aaaf34
--- /dev/null
+++ b/.codex/skills/frontend-crud-coding/SKILL.md
@@ -0,0 +1,136 @@
+---
+name: frontend-crud-coding
+description: 在当前前端项目中按现有 Vue 3 + TypeScript + Element Plus 代码风格生成或修改页面、API、types、组件接入和样式。用于新增列表页、表单弹窗页、树表页、系统管理页、workflow 页面，以及补全与后端接口对应的 src/api 和 src/views 代码。
+---
+
+# 前端编码规范
+
+先对齐当前前端项目里的真实实现，再参考关联后端工程中代码生成器产出的前端模板。不要只套通用 Vue 模板，也不要把生成器模板原样照搬而忽略当前前端项目的实际演进。
+
+## 适用场景
+
+在下面这些任务里优先使用此 skill：
+
+- 新增标准 CRUD 列表页、弹窗表单页、树表页。
+- 补齐后端新增接口对应的 `src/api`、`src/views`、`types.ts`。
+- 按系统管理、监控、工作流、demo 模块现有方式扩展页面功能。
+- 调整已有列表页的搜索、导出、导入、树筛选、列显隐、权限按钮、样式壳。
+- 把关联后端工程中的 generator 模板转换为符合当前前端项目风格的实际代码。
+
+## 不适用场景
+
+下面这些任务不要机械套用本 skill 的 CRUD 规则：
+
+- 纯展示型落地页、营销页、可视化大屏。
+- 完全独立的低代码设计器或第三方嵌入页。
+- 全局框架升级、Vite 配置改造、构建链路迁移。
+- 与当前项目目录结构明显不同的实验性页面。
+
+## 执行流程
+
+1. 先定位目标模块，并阅读 `src/api/<module>/<business>` 与 `src/views/<module>/<business>` 下最近似页面。
+2. 再参考关联后端工程 `ruoyi-modules/ruoyi-generator/src/main/resources/vm/ts` 与 `vm/vue` 下的生成器模板，确认标准 CRUD 的基础骨架。
+3. 新增代码时同时维护 `api/index.ts`、`api/types.ts`、`views/.../index.vue`，必要时补相关子页面或弹窗页。
+4. 页面结构、样式组织、状态管理、权限指令、下载导出、字典使用都以仓库现有模式为准。
+5. 如果后端接口与生成器套路一致，可以用 generator 模板作为起点；如果当前前端项目已有更强约定，以当前项目约定覆盖模板默认行为。
+
+## 优先级规则
+
+发生冲突时按下面顺序决策：
+
+1. 当前目录下最近似页面的真实实现。
+2. 当前项目公共组件、公共工具、公共样式约定。
+3. 关联后端工程中的 generator 模板。
+4. 通用 Vue / Element Plus 习惯。
+
+也就是说：
+
+- 同一模块已有页面怎么写，优先怎么写。
+- 没有现成页面时，再退回到 generator 模板骨架。
+- 没有现成模式时，才使用通用框架默认写法。
+
+## 主要规则
+
+详细规则见 [references/frontend.md](references/frontend.md)。
+使用案例见 [references/examples.md](references/examples.md)。
+
+## 仓库通用规则
+
+- 遵循 [`.editorconfig`](../../../.editorconfig)：UTF-8、LF、默认 2 空格缩进。
+- 遵循 [`.prettierrc`](../../../.prettierrc)：单引号、分号、`printWidth: 150`、`trailingComma: none`。
+- 页面优先使用 `<script setup name="Xxx" lang="ts">`。
+- 优先复用仓库已有基础设施，例如 `request`、`proxy?.$modal`、`proxy?.download`、`proxy?.useDict`、`pagination`、`right-toolbar`。
+- 对于标准 CRUD 页，允许先按后端生成器模板组织 `api/types/index.vue` 骨架，再补齐当前前端项目自己的页面壳、样式和交互。
+- 新页面不要无故引入另一套状态管理、另一套请求封装或另一套 UI 风格。
+
+## 目录映射规则
+
+通常按下面的对应关系组织代码：
+
+- 后端路由 `/system/user/*` 对应 `src/api/system/user/*` 与 `src/views/system/user/*`
+- 后端路由 `/monitor/xxx/*` 对应 `src/api/monitor/xxx/*` 与 `src/views/monitor/xxx/*`
+- 后端路由 `/workflow/xxx/*` 对应 `src/api/workflow/xxx/*` 与 `src/views/workflow/xxx/*`
+- 后端路由 `/demo/xxx/*` 对应 `src/api/demo/xxx/*` 与 `src/views/demo/xxx/*`
+
+标准新增通常至少包含：
+
+- `src/api/<module>/<business>/index.ts`
+- `src/api/<module>/<business>/types.ts`
+- `src/views/<module>/<business>/index.vue`
+
+按业务复杂度，可能继续补：
+
+- 导入弹窗
+- 分配角色页
+- 详情页
+- 编辑页
+- 子组件
+- 自定义 SCSS 样式
+
+## 任务分型
+
+### 1. 标准单表 CRUD
+
+目标是快速补齐 `api + types + index.vue`，优先参考 generator 模板，再贴近 demo 或系统模块现有页。
+
+### 2. 强业务页面
+
+如果页面包含树筛选、导入导出、更多操作、状态切换、角色分配、复杂校验、联动选择，则优先参考 `src/views/system/user/index.vue` 一类更完整页面。
+
+### 3. 工作流页面
+
+如果页面属于流程定义、分类、任务、实例等 workflow 目录，优先参考 `src/views/workflow/*`，不要硬套系统管理模块的页面骨架。
+
+## 输出要求
+
+使用本 skill 时，默认期望产出应满足：
+
+- 类型完整，不把大量 `any` 塞进页面逻辑里。
+- 查询、重置、分页、弹窗、删除、导出流程闭环完整。
+- 权限指令、字典、公共组件接入到位。
+- 样式尽量贴合现有页面壳，而不是只保证“功能能跑”。
+- 如果是从 generator 模板演化而来，要体现出当前前端项目已有增强，而不是模板裸输出。
+
+## 快速检查清单
+
+- API 路径与后端路由完全对应。
+- `src/api` 中同时维护 `index.ts` 和 `types.ts`。
+- 列表页查询、重置、导出、删除、弹窗提交流程与现有页一致。
+- 继续使用项目内权限指令与公共组件。
+- 表单、查询、弹窗、表格样式优先复用现有布局类和 SCSS 片段。
+- 缩进、引号、分号与仓库格式一致。
+
+## 推荐提问方式
+
+推荐把请求描述到下面这个粒度：
+
+- 目标模块和业务名
+- 后端接口前缀
+- 是新增页面还是修改页面
+- 是否需要导入、导出、树筛选、状态切换、字典、权限按钮
+- 希望参考哪个现有页面
+
+例如：
+
+- 使用 `$frontend-crud-coding` 为 `/system/client` 补一套标准 CRUD 页面，参考 `system/user` 和 generator 模板。
+- 使用 `$frontend-crud-coding` 修改 `workflow/category` 列表页，增加导出按钮和状态筛选，保持当前项目风格。
diff --git a/.codex/skills/frontend-crud-coding/agents/openai.yaml b/.codex/skills/frontend-crud-coding/agents/openai.yaml
new file mode 100644
index 0000000..ab42a6d
--- /dev/null
+++ b/.codex/skills/frontend-crud-coding/agents/openai.yaml
@@ -0,0 +1,7 @@
+interface:
+  display_name: "前端编码"
+  short_description: "按当前前端项目约定编写页面与 API"
+  default_prompt: "使用 $frontend-crud-coding 在当前前端项目里按现有约定实现页面和 API 修改。"
+
+policy:
+  allow_implicit_invocation: true
diff --git a/.codex/skills/frontend-crud-coding/references/examples.md b/.codex/skills/frontend-crud-coding/references/examples.md
new file mode 100644
index 0000000..257be87
--- /dev/null
+++ b/.codex/skills/frontend-crud-coding/references/examples.md
@@ -0,0 +1,112 @@
+# 使用案例
+
+## 案例 1：新增标准 CRUD 页面
+
+### 用户提问示例
+
+```text
+使用 $frontend-crud-coding 为 system/client 补一套前端 CRUD 页面。
+后端接口已经有 /system/client/list、/system/client/{id}、POST /system/client、PUT /system/client、DELETE /system/client/{ids}。
+请参考 generator 模板和现有的 system/user、system/config 页面风格实现。
+```
+
+### 期望执行方式
+
+- 先看 `src/api/system/client/*` 是否已存在。
+- 再看 `src/views/system/client/index.vue` 是否为空或缺失。
+- 参考同目录系统模块页面，确定是否需要搜索卡片、表格卡片、弹窗、导出按钮。
+- 再参考关联后端工程中的 generator 模板，补齐基础骨架。
+
+### 期望产物
+
+- `src/api/system/client/index.ts`
+- `src/api/system/client/types.ts`
+- `src/views/system/client/index.vue`
+
+## 案例 2：把 generator 模板落成当前项目风格
+
+### 用户提问示例
+
+```text
+使用 $frontend-crud-coding 按 generator 模板为 demo/order 生成一个标准页面，但不要直接复制模板，要改成当前前端项目现有样式壳和工具链写法。
+```
+
+### 期望执行方式
+
+- 先看 generator 的 `ts/types/index.vue` 模板。
+- 再看 `src/views/demo/demo/index.vue`、`src/views/system/user/index.vue` 的实际风格差异。
+- 生成的页面要使用当前项目里的 `right-toolbar`、`pagination`、`proxy?.$modal`、`proxy?.download` 等。
+
+## 案例 3：修改已有列表页
+
+### 用户提问示例
+
+```text
+使用 $frontend-crud-coding 修改 system/user 页面：
+1. 新增一个创建时间快捷筛选
+2. 导出按钮放到更多菜单中
+3. 保持现有样式和交互不变
+```
+
+### 期望执行方式
+
+- 优先阅读现有 `src/views/system/user/index.vue`。
+- 判断这是“已有页面增强”，不是“重新生成页面”。
+- 保留树筛选、导入导出、列显隐、角色分配等现有能力。
+- 增量修改，而不是重写整个页面。
+
+## 案例 4：补齐复杂业务页面
+
+### 用户提问示例
+
+```text
+使用 $frontend-crud-coding 为 workflow/category 增加导入、导出和状态切换功能，参考 system/user 的完整页面能力，但保持 workflow 模块自己的风格。
+```
+
+### 期望执行方式
+
+- 优先看 `src/views/workflow/category/index.vue`。
+- 再看 `src/views/system/user/index.vue` 里复杂列表页的做法。
+- 只迁移需要的能力，不把用户模块专属逻辑照搬到 workflow 页面。
+
+## 案例 5：只补 API 和 types
+
+### 用户提问示例
+
+```text
+使用 $frontend-crud-coding 为 monitor/cache 补全前端 API 和 types，页面先不改。
+```
+
+### 期望执行方式
+
+- 只维护 `src/api/monitor/cache/index.ts` 和 `src/api/monitor/cache/types.ts`。
+- 仍然要与后端路由、现有 API 风格、返回类型保持一致。
+
+## 案例 6：推荐的高质量任务描述
+
+下面这种描述最容易得到稳定结果：
+
+```text
+使用 $frontend-crud-coding 在当前前端项目中新增一个 `/system/notice` 列表页增强：
+1. 保留现有页面
+2. 新增状态筛选和导出
+3. API 路径沿用后端现有接口
+4. 参考 system/user 的工具栏与导出交互
+5. 参考 generator 模板补齐缺失的 types 定义
+```
+
+## 不推荐的任务描述
+
+下面这种描述太模糊，容易让产物偏离项目：
+
+```text
+帮我写个后台页面
+```
+
+更好的写法至少要补充：
+
+- 模块名
+- 业务名
+- 后端接口前缀
+- 是新增还是修改
+- 想参考哪个现有页面
diff --git a/.codex/skills/frontend-crud-coding/references/frontend.md b/.codex/skills/frontend-crud-coding/references/frontend.md
new file mode 100644
index 0000000..91847fe
--- /dev/null
+++ b/.codex/skills/frontend-crud-coding/references/frontend.md
@@ -0,0 +1,241 @@
+# 前端约定
+
+## 优先参考的代码来源
+
+- 关联后端工程中的生成器模板：
+  `ruoyi-modules/ruoyi-generator/src/main/resources/vm/ts/*.vm`
+  `ruoyi-modules/ruoyi-generator/src/main/resources/vm/vue/*.vm`
+- `src/api/system/user/index.ts`
+- `src/api/system/user/types.ts`
+- `src/views/system/user/index.vue`
+- `src/views/demo/demo/index.vue`
+- `src/views/system/*`
+- `src/views/workflow/*`
+- `src/components/*`
+- `src/assets/styles/components/*`
+
+## 基础栈与格式
+
+- 技术栈是 Vue 3 + TypeScript + Element Plus + Vite。
+- 请求统一通过 `@/utils/request`。
+- API 返回值类型常用 `AxiosPromise<T>`。
+- 项目默认 2 空格缩进。
+- 使用单引号和分号。
+- 不要在一个页面里混入与仓库不一致的格式和写法。
+
+## 决策顺序
+
+写代码时按下面顺序取样：
+
+1. 当前业务目录下最近似页面。
+2. 当前模块下最近似 API/types 文件。
+3. 当前项目的公共组件、公共工具、公共样式。
+4. 关联后端工程的 generator 模板。
+5. 通用 Vue 3 / Element Plus 默认写法。
+
+如果上述规则冲突，优先相信当前项目真实代码。
+
+## API 文件规则
+
+- 标准 CRUD 的 API、types、列表页骨架可以先参考后端生成器模板，再根据当前前端项目风格落地。
+- API 文件通常放在 `src/api/<module>/<business>/index.ts`。
+- 同目录维护 `types.ts`。
+- 常见 import 形式：
+  `import request from '@/utils/request';`
+  `import { AxiosPromise } from 'axios';`
+  `import { XxxForm, XxxQuery, XxxVO } from './types';`
+  `import { PageResult } from '@/api/types';`
+- 列表接口通常返回 `AxiosPromise<PageResult<XxxVO>>`。
+- 详情接口返回 `AxiosPromise<XxxVO>` 或更复杂的 `InfoVO`。
+- 特殊请求参数沿用现有实现，例如：
+  `parseStrEmpty(userId)`
+  `headers: { isEncrypt: true, repeatSubmit: false }`
+  `params` 用于 query string，`data` 用于 body。
+- 当前仓库部分模块会在文件底部 `export default { ... }`，已有模块使用这种形式时继续保持一致。
+
+### API 文件建议结构
+
+标准 CRUD 一般按这个顺序组织：
+
+1. import 区
+2. 列表接口
+3. 详情接口
+4. 新增接口
+5. 修改接口
+6. 删除接口
+7. 特殊接口
+8. 可选的 `export default`
+
+### API 常见判断
+
+- 如果后端是列表分页接口，前端通常返回 `AxiosPromise<PageResult<XxxVO>>`。
+- 如果后端返回复合结构，例如 `user + roles + posts`，单独定义 `InfoVO`。
+- 如果接口需要加密或关闭重复提交，直接在 `headers` 里表达，不要另起封装。
+
+## 类型文件规则
+
+- 类型文件通常定义 `Query`、`VO`、`Form`，必要时补 `InfoVO`、`ResetPwdForm` 等扩展类型。
+- `Query` 一般继承 `PageQuery`。
+- `VO` 常继承 `BaseEntity`。
+- ID 字段通常使用 `string | number`。
+- 列表页多选 ID 常用 `Array<string | number>`。
+- 数组字段在表单里常直接用 `string[]`、`number[]` 或宽松类型，优先跟随现有模块。
+
+### 类型拆分建议
+
+- `VO` 面向列表和详情展示。
+- `Form` 面向新增和编辑。
+- `Query` 面向列表筛选。
+- `InfoVO` 面向详情页、编辑页、弹窗预加载等复合返回结构。
+
+### 类型字段策略
+
+- 能明确写出类型时，不要偷懒用 `any`。
+- 只有在当前模块已有宽松写法或后端返回非常不稳定时，才保留 `any`。
+- 如果列表和表单字段明显不同，不要强行复用一个接口类型。
+
+## Vue 页面结构规则
+
+- 标准 CRUD 页可先参考生成器的 `index.vue.vm` 骨架，再按本仓库现有页面补强。
+- 页面优先使用 `<script setup name="Xxx" lang="ts">`。
+- 常见列表页结构：
+  搜索区卡片、表格区卡片、工具栏、分页、编辑弹窗。
+- 常见页面状态包括：
+  `loading`、`showSearch`、`ids`、`single`、`multiple`、`total`。
+- 表单和查询对象通常通过 `reactive<PageData<Form, Query>>({...})` 管理。
+- 弹窗状态通常使用：
+  `const dialog = reactive<DialogOption>({ visible: false, title: '' });`
+- 表单 ref 通常命名为 `queryFormRef`、`xxxFormRef`。
+- 复杂页面可补充树面板、导入弹窗、子弹窗、路由跳转逻辑。
+
+### 标准页面骨架
+
+标准页面通常包含这些区域：
+
+1. 搜索区
+2. 表格区
+3. 工具栏
+4. 分页
+5. 编辑弹窗
+
+复杂页面可以额外增加：
+
+- 左侧树筛选
+- 导入弹窗
+- 二级对话框
+- 独立详情页
+- 路由跳转按钮
+- 列显隐控制
+
+### 页面命名建议
+
+- 页面组件名通常为业务名，例如 `name="User"`、`name="Demo"`。
+- 页面根类名尽量带模块语义，例如：
+  `system-user-page`
+  `demo-demo-page`
+  `workflow-category-page`
+
+## 页面行为规则
+
+- `getList` 负责发起列表请求、处理 loading、回填 `rows` 和 `total`。
+- `handleQuery` 先把 `pageNum` 置为 `1`，再重新查询。
+- `resetQuery` 负责清空查询表单、日期范围、树节点选择，然后重新加载。
+- `handleSelectionChange` 更新 `ids`、`single`、`multiple`。
+- `handleAdd` 重置表单并打开新增弹窗。
+- `handleUpdate` 查详情后回填表单并打开编辑弹窗。
+- `submitForm` 使用表单校验，通过后调用新增或修改接口，再提示成功并刷新列表。
+- `handleDelete` 通常使用 `proxy?.$modal.confirm(...)` 二次确认。
+- `handleExport` 使用 `proxy?.download(...)`。
+- 日期范围查询沿用 `proxy?.addDateRange(queryParams.value, dateRange.value)`。
+- 需要更稳妥地处理确认框或异步异常时，可沿用 `await-to-js` 的 `to(...)` 风格。
+
+### 页面逻辑建议
+
+- 新增和编辑优先共用一套弹窗和表单。
+- `reset()` 与 `cancel()` 分开写，避免关闭弹窗时状态残留。
+- `handleUpdate()` 先查详情再 `Object.assign(form.value, res.data)`。
+- 删除、状态切换、解锁、重置密码这类危险操作优先保留确认提示。
+- 列表页只做列表页职责，复杂复合逻辑优先拆到子组件或独立页面。
+
+## 字典、权限与公共工具
+
+- 字典通常通过：
+  `const { xxx_dict } = toRefs<any>(proxy?.useDict('xxx_dict'));`
+- 权限指令以仓库现状为准，存在 `v-hasPermi` 和 `v-has-permi` 两种写法；新增代码优先跟随所在目录附近文件，不要在同一文件里混用新的变体。
+- 常用公共能力：
+  `proxy?.$modal`
+  `proxy?.download`
+  `proxy?.useDict`
+  `proxy?.getConfigKey`
+  `checkPermi`
+  `useUserStore`
+
+### 权限规则
+
+- 所有增删改导入导出按钮都先看附近页面是否有权限控制。
+- 新按钮默认补权限指令，除非它是纯展示行为。
+- 如果同目录页面使用 `v-hasPermi`，新代码优先继续用 `v-hasPermi`。
+- 如果同目录页面使用 `v-has-permi`，新代码优先继续用 `v-has-permi`。
+
+## 组件与样式规则
+
+- 优先复用公共组件：
+  `right-toolbar`
+  `pagination`
+  `ImageUpload`
+  `ImagePreview`
+  `FileUpload`
+  `Editor`
+  `DictTag`
+- 页面样式不要堆大量内联样式，优先沿用仓库里的布局类和组件样式。
+- 已有页面使用 SCSS 模块片段时，继续沿用：
+  `@use '@/assets/styles/components/page-shell' as pageShell;`
+  `@include pageShell.xxx;`
+- 类名命名保持模块化，例如：
+  `system-user-page`
+  `demo-demo-page`
+  `table-panel`
+  `search-panel`
+  `toolbar-shell`
+
+### 样式落点建议
+
+- 页面只需要轻量调整时，优先复用已有通用类。
+- 页面结构明显复杂时，优先在 `<style lang="scss" scoped>` 中通过 `@use` 复用组件样式片段。
+- 不要为了单页需求破坏全局组件样式。
+
+## 与生成器模板的关系
+
+- 关联后端工程生成器给出的前端结构可以作为起点，但真实页面通常更完整，包含：
+  树筛选、列显隐、导入导出、更多操作、SCSS 页面壳、复杂表单校验、独立子页面。
+- 因此新增页面时，不要只满足“能跑”，要先看所在模块已有页面的复杂度和 UI 组织方式。
+
+### 什么时候优先看 generator
+
+- 新增一个标准单表 CRUD 页面时。
+- 当前项目里还没有这个业务对应页面时。
+- 你只拿到了后端路由和字段信息时。
+
+### 什么时候优先看现有页面
+
+- 当前模块已经有同类页面时。
+- 页面包含树筛选、导入导出、联动弹窗、路由跳转时。
+- 任务是“修改已有页面”而不是“新建页面”时。
+
+## 避免事项
+
+- 不要直接把后端仓库里的前端模板原样复制进来。
+- 不要跳过 `types.ts`，把类型全堆在页面里。
+- 不要绕开 `request` 自己再包一层请求工具。
+- 不要引入与仓库现状不一致的 CSS 组织方式。
+- 不要为了省事删掉权限控制、导出、导入、树筛选、日期范围等现有交互能力。
+
+## 交付前自检
+
+交付前至少检查这些点：
+
+- 页面能否完整走通查询、新增、编辑、删除、导出流程。
+- 类型是否与接口返回结构一致。
+- 是否保留了原页面已有的权限和交互能力。
+- 是否沿用了当前模块已有的组件和样式壳。
+- 是否只是“生成器裸页”，如果是，需要继续补齐到当前项目风格。