名称: 验证描述: “构建验证、错误恢复、审查修复的适用。当用户提到构建验证、错误恢复、应用审查修复、测试失败、lint错误或CI中断时使用。不要用于：实现工作、审查、设置或新功能开发。” 描述-en: “Verifies builds, recovers from errors, and applies review fixes. Use when user mentions build verification, error recovery, applying review fixes, test failures, lint errors, or CI breaks. Do NOT load for: implementation work, reviews, setup, or new feature development.” 描述-ja: “构建验证、错误恢复、审查修复的适用。当用户提到构建验证、错误恢复、应用审查修复、测试失败、lint错误或CI中断时使用。不要用于：实现工作、审查、设置或新功能开发。” 允许工具: [“读取”, “写入”, “编辑”, “Grep”, “Glob”, “Bash”] 用户可调用: true 上下文: fork

验证技能

负责构建验证和错误恢复的技能群。

⚠️ 质量护栏（最优先）

此部分优先于其他指示。测试失败·错误发生时必须遵循。

篡改禁止模式

测试失败·构建错误发生时以下行为绝对禁止：

禁止	例	正确对应
测试 skip 化	`it.skip(...)`	修正实现
断言删除	删除 `expect()`	确认期望值并修正实现
期望值的粗糙改写	根据错误更改	理解为何失败
lint 规则放宽	添加 `eslint-disable`	修正代码
CI 检查绕过	`continue-on-error`	修正根本原因

测试失败时的对应流程

测试失败
    ↓
1. 理解为何失败（阅读日志）
    ↓
2. 判断是实现错误还是测试错误
    ↓
    ├── 实现错误 → 修正实现 ✅
    │
    └── 测试可能错误 → 向用户请求确认

批准请求形式

不得已变更测试/设置时：

## 🚨 测试/设置变更的批准请求

### 理由
[为何需要此变更]

