@agile-team/wl-skills-kit 2.3.0 → 2.3.1

package/files/.github/skills/core/api-contract/USAGE.md

@@ -1,110 +1,110 @@
-# 使用指南：api-contract（接口约定）
-
-> **谁读这个文档**：团队成员（前端/后端/产品）
-> **AI 触发文件**：同目录 `SKILL.md`
-
----
-
-## 这个 Skill 解决什么问题
-
-为每个页面生成一份 `api.md`，**作为前后端联调的契约**：
-
-- 前端：`data.ts` 里的 `API_CONFIG` URL、查询字段直接来源于此
-- 后端：拿 api.md 即可写 Controller + Service + Entity，字段名一致零联调成本
-
----
-
-## 何时使用
-
-- 拿到《页面清单》（来自 `prototype-scan`），准备让后端开发接口
-- 已有页面但接口未定义，需要补齐契约
-- 接口字段需要变更，更新 api.md 让前后端同步
-
----
-
-## 触发关键词
-
-`接口约定` / `api.md` / `字段定义` / `前后端对齐` / `接口设计`
-
----
-
-## 真实响应契约（务必背下来）
-
-```json
-// 分页
-{ "code": 2000, "message": "操作成功", "data": { "records": [...], "total": 100, "current": 1, "size": 20, "pages": 5, "countId": null, "maxLimit": null, "orders": [], "searchCount": true } }
-
-// 单条 / 数组
-{ "code": 2000, "message": "...", "data": { /* 或 [] */ } }
-
-// 失败
-{ "code": 4001, "message": "...", "data": null }
-```
-
-- **code 成功值是 `2000`**（不是 200！）
-- **包裹字段是 `data`**（不是 `result`！）
-- 业务代码 `.then(res => res)` 拿到的已是 `data` 内容（拦截器剥壳）
-
----
-
-## 标准对话示例
-
-```
-你：基于 reports/PROTOTYPE_SCAN_客户管理_20260426.md 生成各页面的 api.md
-AI：[Pre-flight]
-    将生成 7 个 api.md 文件，输出位置：
-    src/views/produce/aiflow/mmwr-customer-archive/api.md
-    src/views/produce/aiflow/mmwr-customer-detail/api.md
-    ...
-    服务缩写：mmwr，资源名：mmwrCustomer*
-    需向你确认 3 项：
-    1. 主键字段是 customerCode 还是 customerNo？
-    2. 状态字典 logicValue 是 customer_state 还是 mmwr_customer_state？
-    3. 临时客户转正式客户是 /convert 还是单独接口？
-```
-
----
-
-## 输出物
-
-每个页面目录下生成 `api.md`，结构：
-
-1. **API_CONFIG**（粘贴到 data.ts 用）
-2. **实体定义**（字段名、类型、字典、必填）
-3. **接口清单**（list/getById/save/update/remove/export + 业务操作如 release/approve）
-4. **数据字典**（dictCode 列表）
-5. **联调注意**
-
----
-
-## 团队协作流程
-
-1. 前端基于 prototype-scan 输出生成 api.md（标 🟡 待确认）
-2. **发后端 review**（钉钉/IM 直接发文件路径）
-3. 后端确认字段，标 🟢 已确认
-4. 后端按 api.md 出接口，前端按 api.md 写 data.ts
-5. 联调时若有变更，更新 api.md 并标 🔴 有变更，双方同步修改
-
----
-
-## 常见踩坑
-
-| 现象                                              | 原因                           | 解法                                          |
-| ------------------------------------------------- | ------------------------------ | --------------------------------------------- |
-| 字段名不一致（前端 customerNo 后端 customerCode） | 没走 api.md 直接编码           | 强制约定：**先 api.md 再 data.ts**            |
-| 拦截器报"code 不是 2000"                          | mock 数据用了 200              | 改 mock 为 2000                               |
-| 业务代码报 `data.records is undefined`            | 后端忘记包装外壳，返回了纯数组 | 后端按契约包 `{ code, message, data: {...} }` |
-| 雪花 ID 精度丢失                                  | 后端返回 number                | 后端 ID 字段统一 String 序列化                |
-
----
-
-## FAQ
-
-**Q：api.md 一定要放在页面目录下吗？**
-A：是。便于 PR review 时一眼看到改了哪个页面的契约。
-
-**Q：可以跳过 api.md 直接 codegen 吗？**
-A：技术上可以，AI 会用通用模板字段，但**联调时必踩坑**。建议至少写到"实体定义"段落。
-
-**Q：业务操作（如 release / approve）需要写吗？**
-A：写。`page-codegen` 会读取 api.md 中的业务操作列表，自动在 toolbar 里加按钮。
+# 使用指南：api-contract（接口约定）
+
+> **谁读这个文档**：团队成员（前端/后端/产品）
+> **AI 触发文件**：同目录 `SKILL.md`
+
+---
+
+## 这个 Skill 解决什么问题
+
+为每个页面生成一份 `api.md`，**作为前后端联调的契约**：
+
+- 前端：`data.ts` 里的 `API_CONFIG` URL、查询字段直接来源于此
+- 后端：拿 api.md 即可写 Controller + Service + Entity，字段名一致零联调成本
+
+---
+
+## 何时使用
+
+- 拿到《页面清单》（来自 `prototype-scan`），准备让后端开发接口
+- 已有页面但接口未定义，需要补齐契约
+- 接口字段需要变更，更新 api.md 让前后端同步
+
+---
+
+## 触发关键词
+
+`接口约定` / `api.md` / `字段定义` / `前后端对齐` / `接口设计`
+
+---
+
+## 真实响应契约（务必背下来）
+
+```json
+// 分页
+{ "code": 2000, "message": "操作成功", "data": { "records": [...], "total": 100, "current": 1, "size": 20, "pages": 5, "countId": null, "maxLimit": null, "orders": [], "searchCount": true } }
+
+// 单条 / 数组
+{ "code": 2000, "message": "...", "data": { /* 或 [] */ } }
+
+// 失败
+{ "code": 4001, "message": "...", "data": null }
+```
+
+- **code 成功值是 `2000`**（不是 200！）
+- **包裹字段是 `data`**（不是 `result`！）
+- 业务代码 `.then(res => res)` 拿到的已是 `data` 内容（拦截器剥壳）
+
+---
+
+## 标准对话示例
+
+```
+你：基于 reports/PROTOTYPE_SCAN_客户管理_20260426.md 生成各页面的 api.md
+AI：[Pre-flight]
+    将生成 7 个 api.md 文件，输出位置：
+    src/views/produce/aiflow/mmwr-customer-archive/api.md
+    src/views/produce/aiflow/mmwr-customer-detail/api.md
+    ...
+    服务缩写：mmwr，资源名：mmwrCustomer*
+    需向你确认 3 项：
+    1. 主键字段是 customerCode 还是 customerNo？
+    2. 状态字典 logicValue 是 customer_state 还是 mmwr_customer_state？
+    3. 临时客户转正式客户是 /convert 还是单独接口？
+```
+
+---
+
+## 输出物
+
+每个页面目录下生成 `api.md`，结构：
+
+1. **API_CONFIG**（粘贴到 data.ts 用）
+2. **实体定义**（字段名、类型、字典、必填）
+3. **接口清单**（list/getById/save/update/remove/export + 业务操作如 release/approve）
+4. **数据字典**（dictCode 列表）
+5. **联调注意**
+
+---
+
+## 团队协作流程
+
+1. 前端基于 prototype-scan 输出生成 api.md（标 🟡 待确认）
+2. **发后端 review**（钉钉/IM 直接发文件路径）
+3. 后端确认字段，标 🟢 已确认
+4. 后端按 api.md 出接口，前端按 api.md 写 data.ts
+5. 联调时若有变更，更新 api.md 并标 🔴 有变更，双方同步修改
+
+---
+
+## 常见踩坑
+
+| 现象                                              | 原因                           | 解法                                          |
+| ------------------------------------------------- | ------------------------------ | --------------------------------------------- |
+| 字段名不一致（前端 customerNo 后端 customerCode） | 没走 api.md 直接编码           | 强制约定：**先 api.md 再 data.ts**            |
+| 拦截器报"code 不是 2000"                          | mock 数据用了 200              | 改 mock 为 2000                               |
+| 业务代码报 `data.records is undefined`            | 后端忘记包装外壳，返回了纯数组 | 后端按契约包 `{ code, message, data: {...} }` |
+| 雪花 ID 精度丢失                                  | 后端返回 number                | 后端 ID 字段统一 String 序列化                |
+
+---
+
+## FAQ
+
+**Q：api.md 一定要放在页面目录下吗？**
+A：是。便于 PR review 时一眼看到改了哪个页面的契约。
+
+**Q：可以跳过 api.md 直接 codegen 吗？**
+A：技术上可以，AI 会用通用模板字段，但**联调时必踩坑**。建议至少写到"实体定义"段落。
+
+**Q：业务操作（如 release / approve）需要写吗？**
+A：写。`page-codegen` 会读取 api.md 中的业务操作列表，自动在 toolbar 里加按钮。

