未选 Workspace 无法开始对话（Starting a conversation should not require picking a workspace）

[Mby159]

• 分类（dsh 反馈对话框）：product-interaction
• 环境：dsh 0.1.5-rc.1，Windows，Web profile

现象

Web 端在没有任何 Workspace 时，必须先选一个目录才能发出第一条消息。
对于"我只想问个问题 / 聊两句、不碰文件"的场景，输入被卡在一次目录决策上。

复现：打开 dsh web → 不添加任何 Workspace → 在输入框写消息 → 无法开始对话。

为什么值得改

1. 把"执行所需的上下文"提前到了"开口所需"。目录、cwd、沙箱边界是工具执行时才需要的东西，
   不是用户表达一句话的前提。
2. 对新用户是纯阻塞。第一次打开 dsh 的人还不知道 Workspace 是什么，就先被迫做选择题。
3. 低频但高摩擦。每次想临时问一件事，都要走一遍"选目录"的仪式，即使用不上文件工具。

关键点：模型层其实没有这个约束

这一点是我觉得最值得产品侧讨论的——"会话必须属于某个 Workspace"并不是数据模型的不变量：

1. SessionCreateRequest 里 workspace 和 cwd 都是可选的：

   // @deepseek-ai/dsh-api-session-controller lib/types/types.d.ts:253
   export interface SessionCreateRequest {
       readonly workspaceId?: WorkspaceId;
       readonly cwd?: string;
       readonly sessionId?: SessionId;
       readonly agentPreset?: string;
   }

2. UiWorkspace.startSession 的签名本身就允许不传 workspace，文档注释写明会继承当前或最近使用的 Workspace：

   /**
    * Start a New Session flow and navigate to its Session.
    * @param workspaceId - explicit target; absent inherits the current or most recent Workspace.
    */
   startSession(workspaceId?: WorkspaceId): void;
   // @deepseek-ai/dsh-client-ui-workspace lib/types/client/navigation.d.ts

3. 已经存在 "Ungrouped" 这个不属于任何 Workspace 的会话集合：Workspace 被删除后，它的 Session
   就留在 Ungrouped（见 dsh-client-ui-workspace README 的 "Managing sessions"）。

也就是说：宿主和模型层都容得下"没有 Workspace 的会话"，现成的容器（Ungrouped）也有了，
阻塞点是 hero 上那个 workspace picker 的前置校验。

建议（按改动量从小到大）

1. Ungrouped 直聊：未选 Workspace 时让 hero 主操作可用，会话落进 Ungrouped，
   首条消息照常发送。数据模型零改动。
2. 懒绑定：工具第一次真的需要 cwd 时再要求绑定目录，并给一个"把本会话绑到某目录"的入口。
   这条最贴近"想聊就聊、要干活再选目录"的直觉。
3. picker 降摩擦：最近使用置顶、提供"不使用项目 / 临时目录"快捷项、回车即可确认。
4. 如果产品上就是要保留 gate：至少在首屏用一行字解释为什么要选目录，别让新用户猜。

预期影响

• 宿主/协议层：不需要新增能力（workspaceId 可选、Ungrouped 均已存在）。
• 主要改动集中在 hero 的可用性判断与 startSession() 的调用点。
• 不破坏按 Workspace 分组的会话管理，也不影响已有会话的归属。

---

English version

Summary. In the dsh Web client, a user with no Workspace must pick a directory before the first
message can be sent. Directory choice is an execution-time need (cwd, sandbox root, tool roots), not a
precondition for talking, and for a new user it is a pure blocker: they are asked to make a decision
about a concept they have not met yet.

This is a UI-layer gate, not a model constraint. The harness already tolerates a Session with no
Workspace:

• SessionCreateRequest.workspaceId and cwd are both optional
  (@deepseek-ai/dsh-api-session-controller, lib/types/types.d.ts).
• UiWorkspace.startSession(workspaceId?: WorkspaceId) takes an optional workspace and documents that
  an absent value "inherits the current or most recent Workspace"
  (@deepseek-ai/dsh-client-ui-workspace, lib/types/client/navigation.d.ts).
• An "Ungrouped" session set already exists as the destination for sessions whose Workspace was
  deleted (dsh-client-ui-workspace README, "Managing sessions").

Proposal. (1) Let the hero primary action work with no Workspace selected and file the session
under Ungrouped. (2) Lazy binding: request a directory only when a tool actually needs a cwd, with an
explicit "bind this session to a directory" action. (3) Reduce picker friction: most-recent first, a
"no project / scratch directory" shortcut, enter-to-confirm. (4) If the gate is intentional, say why
on the first screen instead of leaving new users to guess.

Impact. No host or protocol changes required (optional workspaceId and the Ungrouped bucket
already exist); the change is confined to the hero's enablement logic and its startSession() call
site, and workspace-grouped session management is unaffected.