@agile-team/wl-skills-kit 2.10.0 → 2.11.0

package/files/{.github → .wl-skills}/skills/core/prototype-scan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: prototype-scan
-description: "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, 建个页面, 写个页面, 口头描述页面."
+description: "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 .wl-skills/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, 建个页面, 写个页面, 口头描述页面."
 ---
 
 # Skill: 原型解析（prototype-scan）
@@ -17,7 +17,7 @@ description: "Use when: analyzing Axure exported HTML prototype files to extract
 | **模式 A（Axure）** | Axure HTML 文件包目录 | 已有原型设计，AI 全量扫描 HTML |
 | **模式 B（非规范详设）** | MD/Word/表格格式的零散详细设计 | 已有非规范详设文档，AI 解析结构化字段 |
 
-> ⚠️ **双线隔离（必读）**：本 Skill 走「原型线」。若输入是 wl-skills-design 产出的**标准需求设计说明书**（路径含 `docs/spec/`、含功能编码 `/[A-Z]{2,6}[0-9]{3}/`、含 IPO 表「处理逻辑」、含流程五要素），属于「规范线」，**禁止本 Skill 接管**，必须路由到 `core/spec-doc-parse/SKILL.md`。两线各自解析，最终都汇聚到同一份 page-spec JSON，下游 `api-contract` / `page-codegen` 无感知来源。
+> ⚠️ **双线隔离（必读）**：本 Skill 走「原型线」。若输入是 wl-skills-design 产出的**标准需求设计说明书**（路径含 `.wl-skills/docs/spec/`、含功能编码 `/[A-Z]{2,6}[0-9]{3}/`、含 IPO 表「处理逻辑」、含流程五要素），属于「规范线」，**禁止本 Skill 接管**，必须路由到 `core/spec-doc-parse/SKILL.md`。两线各自解析，最终都汇聚到同一份 page-spec JSON，下游 `api-contract` / `page-codegen` 无感知来源。
 
 ---
 
@@ -188,7 +188,7 @@ AI 根据提取的信息，内部构建 page-spec JSON（**不输出给用户**
 
 ### 4. 组件匹配
 
-对照平台已有组件（详细 API 见 `docs/jh-*.md`）：
+对照平台已有组件（详细 API 见 `.wl-skills/docs/jh-*.md`）：
 
 | 功能区   | 组件                    | 说明                                 |
 | -------- | ----------------------- | ------------------------------------ |
@@ -200,15 +200,15 @@ AI 根据提取的信息，内部构建 page-spec JSON（**不输出给用户**
 | 左右分割 | jh-drag-col             | 树形+列表必备，设 `:leftWidth` + #left/#right slot |
 | 树形面板 | C_Tree                  | 含搜索+Tab 切换                      |
 | 下拉选择 | jh-select               | dict 属性自动加载字典数据            |
-| 日期选择 | jh-date / jh-date-range | 参见 `docs/jh-date.md`               |
-| 用户选择 | jh-user-picker          | 参见 `docs/jh-user-picker.md`        |
-| 部门选择 | jh-dept-picker          | 参见 `docs/jh-dept-picker.md`        |
-| 文件上传 | jh-file-upload          | 参见 `docs/jh-file-upload.md`        |
+| 日期选择 | jh-date / jh-date-range | 参见 `.wl-skills/docs/jh-date.md`               |
+| 用户选择 | jh-user-picker          | 参见 `.wl-skills/docs/jh-user-picker.md`        |
+| 部门选择 | jh-dept-picker          | 参见 `.wl-skills/docs/jh-dept-picker.md`        |
+| 文件上传 | jh-file-upload          | 参见 `.wl-skills/docs/jh-file-upload.md`        |
 
 **新建组件判断：**
 
-- 3+ 页面相同逻辑 → `src/components/global/C_PascalCase/`
-- 同模块 2 页面共用 → `src/components/local/c_camelCase/`
+- 3+ 页面相同逻辑 → `.wl-skills/src/components/global/C_PascalCase/`
+- 同模块 2 页面共用 → `.wl-skills/src/components/local/c_camelCase/`
 - 业务强耦合 → 页面 `components/` 目录下
 
 ### 5. pages.ts 注册名推断
@@ -236,7 +236,7 @@ AI 根据提取的信息，内部构建 page-spec JSON（**不输出给用户**
   "pageName": "客户档案",           // 中文名
   "kebabName": "customer-archive",  // kebab-case 目录名
   "pattern": "LIST",                // LIST | MASTER_DETAIL | TREE_LIST | DETAIL_TABS | FORM_ROUTE | CHANGE_HISTORY | RECORD_FORM | OPERATION_STATION | TEMPLATE_DRIVEN
-  "path": "views/sale/demo/khda/customer-archive/",
+  "path": "views/sale/.wl-skills/templates/khda/customer-archive/",
   "pagesTs": ["customer-archive", "客户档案"],  // pages.ts 注册项
   "platformComponents": ["BaseQuery", "BaseTable", "jh-pagination"],
   "newComponents": [],              // 需要新建的组件名（空数组=不需要新建）
