Repository navigation
[Task][RFC]: Complete the Desktop execution frontend journeys #5204
Description
Outcome / 目标
完成 Desktop 双执行入口的用户旅程。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: S1/S4/S5/S12, under #4574. Design acceptance is distinct from implementation, live qualification and promotion.
Current boundary
Source audit: main at ce3862e33 (2026-09-28). This is source/PR inspection, not a new test or live-qualification claim.
Desktop, attached-session integration and managed runtime components are shipped in parts. Current App/session work is active; source-level support is not a clean-install or packaged runtime acceptance result.
Work remaining
- Complete connection, runtime/model readiness, useful execution, correction, stop and recovery for the explicitly supported attached and managed profiles.
- Use existing configuration and session owners; present effective provider/model, actual activity and actionable unsupported/unavailable states.
Ownership and ongoing work
#4114 owns bounded computer use and must not expand this task into unrestricted desktop automation. Reuse #5130/#5139 and the session-mode, App conversation and manager trackers; no parallel frontend rewrite.
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
- A clean release-package installation reaches a useful result and independent CLI readback on the advertised profile.
- Restart/update/rollback, stale binding and unavailable credentials/runtime assets preserve commitments without starting another executor.
- Default/off paths and explicit user model choices remain intact; each host/OS claim has its own evidence.
- 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
- apps/desktop/loopx-control-plane
- apps/presentation/dashboard
- docs/integrations/runtime-connector-catalog.md
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
Duang777 commentedon Oct 4, 2026
@huangruiteng I'd like to claim a narrow, currently unowned acceptance gap under this task: stale
desktop_update_statusresponses can overwrite a newer update phase in bothapps/desktop/loopx-control-plane/static/boot.jsandapps/presentation/dashboard/src/features/personal-workspace/desktop-update.tsx. On currentmain(ba443e2b),maintenance.rssnapshots update state before the bounded environment probe, whileboot.jspolls every second without an in-flight or generation guard anddesktop-update.tsxcommits initial and polling responses unconditionally. A response that capturedavailablebefore Apply can therefore arrive after the action has moved todownloading,installing_*, orrestart_required, expose Apply again, and turn a second click intoupdate_busyorrestart_requirederror UI. This is source-level evidence only; I have not reproduced it in a packaged build yet.If this scope is acceptable, I'll move status snapshotting after diagnostics collection, add monotonic request and action fencing to both frontend entry points, and add delayed-response regression coverage proving stale pre-action state cannot replace
installing_*orrestart_required, Apply stays unavailable after the action begins, and only one Apply request is issued. I'll preserve channel, rollback, and readiness state. #5582 overlapsmaintenance.rs,boot.js, andexamples/desktop-update-browser-smoke.mjs, so I'll wait for or rebase onto its stabilized revision and avoid changing its runtime-selection behavior.