web-shell: sidebar shows nothing about a workspace beyond its name — add inline overview, a full workspace menu, and a per-workspace overview endpoint

[wenshao]

Problem

The Web Shell sidebar treats a workspace as a folder heading and nothing more. On main (d853f09) a workspace row shows the basename, an untrusted / read-only badge, and a git pill when a branch is known — and that is all. There is no way to tell from the sidebar how many workspaces are registered, how many sessions each has (or how many are running), whether its MCP servers are connected, or what skills / extensions / channels / context files it carries. The ⋮ menu has exactly one item, Remove workspace.

The data is not the gap. The daemon already exposes every one of those facts per workspace (/workspaces/:w/{mcp,skills,extensions,channels,git,memory,hooks,sessions}), and the SDK wraps them (workspaceByCwd(cwd).workspaceMcp() etc.). The sidebar consumes only the seven fields of DaemonWorkspaceCapability (sdk-typescript/src/daemon/types.ts:108-118).

Concretely:

1. Row carries almost no information — WorkspaceSection.tsx:493-560 renders name + badges + git pill; no full path, no session counts, no MCP / Skills / Extensions hint.
2. Only management action is Remove — WebShellSidebar.tsx:5438-5478. updateWorkspace (rename), initWorkspace (reload runtime) and requestWorkspaceTrustChange exist in the SDK with zero web-shell call sites.
3. MCP / Skills pages are implicitly bound — reachable only via /mcp, /skills or the global Plugins nav; openPanel() (App.tsx:5371) takes no workspace, and the pages read the provider-bound cwd. With several workspaces registered the user cannot tell whose MCP list they are looking at.
4. No workspace overview — no count / limit, SessionOverviewPanel is a session grid with no per-workspace roll-up, and GET /daemon/status?detail=full only covers the bound workspace (daemon-status.ts:1137).
5. No aggregate endpoint — showing counts today means 8 requests per workspace, and MCP / Skills / Extensions return initialized:false placeholders while no ACP child is live.

Plan

Three layers; each is independently shippable and the order is a real dependency chain.

A — inline info + full ⋮ menu (one frontend PR, no protocol change)

• Header: ● running / total session counts (kept in the collapsed state), full path line when expanded (tooltip when collapsed), Projects N count in the section header.
• Expanded state: a chip row main ↑2 ·3 · MCP 3/4 · Skills 12 · Ext 4 · Ch 2 · Ctx 3. MCP chip turns warning-colored when any server is disconnected / errored. Chips collapse to one icon below ~250px sidebar width. Placeholders are never rendered as 0 — while the runtime is not initialized the chip shows "—".
• ⋮ menu: Rename · Copy path · New task · New task in worktree · Manage: MCP servers / Skills / Extensions / Channels / Settings (with live counts) · Reload runtime · Trust… · Remove workspace.
• New files: sidebar/WorkspaceOverview.tsx, sidebar/WorkspaceMenu.tsx, hooks/useWorkspaceOverview.ts (fan-out via workspaceByCwd, gated on expanded + visible, reusing the 2s / 30s poll tiers, request-deduped per cwd). Each with its own tests rather than growing the existing 1.6k / 5.2k-line sidebar test files.
• New sidebar prop workspaceOverview?: false | { items?: (...)[] } so embedders can turn it off. Untrusted workspaces skip MCP / Skills fetches; locked-workspace and kind: 'live' rows keep their current rendering.

B — workspace-bound management pages + Workspaces overview (two frontend PRs)

• B1: openPanel(panel, { workspaceCwd }); MCP / Skills / Extensions / Channels / Settings pages show which workspace they are bound to and offer a switcher (reusing the composer workspace selector). Chips and the Manage menu group open the page for that workspace. Locked mode pins the cwd and hides the switcher.
• B2: new App panel 'workspaces' — a table (name, path, trust, running / total sessions, MCP health, branch + dirty state, last activity, actions), styled after SessionOverviewPanel, reusing the existing removal dialog. Entry: Manage workspaces… at the end of the Projects section + optional footer item.

C — GET /workspaces/:w/overview (one daemon + SDK PR)

A read-only projection advertised as feature workspace_overview:

{ "runtime": { "acpLive": true, "initialized": true },
  "sessions": { "total": 14, "running": 2, "needsApproval": 1 },
  "mcp": { "configured": 4, "connected": 3, "error": 1, "disabled": 0, "discoveryState": "completed" },
  "skills": { "total": 12, "enabled": 11 }, "extensions": { "total": 4, "enabled": 4 },
  "channels": { "configured": 2, "running": 1 },
  "git": { "branch": "main", "ahead": 2, "behind": 0, "dirty": 3 },
  "memory": { "fileCount": 3, "ruleCount": 27 }, "hooks": { "count": 5, "disabled": false },
  "asOf": "…" }

