dsh-hindsight-memory 在 DSH ≥ 0.2.0-rc.2 (Session V4) 下报 format v4 message requires a producer-owned source kind

[wanwan2qq]

环境

• @deepseek-ai/dsh-*：0.2.0-rc.2（任何启用 Session V4 的版本都受影响）
• dsh-hindsight-memory：0.1.1
• profile：web（也应该影响 headless / desktop）

复现步骤

1. 在 cordis 配置里启用 dsh-hindsight-memory（autoRecall: true）
2. 启动 dsh（pnpm dsh web）
3. 在客户端发一条普通消息（任意文本）
4. 当前轮被丢弃；UI 显示「本轮运行失败 format v4 message requires a producer-owned source kind」

观察到的错误

UI 直接显示底层错误文本：

本轮运行失败
format v4 message requires a producer-owned source kind

session 日志末尾会出现：

seq N-1   agent/inbox/spliced   inserted=[{role:"user", source:{kind:"user", ...}}]
seq N     turn/start            {turn: K}
seq N+1   agent/inbox/spliced   start:0, removedCount:1, inserted:[]
 ^^^^^^^^^^^^^^^^^^^^^
                                          claim 之后无 step/start / assistant/message

removedCount:1, inserted:[] 之后没有任何 step事件，说明 recall 块进入 preStep waterfall 后被拦下。

根因

lib/index.js 的 agent/pre-step 监听器在 recall 命中时构造的 user message：

createUserMessage({
  content: [{ type: "text", text }],
  source: {
    kind: "plugin",                ← 字面量 "plugin"
    plugin: name,                  // "hindsight-memory"
    form: "snapshot",
    sections: [{ name, text }]
  }
})

kind: "plugin" 是 V3 时代的语法。V4 把 kind: "plugin" 升级为「producer-owned」归属模型，要求 kind 是具体产方名（白名单如 tmux-context / time-context / session-reference 等，或 plugin: 形式）。

packages/session/session-format-v3-to-v4/src/message-sources.ts:9 的 source() 检查：

if (... || value['kind'] === 'plugin') {
  throw new SessionFormatError('format v4 message requires a producer-owned source kind')
}

由于 recall 块通过 prepend: true 排在 waterfall 最前，一旦被构造就会被 assistant/call / tool/result 写日志的 admission gate（assertV4SourceRowAdmission）拦下，导致整轮失败。

参考对比：

• Hindsight dist plugin 之前也是同一模式，已修（kind: "plugin:" + HINDSIGHT_PLUGIN）
• packages/context/tmux-context/src/index.ts 用 kind: name（即 "tmux-context"）
• packages/context/session-reference/src/index.ts 用 kind: "session-reference"
• packages/session/session-format-v3-to-v4/src/sources.ts:64 的 producerKind() fallback 给出标准形式 plugin:${plugin}

最小修复

lib/index.js 第 338 行（一行）：

 source: {
-    kind: "plugin",
+    kind: "plugin:" + name,
     plugin: name,
     form: "snapshot",
     sections: [{ name, text }]
 }

修完后 recall 块用 plugin:hindsight-memory 作为 source kind，符合 V4 admission。已在我本地验证：line 338 改完后（node_modules 内的临时修复），重启 dsh，新一轮 step 1 正常进入 model call，无 admission error。

建议永久修复

考虑到 lib 是 build 产物，建议：

1. 上游在 src 层把 kind 显式化为 plugin:${name}（即 plugin:hindsight-memory），跟 packages/session/session-format-v3-to-v4/src/sources.ts:64 的 producerKind() fallback 一致
2. 升级 dsh-hindsight-memory 到 ≥ 0.1.2
3. 在 README 里加一段：「DSH 0.2.0 起 session format V4 强制 producer-owned source kind，本插件自 0.1.2 起适配」

用户侧临时 workaround（如果等不及 release）

# 在 cordis 把插件指向本地打过补丁的文件副本
# 或者直接 sed：
sed -i.bak 's|kind: "plugin",$|kind: "plugin:" + name,|' \
  ~/.dsh/profiles/web/node_modules/dsh-hindsight-memory/lib/index.js
# 重启 dsh daemon
launchctl kickstart -k gui/$(id -u)/com.claw.dsh-web   # macOS + LaunchAgent 场景

pnpm install 之后记得重打。

[slyyr]

The error suggests that Session V4 is validating message provenance more strictly than the memory plugin currently expects.

Since the failure happens when dsh-hindsight-memory is enabled and the normal message is otherwise valid, I’d inspect the message that the plugin injects during autoRecall.

The important question is whether the plugin creates a new message/source object without assigning a source kind owned by the producer.

I’d compare:

1. a normal user/assistant message produced by DSH,
2. the message generated by dsh-hindsight-memory,
3. the serialized Session V4 representation of both.

If the plugin is constructing a synthetic message, it likely needs to use the Session V4 API for creating producer-owned content rather than manually constructing an object that happens to look like a message.

I would avoid simply disabling the V4 validation because that could hide malformed session data.

A good regression test would enable autoRecall, send a normal message, and verify that the resulting memory-injected content passes Session V4 validation and survives session serialization/reload.

