Files
Shaojin WenandQwen-Coder 5b44cfad71 fix(web-shell): include channel sessions in release dialog (#16537)
* fix(web-shell): include channel sessions in release dialog

The release dialog inherited the sidebar's default source filter, which
excludes sourceType: "channel". A workspace filled by idle channel
sessions therefore opened an empty recovery list.

Query the workspace catalog without a source filter for this dialog and
keep the default, channel, and qwen-live rows. The sidebar and every
other useScopedSessions caller keep the default filter.

Add hook/dialog regressions and verify banner -> release -> create with
a real sourceType: "channel" session filling a one-session workspace.

* fix(web-shell): keep live sessions visible in release dialog

Expanding the recovery list from the sidebar's default source filter to
persisted history can still bury the sessions holding slots: closed
channel rows fill the first page before they are reached.

Add a liveOnly session-list option on the daemon route and SDK so callers
can read the workspace bridge instead of persisted history. The release
dialog requests the shared page size with that option and keeps listing
default, channel, and qwen-live rows, so closed history can no longer
crowd out what can be released.

Co-authored-by: Qwen-Coder <[email protected]>

* fix(sdk): serve liveOnly session lists over native REST

The ACP session/list mapping drops liveOnly, so a DaemonClient
configured with an AcpHttpTransport silently returned persisted
history for the release dialog's live-only request. Route liveOnly
through the native REST transport for both the legacy and
workspace-qualified list methods, and cover the real ACP transport
with a regression test.

Co-authored-by: Qwen-Coder <[email protected]>

* test(web-shell): pin the release dialog's source whitelist

Live-only listings can include side_task, scheduled_task, and standalone
sessions that the server does not hide. Add those rows to the dialog test
so widening the whitelist fails, and state the 100-row live-page ceiling
next to the page-size request.

Co-authored-by: Qwen-Coder <[email protected]>

---------

Co-authored-by: Qwen-Coder <[email protected]>
2026-11-07 15:31:35 +00:00
..
2026-07-29 06:08:22 +00:00

Design Documentation Requirements

English | 简体中文

Design documents describe proposed changes, their rationale, and how to verify them. Store them under docs/design/ and follow the requirements below when creating or updating a design.

File naming and navigation

  • Maintain two complete versions in the same directory: <name>.md for English and <name>.zh-CN.md for Simplified Chinese. Keep the same base name and date prefix, if any. Directory entry pages use README.md and README.zh-CN.md.
  • Add relative links to both versions immediately below each document title.
  • Preserve existing document paths where possible. If a path or heading anchor changes, update its incoming references in the same change.

Content alignment

  • Both versions must cover the full design. A summary or a link to the other language does not replace a translation.
  • Keep section order and heading levels aligned. Match the meaning of the problem statement, current state, goals, scope boundaries, proposed solution, design decisions and rationale, constraints, risks, validation plan, acceptance criteria, and open questions wherever those sections apply.
  • Preserve technical identifiers, file paths, commands, configuration keys, protocol fields, example values, and numeric limits. Translate explanatory prose and captions without changing the behavior they describe.
  • Keep status, dates, milestones, and follow-up requirements aligned when present. Distinguish proposals, implemented behavior, and verified results in both languages; translation must not change a design's status.
  • Share diagrams and other assets where practical. Provide equivalent explanations for language-specific text in shared assets.

Requirements for subsequent changes

  • Create or update both versions in the same change and submit them together in the same PR. Either language may be edited first; reconcile any differences before considering the documentation complete.
  • When updating an existing single-language design, add the missing version and align the complete pair. Preserve the original design's meaning when translating; explain actual design changes consistently in both versions.
  • Reflect new decisions, implementation constraints, acceptance criteria, and follow-up work in both versions as the design evolves. Do not leave one version with an earlier requirement or an unresolved question that the other version has already answered.

Review checklist

  • Both files exist, and their language links resolve in both directions.
  • Section structure and substantive requirements match; neither version omits decisions, limitations, acceptance criteria, or follow-up work.
  • Technical identifiers, examples, links, and shared assets remain correct.
  • Both versions reflect the same status and the changes proposed in the PR.
  • Markdown formatting and relative links have been checked.