@ranger1/dx 0.1.104 → 0.1.106

package/skills/backend-layering-audit-fixer/SKILL.md

@@ -1,180 +0,0 @@
----
-name: backend-layering-audit-fixer
-description: Use when backend、NestJS 分层架构或事务规范审查中，需要检查 Service 是否绕过 Repository 直接访问数据库、Controller 是否跨层注入 Repository、Service 是否伪装 Repository、事务装饰器是否匹配 afterCommit 使用、非 HTTP 场景事务模式是否正确、SSE 端点是否误加事务装饰器、以及是否存在直接 prisma.$transaction() 调用。
----
-
-# 后端三层架构与事务规范合规检查
-
-## 概览
-
-扫描后端代码是否遵守 **Controller → Service → Repository** 三层架构约束及事务规范。默认只输出审计结果和修复建议；用户明确要求时才自动修复。
-
-规则来源：`ruler/conventions.md` 第 4 节 "NestJS/Prisma 约定" + 第 5 节 "事务规范"。
-
-## 检查项
-
-### 分层架构
-
-| 编号 | 违规类型 | 说明 |
-|------|----------|------|
-| L1 | Service 直接访问数据库 | Service 注入 `PrismaService` 并调用 `this.prisma.*` |
-| L2 | Service 伪装为 Repository | Service 文件含 `getClient()` / `txHost.tx` 模式，实质是 Repository |
-| L3 | Service 死依赖 | Service 注入 `PrismaService` 但从未使用 |
-| L4 | Controller 跨层调用 | Controller 直接注入 Repository |
-
-### 事务规范
-
-| 编号 | 违规类型 | 说明 |
-|------|----------|------|
-| T1 | afterCommit 未被排空 | Controller 用 `@Transactional()` 但调用链中存在 `txEvents.afterCommit()` 回调（应改用 `@TransactionalWithAfterCommit()`） |
-| T2 | Service 违规传播类型 | Service 使用 `Propagation.Required` / `RequiresNew` / `Nested`（禁止 Service 自行创建事务） |
-| T3 | 直接 `prisma.$transaction()` | 绕过 `TransactionHost` 抽象，直接调用 `prisma.$transaction()` |
-| T4 | SSE/流式端点加事务装饰器 | `@Sse()` 或流式返回的方法上使用了 `@Transactional()` / `@TransactionalWithAfterCommit()`（会导致 afterCommit 提前排空） |
-| T5 | 非 HTTP 场景事务模式错误 | Subscriber/Scheduler 使用了 `@Transactional()` 装饰器而非 `txHost.withTransaction()` 或 `txEvents.withAfterCommit()` |
-| T6 | 非 HTTP 场景缺少 CLS 作用域 | Scheduler 调用 `txHost.withTransaction()` 前未用 `cls.run()` 创建 CLS 作用域 |
-
-## 审计命令
-
-**分层架构扫描（并行执行）：**
-
-```bash
-# L1 + L2 + L3：Service 注入 PrismaService
-rg "PrismaService" apps/backend/src/modules --glob '*.service.ts' -l
-
-# L2：Service 含 Repository 模式
-rg "getClient|txHost\.tx" apps/backend/src/modules --glob '*.service.ts' -l
-
-# L4：Controller 注入 Repository
-rg "Repository" apps/backend/src/modules --glob '*.controller.ts' -l
-```
-
-**事务规范扫描（并行执行）：**
-
-```bash
-# T1：找出所有只用 @Transactional() 的 Controller 方法（排除 @TransactionalWithAfterCommit）
-rg "@Transactional\(\)" apps/backend/src/modules --glob '*.controller.ts' -l
-
-# T2：Service 违规传播类型
-rg "Propagation\.(Required|RequiresNew|Nested)" apps/backend/src/modules --glob '*.service.ts' -l
-
-# T3：直接 prisma.$transaction()
-rg "prisma\.\$transaction" apps/backend/src/modules -l
-
-# T4：SSE 端点是否带事务装饰器（需人工确认上下文）
-rg "@Sse\(\)" apps/backend/src/modules --glob '*.controller.ts' -l
-
-# T5：Subscriber/Scheduler 误用 @Transactional 装饰器
-rg "@Transactional" apps/backend/src/modules --glob '*.subscriber.ts' --glob '*.task.ts' --glob '*.scheduler*.ts' -l
-
-# T6：Scheduler 使用 txHost.withTransaction 但未包 cls.run
-rg "txHost\.withTransaction" apps/backend/src/modules --glob '*.scheduler*.ts' --glob '*.task.ts' -l
-```
-
-## 执行流程
-
-1. 执行上述审计命令，收集命中文件列表
-2. **分层检查**：对每个命中文件，读取构造函数和使用处，判定违规类型：
-   - 注入了 `PrismaService` 且有 `this.prisma.*` 调用 → **L1**
-   - 注入了 `PrismaService`/`txHost` 且有 `getClient()` → **L2**
-   - 注入了 `PrismaService` 但无任何 `this.prisma.*` 调用 → **L3**
-   - Controller 文件 import/注入 Repository → **L4**
-3. **事务检查**：
-   - T1：对只用 `@Transactional()` 的 Controller，追踪其调用的 Service 方法，检查是否存在 `txEvents.afterCommit()` 调用
-   - T2：直接匹配即违规
-   - T3：直接匹配即违规
-   - T4：对 `@Sse()` 方法，检查同一方法上是否有事务装饰器
-   - T5：直接匹配即违规（Subscriber/Scheduler 不应用装饰器声明事务）
-   - T6：对命中文件，检查 `txHost.withTransaction()` 调用是否在 `cls.run()` 回调内部
-4. 输出审计报告（按模块分组，标注违规类型和行号）
-5. 仅当用户明确要求修复时，才执行修复
-
-## 修复策略
-
-### 分层架构
-
-**L1：Service 直接访问数据库**
-- 将数据库查询逻辑提取到对应 Repository（新建或复用已有）
-- Service 改为注入 Repository 调用
-
-**L2：Service 伪装为 Repository**
-- 重命名文件为 `*.repository.ts`，类名改为 `*Repository`
-- 更新所有引用（import、Module providers、注入处）
-- 确认 Service 层消费者改为注入新 Repository
-
-**L3：Service 死依赖**
-- 移除构造函数中 `PrismaService` 注入
-- 移除对应 import 语句
-- 运行 lint 确认无残留
-
-**L4：Controller 跨层调用**
-- Controller 中的 Repository 调用下沉到 Service
-- Controller 改为调用 Service 方法
-
-### 事务规范
-
-**T1：afterCommit 未被排空**
-- 将 Controller 方法的 `@Transactional()` 改为 `@TransactionalWithAfterCommit()`
-- 或确认调用链中确实不存在 `afterCommit()` 回调（则无需修改）
-
-**T2：Service 违规传播类型**
-- 改为 `Propagation.Mandatory`（必须在事务中调用）或 `Propagation.Supports`（有事务则加入）
-- 事务边界上移到 Controller 层
-
-**T3：直接 `prisma.$transaction()`**
-- 改用 `txHost.withTransaction()` 或由 Controller 层 `@Transactional()` 声明事务边界
-- Repository 内通过 `txHost.tx` 自动参与事务
-
-**T4：SSE/流式端点加事务装饰器**
-- 移除事务装饰器
-- 如需事务操作，在流式逻辑内部用 `cls.run()` + `txHost.withTransaction()` 局部处理
-
-**T5：非 HTTP 场景误用 @Transactional 装饰器**
-- Subscriber：改用 `txEvents.withAfterCommit()` 包裹处理逻辑
-- Scheduler/Task：改用 `cls.run()` + `txHost.withTransaction()`
-
-**T6：非 HTTP 场景缺少 CLS 作用域**
-- 在 `txHost.withTransaction()` 外层包裹 `cls.run()`：
-  ```typescript
-  await this.cls.run(async () => {
-    await this.txHost.withTransaction(async () => { /* ... */ })
-  })
-  ```
-
-## 排除项
-
-以下场景不视为违规：
-- `*.repository.ts` 文件中使用 `PrismaService` / `getClient()` / `txHost`（Repository 正常职责）
-- `prisma/` 目录下的基础设施文件（`prisma.service.ts` 等）
-- `common/` 目录下的事务基础设施（`TransactionEventsService`、`AfterCommitInterceptor` 等）
-- `*.spec.ts` / `e2e/` 测试文件
-- Subscriber / Scheduler 中通过 `txHost.withTransaction()` 管理事务（正确模式，但其中数据库查询仍应走 Repository）
-
-## 审计报告模板
-
-```
-## 后端分层架构与事务规范审计报告
-
-### 违规汇总
-
-**分层架构：**
-- L1（Service 直接访问 DB）：N 处
-- L2（Service 伪装 Repository）：N 处
-- L3（Service 死依赖）：N 处
-- L4（Controller 跨层调用）：N 处
-
-**事务规范：**
-- T1（afterCommit 未被排空）：N 处
-- T2（Service 违规传播类型）：N 处
-- T3（直接 prisma.$transaction）：N 处
-- T4（SSE 端点加事务装饰器）：N 处
-- T5（非 HTTP 场景误用装饰器）：N 处
-- T6（非 HTTP 缺少 CLS 作用域）：N 处
-
-### 详细列表
-
-#### [模块名]
-| 文件 | 违规类型 | 行号 | 说明 |
-|------|----------|------|------|
-| ... | L1 | 39 | `this.prisma.user.findMany()` |
-| ... | T1 | 85 | `@Transactional()` 但调用链含 `afterCommit()` |
-```

