Roadmap: compatibility-first public alpha, then evidence-conditioned routing

[Altairpaca]

Objective

Sequence DSHelm around the current DSH ecosystem bottleneck: compatibility and reproducible adoption first, broader routing policy second.

P0 — DSH compatibility and public-alpha readiness

Recent DSH 0.1.2-rc.1 churn has repeatedly affected client-module composition, plugin loading, provider/settings surfaces and first-run behavior. DSHelm should therefore make version skew observable rather than racing the host release train.

• Keep compatibility-candidates.json / promotion checks from feat(compat): gate DSH 0.1.2-rc.1 promotion on evidence #30 as the machine gate.
• Preserve an explicit distinction between verified DSH baseline, source target and blocked candidate.
• Track upstream client/plugin/provider regressions as external blockers; do not widen compatibility claims because source adapters compile.
• Improve doctor / first-run output so package-graph, Web bundle, profile discovery and unsupported-host failures are actionable.
• Complete release: publish npm alpha and verify clean-HOME install/uninstall #7/qa: build a cross-platform community installation evidence matrix #8/community: prepare the public alpha launch and ecosystem distribution kit #23 launch evidence before broad promotion: published alpha, clean-HOME install/uninstall, platform evidence and exact compatibility notes.

P1 — evidence-conditioned routing policy

Only after the P0 adoption path is reproducible:

• define the machine-readable routing policy contract from feat: introduce evidence-conditioned routing policy engine #31;
• consume empirical AHI evidence without converting unmatched benchmarks into rankings;
• support explicit budget/latency/risk constraints and policy overrides;
• keep Resolution Trace as the user-visible explanation boundary;
• add regression tests for policy evaluation and unavailable/unknown evidence.

P2 — ecosystem integrations

• provider proposals remain opt-in and use the provider-integration contract;
• plugin/marketplace integration should consume compatibility metadata rather than bypass it;
• external partnerships must not influence evidence scores or defaults without independent technical evidence.

Acceptance

• No blocked DSH candidate can become tested through metadata-only changes.
• A new user has one documented, reproducible first-run path before policy-engine scope is advertised as the main product.
• Compatibility failures remain explicit and actionable.
• Routing decisions cite their policy/evidence inputs rather than hiding fallback semantics.

Related: #7 #8 #20 #23 #29 #30 #31