维护者确认：#3866 动态任务标题（设置开关 + 用户可见标题变化）

[MagicLizi]

PR #3866 给设置页新增「自动更新任务标题」开关：打开后，任务每轮收尾会把侧边栏标题改写成全中文「MMDD｜类型｜主题」。

这是用户看得见的新产品行为（设置项、任务列表标题、默认关闭但仍改变可选产品路径），不是内部实现修补。请维护者确认：

1. 是否接受「默认关闭、opt-in 后由模型改写任务标题」这条产品路径；
2. 标题格式（上海时区日期、固定中文类型词、永不覆盖手动改名）是否符合任务/对话命名口径；
3. 设置页新卡片与文案是否按现有设置分区规格落地。

确认方式：直接在 PR 上 Approve。需要修改就 Request Changes，作者改完后重新 Approve 即放行。

---

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

[dash-s-cindy]

判断：动态任务标题能够改善侧栏中多任务并行时的识别效率，采用默认关闭、用户主动开启的产品路径具备可评估性；当前应先完善实现和验证，再由维护者对用户可见行为作出确认，不建议此刻直接批准 #3866。

行动：

1. 请作者先处理 #3866 中尚未解决的 dynamicSessionTitle.ts review conversation，并针对普通任务补充回归测试；在该问题关闭前不要以现有 45 个测试通过作为功能可用的依据。
2. 修复后重新验证：普通首条文字消息、已有普通自动标题、Fork 占位、纯附件后再输入文字、用户手动改名（包括改成与占位相同的文字）、模型失败、开关关闭，以及连续多轮更新。
3. 维护者单独确认三个产品问题：是否接受模型改写标题；是否接受 MMDD｜类型｜主题、上海时区和固定中文类型词；设置卡片和五语言文案是否符合当前设置分区规范。确认后再在 PR 上 Approve 或 Request Changes。
4. 在合并前完成 Desktop 实机检查：打开开关后运行完整一轮，确认侧栏标题实际更新；手动改名后继续运行多轮，确认不再覆盖；分别检查 Light/Dark 设置页。当前 PR 自述这些项目均未实机完成，因此自动测试和 typecheck 不能替代它们。

现有实现与证据

当前 main 快照 d42265481847fe3fce0955b4d5dc2ac2bb97d972 已存在“首条输入自动起名”能力，但尚未包含 PR 所述的动态任务标题模块。相关代码位于：

• apps/desktop/src/main/localDb/ipc/sessions.ts
  • getOverwritableAutoTitle() 只把三类标题视为系统可覆盖占位：默认 New Maker、带父任务的 [Fork...] 占位、纯附件生成的合成占位。
  • 普通已有标题不会通过该资格判断，因此后续动态更新若沿用这条资格路径，会出现“模型根本不调用、标题不变化”的结果。
  • persistSessionTitleIfStillDraft() 使用 WHERE title = expectedTitle 的条件写入，避免异步模型结果覆盖并发中的用户改名。
  • setOnUserSessionTitleWritten() 进一步记录用户显式改名，即使用户改成与占位完全相同的字符串，也能阻止后续自动起名覆盖。
• apps/desktop/src/main/localDb/ipc/__tests__/sessionAutoTitlePersist.test.ts
  • 覆盖了条件写、用户改名优先、Fork/附件占位、DB 不存在和 DB 权威 agentKind 等行为。
• apps/desktop/src/main/maker-ipc/__tests__/sessionAutoTitle.test.ts
  • 覆盖了首条文字、纯附件后再输入文字、模型失败、并发串行化、用户改名同值、消息拦截和写入回执不确定等路径。

因此，PR 声称“永不覆盖手动改名”与现有数据层不变量方向一致，也有可复用的安全基础；但这只能证明保护机制已有基础，不能证明 PR 新增的动态资格判断、触发时机和标题格式已经正确。

PR 当前状态与关键阻塞

#3866 当前仍为 open、未合并的非 draft PR，标记为 awaiting-discussion，有 23 个文件变更、约 1120 行新增。PR 声明实现了设置开关、turn 收尾触发、标题生成/解析/条件写入、设置 UI 和五语言文案；自动测试、Desktop typecheck、i18n glossary 和 design inventory 均声称通过。

