Repository navigation
v0.1.46 — DSH 0.2.0-rc.2 compatibility
Compatibility
- Verified DSH
0.2.0-rc.2using an isolated, hoisted tarball Profile, actual visual-tool calls, and Web Settings. Add an exact peer/compatibility declaration and a required CI Profile lane for this release. The fixture explicitly selects its OpenAI-compatible protocol after the host's default provider protocol changed. - 已通过 DSH
0.2.0-rc.2隔离压缩包 Profile、真实视觉工具调用及 Web 设置验收;增加确切兼容声明及 CI 验收矩阵。官方默认协议变更后,测试 fixture 显式选择原有 OpenAI 协议。核实时官方尚无正式稳定版。
Added
-
Added an explicit OpenAI Responses protocol for custom vision providers. An optional, constrained
reasoningEffortis forwarded only for Responses requests, exposed conditionally in bilingual Settings, and included in both live-Session and durable evidence cache identities. Existing OpenAI configurations remain on Chat Completions and omit effort by default. -
Added hardened
provider.headersfor non-secret deployment metadata andprovider.sessionHeadersfor gateways such as OpenCode Zen that require per-session routing. Session values are process-keyed HMAC identifiers that never expose raw Session ids or workspace paths; configured headers are bounded, conflict-checked, error-redacted, cache-isolated, restricted to the provider origin/base path, and shared by both requests in a connection-and-model health operation. The manifest-verified vendored snapshot remains unchanged (#144).
Fixed
- Restored startup and live Settings on DSH 0.1.7, whose Config projection replaced the old
settings.register/get/watchAPI. The plugin now uses the host's matching Schema form, unwraps live configuration values for runtime use, and follows Settings document updates. Earlier DSH versions continue using their registration API. - Vision API subprocesses now try IPv4 addresses before IPv6 when both are returned by DNS. This avoids exhausting the connection timeout on unusable fake IPv6 addresses in TUN proxies while preserving IPv6-only endpoints.
- Stopped the image-input variant route from crashing on request messages that carry no
source. The variant readmessage.source.kindwhile assembling the evidence pass, but the officialcreateUserMessage()helper writes nosourceat runtime (its published type still declares one as required), so a plugin that built a programmaticctx.llm.stream()call on avision-toolkit-*route — the usual summarize, title, or classify pattern (@modusensus/dsh-mneme≤ 0.8.1 did exactly this) — failed withTypeError: Cannot read properties of undefined (reading 'kind'), which the host surfaced only as a genericUNKNOWNfailure chunk. A user message without provenance is now treated as a user turn, and assistant history without provenance is skipped instead of throwing; messages that do carry a source behave exactly as before.
Documentation
- Documented
/responsesendpoint composition, common and provider-specific effort values, possible token/latency/cost effects, and the need to review provider data-retention policy even though requests sendstore: false.
Verified host: DSH 0.2.0-rc.2. No official stable DSH version was available at verification time.