[Bug] autoDream 长期不可用：两处独立缺陷 ——「模型回填 8 位 id 前缀 vs 校验器 36 位整串匹配」与「默认档位+预算让思考型模型返回空体」

[aizhimoran]

摘要：181 轮 autoDream 里 169 轮失败（no json array in llm output 146 轮、invalid decisions: 1 errors 22 轮），只有 5 轮真正合并过任何东西。

本机定位到两处互相独立的缺陷，并各自验证了修复：

1. 主缺陷（本轮新发现）：模型把 36 位 UUID 回填成前 8 位前缀，而校验器用 snapshot.get(id) 做整串精确匹配 → 逐条 unknown id → claimed=0 → 覆盖率闸整单拒绝。模型的语义判断其实是对的（实测 78/78 个前缀都能精确对应到窗口里的真实记忆）。
2. 次缺陷（承接 [Bug] autoDream 在记忆量较大且路由为思考型模型时 100% 失败：no json array in llm output #9）：dreamReasoningEffort 默认 none 会让 harness 补上模型的 defaultEffort（v4-flash 系 = high），叠加 dreamMaxTokens 的 schema 默认值 32768，思考型模型把预算烧在推理上 → 正文为空。

关键放大器：这两类失败既不落库也不落日志（见「观测缺口」），所以问题被藏了 140+ 轮。

修复后首轮即成功：status=degraded, applied=34, merge-archived=62。

环境

项	值
DSH	0.1.5-rc.1（win32，web profile）
@modusensus/dsh-mneme	0.7.31（npm latest，GET /api/dsh-mneme/info 确认）
agent 默认模型	deepseek-official / deepseek-flash（~/.dsh/settings.yaml → agent-default-model）
dream 路由（复现期）	先 deepseek-official / deepseek-v4-flash（思考型，声明 off/low/high/max，default = high），后落到 agent 默认 deepseek-flash
dream 生效预算	dreamMaxTokens = 32768（schema 默认值，未配置）
候选窗口	dreamMaxSnapshotSize = 200（默认）
记忆库	总 1010 / 活跃 376 / 归档 634

现象

dream_runs 全量（2026-08-28 → 2026-09-12 01:41，共 181 轮）：

status	轮数	applied 合计	说明
failed	169 (93.4%)	0	全部无产出
ok	8	6	其中 7 轮是「模型零有效决策」被隐式 keep 补齐（见附录 B）
reconcile	3	100	决策部分未提交（CAS/回滚）
degraded	1	34	修复补丁落地后的首轮

失败原因：

error	轮数
no json array in llm output	146
invalid decisions: 1 errors	22
llm failed	1

真正合并过的轮次全库只有 5 轮，累计 merge-archived 295 条。

缺陷 1 的实证：8 位前缀 vs 36 位整串

在失败路径落库的校验明细里（见「观测缺口」，这是本机打补丁后才拿到的）：

errors  = ['explicit decision coverage 0% < minimum 1%']
skipped = 27 条
  decision[0] merge ids=5 → unknown id "f77a0d17"; …（5 个全 unknown）
  decision[1] merge ids=4 → unknown id "23178b3b"; …
  …

三向归类（window_ids 取该轮 dream_runs.input 的 200 个 id；all_ids 取 memories 全表 1002 个 id）：

分类	条数
在窗口内	0
不在窗口但在库中（活跃/归档）	0
库中根本不存在	77（去重后）= 全部

但被拒 id 的长度分布是 {8: 78}，而窗口 id 与库中 id 的长度分布都是 {36: 200} / {36: 1002}。把它们按「窗口 id 的前 8 位」匹配：

被拒 id 共 78 个，能在窗口前 8 位中找到的：78 / 78
  f77a0d17 → f77a0d17-2586-41fe-a789-d69f4d1cee83
  bc17c9ed → bc17c9ed-e84c-4b9f-bc36-48f8e9a6b3e0
  fe6199e6 → fe6199e6-1933-4520-a028-9ceb2cf79011

而提示词给模型看的是完整 36 位（src/dream.js:693 的聚类分支与 :706-708 的兜底分支都是 id=${m.id}）。

⇒ 模型认对了要合并哪几条记忆，只是把 id 缩写成了前 8 位；校验器按整串查表，于是整轮成果被判无效。

缺陷 2 的实证：no json array in llm output

• 失败点是 src/dream.js:762-765：extractJsonArray(text) 返回 null → 整轮丢弃。
• streamText 只收集 text-delta；思考型模型把 maxTokens 全花在 reasoning-delta 时正文为 0 —— 该机制已由 [Bug] autoDream 在记忆量较大且路由为思考型模型时 100% 失败：no json array in llm output #9 用 chunk 分布实测（{reasoning-delta: 32768, text-delta: 0}）并获维护者认可。
• 本机命中该模式的两个条件都成立：
  • (a) dreamMaxTokens 停在 schema 默认 32768（src/config.js:67 的 .default(32768)；[Bug] autoDream 在记忆量较大且路由为思考型模型时 100% 失败：no json array in llm output #9 只把 max 抬到 131072，默认值没抬）。
  • (b) dreamReasoningEffort 默认 "none"（config.js:81），而 resolveDreamEffort 在 src/dream.js:392 直接短路 if (!configuredEffort || configuredEffort === "none") return null; → 不发送 reasoningEffort 字段 → harness 补上模型声明的 defaultEffort（v4-flash 系 = high）。即开箱默认配置恰好把思考预算拉满，也让 v0.7.26 声称的「defaultEffort 陷阱根治」默认不生效。
• 换非思考模型只压低、未消除：把路由换到 deepseek-flash 后，失败率从 98.0% 降到约 50%（重启后 6 轮里仍有 3 轮 no json array），输入 8 万字符量级。所以预算/档位仍是活的隐患。

观测缺口（本机为了让根因可见，不得不先打补丁）

与 #104 的关系：该 issue 已包含「失败审计缺明细」这一项，本 issue 不主张它是新问题；这里提供的是可复现的量化证据（168 轮失败零现场、明细 warn 因写在 return 之后而不可达），可直接并入 #104 处理。

失败轮次不落任何可诊断信息，且日志路径不可达：