package/skills/e2e-audit-fixer/SKILL.md

@@ -1,76 +0,0 @@
----
-name: e2e-audit-fixer
-description: 对 backend 的 E2E 用例进行中文名称、通用 fixture 重复实现与测试请求构建规范检查，并按可配置路径输出修复建议与可选自动修复。适用于需要审计或修复 E2E 测试中的中文用例名、手工请求构造、手工 JWT、以及本应复用通用测试基建的重复实现。
----
-
-# E2E 测试可维护性检查与修复
-
-## 触发场景
-
-- 需要检查 `apps/backend/e2e/**/*.e2e-spec.ts` 的 E2E 用例是否符合英文命名规范。
-- 需要识别直接操作 Prisma、手工 JWT、手工 API URL、手工请求实现，并区分哪些适合改用全局通用 fixture，哪些更适合抽成本地 helper。
-- 需要一次性生成问题清单并按规则应用可控修复。
-
-## 准备
-
-执行前确认项目有可读权限，并准备以下路径参数（全部可覆盖，避免硬编码）：
-
-1. `--workspace`：代码根目录，默认当前目录。
-2. `--e2e-glob`：扫描文件模式，默认 `apps/backend/e2e/**/*.e2e-spec.ts`。
-3. `--fixtures`：fixtures 文件路径，默认 `${workspace}/apps/backend/e2e/fixtures/fixtures.ts`。
-
-## 执行流程
-
-1. 先扫描问题：
-
-```bash
-CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
-python "$CODEX_HOME/skills/e2e-audit-fixer/scripts/e2e_e2e_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo
-```
-
-2. 生成输出 JSON 用于复核：
-
-```bash
-python "$CODEX_HOME/skills/e2e-audit-fixer/scripts/e2e_e2e_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo \
-  --output-json /tmp/e2e-audit.json
-```
-
-3. 按修复策略应用：
-
-   1. 中文测试名：先翻译为英文。可直接提供翻译映射：
-
-   ```bash
-   python "$CODEX_HOME/skills/e2e-audit-fixer/scripts/e2e_e2e_audit.py" \
-     --workspace /Users/a1/work/ai-monorepo \
-     --translation-map /tmp/name-map.json \
-     --apply
-   ```
-
-   2. fixture 重复实现：自动加注释提示并给出替换建议，保留原有逻辑不变。仅 `user` / `userCredential` 作为全局通用 fixture 候选，其余默认建议抽成本地 helper。
-
-4. 必要时清理：对比扫描结果再次运行，确保无回归。
-
-## 检查规则（脚本输出）
-
-- `e2e-chinese`：`describe/it/test/context` 名称包含中文字符。
-- `e2e-fixtures`：检测 `prisma.user.*`、`prisma.userCredential.*`、`jwtService.sign/jwt.sign`、未使用 `buildApiUrl()` 的 API URL 片段、未使用 `createAuthRequest/createAdminAuthRequest/createPublicRequest` 的手工请求调用。
-- `e2e-local-helper`：检测其他 `prisma.*.create*` / `upsert` 类重复实现，默认只建议在当前测试文件内抽成本地 helper，不建议直接上收为全局 fixtures。
-
-## 可选翻译入口
-
-支持三种方式之一：
-
-1. `--translation-map`：JSON 映射文件 `{ "中文原文": "English text" }`（推荐，稳定、可审计）。
-2. `--translate-service openai`：提供 `OPENAI_API_KEY` 后自动调用 OpenAI 批量翻译。
-3. 不提供翻译参数：仅输出中文字符串与建议，不改写文件。
-
-## 注意
-
-- 扫描不改变业务逻辑，只做问题检测与可控注释插入。
-- 自动修复默认只对中文测试名称做真实替换。
-- `user` / `userCredential` 以外的重复造数默认视为“本地 helper 候选”，不默认建议进入全局 fixtures。
-- fixture 与请求构造类问题仅插入 TODO 注释，不宣称已完成重构。
-- 翻译服务仅处理测试名称，不处理其他文本。
-- 扫描路径来源全部来自参数，不会固定死为 `apps/backend/e2e/**/*.e2e-spec.ts`。

