@deepseek-ai/dsh-llm typert codec incomplete + web profile 缺 service-provider bundle

[SilenZerOrz]

现象

dsh web（web profile）启动时，@deepseek-ai/dsh-llm 无法注册其 typert manifest：

typert-loader: @deepseek-ai/dsh-llm invocation "@deepseek-ai/dsh-llm#llm/discoverModels"
parameter codec has no create() factory
Error: typert-loader: @deepseek-ai/dsh-llm invocation "@deepseek-ai/dsh-llm#llm/discoverModels" parameter codec has no create() factory
    at requireStrictCodec (.../dsh-typert-loader/lib/index.js:211:48)
    at requireInvocation (.../dsh-typert-loader/lib/index.js:185:3)

影响

In-process cordis consumer（如 @deepseek-ai/dsh-acp 的 apply(ctx, ...)）拿不到 llm / sessionPersistence / agents / sessions 四个核心 service。

实测 probeOfficialBridge(ctx) 返回：

{
  "importable": true,
  "servicesReady": false,
  "envSwitchOn": true,
  "missingServices": ["llm", "sessionPersistence", "agents", "sessions"],
  "applySignature": "2"
}

web profile 的 dependencies 不含 @deepseek-ai/dsh-llm / dsh-session / dsh-agent 等 service-provider 包（即使装了也因 typert codec 失败）。

复现

1. dsh web --no-open（web profile）
2. 启动日志出现上述 typert-loader 错误
3. probeOfficialBridge(ctx) → servicesReady: false

请求

1. 修复 @deepseek-ai/dsh-llm 的 typert manifest（llm/discoverModels 参数 codec 缺 create() factory）
2. 确保 dsh web 的 web profile 加载 service-provider bundles（llm / agents / sessions / sessionPersistence）

环境

• macOS 26 (Apple Silicon)
• @deepseek-ai/dsh 0.1.6-alpha.1（npm-global）
• @deepseek-ai/dsh-llm 0.1.6-alpha.1

[SilenZerOrz]

Update 2026-09-25: retested with dsh 0.1.7-rc.1.

Partial fix confirmed:

• typert codec now complete (no more "codec has no create() factory")
• dsh-llm / dsh-agent / dsh-acp now bundled in web profile
• HTTP gateway now registers successfully (was 401)

Still broken:

• cordis ctx in dsh web profile still missing 4 services: llm, sessionPersistence, agents, sessions
• probeOfficialBridge(ctx).servicesReady === false
• apply() returns 0 frames for in-process consumers

Root cause narrowed: packages are bundled, but no cordis-plugin provides these services to the ctx. Need a provider registration step in web profile startup.

Repro: install obsidian-dsh-acp@0.3.0-rc.1 in dsh web profile, enable DSH_ACP_USE_OFFICIAL_BRIDGE=1, send any prompt -> adapter falls back to legacy spawn.

[SilenZerOrz]

Follow-up: additional class of missing tool_call frames.

When prompt is plan-style (e.g., "check if X has been updated in the docs"), some models (tested: jl-token / DeepSeek-V4-Flash) emit tool-call intent as raw text markup instead of structured tool_call:

• DSML form: <｜DSML｜｜DSML｜｜DSML｜tools_call>...
• XML form: <read_file><path>...</path></read_file>

Session JSON evidence (Obsidian Agent Client): role: assistant, content: [{type:"text", text:"...raw markup..."}]. dsh runtime does not detect these as tool_call, so ACP consumers receive text with embedded markup. UI clients (Obsidian agent-client) correctly render it as text, but the user sees raw tool-call syntax instead of a tool-call card.

Both markup formats observed in the same session — model behaviour is inconsistent between turns. The DSML form repeats the markup block twice in one response, suggesting model confusion or fallback path.

Repro:

1. dsh web running + any ACP client (Obsidian Agent Client tested)
2. Send plan-style prompt that intends a tool call (e.g., "check if X has been updated in the docs" + autoMentionContext)
3. Model emits raw DSML / XML markup in text instead of structured tool_call

Workaround until upstream fix: reword to direct-task prompts ("read file X") which the model handles cleanly via structured tool_call.

Ask: add a raw tool-call markup detector in dsh runtime that recognizes DSML / XML tool-call shapes in text output and converts them to structured tool_call events.