// src/dream.js:779-786
if (!ok) {
  logger?.warn?.(`dsh-mneme dream: invalid decisions: ${errors.join("; ")}`);
  return finish({ ok: false, error: `invalid decisions: ${errors.length} errors`, summary: false }); // ← 不传 decisions
}
const skippedInvalid = skipped.length > 0;
if (skippedInvalid) {
  logger?.warn?.(`dsh-mneme dream: ${skipped.length} invalid decision(s) skipped …`); // ← 在 return 之后，永远执行不到
}

• finish 在失败分支不传 decisions → 落库为 NULL；而 validateDecisions 明明已经把逐条明细 skipped: [{index, action, ids, error}] 返回给了调用方，却被丢弃。
• 唯一的明细日志写在 return 之后 → 不可达。
• 本机实测该插件的 ctx.logger.warn 也不上 stdout（终端里看不到 mneme 的任何日志）。
• 结果：146 + 22 = 168 轮失败，没有一轮留下「模型到底输出了什么」的痕迹。

根因

主因：校验器不接受 id 前缀

src/dream/decisions.js 的 validateDecisions 用整串匹配判定 id 合法性，任何未精确命中的 id 都记 unknown id 并把该条决策跳过（dreamSkipInvalid 默认 true）。当模型把所有 id 都缩写成 8 位前缀时，全部决策被跳过 → claimed.size = 0 → 覆盖率闸（explicit decision coverage 0% < minimum …）整单拒绝 → 整轮丢弃、applied=0。

这是「校验器过严 + 模型习惯」的组合缺陷，而且因为上文的观测缺口，运维侧完全看不出是 id 格式问题（错误串只有一句覆盖率，明细被丢）。

次因：预算与默认档位（承接 #9）

见「缺陷 2 的实证」。

第三层：候选窗口（已由 #125 覆盖）

dreamMaxSnapshotSize（默认 200）按 updated_at DESC 截断候选，窗外旧记忆永不进视野。本机候选池 375 条、窗口覆盖约 53%，且写入速率可达单小时 140 条。此处不复述、不重复提交。

附属发现：memoryQualityFilter 的两个问题（与 dream 失败无关，但同属「静默归档 + 审计线索被销毁」）

机制（src/service.js:960-978）：每次写入由 LLM 打分（0–100，本机全库均分 79.2）并给出理由标签（low_quality / duplicate / meta / repetitive / short_content）；score < archiveThreshold（默认 30）即无条件归档，标签以并集写入，作为「为什么被归档」的审计痕迹。

本机实测（2026-09-12）：

口径	条数
quality_score < 30	150
其中带 low_quality 标签	148
已归档	149
其中 importance ≥ 4	128（126 条带标签）

问题 1：importance 完全不参与归档决策

150 条低分条目 100% 被归档，其中 51 条 importance=5、77 条 importance=4 —— 一条被标为最重要的记忆，会被一个 LLM 分数静默归档：无感知、无通知、无豁免。建议 importance ≥ 4（或 ≥5）时只降权不归档，或至少归档时给出可见通知。

但这些低分条目并非误伤：判断器自己给出的理由标签里 duplicate 占 79%（101/128），meta 37%、repetitive 34%，且无一条 short_content（说明不是按长度误杀）。它归档的确实多是重复/元信息。

真正的上游问题在 #127：本机这 150 条低分条目的 source 几乎全是 session:*，即 autoSummarize 的蒸馏产物——每轮都在铸造注定被立即归档的条目，白烧 LLM 配额。

问题 2：信号标签会被后续 update 覆盖

applyQualityDisposition 用并集写标签（src/service.js:967），但更新路径是整组替换：

memory_update(args)               lib/tools.js:233
  → service.update(id, {…, tags})  src/service.js:1485
    → store.update(id, p)          （p.tags 直接写入，不再并集）

于是任何带 tags 的更新都会冲掉判断器留下的 low_quality/duplicate/meta 等标记。实证对账：150 条低分条目中 148 条带 low_quality，缺的 2 条恰好都是被 memory_update 改过的；而另一条创建后未再更新的同类条目标签完好。

后果：「这条记忆为什么被归档」变得不可追溯 —— 无法区分「质量门自动归档」「用户手动去重归档」「dream 合并归档」。本机就因此一度误判为"是被 dream 合并归档的"，不得不额外排查全部 dream 轮次的 outcome/decisions 才排除。建议更新时把系统信号标签并集保留（用户自传的标签照常生效）。

附属发现 2：向量层从未配置 —— 五个功能静默失效，而 /semantic 报 ready: true

机制（src/embedding.js:85-86 与 :111-112；local-embedder.js 的各后端同理）：

const cfg = settings.getVectorConfig();
if (!cfg?.enabled || !cfg.baseUrl || !cfg.apiKey || !cfg.model) return;   // ← 静默返回

本机实测（2026-09-12）：

GET /api/dsh-mneme/vector-config → {"enabled": false, "baseUrl": "", "apiKey": "", "model": ""}
kv（user_settings）              → 只有 external_api 与 feature_flags，没有任何向量配置
memories                         → 总 1035 / 无向量 1035（100%）
vector_meta                      → 空表（0 行）
llm_audit_logs                   → 435 行里没有一种与嵌入沾边的 operation_type

即一次嵌入请求都没有发出去过（在第 86 行就 return 了），因此不产生任何错误日志 —— 连"未配置"这个事实都无处可查。

静默失效的五个功能：

功能	表现
语义召回（向量检索）	无向量可搜，只能靠关键词 / BM25 兜底
searchSemanticDedup	开关为 true 但不生效
rerankEnabled	reranker: null
sleep 的冲突检测	被跳过（报告里写 "reason": "no usable vectors"）
dream 的语义聚类预分组	退化到全量窗口列表兜底（dream.js:705-708）

对照：不依赖向量的功能是正常的 —— entities 121 行、recall_runs 2177 行、llm_audit_logs 435 行。所以问题精确定位在向量这一层。

问题：GET /api/dsh-mneme/semantic 报 ready: true，但同一响应里 index.embeddedCount = 0 / totalCount = 346、modelHash / dimension / reranker 全为 null。ready 只反映"嵌入器对象已构造"，不反映索引里有没有数据。建议：ready 结合 embeddedCount / totalCount 计算；并在 getVectorConfig() 为空时至少记一条 info/warn。

