[Task][RFC]: Qualify DSH/Pi observation and managed-runtime selection

[huangruiteng]

Outcome / 目标

验收 DSH/Pi 观测与托管运行时选择。One task tracks this RFC's delivery; keep implementation PRs and milestone evidence here instead of creating a parallel task tree.

Canonical design: RFC. Roadmap: S4/S10/S11, under #4574. Design acceptance is distinct from implementation, live qualification and promotion.

Current boundary

Comparative source audit: main at ce3862e33 (2026-09-28); that audit does not establish live observer qualification.

The bounded DSH install/compatibility repair #5589 is merged at 4e820bb0ced6c0f8dff2acd641a6c19dbc986935 (reviewed head 4c08ea3d293a66c24a65fabcfbfaa35420248cb4, integrated main baseline bfe3c434). It qualifies the existing provider on 0.2.0-rc.2 while retaining supported legacy lifecycle behavior and requires the already released Windows-safe LoopX 1.2.4 CLI. The final risk-based validation passed frozen install, types, peer ranges, 206 tests, exact registry bundles and four rows, wrong-tag/discovery/integrity rejection, removal, packed artifact/profile, real 0.2 web runtime/shared carrier, full semantic validation and the 22-path public boundary scan. Earlier real 0.1.7/frozen 0.1.5 and isolated PyPI bootstrap/native skill/reopen evidence remains explicitly bounded; fresh floating 0.1.5 upstream startup fails on both baseline and candidate. The patched fflate development dependency was requalified. Earlier broad canary/CI failures are recorded, not labeled green; Windows distribution CI passed on the earlier 5b4a885 head. Current existing managed review policy does not consult remote CI. The complete exact-head review was published/read back and merge readiness returned ready before the explicitly authorized merge.

Beta.6 is now published from merged commit 5eee730c201a374d57e6695139bdbe0ea8eac782. Downloaded GitHub bytes match the tagged build (SHA-256 5c36776ded02ea330f560fa5395ed8deef144b59690ac15353df1c7263474a90). The illustrated upgrade guide belongs to the verified personal user account; final text and all three real DSH screenshot bytes were read back. #5680 updates the approved install entry, and #5687 reconciles this evidence in the RFC. Optional npm publishing remains unconfigured; GitHub package distribution does not require an npm account.

Published-byte qualification passed native DSH 0.2 URL installation, beta.5-on-compatible-0.1.5 to beta.6-on-0.2 upgrade/removal, offline plugin tgz install/removal, packed real SDK/HTTP runtime and VM Client lifecycle, and a clean Linux container with the released LoopX 1.2.4 wheel for PEP 668 private installation, skills, launch authentication and GoalBar readback. The original source-wheel Docker script failed for an unbuilt Chat bundle; the independent release-wheel harness passed using artifact copying. In a real macOS DSH 0.2 browser, a synthetic Goal and preconfigured unique binding passed Start/Pause through the published CLI (active/stopped read back); an unactivated Session added no model turn. This does not qualify model-driven continuation, observer fidelity or Windows desktop.

The live marketplace still selects beta.5. Catalog #6633 changes only the existing pinned asset URL; its generator check and asset identity passed. Released Hub 1.4.14 supports GitHub package download but still misses installed identity. Hub #98 fixes that existing parser path; 107 tests passed with two platform skips. The released backend plus candidate Client logic passed proposed beta.6 catalog install/identity/pinned update/removal with native DSH 0.2. Neither upstream PR has merged/released yet; this is not live-market recovery. DSH 0.2 correctly rejects the current beta.5 catalog package as incompatible.

Failed or unverified: Native browser hot uninstall disconnected the Web server while retaining the package dependency. Closing DSH, using native CLI remove and restarting recovered the profile; the GUI path remains failed. #5671 separately reports a missing Windows desktop-host CLI module before plugin loading, not a missing LoopX bundle entry. Windows/DSH 0.2 full market install/init/control/upgrade/remove and that desktop packaging path remain unverified. External network timeouts are not fixed by a version bump; offline tgz recovery covers only the plugin and needs compatible host/CLI dependencies or prepared caches. C0/C1, overhead, retention/deletion and runtime-selection acceptance below remains open.