If this clears up the issue, please consider marking the answer as accepted so others who run into the same problem can find the solution more easily.

[argszero]

Thanks for the write-up — the diagnosis is right, and the one-line fix is the right one. Two
corrections to the mechanism, and one thing the write path still cannot tell you.

The admission is not a whitelist

plugin:<name> is not a form the check accepts "in addition to" a set of known producers. There is no
producer registry on the admission path at all. source() in
packages/session/session-format-v3-to-v4/src/message-sources.ts:9 refuses exactly four things:

if (!isSessionFormatJsonObject(value) || typeof value['kind'] !== 'string'
  || value['kind'].length === 0 || value['kind'] === 'plugin') {
  throw new SessionFormatError('format v4 message requires a producer-owned source kind')
}

So: not an object, kind not a string, kind empty, or kind the literal 'plugin'. Any other
non-empty string is admitted — hindsight-memory, plugin:hindsight-memory, tmux-context and
nonsense all pass equally. That is deliberate and it is why a third-party plugin never has to
register its identity anywhere.

The list you are thinking of is real, but it lives on a different path. RENAMED_PRODUCERS and
RELEASED_SAME_NAME_PRODUCERS (sources.ts:39 and :48) are read only by producerKind
(sources.ts:59) during the V3→V4 migration rewrite, and assertV4SourceRowAdmission never
touches them. producerKind returns plugin:${plugin} as its fallback for a name the harness did
not release — sources.ts:64. That is why plugin:<name> is the value to write: it is what the
harness's own rewriter derives for your message, so a log written now and a log migrated later are
byte-identical. It is not a requirement of the admission; it is agreement with the migration.

Worth knowing, since it changes what "correct" means for a first-party-looking name: for a name in
RELEASED_SAME_NAME_PRODUCERS the rewriter's answer is the bare name, because that is what those
producers already emit. For a plugin like yours the fallback applies, so plugin:hindsight-memory is
exactly what the rewriter would produce.

Which check actually refuses you, and why its message is empty

You are right that it is the row gate, but the two source checks are not the same one. codec.ts
runs assertV4RowAdmission on the way to storage, and its source re-check
(assertV4SourceRowAdmission, message-sources.ts:29) walks a fixed table:

user/message                                       → [data]
system/message | assistant/message | tool/result    → [data.message]
agent/inbox/spliced                                → data.inserted
session/title-llm-request                          → data.messages

and re-checks a message only when value['kind'] === 'plugin' — its own comment says so: "refuse
retired source syntax even after a malformed recoverable row".

Two consequences. Your recall block arrives as agent/inbox/spliced.inserted[], which is in that
table, so the row gate fires there. And the sibling check on the adoption path,
assertV4MessageSources, covers one slot the row table does not — developer/message — while being
stricter in another way: it requires a non-empty producer kind on every declared slot, not only on
the retired literal. Same rule, two walks, two sentences. A developer/message with a retired source
is refused by that event's own row validator instead, with a message that also names id, role and
content.

That is also why the sentence you saw names nothing: it is raised while decoding a physical row, and
a row has no event type, no sequence and no plugin to name. Nothing after it was parsed, so a reader
that hits it cannot locate the offending message, and nothing before it identifies the writer. The
sed you posted is the only way to bisect it from the outside — which is the gap worth closing.

A plugin that closes the attribution gap

I published @argszero/cordis-plugin-session-event-guard@0.2.0 for this:
https://www.npmjs.com/package/@argszero/cordis-plugin-session-event-guard

It observes the committed event on session/event — before the durable write reaches the row gate —
so it can name what the gate cannot. For a message like yours it logs and reports:

session-event-guard: session "<id>" committed agent/inbox/spliced at seq N slot data.inserted[0]
written by plugin "hindsight-memory" whose `source.kind` is "plugin" (kind-retired). ...
Write {"kind":"plugin:hindsight-memory","form":"snapshot","sections":[...]} instead.

with event type + seq + payload slot + producer + the exact replacement, and it also exposes
session_event_guard({ source: '{"kind":"plugin","plugin":"x"}' }) to judge a source before anything
carries it. The slot table it walks mirrors mapEventMessages, and the suite measures that mirror
against the real assertV4RowAdmission for every slot, so it cannot drift silently.

Two honest limits, since they bound what the plugin is worth to you: it does not rewrite anything —
the replacement is a value it hands you, because the in-memory event is deepFreezed and a plugin
that silently fixed the persisted copy would leave the process holding kind: "plugin" while the
file holds plugin:hindsight-memory, which is a worse bug than the one it hides. And it observes
Session.append writes; the handle seam throws synchronously on its own, so it does not need the
observer.

On the fix

Your minimal fix is correct as written. Point 1 of the permanent fix — canonicalising kind in
src rather than patching lib, so a pnpm install does not undo it — is the one that matters;
sed-ing lib is fine as a stopgap but a rebuild quietly reverts it. I would add to your README
suggestion: say why the value is plugin:${name} (agreement with producerKind's fallback, so
migrated and freshly-written logs match), not just that the string is required — that is the part
that is easy to get wrong the next time a message is constructed.