compat: audit and qualify DSH 0.1.5-rc.1 without widening the verified baseline

[Altairpaca]

Context

DeepSeek Harness published dsh-v0.1.5-rc.1 on 2026-09-10. DSHelm must keep compatibility.json.tested.dshPackages = 0.1.0-rc.7 until a full promotion journey passes; source compatibility, package resolution and verified runtime compatibility are separate claims.

The 0.1.5 train touches several seams DSHelm uses directly: Session V3/lifecycle ownership, Agent/Inbox semantics, subagent agentOptions, current Web main/sidebar.panellist composition, DeepSeek V4.1/model discovery, pi-ai 0.85.1 and ordinary subprocess changes.

Qualification work

Source/API audit

• Pin the exact dsh-v0.1.5-rc.1 release target in compatibility evidence.
• Replace the stale 0.1.2 forward candidate with 0.1.5 while leaving the verified baseline unchanged (compat: advance forward candidate to DSH 0.1.5-rc.1 #38).
• Remove production/test reliance on legacy session.events; prefer current snapshotEvents() with rc.7 fallback (fix(dsh): bridge current Session snapshots without dropping rc.7 #40/fix(dsh): declare current subagent agentOptions capability #42).
• Audit Agent creation ownership: DSHelm awaits ctx.agents.create() and disposes the returned handle.
• Audit Agent/Inbox semantics: no ctx.agent, hasPending or claim dependency; explicit parent Agent use retained.
• Advertise the current agentOptions subagent capability without claiming unsupported continuable-child lifecycle (fix(dsh): declare current subagent agentOptions capability #42).
• Migrate Control Plane source composition toward current main / sidebar.panellist slots while retaining verified-host fallback (feat(dsh): prefer current native Web panel slots #43).
• Remove the deleted dsh-client-runtime/client source type dependency and isolate host-only projection augmentation from browser declarations (feat(dsh): prefer current native Web panel slots #43).
• Confirm no ordinary-subprocess pid dependency in the current DSHelm surface.
• Complete DeepSeek V4/V4.1 + pi-ai 0.85.1 provenance work without converting catalog/release metadata into model-quality scores (model-knowledge: refresh DeepSeek V4/V4.1 evidence and multimodal routing facts #35/feat(model-knowledge): add DeepSeek V4.1 multimodal catalog evidence #39/feat(model-knowledge): refresh current DSH provenance for V4 routes #44).

Candidate package/source graph

• Add an isolated candidate-source lane that transiently aligns direct DSH dependencies, current minimal Web service dependencies and pi-ai without rewriting the committed verified manifest (ci: qualify DSH 0.1.5 candidate source graph in isolation #45).
• Make the ci: qualify DSH 0.1.5 candidate source graph in isolation #45 candidate-source lane pass. Its first run is currently failing while the normal verified-baseline CI remains green; therefore package/source compatibility is still unverified.
• Record the exact resolved 0.1.5 candidate package cohort and prevent mixed prerelease graphs.
• Run workspace typecheck/build and compatibility-sensitive tests against the coherent candidate graph.
• Verify the DSHelm client bundle against current client-module/renderer/session composition.

Distribution/runtime promotion gates

• Pack/install all DSHelm artifacts into a fresh consumer against the candidate graph.
• Run isolated HOME/DSH_HOME init, bounded boot, doctor, explain, first-run fixtures and uninstall against the candidate.
• Verify Session V3 lifecycle/persistence behavior with a real candidate host journey.
• Verify the browser bundle is discovered and materialized by the current Web client graph.
• Record blocker/evidence status in the shared compatibility evidence contract used by feat: expose a machine-readable DSH Compatibility Radar #47.
• Only after every required evidence layer passes may compatibility.json.tested move from 0.1.0-rc.7.

Evidence output

This issue owns qualification evidence, not presentation. #47 should project the resulting machine state into the Compatibility Radar; #41/doctor should consume that projection instead of implementing a separate compatibility truth table.

Evidence boundary

0.1.5-rc.1 remains a forward candidate until the package graph, packed install, clean profile, Session lifecycle and Web/runtime journeys pass. A source/API adaptation marked complete above is not a support claim by itself.

Related: #32 #35 #38 #40 #41 #42 #43 #44 #45 #47.

[Altairpaca]

Static audit update after landing #38:

• ✅ Forward candidate metadata now targets 0.1.5-rc.1; exact release target commit/date are pinned in docs/compatibility/dsh-0.1.5-rc.1.md.
• ✅ runRoleAgent() already awaits ctx.agents.create(...) and disposes the returned handle in finally, so its lifecycle shape is compatible with the async/create-handle direction. This is source-level evidence only, not a candidate-runtime pass.
• ⚠️ lastAssistantText() still iterates agent.session.events. Current DSH Session exposes the stable log through snapshotEvents() / eventAt() / seq; a dual-generation snapshotEvents()→legacy events bridge can be landed now without widening the rc.7 package baseline.
• ✅ Repository code search found no ordinary subprocess pid dependency.
• ⚠️ packages/dsh/package.json still intentionally injects the rc.7 client graph (dsh-client-runtime, dsh-client-ui-slots, dsh-client-ui-conversation), and the browser control plane remains body-mounted. This should not be mechanically rewritten until the 0.1.5 package/client graph is migrated atomically and Web materialization can be tested.

Next implementation slice: salvage the narrow session-log bridge from the closed #21 branch, adapt its tests to the current V3 audit framing, and keep the Web/package-graph migration separate.

[Altairpaca]

Client-graph audit update from the exact dsh-v0.1.5-rc.1 tag:

• @deepseek-ai/dsh-client-modules@0.1.5-rc.1 is the current module/boot-graph owner and declares dsh.client.immediately: true; its own inject set is empty.
• Current native panel placement is owned by the UI layout/sidebar composition rather than the old rc.7 dsh-client-runtime + ui-conversation trio. @deepseek-ai/dsh-client-ui-layout@0.1.5-rc.1 provides the shell/layout service and @deepseek-ai/dsh-client-ui-sidebar@0.1.5-rc.1 composes the sidebar surface; the current slot hierarchy reserves root main, main.conversation, and sidebar.panellist.
• Therefore the candidate migration should first prove which host-provided client services a standalone DSHelm panel actually needs. Do not add ui-sidebar merely because the panel is selectable there, and do not replace three legacy inject names with three new names one-for-one.

This narrows the Web task to: (1) build a source-level native panel adapter against the current slot contract, (2) derive its minimal inject set from actual Context use, then (3) change package metadata/lockfile and run Web materialization evidence atomically.