@@ -407,7 +407,7 @@ const [模块名]Module = gProd("[base-path]", {
 
 ## 输入模式 B：非规范详细设计文档
 
-> ⚠️ **模式 B 排除范围**：若文档路径含 `docs/spec/`，或文档内含 `§四 功能设计详细规范` / IPO 表格（含「处理逻辑」二级标题）/ 功能编码（正则 `/[A-Z]{2,6}[0-9]{3}/`）/ 流程说明五要素，
+> ⚠️ **模式 B 排除范围**：若文档路径含 `.wl-skills/docs/spec/`，或文档内含 `§四 功能设计详细规范` / IPO 表格（含「处理逻辑」二级标题）/ 功能编码（正则 `/[A-Z]{2,6}[0-9]{3}/`）/ 流程说明五要素，
 > **表明这是 wl-skills-design 的标准产出，不触发本模式**，应转发 `core/spec-doc-parse/SKILL.md`。
 > 本模式只处理**非规范、零散的**详设（本来就不规范的输入，AI 自由发挥是帮助）；面对高精度规范文档时，专属解析才能保证零损耗。
 

package/files/{.github → .wl-skills}/skills/core/prototype-scan/USAGE.md

@@ -31,10 +31,10 @@
 ### 示例 1：HTML 原型扫描
 
 ```
-你：扫描 docs/prototypes/客户管理/ 下的所有原型，生成页面清单。
+你：扫描 .wl-skills/docs/prototypes/客户管理/ 下的所有原型，生成页面清单。
 AI：[读取 SKILL.md → 输出 Pre-flight 声明]
     Pre-flight：
-    ├─ 来源：docs/prototypes/客户管理/ 共 7 个 HTML
+    ├─ 来源：.wl-skills/docs/prototypes/客户管理/ 共 7 个 HTML
     ├─ 输出：reports/PROTOTYPE_SCAN_客户管理_20260426.md
     └─ 不会生成代码
     [扫描中... 3 分钟]
@@ -64,7 +64,7 @@ AI：[输出 Pre-flight]
 
 ## 输出物
 
-`.github/reports/PROTOTYPE_SCAN_<模块>_<YYYYMMDD>.md` —— 包含：
+`.wl-skills/reports/PROTOTYPE_SCAN_<模块>_<YYYYMMDD>.md` —— 包含：
 
 - 页面清单表格（页面英文名 / 中文名 / 类型 / 路由 / 字段概要）
 - 各页面查询条件、表格列、表单字段的初步定义

package/files/{.github → .wl-skills}/skills/core/spec-doc-parse/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: spec-doc-parse
-description: "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, 功能编码, 需求设计说明书."
+description: "Use when: parsing STANDARD requirement-design specification documents produced by wl-skills-design (path contains .wl-skills/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 转页面, .wl-skills/docs/spec, 功能编码, 需求设计说明书."
 ---
 
 # Skill: 规范文档解构（spec-doc-parse）
 
-将 **wl-skills-design 产出的标准《需求设计说明书》**（`docs/spec/{项目代号}/` 下的 `ch1-3.md` + `4.x-{子模块}.md` + `4.N-data-report.md`）解构为与 `prototype-scan` **完全相同格式的 page-spec JSON**，作为 `api-contract` / `page-codegen` 的输入。
+将 **wl-skills-design 产出的标准《需求设计说明书》**（`.wl-skills/docs/spec/{项目代号}/` 下的 `ch1-3.md` + `4.x-{子模块}.md` + `4.N-data-report.md`）解构为与 `prototype-scan` **完全相同格式的 page-spec JSON**，作为 `api-contract` / `page-codegen` 的输入。
 
 > **双线汇聚原则**：原型线（prototype-scan）和规范线（本 Skill）是两条独立的输入线，但**汇聚点只有一个 —— page-spec JSON + api.md**。下游 `page-codegen` 不感知来源，两线代码完全共享。
 > **职责边界**：design 负责「生成标准」，kit 负责「解构标准、完整读取」。本 Skill 是 kit 侧解构能力的承载者。
@@ -17,9 +17,9 @@ description: "Use when: parsing STANDARD requirement-design specification docume
 | 维度 | prototype-scan（原型线） | spec-doc-parse（规范线） |
 |------|--------------------------|--------------------------|
 | 输入 | Axure HTML / 截图 / 口述 / **非规范**详设 | **wl-skills-design 标准说明书** |
-| 识别特征 | 视觉原型、自由格式文档 | `docs/spec/` 路径 / 功能编码 `/[A-Z]{2,6}[0-9]{3}/` / IPO 表「处理逻辑」/ 流程五要素 |
+| 识别特征 | 视觉原型、自由格式文档 | `.wl-skills/docs/spec/` 路径 / 功能编码 `/[A-Z]{2,6}[0-9]{3}/` / IPO 表「处理逻辑」/ 流程五要素 |
 | 解析方式 | 视觉/语义推断（精度 70-95%） | 规范结构精确映射（精度 95-100%） |
-| 禁区 | **不得处理** `docs/spec/` 标准文档 | **不接受** Axure HTML / 截图 |
+| 禁区 | **不得处理** `.wl-skills/docs/spec/` 标准文档 | **不接受** Axure HTML / 截图 |
 
 > 当用户输入命中规范线特征时，**强制走本 Skill**，禁止 prototype-scan 接管（见 `_registry.md` 调度规则「优先级 0」）。
 
@@ -33,7 +33,7 @@ description: "Use when: parsing STANDARD requirement-design specification docume
 ✅ 已读取 core/prototype-scan/SKILL.md       → page-spec JSON 结构定义（统一汇聚格式）
 ✅ 已读取 standards/12-base-table.md         → AGGrid 列定义约束（供下游 page-codegen）
 ✅ 已识别文档结构：{doc-skeleton 5 文件 / 单卷 / 单子模块}
-✅ 来源文件：{docs/spec/{项目代号}/...}
+✅ 来源文件：{.wl-skills/docs/spec/{项目代号}/...}
 ✅ 输出：reports/SPEC_PARSE_{模块}_{日期}.md（page-spec JSON + 解析报告）
 ✅ 不会生成代码（解析 + 报告，代码生成由 page-codegen 承接）
 ```
@@ -52,7 +52,7 @@ description: "Use when: parsing STANDARD requirement-design specification docume
 ## 前置检查
 
 ```
-□ 文档来源路径：docs/spec/{项目代号}/
+□ 文档来源路径：.wl-skills/docs/spec/{项目代号}/
 □ 文件清单：ch1-3.md（概述）+ 4.x-{子模块}.md（详细设计）[+ 4.N-data-report.md]
 □ 目标项目路径：src/views/[域]/[模块]/[子模块]/
 □ 服务缩写：从功能编码前缀推断（pm / mmwr / mmsm / sale / hrms / base）
@@ -82,7 +82,7 @@ Step 9  自验证+报告  Parse Validation 五项检查 + 自动修复 + 解析
 依据 `wl-skills-design` 的 `doc-skeleton.md` 5 文件结构识别：
 
 ```
-docs/spec/{项目代号}/
+.wl-skills/docs/spec/{项目代号}/
 ├── ch1-3.md              ← 第 1~3 章（总体概述、术语、范围）
 ├── 4.1-{子模块名}.md     ← 子模块详细设计（流程 + IPO）
 ├── 4.2-{子模块名}.md
@@ -231,7 +231,7 @@ PMMB-A-01-M-03（修改目标）     → permission:pmmb:target:edit
 
 ```jsonc
 "notes": [
-  "[规范线] 来源：docs/spec/huaxin/4.1-target.md §4.1.4.1 PMMB001",
+  "[规范线] 来源：.wl-skills/docs/spec/huaxin/4.1-target.md §4.1.4.1 PMMB001",
   "[规范线] 权限码候选：permission:pmmb:target:list / :add / :edit",
   "[规范线] 触发事件：提交后写入 bom_ratio 表并触发重算（见处理逻辑）",
   "[待确认] status 字段 dictCode 推断为 target_status，需后端确认"
@@ -270,7 +270,7 @@ PMMB-A-01-M-03（修改目标）     → permission:pmmb:target:edit
 ```markdown
 # Spec-Doc Parse 报告
 - 生成时间：{YYYY-MM-DD HH:mm}
-- 来源文件：docs/spec/{项目代号}/4.x-{子模块}.md
+- 来源文件：.wl-skills/docs/spec/{项目代号}/4.x-{子模块}.md
 - 解析范围：{整卷 / 子模块 / 功能编码}
 
 ## 解析摘要

package/files/{.github → .wl-skills}/skills/core/spec-doc-parse/USAGE.md

@@ -7,7 +7,7 @@
 
 ## 这个 Skill 解决什么问题
 
-把 **wl-skills-design 产出的标准《需求设计说明书》**（`docs/spec/` 下的 IPO 表、功能编码、流程五要素）**完整解构**为一份《页面清单》（page-spec JSON），作为后续 `api-contract` 和 `page-codegen` 的输入。
+把 **wl-skills-design 产出的标准《需求设计说明书》**（`.wl-skills/docs/spec/` 下的 IPO 表、功能编码、流程五要素）**完整解构**为一份《页面清单》（page-spec JSON），作为后续 `api-contract` 和 `page-codegen` 的输入。
 
 一句话：**design 负责「写标准文档」，spec-doc-parse 负责「读懂标准文档、转成可生成代码的结构」。**
 
@@ -20,7 +20,7 @@
 | 线 | Skill | 输入 | 何时用 |
 |----|-------|------|--------|
 | **原型线** | `prototype-scan` | Axure 原型 / 截图 / 口述 / 零散详设 | 只有原型、没有规范文档时 |
-| **规范线** | `spec-doc-parse`（本 Skill） | wl-skills-design 标准说明书 | 已有 `docs/spec/` 标准文档时 |
+| **规范线** | `spec-doc-parse`（本 Skill） | wl-skills-design 标准说明书 | 已有 `.wl-skills/docs/spec/` 标准文档时 |
 
 > 两条线最终都汇聚到**同一份 page-spec JSON**，下游代码生成完全一样。
 > 所以：**有标准说明书就走规范线，精度最高（95-100%）；只有原型走原型线。**
@@ -29,7 +29,7 @@
 
 ## 何时使用
 
-- 拿到 wl-skills-design 生成的 `docs/spec/{项目代号}/4.x-xxx.md`，要把它变成页面
+- 拿到 wl-skills-design 生成的 `.wl-skills/docs/spec/{项目代号}/4.x-xxx.md`，要把它变成页面
 - 说明书里有功能编码（如 PMMB001）、IPO 表、流程图说明
 - 想把整卷说明书一次性解构成页面清单，再批量生成代码
 
@@ -46,11 +46,11 @@
 ### 示例 1：解析单个子模块
 
 ```
-你：解析 docs/spec/huaxin/4.1-target.md，生成页面清单。
+你：解析 .wl-skills/docs/spec/huaxin/4.1-target.md，生成页面清单。
 AI：[读取 SKILL.md → 输出 Pre-flight]
     Pre-flight：
     ├─ 识别结构：doc-skeleton 单子模块（4.1 目标管理）
-    ├─ 来源：docs/spec/huaxin/4.1-target.md
+    ├─ 来源：.wl-skills/docs/spec/huaxin/4.1-target.md
     ├─ 输出：reports/SPEC_PARSE_target_20260531.md
     └─ 不会生成代码
     [解析中...]
@@ -62,7 +62,7 @@ AI：[读取 SKILL.md → 输出 Pre-flight]
 ### 示例 2：误用原型线的自动纠偏
 
 ```
-你：扫描 docs/spec/huaxin/4.1-target.md 生成页面。
+你：扫描 .wl-skills/docs/spec/huaxin/4.1-target.md 生成页面。
 AI：检测到输入是 wl-skills-design 标准说明书（含功能编码 + IPO 表）。
     → 这属于「规范线」，已自动切换到 spec-doc-parse（精度更高）。
     [继续按规范线解析]

package/files/{.github → .wl-skills}/skills/core/template-extract/SKILL.md

@@ -5,7 +5,7 @@ description: "Use when: extracting domain-specific page templates from existing
 
 # Skill: 模板提取（template-extract）
 
-从现有项目的成熟页面提取领域模板，沉淀到 `.github/skills/core/page-codegen/templates/domains/`，扩充团队 AI 模板库。
+从现有项目的成熟页面提取领域模板，沉淀到 `.wl-skills/skills/core/page-codegen/templates/domains/`，扩充团队 AI 模板库。
 
 > **核心理念**：模板贡献门槛极低 — 开发者只需说出一个页面目录路径，AI 完成 90% 的分析和写作。
 

package/files/{.github → .wl-skills}/skills/core/template-extract/USAGE.md

@@ -90,4 +90,4 @@ A：建议至少同事 review 一下 meta.json + 是否真有复用价值。直
 A：贡献者维护一段时间，稳定后由 kit 维护者接管。模板里要写 author + lastUpdate。
 
 **Q：能否私有领域只抽到本仓库不发布？**
-A：可以。`templates/domains/` 在 `.github/skills/` 下，跟着业务项目走。kit 包不强制收集。
+A：可以。`templates/domains/` 在 `.wl-skills/skills/` 下，跟着业务项目走。kit 包不强制收集。

package/files/{.github → .wl-skills}/skills/ops/code-fix/SKILL.md

@@ -1,96 +1,135 @@
----
-name: code-fix
-description: "Use when: fixing code convention issues found in convention-audit reports. Triggers on: 自动修复, 整改偏差, 修复报告, 规范整改, 修复偏差, code fix, 整改规范."
----
-
-# Skill: 受控自动修复（code-fix）
-
-读取 `reports/规范审查报告.md` 中的偏差条目，在用户确认 diff 后执行单条或分组修复。
-
-> **前置**：必须先运行 `convention-audit` 生成审计报告，code-fix 依赖其输出。  
-> **范围**：仅修复 🟡 / 🟢 等级偏差；🔴 严重偏差必须人工或 page-codegen 重新生成。
-
----
-
-## 工作流
-
-```
-reports/规范审查报告.md（convention-audit 输出）
-        │
-        ▼
-[1] 用户从报告挑选 issueId（或 issueGroup），或说"列出可修复项"
-        │
-        ▼
-[2] 解析 issue → 定位文件 + 行号 + 偏差类型
-        │
-        ▼
-[3] 选择修复策略：
-    ├─ rule-based（如缺 :scoped、缺 cid 等）→ 直接按规则生成 patch
-    └─ ai-based（语义性偏差）→ AI 生成 patch
-        │
-        ▼
-[4] Pre-flight 输出 diff 预览（人读，必须等待确认）
-        │
-        ▼
-[5] 用户 yes → 写入文件 + 在报告中标记该条目为 ✅ 已修复
-    用户 no  → 跳过该 issue，回到挑选界面
-```
-
----
-
-## 受控原则（严格执行，不可绕过）
-
-| 原则 | 说明 |
-| --- | --- |
-| **不修 🔴** | 严重偏差必须人工或 page-codegen 处理，code-fix 不介入 |
-| **不破坏功能** | 只改报告点名的行，不顺手"重构"周边代码 |
-| **不批量盲改** | 每个文件都先 diff 预览，禁止跳过用户确认 |
-| **不生成新逻辑** | 只修偏差，不做功能补全（那是 page-codegen 的职责） |
-| **范围明确** | 若用户引导修改业务逻辑，必须拒绝并说明原因 |
-
----
-
-## 偏差类型 → 修复策略
-
-| 偏差类型 | 来源 standards | 策略 |
-| --- | --- | --- |
-| EColumn 缺 cid | standards/12-base-table.md | rule-based |
-| 列级 cid 只用缩写前缀（如 `mca-steelCode`） | standards/12-base-table.md | rule-based |
-| scss 文件缺 `:scoped` 包裹 | standards/02-code-structure.md | rule-based |
-| import 路径不规范 | standards/04-coding-basics.md | rule-based |
-| `any` 滥用（> 3 处/页） | standards/09-typescript.md | ai-based |
-| API_CONFIG URL 命名偏差 | api-contract.md | ai-based |
-| 表格列定义与 api.md 字段不一致 | api-contract + data-ts | ai-based |
-| 业务语义偏差（流程不对）| 多 standards 综合 | **不修复，标记人工** |
-
----
-
-## 触发命令形态
-
-```
-"修复 reports/规范审查报告.md 中的 issue#3"              → 单条修复
-"修复 reports/规范审查报告.md 中所有 scss 偏差"          → 分组修复
-"修复全部 rule-based 偏差，跳过 ai-based"                → 受控批量
-"列出可修复的 issue"                                     → 仅列清单，不动任何文件
-```
-
----
-
-## Pre-flight 声明示例
-
-```
-🚀 已触发技能 ops/code-fix/SKILL.md → 受控自动修复偏差
-✅ 已读取 reports/规范审查报告.md    → 找到 12 条偏差（rule-based 8 条，ai-based 4 条）
-✅ 当前目标：issue#3（EColumn 缺 cid）→ 文件 src/views/sale/order/data.ts L42
-⚠️  以下操作会修改文件，请在 diff 预览后确认
-```
-
----
-
-## 与其他 Skill 的关系
-
-| Skill | 关系 |
-| --- | --- |
-| convention-audit | **前置**：必须先有审计报告，code-fix 才有输入 |
-| page-codegen | 互斥：生成新页面用 codegen，不用 fix |
-| template-extract | 无直接关系 |
+---
+name: code-fix
+description: "Use when: fixing code convention issues found in convention-audit reports. Triggers on: 自动修复, 整改偏差, 修复报告, 规范整改, 修复偏差, code fix, 整改规范."
+---
+
+# Skill: 受控自动修复（code-fix）
+
+读取 `reports/规范审查报告.md` 中的偏差条目，在用户确认 diff 后执行单条或分组修复。
+
+> **前置**：必须先运行 `convention-audit` 生成审计报告，code-fix 依赖其输出。  
+> **范围**：仅修复 🟡 / 🟢 等级偏差；🔴 严重偏差必须人工或 page-codegen 重新生成。
+
+---
+
+## 工作流
+
+```
+reports/规范审查报告.md（convention-audit 输出）
+        │
+        ▼
+[1] 用户从报告挑选 issueId（或 issueGroup），或说"列出可修复项"
+        │
+        ▼
+[2] 解析 issue → 定位文件 + 行号 + 偏差类型
+        │
+        ▼
+[3] 选择修复策略：
+    ├─ rule-based（如缺 :scoped、缺 cid 等）→ 直接按规则生成 patch
+    └─ ai-based（语义性偏差）→ AI 生成 patch
+        │
+        ▼
+[4] Pre-flight 输出 diff 预览（人读，必须等待确认）
+        │
+        ▼
+[5] 用户 yes → 写入文件 + 在报告中标记该条目为 ✅ 已修复
+    用户 no  → 跳过该 issue，回到挑选界面
+        │
+        ▼
+[6] ★ 强制复扫验证（闭环关键步骤，不可跳过）
+    ├─ 本轮修复完成后，自动执行 wl-skills validate 检测修复结果
+    ├─ 如仍有 error → 提示未完全修复，建议继续处理
+    └─ 全部通过 → 输出 ✔ 闭环完成，可安全提交
+```
+
+---
+
+## 强制复扫验证（v2.11+ 闭环保障）
+
+> **闭环原则**：code-fix 修复后必须验证修复效果，不允许"改完就走"。
+
+AI 在完成**本轮全部修复**后（单条或批量），**必须自动执行**：
+
+1. 调用 `wl-skills validate`（或 MCP `wls_validate_page`）对修复文件检测
+2. 检测通过（0 error）→ 输出 "✔ 复扫通过，闭环完成"
+3. 检测仍有 error → 输出残余问题清单，建议继续修复或标记人工
+4. 完成摘要中记录复扫结果
+
+```
+## 完成摘要
+- 修复项：{N} 条（rule-based {N} / ai-based {N}）
+- 复扫结果：✔ 通过 / ✖ 残余 {N} 个 error
+- 涉及文件：{file list}
+
+## 复扫验证
+- 执行：wl-skills validate
+- error: 0 / warn: {N}
+- 结论：可安全提交 / 需继续处理
+
+## 建议下一步
+- next_suggest：git add + git commit（复扫通过时）
+- next_suggest：继续 code-fix 或人工处理（复扫未通过时）
+```
+
+**不可跳过**：即使用户说"不用验证了"，AI 也必须执行复扫。这是闭环完整性的硬性约束。
+
+---
+
+## 受控原则（严格执行，不可绕过）
+
+| 原则 | 说明 |
+| --- | --- |
+| **不修 🔴** | 严重偏差必须人工或 page-codegen 处理，code-fix 不介入 |
+| **不破坏功能** | 只改报告点名的行，不顺手"重构"周边代码 |
+| **不批量盲改** | 每个文件都先 diff 预览，禁止跳过用户确认 |
+| **不生成新逻辑** | 只修偏差，不做功能补全（那是 page-codegen 的职责） |
+| **范围明确** | 若用户引导修改业务逻辑，必须拒绝并说明原因 |
+
+---
+
+## 偏差类型 → 修复策略
+
+| 偏差类型 | 来源 standards | 策略 |
+| --- | --- | --- |
+| EColumn 缺 cid | standards/12-base-table.md | rule-based |
+| 列级 cid 只用缩写前缀（如 `mca-steelCode`） | standards/12-base-table.md | rule-based |
+| scss 文件缺 `:scoped` 包裹 | standards/02-code-structure.md | rule-based |
+| import 路径不规范 | standards/04-coding-basics.md | rule-based |
+| `any` 滥用（> 3 处/页） | standards/09-typescript.md | ai-based |
+| API_CONFIG URL 命名偏差 | api-contract.md | ai-based |
+| 表格列定义与 api.md 字段不一致 | api-contract + data-ts | ai-based |
+| 业务语义偏差（流程不对）| 多 standards 综合 | **不修复，标记人工** |
+
+---
+
+## 触发命令形态
+
+```
+"修复 reports/规范审查报告.md 中的 issue#3"              → 单条修复
+"修复 reports/规范审查报告.md 中所有 scss 偏差"          → 分组修复
+"修复全部 rule-based 偏差，跳过 ai-based"                → 受控批量
+"列出可修复的 issue"                                     → 仅列清单，不动任何文件
+```
+
+---
+
+## Pre-flight 声明示例
+
+```
+🚀 已触发技能 ops/code-fix/SKILL.md → 受控自动修复偏差
+✅ 已读取 reports/规范审查报告.md    → 找到 12 条偏差（rule-based 8 条，ai-based 4 条）
+✅ 当前目标：issue#3（EColumn 缺 cid）→ 文件 src/views/sale/order/data.ts L42
+⚠️  以下操作会修改文件，请在 diff 预览后确认
+```
+
+---
+
+## 与其他 Skill 的关系
+
+| Skill | 关系 |
+| --- | --- |
+| convention-audit | **前置**：必须先有审计报告，code-fix 才有输入 |
+| wl-skills validate | **后置**：修复完成后必须复扫验证（闭环保障） |
+| convention-audit（复扫） | **后置可选**：大规模修复后可触发 --quick 模式复扫 |
+| page-codegen | 互斥：生成新页面用 codegen，不用 fix |
+| template-extract | 无直接关系 |

package/files/{.github → .wl-skills}/skills/sync/_mcp-guardrail.md

@@ -49,12 +49,12 @@ AI 调用 MCP 工具后，按返回内容判定属于哪一类，并按对应剧
 
 如果工具返回类似：
 - `请在 env.local.json 中填写真实的 gatewayPath（当前为占位值）`
-- `请在 .github/skills/sync/env.local.json 填写 menu.domainId`
+- `请在 .wl-skills/skills/sync/env.local.json 填写 menu.domainId`
 - `配置文件不存在: .../env.local.json`
 
 AI **立即转入引导模式**：
 
-1. `read_file` 加载 `.github/skills/sync/menu-sync/env/guide.md`（统一配置说明）
+1. `read_file` 加载 `.wl-skills/skills/sync/menu-sync/env/guide.md`（统一配置说明）
 2. 告诉用户具体哪个字段缺失、获取方式（如 token 抓包、domainId Network 查询）
 3. 等待用户填好 `env.local.json` 后**自动重试同一个 MCP 工具调用**
 4. 直到配置完整、调用成功为止 → 完成闭环
@@ -95,7 +95,7 @@ AI **立即转入引导模式**：
 ```
 🚀 已触发技能 {skill-name}/SKILL.md → {一句话用途}
 ✅ MCP 工具检查：{要用到的 wls_* 全部列出，✓/✗}
-✅ 已读取 .github/skills/sync/env.local.json → gatewayPath/token/sysAppNo/{其他必填}
+✅ 已读取 .wl-skills/skills/sync/env.local.json → gatewayPath/token/sysAppNo/{其他必填}
 ✅ 已读取 {本 Skill 的 SYS_*_INFO.md 基线}
 ✅ 操作模式：{pull / push / audit / ...}
 ```

package/files/{.github → .wl-skills}/skills/sync/dict-sync/SKILL.md

@@ -21,7 +21,7 @@ description: "Use when: syncing data dictionary entries to the backend, pulling
 
 ## 配置（统一配置文件）
 
-读取 `.github/skills/sync/env.local.json`（已在 `.gitignore`，不入 git）：
+读取 `.wl-skills/skills/sync/env.local.json`（已在 `.gitignore`，不入 git）：
 
 ```json
 {
@@ -50,8 +50,8 @@ description: "Use when: syncing data dictionary entries to the backend, pulling
 ```
 🚀 已触发技能 dict-sync/SKILL.md → 字典同步
 ✅ MCP 工具检查：wls_dict_query / wls_dict_upsert 均可用
-✅ 已读取 .github/skills/sync/env.local.json → 网关 + token + sysAppNo + dict.moduleId
-✅ 已读取 .github/reports/SYS_DICT_INFO.md   → 本地字典基线
+✅ 已读取 .wl-skills/skills/sync/env.local.json → 网关 + token + sysAppNo + dict.moduleId
+✅ 已读取 .wl-skills/reports/SYS_DICT_INFO.md   → 本地字典基线
 ✅ 操作模式：{pull / push / audit}
 ✅ 目标字典码：{用户指定 / data.ts 扫描结果}
 ```
@@ -142,7 +142,7 @@ logicType: BusLogicDataType.dict, logicValue: "DICT_CODE"
 | SALES_COMPANY | 销售公司 | 3 | ✅ created |
 | PRODUCT_SEGMENT | 产品板块 | - | ⏭️ skipped（线上已有） |
 
-执行完成后，将新建字典追加写入 `.github/reports/SYS_DICT_INFO.md`。
+执行完成后，将新建字典追加写入 `.wl-skills/reports/SYS_DICT_INFO.md`。
 
 ---
 
@@ -165,7 +165,7 @@ logicType: BusLogicDataType.dict, logicValue: "DICT_CODE"
 
 ## SYS_DICT_INFO.md — 本地基线格式
 
-路径：`.github/reports/SYS_DICT_INFO.md`
+路径：`.wl-skills/reports/SYS_DICT_INFO.md`
 
 ```markdown
 ## ORDER_STATUS（订单状态）

package/files/{.github → .wl-skills}/skills/sync/dict-sync/USAGE.md

@@ -34,7 +34,7 @@
 
 ## 前置条件
 
-`.github/skills/sync/env.local.json`（已 gitignore，每个开发者本地填自己的 token）：
+`.wl-skills/skills/sync/env.local.json`（已 gitignore，每个开发者本地填自己的 token）：
 
 ```json
 {
@@ -84,7 +84,7 @@ AI：[Pre-flight]
 | 维度 | `business-doc-extract` | `dict-sync` |
 |---|---|---|
 | 职责 | 业务理解 / 设计意图 | 线上事实 / 数据落地 |
-| 输出 | `docs/business/0X-xx/dictionary.md`（人读） | 后端字典表（系统读） |
+| 输出 | `.wl-skills/docs/business/0X-xx/dictionary.md`（人读） | 后端字典表（系统读） |
 | 时机 | 项目/模块沉淀阶段 | 联调前 / 上线前 |
 
 两者**互不替代**：业务文档说的是"应该有什么字典"，dict-sync 解决"线上有没有"。建议顺序：`business-doc-extract` 整理出 dictionary.md 草案 → 评审 → `dict-sync` 落地。

package/files/{.github → .wl-skills}/skills/sync/menu-sync/SKILL.md

@@ -9,7 +9,7 @@ description: "Use when: creating system menus for newly generated pages, batch r
 
 > **背景**：本项目是 Module Federation 子应用，页面在 `pages.ts` 注册后，
 > 还需要在后端菜单表中创建对应记录，系统才能路由到该页面。
-> 设计文档：`.github/guides/architecture.md`
+> 设计文档：`.wl-skills/guides/architecture.md`
 
 ---
 
@@ -19,14 +19,14 @@ description: "Use when: creating system menus for newly generated pages, batch r
 
 | 数据                                             | 来源                       | 说明                                    |
 | ------------------------------------------------ | -------------------------- | --------------------------------------- |
-| 菜单名称、路径、组件、权限、隐藏、排序、应用编码 | `.github/reports/SYS_MENU_INFO*.md` | 由 page-codegen 追加写入，AI 直接读取 |
+| 菜单名称、路径、组件、权限、隐藏、排序、应用编码 | `.wl-skills/reports/SYS_MENU_INFO*.md` | 由 page-codegen 追加写入，AI 直接读取 |
 | `parentMenuNameCode`                             | `wls_menu_query` 查询菜单树 | 从父级节点获取，无需手填               |
 | **gatewayPath、parentMenuId、sysAppNo、token**   | `env.local.json`           | 可通过 token/接口辅助提取               |
 | **domainId**                                     | 用户确认 / 菜单后台 Network | 当前权限下无法总是自动获取，需确认     |
 
 ### 配置文件（统一维护，菜单/字典/权限共用）
 
-优先读取 `.github/skills/sync/env.local.json`（v2.1.5+ 统一配置）：
+优先读取 `.wl-skills/skills/sync/env.local.json`（v2.1.5+ 统一配置）：
 
 ```json
 {
@@ -49,7 +49,7 @@ menu-sync 读取规则：`parentMenuId` 优先从 `menu.parentMenuId` 读取，
 
 1. **首次**：按 `env/guide.md` 填写 `skills/sync/env.local.json` 的字段
 2. **之后**：直接对 AI 说「帮我创建菜单」/「同步菜单」/「补菜单」
-3. AI 自动执行：读 `.github/reports/SYS_MENU_INFO*.md` → 读 `env.local.json` → 优先调用 `wls_menu_sync_from_report` 一步完成确定性同步；如需手动拆分，则 `wls_menu_query` 查 domain 菜单树 → 先 upsert 一级目录 → 用返回 id upsert 二级页面菜单 → 输出 created/updated/skipped 结果表
+3. AI 自动执行：读 `.wl-skills/reports/SYS_MENU_INFO*.md` → 读 `env.local.json` → 优先调用 `wls_menu_sync_from_report` 一步完成确定性同步；如需手动拆分，则 `wls_menu_query` 查 domain 菜单树 → 先 upsert 一级目录 → 用返回 id upsert 二级页面菜单 → 输出 created/updated/skipped 结果表
 4. **全程无需手动执行任何命令**
 
 SYS_MENU_INFO.md 是 menu-sync Skill 的输入数据源：
@@ -81,7 +81,7 @@ SYS_MENU_INFO.md 是 menu-sync Skill 的输入数据源：
 ### 前置条件
 
 1. MCP 已连接（工具列表中可见 `wls_menu_sync_from_report`）
-2. `.github/skills/sync/env.local.json` 已填写 `token`（纯 JWT，不含 `bearer ` 前缀）、`gatewayPath`、`sysAppNo`、`menu.parentMenuId`、`menu.domainId`
+2. `.wl-skills/skills/sync/env.local.json` 已填写 `token`（纯 JWT，不含 `bearer ` 前缀）、`gatewayPath`、`sysAppNo`、`menu.parentMenuId`、`menu.domainId`
 
 ### 输入
 
@@ -253,7 +253,7 @@ POST /system/menu/batchPush
 - 按 `componentPath` 做 upsert（存在则更新结构字段，不存在则新增）
 - **不删除**后端多余的菜单
 - **不碰**权限/角色绑定字段
-- 详见 `.github/guides/architecture.md`
+- 详见 `.wl-skills/guides/architecture.md`
 
 ### pages.ts 扩展
 

package/files/{.github → .wl-skills}/skills/sync/menu-sync/USAGE.md

@@ -31,7 +31,7 @@
 
 ## 前置条件
 
-`.github/skills/sync/env.local.json`（首次使用先填写，已加入 `.gitignore`）：
+`.wl-skills/skills/sync/env.local.json`（首次使用先填写，已加入 `.gitignore`）：
 
 ```json
 {
@@ -70,8 +70,8 @@ AI：[Pre-flight]
 
 ## 输出物
 
-1. **基线文件**：`.github/reports/SYS_MENU_INFO.md` —— 线上菜单的本地基线（团队 review 用）
-2. **同步报告**：`.github/reports/MENU_SYNC_<YYYYMMDD>.md` —— 本次新增/更新了哪些菜单
+1. **基线文件**：`.wl-skills/reports/SYS_MENU_INFO.md` —— 线上菜单的本地基线（团队 review 用）
+2. **同步报告**：`.wl-skills/reports/MENU_SYNC_<YYYYMMDD>.md` —— 本次新增/更新了哪些菜单
 3. **回滚 SQL**：报告里附带 DELETE SQL，用于回退
 
 ---

package/files/{.github → .wl-skills}/skills/sync/menu-sync/env/guide.md

@@ -6,8 +6,8 @@
 
 ## 配置文件位置（优先使用新统一路径）
 
-**新路径（v2.1.5+ 推荐）**：`.github/skills/sync/env.local.json`  
-**兼容路径（老版）**：`.github/skills/sync/menu-sync/env/env.local.json`
+**新路径（v2.1.5+ 推荐）**：`.wl-skills/skills/sync/env.local.json`  
+**兼容路径（老版）**：`.wl-skills/skills/sync/menu-sync/env/env.local.json`
 
 AI 优先读新路径，如不存在自动回落到兼容路径。