DSH is the first L1 event source, not an automatically preferred production runtime. Combined diagnostic status/receipt readback exists; mode/session support and manager transport have separate partial evidence.

Work remaining

• Complete the remaining existing provider delivery: upstream catalog #6633 and Hub Add active-user injection channel probe #98 merge/release/adoption; repair/qualify native browser hot uninstall and Windows desktop-host [dsh-plugin.org | dsh-plugin-hub] plugin install failed: loopx-project/loopx #5671; then clean Windows/0.2 market installation, initialization, Start/Pause, upgrade and removal readback. Public beta.6 and the personal guide are delivered; npm remains optional.
• Complete the RFC’s C0/C1, overhead and retention/deletion decision record before claiming an observer-qualified profile.
• Separately qualify managed lifecycle behavior and make runtime selection follow explicit user intent and current readiness; retain Pi as a candidate, not a predetermined migration.

Ownership and ongoing work

This task owns comparative runtime/observer evidence. Session-mode RFC owns admission, and reliability-diagnostics RFC owns diagnostic product/retention. Reuse existing providers and #3243; no live model spend or retention deletion is granted by issue publication.

Contribution route: implementation/integration overlaps active work. Start from the linked current owners/PRs and identify an unowned acceptance gap in a claim comment; do not begin a competing rewrite.

Acceptance

• Freeze treatments and thresholds before authorized experiments; preserve failed runs, uncertainty and no-uplift outcomes.
• Exact session/run identity and observation age prevent a stale goal ledger being shown as current health.
• Start/resume/interrupt/close, crash and duplicate completion preserve one executor; observation cannot influence prompts or scheduler decisions.
• Reconcile the RFC's current delivery checkpoint and this issue with the integrated revision, commands, passed/failed/untested evidence and remaining gates. Close the accepted scope only; no claim that a merged PR alone completes the RFC.

Starting points and delivery boundary

• packages/dsh-loopx-plugin
• loopx/capabilities/reliability_diagnostics
• loopx/control_plane/turn_driver

Base: latest main. Reuse the existing typed owner and provider boundaries. Include affected CLI/frontend/Lark companions; verify real entrypoints and backend where changed. Preserve existing first-screen review and maintainer merge gates. Public artifacts contain only synthetic/public-safe evidence, no private operational state. This task does not authorize provider promotion, benchmark launches, release/deployment or unrelated protected effects.

[Dante-dan]

I'd like to take the bounded exact-session/run diagnostic read contract slice of the second Acceptance row, separate from #5589's install/compatibility work and the Hub release route.

The RFC's Implemented Readback Increment explicitly requires a future consumer to refuse to label a stale or multi-run goal ledger as current session health. Today, build_diagnostic_projection() folds every ordered envelope in the goal ledger into one stage; the CLI binds only goal_id and an evaluation timestamp. The receipt exposes treatment/run identities, but a caller cannot pin the session/observer/treatment it expects before consuming that stage. Existing replay/age tests cover explicit timestamps and read-only behavior, so simply adding another fixture would not close this consumer gap.

I plan an opt-in manual status read that carries the caller's expected provider/observer/session identity plus the existing typed treatment identity, an explicit evaluation time, and a caller-declared maximum observation age. It will return typed ineligibility for mismatched or ambiguous identities, stale/future observations, and non-valid integrity instead of presenting an aggregate stage as that binding's current health. The existing unbound historical response remains compatible. Positive and independent negative tests will exercise the real CLI/readback seam and assert that neither ledger nor canonical work state is changed.

This is a reusable read contract prerequisite, not C0/C1 live qualification, a Mode B panel, automatic polling, runtime promotion, overhead measurement, or retention/deletion work. No provider calls or maintainer-owned benchmark runs are included. I'll keep the delivered checkpoint and remaining live qualification gates distinct. Please flag any existing owner of this exact read-contract slice so I can avoid overlapping their work.