package/files/.github/skills/core/convention-audit/SKILL.md

@@ -1,189 +1,189 @@
----
-name: convention-audit
-description: "Use when: auditing project source code against the 13 modular standards in .github/standards/. Outputs deviation report and component-extraction suggestions to reports/. Triggers on: 规范审计, 规范检查, 代码审计, 对齐规范, 规范偏差, 接手新项目, 存量代码分析, 项目体检, audit code, check conventions, onboard project."
----
-
-# Skill: 规范审计（convention-audit）
-
-以 `.github/standards/` 13 条规范为唯一基线，扫描项目源码，输出**偏差报告**和**组件提取建议**到 `reports/` 目录。
-
-> **核心理念**：规范是"标准"，代码必须对齐标准。本 Skill 只负责发现偏差并给出整改建议，**不自动修复**（修复由 [PLANNED] code-fix Skill 完成）。
-
----
-
-## 触发词
-
-`规范审计` / `规范检查` / `代码审计` / `对齐规范` / `规范偏差` / `audit code`
-
----
-
-## Pre-flight 声明（执行前必须输出）
-
-```
-🚀 已触发技能 convention-audit/SKILL.md → 规范审计：扫描源码 + 偏差报告 + 提取建议
-✅ 已读取 standards/index.md          → 规范门控
-✅ 已读取 standards/01 ~ 13           → 完整 13 条规范基线（审计场景需全量加载）
-✅ 已读取 reports/规范审查报告.md      → 现有报告（用于追加，不覆盖）
-✅ 审计范围：{用户指定的目录或单文件}
-```
-
----
-
-## 适用场景
-
-| 场景                        | 说明                                     |
-| --------------------------- | ---------------------------------------- |
-| 新项目导入 wl-skills-kit 后 | 扫描旧代码，输出整改清单，逐步迁移       |
-| 日常 Code Review 辅助       | 比对单文件或目录，快速发现偏差           |
-| 项目迁移/升级               | 老项目引入新架构，批量评估改造量         |
-| 团队培训                    | 新成员提交代码前，用审计验证是否符合规范 |
-| page-codegen 后置自检       | 页面生成完成后自动跑一次审计，确认合规   |
-| CI/CD（PLANNED）            | PR 上自动跑审计，不合规 PR 阻断合并      |
-
----
-
-## 审计范围（13 条规范全覆盖）
-
-| 编号 | 审计维度                     | 严重度判定                                                           |
-| ---- | ---------------------------- | -------------------------------------------------------------------- |
-| 01   | 工具链就绪                   | 缺少 `.prettierrc.js` / `eslint.config.ts` / `.husky/` → 🔴 严重     |
-| 02   | 4 文件原则、三段式、9 段顺序 | 缺 data.ts / index.vue 含业务逻辑 → 🔴；段落顺序乱 → 🟡              |
-| 03   | 注释规范                     | 文件头缺失 → 🟡；显而易见的注释 → 🟢 提示                            |
-| 04   | 基础编码（13 条）            | 用 var / for...in / 字符串拼接 → 🟡                                  |
-| 05   | console 残留                 | src/ 下任何 console.log / warn / error → 🟡                          |
-| 06   | 安全规范                     | v-html 无注释 / import axios / eval → 🔴                             |
-| 07   | 配置管理                     | 硬编码 `http://` / `https://` IP → 🔴；非 VITE\_ 环境变量 → 🟡       |
-| 08   | Git 规范                     | （审计时不检测，由 husky 自动拦截）                                  |
-| 09   | TypeScript                   | 滥用 any（>3 处/页） → 🟡                                            |
-| 10   | Pinia                        | data.ts 内 import Store → 🔴                                         |
-| 11   | 表单校验                     | FORM_ROUTE 缺 validate / resetFields → 🔴                            |
-| 12   | BaseTable + cid              | 用 el-table / 缺 render-type / cid 缺失或重复 → 🔴；cid 后缀使用旧格式（十进制截断后6位）→ 🟡；列级 cid 只用缩写作前缀（同页面两张表同名列碰撞）→ 🔴；**存量代码迁移期**：已存在旧格式 cid（缩写作前缀的列级 cid）→ 降级为 🟡，由 code-fix 逐步整改，不必一刀切全报红 |
-| 13   | 平台组件合规                 | 用 el-form/el-table/el-date-picker 替代封装 → 🔴；3+ 复用 → 提取建议 |
-
----
-
-## 执行流程
-
-### 步骤 1：确定审计范围
-
-| 用户输入                          | 范围          |
-| --------------------------------- | ------------- |
-| "审计整个项目"                    | `src/views/`  |
-| "审计 produce/mmwr"               | 该子目录      |
-| "审计 mmwr-customer-archive 页面" | 单页面 4 文件 |
-
-### 步骤 2：加载规范基线
-
-读取 `standards/01 ~ 13` 全部规范文件（审计场景必须全量加载）。
-
-### 步骤 3：扫描源码
-
-逐个文件检查 13 个维度。同时记录：
-
-- **跨页面相同 el-\* 模式**（统计出现次数和位置）
-- **每个偏差所在文件的菜单位置**（从 koroFileHeader 文件头注释解析）
-
-### 步骤 4：追加写入两份报告
-
-#### 报告 A：`reports/规范审查报告.md`（追加，最新章节在顶）
-
-```markdown
-## 🕐 {YYYY-MM-DD HH:mm} | 范围：{范围} | 触发：{user / page-codegen / CI}
-
-### 概要
-
-| 指标     | 值  |
-| -------- | --- |
-| 扫描页面 | 12  |
-| 合规页面 | 8   |
-| 偏差页面 | 4   |
-| 🔴 严重  | 5   |
-| 🟡 轻微  | 7   |
-
-### 🔴 严重偏差（必须整改）
-
-#### {页面路径} — 违反规范 13（平台组件合规）
-
-- **菜单位置**（来自文件头）：销售管理 > 国内贸易订单
-- **现状**：使用 `<el-table>` 渲染数据
-- **应为**：使用 `<BaseTable render-type="agGrid" cid="...">`
-- **整改建议**：参考 templates/universal/TPL-LIST.md
-- **修复标记**：🔧 待修复
-
-（按规范条目分组列出全部偏差）
-
-### 🟡 轻微偏差（建议整改）
-
-（同格式）
-
-### ✅ 合规页面
-
-- src/views/produce/.../mmwr-customer-archive/
-- ...
-
----
-
-（历史章节自然下沉）
-```
-
-#### 报告 B：`reports/组件提取建议.md`（追加）
-
-```markdown
-## 🕐 {YYYY-MM-DD HH:mm} | 范围：{范围}
-
-### 📦 组件提取建议（共 N 处）
-
-| 建议组件名    | 出现次数 | 页面路径                                 | 菜单位置              | 模式描述         |
-| ------------- | -------- | ---------------------------------------- | --------------------- | ---------------- |
-| c_statusBadge | 5 处     | src/views/sale/.../{a,b,c,d,e}/index.vue | 销售管理 > 多个子菜单 | 状态枚举彩色标签 |
-| c_priceFormat | 4 处     | src/views/.../...                        | ...                   | 千分位金额显示   |
-
-> ⚠️ 以上为建议，不自动提取。
-> 人工确认后，触发 `template-extract` Skill（页面级模板）或手动封装为 `c_*` 组件。
-```
-
-### 步骤 5：输出摘要
-
-```
-📦 审计完成
-─────────────────────────────────────────────────────
-✅ reports/规范审查报告.md   → 已追加章节（{N} 个偏差）
-✅ reports/组件提取建议.md  → 已追加 {M} 条提取建议
-─────────────────────────────────────────────────────
-📌 后续步骤：
-   1. 人工 review 报告，标记需要修复的条目
-   2. 严重偏差优先修复（用 page-codegen 重新生成）
-   3. 触发 code-fix 自动整改 🟢/🟡 等级偏差
-   4. 提取建议人工评审 → template-extract 或手动封装
-─────────────────────────────────────────────────────
-```
-
----
-
-## 偏差严重度定义
-
-| 级别 | 标记 | 定义                                       | 示例                                                  |
-| ---- | ---- | ------------------------------------------ | ----------------------------------------------------- |
-| 🔴   | 严重 | 架构性违反，影响可维护性 / 安全 / 团队协作 | 不用 AbstractPageQueryHook、用 el-table、import axios |
-| 🟡   | 轻微 | 风格 / 命名不统一，不影响功能              | for...in、目录名 camelCase、缺 api.md                 |
-| 🟢   | 提示 | 优化建议，可逐步改进                       | 重复表达式可抽 computed、超长函数可拆分               |
-
----
-
-## 与其他 Skill 的关系
-
-| Skill                  | 关系                                                    |
-| ---------------------- | ------------------------------------------------------- |
-| **page-codegen**       | 审计发现偏差后，可调用 page-codegen 重新生成合规代码    |
-| **template-extract**   | 审计输出的"组件提取建议"，确认后可触发 template-extract |
-| **code-fix**           | 审计报告作为修复输入，自动整改 🟢🟡 等级偏差            |
-| **CI/CD**              | 审计可作为 PR 检查项，不合规 PR 阻断合并                |
-
----
-
-## 注意事项
-
-1. **规范基线唯一**：以 `standards/index.md` 加载的 13 条文件为准，**不接受**"旧代码一直这么写"的辩解
-2. **追加不覆盖**：每次审计追加新章节到报告，**不删除历史**，便于追溯整改进度
-3. **菜单位置解析**：依赖 koroFileHeader 文件头注释，缺失文件头时标记 `菜单位置：未知`
-4. **AI 自我审计**：page-codegen 生成代码后，建议立即跑一次单页审计验证合规
+---
+name: convention-audit
+description: "Use when: auditing project source code against the 13 modular standards in .github/standards/. Outputs deviation report and component-extraction suggestions to reports/. Triggers on: 规范审计, 规范检查, 代码审计, 对齐规范, 规范偏差, 接手新项目, 存量代码分析, 项目体检, audit code, check conventions, onboard project."
+---
+
+# Skill: 规范审计（convention-audit）
+
+以 `.github/standards/` 13 条规范为唯一基线，扫描项目源码，输出**偏差报告**和**组件提取建议**到 `reports/` 目录。
+
+> **核心理念**：规范是"标准"，代码必须对齐标准。本 Skill 只负责发现偏差并给出整改建议，**不自动修复**（修复由 [PLANNED] code-fix Skill 完成）。
+
+---
+
+## 触发词
+
+`规范审计` / `规范检查` / `代码审计` / `对齐规范` / `规范偏差` / `audit code`
+
+---
+
+## Pre-flight 声明（执行前必须输出）
+
+```
+🚀 已触发技能 convention-audit/SKILL.md → 规范审计：扫描源码 + 偏差报告 + 提取建议
+✅ 已读取 standards/index.md          → 规范门控
+✅ 已读取 standards/01 ~ 13           → 完整 13 条规范基线（审计场景需全量加载）
+✅ 已读取 reports/规范审查报告.md      → 现有报告（用于追加，不覆盖）
+✅ 审计范围：{用户指定的目录或单文件}
+```
+
+---
+
+## 适用场景
+
+| 场景                        | 说明                                     |
+| --------------------------- | ---------------------------------------- |
+| 新项目导入 wl-skills-kit 后 | 扫描旧代码，输出整改清单，逐步迁移       |
+| 日常 Code Review 辅助       | 比对单文件或目录，快速发现偏差           |
+| 项目迁移/升级               | 老项目引入新架构，批量评估改造量         |
+| 团队培训                    | 新成员提交代码前，用审计验证是否符合规范 |
+| page-codegen 后置自检       | 页面生成完成后自动跑一次审计，确认合规   |
+| CI/CD（PLANNED）            | PR 上自动跑审计，不合规 PR 阻断合并      |
+
+---
+
+## 审计范围（13 条规范全覆盖）
+
+| 编号 | 审计维度                     | 严重度判定                                                           |
+| ---- | ---------------------------- | -------------------------------------------------------------------- |
+| 01   | 工具链就绪                   | 缺少 `.prettierrc.js` / `eslint.config.ts` / `.husky/` → 🔴 严重     |
+| 02   | 4 文件原则、三段式、9 段顺序 | 缺 data.ts / index.vue 含业务逻辑 → 🔴；段落顺序乱 → 🟡              |
+| 03   | 注释规范                     | 文件头缺失 → 🟡；显而易见的注释 → 🟢 提示                            |
+| 04   | 基础编码（13 条）            | 用 var / for...in / 字符串拼接 → 🟡                                  |
+| 05   | console 残留                 | src/ 下任何 console.log / warn / error → 🟡                          |
+| 06   | 安全规范                     | v-html 无注释 / import axios / eval → 🔴                             |
+| 07   | 配置管理                     | 硬编码 `http://` / `https://` IP → 🔴；非 VITE\_ 环境变量 → 🟡       |
+| 08   | Git 规范                     | （审计时不检测，由 husky 自动拦截）                                  |
+| 09   | TypeScript                   | 滥用 any（>3 处/页） → 🟡                                            |
+| 10   | Pinia                        | data.ts 内 import Store → 🔴                                         |
+| 11   | 表单校验                     | FORM_ROUTE 缺 validate / resetFields → 🔴                            |
+| 12   | BaseTable + cid              | 用 el-table / 缺 render-type / cid 缺失或重复 → 🔴；cid 后缀使用旧格式（十进制截断后6位）→ 🟡；列级 cid 只用缩写作前缀（同页面两张表同名列碰撞）→ 🔴；**存量代码迁移期**：已存在旧格式 cid（缩写作前缀的列级 cid）→ 降级为 🟡，由 code-fix 逐步整改，不必一刀切全报红 |
+| 13   | 平台组件合规                 | 用 el-form/el-table/el-date-picker 替代封装 → 🔴；3+ 复用 → 提取建议 |
+
+---
+
+## 执行流程
+
+### 步骤 1：确定审计范围
+
+| 用户输入                          | 范围          |
+| --------------------------------- | ------------- |
+| "审计整个项目"                    | `src/views/`  |
+| "审计 produce/mmwr"               | 该子目录      |
+| "审计 mmwr-customer-archive 页面" | 单页面 4 文件 |
+
+### 步骤 2：加载规范基线
+
+读取 `standards/01 ~ 13` 全部规范文件（审计场景必须全量加载）。
+
+### 步骤 3：扫描源码
+
+逐个文件检查 13 个维度。同时记录：
+
+- **跨页面相同 el-\* 模式**（统计出现次数和位置）
+- **每个偏差所在文件的菜单位置**（从 koroFileHeader 文件头注释解析）
+
+### 步骤 4：追加写入两份报告
+
+#### 报告 A：`reports/规范审查报告.md`（追加，最新章节在顶）
+
+```markdown
+## 🕐 {YYYY-MM-DD HH:mm} | 范围：{范围} | 触发：{user / page-codegen / CI}
+
+### 概要
+
+| 指标     | 值  |
+| -------- | --- |
+| 扫描页面 | 12  |
+| 合规页面 | 8   |
+| 偏差页面 | 4   |
+| 🔴 严重  | 5   |
+| 🟡 轻微  | 7   |
+
+### 🔴 严重偏差（必须整改）
+
+#### {页面路径} — 违反规范 13（平台组件合规）
+
+- **菜单位置**（来自文件头）：销售管理 > 国内贸易订单
+- **现状**：使用 `<el-table>` 渲染数据
+- **应为**：使用 `<BaseTable render-type="agGrid" cid="...">`
+- **整改建议**：参考 templates/universal/TPL-LIST.md
+- **修复标记**：🔧 待修复
+
+（按规范条目分组列出全部偏差）
+
+### 🟡 轻微偏差（建议整改）
+
+（同格式）
+
+### ✅ 合规页面
+
+- src/views/produce/.../mmwr-customer-archive/
+- ...
+
+---
+
+（历史章节自然下沉）
+```
+
+#### 报告 B：`reports/组件提取建议.md`（追加）
+
+```markdown
+## 🕐 {YYYY-MM-DD HH:mm} | 范围：{范围}
+
+### 📦 组件提取建议（共 N 处）
+
+| 建议组件名    | 出现次数 | 页面路径                                 | 菜单位置              | 模式描述         |
+| ------------- | -------- | ---------------------------------------- | --------------------- | ---------------- |
+| c_statusBadge | 5 处     | src/views/sale/.../{a,b,c,d,e}/index.vue | 销售管理 > 多个子菜单 | 状态枚举彩色标签 |
+| c_priceFormat | 4 处     | src/views/.../...                        | ...                   | 千分位金额显示   |
+
+> ⚠️ 以上为建议，不自动提取。
+> 人工确认后，触发 `template-extract` Skill（页面级模板）或手动封装为 `c_*` 组件。
+```
+
+### 步骤 5：输出摘要
+
+```
+📦 审计完成
+─────────────────────────────────────────────────────
+✅ reports/规范审查报告.md   → 已追加章节（{N} 个偏差）
+✅ reports/组件提取建议.md  → 已追加 {M} 条提取建议
+─────────────────────────────────────────────────────
+📌 后续步骤：
+   1. 人工 review 报告，标记需要修复的条目
+   2. 严重偏差优先修复（用 page-codegen 重新生成）
+   3. 触发 code-fix 自动整改 🟢/🟡 等级偏差
+   4. 提取建议人工评审 → template-extract 或手动封装
+─────────────────────────────────────────────────────
+```
+
+---
+
+## 偏差严重度定义
+
+| 级别 | 标记 | 定义                                       | 示例                                                  |
+| ---- | ---- | ------------------------------------------ | ----------------------------------------------------- |
+| 🔴   | 严重 | 架构性违反，影响可维护性 / 安全 / 团队协作 | 不用 AbstractPageQueryHook、用 el-table、import axios |
+| 🟡   | 轻微 | 风格 / 命名不统一，不影响功能              | for...in、目录名 camelCase、缺 api.md                 |
+| 🟢   | 提示 | 优化建议，可逐步改进                       | 重复表达式可抽 computed、超长函数可拆分               |
+
+---
+
+## 与其他 Skill 的关系
+
+| Skill                  | 关系                                                    |
+| ---------------------- | ------------------------------------------------------- |
+| **page-codegen**       | 审计发现偏差后，可调用 page-codegen 重新生成合规代码    |
+| **template-extract**   | 审计输出的"组件提取建议"，确认后可触发 template-extract |
+| **code-fix**           | 审计报告作为修复输入，自动整改 🟢🟡 等级偏差            |
+| **CI/CD**              | 审计可作为 PR 检查项，不合规 PR 阻断合并                |
+
+---
+
+## 注意事项
+
+1. **规范基线唯一**：以 `standards/index.md` 加载的 13 条文件为准，**不接受**"旧代码一直这么写"的辩解
+2. **追加不覆盖**：每次审计追加新章节到报告，**不删除历史**，便于追溯整改进度
+3. **菜单位置解析**：依赖 koroFileHeader 文件头注释，缺失文件头时标记 `菜单位置：未知`
+4. **AI 自我审计**：page-codegen 生成代码后，建议立即跑一次单页审计验证合规