feat(multimodal): 完成阶段F运行管理与收尾验收

docs/retrospectives/阶段F-Embedding与知识库问题与解决方案.md

@@ -138,6 +138,46 @@ embedding_local_only: true
 
 ## 9. 工程经验
 
+### F-16：CUDA 选装只有脚本，前端缺少安装入口
+
+问题：上一轮完成了独立 CUDA 环境安装和 GPU 实测，但页面只有设备下拉框及脚本说明。用户无法从前端下载组件，工程收尾遗漏了可操作入口。
+
+实际方案：增加独立组件卡片和 GET/POST 状态、安装接口；展示环境检查、下载 PyTorch、安装依赖、验证等真实阶段，失败允许重试。固定脚本、目录和参数，默认 CPU 环境不变；安装成功后 CUDA 模式自动选择已验证环境，显式 Python 覆盖仍优先。推理期间拒绝安装，重复点击不产生多个任务，后端关闭时回收安装子进程树。
+
+验证：21 项后端相关测试及新增前端组件测试通过，类型检查和构建通过；真实页面已显示本机 `2.9.1+cu128` 组件就绪，默认 CPU 未改变。本轮复用已安装组件验证识别，未重复下载 3 GB 安装包；下载入口、重复请求和失败重试由隔离测试覆盖。
+
+### F-17：幂等键跨扩展名与请求规则导入竞态
+
+问题：附件 ID 原先由幂等键哈希和扩展名共同生成，相同键更换扩展名可以创建第二份附件。请求规则导入等待服务端验证期间，用户的新编辑可能被迟到的导入响应覆盖。
+
+实际方案：后端持久映射幂等键、文件名、附件 ID 和内容摘要，并在 SQLite 写锁中完成查重；文件名或内容变化均返回冲突，已清理的旧附件要求开始新提交。请求规则编辑器为导入和每次草稿变化递增 generation，只接受仍对应当前草稿的响应。
+
+验证：增加同键跨扩展名冲突，以及导入后继续编辑、迟到响应不覆盖的测试。相关后端 17 项、前端 15 项通过；最终全量后端 559 项、前端 102 项及生产构建通过。
+
+### F-13：CUDA 失败重试与诊断无法追溯
+
+问题：设备不可用时能够使用 CPU，但 CUDA 初始化失败、显存不足会直接使任务失败；诊断只留在进程内存中，重启后无法解释当时的失败和回退。
+
+实际方案：在同一队列占位内完成 CUDA → CPU 单次重试，先回收失败子进程再启动 CPU。只接受初始化失败、CUDA OOM 两类重试原因，普通模型错误不扩大重试范围。转写部分结果随尝试重置，取消仍终止流程。诊断按白名单写入 SQLite，保留最近 200 条，记录请求设备、实际设备、尝试设备、状态和耗时；未知设备不冒充实际使用设备。
+
+验证：故障注入覆盖初始化失败、OOM、普通错误、CPU 再失败、资源释放顺序、队列顺序和请求用量归属。Windows RTX 4060 Laptop 实机安装 `torch 2.9.1+cu128`，ASR、片段声纹和 Embedding 的实际设备均为 `cuda:0`，完成笔记生成、检索与修订更新。实机正常 CUDA 路径通过；OOM 回退是确定性注入验证，未人为耗尽用户显存。
+
+### F-14：响应丢失重复上传与转写笔记无法安全更新
+
+问题：前端每次点击都生成新幂等键，上传或创建任务已成功但响应丢失时，重试可能制造重复附件/任务。已有导出幂等只能返回相同修订，缺少新修订更新原笔记的保护机制。
+
+实际方案：同一次页面提交冻结文件与选项，复用上传/任务键，已获得的附件 ID 继续使用；主动重新处理才重置标识。后端重复上传校验内容摘要。导出基线保存正文摘要，跨修订更新在 Vault 写锁内核对基线，用户编辑冲突返回 409，允许改为创建新笔记；旧无基线记录不强行覆盖。索引重建不丢失基线，本地限制继续随笔记持久化。
+
+验证：覆盖上传响应丢失、任务响应丢失、主动重跑、重复键内容冲突、修订更新保持 note_id、重复导出、重建恢复和用户正文冲突。CPU/CUDA 两次真实本地管线均在隔离 Vault/SQLite 中通过检索与修订闭环，不写入用户笔记库。
+
+### F-15：运行管理与请求配置验收缺项
+
+问题：下载计数不能反映实际占用，后台索引与交互查询同优先级；音频调用没有独立时长统计；请求规则缺少导入/导出/恢复默认和真实推理验证，草稿改变后旧验证结果可能误导用户。
+
+实际方案：磁盘大小读取目录文件，查询/媒体/后台索引分别排队；音频次数、已报告时长与 Token 分开聚合，保留覆盖数。规则文件由服务端验证后替换草稿，保存后生效；验证按钮使用固定短消息走实际 Adapter。草稿变化使预览与验证失效，包括无效 JSON 和迟到响应。
+
+验证：增加实际目录统计、音频缺失值与去重、规则拒绝受保护字段、隔离 HTTP 协议测试及前端迟到响应测试。最终后端 555 项、前端 100 项通过。真实供应商兼容性仍须使用目标账号验证；本轮不将 MockTransport 协议测试称为厂商实测。
+
 ### F-12：普通分割线与元数据头部消歧
 
 F-11 修复后，`---` 和 `---\n\n# Title\n\n正文` 等合法 Markdown 被误判为未闭合 frontmatter，原先能够保存的笔记被拒绝；库中已有此类文件时全量重建也会失败。