补充：本机原先 embedProvider 取 openai，而该分支必须依赖上表那四个字段（index.js:210-213）；把 embedProvider 改成 local/ollama 则走 local-embedder.js（本机已装 @huggingface/transformers + onnxruntime-node，但 HF 模型缓存为空，首次使用需下载）。

本 issue 涉及的「绿色假阳性」共性清单

这一类问题在本仓库已经出现 5 次，模式完全一致：状态显示正常，功能实际是死的。

#	表面状态	实际情况
1	/semantic → ready: true	向量索引 0/346，嵌入器从未被配置
2	面板「测试连通性」→ 通过	maxTokens: 1024 + 一句提示词；空 reply 也算通过；与 dream 路径无关
3	dream_runs.status 静默记 ok	模型零有效决策被隐式 keep 补成 200 条（dreamMinExplicitCoverage: 0 时）
4	llm_audit_logs 有 435 行	input_tokens / output_tokens / cost_usd 全部为 0
5	记忆带 low_quality 标签、看似可审计	一次 memory_update 就把信号标签冲掉

建议给这五处各加一条"真实状态"断言或启动自检（例如启动时校验 embeddedCount > 0，否则明确警告），比逐个修更省事。

修复与验证

本机通过两个本地补丁验证（pnpm patch，合并进同一份 @modusensus__dsh-mneme@0.7.31.patch）：

1. 让失败可观测：!ok 分支改为 finish({ …, decisions: [{ _validationFailed: true, errors, skipped }] })，并把 skipped 明细的 warn 提到 return 之前。
2. 让前缀可解析：在 validateDecisions 入口把「唯一前缀」解析回完整 id（git 短哈希式）——仅在 snapshot 内解析，前缀有歧义或匹配不到则原样保留、仍由后续校验如实报 unknown id；就地改写 ids / keepSource / winner / loser，使下游 applyDecisions 也拿到完整 id。

修复后首轮（补丁需重启 dsh 生效；cordis.patch.yml 那类配置是 live 重载，插件源码不是）：

status   = degraded        （skipInvalid 语义：单条非法只跳过、合法子集照常应用）
applied  = 34
decisions= keep=103  merge=31  archive=2  conflict=1
outcome  = merge-archived: 62 · merge-keep: 31 · conflict-winner: 1 · conflict-archived: 1
库况      = 活跃 436 → 376（−60）／归档 566 → 634（+68）   ← 单轮

全库成功合并轮次复盘：

#	时间（北京）	status	applied	merge-archived
1	08-28 21:48	ok	6	6
2	09-10 20:39	reconcile	31	90
3	09-10 20:43	reconcile	35	65
4	09-12 00:52	reconcile	34	72
5	09-12 01:41	degraded	34	62

前 4 轮都发生在 deepseek-v4-flash 时代（那时模型回填完整 id），第 5 轮是首次在 deepseek-flash 上成功、也是首次由前缀解析解开的。

复现

1. dream 路由指向一个会缩写 id 的模型（本机 deepseek-flash）；
2. 记忆库涨到候选窗口 200 条、单轮输入 8 万字符量级；
3. 等 autoDream 触发，查 dream_runs：status='failed'、error='invalid decisions: 1 errors'、applied=0、decisions IS NULL；
4. 想看到真正的原因，需要先让失败路径落库（见上文补丁 1）——否则 skipped 明细不可得。

窗口口径（与 src/dream.js:600-612 一致）：活跃非 summary、按 updated_at 倒序取前 dreamMaxSnapshotSize 条。

建议（按优先级）

1. 校验器接受「唯一前缀」：在 validateDecisions 入口把短 id 解析回完整 id（git 短哈希式），歧义/无匹配才判 unknown id。这是本机解锁合并的决定性一步，且不改变任何用户可见语义。
   （替代方案：在 CONSOLIDATION_PROMPT 里明确要求「原样复制 36 位完整 id」，并把 few-shot 示例里的 "m1"/"m2" 换成真实 UUID —— 当前示例的短占位符很可能在诱导模型缩写。）
2. 失败路径必须落 decisions / skipped：把 validateDecisions 已经返回的逐条 {index, action, ids, error} 写进 dream_runs.decisions，并把那行 skipped warn 提到 return 之前。否则上百轮失败级的故障完全没有现场。
3. 把 dreamMaxTokens 的 schema 默认值从 32768 抬到 131072（或按输入长度自算预算）。[Bug] autoDream 在记忆量较大且路由为思考型模型时 100% 失败：no json array in llm output #9 只放开了 max，default 未动，等于把已修好的问题留给了默认配置。
4. dreamReasoningEffort 默认不应是 none：对"必须产出 JSON"的后台调用，默认发送该模型支持的最低档，而不是省略字段让 defaultEffort 顶上。
5. resolveDreamEffort 对 none 的短路（dream.js:392）应区分"用户显式选了 none"与"默认未配置"：前者尊重省略语义，后者取最低支持档。这是 v0.7.26 那处"defaultEffort 陷阱根治"真正生效的前提。
6. 修复 llm_audit_logs 的 token/cost 恒为 0（见附录 B）。这是定位本类问题唯一的量化面。
7. 可选：失败轮持久化原始 LLM 文本（或至少 raw length + 前 300 字节），现在只进不可达的日志。
8. memoryQualityFilter：让 importance 参与归档决策（≥4/≥5 只降权不归档，或归档时给出可见通知）；并让系统信号标签不被 update 覆盖。详见「附属发现」。
9. 向量层：让 /semantic 的 ready 反映索引覆盖度（embeddedCount / totalCount），并在嵌入器未配置（getVectorConfig() 为空）时至少记一条 info/warn。否则"从未配置"会让五个依赖向量的功能长期静默失效，而状态页一直是绿的。详见「附属发现 2」。
10. 可选（更强）：把「附属发现 2」里那张绿色假阳性清单做成启动自检 —— 状态页只在功能真能工作时才显示绿。

与既有 issue 的关系

