chore(dsh): pin the managed dsh host to the latest released SDK

[huangruiteng]

What

Pins the managed dsh host to the newest released dsh channel:

• PyPI deepseek-harness-sdk==0.1.5rc1, which pulls its bundled
  deepseek-harness-runtime-bin==0.1.5rc1.
• npm @deepseek-ai/dsh publishes the same release train as latest
  (0.1.5-rc.1); newer next / alpha tags exist upstream but are not the
  released channel.

Previously pinned: 0.1.2a3 (2026-09-01).

Why

LoopX now binds the default Turn and steward host to dsh when an operator
credential is configured (#4409, #4416). The runtime behind that default should
be the current released dsh, not a two-week-old pin.

Surface diff

The SDK's Python client is byte-identical between 0.1.2a3 and 0.1.5rc1: a
wheel diff shows only dist-info metadata changed. What moves is the bundled
self-contained dsh runtime. LoopX passes no profile, so it runs the SDK's
default sdk profile unless the operator supplies --cordis; the upstream
sdk-minimal profile change in this release therefore does not affect the
managed host path.

Validation

Hermetic runs against a local mock OpenAI-compatible endpoint: no provider
call, no API key, no Codex subscription use.

check	0.1.2a3 (control)	0.1.5rc1
examples/loopx-turn-dsh-real-e2e-smoke.py --host generic-cli	passed	passed
examples/loopx-turn-dsh-real-e2e-smoke.py --host dsh	passed	passed
tests/test_dsh_goal_mode.py	—	55 passed
examples/dsh-turn-host-adapter-smoke.py	—	11 checks passed
examples/loopx-turn-dsh-e2e-smoke.py	—	passed
examples/loopx-turn-dsh-builtin-host-e2e-smoke.py	—	passed

The candidate release was installed into a throwaway target directory with
uv pip install --target ... --no-deps and injected on PYTHONPATH (the shared
dev environment already provides pydantic 2.13.4, above the release's
>=2.12 floor), so the previous pin stayed untouched during the comparison.

Upstream gap carried forward

The stock headless profile still cannot boot from the bundled snapshot at
0.1.5rc1: @deepseek-ai/dsh-session-title-first-prompt-llm imports the
missing @deepseek-ai/dsh-session-title-llm from inside the packaged snapshot.
The default sdk profile boots and exits cleanly, so this stays a recorded
upstream gap rather than a blocker for the managed host. The RFC records the
current revision.

Follow-on

The related managed/steward PRs are rebased on this branch so the stack carries
the pin: #4400 (RFC version references), #4409, #4416, #4417, #4419.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

详细中文评审

审查对象：39539a7d06f97b7809872e7f2576732ec52a3447（chore(dsh): pin the managed dsh host to the latest released SDK，base main，3 文件 +11/-3）。执行契约 policy_revision=3；结果 JSON 已通过 pr-review --check-result（approval_consistent: true）。

动机

托管宿主依赖的 dsh 运行时 pin 落后于上游已发布渠道（main 停在 0.1.2a3）。pin 落后会让「按文档安装」与「RFC 记录的运行时」不一致，而 dsh 侧插件与 Turn 宿主的版本差会继续扩大。

改动思路

只改一处权威（pyproject.toml 的 deepseek-harness extra），并在两处文档写明渠道语义：跟随已发布渠道，而不是上游更新的 next/alpha tag。这个说明是必要的配套——否则下一位维护者无法判断 0.1.5rc1 是「最新」还是「恰好在手边」。

具体改动

• pyproject.toml:25：deepseek-harness-sdk==0.1.2a3 → ==0.1.5rc1。
• docs/integrations/deepseek-harness-connector.md：新增渠道说明段（PyPI SDK/runtime 0.1.5rc1、npm @deepseek-ai/dsh latest = 0.1.5-rc.1，next/alpha 不采用），并说明 LoopX 默认选用 SDK 的 sdk profile。
• loopx/dsh_goal_mode/README.md：同步 pin 数字。

对主干的风险

影响面只有安装 loopx[deepseek-harness] 的机器；未安装该 extra 的路径行为不变，默认托管 Turn 仍是「不可用即 fail-closed」。0.1.5rc1 仍是 rc 而非稳定版，但它是上游已发布的 latest 渠道，文档已写明该判定标准，因此这是一个可审计的选择而不是隐含升级。

两点需要明说：

1. 本 head 的聚合作业 pytest 仍为 in-progress（conclusion=null），其余已完成检查全为 success/skipped。因此本卡不声明远端全绿，合并前需要复读一次（建议走 loopx pr-review --check-merge-readiness 4420@39539a7d0）。
2. 本次评审只核对了上游渠道版本，没有在 0.1.5rc1 环境下重跑 live governed Turn；沿用 2026-09-15 的本地实测记录（真实 SDK/runtime，--host dsh 的受治理 Turn 达到 validated_progress 并 commit，另一条未通过校验的 Turn 正确 fail-closed 且配额消耗为 0）。

我的整体评价

APPROVE。这是一次小而有据的 pin 更新：code_volume=necessary、change_proportionality=proportionate、observable_semantics=intentional_change_validated、default_off_isolation=isolated（未安装 extra 的机器升级前后一致）。我把上游 registry 实测当作关键证据：PyPI latest=0.1.5rc1，npm dist-tags.latest=0.1.5-rc.1（next=0.1.5-rc.2、alpha=0.1.6-alpha.1），与文档所述完全一致——也就是说这个 pin 确实指向「最新已发布渠道」，符合我们对 dsh「基于最新版」的要求。

非阻塞项一条（P2）：等 pytest 聚合结论出来再入队合并。

验证：curl https://pypi.org/pypi/deepseek-harness-sdk/json → latest 0.1.5rc1；curl https://registry.npmjs.org/@deepseek-ai/dsh → dist-tags latest=0.1.5-rc.1；仓库内 0.1.5rc1 三处引用一致；远端该 head 已完成检查无 failure（pytest pending）。

---

English verdict: APPROVE at 39539a7d06f97b7809872e7f2576732ec52a3447. The pin moves only the deepseek-harness optional extra (0.1.2a3 → 0.1.5rc1) and documents the channel rule that next/alpha are deliberately not adopted. I verified the upstream registries during this review: PyPI deepseek-harness-sdk latest is 0.1.5rc1, and npm @deepseek-ai/dsh latest is 0.1.5-rc.1 (next = 0.1.5-rc.2, alpha = 0.1.6-alpha.1) — so this pin really is the newest released channel, which is what the managed host requirement asked for. Non-blocking: the aggregate pytest check on this head is still in progress, so re-read merge readiness before merging; and this review did not re-run the live governed Turn against 0.1.5rc1 (it relies on the 2026-09-15 local qualification records, including the fail-closed case with zero quota spend). Machines that do not install the extra are unaffected.