fix(web-shell): Preserve workspace navigation in standalone tasks

[doudouOUC]

What this PR does

This PR keeps workspace navigation and explicit workspace-management entry points available when a Web Shell task uses standalone mode. The global New task action now defaults to the current trusted workspace, exposes trusted non-Live workspaces and No workspace through a split menu, and mirrors the same explicit scope choice in the empty-state composer. Selecting No workspace changes only the draft context; the standalone session is still created lazily by the first prompt.

Standalone tasks continue to show Project sessions, Plugins, and Scheduled Tasks. Plugins and schedules are labeled and routed to the trusted primary workspace without changing the active standalone conversation. Bound scheduled-task runs and history preserve their workspace owner, while legacy unbound tasks fail closed outside that workspace. Workspace-only actions such as Git, Goals, Channels, worktrees, settings, and direct skill insertion remain unavailable in standalone mode.

Why it's needed

After starting or sending a standalone task, the sidebar previously removed the workspace tree together with Plugins and Scheduled Tasks. This made existing project sessions and workspace administration appear to disappear. New task also silently preferred standalone mode whenever the capability was present, even when a trusted workspace was available. The new behavior makes scope explicit, keeps navigation stable across workspace and standalone tasks, and preserves the existing trust and session-ownership boundaries.

Reviewer Test Plan

How to verify

1. Start Web Shell against a daemon that advertises standalone_sessions_v1 and has a trusted primary workspace. Click the main New task action and send a prompt; expect a workspace session created with that workspace cwd.
2. Open the New task scope menu or the empty-state composer Workspace menu and choose No workspace. Expect context=standalone, a visible No workspace chip, and no session-creation request until the first prompt is sent. Switch back to the workspace before sending and confirm no session was created during either scope change.
3. Send the standalone prompt, then confirm Project sessions, Plugins, and Scheduled Tasks remain visible. Opening Plugins or Scheduled Tasks should display the primary workspace label and must not change the standalone URL or create another session.
4. Open a bound scheduled-task run from another workspace and confirm its session is loaded with that workspace. Attempting to run a legacy unbound workspace task while standalone should fail instead of dispatching into the standalone conversation.
5. Confirm a settled standalone session and a locked-workspace embed do not expose composer retargeting, Live does not gain workspace management, and a daemon without standalone support keeps the legacy primary-workspace route.

Evidence (Before & After)

Before	After
New task silently selected standalone whenever supported; after sending, Project, Plugins, and Scheduled Tasks disappeared from the sidebar.	New task defaults to the trusted current/primary workspace; No workspace is explicit; standalone tasks retain Project, Plugins, and Scheduled Tasks with the management workspace shown.
Scope changes were coupled to starting a new task.	Switching the empty draft between workspace and No workspace sends zero create requests; the first prompt performs the one expected create request.

Automated browser evidence: 6/6 standalone Playwright scenarios passed, including exact /session versus /standalone/sessions request assertions. Real cold-start verification also observed zero create POSTs while switching workspace → No workspace → workspace, and no composer workspace selector on an already-created standalone session.

Tested on

OS	Status
🍏 macOS	✅ tested
🪟 Windows	⚠️ not tested
🐧 Linux	⚠️ not tested

Environment (optional)

macOS, Node.js 24.12.0, local npm run dev:daemon with daemon on port 4170 and Vite on port 5173. Web Shell lint, typecheck, and production build passed. Focused component suites passed (WorkspaceSelector 4/4, Sidebar 120/120, Scheduled Tasks 57/57, Skills 7/7), the complete App suite passed 661/661, and standalone Playwright passed 6/6. The repository-wide build remains blocked on the unchanged main-branch error in packages/cli/src/ui/opentui/commands-registry.ts where "output-style" is not assignable to never.

Risk & Scope

• Main risk or tradeoff: The change separates project navigation, workspace management, and workspace-only conversation actions, so the primary risk is dispatching an action through the wrong workspace or session owner; explicit cwd propagation and fail-closed checks cover those paths.
• Not validated / out of scope: Windows and Linux browser rendering, redesigning Live sessions, and changing daemon persistence or scheduling formats.
• Breaking changes / migration notes: None. Older daemons without standalone support and locked-workspace embeds retain their existing single-workspace behavior.