• [Bug] autoDream 在记忆量较大且路由为思考型模型时 100% 失败：no json array in llm output #9（closed）：同一失败字符串与机制（no json array），已修方案 A/B。本 issue 是"修复在默认配置下不生效"的补充，并补上"换非思考模型只压低未消除"的实测。
• [Bug] dreamProvider/sleepProvider 配置不生效：resolveRoute 中 agentDefaultModel 绝对优先，config 路由成为死代码 #25（closed）：resolveRoute config-first 已修，本机路由确实按配置生效，不涉及。
• autoDream 的候选取样建议改为向量驱动，替代 updated_at 时间窗口（实测：45 对高相似候选 0 对能同时进窗口） #125（open）：候选窗口盲区。本 issue 不重复提交，仅作为第三层引用。
• autoDream 宽容路径补强（0.7.22 实测三发现）：coverage 误伤 / archive 类型越界 / 失败审计缺明细 #104（open）：宽容路径补强，已含「coverage 误伤」与「失败审计缺明细」。本 issue 的观测缺口一节与它同源、不重复主张；而「前缀不被接受」是新的一类——不是宽容度问题，而是 id 匹配方式问题，建议在 autoDream 宽容路径补强（0.7.22 实测三发现）：coverage 误伤 / archive 类型越界 / 失败审计缺明细 #104 之外单独处理。
• memory_delete 传截断 id 时静默空转，容易误以为删除成功（体验反馈） #48（closed）：memory_delete 传截断 id 时静默空转 —— 同一类「截断 id」问题，当时修的是 delete 路径；本 issue 报的是校验器路径（validateDecisions 只认整串）。建议统一处理（或在两处都做唯一前缀解析）。
• 弱模型（qwen3.8-flash）驱动 autoDream 时 invalid decisions 整单拒绝——建议恢复宽容路径或提供 dreamSkipInvalid #89（open）：弱模型下 invalid decisions 整单拒绝。本机那 22 轮同一错误串属同一族，但成因不同（这里是 id 格式，不是模型能力），故不重复主张。
• [Bug] autoDream 恒失败 (applied=0)：跨类型 merge 触发 fail-safe 整单拒绝 #26（closed）：跨类型 merge 触发 fail-safe 整单拒绝 —— 同属"一条不合格就整单作废"的家族，而本 issue 的前缀问题会放大它（78 个 id 全被判非法 → 必然整单拒绝）。
• autoSummarize 每个 turn/end 都触发且无产出上限——建议新增节流、条数上限与同会话主题抑制（实测单会话日铸 198 条） #127（open）：写入洪泛，是"重复不断产生"的上游放大器。
• autoReindexOnBoot 的模型指纹门 + needsEmbedding 未过滤归档行，导致部分记忆的 embedding 永久缺失 #128（open）：其附录 A 提到 /features 的 effective 优先于 cordis.patch.yml。补充实测：该"优先"只对下次启动成立（src/index.js:146 把 kv feature_flags 合到配置之上，而 index.js:129-130 注明只在下次启动生效）；本机 kv 里存着 "dreamProvider":""/"dreamModel":""，重启后会把 patch 里的路由静默清空、回落 agent 默认模型（已实测 POST /api/dsh-mneme/test-model 返回的 modelId 从 deepseek-v4-flash 变为 deepseek-flash）。建议 effective 区分 live / nextBoot 两个口径。

附录 A：生效配置

GET /api/dsh-mneme/features 的 effective（2026-09-11 实测）：

{
  "autoDream": true, "autoInject": true, "autoSummarize": true, "hotMemoryEnabled": true,
  "sleepModeEnabled": true, "heatEnabled": false, "conflictFreezeEnabled": false,
  "allowCrossTypeMerge": false, "dreamSkipInvalid": true, "llmAudit.enabled": true,
  "memoryQualityFilter.enabled": true,
  "dreamMinIntervalMinutes": 0, "dreamMaxTokens": 32768,
  "dreamProvider": "", "dreamModel": "",
  "distillMaxChars": 24000, "rerankEnabled": true, "searchSemanticDedup": true
}

另注：面板的「测试连通性」按钮不能代表巩固可用——它 maxTokens: 1024、提示词仅 Reply with exactly one word: ok，且只在流报错时返回 ok:false（空 reply 也算通过）。作者注释已点破机制（16 会被 reasoning 全部吃掉，reply 恒为空）：他们把测试按钮的预算 16→1024 修了，却没动 dream 那条路径。

附录 B：审计方法与库况

• 方法：把 memory.db + -wal + -shm 复制到临时目录后以只读方式打开，不触碰运行中的库，用 Python sqlite3 分析 dream_runs / llm_audit_logs / memories。
• 判定 keep 是模型输出还是代码补齐：取 dream_runs.decisions 的 id 序列与 dream_runs.input 快照的 id 序列（updated_at DESC）做尾对齐 —— 代码 decisions.js:183 补的 keep 严格按快照顺序、落在数组末尾。实测：真实合并轮只有尾部对齐（补 1/6/1/3 条），空转轮从头就对齐（整条 200 条都是补的）。另：200 × 64 + 199(逗号) + 2(括号) = 13,001，即那批 keep=200 的 decisions 长度是确定性代码产物，不能当作模型行为指标。
• 判定 unknown id 的性质：把被拒 id 分别与「窗口 id 集」「库中全表 id 集」比对，并额外做「窗口 id 前 8 位」匹配 —— 本机正是靠这一步把根因锁定到"8 位前缀"。
• 库况（2026-09-12 01:42）：总 1010 / 活跃 376 / 归档 634。
• llm_audit_logs 全部 435 行里（dream_consolidate 183 + summarize_compress 238 + dream_summarize 14），input_tokens / output_tokens / cost_usd 三项为 0 —— runAuditedLlm 的 reportUsage 从未拿到 usage，token 计量与成本核算完全失效（见建议 6）。

[aizhimoran]

附：本机验证用的补丁 + 一点说明

关于来源（先说清楚）：这份报告——包括根因定位、逐轮审计与这个补丁——是我与 AI 助手协作完成的。SQL 查询、日志核对、代码阅读都是在本机实机执行的真实结果，但分析与叙述由 AI 协助产出。仓库里有 agent-generated 标签，特此声明，以免来源被误判。

