Turtle
38c7a9fbf4
* feat(release): publish package source, declaration maps, and documentation Every release member publishes its TypeScript source and the declaration maps that resolve into it, and @deepseek-ai/dsh publishes the repository Markdown documentation staged from docs/ at prepack time. The ./src/* export most members already declared now resolves for an installed consumer, and a consumer editor follows a declaration to the implementation. Bundled JavaScript maps stay unpublished; the vendored family and the Desktop runtime file policy are unchanged. Rationale: .agents/notes/implemented/process/2026-10-08-published-source-and-docs.md * feat(release): publish JavaScript maps and compress bundles Every emitted JavaScript map ships beside the bundle it describes, and the workspace build and the client preset compress bundles without mangling identifiers. The documentation payload now mirrors the website publication manifest and is removed again by `postpack`; Desktop and the Python executable exclude the published source, documentation, and maps; `clean` removes a staged copy. Typert's publication contract gains the Remote declaration map. * fix(release): keep node bundles readable for the worker image The browser worker image lowers `yield*` only as a whole statement and rewrites `for await` loops by their source layout, so compressed node-side entries either fail that lowering or lower to unparseable code. Only the browser bundles keep compression, which removes about a third of their text. The bundle-purity assertion now matches the module-loader call regardless of the quote style compression picks, and the release-pack fixture exercises the installed package's new documentation requirement. * feat(release): publish the whole documentation tree `@deepseek-ai/dsh` copies `docs/` in full instead of the website's page set: the maintainer documents, the generated migration records, the translation guidelines, and the `*.i18n.yaml` consistency records ship with the installed package, so the documentation's own links resolve without a checkout. * feat(release): publish the upgrade guides with the documentation The staged documentation keeps the website's page set and adds every `docs/upgrade-guide/` document, which is what an installed reader consults when a released change breaks something. The rest of the maintainer tree stays out. * test(release): expect source and maps in master's new payload cases * feat(release): keep installed docs and source readable in Desktop Desktop keeps the published src/ and docs/ trees inside app.asar, and every model shell call receives DSH_INSTALL_DIR and DSH_NODE_EXECUTABLE so an agent can read them through Electron's Node mode. Staging also generates docs/upgrade-guide/README.md, an index of the upgrade guides grouped by the release they upgrade from. Minified client bundles print string literals with backticks: the worker image packer now recognizes those chunk requests, client license banners are prepended after minification so their text survives, and the affected artifact tests accept either quote. * test(desktop): read archived docs through the Windows PowerShell form Regenerate the config catalog for the shifted shell-env source line. * test(desktop): wait for the GUI-subsystem Electron process from PowerShell * build(release): publish source and maps from the message-quotes package * build(release): publish source and maps from packages new on master * build(release): publish source and maps from the tool-office package
description, kind
| description | kind |
|---|---|
| In-process spawn subagent backend for users and maintainers choosing, configuring, or debugging fresh-child delegation. | package-reference |
@deepseek-ai/dsh-subagent-spawn-in-process
English | 中文
Summary
dsh-subagent-spawn-in-process is an in-process subagent backend: it runs each delegated task in a fresh child agent that shares this process and its agent factory, LLM, and tool services. The child starts with an empty conversation, so a task prompt must stand alone; it inherits the parent's working directory, session lineage, provider, model, reasoning effort, and output-token limit unless agentOptions overrides them. A delegation tool or API call reaches it under the spawn provider name. Choose it for the cheapest delegation transport; choose the fork backend when the child must build on the parent's completed conversation turns.
Table of Contents
- Use this package
- Understand the implementation
- Further Exploration
- Model Experience
- Known Limitations and Deferred Work
- Dev Note
Use this package
Mount this backend in a composition that delegates work to fresh in-process children. The common path is explicit: load the subagent service and this backend, then point a delegation tool such as dsh-tool-subagent at the spawn provider.
When to choose it
Choose the spawn backend when the child needs no parent conversation and running in this process is acceptable. Avoid it when the child must build on completed parent turns — the fork backend seeds that history — or when the child must run outside this process, which the out-of-process backends provide. Because the child inherits the parent's working directory and LLM selection by default, a self-contained prompt behaves exactly as written.
Minimal configuration
Load the subagent service and this backend, then configure one delegation tool per target. This is the smallest composition that exposes a subagent tool backed by spawn:
- name: '@deepseek-ai/dsh-subagent'
- name: '@deepseek-ai/dsh-subagent-spawn-in-process'
- name: '@deepseek-ai/dsh-tool-subagent'
config:
provider: spawn
| Field | Default | Meaning |
|---|---|---|
providerName |
spawn |
Provider name registered on ctx.subagents |
The generated configuration catalog is the exhaustive source for every accepted field and its JSDoc.
What a delegation does
One tool call creates a background child and returns its name immediately. The child works in its own session; the parent receives its final answer in a completion notice. The child can also send messages through send_message. A rejected start leaves no published child. Programmatic callers such as workflows can await the activation result directly.
An explicit agentPreset selects the currently registered preset independently; omission joins the parent's active revision. Only spawn supports this choice. Persona and tools belong in the preset definition. Cold resume follows the shared child composition rules.
Understand the implementation
Implementation internals — click to expand
This section explains provider preparation and the activation lifecycle owned by the subagent service.
Design concept
This backend registers the provider and prepares a fresh child session. dsh-subagent owns activation depth checks, child creation, preset composition, structured output, result collection, and disposal. The caller signal cancels unpublished creation; the published handle cancels and reaches quiescence through dispose().
Source map
| File | Role |
|---|---|
src/index.ts |
Provider registration: Config schema, capability declaration, prepareContinuable() |
Run flow
startActivation() resolves the provider and calls prepareContinuable(), then creates and publishes the child. Structured output is attached separately for each activation. Callers can await result and use dispose() to wait for the entire child subtree to reach quiescence.
Ownership and scope
The child has its own registration scope below the inherited or independently selected preset. The parent's agent-local tool restrictions are not imported. The backend advertises agentPreset and agentOptions alongside its other start-time capabilities; the subagent manager applies them during child creation.
Further Exploration
Read these pages when the package-level contract is not enough; they move from the shared subagent model to the sibling backends and exhaustive configuration.
- Subagent subsystem — start requests, results, live runs, and the provider contract.
- dsh-subagent-fork-in-process — the sibling backend that seeds completed parent turns.
- dsh-tool-subagent — the model-facing delegation tool that reaches this provider.
- Generated configuration catalog — every accepted config field and its source declaration.
Model Experience
Child-agent request
What the model sees
The fresh child receives the task content verbatim as its only user message in a new empty conversation, with the parent provider, model, reasoning effort, output-token limit, and working directory by default. The inherited or selected preset supplies tools and prompt sections. No parent conversation message is included.
Token effect
The child pays for a new independent context and history, and no parent-history token is duplicated. The preset's prompt and tools determine repeated prompt, schema, and generated SDK costs.
KV Cache effect
The child's request cache is independent of the parent's. Child history grows append-only, while preset, generated-SDK, provider, or model changes establish a different child prefix.
Parent tool result, indirectly
What the model sees
Through dsh-tool-subagent, the parent first receives the child's name, then a completion notice with its final answer. Child-authored messages arrive through send_message. Internal child tool calls remain in the child session.
Token effect
Parent input grows by one data-dependent result, retained until compaction.
KV Cache effect
Append-only; newly visible content follows the reusable request prefix and does not invalidate existing KV-cache entries.
Known Limitations and Deferred Work
These limits define when the backend is the wrong choice; they are current package constraints.
- Fresh means no parent transcript — the child inherits cwd, lineage, provider, model, reasoning effort, and output-token limit, but none of the parent's conversation; use the fork backend when completed-turn context is required.
Dev Note
Working context for maintainers — click to expand
None.