184e164091
One shared ctx.tasks registry (branded <kind>-N ids, owner-fenced read/kill/wait/list, attachSurface misconfiguration fence, reported-flag notice dedup, atomic register) + dsh-tool-tasks (task_output/task_list/ task_kill, completion-notice injection, background prompt habit). Producers opt in via their own enableRunInBackground config: bash (stream kind; seam slimmed to resolve/run/start returning a BashProcess handle, bash_output/bash_kill deleted) and subagent (final-output kind; done settles after run.dispose()). Owner disposal drains tasks through the new awaited ctx.agents.onCleanup seam in the loop's disposal chain. Both RFCs moved to implemented/; docs, catalogs, snapshots re-pinned.
tasks/ — background task capability family
The shared background-task runtime: ONE home for task ids, owner isolation, polling, cancellation, wait, and completion notification, so bash, subagents, and every future long-running tool expose the same model-facing habit instead of cloning a private task protocol each. Rationale and the full design: the background-task-runtime RFC.
| Package | ctx key | Role |
|---|---|---|
tasks (@deepseek-ai/dsh-tasks) |
ctx.tasks |
The registry service: branded <kind>-N ids, owner-fenced read/kill/wait/list, settlement bookkeeping, the awaited owner-cleanup path, and the attachSurface misconfiguration fence |
tool-tasks (@deepseek-ai/dsh-tool-tasks) |
— | The model-facing control surface: task_output, task_list, task_kill, the completion-notice injection, and the background-habit prompt section |
The split is the state/surface boundary: the registry holds task state (an HMR reload of any tool plugin never orphans or kills a running task), while the tool surface is stateless presentation. Producers (dsh-tool-bash, dsh-tool-subagent) register running work via ctx.tasks.register and keep their own execution concerns; whether a producer exposes run_in_background is that producer's own enableRunInBackground config, never rewritten by this family.