运行配置管理 xiaoso456/dsh-run-config

· Added · 插件图标与 README 词标（品牌资产）：assets/ 新增插件页图标 icon.webp（448、圆角 104、WebP 无损，由 1254² 母版按黄金比例裁框而来，205 KiB）、README 头图 icon-full.webp（整幅不裁）与词标 wordmark.png（Jua 400，三色 #4d6bfe / #37b3cb / #e0a93f）。package.json 顶层 icon 指向 assets/icon.webp，files 同时收进 icon-full.webp 与 wordmark.png——README 引用了它们，不进包则 npm 包页面上的两张图会 404。两份 1254² 母版（icon-source.png / icon-art.png）入库但不进包 · 两版 README 的居中排头：开头改为居中「icon-full.webp（宽 140）+ wordmark.png（宽 360）」并去掉 H1，正文不变；中英两版同步 · Fixed · 命令任务不再被 shell 执行器的默认截止时间杀掉：shell.resolve 现在显式传 onExpiry: 'none'。此前它没传，于是落到执行器默认值（PwshLocalExecutor / LocalBashExecutor 的 onExpiry: request.onExpiry ?? 'kill' + timeoutMs 默认 120000），任何超过 2 分钟的命令任务都会在第 120 秒被 deadline 杀掉，且因为 killed 一律被映射成不带 detail 的 { status: 'killed' }，在会话里只表现为一句 finished [status: killed]、job_output 空空如也，完全看不出原因（真机实例：pi-agent 的「Build Gateway Binaries」两次被杀，间隔精确 120s）。背景作业本就不该受执行器 deadline 约束——官方 dsh-tool-bash / dsh-tool-pwsh 在后台分支同样显式传 onExpiry: 'none'，只由作业自身生命周期（cancel / owner 回收 / 服务 teardown）决定何时结束。注：这是 dsh 0.1.7 的官方回归——0.1.5/0.1.6 的 shell.start() 后台路径本就注释写明「Background runs ignore timeoutMs」，0.1.7 的 d6bebc5783 把 run()/start() 合并为 execute() 并引入 onExpiry（默认 kill）后，后台不再豁免（该提交自述 "the 'start ignores timeoutMs' wart dies"）。我们插件迁移 0.1.7 时只换了 API 名、没跟上默认语义 · cancel 现在也能中断「准备阶段」：作业持有自己的 AbortController，signal 随 spec 交给执行器；cancel 先 controller.abort(reason) 再对已存在的句柄 kill()。此前 cancel 只能对已解析的 ShellExecution 调 kill()，若 kill 请求到达时进程尚未 spawn 完成（慢启动 / 受限模式下的 confine 准备），这次取消会整个丢失。受限执行器在准备阶段被 abort 时会 reject execute（dsh-pwsh-sandbox 的 mapError 在 spec.signal.aborted 时重新抛出），该分支按官方 processJob 的口径映射为 killed 而非 failed · killed 的起因不再被抹平：{ status: 'killed' } 现在带上 signal: （或 killed before exit），于是「deadline 杀 / 用户 job_kill / owner 回收」在通知里可区分。刻意不回显 killedReason——dsh-jobs-local 结算时本就会把它追加进 detail（killJob → ${detail}; ${killReason}），回显会得到 user stopped it; user stopped it · 任务写入边界加固：type / scope 现在经运行时白名单校验（RPC 参数、工具 schema 的 enum、validateTaskInput 三处），并在存储边界再校验一次。此前非白名单值会被原样写进存储，而存储层只在 open 时解析记录——一次坏写就会让下次 open 失败、openTaskS

