What version of Kimi Code is running?
v3.1.10
Which open platform/subscription were you using?
moonshot
Which model were you using?
kim-k2.6
What platform is your computer?
windows 10 / window 11
What issue are you seeing?
环境信息
Kimi Work 版本：v3.1.x（旧备份生成版本）→ v3.1.x（新安装版本，版本一致）
操作系统：Windows 10 / Windows 11
迁移场景：旧笔记本 → 新笔记本，用户名相同
复现步骤
在旧机器上正常使用 Kimi Work，产生历史对话、项目、记忆等数据
备份 daimon-share 目录（含 agents_main/、config.toml、plugin-packages/ 、 sessions/ ）
在新机器上安装相同版本 Kimi Work，完成首次启动初始化
完全退出 Kimi Work
将备份的 daimon-share 覆盖到新机器对应位置
启动 Kimi Work
实际行为
✅ 左侧对话列表正确显示所有历史对话标题
✅ 对话对应的项目文件夹路径已正确指向新位置（通过数据库路径改写验证）
✅ 对话关联的 kernel_session_dir 目录和 wire.jsonl 文件均存在且可读
❌ 点击对话后内容区域为空，无法加载历史消息内容
❌ 搜索历史对话标题无结果
请求
提供官方数据迁移/恢复文档：明确 daimon-share 迁移的标准步骤，以及是否需要特殊操作触发索引重建
提供缓存重建机制：如启动参数、菜单选项、或自动检测机制，能在检测到数据库变更时刷新前端索引
确认 schema 兼容性：如果跨版本迁移需要数据库升级，请提供升级脚本或兼容层说明
What steps can reproduce the bug?
根因推测
Kimi Work 桌面版（Electron）在首次启动时基于当前数据库建立了前端缓存/索引（可能位于 runtime/ 目录、IndexedDB、或内存中的会话索引）。当用户后续用备份数据覆盖 daimon-share 后，前端缓存未检测到数据库变更并自动重建，导致：
列表层（可能直接读取 SQLite conversations 表）能显示标题
内容层（依赖前端缓存索引或 runtime/ 下的会话索引）无法关联到实际消息内容
What is the expected behavior?
预期行为
左侧对话列表应显示所有历史对话
点击任意历史对话，应加载并显示完整的对话内容（消息、附件、代码块等）
Additional information
已排查的线索（供参考）
检查项 结果 说明
数据库完整性 ✅ 完好 conversations.sqlite 可正常读取，25 条对话记录完整
路径改写 ✅ 正确 workspace_path 和 kernel_session_dir 已从旧路径更新为新机器路径
文件存在性 ✅ 存在 所有 kernel_session_dir 指向的 wire.jsonl 文件均存在
权限 ✅ 正常 当前用户拥有完全读写权限
版本一致性 ✅ 一致 新旧机器 Kimi Work 版本相同
前端缓存清除 ❌ 无效 清除 AppData/Roaming/kimi-desktop/ 下 Cache/Local Storage/Session Storage 后重启，问题依旧
What version of Kimi Code is running?
v3.1.10
Which open platform/subscription were you using?
moonshot
Which model were you using?
kim-k2.6
What platform is your computer?
windows 10 / window 11
What issue are you seeing?
环境信息
Kimi Work 版本：v3.1.x（旧备份生成版本）→ v3.1.x（新安装版本，版本一致）
操作系统：Windows 10 / Windows 11
迁移场景：旧笔记本 → 新笔记本，用户名相同
复现步骤
在旧机器上正常使用 Kimi Work，产生历史对话、项目、记忆等数据
备份 daimon-share 目录（含 agents_main/、config.toml、plugin-packages/ 、 sessions/ ）
在新机器上安装相同版本 Kimi Work，完成首次启动初始化
完全退出 Kimi Work
将备份的 daimon-share 覆盖到新机器对应位置
启动 Kimi Work
实际行为
✅ 左侧对话列表正确显示所有历史对话标题
✅ 对话对应的项目文件夹路径已正确指向新位置（通过数据库路径改写验证）
✅ 对话关联的 kernel_session_dir 目录和 wire.jsonl 文件均存在且可读
❌ 点击对话后内容区域为空，无法加载历史消息内容
❌ 搜索历史对话标题无结果
请求
提供官方数据迁移/恢复文档：明确 daimon-share 迁移的标准步骤，以及是否需要特殊操作触发索引重建
提供缓存重建机制：如启动参数、菜单选项、或自动检测机制，能在检测到数据库变更时刷新前端索引
确认 schema 兼容性：如果跨版本迁移需要数据库升级，请提供升级脚本或兼容层说明
What steps can reproduce the bug?
根因推测
Kimi Work 桌面版（Electron）在首次启动时基于当前数据库建立了前端缓存/索引（可能位于 runtime/ 目录、IndexedDB、或内存中的会话索引）。当用户后续用备份数据覆盖 daimon-share 后，前端缓存未检测到数据库变更并自动重建，导致：
列表层（可能直接读取 SQLite conversations 表）能显示标题
内容层（依赖前端缓存索引或 runtime/ 下的会话索引）无法关联到实际消息内容
What is the expected behavior?
预期行为
左侧对话列表应显示所有历史对话
点击任意历史对话，应加载并显示完整的对话内容（消息、附件、代码块等）
Additional information
已排查的线索（供参考）
检查项 结果 说明
数据库完整性 ✅ 完好 conversations.sqlite 可正常读取，25 条对话记录完整
路径改写 ✅ 正确 workspace_path 和 kernel_session_dir 已从旧路径更新为新机器路径
文件存在性 ✅ 存在 所有 kernel_session_dir 指向的 wire.jsonl 文件均存在
权限 ✅ 正常 当前用户拥有完全读写权限
版本一致性 ✅ 一致 新旧机器 Kimi Work 版本相同
前端缓存清除 ❌ 无效 清除 AppData/Roaming/kimi-desktop/ 下 Cache/Local Storage/Session Storage 后重启，问题依旧