v0.5.0 — 健壮性：超时+重试+轮换

健壮性修复：

• taskTimeoutMs（默认 30min，0=不限）：单任务超时 → interrupt + 记 failed，防 worker 挂死
• maxRetries（默认 1，0..3）：失败换新子代理自动重试（retryDelayMs 5s），覆盖瞬态故障
• tasksPerWorker（默认 12）：worker 轮换防长批上下文累积污染
• per-run subagent/end 监听：只登记本池子代理，零噪音随 run 注销
• 超时文案按秒显示、结果行显示重试次数（×N）

真机实测：4 任务并发 2 → 仅 2 个 worker 子代理、4/4 完成补位激活；15s 超时任务 ×2 次尝试正确失败；坏模型任务自动重试并带底层错误详情；前台模式回归通过。

v0.4.0 — 工作器池性能优化

性能优化（工作器池）：持久子代理数 = 并发数而非任务数——每任务不再新建子会话，Web 会话回显与子代理目录负载不再随任务数增长（实测：189 个子代理 → listChildren 13.6s，每冷子代理折叠 ~68ms；64 任务批次旧引擎 64 个子会话，新引擎仅 maxConcurrency 个）。worker 串行处理任务（首任务随 startContinuable 创建派发、后续 subagents.followup，subagent/end 逐回合结算）；中止宽限期 1s 防丢结果；kill 前完成的任务记 completed。

v0.3.0 — 结算反馈可靠性 + 实时进度

结算反馈可靠性修复（用户实测：池汇总通知 0 送达，模型自行 job_output 轮询只拿到裸状态串）：

• job readOutput：每任务结算即更新进度文本（N/M settled + 逐行结果），job_output 实时可见；终态输出完整汇总——富文本结果不再只存在于回调消息
• 宽松校验：model/description 空字符串视为未提供（修复模型传 model:"" 导致整批被拒）
• 引导文案收紧：长批默认后台；job_output 可看实时进度；仅小批量快速任务用前台

实测：model:"" 批次正常受理；中途 job_output 显示 1/3 settled + 逐行结果；终态返回 3/3 完整时间线。

v0.2.0 — continuable 子代理接入默认插件体系

完整接入默认子代理插件体系（此前池用 one-shot 子代理：面板不可见、无原生通知，用户看到只有一个后台任务）：

• 池子代理改为 startContinuable（与默认 subagent 工具同型）：子代理面板实时可见（running 徽标）、完成即平台原生通知、保留为可续跑子代理（失败任务可追问重试）
• 结算改由 subagent/end 事件驱动（stopReason + lastAssistantMessage），长轮询等待；中止时逐个 interrupt in-flight 子代理

实测：批任务运行中 listChildren 显示 mode=continuable 且 live agents running；每个子代理完成都有原生 Background subagent 通知；池汇总照常投递。

v0.1.0 — 后台非阻塞 + 滚动补位 + 自动投递

后台非阻塞模式 + 模型使用引导（此前池工具调度正确，但主对话仍要等整批结束，且模型没有被引导去用它）：

• 后台模式（默认）：提交毫秒级返回 job id，池在后台滚动窗口补位，全批结算后完整结果（每任务时间线）作为会话消息自动投递、唤醒主对话；job_output/job_kill 可用
• 前台模式（background:false）：等待整批完成内联返回（保留）
• 系统提示引导段（order 110）：2+ 独立任务整批交给任务池，替代手动逐波派发 subagent
• 依赖落地：loader 内部解析器不读 package.json，dsh-llm 及传递闭包改为真实副本 + 包根 index.js 垫片

实测：4 任务并发 2 后台批 43ms 返回，滚动补位激活（#3 于 #2 结束前启动），18.1s 完成 4/4，结果自动投递。

v0.0.2 — 失败详情富化 + signal 兜底

修复测试中发现的两个问题（测试触发：子代理因模型路由 402 余额不足失败，被误判为插件问题）：

• 失败详情富化：子代理失败时经 subagent/end 事件定位子会话，回读 turn/end 底层错误（如 Insufficient Balance、no adapter）并入结果 error 字段
• signal 兜底：spawn 路径要求 request.signal 存在，缺失时用一次性独立控制器兜底，修复 start 崩溃路径

诊断结论：v0.0.1 本身调度逻辑无缺陷（滚动补位时间线证据完整）；子代理失败根因是 deepseek2 路由余额耗尽（402 QUOTA），标准 subagent 工具同样失败。

v0.0.1 — 动态滚动窗口子代理任务池首发

parallel_pool 工具：一次调用跑完整批独立任务，内部滚动窗口补位（任何子代理一结束立即派发下一任务，无轮次屏障），返回每任务起止时间线。

• 入参：tasks[{prompt, description?, model?}]（≤64）+ maxConcurrency（默认 4，1–16）+ provider（spawn/fork）+ failFast
• 返回：completed/failed/aborted/skipped、总耗时、峰值并发、rollingRefill、每任务时间线
• 实现：ctx.subagents.start 派生一次性子代理，结算回调触发补位；exec.signal 中止即返回部分结果；结果按 150KB 预算截断
• 生命周期：全部注册挂 ctx.effect，卸载即净；支持注入器热重载
• 实测：4 任务（sleep 1s/6s/1s/6s，并发 2）4/4 完成 19.4s，滚动补位激活（#3 于 #2 结束前 4s 启动）
• 安装：dev_inject_plugin /projects/dsh/dsh-parallel-pool（或 dev_install_package 持久化）