#fix：分析并修复

新的主入口是 开发与修复。本页保留 /workflows/fix 深链，并提供 fix 的修复证据链；fix.default、fix.incident、fix.security 的选择以分组页和工作流索引为准。

#适用 / 不适用

适用：有可复现的失败、回归或缺陷，要定位并改掉。
不适用：还没确定是不是缺陷的调研（用 analyze 或 audit）。

#是否改文件

会。先复现和定位，修复方案确认后再改。

#阶段与证据

1. 记录期望、实际、环境与可重复步骤。
2. 用失败测试、日志或可观察行为固定复现证据。
3. 解释根因，并检查共享路径和同类消费者。
4. 确认修复范围、非目标、回滚与回归路线。
5. 修改后先证明原失败消失，再运行风险相关回归。
6. 报告证据、未验证范围和后续动作。

确认要修改后，修复任务同样先绑定唯一 project、active-root 与 task，再建立正式任务身份；不会从 workspace 的“最近任务”、目录修改时间或另一个会话的旧 terminal 状态推断写入目标。问题说明、用户原始需求与后续修复产物各有固定职责，不能互相覆盖。

#确认边界

修哪些路径、是否顺手重构、是否提交，需要确认。每次正式 mutation 还要与当前 task、目标路径和实际观察到的效果对账。不会因为「看起来相关」就扩大删除、清理别人的 dirty、改发布脚本或安装全局工具。

#产物

问题说明、根因、修复、验证证据、报告。

#验证

至少复现原失败，再按可能受影响的消费者跑相关 V0～V2 测试。不能只靠「我看了代码」，也不能因为控制面风险较高就自动升级 full、pack 或发布验证；更大范围必须有当前、精确的独立授权。

#完成条件

原失败在同一条件下由 fail 变为 pass，约定回归通过，同类路径已检查，剩余风险写明。一次偶然成功不能替代稳定复现与回归。

#示例请求

复现当前失败的文档站点链接检查，定位根因并修复。只改公开站相关文件。

完整走法见修复并控制回归。