package/skills/e2e-audit-fixer/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "E2E Audit Fixer"
-  short_description: "扫描 E2E 测试中文名称、手工请求与重复实现，并输出可控修复建议"
-  default_prompt: "使用 $e2e-audit-fixer 对 E2E 测试进行 e2e-chinese 与 e2e-fixtures 检查，并按修复建议输出可执行改动。"

package/skills/env-accessor-audit-fixer/SKILL.md

@@ -1,149 +0,0 @@
----
-name: env-accessor-audit-fixer
-description: Use when backend、NestJS、配置模块、E2E 测试或脚本中需要审计或修复 `process.env` 直读，判断项目是否已具备统一环境访问基础设施，并在缺少 EnvAccessor、EnvService、EnvModule 或统一配置接入时补齐最小可用实现。
----
-
-# 环境变量访问审计与修复
-
-## 概览
-
-先扫描 `process.env` 直读点，再判断仓库是否已有统一 env 访问基础设施。
-
-- 若已有 `EnvService`、`createEnvAccessor`、`defaultEnvAccessor` 或等价封装，优先复用现有方案并逐项迁移。
-- 若缺少统一入口，先补齐最小基础设施，再收口剩余直读点。
-
-## 快速开始
-
-先运行扫描脚本：
-
-```bash
-CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
-python "$CODEX_HOME/skills/env-accessor-audit-fixer/scripts/env_accessor_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo
-```
-
-需要结构化结果时输出 JSON：
-
-```bash
-python "$CODEX_HOME/skills/env-accessor-audit-fixer/scripts/env_accessor_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo \
-  --output-json /tmp/env-accessor-audit.json
-```
-
-若脚本显示尚未形成统一 env 入口，再读取 [references/bootstrap-env-foundation.md](./references/bootstrap-env-foundation.md)。
-
-## 执行流程
-
-1. 扫描 `apps/backend/src` 与 `apps/backend/e2e` 中的 `process.env`。
-2. 仅排除真正的基础封装文件：
-   - `env.accessor.ts`
-   - `env.service.ts`
-3. 不排除 `apps/backend/src/config/**/*.ts`，确保 `registerAs` 配置层也纳入审计。
-4. 优先识别当前基础设施状态：
-   - 是否存在 `createEnvAccessor`
-   - 是否存在 `defaultEnvAccessor`
-   - 是否存在 `EnvService`
-   - 是否存在 `EnvModule`
-   - 是否已有 `registerAs` 或配置层通过统一 env 入口读取变量
-5. 按场景为每个直读点选择迁移方式，而不是机械替换。
-6. 修复后重新扫描，并补跑最小验证，确认配置读取与运行行为一致。
-
-## 快速复核命令
-
-项目具备 `rg` 时，优先用下列命令复核：
-
-```bash
-rg "process\\.env" apps/backend/src apps/backend/e2e \
-  --glob '!*env.accessor.ts' \
-  --glob '!*env.service.ts'
-```
-
-## 修复准则
-
-### 配置层与 `registerAs`
-
-- 优先使用 `defaultEnvAccessor`
-- 仅在必须显式传入环境对象时使用 `createEnvAccessor(process.env)`
-- 不要继续裸读 `process.env.FOO`
-
-```typescript
-import { registerAs } from '@nestjs/config'
-import { defaultEnvAccessor } from '@/common/env/env.accessor'
-
-const env = defaultEnvAccessor
-
-export const redisConfig = registerAs('redis', () => ({
-  host: env.str('REDIS_HOST', 'localhost'),
-}))
-```
-
-### 运行期服务、控制器、提供者
-
-- 注入 `EnvService`
-- 优先使用 `getString`、`getInt`、`getBoolean`、`isProd`、`isE2E` 等 typed getter
-- 若模块尚未暴露 `EnvModule`，先补模块依赖，再迁移读取逻辑
-
-```typescript
-@Injectable()
-export class ExampleService {
-  constructor(private readonly env: EnvService) {}
-
-  getRedisHost() {
-    return this.env.getString('REDIS_HOST', 'localhost')
-  }
-}
-```
-
-### 独立脚本与 CLI
-
-- 在完成 dotenv 装载后显式创建 accessor
-
-```typescript
-const env = createEnvAccessor(process.env)
-```
-
-### 必须读取原始值
-
-- 使用 `EnvService.getAccessor().raw(key)`，或 accessor 的 `raw(key)`
-- 在代码中简短说明为何 typed getter 不适用
-
-## 缺失基础设施时的补齐顺序
-
-若扫描结果显示项目尚未形成统一 env 访问方案，按以下顺序补齐：
-
-1. 创建 `env.accessor.ts`
-   - 提供 `createEnvAccessor`
-   - 提供 `defaultEnvAccessor`
-   - 至少支持 `str`、`bool`、`int`、`num`、`raw`、`appEnv`、`snapshot`
-2. 创建 `env.service.ts`
-   - 包装 `ConfigService`
-   - 提供 typed getter 与常用环境判断方法
-3. 创建 `env.module.ts`
-   - 暴露 `EnvService`
-4. 将配置层迁移到 `registerAs + defaultEnvAccessor`
-5. 将运行期服务迁移到 `EnvService`
-6. 重新扫描剩余 `process.env` 直读点
-
-优先复用现有命名、目录与模块结构；若无统一基础设施，再参考 [references/bootstrap-env-foundation.md](./references/bootstrap-env-foundation.md)。
-
-## 例外与判断原则
-
-- `env.accessor.ts`、`env.service.ts` 本身允许访问 `process.env`
-- 负责 dotenv 装载、环境注入、测试环境临时覆写的底层入口可保留少量受控访问
-- 测试里对 `process.env` 的显式设值可视为受控例外，但优先复用公共 fixture 或 helper
-- 若某文件同时负责“装载环境”和“消费环境”，优先拆分职责，避免例外扩大
-
-## 输出要求
-
-最终输出至少包含：
-
-1. 基础设施状态
-2. `process.env` 直读文件清单
-3. 每个问题的推荐迁移方式
-4. 是否需要补齐基础设施
-5. 已修改内容、验证结果与剩余风险
-
-## 资源
-
-- 扫描脚本：`scripts/env_accessor_audit.py`
-- 补齐模板：`references/bootstrap-env-foundation.md`

