soia-dev-fix-looplisted

# soia-dev-fix-loop 将 review、测试或运行中发现的问题当作可追溯工单处理。输入是一份或多份 findings；输出是逐项处理记录、经过回归验证的修复，以及不能修复项的明确理由和后续路径。 ## 适用范围 适用于普通工程仓库中的结构化 findings、失败测试或可定位缺陷。若任务受某个组织的专属状态、审批或归档规则约束，先加载对应的绑定层；本技能不假设任何特定目录、项目或工具链。 单个显而易见的小修改也应保留最小记录：复现证据、修复、相关回归和回执。 ## 客户可读说明 ### 这个技能可以做什么 | 客户想要 | 执行闭环 | 客户能看到 | |---|---|---| | 按审查意见逐条修复 | 汇总、决策、修复和逐项验证 | 每条 finding 的状态与证据 | | 确认是否可以收口 | 独立复核修复和回归结果 | 通过、需修改或受阻的结论 | | 暂缓部分问题 | 给出可追踪的后续位置与原因 | 明确的延后边界 | ### 客户如何使用 提供 findings、目标工作区、相关测试或复现信息，以及允许的修改范围。若某项可能涉及删除、覆盖、远端状态、发布或扩大范围，先明确授权；信息不足时先整理输入清单，不开始修改。 ### 依赖与安装 本技能无需专用安装或私有配置。强依赖是可访问的 findings、目标工作区和与风险相称的验证入口；遵循目标仓库已有的贡献说明和检查约定。 ### 日志与完成回执 过程记录输入数量、逐项决策、验证状态和阻塞原因。最终回执必须覆盖每条 finding 的结论、实际运行的检查、未处理项和残余风险；不得输出凭据或本机私有信息。 ## 五步修复循环 ### 1. 复现并规范化输入 读取全部 findings，提取唯一标识、严重性、位置、问题描述和来源。合并重复项；同一问题有不同严重性时采用较高等级，同时保留来源。对每条关键问题运行最小复现，或记录为什么当前无法复现。 ```markdown | Finding | 严重性 | 来源 | 位置 | 复现证据 | |---|---|---|---|---| | F-01 | high | review-a | <file:line> | <命令或步骤> | ``` ### 2. 修复前逐项决策 每条 finding 必须在实现前选择一个状态： | 决策 | 含义 | 必需依据 | |---|---|---| | fix | 本轮修复 | 目标行为和验证计划 | | reject | finding 不成立 | 可检验的反驳证据 | | defer | 暂不修复 | 可追踪的后续位置、负责人或触发条件 | 不得静默漏掉问题；不得用“以后再看”替代 defer。高风险决策或会扩大范围的修复先向用户说明影响并取得必要授权。 ### 3. 实施最小修复 只修改使该 finding 满足目标行为所需的部分。禁止以 TODO、注释、屏蔽异常、降低断言或删除测试来伪装修复。每项修复应能在 diff 中找到对应证据；若多项修复互相依赖，明确写出依赖关系。 修改后搜索同类模式，决定是否纳入本轮；若排除，记录范围理由，避免将未检查的相似问题误称为已解决。 ### 4. 回归与独立复核 每个 `fix` 项至少运行一条直接验证，并运行与改动面相称的回归检查。每个 `reject` 项复核其反驳证据；每个 `defer` 项复核后续链路真实存在且足够具体。 除测试外，使用独立路径攻击结论，例如检查 diff、构造反