dsh-superagent Windows Desktop + 飞书 Source：11769 之后的六处新坑与端到端实测

[deepsleepzzz0211]

接着 #11769 的 windows-compat 分支继续。该补丁解决的是"能不能跑"；这篇记录的是跑起来之后在 Desktop 托管 + Feishu Source 场景踩到的六处坑，全部有实测复现与修复。环境：Windows 11 / DSH Desktop 0.2.2-rc.1 / Node 22.19 / GitHub CLI 2.103 / lark-cli 1.0.90。

一、stateDir 的 /Users/... 写法会埋一个延迟炸弹

11769 把 stateDir 校验放宽为 path.isAbsolute() 之前，Windows 用户常用 /Users/<name>/... 绕过正则（部分运行时层会映射到用户目录）。但该写法在配置了仓库、setup 走完整流程后会死在别处：

Sessions.ensure → dsh-workspace realpathNormalize:
TypeError: Workspace path is not fully qualified: '/Users/<name>/.dsh/state/superagent'

症状极具迷惑性：仓库未配置时插件正常挂载（setup 在 repositoryUnset 提前返回，走不到 workspace 创建），一旦配置仓库就整体静默消失（面板 404、无任何报错），表现为"时好时坏的启动竞态"。修复：打了 11769 补丁后直接写盘符路径（C:/Users/<name>/...）。

教训：插件导入/激活失败在 Desktop 模式下完全不可见，只有用 CLI 启动同 profile 的副本才能看到 entries did not activate 那行 warning。排障时复制 profile 用 dsh --profile <副本> 启动，日志全部可见。

二、worker 的 git 环境：GIT_CONFIG_NOSYSTEM=1 会丢掉 http.sslBackend=schannel

dsh-superagent 为 worker 生成独立 gitconfig（GIT_CONFIG_GLOBAL=<stateDir>/worker-gitconfig + GIT_CONFIG_NOSYSTEM=1），即同时绕过操作员的系统级和全局 git 配置。在中文网络环境，系统级配置里的 http.sslBackend=schannel 和全局的 http.schannelCheckRevoke=false 都被丢掉，worker 的 git 落到 OpenSSL 后端，fetch 报：

fatal: unable to access 'https://github.com/.../': schannel: next InitializeSecurityContext
failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012)

本地裸 git 一切正常，极易误判为网络抖动。确定性复现：

GIT_CONFIG_GLOBAL=<stateDir>/worker-gitconfig GIT_CONFIG_NOSYSTEM=1 git fetch ...

修复：在 src/infra/environment.ts 的 worker-gitconfig 生成处，win32 追加 [http] sslBackend = schannel + schannelCheckRevoke = false（+4 行，已实测验证）。建议上游考虑把这两项作为 Windows 默认或可配置项。

三、飞书 Source 的 CLI wrapper：Windows 上需要承担四项职责

官方文档的 lark-cli 配置是一个 POSIX sh wrapper（设 LARKSUITE_CLI_CONFIG_DIR 隔离 bot 身份）。Windows 上 Source CLI 必须是可直接 spawn 的 exe（.cmd/.bat 会被按名字拒绝，sh 脚本无法 spawn），我们用 MinGW 编了一个 ~100 行的 C wrapper，实测发现它必须承担四项职责，缺一不可：

1. 隔离 bot 配置目录（设 LARKSUITE_CLI_CONFIG_DIR；操作员个人 lark-cli 配置不受影响）
2. 修复 MSYS 路径改写：DSH 的部分命令层经 sh 启动时，MSYS 运行时把 /open-apis/bot/v3/info 这类参数改写成 <msys-root>/open-apis/bot/v3/info，飞书 API 直接 404 → setup 报 feishuNoBot（手工直跑却正常，极易误导排查方向）。wrapper 把该前缀的参数改回 /...
3. 自持 stdin 管道：lark-cli event consume 以 stdin EOF 为退出信号；Node 的重叠（overlapped）stdin 管道被它立即读成 EOF，消费者"0 秒退出（reason: signal）"无限重试。wrapper 用 _pipe + _dup2 给 lark-cli 一个永不关闭的 stdin（停止走 SIGTERM，插件本来就会发）
4. 自行拼装命令行引号：MSVC _execv 连接 argv 时不给含空格的参数加引号，中文回复文本被拆成一堆 positional 参数（lark-cli 报 "positional arguments are not supported"），回复投递失败（SyntaxError: Unexpected end of JSON input）。改用 CreateProcess + 标准 Windows 引号规则

另注：lark-cli 的绑定建议用 config init --new 的验证 URL 流程（CLI 输出 URL → 浏览器确认 → "选择已有应用"），App Secret 完全不经过终端/聊天；config init --app-id ... --app-secret-stdin 需要 TTY，后台运行会直接报错。

四、GitHub Source：自提及不产生通知

Agent 账号靠它自己的通知接活。GitHub 不为账号自己对它自己的 @提及/assign 发通知——如果用自己的账号当 agent，自己开的 issue 里 @自己永远收不到。专用 agent 账号（协作者 + Write 权限）+ 独立 GH_CONFIG_DIR 是必须的；GH_CONFIG_DIR 可以放进 profile 的 .env（DSH 启动时加载，仅影响该 profile），避免 wrapper。

五、端到端实测结果

配置完成后双通道各跑了一轮真实任务（"读仓库 README 并总结，不改代码"）：

通道	触发 → 确认	Ticket → 交付	结果
GitHub（issue 评论 @bot）	< 1 min	~1 min	✅ 确认 + 回帖，含免责声明
飞书（群内 @bot）	首条轮询即命中（~12 s）	~3 min	✅ 确认 + 群内回复（修复引号问题后投递成功）

期间共复现并修复：worker git TLS（第二节）、wrapper 路径修复（第三节-2）、stdin 管道（第三节-3）、命令行引号（第三节-4）。eval 全程 observe 模式（显式请求不受影响，照常执行）。

六、排障速查

症状	根因位置
配置仓库后面板 404、无报错	stateDir 路径 + Sessions.ensure（第一节）
feishuNoBot 但手工调用正常	wrapper 是否处理 MSYS 前缀（第三节-2）
消费者 0s 退出 (reason: signal) 循环	wrapper 的 stdin 管道（第三节-3）
回复报 Unexpected end of JSON input	命令行引号（第三节-4）
Ticket prepare 报 CRYPT_E_NO_REVOCATION_CHECK	worker git sslBackend（第二节）

代码改动（worker gitconfig 两行 + wrapper）都在本地 fork 验证通过；如果社区需要，可以整理成分支。Windows Desktop 用户建议：插件激活失败先看 CLI 副本启动的日志，别只信面板的"没有响应"。