Roadmap: runtime truth + compatibility evidence before broad routing and launch

[Altairpaca]

Product thesis

DSHelm should become the DSH control plane users reach for when two things are uncertain:

1. What route actually executed?
2. Is this DSH/plugin combination actually verified to work?

The differentiator is therefore not merely multi-model routing. It is Effective Route Truth + Compatibility + Explainability: requested/resolved/effective route provenance, evidence-backed compatibility boundaries, and policy decisions that remain inspectable.

Community signal behind the sequence

Current DSH discussions independently expose the same two failure classes:

• subagent/root routes can diverge with real cost consequences and insufficient visibility: [bug]SubAgent routing can use stale/wrong models and silently escalate cost deepseek-ai/deepseek-harness#5973
• multiple plugin authors independently use actual request/session records as the closest thing to authoritative effective-route evidence: Authoritative effective model selection for subagents and plugin runtimes deepseek-ai/deepseek-harness#2053
• plugin upgrades routinely pass static checks yet fail at real host/runtime/client composition; the community is actively consolidating migration/validation practice: 有没有人搞过升级 dsh 插件代码来支持新 dsh 版本的 skill？ deepseek-ai/deepseek-harness#5120

DSHelm should solve these infrastructure problems rather than compete on plugin count.

P0-A — qualify the current host train without lying about support

Current forward target: dsh-v0.1.5-rc.1.
Verified baseline remains 0.1.0-rc.7 until every required machine/runtime gate passes.

• Source-level Session/Agent/Subagent/Web seams adapted through fix(dsh): bridge current Session snapshots without dropping rc.7 #40/fix(dsh): declare current subagent agentOptions capability #42/feat(dsh): prefer current native Web panel slots #43.
• Current DeepSeek V4/V4.1 evidence refresh completed through 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.
• Diagnose and repair the isolated candidate graph in ci: qualify DSH 0.1.5 candidate source graph in isolation #45; the normal verified-baseline CI remains independent.
• Complete package graph + workspace type/build evidence.
• Complete packed-install evidence.
• Complete isolated HOME/DSH_HOME init/boot/doctor/explain/fixture/uninstall journey.
• Complete Session V3 lifecycle evidence.
• Complete current Web client discovery/materialization evidence.
• Promote compatibility.json.tested only after the promotion contract passes.

Owner issues: #34 #45.

P0-B — make Effective Route Truth the primary product proof

Ship #46 before building a more ambitious automatic policy.

Required semantic layers:

requested → resolved → effective

The effective route must come from runtime evidence rather than root-agent UI state or inheritance assumptions.

• Persist provider/model/reasoning effective-route observations.
• Expose divergence class and provenance in Resolution Trace.
• Show actual route in the Control Plane.
• Warn on material child-route escalation when tier/cost evidence exists.
• Preserve unknown when cost/tier evidence does not exist.
• Make the Flash → Pro-style divergence fixture the canonical 30-second demo.

Owner issue: #46.

P0-C — turn compatibility discipline into ecosystem infrastructure

Ship #47 above the existing doctor/version-skew work in #41.

• Export a machine-readable Compatibility Radar from the same candidate/evidence contracts used by CI.
• Distinguish source/API, package graph, packed install, clean profile, Session lifecycle, Web client and runtime journey.
• Render verified/candidate/blocked/unknown/mixed-cohort states without collapsing them into a single support boolean.
• Reuse the projection in dshelm doctor.
• Provide a compact Compatibility Card suitable for README/releases and later plugin-index consumption.

Owner issues: #41 #47.

P1 — publish an alpha users can actually reproduce

Broad promotion starts only after the infrastructure proof above is usable.

Minimum launch gate:

• release: publish npm alpha and verify clean-HOME install/uninstall #7 public npm alpha + clean-HOME install/uninstall evidence.
• at least one real supported-environment installation report from qa: build a cross-platform community installation evidence matrix #8.
• feat: ship Effective Route Inspector and escalation guard #46 has a reproducible requested/resolved/effective demo.
• feat: expose a machine-readable DSH Compatibility Radar #47 can state the exact verified DSH baseline and current candidate status.
• release notes state exact limitations instead of 0.1.x compatible shorthand.
• first-run/doctor gives an actionable next command.

P1.5 — problem-led community entry, not generic promotion

The first two technical community artifacts should teach a real DSH problem and use DSHelm as reproducible evidence:

1. Why green TypeScript tests are not enough for a DSH plugin upgrade — package cohort, Cordis composition, Session/client API, Web materialization and real runtime acceptance, using the rc.7 → 0.1.5 migration evidence.
2. Your root model is not necessarily your subagent model — requested vs resolved vs effective routing, durable runtime evidence and escalation visibility, using feat: ship Effective Route Inspector and escalation guard #46.

Distribution order:

1. contribute problem-specific findings back to the relevant DSH Discussions;
2. GitHub prerelease + DSHelm Discussion with the same reproducible evidence;
3. plugin indexes/awesome lists after npm/install evidence exists;
4. technical communities/social channels only after the first-run path is reproducible;
5. provider/partner cross-promotion only after independent technical validation.

Owner issue: #23.

P2 — evidence-conditioned routing policy

Only after runtime truth is observable should #31 add richer automatic decisions.

• explicit budget/latency/risk constraints;
• evidence-conditioned policy decisions;
• explicit user/project/request override precedence;
• stale/unknown evidence as first-class state;
• policy intent compared against feat: ship Effective Route Inspector and escalation guard #46 effective runtime observations;
• automatic escalation only when policy explicitly permits it.

Owner issue: #31.

P3 — ecosystem health and integrations

• expose compatibility/freshness metadata for indexes/marketplaces;
• keep provider integrations optional and evidence-backed;
• add declarative permission/capability metadata where DSHelm can state it honestly;
• prefer current DSH-native slots/services over long-lived legacy shims;
• do not let commercial relationships alter routing scores/defaults without independent evidence.

Adoption metrics

Do not treat raw stars as the primary success criterion. The next meaningful community milestone is:

• 3 non-maintainer reproducible install reports;
• 2 real external routing/use cases or route traces;
• 1 external contributor PR;
• 1 external DSH project/index/integration that cites or consumes a DSHelm route/compatibility contract.

Stars/forks remain secondary awareness signals. CI clones/indexer traffic are not user adoption.

Invariants

• No candidate becomes tested through metadata-only changes.
• Requested/displayed route is never silently presented as effective runtime truth.
• A compatibility PASS always names the evidence layer it proves.
• Missing price/capability evidence remains unknown rather than guessed.
• Community content must teach/reproduce a problem; no generic "please star" launch before a reproducible alpha.
• DSHelm is independent and must not be presented as an official DeepSeek project.

Related: #7 #8 #10 #23 #31 #34 #41 #45 #46 #47.