但 PR 的 Greptile review 指出一个直接影响主路径的问题：现有首条消息自动起名会先把 New Maker 改成用户首句或普通智能标题，而新增动态逻辑只允许默认占位或既有动态格式继续覆盖，于是普通任务会被判定为 title-not-system-owned 并跳过动态生成。这一 finding 与当前 main 中 getOverwritableAutoTitle() 的资格模型相吻合，应视为合并前必须澄清和修复的功能阻塞，而不是仅凭 UI 或格式偏好可接受的差异。

另外，PR 讨论显示该 review conversation 尚未 resolve，自动审查因此暂停；Issue #3868 又为该 PR 增加了维护者产品确认门。当前正确的推进顺序是“修复实现与测试 → resolve conversation → 重新自动审查 → 产品确认 → 实机验证”，而不是先 Approve 再补齐功能正确性证据。

产品口径

docs/product-rules/task-and-conversation-naming.md 已明确：侧栏中可单独打开、删除、重命名、分享的条目称为“任务”；任务内的交流过程称为“对话”；单条往来称为“消息”。这支持设置项和侧栏标题使用“任务”一词，也说明不应把 Agent 运行时会话与产品任务混称。

该规则没有确认以下新增选择：

• 标题是否应由模型在每轮收尾时持续改写；
• 日期是否固定取上海时区；
• 类型是否固定使用“功能/设计/修复/优化/发布/探索/文档/研究”；
• 主题是否应完全由模型概括；
• 开关开启后是否覆盖此前由现有自动起名生成的普通标题。

其中“永不覆盖手动改名”与现有条件写和用户改名通知机制相容，风险相对可控；其余项目仍属于产品取舍，不能仅凭代码中缺少限制或 PR 作者的建议推导为既定规则。

范围需要澄清

Issue 正文称任务列表标题由桌面、移动、远程侧边栏共用同一份数据；而 #3866 的 PR 描述将影响范围写成“仅 Desktop 本机任务标题”，并明确用户可见变化为 Desktop 设置和侧边栏。现有检索没有足够证据证明移动端和远程端会同步消费这次新增设置或动态标题事件，因此合并前应明确本次契约：

• 如果只支持 Desktop 本机，应将 Issue/PR 文案收窄，避免承诺移动和远程行为；
• 如果目标确实是共享数据的多端展示，应补充 device-link/mobile 的触发、同步、旧端降级和验证证据，而不能只依赖 Desktop 单测。

这不是建议额外扩大范围，而是避免按不同范围理解同一产品承诺。

建议的验收最小集

场景	期望
开关默认状态	新安装和无 override 时关闭；恢复默认删除 override；关闭后停止新的动态刷新，已有标题保留
普通首条文字	开启后能在规定触发点生成动态标题，不因既有普通自动标题而被跳过
多轮任务	在冷却规则允许时可更新；模型失败静默保留现标题，不阻断任务
手动改名	任意用户手动改名后不再被模型覆盖，包括改成系统占位同值
Fork/附件	Fork 占位和纯附件占位遵守既有“先保留、用户输入后替换”语义，不被附件名错误推进为最终动态标题
并发与条件写	用户改名、turn 收尾、标题模型返回乱序时，用户写入胜出，条件写失败不误报成功
格式	日期、类型、主题长度/空值/异常输出有确定的归一化结果，五语言设置文案 key 对齐
视觉	设置卡片在 Light/Dark 均使用语义 token；至少完成一次实际开关和侧栏联动目检

相关记录：

• #3866：当前功能实现、自动审查 finding、未完成的实机验证和产品确认阻塞，属于直接依赖。
• #1171：确立“任务/对话/消息”的产品术语边界，可用于审查设置文案和标题相关说明；它没有确认动态标题格式或模型改写策略。

没有发现已合并发布、已明确决定采用该动态标题格式，或能替代本次维护者产品确认的其他可靠记录。