Linked Issues

Follow-up to #10514.

中文说明

本 PR 做什么

本 PR 在 Web Shell 任务使用无工作区模式时保留工作区导航和明确的工作区管理入口。全局“新建任务”现在默认使用当前可信工作区，通过拆分菜单提供可信的非 Live 工作区和“无工作区”，空状态编辑器也提供相同的明确范围选择。选择“无工作区”只改变草稿上下文；无工作区会话仍由第一条提示词按现有机制延迟创建。

无工作区任务会继续显示项目会话、插件和定时任务。插件和定时任务会明确标注并路由到可信主工作区，同时不改变当前无工作区会话。已绑定的定时任务运行和历史会携带其工作区所有者；旧的无绑定任务在离开所属工作区时会失败关闭。Git、目标、频道、worktree、设置和直接插入技能等仅限工作区的操作在无工作区模式下仍不可用。

为什么需要

此前启动或发送无工作区任务后，侧边栏会同时移除工作区树、插件和定时任务，让已有项目会话和工作区管理看起来像是消失了。只要 daemon 支持无工作区能力，“新建任务”也会静默优先选择无工作区，即使已有可信工作区。新行为让范围变得明确，在工作区与无工作区任务之间保持稳定导航，并保留现有的信任和会话所有权边界。

Reviewer 测试计划

如何验证

1. 使用声明 standalone_sessions_v1 且具有可信主工作区的 daemon 启动 Web Shell。点击主“新建任务”并发送提示词；应使用该工作区 cwd 创建工作区会话。
2. 打开“新建任务”范围菜单或空状态编辑器的工作区菜单并选择“无工作区”。应看到 context=standalone 和“无工作区”标签，并且在发送第一条提示词前没有创建会话请求。发送前切回工作区，确认两次范围切换都没有创建会话。
3. 发送无工作区提示词后，确认项目会话、插件和定时任务仍然可见。打开插件或定时任务时应显示主工作区标签，且不能改变无工作区 URL 或创建另一个会话。
4. 打开另一个工作区中已绑定定时任务的运行记录，确认使用该工作区加载会话。在无工作区中尝试运行旧的无绑定工作区任务时，应失败而不是发送到无工作区会话。
5. 确认已建立的无工作区会话和锁定工作区嵌入不会显示编辑器改绑入口，Live 不会获得工作区管理能力，不支持无工作区的旧 daemon 继续走原有主工作区路由。

证据（修改前后）

修改前	修改后
只要支持就会由“新建任务”静默选择无工作区；发送后侧边栏中的项目、插件和定时任务消失。	“新建任务”默认选择可信的当前或主工作区；“无工作区”需要显式选择；无工作区任务保留项目、插件和定时任务，并显示管理工作区。
范围切换与开始新任务耦合。	空草稿在工作区与无工作区之间切换时创建请求为 0；第一条提示词才发送唯一一次预期创建请求。

自动化浏览器证据：6/6 个无工作区 Playwright 场景通过，包括精确断言 /session 与 /standalone/sessions 请求。真实冷启动验证也观察到工作区 → 无工作区 → 工作区切换期间创建 POST 为 0，并确认已创建的无工作区会话不再显示编辑器工作区选择器。

测试平台

操作系统	状态
🍏 macOS	✅ 已测试
🪟 Windows	⚠️ 未测试
🐧 Linux	⚠️ 未测试

环境（可选）

macOS、Node.js 24.12.0，本地执行 npm run dev:daemon，daemon 使用 4170 端口，Vite 使用 5173 端口。Web Shell lint、typecheck 和生产构建通过。定向组件测试通过（WorkspaceSelector 4/4、Sidebar 120/120、Scheduled Tasks 57/57、Skills 7/7），完整 App 测试通过 661/661，无工作区 Playwright 通过 6/6。仓库级构建仍被 main 分支未改动的问题阻塞：packages/cli/src/ui/opentui/commands-registry.ts 中 "output-style" 不能赋值给 never。