· [0.2.2] - 2026-09-29 正式版，发布在 latest。适配 dsh 0.2.0-rc.2。与 0.2.1 互不兼容（peer 精确写死，运行时版本不一致就会被官方闸门禁用）：dsh 0.2.0-rc.1 线继续用 0.2.1，0.1.7 线用 0.2.0。 · Changed · 适配 dsh 0.2.0-rc.2：33 个 dsh devDependencies 与 13 个 peerDependencies 由 0.2.0-rc.1 精确改到 0.2.0-rc.2；pnpm-workspace.yaml 的发布年龄白名单同步加白。零业务代码改动——逐包核对官方 rc.1→rc.2 的 187 个提交（630 个文件）后确认本插件用到的契约全部未变：实质源改动只有 IconThinkOutline* 的图形微调、新增 MenuGroup 组件、ui-renderer 的一处 hooks 顺序修复、ui-workspace 把重命名快捷键从 Ctrl+Alt+R 改成 Ctrl+Alt+G、api/remotes 多挂一个新包 dsh-user-questions · 验收脚本参数化：6 个仍写死 的 tests/cdp-*.mjs 改为读 DSH_BASE（12 个脚本口径一致；3190 被其它实例占用时一样能验收） · tests/cdp-llm-run.mjs 补上 hero「先绑定工作区」前置：未绑定工作区时点运行只会把 prompt 填进草稿、无法提交，send 分支会因此假红（实测 3/3 确定性失败，先在 hero 选好工作区即恢复正常）；菜单选择同时改为「点开即读 + 重试」（菜单卡会被「工作区/任务列表落地」关掉，一次性 sleep 会错过窗口） · 说明 · 真机验收（全局 CLI 0.2.0-rc.2 + 独立 profile 端口 3191 + 全新 profile 的 headless Chrome）：插件加载零错误（闸门通过）；e2e-crud 8 个 RPC 端点全通并自清理；client bundle 到达 HTTP 200；cdp-refresh / cdp-header-order / cdp-workspace-select / cdp-combo / cdp-llm-run（send 与 fill 两分支）/ cdp-double-run / cdp-config-description-clear / cdp-shot 全过、console error 0 · 自测：tsc --noEmit 0 诊断 · 109 单测全过 · biome check 0 error · tsdown 构建 0 · build:types 0；官方 API 触点逐符号核验 63/63（含 15 个纯副作用导入可达） · 数据无迁移：任务仍在 $DSH_HOME/storages/task_runner.json（domain task_runner），RPC 端点、工具名、locale、slot 挂载点均未变 · 说明 · 与 0.2.1 互不兼容：本版 peer 精确写死 0.2.0-rc.2，0.2.1 写死 0.2.0-rc.1；官方闸门按 semver.satisfies(runtime, range, { includePrerelease: true }) 判定，运行时版本不一致的那一版会被禁用。dsh 0.2.0-rc.1 线请继续用 0.2.1，0.1.7 线用 0.2.0，0.1.5 线用 0.1.5 · 适配本身零业务代码改动：官方 rc.1 → rc.2 的 187 个提交里，本插件用到的契约全部未变 · 数据无迁移：任务仍在 $DSH_HOME/storages/task_runner.json（domain task_runner），RPC 端点、工具名 task_run_config、locale 命名空间、slot 挂载点均未变 · 自测：tsc --noEmit 0 诊断 · 109 单测全过 · biome check 0 error · tsdown 构建 0 · build:types 0；官方 API 触点逐符号核验 63/63（含 15 个纯副作用导入可达） · 真机验收（全局 CLI 0.2.0-rc.2 + 独立 profile 端口 3191 + 每脚本全新 headless profile）：插件加载零错误（闸门通过）；e2e-crud 8 个 RPC 端点全通并自清理；client bundle 到达 HTTP 200；cdp-refresh / cdp-header-order / cdp-workspace-se

· [0.2.1] - 2026-09-28 正式版，发布在 latest。首个适配 dsh 0.2.0-rc.1 的版本。版号取补丁位是有意的破例（维护者拍板）：本版把 13 个 dsh peerDependencies 精确写死为 0.2.0-rc.1，因此在 dsh 0.1.7 线上会被官方闸门禁用——对使用 ^0.2.0 的环境而言，这等于「补丁号里含破坏性变更」，按 semver 本应是 0.3.0。升级前请确认运行时就是 0.2.0-rc.1。本版同时收进 0.2.0 之后未发布的运行控件 UI 迭代（窄视口、加载三态、拖拽、连点门、保存提示等）。 · Added · 新增 client 侧纯函数模块（无 React/浏览器 API，可单测）：core/createInput.ts（对话框「新增」的作用域推导）、core/pendingRun.ts（hero → 会话的待运行交接规则）、core/firstVisibleTask.ts（对话框打开时的默认选中）、core/taskListState.ts（列表「加载中 / 空 / 失败」三态推导）、core/draft.ts · 新增 UI 组件：components/Spinner（加载态转圈，尊重 reduced-motion）、components/TaskListNotice（加载中 / 加载失败的行内提示） · 新增验收脚本与基础设施：tests/lib/{cdp-endpoint,cdp-chrome-launch,web-session}.mjs（CDP 端点可覆盖、私有 headless Chrome 启动、launch token 换会话 cookie 与 RPC 调用）、tests/cdp-{reorder,saved-hint,double-run,config-description-clear,hero-add-workspace}.mjs、tests/external/（外部依赖验收通道：本地 mock provider + 编排脚本） · 新增单测：tests/{create-scope,draft,pending-run,store-upsert,task-update-patch,ui-state,vitest-collection,acceptance-tooling}.spec.ts · Changed · 适配 dsh 0.2.0-rc.1（npm next 线）：插件版号 0.2.0 → 0.2.1。33 个 @deepseek-ai/dsh-* devDependencies 与 13 个 peerDependencies 全部对齐 0.2.0-rc.1，且 peer 精确写死（不写 ^）。本轮零业务代码改动（证据见 docs/决策记录.md D31）：tsc --noEmit 0 诊断、109 单测全过、biome check 0 error、tsdown 构建 0、build:types 0；官方 API 触点逐符号核验 63/63 解析到 0.2.0-rc.1 的真实声明（含 15 个纯副作用导入可达）；宿主真实包验证 verify-skill / verify-tool-schema / verify-pwsh 全过。逐包核对官方 packages//src 后确认本插件用到的表面全部未变——jobs / shell / tools / storage-domain / skill / settings / client-connection / client-locale / client-ui-settings / client-ui-slots 等包在 0.1.7-rc.2 → 0.2.0-rc.1 之间只改了 package.json 的版本号（源码逐字节相同）；客户端契约的改动全是可选新增（SessionInput.submit(mode?, source?)、ISessions.fork({onCreated?})、UiWorkspace.forkSession(id, onCreated?)），本插件的调用点都不传这些新参数 · peer 精确写死的已知后果（用户要求，接受）：官方插件版本闸门是 semver.satisfies(runtimeVersion, range, {includePrerelease:true})（官方 packages/boot/app-boot/src/plugin-compatibility.ts:77，0.1.7-rc.2 → 0.2.0-rc.1 之间该文件无改动）。写死版本意味着运行时只要不是 0.2.0-rc.1（如 0.2.0-rc.2、0.2.0