「环境检查」显示 explicit:github，「改色弹窗」报 no-backend —— 疑似启动早期用进程 cwd（安装目录）当工作区

[zhengcookie]

版本：dsh-mattpocock-skills-deck@1.7.51 + DSH 桌面版 dsh-plugin-desktop@2.0.17（win32）。

现象

同一个工作区、同一时刻，两个界面给出互相打脸的结论：

• 环境检查：10/10 全绿，其中「已选择后端」显示 explicit:github
• 改色弹窗（「复制推荐配色 prompt」）：橙色提示条「这一次未能读到这个后端的标签颜色存放在哪里，因此未生成提示词。……」

用户的工作区确实是个 git 仓库（gh:remote、tracker:initialized 都 pass），所以第一反应是「这两句话总有一句错了」。查下来两句都对 —— 只是它们读的不是同一个 cwd。

诊断

一、两句读的是两个不同的字段

	no-backend	explicit:github
出处	lcCopyPlanOf() → moduleMetaOf(store, backendId) 返回 null → reason:'no-backend'	backendSelected 谓词读 ctx.explicitBackendId → detail:'explicit:'+…
数据源	store.selection.backendId（运行时按 cwd 解析出来的选择）	ctx.explicitBackendId（cwd 里的静态声明）

两者不同字段、不同层，所以可以一个 pass、一个空，同时成立。

二、于是问题变成：两条链各读哪个 cwd

用本仓自带的 hash8（djb2，h = h*33 + charCode，取末 8 位十六进制）复算 cwdHash，两种值泾渭分明：

cwdHash	是哪	source	explicit	matches	selection
0f31f571	真实工作区（git 仓库根）	git	true	0	github
0f7b629e	DSH 桌面版安装目录（= 宿主进程 cwd）	self	false	0	""

detection.detect 全量 258 条：真实工作区 251 条全是 selection:"github"；安装目录 7 条全是 selection:""。

那 7 条全部落在「刚启动 / 刚重载」的瞬态里：

08:47:14   ← host.start 08:47:12
09:07:08 / 09:07:12
12:36:30   ← host.start 12:36:22
13:38:27
14:32:24
14:53:25

顺带一个观察：matches 258/258 全为 0 —— 从来没有一次是靠「内容匹配」选到后端的，selection 完全由 explicit 声明撑着。副作用是 registry.select 在真实工作区上耗时恒定 ≈3000ms（每轮都要把 3 秒的匹配探测跑完才回落到已经声明好的 explicit）。

我认为的根因

lib/index.js:32：

const DEFAULT_CWD = (typeof process !== 'undefined' && typeof process.cwd === 'function') ? process.cwd() : ''

桌面端从快捷方式启动时，process.cwd() 就是可执行文件所在目录，即 DSH 安装目录。宿主启动早期（会话/工作区尚未就位）任何没带 cwd 的调用都会回退到它，而 tracker/detection/detectionService.js:105-107 的注释也把这条约定写明了：

// 入口先洗 cwd（空值保持空串——上层 handler 已回退 DEFAULT_CWD；洗钥匙异常则回退原串）。

这个目录恰好：不是 git 仓库（source=self）、没有 docs/agents/issue-tracker.md（explicit=false）、自动识别 0 命中（matches=0），于是 selection 落空。isWorkspaceEmpty() 也拦不住它 —— 安装目录非空，返回 false，它就被当成一个「正常但识别不出后端的工作区」继续走完。

一句话：兜底值把一个「未知工作区」表示成了一个真实存在的、但不是工作区的目录，用户于是看到「后端读不出来」，而实际原因是「当前 cwd 根本不是工作区」。

想请维护者确认三件事

1. 根因判断对不对 —— 兜底值指向一个「真实存在但不是工作区」的目录，是否就是设计外的行为？
2. 修法方向 —— 把 DEFAULT_CWD 改成 ''/null，让「未知 cwd」如实是未知（而不是产出一个空 selection），这个方向可行吗？还是有既定的做法？
3. cwd 未就绪时界面该怎么说话 —— 现在这一档文案是「未能读到这个后端的标签颜色存放在哪里」，会把用户推向「刷新一下再试」；真实原因是 cwd 根本不是工作区。是否该把这两种情形分开？

完整证据、可复核步骤，以及与我在仓库里看到的相关票（#930 的 cwd 未归一、#669 的空目录判无后端）的边界对照，都写在 #1003。