111 lines
6.9 KiB
Markdown
111 lines
6.9 KiB
Markdown
# 调研记录
|
||
|
||
## 2026-08-07 初始现象
|
||
|
||
- 用户截图中，标题条位于编号 2 的消息之后、编号 3 的消息之前。
|
||
- 预期是标题条属于编号 2 的消息，应显示在编号 2 的消息上方。
|
||
- 本轮 `ccweb_set_title` 返回的标题事件同时包含 `messageIndex: 1` 和
|
||
`anchorMessageIndex: 0`。两个字段相差 1，说明系统已经表达了“事件发生位置”
|
||
与“标题归属锚点”的区别。
|
||
- 初步假设：事件生成端已恢复 `anchorMessageIndex`，但某个持久化或渲染路径
|
||
仍读取 `messageIndex`，从而产生一位偏移。
|
||
|
||
## 仓库状态
|
||
|
||
- Git 工作区开始时干净。
|
||
- `codebase-memory-mcp` 项目 `home-cc-web` 索引状态为 `ready`，
|
||
共 5036 个节点、10706 条边。
|
||
|
||
## 代码索引初查
|
||
|
||
- 服务端 `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 与真实浏览器渲染。
|
||
|
||
## 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 版本下发及原有标题历史回归均保持通过。
|