[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 is proposed in #5589, head 5b4a885a91e6327bb628ab97e2f4c8033a9b3d4f, based on f2efcb770. It retains the existing provider owner, qualifies 0.2.0-rc.2 while preserving supported legacy lifecycle behavior, and requires the released Windows-safe LoopX 1.2.4 CLI. Local evidence: 206 tests and type checks; real packed DSH 0.2/0.1.7/frozen 0.1.5 runtime; package-name install/readback/removal with tag/discovery/integrity negatives; real isolated PyPI bootstrap, native skill readback and idempotent reopening. Fresh floating 0.1.5 upstream startup fails on both baseline and candidate. Broad premerge validation was not green; failure distinctions are recorded in the PR. Rebased final-head Windows packaging/install/removal and DCO passed; Linux, dependency review and frontstage CI remain pending. Latest-main integration requalification passed all 206 tests, full semantic validation and the 22-path public boundary scan. A compatible locked HTTP-cache dependency refresh was requalified with 206 tests and real 0.2 runtime.

This is proposed source qualification, not an installed marketplace or release claim. Maintainer merge, beta.6 publication and verified marketplace adoption remain required. npm discovery serves the current Hub route; Hub #93, head af4a4941ba1da8f63d48e5419f76bf4224d9a430, proposes an alternative through the existing authoritative release command. Its type checks/build and 107 tests passed with 2 platform skips; a built-backend HTTP server installed the live catalog beta.5 package through native DSH, verified installed identity, performed a pinned update and removed it with readback. Upstream review, release and adoption are still pending; fork CI is action_required with no jobs executed and awaits upstream authorization. Browser-mounted Hub interaction is untested. The mounted-browser Start/Pause and Docker gates are untested by this repair; C0/C1, overhead, retention/deletion and runtime-selection acceptance below remain 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 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.