// Use when: auditing project source code against the 14 modular standards in .github/standards/. Outputs deviation report and component-extraction suggestions to reports/. Triggers on: 规范审计, 规范检查, 代码审计, 对齐规范, 规范偏差, 接手新项目, 存量代码分析, 项目体检, audit code, check conventions, onboard project.
Use when: analyzing Axure exported HTML prototype files to extract page inventory, classify interaction patterns, identify reusable components, and produce a structured page checklist for Vue development. Also supports NON-standard detailed design documents (free-form MD/Word) or natural language descriptions as input. DO NOT use for standard requirement-spec documents produced by wl-skills-design (path contains docs/spec/, has function codes like PMMB001, IPO tables, flow five-elements) — route those to spec-doc-parse instead. Triggers on: prototype analysis, axure scan, page inventory, 原型解析, 页面清单, axure转vue, 口述需求, 自然语言建页面, natural language page request, 建个页面, 写个页面, 口头描述页面.
Use when: parsing STANDARD requirement-design specification documents produced by wl-skills-design (path contains docs/spec/, files like ch1-3.md / 4.x-{module}.md / 4.N-data-report.md, with function codes like PMMB001, IPO tables containing 处理逻辑, and flow descriptions with five-elements) into the SAME page-spec JSON consumed by page-codegen. This is the 规范线 (spec line) counterpart to prototype-scan (原型线). Self-validating, self-correcting, report-producing. Triggers on: 解析说明书, 解析需求文档, 解析详设, 规范文档转页面, 根据说明书生成, spec doc parse, IPO 转页面, docs/spec, 功能编码, 需求设计说明书.
Use when: generating complete Vue 3 page code (index.vue + data.ts + modal components + api.md + pages.ts registration) from a prototype page inventory and API contract, strictly following the cx-ui-produce project conventions. Read SKILL.md first (rules+constraints), then read the matching TPL-*.md for the template code. Triggers on: generate page, create page, code generation, 生成页面, 页面代码, 代码生成, vue页面, 按原型生成, 口述需求, 建个页面, 写个页面, 帮我生成, natural language page generation.
Use when: fixing code convention issues found in convention-audit reports. Triggers on: 自动修复, 整改偏差, 修复报告, 规范整改, 修复偏差, code fix, 整改规范.
Use when: managing roles, authorizing menus to roles, attaching action buttons (type=A) to page menus, or wiring permission field in data.ts toolbar config. Triggers on: 创建角色, 角色管理, 角色授权, 给角色分配菜单, 挂动作, 添加动作按钮, 同步权限, 权限码注册, role assign, permission sync.
Use when: syncing data dictionary entries to the backend, pulling the current online dictionary baseline, or checking which dictionaries used in data.ts are missing from the system. Triggers on: 同步字典, 创建字典, 刷新字典基线, 字典对比, 字典审计, dict sync, create dict.
| name | convention-audit |
| description | Use when: auditing project source code against the 14 modular standards in .github/standards/. Outputs deviation report and component-extraction suggestions to reports/. Triggers on: 规范审计, 规范检查, 代码审计, 对齐规范, 规范偏差, 接手新项目, 存量代码分析, 项目体检, audit code, check conventions, onboard project. |
以 .github/standards/ 14 条规范为唯一基线，扫描项目源码，输出偏差报告和组件提取建议到 reports/ 目录。
核心理念：审查全覆盖、结果强量化、规则场景化、新增严格 + 存量渐进。 本 Skill 只负责发现偏差并给出整改建议，不自动修复（修复由 code-fix Skill 完成）。
规范审计 / 规范检查 / 代码审计 / 对齐规范 / 规范偏差 / audit code
🚀 已触发技能 convention-audit/SKILL.md → 规范审计：扫描源码 + 偏差报告 + 提取建议
✅ 已读取 standards/index.md → 规范门控
✅ 已读取 standards/01 ~ 14 → 完整 14 条规范基线（审计场景需全量加载）
✅ 已读取 reports/规范审查报告.md → 现有报告（用于追加，不覆盖）
✅ 审计范围：{用户指定的目录或单文件}
✅ 工具链检测：ESLint {状态} / tsc {状态} / Husky {状态}
| 场景 | 说明 |
|---|---|
| 新项目导入 wl-skills-kit 后 | 扫描旧代码，输出整改清单，逐步迁移 |
| 日常 Code Review 辅助 | 比对单文件或目录，快速发现偏差 |
| 项目迁移/升级 | 老项目引入新架构，批量评估改造量 |
| 团队培训 | 新成员提交代码前，用审计验证是否符合规范 |
| page-codegen 后置自检 | 页面生成完成后自动跑一次审计，确认合规 |
| 修复闭环复扫 | code-fix 修复后复扫，生成前后对比 |
| CI/CD（PLANNED） | PR 上自动跑审计，不合规 PR 阻断合并 |
| 方式 | 说明 |
|---|---|
| 静态扫描 | 文件存在性检测、正则匹配（高可信度） |
| 工具链委托 | ESLint / tsc --noEmit / Git 命令（高可信度，不浪费 AI 算力） |
| AI 场景判断 | 页面类型识别、豁免判定（中可信度，需人工确认） |
| 编号 | 审计维度 | 审计方式 | 严重度判定 |
|---|---|---|---|
| 01 | 工具链就绪 | 静态扫描 | 缺少 .prettierrc.js / eslint.config.ts / .husky/ → 🔴 |
| 02 | 三文件分离 + 接口契约 | 静态 + AI 场景判断 | 应拆未拆 data.ts → 🔴（新增）/🟡（存量）；api.md 缺失见场景规则；index.vue 含业务逻辑 → 🔴/🟡；段落顺序乱 → 🟡 |
| 03 | 注释规范 | 静态扫描 | 死代码注释 → 🟡；TODO 不规范 → 🟡；显而易见注释 → 🟢；文件头缺失 → 🟢 |
| 04 | 基础编码（13 条） | ESLint + 静态扫描 | var / for...in / 字符串拼接 / .then() / ::v-deep → 🟡 |
| 05 | console 残留 | 静态扫描 | src/ 下无守卫的 console → 🟡 |
| 06 | 安全规范 | 静态扫描 | v-html 无注释 / import axios / eval / new Function → 🔴 |
| 07 | 配置管理 | 静态扫描 | 硬编码 http:// IP → 🔴；API 路径散落 → 🟡 |
| 08 | Git 规范 | Git 命令 + 文件检测 | 工具链缺失 → 🔴；分支名不规范 → 🟡；近期提交不规范 → 🟡；历史 → 🟢 |
| 09 | TypeScript | tsc / ESLint 委托 | AI 不逐文件做类型推导，读取工具链输出归类；any 滥用 → 🟡 |
| 10 | Pinia | 静态扫描 | data.ts 内 import Store → 🔴 |
| 11 | 表单校验 | AI 场景判断 | FORM_ROUTE 缺 validate / resetFields → 🔴 |
| 12 | BaseTable + cid | 静态 + 场景判断 | 主列表用 el-table → 🔴；cid 缺失/重复 → 🔴；弹窗小表格见豁免规则 |
| 13 | 平台组件合规 | 静态扫描 | 业务页面用 el-form/el-table/el-date-picker 替代封装 → 🔴；封装组件内部 → ⚠️ 待确认；3+ 复用 → 提取建议 |
| 14 | 布局容器 | 静态扫描 | 业务代码用 C_Splitter → 🔴（必须替换为 jh-drag-row/jh-drag-col） |
不同目录类型适用不同规则强度，避免封装组件内部与业务页面混淆。
| 目录 | 规则强度 | 说明 |
|---|---|---|
src/views/** | 最严格 | 业务页面，全规范覆盖 |
src/components/local/** | 中等 | 业务封装组件，检查复用性和命名 |
src/components/**（基础/历史） | 宽松 | 不套页面三文件原则；内部使用 el-* 需单独评审 |
| 类型 | 处理策略 |
|---|---|
| 新增页面（AI 生成 / 手动新增） | 必须全规约，阻断项严格执行 |
| 本次修改页面 | 不新增违规，触碰范围内尽量修 |
| 存量未触碰页面 | 报告记录，后续治理，不阻断 |
| 用户输入 | 范围 |
|---|---|
| "审计整个项目" | src/views/ |
| "审计 produce/mmwr" | 该子目录 |
| "审计 mmwr-customer-archive 页面" | 单页面文件 |
standards/01 ~ 13 全部规范文件tsc --noEmit 是否可执行.husky/pre-commit、.husky/commit-msg 是否存在package.json 获取项目脚本名称逐个文件检查 13 个维度。同时记录：
data.ts、api.md，是否属于豁免场景reports/规范审查报告.md（追加，最新章节在顶）## 🕐 {YYYY-MM-DD HH:mm} | 范围：{范围} | 触发：{user / page-codegen / CI}
### 1. 扫描范围与数据量
| 指标 | 值 |
|---|---|
| 扫描根目录 | {路径} |
| 扫描目录数 | {N} |
| 扫描文件数 | {N} |
| Vue 文件数 | {N} |
| TS/JS 文件数 | {N} |
| SCSS/CSS 文件数 | {N} |
| 业务页面目录数 | {N} |
| 豁免/不适用页面数 | {N} |
### 2. 工具链与 Git 状态
| 项目 | 状态 |
|---|---|
| ESLint | {已配置 / 未配置 / 执行失败} |
| Prettier | {.prettierrc.js 存在 / 缺失} |
| TypeScript | {tsc 可用 / 不可用} |
| Husky | {pre-commit ✓ commit-msg ✓ / 缺失} |
| @robot-admin/git-standards | {已初始化 / 未安装} |
| 当前分支 | {分支名} — {符合规范 / 不符合规范} |
| 最近提交规范性 | {N}/{总数} 条符合 type(scope): 格式 |
### 3. 14 条规范覆盖矩阵
| 规范 | 审查方式 | 结果 | 🔴 | 🟡 | 🟢 |
|---|---|---|---:|---:|---:|
| 01 工具链 | 文件检测 | {结果} | {N} | {N} | {N} |
| 02 结构 | 静态+AI | {结果} | {N} | {N} | {N} |
| 03 注释 | 静态扫描 | {结果} | {N} | {N} | {N} |
| 04 基础编码 | ESLint/静态 | {结果} | {N} | {N} | {N} |
| 05 日志 | 静态扫描 | {结果} | {N} | {N} | {N} |
| 06 安全 | 静态扫描 | {结果} | {N} | {N} | {N} |
| 07 配置 | 静态扫描 | {结果} | {N} | {N} | {N} |
| 08 Git | Git+文件 | {结果} | {N} | {N} | {N} |
| 09 TS | tsc/ESLint | {结果} | {N} | {N} | {N} |
| 10 Pinia | 静态扫描 | {结果} | {N} | {N} | {N} |
| 11 表单校验 | 场景扫描 | {结果} | {N} | {N} | {N} |
| 12 BaseTable | 静态+场景 | {结果} | {N} | {N} | {N} |
| 13 平台组件 | 静态扫描 | {结果} | {N} | {N} | {N} |
| 14 布局容器 | 静态扫描 | {结果} | {N} | {N} | {N} |
### 4. 🔴 严重偏差（必须整改）
#### {编号}. 违反规范 {XX}（{规范名}）— {问题描述}
- **影响文件数**：{N}
- **出现次数**：{N}
- **菜单位置**（来自文件头）：{位置}
- **现状**：{描述}
- **应为**：{描述}
- **整改建议**：{建议}
- **自动修复**：{✅ 可自动修 / ⚠️ 需确认 / ❌ 人工处理}
- **涉及文件 Top N**：
1. `src/views/.../index.vue` — {N} 处
2. ...
（按规范条目分组列出全部偏差）
### 5. 🟡 警告偏差（建议整改）
（同格式，增加自动修复标记）
### 6. 🟢 提示与后续关注
（注释、TS 类型优化、存量历史问题等）
### 7. 豁免 / 不适用清单
| 文件/目录 | 规则 | 原因 | 结论 |
|---|---|---|---|
| {路径} | data.ts | 纯静态说明页 | 不适用 |
| {路径} | api.md | 无接口调用 | 豁免 |
| {路径} | AGGrid | 弹窗小型明细表 | 待人工确认 |
| {路径} | el-dialog | 封装组件内部实现 | 合理 |
### 8. 本次建议 code-fix 修复清单
| 问题 | 影响文件数 | 自动修复 | 建议 |
|---|---:|---|---|
| console 清理 | {N} | ✅ | 本轮修复 |
| var → const/let | {N} | ✅ | 本轮修复 |
| ::v-deep → :deep() | {N} | ✅ | 本轮修复 |
| BaseTable 缺 cid | {N} | ✅ | 本轮修复 |
| 简单 .then() → async/await | {N} | ⚠️ | 需确认 |
### 9. 本次不建议修复 / 后续治理清单
| 问题 | 原因 | 建议时间 |
|---|---|---|
| 存量页面迁移 data.ts | 大规模重构 | 按模块渐进 |
| el-table 全量迁移 | 需逐页面验证 | P1 分批 |
| 存量 api.md 补齐 | 非阻断项 | 后续补充 |
### 10. 目录/模块问题分布
| 模块目录 | 🔴 | 🟡 | 🟢 | 合计 | 建议 |
|---|---:|---:|---:|---:|---|
| {模块路径}/ | {N} | {N} | {N} | {N} | {建议} |
### 11. 推荐整改路线
| 优先级 | 整改项 | 建议方式 |
|---|---|---|
| P0 | {工具链缺失项} | 先备份配置，再初始化 |
| P1 | {严重偏差项} | code-fix / 立即修复 |
| P2 | {警告偏差项} | 分批修 |
| P3 | {存量治理项} | 渐进迁移 |
### 12. 修复闭环与复扫
| 指标 | 本次值 | 上次值 | 变化 |
|---|---:|---:|---|
| 🔴 严重 | {N} | {N/-} | {±N} |
| 🟡 警告 | {N} | {N/-} | {±N} |
| el-table 文件数 | {N} | {N/-} | {±N} |
| console 文件数 | {N} | {N/-} | {±N} |
> 📌 后续提交必须使用 `git cz`，不符合规范的提交视为闭环失败。
> 报告生成时间：{YYYY-MM-DD} | @agile-team/wl-skills-kit@{version} | {项目名}@{branch} branch
> 扫描工具：@agile-team/wl-skills-kit scanner + AI 代码全量扫描
> 执行人：{姓名} | {工号}
---
（历史章节自然下沉）
reports/组件提取建议.md（追加）## 🕐 {YYYY-MM-DD HH:mm} | 范围：{范围}
### 📦 组件提取建议（共 N 处）
| 建议组件名 | 出现次数 | 页面路径 | 菜单位置 | 模式描述 |
|---|---|---|---|---|
| c_statusBadge | 5 处 | src/views/sale/.../{a,b,c,d,e}/index.vue | 销售管理 > 多个子菜单 | 状态枚举彩色标签 |
> ⚠️ 以上为建议，不自动提取。
> 人工确认后，触发 `template-extract` Skill（页面级模板）或手动封装为 `c_*` 组件。
📦 审计完成
─────────────────────────────────────────────────────
📊 扫描：{N} 个目录 / {N} 个文件 / {N} 个业务页面
✅ reports/规范审查报告.md → 已追加（🔴{N} 🟡{N} 🟢{N}）
✅ reports/组件提取建议.md → 已追加 {M} 条
─────────────────────────────────────────────────────
📌 后续步骤：
1. 人工 review 报告，确认豁免清单和修复优先级
2. 触发 code-fix 修复"本次建议修复清单"中 ✅ 项
3. 需确认项（⚠️）人工评审后决定是否 code-fix
4. 提取建议人工评审 → template-extract 或手动封装
5. 修复后复扫，生成前后对比指标
6. 所有修复提交使用 git cz，确保 Git 规范合规
─────────────────────────────────────────────────────
| 级别 | 标记 | 定义 | 自动修复 |
|---|---|---|---|
| 🔴 | 严重 | 架构性违反，影响可维护性 / 安全 / 团队协作 | 部分可自动修，部分需人工 |
| 🟡 | 警告 | 风格不统一 / 最佳实践偏离，不影响功能 | 大部分可自动修 |
| 🟢 | 提示 | 优化建议，可逐步改进 | 按需 |
| 标记 | 含义 | 处理方式 |
|---|---|---|
| ✅ 可自动修复 | 模式明确、风险低 | 直接交给 code-fix |
| ⚠️ 需确认后修复 | 有业务风险 | 人工确认后 code-fix |
| ❌ 人工处理 | 需要理解业务 | 不自动修 |
| 👀 后续关注 | 本轮不修 | 持续观察 |
以下问题视为阻断项，修复闭环前必须解决：
api.mddata.tsel-tableeval、未声明的 v-html、硬编码 secret以下问题不阻断，作为后续治理：
api.mddata.tsany审计报告应在概要处标注各检查方式的可信度，便于人工评审。
| 检查类型 | 可信度 |
|---|---|
| 文件是否存在 | 高 |
| 正则匹配（el-table / console / var 等） | 高 |
| 工具链输出（ESLint / tsc） | 高 |
| Git 提交历史 | 高 |
| 页面是否需要 data.ts | 中（需人工确认） |
| AGGrid 是否适配弹窗表格 | 中（需人工确认） |
| 复杂业务逻辑是否应提取 | 中 |
| Skill | 关系 |
|---|---|
| page-codegen | 审计发现偏差后，可调用 page-codegen 重新生成合规代码 |
| template-extract | 审计输出的"组件提取建议"，确认后可触发 template-extract |
| code-fix | 审计报告中 ✅/⚠️ 标记项作为修复输入 |
| spec-doc-parse | 提供 spec 对齐模式的基准：用规范线解析出的 page-spec 与生成代码比对，输出 GAP 报告 |
| CI/CD | 审计可作为 PR 检查项，不合规 PR 阻断合并 |
standards/index.md 加载的 14 条文件为准，不接受"旧代码一直这么写"的辩解菜单位置：未知data.ts / api.md / AGGrid 均按场景规则判定，不机械检查文件数量闭环能力：与
core/spec-doc-parse联动。当页面代码来自「规范线」（wl-skills-design 说明书 → spec-doc-parse → page-codegen）时，本模式把 原始 spec 定义的字段 与 代码中实际存在的字段 逐项比对，生成 GAP 报告，验证「说明书 → 代码」是否零损耗。
审计 {页面目录} --mode spec-align --spec docs/spec/{项目代号}/4.x-{子模块}.md
或自然语言：「检查 {页面} 是否跟说明书对齐」。
| 维度 | 检查点 | 偏差判定 |
|---|---|---|
| 查询字段 | spec query[] vs 代码 queryDef() | spec 有代码缺 → 🔴 漏字段；代码多出 → 🟡 超出 spec |
| 表格列 | spec columns[] vs 代码 columnsDef() | 同上，且顺序不一致 → 🟡 |
| 工具栏 | spec toolbar[] vs 代码 toolbarDef() | 按钮缺失/多出 → 🔴/🟡 |
| 表单字段 | spec formSections[].fields[] vs 弹窗组件 | 必填字段缺失 → 🔴 |
| 接口 URL | spec 推算 URL vs 代码 API_CONFIG | 路径不一致 → 🟡 待确认 |
| 权限码 | spec notes 权限码候选 vs 代码 v-permission | 未挂载 → 🟡，建议 permission-sync |
# Spec 对齐 GAP 报告
- 生成时间：{YYYY-MM-DD HH:mm}
- spec 来源：docs/spec/{项目代号}/4.x-{子模块}.md
- 代码范围：src/views/.../{页面}/
## GAP 摘要
- spec 字段总数：N 代码实现：N 漏：N 多：N 顺序不一致：N
## 漏字段（spec 有、代码无 → 🔴）
| # | 类型 | spec 字段 | 所在功能 | 建议 |
|---|------|----------|---------|------|
| 1 | query | customerType | PMMB001 | 补入查询项 |
## 多余字段（代码有、spec 未定义 → 🟡）
| # | 类型 | 代码字段 | 建议 |
|---|------|----------|------|
| 1 | column | remark | 确认是否需要，否则反馈 design 补 spec |
## 下一步
→ 漏字段交 code-fix / page-codegen 补齐；多余字段反馈上游 design 补 spec。
spec 对齐模式只对规范线生成的页面生效；原型线（prototype-scan）生成的页面无 spec 基准，跳过本模式。