Skip to content

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

Description

@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.

As of 2026-10-07, the live marketplace still selects beta.5. Catalog #6633 remains open and changes the pinned asset URL to published beta.6; its description now reflects the current Hub release. Hub #98 has merged and ships in Hub 1.5.0, including the npm package. The published backend and Client helpers passed proposed beta.6 catalog install, installed identity, pinned update and removal through native DSH 0.2 HTTP routes. This is published-Hub qualification with a proposed catalog URL, not adoption by the live marketplace. DSH 0.2 still rejects beta.5 as incompatible.

Fresh #5786 and #5796 report ERR_PNPM_MISSING_TARBALL_INTEGRITY while attempting beta.5; #5772 already uses Hub 1.5.0 but supplies only a generic failure. Clean macOS native profiles install beta.6 with pnpm 11.25.0/12.6.0 using existing stores. A synthetic missing-checksum lockfile reproduces the refusal with 12.6.0; --force and --fix-lockfile also fail. Preserving the old lockfile and resolving compatible dependencies again restores the checksum and installation with integrity checks enabled. This does not establish why the reported Windows lockfiles lack a checksum.

Hub #102 proposes exact-code policy diagnostics, shared English/Chinese backup-and-recovery guidance in the live dialog and saved notifications, and backend-recorded executed commands instead of invented Git-root fallbacks. The packed candidate passed real macOS DSH native failure, persisted notification/reload, both languages and successful installation retry after backup-preserving recovery. Three TypeScript checks, 109 tests (two platform skips) and builds passed with isolated Git configuration; the unchanged proxy test also fails on the base under global Git configuration. #102 remains an upstream proposal, not a published or Windows-qualified repair. #5801 reconciles the existing RFC checkpoint; the personal illustrated guide now contains released-Hub status and bounded recovery instructions.

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 adoption and Hub Keep review handoffs within budget #102 review/release/adoption; establish the reported Windows lockfile origin from complete logs; 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

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.

Activity

Dante-dan commented on Oct 4, 2026

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions