Windows 桌面版无法添加工作区：workspaceController is unavailable

[LXC-code-1]

你好，我在 Windows 上使用 DeepSeek Harness 时，添加工作区失败。

报错：
workspace create failed: gateway/service-unavailable:
typert gateway: workspace/create:
active Service "workspaceController" is unavailable

复现步骤：

1. 打开 DeepSeek Harness
2. 添加工作区并选择 E:\workplace
3. 点击“选择文件夹”后出现上述错误

已排查：

• 文件夹 E:\workplace 已存在
• 原版本 0.2.1-rc.3 下报错
• 回退至 0.2.0-rc.2 后仍报错
• 备份旧 profile、使用新建的 desktop profile 后仍报错
• workspace.json 是有效 JSON，sessions 目录为空

请问如何诊断并修复 workspaceController 未启动的问题？

[Smalldy]

补充一个已确认的同类根因与修复路径（Windows x64 / dsh-desktop 0.2.1-rc.3 / Electron 44.7.0 / Node 24.21.0）。

workspace.json 是合法 JSON ≠ 通过 schema。workspaces 表里任意一条记录不满足 workspaceRecord（path、title、sessionIds、createdAt、updatedAt 必须存在，时间戳必须是 ISO-8601 字符串）时，宿主会抛：

DomainError: domain 'workspace': stored record '<id>' in table 'workspaces' does not match its schema
ZodError: createdAt: expected string, received undefined
         updatedAt: expected string, received undefined

于是 @deepseek-ai/dsh-workspace 的 domain 打不开 → workspaceRegistry 不激活 → 依赖它的 workspaceController 一直 pending。桌面端不会因此崩溃，所以 UI 只显示 active Service "workspaceController" is unavailable，真实原因只在宿主 stderr 里。

修复（先完全退出 App，并备份 ~/.dsh/storages/workspace.json）：

1. 检查 workspaces 表每条记录是否都有上述 5 个字段，时间戳补成 ISO 字符串（例如 2026-01-01T00:00:00.000Z）；
2. 如果确认是废弃记录，可删除该记录，并同步从 global.workspaceIds 移除；
3. 重启 App。

验证：单独启动宿主时不再出现 entries did not activate，workspace/create 返回 ok: true。

注意：

• 新建 profile、回退版本、重装都绕不过，因为坏记录仍在同一个 storage 文件里。
• 这与凭据、HOME、目录权限无关；合法 JSON 里的字段错误同样会触发。

建议上游：把 workspace domain 像 session-projection-cache 一样启用 invalidRecords: 'backup-and-skip'（#6781 的评论里给了源码位置），或至少在桌面端把失败记录 id / 宿主日志路径暴露出来，而不是只给一个泛化的 service-unavailable。

[123456wcom]

你好，我遇到与本讨论相同的问题，想请教如何安全恢复。 • Windows，DeepSeek Harness 0.2.1-rc.5 • 错误：workspace create failed: gateway/service-unavailable: typert gateway: workspace/create: active Service "workspaceController" is unavailable • 原目录：C:\Users\吴.dsh • storages 中原本没有活动的 workspace.json，有多个 .bak / .broken 文件；我已把 workspace.json.broken-20261102 复制成 workspace.json 测试，但应用仍显示“正在加载工作区”，列表为空。 • 会话文件仍在 sessions 中；例如 ...\bili-whale\session.v4.jsonl.zstd 为 2,911,171 字节。 • 我已备份整个 .dsh 到 D 盘，并另做一份安全副本，目前没有改动会话文件。 能否请维护者指导：如何在 Windows 上取得宿主 stderr/启动日志，并检查 workspace.json 是否有不符合 workspaceRecord schema 的记录？我希望先只读诊断，不覆盖会话数据。若需要，我可以私下提供脱敏后的配置片段和日志。请特别告知恢复未分类会话索引的安全步骤。

[LXC-code-1]

这是我的解决方法

根因：升级后 .dsh\storages\workspace.json 处于损坏/失效状态，导致宿主的 workspaceController 服务挂载失败——它挂载失败，网关上就没有 workspace/create 这个路由，于是点「添加工作区」必然报 service-unavailable。关键点：把 broken 文件复制回 workspace.json 是没用的（我一开始也这么试过），文件本身就是坏的，必须删掉让应用重新生成。会话数据（session.v4.jsonl.zstd、.whale 等）与 workspace.json 是分开存储的，删除它不影响会话历史——我的会话完好无损。

解决步骤（Windows）：

完全退出 DeepSeek Harness（确认任务管理器里没有残留进程）。
备份并删除损坏的工作区状态文件：
C:\Users<你>.dsh\storages\workspace.json（连同 .bak / .broken 副本一起清掉，避免混淆）
正常启动应用，重新在界面里添加工作区文件夹。
验证：此时 workspace.json 会被重新生成，内容大致是 { "workspaces": [ { "path": "E:\xxx", "createdAt": "..." } ] }，会话自动回到该工作区下。
如何抓宿主 stderr / 启动日志：用 PowerShell 带重定向启动，不依赖 IDE：

powershell
复制
Start-Process "C:...\DeepSeek Harness.exe" -WorkingDirectory "C:..." -RedirectStandardOutput "$env:USERPROFILE\dsh-boot-out.log"
-RedirectStandardError "$env:USERPROFILE\dsh-boot-err.log"
看 dsh-boot-err.log：如果服务挂载失败，会出现 N entries did not activate 警告，会逐条列出哪个条目失败/等待中及原因（我当时的判断依据就是它）。注意：dsh-boot-out.log 里含网关 token（本机访问凭据），发帖求助时务必删掉或打码。

关于 schema 检查：不用逐字段校验，直接用上面的「删除重建」法更稳妥——合法记录就 path + createdAt 两个字段，手工拼装容易再踩坑。纯只读诊断的话，看 did not activate 列表即可确认是不是 workspaceController 在等待/失败。