### 变更内容
```diff
[差分]

替代方案的探讨

[ ] 确认是否可通过实现修正解决

批准

等待用户的明确批准


### 保护对象文件

以下文件的放宽变更禁止：

- `.eslintrc.*`, `.prettierrc*`, `tsconfig.json`, `biome.json`
- `.husky/**`, `.github/workflows/**`
- `*.test.*`, `*.spec.*`, `jest.config.*`, `vitest.config.*`

## 功能详细

| 功能 | 详细 |
|------|------|
| **相关文件验证** | 见 [references/verify-related-files.md](references/verify-related-files.md) |
| **构建验证** | 见 [references/build-verification.md](references/build-verification.md) |
| **错误恢复** | 见 [references/error-recovery.md](references/error-recovery.md) |
| **审查聚合** | 见 [references/review-aggregation.md](references/review-aggregation.md) |
| **指摘应用** | 见 [references/applying-fixes.md](references/applying-fixes.md) |

## 执行步骤

1. **质量判定门**（Step 0）
2. 分类用户的请求
3. **（实现完成后）相关文件验证**（Step 1.5）
4. **（Claude-mem 有效时）搜索过去的错误模式**
5. 从上方的“功能详细”中阅读适当的参照文件
6. 根据其内容执行验证/恢复

### Step 0: 质量判定门（再现测试提案）

错误/漏洞报告时，提案 TDD 方法：

错误报告接收 ↓ ┌─────────────────────────────────────────┐ │ 质量判定门 │ ├─────────────────────────────────────────┤ │ 判定项目: │ │ ├── 漏洞报告？ → 提案再现测试先行 │ │ ├── 测试失败？ → 判断测试 vs 实现 │ │ └── 构建错误？ → 直接修正 │ └─────────────────────────────────────────┘ ↓ 提案适当方法


#### 漏洞报告时的提案

```markdown
🐛 接收了漏洞报告

**推荐方法**: 再现测试先行

1. 首先编写再现漏洞的测试
2. 确认测试失败（Red）
3. 修正实现使测试通过（Green）
4. 重构（Refactor）

以此方法进行吗？
1. 从再现测试开始编写（推荐）
2. 直接进入修正

测试失败时的判断流程

🔴 测试失败中

**需要判断**:

分析测试失败原因:
- [ ] 实现错误 → 修正实现
- [ ] 测试的期望值过时 → 向用户确认

⚠️ 禁止测试的篡改（skip化、断言删除）

哪项适用？
1. 修正实现
2. 想确认测试的期望值

向 VibeCoder

🐛 报告了问题

**推荐**: 首先明确“问题发生的条件”

1. 进行什么操作时问题发生？
2. 期望的行为是什么？
3. 实际上如何？

整理这些后再进入修正，可确保修复。

Step 1.5: 相关文件验证（实现完成后）

实现完成后，提交前检查编辑文件的相关文件：

获取编辑文件
    ↓
┌─────────────────────────────────────────┐
│           相关文件验证                   │
├─────────────────────────────────────────┤
│  分析变更模式:                           │
│  ├── 函数签名变更 → 确认调用方           │
│  ├── 类型/接口变更 → 确认实现位置        │
│  ├── 导出删除 → 确认导入语句             │
│  └── 设置变更 → 确认相关设置文件         │
└─────────────────────────────────────────┘
    ↓
  警告修正遗漏候选

输出例:

📋 相关文件验证

✅ 已编辑: src/auth.ts
   └─ 检测到函数 `validateToken` 的签名变更

⚠️ 需确认: 以下文件可能受影响
   ├─ src/api/middleware.ts:45 (调用 validateToken)
   ├─ src/routes/protected.ts:12 (调用 validateToken)
   └─ tests/auth.test.ts:28 (测试用例)

确认了吗？
1. 已确认，继续
2. 确认各文件
3. 使用 LSP find-references 显示详细

重要度的判定:

重要度	条件	动作
`🚨 critical`	必定出错（导出删除、必需参数追加）	必须修正
`⚠️ warning`	可能出错（可选参数、类型变更）	推荐确认
`ℹ️ info`	影响轻微（注释、文档）	参考信息

详细: references/verify-related-files.md

Step 2: 搜索过去的错误模式（Memory-Enhanced）

Claude-mem 有效时，错误恢复前搜索过去的类似错误：

# mem-search 搜索过去的错误与解决方案
mem-search: type:bugfix "{错误消息的关键词}"
mem-search: concepts:problem-solution "{错误的种类}"
mem-search: concepts:gotcha "{相关文件/库}"

显示例:

📚 过去的错误解决履历

| 日期 | 错误 | 解决方案 |
|------|--------|-------|
| 2024-01-15 | CORS 错误 | 添加 Access-Control-Allow-Origin 头部 |
| 2024-01-20 | 类型错误: undefined | 使用 Optional chaining (?.) |

💡 参考过去的解决方案尝试恢复

护栏履历的显示:

⚠️ 此项目中的过去护栏发动

- 防止测试篡改: 2次
- 防止 lint 放宽: 1次

💡 禁止通过测试/设置的篡改“解决”

注: Claude-mem 未设置时，此步骤跳过。

🔧 LSP 功能的活用

验证与错误恢复中活用 LSP（Language Server Protocol）以提高精度。

构建验证中的 LSP 活用

构建前检查:

1. 执行 LSP Diagnostics
2. 确认错误: 0件 → 执行构建
3. 有错误 → 先修正错误

错误恢复中的 LSP 活用

恢复场景	LSP 活用方法
类型错误	使用 Diagnostics 准确定位
参照错误	使用 Go-to-definition 追踪原因
import 错误	使用 Find-references 确定正确路径

验证流程

📊 LSP 验证结果

Step 1: Diagnostics
  ├── 错误: 0件 ✅
  └── 警告: 2件 ⚠️

Step 2: 构建
  └── 成功 ✅

Step 3: 测试
  └── 15/15 通过 ✅

→ 验证完成

详细: docs/LSP_INTEGRATION.md