Not every workspace is a project — 建议给 DSH 工作区加一个「用途」维度

[buhuikongpan]

现状

DSH 的工作区模型很干净:工作区按规范化目录路径归组,一个目录下的会话聚在一起,
由 ctx.workspaceRegistry 统一管理,持久化在 ~/.dsh/storages/workspace.json,侧边栏是它的投影。

但这个模型有一个隐含前提:每个工作区都是一个项目。

而真实使用里,并非所有工作区都是项目。很多时候我只想临时问一个问题、试一段一次性代码、
或者让 agent 干点跟任何仓库都无关的事——这类"临时对话"在当前的模型里没有位置。

痛点

1. 临时对话没有落脚点。 想快速问点东西,只能开一个真实目录当工作区。于是它进入工作区
   列表,和真实项目混在一起,想去掉还得手工收拾。

2. 会被动继承项目作用域。 项目指令是按会话 cwd 逐级向上加载的
   (@deepseek-ai/dsh-agent-instructions 找 AGENTS.md/CLAUDE.md)。把一个真实目录当临时
   工作区,项目约定就会被注入;即使用一个空目录,较上层的 AGENTS.md 仍可能沿祖先链命中。

3. 无法按性质组织。 区分"项目"和"随手开的临时空间"目前只能靠命名习惯,侧边栏没有
   按用途分区的能力。

4. 恢复时没有用途概念。 重启后无法表达"这几个是项目、那几个是临时工作区",
   最近打开的工作区丢掉了它本来的性质。

这不是新概念——有些 coding agent 已经区分项目工作区与临时/scratch 会话。
DSH 的工作区模型离这个能力,其实只差一个维度。

建议

给工作区加一个用途维度,而不是给会话加类型:

workspacePurpose: "project" | "conversation"    // 缺省 "project"

配套行为:

• 临时对话有固定沙箱:在应用数据目录下提供一个固定的临时工作区
  (如 $DSH_HOME/workspace/default),懒创建,所有临时对话共用,不落进任何项目目录。
• 不参与项目级作用域:conversation 用途的工作区不注入项目指令、不参与项目级 bootstrap。
• 侧边栏按用途分区:「项目」/「对话」两组,分区顺序与展开态独立持久化。
• 恢复时带上用途:记录"上次打开的工作区及其用途",重启原样恢复。
• 会话级可覆盖:仍允许在单个会话上临时切换用途,不牺牲灵活性。

为什么维度加在工作区上

• 用途是工作区固有的,不是会话偶然的属性;同一目录下所有会话天然同性质。
• 现有基础设施可以复用:工作区注册表、持久化、侧边栏投影都已存在,只多一维。
• 迁移成本低:缺省 project,旧数据无需改动。

一个可参考的实现:ZCode 的做法

ZCode(智谱的编码客户端)已经把这层做出来了,可以直接当参考:

• 用途挂在工作区上,不在会话上:本地工作区描述符带 workspacePurpose: "project" | "conversation"(缺省 project);远程工作区没有这个概念。
• 临时对话有固定目录:所有临时对话共用一个位于应用数据目录下的工作区(~/.zcode/workspace/default),按需懒创建,而不是每个会话一个沙箱。
• 按工作区限定作用域时按用途过滤:内部在需要按工作区组装 bootstrap 范围时,把 conversation 用途直接跳过,所以项目级配置不会作用到临时对话上。
• UI 按用途分区:侧边栏分成「项目」「对话」两组,分组的顺序与展开态单独持久化。
• 恢复时记录用途:持久化"上次打开的工作区及其用途",重启原样恢复。
• 会话表里没有用途字段——用途是工作区级属性,查询时按工作区关联出来。

值得注意的是,ZCode 把固定单一目录作为默认:所有临时对话共用一个沙箱,而不是一个对话一个目录。

想听官方的意见

1. 这个方向是否在路线图上?
2. 临时对话工作区应该固定单目录(所有临时对话共用),还是每个对话一个独立临时目录?
3. 工作区列表是否会开放行级/分区级扩展点,让第三方能参与按用途分组,而不必接管官方
   工作区组件?

感谢!如果这个方向可行,也很想知道官方倾向的语义边界(例如 conversation 工作区是否
还应该有独立的权限/工具默认值)。

---

---

Not every workspace is a project — a case for a workspacePurpose dimension

Where things stand

