终端页签标题无法跟随按会话改写后的实际 shell（spawnTerminal spec 无显示名字段，title 固定为组合级 shell.name）

[Big-Dao]

Motivation

现状

TerminalController.spawn 在调用 provider 之前就把页签标题定死为解析出的 shell profile 名（packages/api/terminal-controller/src/index.ts）：

const info: WebTerminalInfo = {
  id: request.id, shell, title: shell.name, cwd: environment.cwd, ...
}

shell 来自组合级配置 config.shell，resolveShell 里 resolveExecutable 只替换 path、保留 name。而：

• SubprocessTerminalSpawnSpec（dsh-subprocess）没有任何显示名字段（只有 argv / cwd / env / rows / cols / terminalType / shellActivity / graceMs / signal）；
• SubprocessTerminalHandle 也不回读实际启动的程序。

所以任何在 spawnTerminal 里改写启动的 provider，对页签标题都是不可见的。

受影响的场景

dsh-plugin-wsl-env（WSL 插件）的按会话路由：subprocess-wsl.hostSessions 会把 Windows 目录会话的 wsl.exe 启动改写为 powershell.exe -NoLogo（Windows 目录会话运行 PowerShell，而不是落在 /mnt/<盘符>/… 的 distro shell）。功能正确，但页签仍显示 profile 名 WSL——PowerShell 进程顶着 WSL 标题。

插件侧无法自救（三条路都实测封死）

写这个提案是因为补丁层看起来像能解决，实际不能：

1. 用子类替换控制器行的模块：补丁层契约是 "A truthy name asserts the existing plugin name rather than renaming it"（packages/boot/app-boot/src/config-schema/document.ts）——按 id 覆写只能整块替换 config，不能换 name。

2. 禁用官方行、以新 id 插入子类行：行 id 被 web 组合承载。web-app bundle 插入的 terminal-controller 行注册 terminal 远程命名空间，客户端的 webTerminals 服务以 inject = ['remote', 'remote.terminal'] 挂载。禁用该行后 web boot 失败（dsh-desktop 0.2.0-rc.2 实测）：

   Error: web boot: 1 entry did not activate
   @deepseek-ai/dsh-client-ui-sidebar-terminal: pending (waiting for service: webTerminals)
   

3. 按会话的配置：shell profile 是组合级状态；!!js 表达式在配置解析期求值一次，触达不了 Session。

当前用户变通：双击页签手动重命名；或在用户层给 terminal-controller 行加 shellCandidates（手动选中的 shell 以自身命名）。

Behavior

提案（两选一，第 1 个最小、向后兼容）：

1. SubprocessTerminalSpawnSpec 增加可选 displayTitle（或 SubprocessTerminalHandle 暴露实际启动的 argv）；create() 在存在时用它作 info.title，否则回退 shell.name。改写启动的 provider 声明它实际启动的程序，其余一切不变。
2. 或者控制器自行从生效程序取标题：生效 argv[0] 与 shell.path 指向不同程序时用 executableName(effectiveArgv[0])，否则维持 shell.name。

两种方案下，不改写启动的 provider 与现有配置的标题行为完全不变。

Environment

• deepseek-harness / dsh-desktop 0.2.0-rc.2
• @deepseek-ai/dsh-api-terminal-controller 0.2.0-rc.2
• Windows 11 + WSL2，dsh-plugin-wsl-env（npm 公开包）

[Big-Dao]

补充现状（2026-11-01，dsh-plugin-wsl-env 侧，基于 0.2.1-rc.5 运行时复核）

这个缺口的插件侧缓解已落地并发布（dsh-plugin-wsl-env 0.17.0），两点现状供参考：

1. 插件已内建 shellCandidates 缓解。 组合层不再只配一个 shell profile，而是 shellCandidates: [wsl.exe, powershell, cmd]。按本讨论指出的行为（手选 shell 以自身命名），Windows 工作区的会话手选 PowerShell 后页签标题正确。但默认条目——新开标签未经选择时——仍读 shell.name，宿主会话的 PowerShell 照旧顶着 WSL 标题，这正是本讨论请求的 seam。

2. 源码位置复核无变化：

• packages/api/terminal-controller/src/index.ts:327：const info: WebTerminalInfo = { id: request.id, shell, title: shell.name, cwd, ... } —— 构建于 subprocess.spawnTerminal(...) 返回之后，不读回实际启动的程序；
• 同文件 spawn()：spawnTerminal 调用参数为 argv/cwd/cols/rows/terminalType/env/shellActivity/graceMs/signal，无显示名字段；
• shells.ts 的 resolveShell 路径表明：手选 shell 的标题来自候选自身的 name——这是当前唯一能让标题跟随会话的通路。

请求维持原议，两个方向任一即可闭合：

1. SubprocessTerminalSpawnSpec 增加可选显示名字段（provider 改写 launch 时声明实际启动的程序）；
2. 或 WebTerminalInfo.title 优先读回 handle 报告的实际程序。

对按路径路由执行世界的 provider（Windows/WSL 混合桌面是常态场景），方向 2 的"读回"形态更自然——provider 知道自己实际启动了什么，而 spec 在改写发生前就该被允许说清楚。