关于补丁：下面是本机让 autoDream 恢复正常所用的完整 pnpm patch（针对 @modusensus/dsh-mneme@0.7.31，12,446 字节 / 8 个文件）。它含 4 处改动，其中第 ① 处不属于本 issue（那是 #129 的 hot-memory 修复，之前已在本地应用）：

#	文件	对应	作用
①	lib/inject.js、src/inject.js	#129（非本 issue）	hot-memory 的 textOf 补上 data.message.content
②	lib/dream.js、src/dream.js	本 issue（与 #104 的「失败审计缺明细」同源）	失败路径把 {errors, skipped} 落进 dream_runs.decisions；并把 skipped 明细的 warn 提到 return 之前（原来写在 return 之后，永远不可达）
③	lib/dream/decisions.js、src/dream/decisions.js	本 issue 主因	validateDecisions 入口做「唯一前缀 → 完整 id」解析（git 短哈希式，仅在 snapshot 内；前缀歧义或匹配不到则原样保留，仍由后续校验如实报 unknown id），并就地改写 ids / keepSource / winner / loser，使下游 applyDecisions 也拿到完整 id
④	lib/service.js、src/service.js	报告里「附属发现 · 问题 2」	service.update 在调用方传入 tags 时，把 existing 里的系统信号标签（low_quality/duplicate/meta/repetitive/short_content）并集保留，而不是让它们被整组替换

本机实测效果（仅供参照）：应用 ②③④ 后 autoDream 连续三轮成功（degraded/reconcile/ok），merge-archived 累计 103 条，活跃记忆 436 → 346；在此之前 181 轮里 169 轮失败、只有 5 轮真正合并过。

这只是参考实现，不是正式提交 —— 写法、边界与取舍请以维护者的判断为准。若要我把某一部分拆成独立 PR，或提供更小的最小复现补丁，随时说。

