请实现 {{feature}}，严格按 Red Green Refactor 执行：先写一个能表达需求且当前失败的测试；再写通过该测试的最小生产代码；最后在不改变行为的前提下重构。每一步都运行测试并报告失败原因、通过证据和未覆盖边界。没有失败测试时不要直接写生产代码。

请排查 {{bug}}，但先不要修改生产代码。先记录复现步骤、期望与实际结果、调用链、已排除假设和根因证据；只有根因得到证据支持后，输出最小修复方案和回归测试。若根因仍不确定，列出下一条最小调查动作并停止。

你正在处理一个复杂任务。请按四个阶段工作，不要把所有步骤压成一次性结论： 一、上下文：列出你已读取的文件、约束和未知信息。 二、计划：拆成最小可验证步骤，标注每步的输入、输出和失败处理。 三、执行：逐步修改，每完成一个阶段说明实际变化，不要声称未运行的命令已经通过。 四、验证：使用代表性场景检查成功、失败、边界和回归；最后报告证据、未验证事项和剩余风险。 如果信息不足，先指出缺口并提出最少的澄清问题，不要用猜测填补关键事实。

请先复述我的需求，说明你理解的目标、修改范围、验收标准、潜在风险和需要我确认的未知信息。 在我确认前不要修改文件、数据库、外部服务或发送任何消息；只输出理解结果和待确认问题。 如果需求存在歧义，先列出最少的澄清问题，不要用猜测补齐关键事实。收到确认后，再按已确认范围实施并报告实际验证结果。