风险与范围

• 主要风险或权衡：本次修改拆分了项目导航、工作区管理和仅限工作区会话的操作，主要风险是将操作发送到错误的工作区或会话所有者；显式 cwd 传递和失败关闭检查覆盖了这些路径。
• 未验证或不在范围内：Windows 和 Linux 浏览器渲染、Live 会话重新设计，以及 daemon 持久化或调度格式变更。
• 破坏性变更或迁移说明：无。不支持无工作区的旧 daemon 和锁定工作区嵌入保留原有单工作区行为。

关联问题

#10514 的后续修复。

[qwen-code-ci-bot]

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

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

[doudouOUC]

E2E test report

Baseline on main: global New task implicitly selected standalone whenever supported, and Project, Plugins, and Scheduled Tasks disappeared from the sidebar after entering that context.

Automated browser verification:

• cd packages/web-shell && npx playwright test client/e2e/web-shell.standalone.spec.ts — 6/6 passed.
• The default New task path produced exactly one POST /session with the trusted primary cwd.
• Explicit No workspace produced exactly one POST /standalone/sessions on the first prompt, with no workspace-session create request.
• Opening Plugins and Scheduled Tasks in standalone preserved context=standalone, showed the primary workspace scope, and produced no create request.
• Legacy-daemon routing and uncertain standalone-create recovery scenarios also passed.

Real cold-start verification against the local daemon/Web Shell:

• The empty composer workspace menu contained qwen-code, No workspace, and New workspace.
• Switching workspace → No workspace → workspace updated the URL/chip and produced zero exact session-create POSTs.
• Workspace-only controls returned after switching back to qwen-code.
• Loading an existing standalone session used only its load route; the settled composer exposed no workspace-retargeting selector and produced no create POST.
• Locked-workspace retargeting is covered by the focused guard test.

Supporting verification:

• App: 661/661 passed.
• WorkspaceSelector: 4/4 passed.
• Sidebar: 120/120 passed.
• Scheduled Tasks: 57/57 passed.
• Skills: 7/7 passed.
• Web Shell lint, typecheck, and production build passed.
• Repository-wide build is still blocked by the unchanged commands-registry.ts main-branch "output-style"/never type error.

Environment: macOS, Node.js 24.12.0, local daemon on 4170 and Vite on 5173. Windows and Linux were not run locally.

[qwen-code-ci-bot]

Qwen Code review did not complete successfully. The review pipeline failed before a review could be posted. A transient error is retried automatically; if you are seeing this, retry with @qwen-code /review. See workflow logs.

[qwen-code-ci-bot]

Thanks for the PR!

Template looks good ✓