diff --git a/lib/dream/decisions.js b/lib/dream/decisions.js
index ef581df20c412bcfea7940a37de2c95d44b0eb5f..9226001be7a6dcbfe1c4a164a8d9ae070fc2725e 100644
--- a/lib/dream/decisions.js
+++ b/lib/dream/decisions.js
@@ -35,6 +35,42 @@ export function validateDecisions(decisions, snapshot, options = {}) {
   if (decisions.length === 0) {
     return { ok: true, errors: [], skipped: [] };
   }
+  // [local patch] 模型常把 36 位 UUID 缩写成前 8 位（deepseek-flash 实测 78/78：提示词给的
+  // 是完整 id，回填却只剩前缀），而下面用 snapshot.get(id) 做整串精确匹配 → 全部判
+  // unknown id → claimed=0 → 覆盖率闸整单拒绝，一整轮的语义成果被白白丢掉。
+  // 这里在进入校验前把「唯一前缀」解析回完整 id（git 短哈希式）：只在 snapshot 内解析，
+  // 前缀有歧义或匹配不到就原样保留，仍由下面的 unknown id 校验如实报错。
+  let resolvedShortIds = 0;
+  const resolveShortId = (value) => {
+    if (typeof value !== "string") return value;
+    if (snapshot.has(value)) return value;                     // 已是完整 id
+    if (value.length < 8 || value.length >= 36) return value;  // 太短不猜；太长交给校验
+    let hit;
+    let matches = 0;
+    for (const id of snapshot.keys()) {
+      if (id.startsWith(value)) {
+        hit = id;
+        if (++matches > 1) return value;                       // 有歧义，不解析
+      }
+    }
+    if (matches === 1) {
+      resolvedShortIds++;
+      return hit;
+    }
+    return value;
+  };
+  for (const d of decisions) {
+    if (!d || typeof d !== "object") continue;
+    if (Array.isArray(d.ids)) d.ids = d.ids.map(resolveShortId);
+    if (typeof d.keepSource === "string") d.keepSource = resolveShortId(d.keepSource);
+    if (typeof d.winner === "string") d.winner = resolveShortId(d.winner);
+    if (typeof d.loser === "string") d.loser = resolveShortId(d.loser);
+  }
+  if (resolvedShortIds > 0) {
+    // 用 console 而非 ctx.logger：本机实测插件的 ctx.logger.warn 不上 stdout，
+    // 而 console.warn 可见——这行是判断「补丁是否真的起了作用」的唯一直接证据。
+    console.warn(`[dsh-mneme] validateDecisions: resolved ${resolvedShortIds} short id(s) to full ids`);
+  }
   const claimed = new Set();
   for (const [index, d] of decisions.entries()) {
     const at = `decision[${index}]`;
diff --git a/lib/dream.js b/lib/dream.js
index 72d6c616c42937edd58857748649c6e4948d1667..927b30bedaf177f92ef83ae8c68fb8224bc2a050 100644
--- a/lib/dream.js
+++ b/lib/dream.js
@@ -777,8 +777,19 @@ export function createDreamScheduler({ onRun, thresholdCount = 10, thresholdChar
       allowCrossTypeMerge: config.allowCrossTypeMerge === true
     });
     if (!ok) {
+      // [local patch] 失败路径原本既不落 decisions（finish 没传该字段），也到不了下面
+      // 那行 skipped warn（它写在 return 之后），导致「模型的输出为何逐条非法」既不落库
+      // 也不落日志、完全不可回溯。这里把校验明细落库，便于事后定位。
       logger?.warn?.(`dsh-mneme dream: invalid decisions: ${errors.join("; ")}`);
-      return finish({ ok: false, error: `invalid decisions: ${errors.length} errors`, summary: false });
+      if (skipped.length > 0) {
+        logger?.warn?.(`dsh-mneme dream: ${skipped.length} invalid decision(s) skipped: ${skipped.map((s) => `decision[${s.index}]: ${s.error}`).join("; ")}`);
+      }
+      return finish({
+        ok: false,
+        error: `invalid decisions: ${errors.length} errors`,
+        summary: false,
+        decisions: [{ _validationFailed: true, errors, skipped }]
+      });
     }
     const skippedInvalid = skipped.length > 0;
     if (skippedInvalid) {
diff --git a/lib/inject.js b/lib/inject.js
index c3dbfbea2eb777a324bd238a89548872dc37b53a..168800bd7385fd72bd5e5941af2d42fc8b63335a 100644
--- a/lib/inject.js
+++ b/lib/inject.js
@@ -43,7 +43,9 @@ function extractRounds(ctx, maxRounds) {
     const rounds = [];
     let pendingQuery = null;
     const textOf = (event) => {
-      const parts = event?.data?.content;
+      // [local patch] user/message 的正文就在 data 上，而 assistant/message 与 tool/result
+      // 嵌在 data.message 下。只读 data.content 会让每一轮的 A 恒为空（上游 issue #129）。
+      const parts = event?.data?.content ?? event?.data?.message?.content;
       if (!Array.isArray(parts)) return "";
       return parts
         .map((p) => (typeof p === "string" ? p : p?.text ?? ""))
diff --git a/lib/service.js b/lib/service.js
index eddec77b5e25e3c2900cc4d46e325d47ac0c4aee..0930cb61842530e85577b580caff770c7f4e39b2 100644
--- a/lib/service.js
+++ b/lib/service.js
@@ -1484,7 +1484,17 @@ export function createService({ store, mirror, config, onWrite, logger }) {
     },
     update: (id, p, ctx = {}) => {
       const old = store.getById(id);
-      const updated = store.update(id, p);
+      // [local patch] 质量过滤器把「为什么被归档」写在信号标签上（low_quality / duplicate /
+      // meta / repetitive / short_content，见 applyQualityDisposition 的并集写法）。而更新
+      // 路径把 tags 整组替换，于是任何带 tags 的 memory_update 都会抹掉这条唯一的审计线索
+      // ——实测：全库 150 条 score<30 中 148 条带 low_quality，缺的正是被 update 过的那 2 条，
+      // 并因此导致过"不是质量过滤器归档的"这类误判。这里把系统信号标签并集回去；用户自己
+      // 传的标签照常生效。
+      const SIGNAL_TAGS = ["low_quality", "duplicate", "meta", "repetitive", "short_content"];
+      const p2 = (p && Array.isArray(p.tags) && old && Array.isArray(old.tags))
+        ? { ...p, tags: [...new Set([...p.tags, ...old.tags.filter((t) => SIGNAL_TAGS.includes(t))])] }
+        : p;
+      const updated = store.update(id, p2);
       // Record a user correction when any meaningful field changed and the
       // reflection failure tracker is enabled. expected = what it became,
       // actual = what it was before; query (when provided) captures the
diff --git a/src/dream/decisions.js b/src/dream/decisions.js
index ef581df20c412bcfea7940a37de2c95d44b0eb5f..9226001be7a6dcbfe1c4a164a8d9ae070fc2725e 100644
--- a/src/dream/decisions.js
+++ b/src/dream/decisions.js
@@ -35,6 +35,42 @@ export function validateDecisions(decisions, snapshot, options = {}) {
   if (decisions.length === 0) {
     return { ok: true, errors: [], skipped: [] };
   }
+  // [local patch] 模型常把 36 位 UUID 缩写成前 8 位（deepseek-flash 实测 78/78：提示词给的
+  // 是完整 id，回填却只剩前缀），而下面用 snapshot.get(id) 做整串精确匹配 → 全部判
+  // unknown id → claimed=0 → 覆盖率闸整单拒绝，一整轮的语义成果被白白丢掉。
+  // 这里在进入校验前把「唯一前缀」解析回完整 id（git 短哈希式）：只在 snapshot 内解析，
+  // 前缀有歧义或匹配不到就原样保留，仍由下面的 unknown id 校验如实报错。
+  let resolvedShortIds = 0;
+  const resolveShortId = (value) => {
+    if (typeof value !== "string") return value;
+    if (snapshot.has(value)) return value;                     // 已是完整 id
+    if (value.length < 8 || value.length >= 36) return value;  // 太短不猜；太长交给校验
+    let hit;
+    let matches = 0;
+    for (const id of snapshot.keys()) {
+      if (id.startsWith(value)) {
+        hit = id;
+        if (++matches > 1) return value;                       // 有歧义，不解析
+      }
+    }
+    if (matches === 1) {
+      resolvedShortIds++;
+      return hit;
+    }
+    return value;
+  };
+  for (const d of decisions) {
+    if (!d || typeof d !== "object") continue;
+    if (Array.isArray(d.ids)) d.ids = d.ids.map(resolveShortId);
+    if (typeof d.keepSource === "string") d.keepSource = resolveShortId(d.keepSource);
+    if (typeof d.winner === "string") d.winner = resolveShortId(d.winner);
+    if (typeof d.loser === "string") d.loser = resolveShortId(d.loser);
+  }
+  if (resolvedShortIds > 0) {
+    // 用 console 而非 ctx.logger：本机实测插件的 ctx.logger.warn 不上 stdout，
+    // 而 console.warn 可见——这行是判断「补丁是否真的起了作用」的唯一直接证据。
+    console.warn(`[dsh-mneme] validateDecisions: resolved ${resolvedShortIds} short id(s) to full ids`);
+  }
   const claimed = new Set();
   for (const [index, d] of decisions.entries()) {
     const at = `decision[${index}]`;
diff --git a/src/dream.js b/src/dream.js
index 72d6c616c42937edd58857748649c6e4948d1667..927b30bedaf177f92ef83ae8c68fb8224bc2a050 100644
--- a/src/dream.js
+++ b/src/dream.js
@@ -777,8 +777,19 @@ export function createDreamScheduler({ onRun, thresholdCount = 10, thresholdChar
       allowCrossTypeMerge: config.allowCrossTypeMerge === true
     });
     if (!ok) {
+      // [local patch] 失败路径原本既不落 decisions（finish 没传该字段），也到不了下面
+      // 那行 skipped warn（它写在 return 之后），导致「模型的输出为何逐条非法」既不落库
+      // 也不落日志、完全不可回溯。这里把校验明细落库，便于事后定位。
       logger?.warn?.(`dsh-mneme dream: invalid decisions: ${errors.join("; ")}`);
-      return finish({ ok: false, error: `invalid decisions: ${errors.length} errors`, summary: false });
+      if (skipped.length > 0) {
+        logger?.warn?.(`dsh-mneme dream: ${skipped.length} invalid decision(s) skipped: ${skipped.map((s) => `decision[${s.index}]: ${s.error}`).join("; ")}`);
+      }
+      return finish({
+        ok: false,
+        error: `invalid decisions: ${errors.length} errors`,
+        summary: false,
+        decisions: [{ _validationFailed: true, errors, skipped }]
+      });
     }
     const skippedInvalid = skipped.length > 0;
     if (skippedInvalid) {
diff --git a/src/inject.js b/src/inject.js
index c3dbfbea2eb777a324bd238a89548872dc37b53a..168800bd7385fd72bd5e5941af2d42fc8b63335a 100644
--- a/src/inject.js
+++ b/src/inject.js
@@ -43,7 +43,9 @@ function extractRounds(ctx, maxRounds) {
     const rounds = [];
     let pendingQuery = null;
     const textOf = (event) => {
-      const parts = event?.data?.content;
+      // [local patch] user/message 的正文就在 data 上，而 assistant/message 与 tool/result
+      // 嵌在 data.message 下。只读 data.content 会让每一轮的 A 恒为空（上游 issue #129）。
+      const parts = event?.data?.content ?? event?.data?.message?.content;
       if (!Array.isArray(parts)) return "";
       return parts
         .map((p) => (typeof p === "string" ? p : p?.text ?? ""))
diff --git a/src/service.js b/src/service.js
index eddec77b5e25e3c2900cc4d46e325d47ac0c4aee..0930cb61842530e85577b580caff770c7f4e39b2 100644
--- a/src/service.js
+++ b/src/service.js
@@ -1484,7 +1484,17 @@ export function createService({ store, mirror, config, onWrite, logger }) {
     },
     update: (id, p, ctx = {}) => {
       const old = store.getById(id);
-      const updated = store.update(id, p);
+      // [local patch] 质量过滤器把「为什么被归档」写在信号标签上（low_quality / duplicate /
+      // meta / repetitive / short_content，见 applyQualityDisposition 的并集写法）。而更新
+      // 路径把 tags 整组替换，于是任何带 tags 的 memory_update 都会抹掉这条唯一的审计线索
+      // ——实测：全库 150 条 score<30 中 148 条带 low_quality，缺的正是被 update 过的那 2 条，
+      // 并因此导致过"不是质量过滤器归档的"这类误判。这里把系统信号标签并集回去；用户自己
+      // 传的标签照常生效。
+      const SIGNAL_TAGS = ["low_quality", "duplicate", "meta", "repetitive", "short_content"];
+      const p2 = (p && Array.isArray(p.tags) && old && Array.isArray(old.tags))
+        ? { ...p, tags: [...new Set([...p.tags, ...old.tags.filter((t) => SIGNAL_TAGS.includes(t))])] }
+        : p;
+      const updated = store.update(id, p2);
       // Record a user correction when any meaningful field changed and the
       // reflection failure tracker is enabled. expected = what it became,
       // actual = what it was before; query (when provided) captures the

[modusensus]

感谢这份高质量的报告——181 轮的全量审计、三向归类锁定 8 位前缀、尾对齐判定 keep 来源、只读副本不打扰运行库，这套实证方法非常扎实。我们已把核心断言逐条对照当前 main 的代码核实，全部成立，两条缺陷的定位和修复建议我们都认可：

核实结果：

1. 主缺陷成立：validateDecisions 用 snapshot.get(id) 整串匹配（src/dream/decisions.js:104），未命中即 unknown id，覆盖率闸（decisions.js:179-181）整单拒绝。你补丁里的「唯一前缀解析」（git 短哈希式、仅在 snapshot 内解析、歧义不猜、匹配不到仍如实报错）方向我们认可，会按这个语义落地；同时采纳你的替代建议——把 CONSOLIDATION_PROMPT few-shot 示例里的 "m1"/"m2" 短占位符换成真实 UUID 形态（已确认这个诱导确实存在，src/lang.js），两手一起修。
2. 次缺陷成立：resolveDreamEffort 对 none 的短路（src/dream.js:347）+ dreamMaxTokens schema 默认 32768（src/config.js:71，[Bug] autoDream 在记忆量较大且路由为思考型模型时 100% 失败：no json array in llm output #9 只抬了 max 没抬 default），默认配置对思考型模型确实不生效。建议 3/4/5 全部采纳：抬 default、区分「用户显式选 none」与「未配置」、对必须产出 JSON 的后台调用默认取最低支持档。
3. 观测缺口基本成立：invalid-decisions 失败路径（src/dream.js:735-738）至今仍不落 decisions/skipped 明细，建议 2 采纳。一点补充：no-json 路径在 main 上已部分加固（记 raw length + 前 300 字节 head，v0.8.1 批次）——你的报告基于 0.7.31，这条已解决一半；明细落库与 skipped warn 仍缺，按你的建议并入 autoDream 宽容路径补强（0.7.22 实测三发现）：coverage 误伤 / archive 类型越界 / 失败审计缺明细 #104 一并处理。
4. 附属发现同样确认：applyQualityDisposition 确实不看 importance（src/service.js:967-983）；service.update 直传 patch、信号标签被整组替换（src/service.js:1493-1495），并集保留的补丁思路会采纳；/semantic 的 ready 目前只反映 embedder 就绪而非索引覆盖度，会按建议 9 结合 embeddedCount/totalCount 计算，并在嵌入器未配置时记日志。审计 token/cost 恒 0 的机制也确认（流式 usage chunk 缺失，与我们 v0.7.15 时代对 volcano 的观察一致），列入 autoDream 宽容路径补强（0.7.22 实测三发现）：coverage 误伤 / archive 类型越界 / 失败审计缺明细 #104 的观测面。

「绿色假阳性」这张清单是整份报告里最有价值的总结之一——状态显示正常、功能实际是死的这个模式在仓库里反复出现，启动自检的方向我们认同，会作为独立事项排进 v0.8。

也感谢你把与 #9/#25/#48/#89/#104/#125/#127/#128 的关系梳理清楚，处理顺序因此清晰了很多。落地顺序初步为：前缀解析 + 失败落库 → 预算/档位默认值 → ready 语义与未配置告警 → 质量标签保留与 importance 参与，进展在本 issue 同步；若你想把某一块拆成独立 PR，也随时欢迎（#129 那个 PR 的质量我们有目共睹 🙂）。

---

TL;DR: All core findings verified against the codebase — the short-id vs exact-match validator conflict, the effort/token default trap, the missing failure-path audit, the quality-signal tag overwrite, and the silent vector-layer absence. The proposed fixes are accepted and will land in order; the no-json head-logging part is already partially hardened on main. Outstanding report — thank you.

[modusensus]

跟进一下分工，避免撞车：按上一条的落地顺序，**前缀唯一解析 + 失败路径落库（建议 1/2）以及预算/档位默认值（建议 3/4/5）**这三块我们正在动手修，会配测试跟进；解析语义就按你补丁的思路来（仅在 snapshot 内、唯一才解析、歧义不猜、匹配不到仍如实报 unknown id），参考实现会注明出处。

剩下两块相对独立，想留给你：ready 语义与未配置告警（建议 9）、质量标签保留 + importance 参与归档（附属发现两问）——如果你想拆 PR 欢迎认领其中一块；为避免重复劳动，动工前请在本 issue 说一声认领哪块。当然，什么都不领也完全没问题，我们会兜底。

[aizhimoran]

认领：① ready 语义与未配置告警（建议 9）

感谢逐条核实。我们认领建议 9；按你们的要求先报一声避免撞车，同时把拟定的语义写出来，如果口径不同我按你们的改。

动手前先把现有契约摸了一遍 —— 有两处坑，所以我没有直接按「ready = 覆盖率 > 0」改

1. src/api.js:611 的判据其实是三层：无 embedder → null；embedder 带 ready 属性（Local / Ollama）→ 透传；不带该属性（legacy OpenAI 兼容 embedder，对象字面量）→ 恒为 true。本机那个绿色假阳性正是第三层：getVectorConfig() 四字段全空、1035/1035 无向量，而 ready 报 true。
2. test/api.test.js:451-470 已固化了这套契约（含 {embed(){}} → true 的用例）；而 lib/client.js:2617 又把 ready !== true 当作"初始化中"来展示。若直接把 ready 改成"覆盖率 > 0"，那么一个刚建、还没有任何记忆的空库（totalCount = 0）会永远显示"初始化中" —— 这是我不想引入的回归。

拟定方案（欢迎纠正）

• ready 语义不动（仍是"嵌入器可用"），但修掉第三层的假阳性：给 legacy OpenAI 兼容 embedder 加 get ready()，判据是 getVectorConfig() 四要素齐备（enabled && baseUrl && apiKey && model）。这样 api.js:611 的通用分支自动生效 —— 不改判据，也不动既有断言。
• /semantic 新增向后兼容字段，把"为什么不可用"显式化：
  • configured：true | false | null（null = 没有 embedder）
  • reason：null | "no-embedder" | "not-configured" | "initializing"
  • coverage：{ embedded, total, ratio }（total === 0 时 ratio 为 null，表示"空库，不适用"）
  • degraded：configured && total > 0 && embedded === 0 —— 即"配了、也有数据，却一条都没索引上"。这一档正是本机情况的可观测化（有配置而无索引），也是单纯看 ready 永远看不出来的那一种。
• 未配置时启动记一次 ctx.logger.warn，内容点明受影响的功能：语义召回 / searchSemanticDedup / rerank / sleep 冲突检测 / dream 语义聚类（会退化为全量窗口兜底）。

验证条件

本机正好是"未配置"的现场（vector-config 四字段全空、embeddedCount 0 / totalCount 346），所以可以端到端验：改后 /semantic 应报 ready=false / configured=false / reason="not-configured"，启动日志出现那条 warn；接上真实 embedder 后应回到 ready=true，degraded 随索引建立转 false。测试按 test/api.test.js 的现有风格补，不改既有用例的断言。

同步一件事

我们本地那份 pnpm 补丁里，①（#129 的 hot-memory 修复）已随 PR #136 合进 main，但 npm latest 仍是 0.7.31，所以本地暂时仍挂着该补丁。等含这些修复的版本发布后，我们会按 gate_scan → 快照+备份 → 升级 → 验证 的流程升级，并摘掉补丁里已被上游覆盖的部分。

[modusensus]

方案照准，按你的拟法实施 👍

两处坑拦得都对，尤其是第二个——「ready 改成覆盖率」会让空库永远显示「初始化中」这种回归，正是修假阳性时最不想引入的新假阴性。get ready() 的修法我们认可：判据（getVectorConfig() 四要素齐备）语义清晰，api.js 的通用分支自动生效，不动既有方言，test/api.test.js 的既有契约也不用改。

/semantic 新增字段的设计（configured / reason / coverage / degraded）没有异议：degraded 这一档（配了、有数据、却 0 条索引）恰好把 #135「绿色假阳性」里最难察觉的那一类状态显式化了；启动 warn 点明受影响功能也照你列的五项写。唯一小提醒：lib/client.js 的状态卡记得把新字段接上（比如 degraded / configured=false 时给出明确的说明文案，而不只是 ready 翻转），Web 用户才能真正看到「为什么不可用」。

进度同步：

• 建议 1/2（前缀唯一解析 + 失败落库）已在 PR fix(dream): 决策前缀唯一解析 + 失败路径校验明细落库（issue #135） #137；
• 建议 3/4/5（dreamMaxTokens 默认抬至 131072 + effort 未配置自动取模型最低档）已在 PR fix(dream): effort 未配置自动最低档 + dreamMaxTokens 默认抬至 131072（issue #135） #138（stacked on fix(dream): 决策前缀唯一解析 + 失败路径校验明细落库（issue #135） #137，与你的建议 9 文件面零重叠）；
• 附属发现两问（质量信号标签并集保留 + importance 参与归档）归我们兜底，前两个 PR 合并后开第三批；
• 两批合并后云侧安排发版，npm latest 更新后你就可以走 gate_scan → 快照+备份 → 升级 → 验证 摘补丁了。

期待你的 PR——按你的验证条件（本机未配置现场端到端）跑通后直接提，我们随时审。