JianFeeeee
b393b7072c
fix(ctx): prune 的查询向量改用插件 Cleaner 清洗后的有效内容(§13.8)
ContextPolicy=prune 上线时直接把**原始**工具结果传给 RelevanceContext.Prune，
而 Prune 的入参是**相关性查询向量**——它决定保留/归档哪些上下文事件。于是
ANSI 转义、base64、JSON 包装等噪声全被编进查询向量，打分失真，裁掉本该
保留的事件。
而 ToolDef.Cleaner 的契约本就写着「仅在向量化/jieba/蒸馏时调用」，裁剪正是
在向量化——所以这是**回归契约**，不是新增能力。此前只在构建事件向量
（context.go 的 toolOutputClean）时用了 Cleaner，裁剪查询这一处漏了。
回退规则（Cleaner 是计算层优化，不能因它失效而丢内容）：
- 未注册 Cleaner → 原文
- RPC 失败 → 原文（proc 侧 cleanerProxy 已有此保证）
- 返回空串 → 原文（空串会让查询向量退化成零向量，所有事件相关性相同，
等于随机裁剪）
验证：TestToolOutputForQueryAppliesCleaner（Cleaner 被调用恰好一次且用其
结果；无 Cleaner / nil stageHost 回退原文）、
TestToolOutputForQueryEmptyCleanFallsBack。
顺带把 §13.13 第 5 条（反向大结果）按核实结论结掉为「不做」：核实发现根本
不存在 llm.chat（llm.* 只映射切换 LLM 源），唯一可能返回大结果的 doc.query
没有任何外部插件使用且已被 CapDocMemory 能力门限制。留成永久 TODO 只会误导。
2026-09-10 23:59:12 +08:00
..
2026-08-05 09:59:33 +08:00
2026-08-14 00:48:40 +08:00
2026-07-29 14:48:23 +08:00
2026-09-10 20:36:39 +08:00
2026-07-25 11:17:31 +08:00
2026-09-09 18:56:44 +08:00
2026-09-09 17:38:34 +08:00
2026-09-05 12:03:30 +08:00
2026-09-06 09:51:31 +08:00
2026-08-18 09:07:21 +08:00
2026-09-05 12:08:33 +08:00
2026-09-06 09:51:31 +08:00
2026-09-06 09:51:31 +08:00
2026-07-28 11:42:29 +08:00
2026-09-05 12:03:30 +08:00
2026-09-04 22:00:03 +08:00
2026-09-09 17:38:34 +08:00
2026-09-04 20:53:32 +08:00
2026-09-09 17:38:34 +08:00
2026-09-04 06:25:51 +08:00
2026-09-04 06:25:51 +08:00
2026-09-10 20:36:39 +08:00
2026-07-16 12:11:16 +08:00
2026-08-18 09:07:21 +08:00
2026-09-10 23:59:12 +08:00
2026-09-10 23:59:12 +08:00
2026-09-10 20:36:39 +08:00
2026-09-10 20:36:39 +08:00
2026-08-18 11:49:57 +08:00
2026-09-03 12:37:58 +08:00
2026-07-24 14:49:08 +08:00
2026-09-03 12:37:58 +08:00
2026-09-03 15:38:31 +08:00
2026-08-25 10:50:37 +08:00
2026-08-26 16:10:02 +08:00
2026-07-27 15:26:23 +08:00
2026-09-06 09:51:31 +08:00
2026-09-09 17:38:34 +08:00
2026-09-10 20:36:39 +08:00
2026-09-06 09:51:31 +08:00