package/skills/env-accessor-audit-fixer/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "环境变量审计修复"
-  short_description: "审计并修复 process.env 直读，必要时补齐统一 env 访问基础设施"
-  default_prompt: "使用 $env-accessor-audit-fixer 扫描项目中的 process.env 直读，判断是否已具备统一 env 访问基础设施，并给出或实施修复方案。"
-
-policy:
-  allow_implicit_invocation: true

package/skills/error-handling-audit-fixer/SKILL.md

@@ -1,187 +0,0 @@
----
-name: error-handling-audit-fixer
-description: Use when backend、NestJS、领域异常治理或错误处理审查中，需要检查业务代码是否绕过 DomainException / ErrorCode 体系，区分生产代码与 E2E 测试中的异常写法，识别直接抛出 BadRequestException、HttpException、Error 或直接返回中文 DomainException，并在项目缺少统一异常基础设施时给出补齐路径。
----
-
-# 错误处理规范检查与修复建议
-
-## 概览
-
-先判断项目是否已经具备统一错误处理基础设施，再扫描业务代码是否绕过 `DomainException` / `ErrorCode` 体系。默认只输出审计结果和修复建议，不自动改代码；只有用户明确要求时才进入自动修复。
-
-## 扫描范围
-
-脚本不预设任何项目路径，需要通过 `--src-dir` / `--e2e-dir` 显式传入。执行前必须先完成项目探索（见下方步骤 0）。
-
-以下路径/后缀始终排除，不会产生误报：
-
-| 排除类别 | 路径/后缀 |
-|----------|-----------|
-| 单元测试 | `*.spec.ts`、`*.test.ts`、`*.e2e-spec.ts` |
-| 测试辅助 | `*.mock.ts`、`*.stub.ts`、`*.fixture.ts`、`fixtures/`、`test-utils/`、`testing/`、`__tests__/`、`__test__/` |
-| 基础设施 | `*/filters/`、`prisma/`、`scripts/` |
-| 异常定义 | `*.exception.ts` |
-| 入口文件 | `main.ts` |
-
-只有在用户**明确要求**评估测试债务时，才传 `--e2e-dir` + `--scope e2e` 扫描测试代码。
-
-## 快速开始
-
-### 步骤 0：项目探索（每个项目首次执行时必须完成）
-
-在调用脚本前，先探索项目结构，识别出后端生产代码和测试代码的实际路径。方法：
-
-1. 查看项目根目录结构（`ls` 或 Glob）
-2. 识别后端应用目录（可能是 `apps/backend/src`、`src`、`server/src` 等）
-3. 识别测试目录（可能是 `apps/backend/e2e`、`test`、`e2e`、`__tests__` 等）
-4. 如果是 monorepo，可能有多个后端服务，每个都需要单独传 `--src-dir`
-
-典型示例：
-
-| 项目类型 | 生产代码 | 测试代码 |
-|----------|----------|----------|
-| NestJS monorepo | `apps/backend/src` | `apps/backend/e2e` |
-| 单体 NestJS | `src` | `test` 或 `e2e` |
-| 多服务 monorepo | `apps/api/src`、`apps/worker/src` | `apps/api/e2e`、`apps/worker/e2e` |
-
-### 步骤 1：审计生产代码
-
-将探索到的路径传给脚本（`--src-dir` 可传多个）：
-
-```bash
-SKILL_HOME="${SKILL_HOME:-$HOME/.claude/skills}"
-python "$SKILL_HOME/error-handling-audit-fixer/scripts/error_handling_audit.py" \
-  --workspace "$PWD" \
-  --src-dir <探索到的生产代码路径>
-```
-
-示例（当前项目）：
-
-```bash
-python "$SKILL_HOME/error-handling-audit-fixer/scripts/error_handling_audit.py" \
-  --workspace "$PWD" \
-  --src-dir apps/backend/src
-```
-
-多服务示例：
-
-```bash
-python "$SKILL_HOME/error-handling-audit-fixer/scripts/error_handling_audit.py" \
-  --workspace "$PWD" \
-  --src-dir apps/api/src \
-  --src-dir apps/worker/src
-```
-
-### 步骤 2：（仅在用户明确要求时）审计测试代码
-
-```bash
-python "$SKILL_HOME/error-handling-audit-fixer/scripts/error_handling_audit.py" \
-  --workspace "$PWD" \
-  --e2e-dir <探索到的测试代码路径> \
-  --scope e2e \
-  --output-json /tmp/error-handling-audit.json
-```
-
-3. 当项目尚未具备 `DomainException` / `ErrorCode` / 领域异常目录等基础设施时，先阅读 [references/foundation-bootstrap.md](./references/foundation-bootstrap.md) 再决定是否补齐。
-
-4. 当项目基础设施齐全但出现违规抛错时，按 [references/error-handling-standard.md](./references/error-handling-standard.md) 给出替换建议；如用户明确要求，才实施自动修复。
-
-5. 当结果里 `e2e/raw-error` 数量很大时，不要直接把它和生产代码风险混在一起汇报；先给 `src` 结论，再决定是否单独治理 `e2e`。
-
-## 执行流程
-
-1. 默认只扫描 `apps/backend/src`（生产代码）。测试代码、E2E、prisma seed、脚本等非生产路径全部排除。只有在用户明确要求评估测试债务时，才传 `--scope e2e` 扫描测试代码。
-2. 先判断基础设施状态：
-   - 是否存在 `DomainException`
-   - 是否存在 `ErrorCode`
-   - 是否存在领域异常目录或模块异常类
-   - 是否存在全局异常过滤器或结构化错误输出链路
-3. 再识别四类问题：
-   - 直接实例化 Nest 标准异常，如 `BadRequestException`、`HttpException`
-   - `throw new Error(...)` 或 `Promise.reject(new Error(...))`
-   - 直接 `new DomainException(...)` 但 payload 中未显式带 `code`
-   - `DomainException` 直接返回中文 message
-4. 对每个命中项给出修复建议，优先级固定如下：
-   - 优先复用现有模块异常类
-   - 其次建议在模块 `exceptions/` 目录新增领域异常类
-   - 最后才允许直接使用 `DomainException`，且必须补齐 `code` 与 `args`
-5. 若基础设施缺失，不直接把全部命中项定性为“应立刻改业务代码”，而是先输出“需补齐基础设施”的诊断与最小落地路径。
-6. 只有在用户明确说“自动修复”“直接改”或等价表述时，才进入落代码阶段。
-7. 若脚本结果与实际代码不一致，必须抽样打开命中文件复核，不要把脚本结果当成绝对真相。
-
-## 审计命令（rg 快速复核）
-
-以下 rg 命令用于手工复核，将 `<SRC_DIR>` 替换为步骤 0 探索到的实际路径：
-
-```bash
-rg "new (BadRequestException|UnauthorizedException|ForbiddenException|NotFoundException|HttpException|InternalServerErrorException)\(" \
-  <SRC_DIR> \
-  --glob '!*spec.ts' --glob '!*test.ts' \
-  --glob '!*exception.ts' \
-  --glob '!*/filters/**' \
-  --glob '!*main.ts'
-```
-
-```bash
-rg "new Error\(" <SRC_DIR> --glob '!*spec.ts' --glob '!*test.ts'
-```
-
-```bash
-rg "new DomainException\([^)]*$" -A3 <SRC_DIR>
-```
-
-```bash
-rg "DomainException\([^)]*[\u4e00-\u9fa5]" <SRC_DIR> \
-  --glob '!*spec.ts' \
-  --glob '!*/common/exceptions/**'
-```
-
-## 修复准则
-
-### 1. 优先复用现有领域异常
-
-- 若模块 `exceptions/` 已有语义匹配的异常类，直接复用。
-- 不要把已可表达为领域异常的问题继续保留成裸 `BadRequestException('字符串')`。
-
-### 2. 缺少模块异常时新增领域异常类
-
-- 在模块 `exceptions/` 下新增异常类。
-- 异常类继承统一 `DomainException`。
-- 构造函数中显式指定 `ErrorCode`。
-- 把上下文放进 `args`，不要把业务文案直接写死到 message。
-- 为新增异常补最小单测。
-
-### 3. 临时直接使用 DomainException
-
-- 仅在尚未抽出专用异常类、但当前修复必须继续推进时使用。
-- payload 中必须显式包含 `code`。
-- `args` 中必须保留排障所需上下文。
-
-### 4. 基础设施缺失时的判断
-
-- 如果仓库里根本没有 `DomainException` 或 `ErrorCode`，优先建议补基础设施，不要直接发散式新增几十个本地异常实现。
-- 如果已有 `DomainException` 但没有统一 `ErrorCode`，先统一错误码来源，再扩展模块异常。
-- 如果已有异常类与错误码，但缺少结构化输出链路，优先补过滤器或输出映射，保证 `code`、`args`、`requestId` 可稳定透出。
-
-## 输出要求
-
-执行这个技能时，最终输出至少包含：
-
-1. 基础设施状态
-2. 命中文件清单
-3. 每个问题的类型、定位与建议替换方式
-4. 是否可复用现有领域异常
-5. 是否需要先补齐基础设施
-6. 若用户要求自动修复，列出拟修改文件、验证方式与剩余风险
-
-补充要求：
-
-7. 明确区分 `src` 与 `e2e` 命中数量，避免测试噪音淹没生产代码风险
-8. 标注哪些命中是脚本结果、哪些已经过源码抽样复核
-9. 若脚本疑似误报，要在结论里明确说明“脚本规则限制”而不是直接要求改代码
-
-## 资源
-
-- 扫描脚本：`scripts/error_handling_audit.py`
-- 规范参考：`references/error-handling-standard.md`
-- 基础设施补齐指南：`references/foundation-bootstrap.md`

package/skills/error-handling-audit-fixer/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "错误处理规范检查"
-  short_description: "按 src 与 e2e 分开审计后端异常是否绕过 DomainException 与 ErrorCode 体系"
-  default_prompt: "使用 $error-handling-audit-fixer 先审计 backend src，再按需审计 e2e，检查错误处理是否绕过 DomainException / ErrorCode 体系，并在基础设施缺失时给出补齐建议。"
-
-policy:
-  allow_implicit_invocation: true