A dashboard makes a promise the moment it shows a Stop or Delete button: the operation refers to a real thing, and it will still refer to that thing while the interface is waiting, retrying, or switching sessions. Qwen Code's workflow-control pull request takes that promise seriously. Its public merge record carries several Claude-Session links, direct evidence that a coding agent was used in the work, but the durable lesson is in the repository: the lifecycle rules underneath the Web Shell are treated as an engineering problem in their own right.
The state before the state
The merged change spans a public 64-commit, 79-file effort across the runtime, daemon/API, SDK, Web Shell, and regression suites. The key design move is that mutations which affect a shared workflow history use a storage-scoped identity rather than a session-local one. That matters when one session retries a run while another deletes its history: if each session owns a separate lock, both operations can honestly believe they are alone.
The inspected workflow-run registry also names the awkward state that UI work often skips. Between reserveStart and register, a runner may be loading a script or replaying a journal: it has begun, but it is not yet a normal registry entry. The code makes that interval visible through reservations and lets cancelStarting reach it. A control plane that ignores that interval can show a run as starting while answering “not found” to the user's cancel request.
The transferable skill
Model every operator control against the same identity the durable store uses, then give the transitional state a first-class name. That is the transferable craft here: make “starting,” “registered,” “settling,” and “deleted” part of the system's truth before decorating them with status colors. Qwen's daemon tests exercise a reserved-but-unregistered cancel and deny workflow surfaces when the workspace is untrusted. The same discipline applies to any agent UI that exposes controls over background work: boundary checks belong at the daemon that owns the state, not only in the client that renders it.
What the work does not settle
These are strong public receipts for intended source behavior and for non-trivial engineering, not a release or adoption report. The public implementation notes do not prove that every platform, narrow layout, or real operator workflow has been exercised. They also do not mean a dashboard itself makes a system safe. The next useful signal is a tagged release and cross-platform evidence that the same shared identity survives a real start, retry, delete, and cancellation sequence outside the test harness.