Repository navigation
首轮注入总是跑偏，这是我用ai总结的原因 #198
Description
首轮跑偏是同步渲染等不起异步向量，必然回退：
inject.js:218-225注入是同步text:(ctx)=>，必须立即返回；向量要调外部embedding，只能prefetch发出去给下轮用，首轮queryVectorCache.get必然miss。
service.js:1278/1290语义两条路双空：无queryVector、无lastSemanticRecall，直接走store.list(limit:200)规则排序：summary>preference>importance×quality取前5个。
你库427条活跃、preference 67条里29条imp=5，MAX_BLOCK=1500/maxItems=5下旧偏好占满槽位，当前话题decision/project进不来。recall_runs手动search走vector 0.78是准的，对得上。
Activity
modusensus commentedon Sep 16, 2026
三段根因逐条核过，与代码完全一致——这份分析把一个我们原本当作已知权衡的问题（inject.js 的 Bug4 注释里写着「首轮可能回退规则排序」）推成了必须修的缺陷：
assemble()对 contexts 的 text 不做 await，renderContextSections直接做同步字符串插值——异步 text 在宿主侧不被支持，所以「等向量」这条路在架构上就不存在；prefetchQueryVector只能发给下一轮，同一查询的首轮queryVectorCache.get必然未命中；修复见 #199：首轮（无向量、无缓存召回）改用 BM25 词法召回领位——查询文本就在手上，BM25 是纯进程内同步计算、无需等任何异步结果，词法相关性足以把当前话题的 decision/project 顶到前排。你的场景里，「夜航限流」这类查询词会直接命中话题记忆，而不是被 29 条 imp=5 偏好淹没。
设计取舍如实说明：
bm25SearchEnabled开关，关掉即回旧行为；「手动 search 走 vector 0.78 很准」这个对照也 thank you——它排除了向量索引本身的问题，把病灶精确锁在同步渲染的回退路径上。
fix(dream): coverage 不足降级为 degraded——不再整单拒绝（#104 方向 1） (#200)
modusensus commentedon Sep 16, 2026
修复已随 #200 合入 main（f39b9b4）。首轮改用 BM25 词法召回领位：优先级链变为 向量 > 缓存语义召回 > BM25 > 静态排序，下一轮向量就位后自动恢复语义精度，BM25 只兜首轮窗口，门控复用 bm25SearchEnabled 开关。回归测试按你报告的库形状建模（多条 imp=5 preference + 1 条 on-topic decision）：修复前 5 槽全被偏好占满，修复后 on-topic 居首。将随 v0.8.1 之后的下一个版本发布，发布后欢迎验证；issue 先保持 open 等你的反馈。
modusensus commentedon Sep 16, 2026
修复已随 f39b9b4（PR #200 的提交集）落在 main：首轮（无向量、无缓存召回）注入改用 BM25 词法召回领位，语义命中时行为不变——见 #199 的实现说明与本 issue 的根因分析。感谢 @lqs50 的报告；问题若在最新版本复现，欢迎重开。