增量修复与版本管理¶

增量流程把“批准内容、候选修改、正式部署、回归证据和历史版本”组织成一次有身份的运行。它解决的是已生成工作流的受控维护，不替代重新生成所有业务文件。

本轮输入¶

启动时冻结当前已批准 findings 和用户 suggestions。每一项都需要稳定 id、批准状态、说明和可确定的目标。增量 Agent 先读取工作流结构摘要、工具和 Checker 索引、相关 GuideDoc 和用户 docs 目录，再按本轮目标定向读取源码。初步认识不要求全文读取全部文件。

候选计划¶

候选计划记录：run id、批准条目、预计文件、每项修改目的、风险、检查命令和部署顺序。计划位于本轮 tmp/inc_runs/<id>/，不是 wfgen/workflow_implementation_plan.md。后者属于最初构建的跨阶段设计，控制台应分别展示。

修改和检查¶

正式文件先通过受控复制工具进入候选目录。Agent 修改候选后运行语法、结构、fixture 和受影响的 Make 目标。检查通过才能部署；部署器保存旧文件并原子替换。部署后必须再对正式目录运行检查，因为候选路径和正式路径可能具有不同引用关系。

历史版本¶

每个部署文件在 tmp/change_history/ 中保存内容和结构化索引。索引包含原路径、备份、哈希、run id、时间和动作。控制台允许查看、恢复和显式删除。

恢复时先为当前正式文件再建一个版本，然后原子写回选择的旧版本，最后运行相应检查。删除操作应同时处理索引和没有其他引用的备份文件；不可变审计默认值不能阻止用户明确清理版本记录。

回归失败处理¶

部署后 make check 失败意味着正式状态不可接受。增量流程应立即根据失败修复、重新部署和验证，或者回滚。此时不需要等待用户再次批准同一修复。若新修复会超出原批准范围，则回滚并报告阻塞，而不是保持错误正式文件并空转。

完成检查表¶

• 每个批准条目对应至少一个实际变更或明确“不需要修改”的证据。
• applied_changes.json 与文件哈希一致。
• 旧版本可定位、可恢复。
• 相关工具/Checker 测试和 make check 通过。
• 没有未登记修改、工作区外临时文件或任意 shell 操作。
• 增量报告不把待重新评估误写为已由评估确认。

候选计划最小字段¶

候选计划记录 run/batch/attempt、批准 id、目标文件、预计操作、原因、风险、候选检查和正式检查。一个文件可以覆盖多个批准，一个批准也可以需要多个文件，计划必须保留双向映射。

计划不是部署记录。实际部署后由 deployer记录源/目标哈希、备份、时间和结果，Agent不能预先把计划项写成 applied。

候选修改规则¶

先用受控 stager 复制正式文件并记录源哈希，再编辑候选。新文件也创建在当前 attempt 的 candidates 下。调试日志和转换中间产物留在 evidence/tmp，不放入 wfgen/ 或正式 workflow 根。

候选测试应最小且快速；部署后再对正式目录运行完整相关检查。若候选测试依赖工作流相对路径，使用隔离投影，不为方便提前覆盖正式文件。

历史和失败退出¶

恢复会先备份当前正式版本，所以可以撤销恢复。删除是用户显式清理，不是 Agent完成任务时自动执行。历史虽然在 tmp 中，clean 也必须保留。

批准范围不足时回滚并报告需要的新授权；依赖缺失时保存候选和证据并 blocked；候选检查失败不能部署；回滚失败要升级为需要人工恢复的严重状态。报告必须包含 run id、目标文件和最后返回码。