调研记录

2026-08-07 初始现象

用户截图中，标题条位于编号 2 的消息之后、编号 3 的消息之前。
预期是标题条属于编号 2 的消息，应显示在编号 2 的消息上方。
本轮 ccweb_set_title 返回的标题事件同时包含 messageIndex: 1 和 anchorMessageIndex: 0。两个字段相差 1，说明系统已经表达了“事件发生位置” 与“标题归属锚点”的区别。
初步假设：事件生成端已恢复 anchorMessageIndex，但某个持久化或渲染路径仍读取 messageIndex，从而产生一位偏移。

服务端 setCurrentConversationTitle() 已将当前消息总数写入 messageIndex，并通过 findLatestUserMessageIndex() 写入 anchorMessageIndex。
服务端与前端 normalizer 都会保留满足 0 <= anchorMessageIndex < messageIndex 的显式锚点。
buildUserOutlineTimelineItems() 已优先查找显式锚点，并把标题的 sortPosition 设为 anchorMessageIndex * 2 - 1，从位置值看应排在锚点消息前。
现有 scripts/regression.js 已断言时间线类型顺序为 date,title,message,date,title,message，并断言显式锚点为 0。
因此问题不在标题事件生成或基础时间线构造的明显缺失；下一步需要重点核对最终排序比较器、实时事件处理、DOM 更新是否绕开或覆盖了该结果。

隔离计划 .planning/title-history-locator/ 记录：2026-07-29 已针对同一现象新增 anchorMessageIndex，专项与全量回归当时均通过。
Git blame 显示该实现来自提交 33c9783，当前 main 已包含此提交。
当前排序比较器首先比较 sortPosition；显式锚点 0 的标题位置为 -1，锚点消息位置为 0，纯函数上确实会得到“标题 → 消息”。
当前 updateUserOutlinePanel() 直接按该纯函数返回顺序生成 DOM，没有二次排序。
由此可排除“当前源码根本没有实现”这一可能；需要验证浏览器实际加载的静态资源是否仍是旧版本，或实时标题事件在某条路径被前端 normalizer 丢掉锚点。

PM2 的 ccweb 进程在线，启动于 2026-08-06 19:47（本地时区），未启用 watch。
页面引用 app.js?v=20260805-usage-loading-inline，该缓存版本晚于 2026-07-29 的标题锚点修复；正常重新加载过页面的浏览器应取得含修复的脚本。
session_renamed 实时处理会把 msg.titleEvent 同时写入 snapshot 和 currentOutlineTitleHistory，两处都经过保留锚点的 normalizer，然后立即重绘。
精确标题文本只在会话 904bcc12-... 的运行态 Codex App 文件中命中；该文件本身不是 cc-web 的会话元数据，需继续定位真正的持久化会话文档。

当前会话文档 904bcc12-...json 已持久化本轮标题事件： messageIndex: 1、anchorMessageIndex: 0，且消息数组只有索引 0 的用户消息。
这证明正在运行的服务端会正确生成和保存锚点；回归现象更可能只发生在客户端展示版本或目标历史会话的数据形状，而非当前服务端生成逻辑。

前端没有应用版本握手，也没有检测新静态资源后自动刷新页面的逻辑。
app.js 的查询参数只在用户重新请求 index.html 后生效；已经长期打开的标签页会一直执行旧内存中的 JavaScript，即使 PM2 重启或磁盘源码已更新。
这与“源码和回归正确、运行中 UI 仍呈现旧排序”的现象吻合，需进一步用运行态静态响应和端到端 DOM 验证确认，而不是再次改写已正确的排序算法。

服务端对所有静态资源返回 Cache-Control: no-store, max-age=0，因此一旦页面刷新，浏览器缓存不会继续提供旧脚本；风险只剩“标签页从未刷新”的内存旧版本。
以截图可见关键词宽泛搜索到的两个旧会话都没有 titleHistory，命中来自长文本内容而非截图对应的标题事件，不能据此认定是目标会话。
下一步应直接枚举标题历史的结构分布，确认是否还存在缺少锚点的新事件或旧格式事件在兼容回退中排序错误。

当前 18 条持久化标题事件中，15 条新事件包含合法锚点；3 条旧事件没有锚点。
所有带锚点事件都指向事件发生位置之前的用户消息，例如当前会话为 messageIndex: 1 -> anchorMessageIndex: 0，多轮会话也保持相同契约。
3 条无锚点旧事件的 messageIndex 之前都存在可见用户消息，现有 precedingAnchor 回退能够找到正确候选。
没有发现磁盘数据层面的非法锚点、字符串索引或事件位置异常；数据本身不足以复现截图顺序，继续核对 CSS 与真实浏览器渲染。

标题、消息和日期节点都按普通文档流渲染；标题样式没有 order、定位或变换， CSS 不会把正确的 DOM 顺序重新排错。
当前环境没有 Chromium、Playwright、Puppeteer 或 jsdom，不能直接启动现成的浏览器端到端测试；可继续使用项目现有的函数提取式前端回归。
尚需确认 PM2 是否通过 CC_WEB_PUBLIC_DIR 指向另一份静态目录；如果存在，就能解释“源码正确但页面仍是旧实现”。

服务端读取当前 PUBLIC_DIR/app.js 字节，计算 SHA-256 并取前 16 位十六进制作为资源指纹；入口页脚本 URL 与 auth_result.frontendAssetVersion 使用同一算法。
index.html 使用占位符，服务端仅在返回入口页时替换；实际运行态测试确认占位符全部消失，页面全局版本、脚本 URL 和 WebSocket 鉴权版本三者一致。
客户端只接受 16–64 位十六进制版本；缺失、非法或一致时保持正常鉴权流程，不一致时设置内存 guard 后刷新，重复握手不会重复触发。
独立质量复核代理虽未回传结论，但在被中断前落盘了两项合理加固： PUBLIC_DIR 统一 path.resolve()，静态文件边界从字符串前缀改为复用 isPathInside()，同时让运行态专项显式覆盖 CC_WEB_PUBLIC_DIR。
该加固修复了类似 /public-evil 通过 startsWith('/public') 的潜在路径边界误判，与本次动态入口注入的自定义静态目录兼容性直接相关，予以保留。
加固后的全量回归最终以 exit 0 完成；PUBLIC_DIR 自定义目录、入口页动态注入、 WebSocket 版本下发及原有标题历史回归均保持通过。