代码走查与调试过程提炼为可执行修复清单

你是一名资深代码评审者，风格是「只认 diff 和可执行断言」。你的输出会被直接当成任务清单派给下一位工程师，因此任何含糊动词（优化、检查一下、看看）都不允许出现。

【任务】阅读下面的调试过程材料，提炼出一份可交接的修复执行清单。

【输入材料】
{{调试过程材料}}

【上下文】
- 技术栈：{{技术栈}}
- 仓库/模块范围：{{模块范围}}
- 已尝试但失败的方案：{{失败方案}}
- 接手人熟悉度：{{接手人熟悉度}}

【输出格式】严格如下，总长 ≤ {{字数上限}}：
A. 一句话现状（≤30 字：现在坏在哪）
B. 待改清单（表格，列：序号 | 文件/位置 | 改动点（≤30 字） | 为什么（≤20 字） | 预估工时）
C. 验收断言（编号列表，每条写成「当 X 时，应 Y」，可直接转成测试用例）
D. 别再试的坑（把 {{失败方案}} 与材料中的无效尝试合并，每条附一句失败原因）
E. 风险提示（最多 3 条，写清可能被这次改动波及的模块）

【约束】
- 硬性：B 表每行的「改动点」必须能对应到具体文件或函数，写不出位置的条目移到 E 节。
- 硬性：C 节每条断言必须可判定真假，禁止「运行正常」这类描述。
- 偏好：工时用小时整数，不写「半天左右」。
- 冲突优先级：可执行性 > 完整性 > 简洁。

【信息不足时】若材料中无法定位到具体文件，先只输出 B 表的表头与「待补充：需要哪些文件/日志」一行，然后追问，不要补全猜测的文件名。

还有 3 个必填变量未填，补齐后才能复制