Menu
模块实现执行器。根据输入材料类型自动选择工作模式——全量优雅实现（A）、 最小化修复迭代（B）、增量更新或冲突修正（C）。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
盲测执行与失败分类中枢（v2.0.0）。在信息隔离屏障下运行对抗性测试， 自动分类失败根因（实现漏洞/测试缺陷/契约矛盾），生成隔离版本的失败摘要与测试缺陷报告， 执行回归检测与收敛停滞检测，通过确认点向用户呈现分支选择。 当需要运行对抗性测试、分类测试失败、生成隔离摘要或判定修复方向时使用本 Skill。
对抗性模块实现流水线入口——环境就绪与契约冻结。 负责环境检查、强化契约提取（含模糊边界显式仲裁）、契约冻结、 执行计划预览与用户确认。支持 core / recontract / contract-update / from-reverse 四种模式。
差异仲裁器。三模式 Skill：模式 A（设计变更差异分析）——对比当前设计文档与已冻结的 contract-expectations.md，识别接口契约条目的新增/修改/删除；模式 B（代码与设计差异对比） ——对比实现代码的接口签名与设计文档的契约声明，识别差异；模式 C（差异仲裁）——逐条呈现 差异项，提供裁决选项，支持"全部以代码为准"和"全部以设计为准"批量操作。 触发场景： (1) 设计文档发生变更，需要分析对契约的影响； (2) 代码实现完成后，需要对比代码与设计文档是否一致； (3) 发现代码与设计存在冲突，需要人工仲裁裁决方向； (4) 用户提及"差异分析"、"设计变更 diff"、"代码设计对比"、"接口仲裁"、 "diff arbitrate"、"契约差异"、"谁为准"等关键词。 核心特征：自动差异检测（模式 A/B）→ 人工裁决（模式 C）。模式 C 在逐条呈现差异时 提供三个裁决方向，并支持批量快捷操作。
存量制品检测器（轻量版）。纯文件系统扫描，检测指定模块的四类存量制品—— 设计文档、实现代码、测试代码、契约文件——并输出结构化 JSON 报告。 本 Skill 不做任何 AI 推理，全部检测逻辑由确定性扫描脚本完成。 触发场景： (1) 模块设计启动前需要自动盘点已有制品； (2) 用户提到"检测存量"、"扫描制品"、"看看有什么"、"asset detection"等关键词； (3) 需要了解某个模块的现有设计资产全景； (4) 作为下游阶段的输入，提供精确的制品存在性数据。
模块实现执行器。根据输入材料类型自动选择工作模式——全量优雅实现（A）、 最小化修复迭代（B）、增量更新或冲突修正（C）。 由工作流编排器调度使用。
验证模块实现产物的格式合规性与风险可控性。运行函数签名校验脚本， 读取并评估待确认事项中的风险条目等级，存在重大风险时条件性请求用户确认。 使用场景：模块实现落地完成后的质量门控；实现输出验证；签名格式校验；实现风险审核。 当用户要求"验证实现"、"检查实现输出"、"审核实现风险"、"确认函数签名"、"审查 pending-confirmations"时使用本 Skill。
| name | impl-executor |
| description | 模块实现执行器。根据输入材料类型自动选择工作模式——全量优雅实现（A）、 最小化修复迭代（B）、增量更新或冲突修正（C）。 |
本 Skill 负责模块的实现落地、修复迭代、增量更新与冲突修正。进入时自动检测输入材料类型，切换到对应模式执行。
进入时扫描输入材料，按以下优先级判定模式：
| 检测条件 | 判定模式 | 说明 |
|---|---|---|
存在 contract-expectations.md + 完整设计文档（落地规范、设计文档、项目结构文档） | 模式 A — 全量优雅实现 | 首次实现或完整重写 |
存在 failure-summary-round-N.md（信息隔离版本，文件头含 ## 失败摘要（第 N 轮） 或等价位标记） | 模式 B — 最小化修复迭代 | 测试反馈循环 |
存在增量契约变更报告（文件头含 ## 增量契约变更 或类似标记，描述局部变更而非完整契约） | 模式 C — 增量更新（incremental_update 路径） | 局部需求变更 |
存在仲裁执行记录（文件头含 ## 仲裁执行记录 或类似标记，列出冲突项与修正方向） | 模式 C — 冲突修正（code_design_conflict 路径） | 设计与代码不一致裁决 |
若无法判定，读取各候选文件的前若干行确认其内容格式，按最佳匹配选择。无法匹配任何模式时上报 ERROR。
不运行测试：本 Skill 不执行任何测试代码。测试由下游盲测阶段统一执行。
信息隔离：
tests/、test/、__tests__/、spec/、__spec__/ 及项目文档标注的测试目录。禁止 grep、read、glob 等任何操作触及这些路径。failure-summary-round-N.md（信息隔离版本），禁止读取测试目录下的任何文件。契约权威：实现代码严格按落地规范编写，不根据想象中的测试来调整实现。
增量优先：优先修改现有代码以适配新需求，仅在现有文件职责不符或不存在时新建。禁止为"统一风格"而大面积重写未涉及的现有代码。
不向用户提问：本 Skill 的业务策略是自主裁决并记录。所有需要用户裁决的事项按保守假设处理，以"待确认事项"形式记录到 pending-confirmations.md，由下游审查阶段决定是否与用户交互。
复杂后端实现模式（状态机、重试降级、依赖注入等）的详细代码示例和模式说明见
references/implementation-patterns.md。前端模块或简单 CRUD 可跳过。
代码按以下顺序生长：类型系统 → 数据契约层 → 工具代码 → 原子功能单元 → 状态机 → 组合层 → 异常处理 → 依赖适配。
| 依赖类型 | 处理方式 |
|---|---|
| 关键基础设施依赖（数据库、日志、外部 API 等） | 必须真实实现，不可用 mock 替代 |
| 核心功能依赖（其他业务模块的接口） | 若未落地，提取接口定义生成 mock/stub，在待确认事项中标注 |
| 禁止项 | 原因 |
|---|---|
| 上帝函数/组件 | 职责不清，难以测试和维护 |
| 全局变量通信 | 引入隐式耦合 |
| 跳过输入校验 | 盲测的首要目标就是发现校验缺失 |
| 静默吞异常 | 掩盖错误，导致调试困难 |
| 无必要地重写现有代码 | 破坏增量优先原则 |
输入：落地规范、设计文档、项目结构设计文档、contract-expectations.md
产出：实现代码、function-signatures.json、pending-confirmations.md
每模块由三份文档组成：落地规范（编码主要来源）、设计文档（项目上下文）、项目结构设计文档（代码组织规范）。
开始编码前必须定位并解析项目结构设计文档，提取：目录结构规范、模块边界、命名规范、技术栈约束、共享资源位置。
若找不到项目结构设计文档：
docs/ 目录下包含"项目结构"、"目录结构"、"structure"等关键词的文件契约信息已由上游提取到
contract-expectations.md，直接读取即可。
| 优先级 | 文档 | 约束范围 |
|---|---|---|
| P0 | 项目结构设计文档 | 目录结构、模块边界、命名规范 |
| P1 | 落地规范 | 类型定义、逻辑步骤、状态机、异常策略 |
| P2 | 设计文档 | 业务意图、上下文说明 |
目标：识别可复用的现有代码，为"增量优先"提供依据。
输出：文件路径 → 已实现项 → 差异，标注增量潜力。排除测试目录。若文档标注"全新模块"，跳过此步骤。
| 差异类型 | 处理方式 |
|---|---|
| 缺失实现 | 直接实现 |
| 字段/类型冲突 | 待确认事项记录，按保守假设处理 |
| 已有逻辑冲突 | 待确认事项记录，按保守假设处理 |
| 技术栈冲突 | 待确认事项记录 |
| 设计文档冲突 | 按 P0→P1→P2 优先级仲裁，待确认事项记录 |
| 设计未覆盖 | 待确认事项记录，采用最宽松假设 |
按实现顺序编写代码，遵循增量优先原则：优先修改现有文件，仅在职责不符或不存在时新建。遵守代码组织铁律和质量要求。
提取所有公开函数/方法的签名，生成 JSON 文件：
{
"module_id": "模块编号（如 M01）",
"module_name": "模块名称",
"functions": [
{
"name": "func_name",
"signature": "def func_name(param_a: int, param_b: str = \"\") -> ResultType",
"parameters": [
{"name": "param_a", "type": "int", "required": true},
{"name": "param_b", "type": "str", "required": false, "default": "\"\""}
],
"return_type": "ResultType",
"exceptions": ["ValueError", "TimeoutError"]
}
]
}
存放路径：{module_code_dir}/.tmp/adversarial-tests/{module_id}/function-signatures.json
格式见「待确认事项处理」章节。即使为空也必须生成该文件。
function-signatures.json 文件路径pending-confirmations.md 文件路径输入：failure-summary-round-N.md（信息隔离版本）、当前实现代码、落地规范
产出：修改后代码、修改说明、pending-confirmations-round-N.md
failure-summary-round-N.md，信息隔离版本，不包含测试代码片段）失败摘要格式：
#### [case-001] TypeError: 参数收到非期望类型
- **涉及函数**：`calculate_limit`
- **涉及参数**：`limit`（类型：int (≥1)）
- **契约条款**：§3.2
- **失败原因**：参数收到 None，函数未进行类型校验
- **修复建议**：在函数入口处添加参数非空和类型校验
按失败摘要中的 case ID 排序，优先处理影响用例数多的问题。
| 失败原因 | 修复动作 |
|---|---|
| 参数未校验 | 添加输入校验（类型检查、非空检查） |
| 边界未处理 | 添加边界检查（范围、长度） |
| 空值未防护 | 添加 None/空值分支 |
| 异常未抛出 | 添加异常抛出（按契约要求的异常类型） |
| 状态未检查 | 添加前置条件/状态检查 |
| 返回值错误 | 修正返回值（按契约要求的返回类型/值） |
## 修复说明（第 {N} 轮）
### case-001
- **修复文件**：`src/services/calculator.py`
- **修复内容**：在 `calculate_limit` 函数入口处添加参数校验
```python
if limit is None:
raise TypeError("limit must be int, got None")
3. `pending-confirmations-round-N.md` 文件路径
---
## 模式 C：增量更新/冲突修正
### C.1 路径判定
进入模式 C 后，按输入材料类型判定子路径：
| 输入材料标记 | 子路径 |
|:---|:---|
| 增量契约变更报告（描述局部契约变更，非完整 `contract-expectations.md`） | `incremental_update` |
| 仲裁执行记录（列出代码与设计文档的冲突项及修正方向） | `code_design_conflict` |
---
### C.2 子路径：增量实现更新（incremental_update）
输入：增量契约变更报告、当前实现代码
产出：修改后代码、修改说明、`pending-confirmations-round-N.md`
#### C.2.1 解析增量变更
增量契约变更报告描述局部契约变更，格式示例：
```markdown
## 增量契约变更（第 {N} 轮）
### 变更项 1：新增字段
- **涉及结构**：`UserProfile`
- **变更内容**：新增 `avatar_url: str | None` 字段
- **默认行为**：None（向后兼容）
### 变更项 2：修改校验规则
- **涉及函数**：`validate_email`
- **原规则**：仅检查 @ 符号存在
- **新规则**：检查 @ 符号 + 域名有效性
- **向后兼容**：是（旧有效输入仍然有效）
遵循增量优先原则：
## 增量更新说明（第 {N} 轮）
### 变更项 1：新增 avatar_url 字段
- **修改文件**：`src/models/user.py`
- **修改内容**：在 `UserProfile` 中新增 `avatar_url: str | None = None`
- **影响范围**：仅 UserProfile 定义，无下游影响
### 变更项 2：修正 validate_email 校验
- **修改文件**：`src/validators/email.py`
- **修改内容**：扩展正则校验规则，新增域名有效性检查
- **影响范围**：`validate_email` 函数，返回值类型不变
pending-confirmations-round-N.md 文件路径输入：仲裁执行记录、当前实现代码、设计文档
产出：修改后代码/设计文档、修改说明、pending-confirmations-round-N.md、更新后的仲裁执行记录
仲裁执行记录列出代码与设计文档不一致的冲突项，每条含修正方向：
## 仲裁执行记录
### 冲突项 1：函数返回值类型不一致
- **涉及文件**：`src/services/payment.py`（代码）、`docs/design/payment-module.md`（设计）
- **冲突描述**：代码返回 `PaymentResult`，设计文档要求返回 `dict`
- **修正方向**：以代码为准 — 更新设计文档
### 冲突项 2：缺少边界校验
- **涉及文件**：`src/models/order.py`（代码）、`docs/specs/order-spec.md`（设计）
- **冲突描述**：代码未校验 `quantity > 0`，设计文档明确要求 `quantity >= 1`
- **修正方向**：以设计为准 — 修改实现代码
### 冲突项 3：接口命名与参数列表均不一致
- **涉及文件**：`src/api/user_api.py`（代码）、`docs/specs/user-spec.md`（设计）
- **冲突描述**：函数名不同（`get_user` vs `fetch_user`）、参数不同（缺 `include_deleted`）
- **修正方向**：混合 — 函数名以代码为准更新设计文档，参数以设计为准修改代码
按冲突项编号顺序执行。每条冲突项的修正方向有三种：
| 修正方向 | 行为 | 操作 |
|---|---|---|
| 以代码为准 | 设计文档向代码靠拢 | 修改设计文档，使其与当前代码行为一致。在修改说明中注明"设计文档已更新以反映代码实际行为"。 |
| 以设计为准 | 代码向设计文档靠拢 | 修改实现代码，使其符合设计文档要求。遵循增量优先原则——优先修改现有文件。 |
| 混合 | 分别执行 | 将冲突项拆分为以代码为准和以设计为准的子项，分别按上述规则执行。 |
在原始仲裁执行记录基础上，为每条冲突项追加执行结果：
### 冲突项 1：函数返回值类型不一致
- **修正方向**：以代码为准 — 更新设计文档
- **执行结果**：✅ 已完成
- **执行详情**：将 `docs/design/payment-module.md` 中 `calc_payment()` 的返回值类型从 `dict` 改为 `PaymentResult`
## 冲突修正说明（第 {N} 轮）
### 冲突项 1：函数返回值类型不一致（以代码为准）
- **修改文件**：`docs/design/payment-module.md`
- **修改内容**：将 `calc_payment()` 返回值类型从 `dict` 改为 `PaymentResult`
- **原因**：代码已实现 `PaymentResult` 类型，设计文档落后于实现
### 冲突项 2：缺少边界校验（以设计为准）
- **修改文件**：`src/models/order.py`
- **修改内容**：在 `__init__` 中新增 `if quantity < 1: raise ValueError(...)`
- **原因**：设计文档明确要求 `quantity >= 1`，代码缺少校验
pending-confirmations-round-N.md 文件路径所有需要裁决但本 Skill 不打断流程确认的事项，按保守假设处理，记录到待确认事项文件。
| 情形 | 策略 |
|---|---|
| 与现有代码冲突 | 优先修改现有文件以适配新需求（保持向后兼容），仅在会破坏现有接口契约时新建 |
| 无法判断缺失或冲突 | 按缺失实现处理（新建），保留现有代码不变，记录为"疑似冲突，待确认" |
| 设计文档间冲突 | 按 P0→P1→P2 优先级仲裁 |
| 增量更新与现有代码冲突无法最小解决 | 记录冲突详情，暂不修改，标记为"需人工裁决" |
存放路径：
{module_code_dir}/.tmp/adversarial-tests/{module_id}/pending-confirmations.md{module_code_dir}/.tmp/adversarial-tests/{module_id}/pending-confirmations-round-N.md{module_code_dir}/.tmp/adversarial-tests/{module_id}/pending-confirmations-round-N.md## 待确认事项（已按保守假设处理）
### 事项 1：与现有代码冲突
- **涉及文件**：`src/existing.py`
- **冲突描述**：已有字段 `status` 为 `str` 类型，落地规范要求 `StatusEnum`
- **采取策略**：保持现有 `str` 类型，新增 `StatusEnum` 用于新接口
- **风险**：新旧接口混用可能导致类型不一致
### 事项 2：无法判断缺失或冲突
- **涉及文件**：`src/utils.py`
- **描述**：`validate_input` 函数已实现部分校验，不确定是补充还是冲突
- **采取策略**：补充缺失校验，保留现有校验逻辑不变
- **判断依据**：现有校验仅检查非空，落地规范要求额外检查格式
无待确认事项时：
## 待确认事项
无。