demock

使用随附脚本，在真实代码路径上查找测试替身、被吞掉的失败或占位实现；逐一阅读，并提出应使用的真实依赖或如实报告失败的方案，然后再进行任何修复。

目标

真实代码路径会运行它声称要运行的内容：成功意味着工作确实完成，失败则会连同原因一起显现。范围由人指定：文件、目录、差异，或刚刚进行的更改。运行过程绝不自行选择目标。

运行会报告每项发现的位置、证明其可从真实路径到达的证据、类别和建议；然后针对人批准的每一项，报告最先失败的测试和修复方案。如果范围内没有发现，运行不会更改任何内容，并会明确说明。

工作流

1. 先区分真实路径和测试路径。 根据测试目录、文件命名规则和测试配置，了解仓库的测试惯例。真实路径是从入口点（构建产物、导出项、处理程序、CLI）可到达的代码：沿着导入和调用追踪，包括依赖注入或注册表实际接入的内容。没有代码能到达的代码属于死代码，不是这里要报告的发现；将其留待清理工作处理。
2. 列出候选项。 在此技能的文件夹中运行 node scripts/scan.mjs <paths...> [--test-glob <glob>]... [--json] 扫描指定范围；如果仓库惯例所用的测试路径命名超出默认规则，为每种此类路径添加一个 --test-glob。该脚本会打印测试路径之外的每个候选项，包含文件、行号、类型和证据文本；--json 会打印一个 JSON 对象。退出码：0 表示没有候选项，3 表示存在候选项，2 表示用法错误。退出码为 2 表示运行有误：修正命令并重新运行。名称匹配只是线索，绝非定论。
3. 加入仓库自身的 linter 规则。 如果仓库已有包含吞掉失败规则的 linter（ruff BLE、S110 和 S112、ESLint no-empty、Go errcheck），通过仓库自身的脚本或本地安装的二进制，按仓库声明的版本运行这些规则，并将其命中项加入候选项。不要安装新工具。
4. 阅读并分类每个候选项。 (a) 类是在真实路径上的测试替身。(b) 类是假成功：将失败转成成功的 catch（无论是否记录日志）；调用方无法将其与真实结果区分的回退方案；或针对访问、支出、删除或计数信号的门控，在检查的密钥、依赖或输入缺失时仍让请求通过。(c) 类是占位实现：真实路径可到达的未完成实现。(d) 类是有意设计的：运行时会选择真实实现的接缝；调用方可感知（有类型的空结果、标志、文档说明的状态）且设计上能够处理的降级；真实路径上默认关闭、且有文档说明的离线模式；或生产构建会排除的代码。保留 (d) 类并附上证据。如果无法确认候选项能否从真实路径到达，仍须给出其类别和建议，并标记为未经验证。
5. 为每个 (a)、(b) 和 (c) 类候选项提出修复方案：应运行的真实依赖，或能显露原因的如实失败；对于让请求通过的门控，如实失败就是拒绝请求。绝不要建议用另一个假实现替换现有实现。
6. 停止并报告。 报告发现及其建议，包括脚本漏掉的任何模式，然后结束本次运行。人通过指定要修复的项目予以批准；其他内容一律不变。
7. 每次只修复一个已批准的项目。 先编写一个在假实现上会失败的测试，证明真实路径会运行或失败会显露；然后修复该项目并重新运行仓库的检查。

规则

• 范围以人类指定的内容为准。绝不扩大范围，也不自行选择目标。
• 候选模式和默认测试约定由脚本负责；若脚本漏掉某种模式，应将其作为脚本变更提议，并附带测试，按照与修复相同的审批流程处理。
• 测试中的测试替身不作处理。
• 在边界处记录日志后重新抛出异常，属于如实报告失败，应予保留。
• 修复必须用真实依赖或如实报告的失败替代伪造实现，绝不能换成另一种伪造实现。
• 未经人类批准，不得进行任何修复；每项修复都必须有一个先前失败的测试。
• 未发现问题的运行不得造成任何变更。
• 测试替身的术语遵循 Gerard Meszaros 的测试替身分类法（dummy、stub、spy、mock、fake）以及 Martin Fowler 的「Mocks Aren't Stubs」。

验证

完成前，请确认：

1. 每项发现都注明了位置、能到达真实路径的证据或未验证标记、类别和提议。
2. 未经人类批准，没有更改任何文件。
3. 每项已应用的修复都有一个先前失败的测试。
4. 脚本发生变更时，其测试通过指向技能文件夹的 junction 或符号链接调用 CLI，并且测试通过。