评估、审批与增量修复问题¶

明显配置错误未被评估发现¶

现象：例如阶段使用不存在的变量、引用未来文件或 Checker 检查错误对象，但评估报告没有 finding。

原因类型：评估指导只列少量表面规则；评估 Agent 只搜索关键字没有进行阶段数据流核对；证据预算耗尽；某分项认为问题属于其他责任域。

处理：增强通用检查维度而不是只增加某个变量名。流程评估应建立变量定义到使用、阶段输入到输出、引用存在时间、Checker 对象到产物的映射，并执行反证。严重程度根据实际影响判断。

用户怎样批准和提出建议¶

可以使用控制台，也可以执行 eval-approve、eval-reject、eval-defer 和 eval-suggest。批准理由写允许的修改边界和验收目的，不需要用户提供完整补丁。新增 suggestion 用于用户主动提出评估报告中没有的问题。

增量第一阶段读了很久¶

认知阶段的目标是理解当前工作流和本轮批准范围，不是全文读取全部 tools、checkers、GuideDoc、docs 和报告。应先读索引、目录和摘要，再按批准目标读取直接相关文件。每次工具输出也要限制到需要的区间，避免压缩后立刻再次超限。

增量流程没有完成全部审批¶

检查当前 run 的批准快照和“条目到修改/证据”映射。完成条件必须覆盖每个 id；只修第一项后 make check 通过不能代表其他建议已完成。没有修改的条目也要记录为什么无需修改及证据。

部署后 make check 失败但流程等待¶

这是严重状态机问题。正式文件已经替换后，批准状态不再是阻止修理的门。流程必须继续修复并再验证，或回滚并失败退出。版本备份负责恢复，不需要为同一已批准目标进行第二轮人工审批。

修复后旧 finding 仍在¶

聚合报告保留历史。需要重新运行 eval_tools、eval_checkers、eval_flow 或 eval_env，用新 run 形成结论。直接删除旧 finding 会损失审计信息，也不能证明修复有效。

修复得异常快¶

查看 applied_changes.json、正式文件差异、候选证据和真实命令返回码。可能是问题只需小改，也可能只更新了报告没有部署。速度本身不是质量证据。

评估 Agent连续失败¶

先区分报告 Checker失败与目标 finding。读取最后工具调用、JSON store 错误、required check id 和 report status。若工具只接受 record 而 Agent传整个文档，应修指导示例；若证据缺失，应补源码或命令，不能直接降低 Checker。

finding 质量判断¶

高质量 finding 可复现、引用需求、有源码或返回码、严重程度有理由且建议范围明确。低质量 finding 只说“可能有风险”、把格式偏好定为 critical、引用不存在路径或建议重写整个系统。审批前合并同根因重复项。

候选计划与构建计划¶

wfgen/workflow_implementation_plan.md 属于初次构建；当前 candidate plan 位于 tmp/inc_runs/<id>/。控制台可以同时展示，但不能混为一套系统。把候选写回构建计划会污染历史设计。

只读正式文件与提前结束¶

deployer 通过同目录临时文件和 os.replace 部署，普通只读文件可处理，目录不可写或备份失败仍阻断。若 inc 提前结束，比较 approval snapshot、candidate plan、incremental report 和 applied changes，确认每个批准 id 都有变更或无修改证据；make check 通过不能单独证明所有建议完成。