Server side this is the existing parallel fan-out in daemon-status.ts:1141-1166 parameterized by workspace and trimmed to summaries, with snapshot caching in the invalidateWorkspaceSkillsSnapshot style. The frontend hook switches to the single request when the feature is advertised and falls back to the layer-A fan-out otherwise. This layer waits for the workspace-runtime stack (#7308 → #7309 → #7310 → #7311) to land so the overview is defined as a projection of the runtime rather than a second resolver.

Risks

• Request amplification before C lands: strictly expanded-only + visible-only + tiered polling; the layer-A PR should report measured request counts for N=5 expanded workspaces over 60s.
• B1 changes the binding semantics of the management pages, which the feat(serve): manage MCP through workspace runtimes #7309–feat(serve): manage skills per workspace runtime #7311 stack is also touching; A ships first, B1 rebases on the stack.
• Sidebar minimum width is 220px (drawer likewise); chips and path must degrade.

Non-goals

• Worktree list per workspace (no daemon route; worktrees are session metadata only).
• Custom slash command counts (session-scoped only).
• Merge-back / worktree management UI.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Triage

• Type: feature
• Labels: type/feature-request, category/ui, scope/web-shell, daemon, priority/P2
• Next: accept for exploration — ship Layer A (frontend-only) first; B/C stay gated on the workspace-runtime stack

Assessment

• Problem confirmed. The daemon already exposes every fact per workspace (/workspaces/:w/{mcp,skills,extensions,channels,git,memory,hooks,sessions}) and the SDK wraps them, yet the sidebar consumes only DaemonWorkspaceCapability, and updateWorkspace / initWorkspace / requestWorkspaceTrustChange have zero call sites in web-shell — verified in the current tree. The workspace ⋮ menu today really is Remove-only.
• Direction aligned. This surfaces data the runtime already produces; Layer A adds no protocol surface. It continues the multi-workspace direction that RFC: Support multiple workspaces in one qwen serve daemon #6378 pointed at and feat(serve): establish workspace runtime ownership #7308–feat(serve): manage skills per workspace runtime #7311 are building.
• Approach sound. A → B → C is a real dependency chain, and C correctly waits for feat(serve): establish workspace runtime ownership #7308–feat(serve): manage skills per workspace runtime #7311 (all four still open). The request-amplification risk is acknowledged with concrete mitigations (expanded + visible only, tiered polling, single aggregate endpoint once C lands).
• One ask for the Layer A PR: include the promised measurement — actual request counts for N=5 expanded workspaces over 60s — so the fan-out cost is evidenced, not assumed.

中文说明

分类

• 类型: feature(功能请求)
• 标签: type/feature-request、category/ui、scope/web-shell、daemon、priority/P2
• 下一步: 接受探索 — 先落地 Layer A(纯前端、无协议变更);B / C 以 workspace runtime 栈为前提

评估

• 问题属实。 daemon 已按 workspace 暴露全部数据(/workspaces/:w/{mcp,skills,extensions,channels,git,memory,hooks,sessions}),SDK 也有封装,但侧边栏只消费 DaemonWorkspaceCapability,且 updateWorkspace / initWorkspace / requestWorkspaceTrustChange 在 web-shell 中零调用——已在当前代码树核实。工作区的 ⋮ 菜单目前确实只有"移除"一项。
• 方向一致。 只是把 runtime 已产生的数据呈现出来,Layer A 不新增协议面。延续了 RFC: Support multiple workspaces in one qwen serve daemon #6378 提出、feat(serve): establish workspace runtime ownership #7308–feat(serve): manage skills per workspace runtime #7311 正在建设的多 workspace 方向。
• 方案合理。 A → B → C 是真实依赖链;C 正确等待 feat(serve): establish workspace runtime ownership #7308–feat(serve): manage skills per workspace runtime #7311(四个均仍为 open)。请求放大风险已被识别,且有具体缓解措施(仅展开 + 可见时拉取、分级轮询、C 层落地后提供单一聚合端点)。
• 对 Layer A PR 的一个要求: 附上计划中承诺的测量数据——N=5 个展开 workspace、60 秒内的实际请求数——让扇出成本有证据支撑,而不是凭假设。

--- Qwen Code

[wenshao]

Layer A is up as #10407 (inline counts, path, facet chips, and the full workspace menu; frontend-only, no protocol change). Layers B1/B2 and C remain as described above; B1 will follow the workspace-runtime stack (#7308 → #7311) so the management pages bind to the chosen workspace instead of the connection's bound one.