维护者确认：PR #3642 新增「中断回合自动继续」设置

[MagicLizi]

为什么需要维护者确认

PR #3642 把「被打断的回合是否自动继续」从内部行为改成了用户可改的设置项：设置页 Window Behavior 新增开关，并打通 main 持久化、IPC、preload 与 renderer hook。

这是产品方向变更（新的用户可见设置 + 默认行为可能被用户改掉），不是既有功能的补丁。需要维护者确认：

• 这个开关是否应该出现在设置里、放在 Window Behavior 是否合适
• 默认开/关是否符合现有中断回合产品口径
• 改设置后是否只影响新的中断，还是也改正在跑的任务

怎么确认

直接在 PR 上 Approve 即放行。需要修改就 Request Changes，作者改完后再 Approve。

不要只在评论或本 issue 里口头说「可以」——流程只认 PR 上的 Approve。

---

关联 PR:#3642(作者 @PeaceMaker-best);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的产品 / UI 变更,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断：连接中断后的自动继续已经是 Cindy 的正式产品能力，当前真正需要处理的是把已有的隐藏控制能力变成普通用户可发现、可持久化的 Desktop 设置；产品方向可以确认，但 #3642 仍应先完成一个技术 review 闭环，再作为最终放行依据。

现有产品事实与源码依据

• 已合入的 #1071 在真实的 SSE 流中断、网络不可达和上游容量异常场景下引入了 interrupted-turn 自动续跑。它不是对原 turn 的盲目重放，而是复用“继续任务”路径，避免重复已经产生的文件修改、命令执行或提交等副作用。
• apps/desktop/src/main/maker-host/interrupted-turn-auto-resume-store.ts 当前仍只提供隐藏配置读取：文件为 <userData>/interrupted-turn-auto-resume-settings.json，格式为 {"enabled": boolean}，缺省默认 enabled: true。当前 main 注释明确写着该配置“不进 Settings UI”，模块也没有设置页写入接口。
• apps/desktop/src/main/maker-ipc/register.ts 中的 InterruptedTurnAutoResumeGuard 会在中断决策时读取该开关；它与 SilentStopAutoResumeGuard 使用不同的 store、入口和额度模型，不能用一个总开关替代另一个。
• apps/desktop/src/main/maker-ipc/interruptedTurnAutoResume.ts 对自动续跑采用白名单判定，覆盖流截断、网络类和过载类中断，并设有连续失败上限 5 次、单次人工介入周期最多 10 次以及约 3–20 秒的退避。已有产出时走续跑，而不是重投原 turn；零产出容量拒绝则与 #844 分工处理。
• apps/desktop/src/renderer/components/settings/WindowBehaviorSection.tsx 当前包含保持唤醒、Windows 关闭行为和后台窗口点击行为等应用级设置，但没有 interrupted-turn 自动续跑这一行。因此“设置中没有可发现入口”的需求仍然存在。

产品判断

Issue #3367 已给出足够明确的产品依据：优先公开一个开关，默认不改变现有行为；暂不直接把默认策略改成断连恢复后强制暂停并等待确认。原 Issue 提到的“歧义指令可能导致不可逆操作”是合理的产品顾虑，但目前没有提供可复现会话、日志或已经发生的具体误操作证据，不能据此强行移除既有自动恢复行为。

因此，对 #3642 中以下方向可以确认：

1. 开关应出现在 Desktop 设置中，放在 Window Behavior / 应用行为与现有应用级行为开关并列是合适的。
2. 默认应保持开启，以避免升级后改变已有用户体验。
3. 关闭开关应停止后续符合条件的 interrupted-turn 自动续跑，并取消仍在退避、尚未派发的精确续跑任务；已经进入分类、派发或 provider 在途的续跑不应被强杀。
4. 该设置只控制 Desktop Host 的 interrupted-turn task-level auto-resume，不应暗示关闭 provider/SDK 自带请求重试，也不应控制 silent-stop auto-resume。
5. Desktop Host 级设置约束该 Host 上的本地和 SSH task 是一致的；不需要新增 Mobile UI、device-link channel 或远程工作区配置。手机端已有 #1161 补齐自动重连过程与结果展示，但那是展示能力，不是本次设置入口。

对 #3642 的推进建议

#3642 的实现方向与上述产品决策一致：PR 摘要显示其新增可信 GET/SET/RESET IPC、原子 override store、等待期排期取消、恢复默认控件、五语文案和回归测试，且默认仍为开启。PR 自报的相关 unit、typecheck、i18n、glossary 和 DCO 检查通过，未声称完成 Electron 实机或 Light/Dark 目视验证。

但目前不建议仅凭产品方向直接完成最终 Approve，原因是 PR 讨论中仍有两个需要收口的事项：

• #3642 review discussion 指出 interrupted-turn-auto-resume-store.ts 的 mtime 缓存可能削弱手动逃生门：如果用户或自动化在文件系统时间戳粒度内原地修改配置，mtime 可能不变，下一次读取仍使用旧缓存，导致 enabled:false 不能立即阻止自动续跑。该意见与当前 main 的设计契约直接相关，因为现有隐藏开关注释明确要求手动编辑后无需重启即可生效。应修改为可靠识别内容变化的方案，或明确证明所采用的版本/原子写入机制能保证变更可见，并增加同时间戳修改回归测试。
• feat(desktop): expose interrupted-turn auto-resume setting #3642 当前还有 bootstrap-electron.ts 的 review conversation 未 resolve；在该讨论收口、作者响应并重新跑 review 前，不应把 PR 视为技术审查完成。

建议行动

1. 在 feat(desktop): expose interrupted-turn auto-resume setting #3642 上确认产品方向：公开设置、默认开启、放入 Window Behavior；不要把“每次恢复前人工确认”混入本 PR，后者仍是独立产品决策。
2. 要求作者修正或充分验证 mtime 缓存问题，至少覆盖：文件不存在、合法开关切换、同时间戳粒度内原地修改、损坏 JSON、重启后状态、恢复默认。
3. Resolve bootstrap-electron.ts 未完成的 review conversation，并重新执行自动 review；所有阻塞性 conversation 收口后再执行最终 Approve。
4. 在发布前做一次 Windows packaged build 验证：断网/恢复触发中断自动续跑；退避期间关闭开关应取消待派发续跑并恢复人工继续入口；续跑已经发出后关闭开关不应终止在途任务；重新打开或恢复默认后行为应回到开启。
5. UI 方面建议补充至少一次 Desktop Light/Dark 目视检查。PR 复用了现有 Settings 卡片、Switch 和主题 token，这降低了风险，但自动 DOM 测试不能替代实机样式确认。

相关记录

• #3367：本需求的直接产品来源，明确了“先公开开关、默认保持开启、等待期取消而不强杀在途续跑”的建议口径。
• #1071：引入 interrupted-turn 自动续跑、白名单判定、退避/额度和隐藏 enabled:false 逃生门，是本 PR 应保持兼容的底层能力。
• #844：说明容量错误的零产出重投与已有产出续跑有明确边界，支持本 PR 不扩大开关语义到 provider/SDK retry。
• #1225：修复续跑已派发后的桌面进行中状态展示，证明“已进入运行态不应因设置变化而被误杀”是既有生命周期语义的一部分。
• #1161：已合入 Mobile 自动重连过程与结果展示；与本 PR 的 Desktop 设置入口正交，不构成额外实现依赖。