Problem: observed bug with solid evidence, not theoretical hardening. This is a direct follow-up to the standalone-chats feature merged yesterday (#10514): entering a standalone task removed the workspace tree, Plugins, and Scheduled Tasks from the sidebar, and New task silently preferred standalone whenever the capability was present. The description carries a before/after table, the E2E report comment adds request-level verification, and the behavior is reproducible from the merged feature's own semantics.

Direction: aligned. Preserving workspace navigation and explicit management entry points while a standalone conversation is active keeps the trust/session-ownership boundaries intact instead of papering over them, and defaulting New task back to the trusted workspace matches the project-first sidebar. No auth/sandbox/telemetry/public-contract surface is touched.

Size: not applicable — no core module paths. All changes are in packages/web-shell/client/** plus one design doc (~505 production lines vs ~740 test lines).

Approach: the scope feels right. Splitting the single projectFeaturesEnabled gate into three concerns (project features, workspace management, project navigation) is the natural way to express "standalone keeps navigation + management but not workspace-only actions", and lazy session creation (zero create requests on scope switches) is kept intact. The design doc under docs/design/ follows the repo convention. Nothing in the diff looks like drive-by churn.

Risk: no elevated risk signals — none of the changed files match the revert-correlated paths.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓

问题： 已观测到的 bug，证据充分，不是理论性加固。这是昨天合入的无工作区会话功能（#10514）的直接后续：进入无工作区任务后侧边栏移除了工作区树、插件和定时任务，且"新建任务"在能力存在时会隐式优先选择无工作区。描述里有 before/after 对照表，E2E 报告评论补充了请求级验证。

方向： 对齐。在无工作区会话激活时保留工作区导航和显式管理入口，保持了信任/会话所有权边界；"新建任务"默认回到可信工作区，符合项目优先的侧边栏设计。不涉及认证/沙箱/遥测/公共契约。

规模： 不适用——未触及核心模块路径。全部改动在 packages/web-shell/client/** 加一篇设计文档（约 505 行生产代码，约 740 行测试）。

方案： 范围合理。把单一的 projectFeaturesEnabled 门拆成三个关注点（项目功能、工作区管理、项目导航）是表达"无工作区保留导航和管理、但排除工作区专属操作"的自然方式；切换范围时零会话创建请求的懒创建语义也得以保留。设计文档放在 docs/design/ 下，符合仓库惯例。

风险： 无升级风险信号——改动文件均未命中与回滚相关的高风险路径。

进入代码审查 🔍

— Qwen Code · qwen3.8-max

_{Reviewed at f98f7edae3707807afe2f7bf0c45fd65ac310ff4 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code review

I wrote my independent proposal before reading the diff — keep the sidebar sections mounted in standalone context, label them with the trusted primary workspace, default New task to the current trusted workspace, and fail closed for tasks whose owning workspace isn't active. The PR's approach matches that, and in a few places goes further than I would have thought to (the workspaceActionId === undefined convention means legacy unbound tasks resolve to the primary workspace's cwd, so the fail-closed check actually has something to check against — a detail I'd have missed).

Things I verified against the base branch rather than taking on faith:

• createNewSession({ kind: 'global' }) only clears the draft and sets the pending context — no session is created until the first prompt, so composer scope switches genuinely issue zero create requests.
• The context-cleanup effect (if (workspaceContextActive) return; ...) is the exact mechanism that used to tear down the plugins panel and scheduled-tasks view on leaving a workspace context; the new workspaceManagementActive conditions keep both alive in standalone with a trusted primary, while Live contexts still tear down (workspaceManagementActive is false there).
• loadSidebarSession(sessionId, workspaceCwd?) already accepts the second argument; bound task runs load with their workspace's cwd and context.
• workspaceLabel, workspace.paneLabel, common.current, and the lucide icons the diff uses all already exist on main; new i18n keys are added to both EN and ZH.
• Workspace-only surfaces stay gated: onUseSkill becomes optional and the Run button disappears in the skills tab; Git/Goals/Channels/worktrees/settings stay hidden; locked-workspace embeds keep the single-button flow; no trusted primary → management entries hidden rather than targeting an untrusted workspace.

One deliberate behavior change worth a maintainer's awareness (not a blocker, documented in the design doc and covered by tests): a legacy unbound scheduled task now fails closed with "no bound workspace session" whenever the active context isn't its owning workspace — previously it would run in whatever session happened to be current, including a different workspace's session. That's the safer semantics, but it is a tightening beyond the standalone case.

No critical findings, no convention violations.

Testing

This is an unattended CI run, so the evidence below is the PR's own CI, fetched via the API — I did not run any of the PR's code.

Check	Conclusion
Test (ubuntu-latest, Node 22.x)	❌ failure
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	❌ failure
Capture web-shell visuals (ubuntu-latest, Node 22.x)	❌ failure
Integration Tests (no-AK, No Sandbox)	❌ failure
Post Coverage Comment (ubuntu-latest, 22.x)	❌ failure (downstream of Test)
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
Dependency CVE audit	✅ success
Secret scan (TruffleHog)	✅ success
Test (macos-latest / windows-latest, Node 22.x)	⏭️ skipped

All four substantive failures are the same build break, and it is not this PR's. Every failing job dies in the shared build step with exactly one type error:

src/ui/opentui/commands-registry.ts(177,13): error TS2322: Type '"output-style"' is not assignable to type 'never'.
npm error command failed: npm run build --workspace=packages/cli

Evidence for the pre-existing call: this PR's diff touches 17 files, all under packages/web-shell/client/ and docs/design/ — nothing in packages/cli, and the failing type (OpenDialogActionReturn['dialog']) is defined and consumed entirely inside packages/cli. A web-shell-only diff cannot change packages/cli type-checking. The author also flagged this exact error as an unchanged main-branch problem in the description. Oddly, the file at this PR's merge ref does contain the case 'output-style': handler and the union member, and the reported line (177) doesn't match the current source layout (the never check sits at line 180) — which points at stale incremental build state on the runner rather than a real source contradiction. Either way: main's build needs fixing before this (or any) PR's CI can go green; unit tests and the Playwright suite never reached execution here.

Consequence: there is no CI test evidence for this PR yet. The author's local results (App suite 661/661, Sidebar 120/120, standalone Playwright 6/6 with exact /session vs /standalone/sessions request assertions) are their claim from the E2E report comment, not independently verified. Not verified: unit/e2e/visual results (blocked by the build break), Windows/Linux rendering (author tested macOS only).

Sandboxed verification would settle the behavioural claim once the build is unblocked: @qwen-code /verify — that New task actually defaults to the trusted workspace and scope switches issue zero create requests against a real daemon is asserted only by the PR's own Playwright suite (which never ran in CI) and the author's cold-start report.

中文说明

代码审查

在读 diff 之前我先独立写了方案——在独立（无工作区）上下文中保留侧边栏各分区、用可信主工作区标注它们、"新建任务"默认当前可信工作区、对所属工作区不活跃的任务失败关闭。PR 的方案与此一致，部分细节比我想得更到位（workspaceActionId === undefined 约定让遗留未绑定任务能解析到主工作区 cwd，失败关闭检查因此有明确对象）。

已对照基线分支核实（而非凭描述采信）：createNewSession({kind:'global'}) 只清草稿、不建会话，切换范围确实零创建请求；上下文清理 effect 正是原先离开工作区时拆掉插件面板和定时任务视图的机制，新的 workspaceManagementActive 条件在有可信主工作区的独立上下文中保留两者，Live 上下文仍会拆除；loadSidebarSession 本就接受第二参数；diff 引用的 workspaceLabel、workspace.paneLabel、common.current、lucide 图标在 main 上均已存在；新 i18n 键同时加了中英文。工作区专属入口保持关闭：技能 Run 按钮隐藏、Git/Goals/Channels/worktrees/设置仍隐藏、锁定嵌入保持单按钮、无可信主工作区时管理入口隐藏而不是指向不可信工作区。

一个有意的行为变化，值得维护者知悉（非阻塞，设计文档已写明且有测试覆盖）：遗留未绑定定时任务现在只要当前上下文不是其所属工作区就会以 "no bound workspace session" 失败关闭——以前它会在任意当前会话中运行（包括别的工作区的会话）。语义更安全，但收紧范围超出了独立场景本身。

无关键问题，无规范违规。

测试

这是无人值守 CI 运行，以下证据来自 PR 自身 CI 的 API 数据，未运行任何 PR 代码。

四个实质失败全部是同一个构建错误，且不是本 PR 造成的：所有失败 job 都死在共享构建步骤，唯一的类型错误是 commands-registry.ts 的 "output-style" 不可赋值给 never（packages/cli 的构建）。本 PR 的 17 个文件全部在 packages/web-shell/client/ 和 docs/design/ 下，未触及 packages/cli，出错的类型也完全定义并消费于 packages/cli 内部；作者在描述中也已声明这是 main 分支上的既有错误。该文件在合并 ref 上实际包含 case 'output-style':，报错行号（177）与当前源码布局（never 检查在 180 行）不符，更像构建缓存/增量状态问题。无论如何：需要先修好 main 的构建，本 PR（以及任何 PR）的 CI 才可能变绿；单元测试和 Playwright 这次根本没跑到。

结果：本 PR 目前没有任何 CI 测试证据。作者本地结果（App 661/661、Sidebar 120/120、独立 Playwright 6/6，含精确请求断言）是其 E2E 报告中的自述，未经独立验证。未验证：单元/e2e/视觉结果（被构建失败阻塞）、Windows/Linux 渲染（作者仅在 macOS 上测试）。

构建恢复后可用沙箱验证补齐行为证据：@qwen-code /verify —— "新建任务默认可信工作区、切换范围零创建请求"目前只有 PR 自己的 Playwright 套件（未在 CI 中运行）和作者的冷启动报告支持。

— Qwen Code · qwen3.8-max

_{Reviewed at f98f7edae3707807afe2f7bf0c45fd65ac310ff4 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 3/5 — the code itself earns a 4/5; what's missing is evidence, not quality.

Stepping back: the approach matches the one I'd have proposed, the diff is exactly the minimal set the stated goal needs (no drive-bys, tests outnumber production code, design doc included), and the trust boundaries are handled the way this repo's daemon routing expects — fail closed, never fall back to an untrusted workspace, never leak a context switch into session creation. Six months from now this reads as careful work, not work to curse at.

So why not approve? Because I'd be attesting to test results that do not exist. Every substantive CI check on this head died in main's pre-existing packages/cli build break before a single test ran — the unit suite, the standalone Playwright specs, and the visual capture all have zero signal for this commit. Approving now would certify a green suite nobody has seen. The author's local numbers look plausible and the static review found nothing, but "plausible" is not the bar.

⏸️ Deferring until CI can actually run this PR's tests. Nothing is being asked of the author here — the blocker is the output-style/never build error on main (which is blocking every PR's CI, not just this one). Once main builds again: re-run CI here; if it lands green on f98f7edae3707807afe2f7bf0c45fd65ac310ff4, an @qwen-code /triage re-run should convert this into an approval without further author work.

中文说明

置信度：3/5 —— 代码本身值 4/5；缺的是证据，不是质量。

退一步看：方案与我独立设想的一致，diff 恰好是目标所需的最小集合（无顺手改动，测试代码多于生产代码，附设计文档），信任边界的处理符合本仓库 daemon 路由的惯例——失败关闭、绝不回退到不可信工作区、绝不把上下文切换泄漏成会话创建。六个月后读这段代码，会觉得它细致，而不是让人骂。

那为什么不批？因为那样等于为不存在的测试结果背书。这个 head 上所有实质 CI 检查都在 main 既有的 packages/cli 构建错误处中断，一个测试都没跑到——单元套件、独立模式 Playwright、视觉捕获对本次提交都是零信号。现在批准就是为一个没人见过的绿色套件作证。作者的本地数据看起来合理，静态审查也没发现问题，但"看起来合理"不是标准。

⏸️ 暂缓，等 CI 真正跑到本 PR 的测试。这里不要求作者做任何事——阻塞点是 main 上的 output-style/never 构建错误（它挡住的是所有 PR 的 CI，不只是这个）。main 恢复构建后：重跑本 PR 的 CI；如果在 f98f7edae3707807afe2f7bf0c45fd65ac310ff4 上变绿，@qwen-code /triage 重跑即可转为批准，无需作者再改代码。

— Qwen Code · qwen3.8-max

_{Reviewed at f98f7edae3707807afe2f7bf0c45fd65ac310ff4 · re-run with @qwen-code /triage}

[doudouOUC]

Closing as superseded by #10777, which is now merged and resolves the original regression with the smaller workspace-first approach: the sidebar New task inherits its context, standalone remains an explicit composer target, and workspace navigation stays reachable outside workspace chats.

This PR also explores broader behavior for Plugins, Scheduled Tasks, and workspace-owner routing in standalone mode. Those changes are not required for the regression fix. If they are still desired, they should be reconsidered in a focused follow-up based on the current main branch instead of resolving conflicts in this alternative implementation.

关闭原因：#10777 已通过更小的方案解决原始回归。本 PR 中 standalone 模式下的 Plugins、Scheduled Tasks 与 workspace owner 路由属于额外产品范围；如后续仍需要，建议基于最新 main 单独提交一个聚焦的后续 PR。