dsh-launch

DSH 服务管理插件：在独立 broker 进程中监督长驻服务（dev server、watcher、mock API、worker），服务在对话回合结束、会话关闭、甚至 DSH 自身重启后继续运行。单包发布——Service 侧边栏 tab、broker、模型工具全部在此包内；better-sidebar 只负责承载 tab（经其扩展 API 注入，无需任何 better-sidebar 改动）。

• 根因：pwsh 后台任务（jobs）绑定在 owner 会话作用域上，会话/回合结束时 dsh-jobs-local 会取消归属任务。
• 解法（机制参考 omp 的 launch daemon broker）：服务由 detached broker 进程以 detached + stdio 落盘 方式拉起；broker 只做监督（日志增量、pid 探活、就绪检测、崩溃退避重启），自身空闲即退；DSH 下次启动时重新拉起 broker 并按 pid 收养仍在运行的服务。

安装

前置：DSH web 环境 +（可选，仅 UI 需要）dsh-better-sidebar。

dsh plugin --profile web add dsh-launch

一条命令完成安装 + 自动挂载（包内 cordis.patch.yml 注册进 dsh.profile.bundles）。装完重启 dsh web + 硬刷新浏览器（Cmd/Ctrl+Shift+R）。没有 better-sidebar 时插件以 headless 模式运行（工具可用，无 UI tab）。

能力

| 入口 | 说明 | |---|---| | Service tab（侧边栏） | 服务卡片：标题 / logo（可选，URL 或图片路径）/ 状态徽标 / PID·运行时长·重启次数 / 启动 / 停止 / 重启 / 日志；可见时轮询本插件自有的 fenced /launch/api 路由 | | service_start | 启动长驻服务：name + command（+ 可选 cwd/title/logo/env/readyLog/readyPort/restart），等待就绪后返回；就绪判定会先剥离 ANSI 转义并对 IPv4/IPv6 双栈探测端口 | | service_stop / service_restart / service_list / service_logs | 模型工具：停止（整树杀）/ 重启 / 列举 / 读日志尾 | | ctx.launch（cordis 服务） | ping / list / start / stop / restart / describe / logs，供其他插件消费 |

架构

DSH 宿主进程 ──────────────►  dsh-launch broker（detached 独立进程）
 dsh-launch 插件(host)         ┌ 命名管道 NDJSON 协议（token 认证，管道名按
  ├ ctx.provide('launch')     │   runtimeDir 哈希，多部署不冲突）
  ├ service_* 模型工具         │ 每服务状态机：starting→running→ready→
  ├ /launch/api fenced 路由    │   stopping→exited/failed (+restarting 退避)
  └ presence 文件注册          └ 每服务：daemons/<name>/{meta.json, output.log}
         │                              │ spawn detached + unref
         ▼                              ▼
 dsh-launch 插件(client) ◄─────── 服务子进程 ×N（stdio→output.log，存活于一切之外）
  └ ctx.betterSidebar.registerTab('service')

• 运行时目录：~/.dsh/tmp/dsh-launch/（插件配置 runtimeDir 可覆盖）：broker.token、broker.pid（单实例租约）、presence/*.json（DSH 存活标记）、daemons/<name>/（元数据 + 日志，8MB 轮转）。
• 就绪检测：readyLog（输出正则，ANSI 已剥离）和/或 readyPort（TCP 探测，无 host 时同时探 127.0.0.1 与 ::1）；start/restart 等待就绪（默认 20s，上限 60s）；broker 重启收养 starting 记录时会重扫日志尾部的已滚过就绪标记。
• 重启策略：no / on-failure（默认）/ always，指数退避 1s→30s。
• Windows 命令执行：command 字符串服务经 cmd.exe /d /c <command.cmd> 由内置 node 启动器（broker/launcher.cjs）执行——detached 的 cmd 会丢失批处理子进程输出，启动器规避了该问题；整树停止用 taskkill /T。

测试

npm test
# broker 冒烟 15 项：启动/就绪(ANSI·IPv6)/日志/停止/重启/持久化/杀 broker 后收养/收养尾部重扫
# 接线 13 项：服务提供/工具注册/presence/真实 broker 往返/fenced 路由信封/围栏拒绝/客户端契约

安全说明

• 服务以运行 DSH 的同一用户身份、脱离任何沙箱执行（这是服务存活的前提）。服务等同于用户在终端启动的进程。
• /launch/api 与 /launch/service-logo 全部经过 Host 头信任围栏（loopback 或 trustedHosts）；broker 管道仅绑定本机（命名管道 + token）。
• 插件卸载（HMR/禁用）不会停止服务或 broker；broker 在无 presence 且空闲 15s 后自行退出，服务继续运行。

配置

插件行可选 config：

- id: dsh-launch
  name: dsh-launch
  config:
    runtimeDir: '~/.dsh/tmp/dsh-launch'   # 覆盖运行时目录（默认同左）
    idleGraceMs: 15000                     # 无客户端/无 presence 后的退出宽限
    maxLogBytes: 8388608                   # 单服务日志轮转阈值

限制

• 服务名全局唯一（全机一个 broker 作用域）。
• 无 PTY / 无 stdin：交互式进程请用 better-sidebar 终端。
• broker 死亡窗口内（DSH 未运行且 broker 已退出）崩溃的服务不会自动重启（detached 服务本身不受影响）。