DSH's workspace model is clean: workspaces group sessions by canonical directory path, are
managed by ctx.workspaceRegistry, persist in ~/.dsh/storages/workspace.json, and the sidebar is
a projection of them.

The model carries one implicit assumption: every workspace is a project.

But in practice, not every workspace is a project. Often I just want to ask a quick question, try a
throwaway snippet, or have the agent do something unrelated to any repo. That kind of temporary
conversation has no home in the current model.

The friction

1. Nowhere to put a temporary conversation. To ask something quick, I have to open a real
   directory as a workspace — so it shows up in the workspace list, gets mixed in with real
   projects, and has to be cleaned up by hand.

2. It inherits project scope by accident. Project instructions are loaded by walking up from the
   session cwd (@deepseek-ai/dsh-agent-instructions looks for AGENTS.md/CLAUDE.md). Point a
   temporary workspace at a real directory and project conventions get injected; even an empty
   directory can still pick up an ancestor AGENTS.md.

3. No way to organize by nature. Separating "projects" from "scratch spaces" is left to naming
   discipline; the sidebar cannot group by purpose.

4. No notion of purpose on restore. After a restart there is no way to express "these were
   projects, those were temporary workspaces" — a recently opened workspace loses what it was.

This isn't a novel idea — some coding agents already separate project workspaces from
temporary/scratch sessions. DSH's workspace model is only one dimension away from it.

Proposal

Give a workspace a purpose dimension, rather than giving a session a type:

workspacePurpose: "project" | "conversation"    // defaults to "project"

Supporting behavior:

• Temporary conversations get a fixed sandbox: a fixed workspace under the app data directory
  (e.g. $DSH_HOME/workspace/default), created lazily, shared by all temporary conversations, and
  never inside a project directory.
• Excluded from project scope: workspaces with purpose conversation do not receive project
  instructions and do not participate in project-level bootstrap.
• Sidebar grouped by purpose: a "Projects" / "Conversations" split, with the group order and
  expansion state persisted independently.
• Restore carries purpose: persist the workspaces that were open and their purpose, and restore
  them as they were.
• Per-session override: still allow switching purpose on an individual session, so flexibility
  isn't lost.

Why the dimension belongs on the workspace

• Purpose is intrinsic to a workspace, not incidental to a session; every session in a directory
  shares its nature.
• The existing infrastructure can be reused: the registry, persistence, and sidebar projection already
  exist — this only adds one dimension.
• Migration is cheap: project is the default, so existing data needs no change.

Prior art: how ZCode does it

ZCode (Z.ai's coding client) has already shipped this layer, so it works as a concrete reference:

• Purpose lives on the workspace, not the session: a local workspace descriptor carries workspacePurpose: "project" | "conversation" (default project); remote workspaces don't have the concept.
• Temporary conversations get a fixed directory: all of them share a single workspace under the app data directory (~/.zcode/workspace/default), created lazily — not one sandbox per session.
• Filtered by purpose when scoping work to workspaces: when composing workspace-scoped bootstrap, it simply skips conversation workspaces, so project-level configuration never reaches temporary conversations.
• Sidebar grouped by purpose: split into "Projects" and "Conversations", with group order and expansion state persisted separately.
• Restore records purpose: it persists the workspaces that were open together with their purpose, and restores them as they were.
• No purpose column in the session table — purpose is a workspace-level attribute, joined in at query time.

Worth noting that ZCode makes the single fixed directory the default: all temporary conversations
share one sandbox rather than getting one directory each.

Questions for the maintainers

1. Is this direction on the roadmap?
2. Should the temporary workspace be a single fixed directory (shared by all temporary
   conversations), or one directory per conversation?
3. Will the workspace list expose row- or section-level extension points, so third parties can
   participate in grouping by purpose without having to take over the official workspace component?

Thanks! If the direction is viable, I'd also love to know the intended semantic boundary — e.g.
whether a conversation workspace should have its own permission/tool defaults.

[exoticknight]

我做了个插件 dsh-just-chat：Web 首页和侧栏一键开始，每次创建独立工作区里的原生会话，尽量复用现有的模型、权限、附件和生命周期。它只解决“快速开始”这半步，还没有实现你提到的 conversation purpose、项目级 bootstrap 隔离或按用途分组，所以这些还是值得上游从模型层处理。

https://github.com/exoticknight/dsh-just-chat